podman-compose icon indicating copy to clipboard operation
podman-compose copied to clipboard

depends_on wrong starting order

Open dmenneck opened this issue 1 year ago • 6 comments

I've noticed that the following compose.yml configuration starts the django service before the db service, even though it should be the other way around. The depends_on configuration does not seem to affect the start order.

version: '3.7'
services: # both services run on the same network
  db:
    container_name: postgres
    image:  docker.io/library/postgres:15.3 
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: postgres_db
    ports:
      - 5432:5432
    volumes:
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql

  django:
   container_name: django
   build: 
     context: .
     dockerfile: Containerfile.django
   depends_on:
     - "db"
   ports:
     - "8000:8000"

This results in the error could not translate host name "db" to address: Name or service not known because the db service is not up and running at the time when the django service is trying to communicate.

dmenneck avatar Jun 23 '23 11:06 dmenneck

Would you please show me the output of up command

I'm sure we start it in correct order

muayyad-alsadi avatar Jun 23 '23 11:06 muayyad-alsadi

Yes of course! As you can see, the django service starts first:

(env-podman) PS C:\Users\dme\code\ip> podman-compose up
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.5.1
** excluding:  set()
['podman', 'inspect', '-t', 'image', '-f', '{{.Id}}', 'ip_django']
Error: inspecting object: unable to inspect "ip_django": failed to find image ip_django: ip_django: image not known
podman build -f ip-maps-light-backend-backend-experimental\Containerfile.django -t ip_django ip-maps-light-backend-backend-experimental
STEP 1/6: FROM python:3.9.13
STEP 2/6: WORKDIR /usr/src/app
--> Using cache d7ee5953136a813885c3eb4c1eeb9aa2283f3eec450b5d40ffd766d32e94c97d
--> d7ee5953136a
STEP 3/6: COPY requirements.txt ./
--> Using cache 889a0b828a0a093bd74b79e4d8e4d54dd9999f0fbc4fceabbad6a68fd7837fa0
--> 889a0b828a0a
STEP 4/6: RUN pip install -r requirements.txt
--> Using cache dff954b654ae1b81316bd4f379285807bcf163560158f8ce1a70a9a8286180e8
--> dff954b654ae
STEP 5/6: COPY . .
--> Using cache c2a2473d86c4684f2bf2e69c5dac53ed21d8276f32218d94d4f054ef03b3bc54
--> c2a2473d86c4
STEP 6/6: RUN python manage.py migrate
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 244, in ensure_connection
    self.connect()
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 225, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 203, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/usr/local/lib/python3.9/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: could not translate host name "db" to address: Name or service not known


The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/app/manage.py", line 22, in <module>
    main()
  File "/usr/src/app/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
    utility.execute()
  File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 440, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 414, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 460, in execute
    output = self.handle(*args, **options)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 98, in wrapped
    res = handle_func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/core/management/commands/migrate.py", line 91, in handle
    self.check(databases=[database])
  File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 487, in check
    all_issues = checks.run_checks(
  File "/usr/local/lib/python3.9/site-packages/django/core/checks/registry.py", line 88, in run_checks
    new_errors = check(app_configs=app_configs, databases=databases)
  File "/usr/local/lib/python3.9/site-packages/django/core/checks/model_checks.py", line 36, in check_all_models
    errors.extend(model.check(**kwargs))
  File "/usr/local/lib/python3.9/site-packages/django/db/models/base.py", line 1461, in check
    *cls._check_indexes(databases),
  File "/usr/local/lib/python3.9/site-packages/django/db/models/base.py", line 1864, in _check_indexes
    connection.features.supports_covering_indexes
  File "/usr/local/lib/python3.9/site-packages/django/utils/functional.py", line 49, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/features.py", line 85, in is_postgresql_11
    return self.connection.pg_version >= 110000
  File "/usr/local/lib/python3.9/site-packages/django/utils/functional.py", line 49, in __get__
    res = instance.__dict__[self.name] = self.func(instance)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 354, in pg_version
    with self.temporary_connection():
  File "/usr/local/lib/python3.9/contextlib.py", line 119, in __enter__
    return next(self.gen)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 639, in temporary_connection
    with self.cursor() as cursor:
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 284, in cursor
    return self._cursor()
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 260, in _cursor
    self.ensure_connection()
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 244, in ensure_connection
    self.connect()
  File "/usr/local/lib/python3.9/site-packages/django/db/utils.py", line 91, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 244, in ensure_connection
    self.connect()
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/base.py", line 225, in connect
    self.connection = self.get_new_connection(conn_params)
  File "/usr/local/lib/python3.9/site-packages/django/utils/asyncio.py", line 26, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/base.py", line 203, in get_new_connection
    connection = Database.connect(**conn_params)
  File "/usr/local/lib/python3.9/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
django.db.utils.OperationalError: could not translate host name "db" to address: Name or service not known

Error: building at STEP "RUN python manage.py migrate": while running runtime: exit status 1

exit code: 1
['podman', 'ps', '--filter', 'label=io.podman.compose.project=ip', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
recreating: ...
** excluding:  set()
podman stop -t 10 django
Error: no container with name or ID "django" found: no such container
exit code: 125
podman stop -t 10 postgres
postgres
exit code: 0
podman rm django
Error: no container with ID or name "django" found: no such container
exit code: 1
podman rm postgres
postgres
exit code: 0
recreating: done


['podman', 'network', 'exists', 'ip_default']
podman create --name=postgres --label io.podman.compose.config-hash=49736e1b13ae160e2dbc53450a34bee0bb977da8b5fe59dcb8c54e0ce63c94ab --label io.podman.compose.project=ip --label io.podman.compose.version=1.0.6 --label [email protected] --label com.docker.compose.project=ip --label com.docker.compose.project.working_dir=C:\Users\dme\code\ip --label com.docker.compose.project.config_files=compose.yaml --label com.docker.compose.container-number=1 --label com.docker.compose.service=db -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=postgres_db -v C:\Users\dme\code\ip\init.sql:/docker-entrypoint-initdb.d/init.sql --net ip_default --network-alias db -p 5432:5432 docker.io/library/postgres:15.3
999cb9b7060b8a58b70680cae0de0e48c21aad93c90668199e6de7e24f196aa2

I have not included the rest of the output of the postgres container for the sake of clarity.

dmenneck avatar Jun 23 '23 11:06 dmenneck

It failed on build phase not on run phase.

Build phase and run phase should be strictly separated according to 12 factors.

Is running the dependency during build phase specifically mentioned in the SPEC? Is it docker-,compose behavior?

muayyad-alsadi avatar Jun 23 '23 12:06 muayyad-alsadi

Yes, it fails on build stage because step 6 of the django service build tries to populate the postgres database. However, the django service still builds first and the db service second (even though is should be the other way around). @muayyad-alsadi, do you know why thats the case?

dmenneck avatar Jun 23 '23 12:06 dmenneck

same issue, depends_on simply doesn't work

denisbereng avatar Oct 31 '23 14:10 denisbereng

Hey, any updates on the depands_on issue?

mrfrsh avatar Aug 08 '24 13:08 mrfrsh