Some question(discuss) for docker-compose.yml of lucky 1.0.0.

[zw963]

Question 1: Why we not use docker-compose short syntax for volumes?

e.g.

    volumes:
      - type: bind
        source: .
        target: /app
      - type: volume
        source: node_modules
        target: /app/node_modules
      - type: volume
        source: shards_lib
        target: /app/lib

Can be replace with:

volumes:
      - .:/app
      - node_modules:/app/node_modules
      - shards_lib:/app/lib

---

Question 2:

In fact, i don't understood, we have been bind mounted the . into /app(that included /app/lib, /app/node_modules, right?) why we still need use volume to mount /app/node_modules and /app/lib? is it necessary?

---

Question 3:

As discuss in this SO answer, we can add a POSTGRES_DB env to make docker-compose create pg database automatically when docker-compose run, following is a example:

version: "3"
services:
  app:
    build:
      context: .
    ports:
      - ${APP_PORT}:3000
    environment:
      DATABASE_URL: postgres://${DB_USERNAME}:${DB_PASSWORD}@db:${DB_PORT}/${DB_NAME}
    depends_on:
      - db
  db:
    image: postgres:14-alpine
    environment:
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: ${DB_NAME}

This will make install postgresql-client in docker/development.dockerfile not necessory, right? AFAIK, install this package is only for createdb which is used by lucky_cli for create db?

Thanks

[zw963]

I found the postgres container will create database automatically if match following two conditions:

1. db user name must not be "postgres"
2. database name same as db user name.

lucky cli generated docker-compose use this hack.

DATABASE_URL: postgres://lucky:password@postgres:5432/lucky

But i consider this is a code bad smell to use this black technology.

[jwoertink]

We do this because you may have other postgres installations already installed. This avoids an issue where you have lots of apps locally with different postgres installs (10, 12, 14, etc...). I don't think it's a hack since it was actually intended this way and not just a "work-around" to make something work.

[zw963]

Hi, what i means is, if you change code to:

DATABASE_URL: postgres://lucky:password@postgres:5432/lucky123

docker-compose up will failed, because postgres assume db name same as user name in this case, but user don't know why, specify the DB_NAME like my previous comment then use it is better.

services:
  app:
    build:
      context: .
    ports:
      - ${APP_PORT}:3000
    environment:
      DATABASE_URL: postgres://lucky:password@postgres:5432/lucky123
    depends_on:
      - db
  db:
    image: postgres:14-alpine
    environment:
      POSTGRES_USER: lucky
      POSTGRES_PASSWORD: password
      POSTGRES_DB: lucky123

[jwoertink]

Ah, I see what you mean.

I don't think you ever need to change the DATABASE_URL here because even though it says the db_name is lucky, it's more of just an alias. For example, your db_name could be clover_development, but you would still connect to it using /lucky (only with docker). If you don't want your alias name to be /lucky, then you would have to also change this line to be lucky123:, right?

[zw963]

If you don't want your alias name to be /lucky, then you would have to also change this line to be lucky123:, right?

No, i tested it, after change that line, docker-compose up still not work, that lucky: only stand for host name which other container connect to app, but in the url, we need the database name, they are not alias?