Wrong order of running docker containers in convox/docker-compose

Question

Here is the compose file that I am using. It consist one postgres db container and one redis container. On top of them I have a gunicorn-django-python web server(docker image:python-3.5). There is one nginx proxy server which is linked to web container.

version: '2'
services:

  nginx:
    build: ./nginx/
    ports:
      - 80:80
    volumes:
      - /usr/src/app/static
    links:
      - web

  web:
    build: ./web
    ports:
      - 8000:8000
    volumes:
      - /usr/src/app/static
    env_file: .env
    environment:
      DEBUG: 'true'
      SECRET_KEY: 5(15ds+i2+%ik6z&!yer+ga9m=e%jcqiz_5wszg)r-z!2--b2d
      DB_NAME: postgres
      DB_USER: postgres
      DB_PASS: postgres
      DB_SERVICE: postgres
      DB_PORT: 5432
    command: /usr/local/bin/gunicorn messanger.wsgi:application -w 2 -b :8000
    links:
      - redis
      - postgres

  postgres:
    image: postgres
    ports:
      - 5432
    volumes:
      - pgdata:/var/lib/postgresql/data/

  redis:
    image: redis
    ports:
      - 6379
    volumes:
      - redisdata:/data

I am facing issue while starting docker containers via

convox start -f docker-compose.yml

Problem is , ideally first postgres/redis servers to be started, then the web server and then nginx server in the end according to their linking order. But actually web server is getting started first due to which it fails without db/cache. See error logs below:

web      │ running: docker run -i --rm --name python-app-web -e DB_NAME=postgres -e DB_USER=postgres -e DB_PASS=postgres -e DB_SERVICE=postgres -e DB_PORT=5432 -e DEBUG=true -e SECRET_KEY=5(15ds+i2+%ik6z&!yer+ga9m=e%jcqiz_5wszg)r-z!2--b2d --add-host redis: -e REDIS_SCHEME=tcp -e REDIS_HOST= -e REDIS_PORT=
 -e REDIS_PATH= -e REDIS_USERNAME= -e REDIS_PASSWORD= -e REDIS_URL=tcp://:%0A --add-host postgres: -e POSTGRES_SCHEME=tcp -e POSTGRES_HOST= -e POSTGRES_PORT=
 -e POSTGRES_PATH= -e POSTGRES_USERNAME= -e POSTGRES_PASSWORD= -e POSTGRES_URL=tcp://:%0A -p 0:8000 -v /Users/gaurav/.convox/volumes/python-app/web/usr/src/app/static:/usr/src/app/static python-app/web sh -c /usr/local/bin/gunicorn messanger.wsgi:application -w 2 -b :8000
web      │ invalid argument "redis:" for --add-host: invalid IP address in add-host: ""
web      │ See 'docker run --help'.
postgres │ running: docker run -i --rm --name python-app-postgres -p 5432 -v pgdata:/var/lib/postgresql/data/ python-app/postgres
redis    │ running: docker run -i --rm --name python-app-redis -p 6379 -v redisdata:/data python-app/redis

But it works fine when I completely removes the nginx server, in that case web server is being kicked off after postgres/redis.

I am not able to understand the actual error.

Complete code can be found here at github.

[Note] Found very strange thing I never expected this. Problem was with the name of the container. If I rename the 'ngnix' container to anything like server/webserver/xyz/myngnix/ngnixxxx etc it all worked as expected and in order. But not working with the name ngnix! strange isn't it.

Answer 1

Just add depends_on directive to docker-compose.yml

version: '2'
services:
  depends_on:
    - web
  nginx:
    build: ./nginx/

    ports:
      - 80:80
    volumes:
      - /usr/src/app/static

  web:
    build: ./web
    depends_on:
     - postrges
     - redis
    ports:
      - 8000:8000
    volumes:
      - /usr/src/app/static
    env_file: .env
    environment:
      DEBUG: 'true'
      SECRET_KEY: 5(15ds+i2+%ik6z&!yer+ga9m=e%jcqiz_5wszg)r-z!2--b2d
      DB_NAME: postgres
      DB_USER: postgres
      DB_PASS: postgres
      DB_SERVICE: postgres
      DB_PORT: 5432
    command: /usr/local/bin/gunicorn messanger.wsgi:application -w 2 -b :8000

  postgres:
    image: postgres
    ports:
      - 5432
    volumes:
      - pgdata:/var/lib/postgresql/data/

  redis:
    image: redis
    ports:
      - 6379
    volumes:
      - redisdata:/data

Order of running containers will be ok. But it doesnt mean that when web app will try to connect to redis, this container will be available. If you want reach this fetures you need something like whait for it or docker-compose health check