Docker, docker-compose failure when creating instance, runtime failure

Question

I am attempting to run an application through docker-compose. The docker images build just fine, it is in creating the container that the issue/exception occurs. I know that this definitely has something to do with the bash/sh command involving gunicorn. I just don't know enough to fix the problem I am experiencing.

Basically I run the following commands:

docker-compose build
docker compose up 

(Yes I know you should run docker compose up -d, but this method illustrates my issue clearly through the console)

The particular error message i receive is:

Creating network "flaskapi_default" with the default driver
Creating app ...
Creating app ... error

ERROR: for app  Cannot start service api: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"bash\": executable file not found in $PATH": unknown

ERROR: for api  Cannot start service api: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: \"bash\": executable file not found in $PATH": unknown
ERROR: Encountered errors while bringing up the project.

I have attempted to build and run the dockerfile separately from the docker-compose with varying degrees of success. That got me mixed up in the ENTRYPOINT CMD issue. So, I would prefer to use docker-compose.

The Dockerfile:

    FROM python:3.6-alpine3.7

    RUN apk add --no-cache --update \
        python3 python3-dev gcc \
        gfortran musl-dev \
        libffi-dev openssl-dev

    RUN pip install --upgrade pip

    ENV PYTHONUNBUFFERED 1
    ENV APP /app

    RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
    RUN mkdir $APP
    WORKDIR $APP

    ADD requirements.txt .
    RUN pip install -r requirements.txt

    COPY . .

The docker-compose file:

version: "2"

services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:8000"
    volumes:
      - ./:/app
      - ./config/nginx:/etc/nginx/conf.d
      - ./config/nginx/ssl/certs:/etc/ssl/certs
      - ./config/nginx/ssl/private:/etc/ssl/private
    depends_on:
      - api
  api:
    build: .
    container_name: app
    command: sh -c "gunicorn -w 1 -b 0.0.0.0:5000 manage:app"
    expose:
      - "5000"

I am very sure my command is correct, it works in my development environment which incidentally is MAC OS. This issue is occurring in my other linux based environments. This particular extract is from a fresh ubuntu 18.04 installation.

I have already attempted to add /bin/bash or /bin/sh to the bash or an sh command of the docker-compose file, with a similar result. I am pulling my hair out at the moment, so well, help me obi-wan-kenobi.

The error when using /bin/sh instead of bash. This seems more likely to have been the answer, since I was able to determine that certain docker containers will not support bash.

Error:

Creating network "flaskapi_default" with the default driver
Creating app ...
Creating app ... done
Creating nginx ...
Creating nginx ... done
Attaching to app, nginx
app      |   File "/bin/sh", line 1
app      | SyntaxError: Non-UTF-8 code starting with '\xb1' in file /bin/sh on line 2, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
app exited with code 1
nginx_flask_api | 2019/09/06 19:25:33 [emerg] 1#1: host not found in upstream "api:5000" in /etc/nginx/conf.d/flask.conf:3
nginx_flask_api | nginx: [emerg] host not found in upstream "api:5000" in /etc/nginx/conf.d/flask.conf:3
nginx exited with code 1

Just to iterate I am fairly sure the issue is not in the flask.conf.

Answer 1

So I have figured out the solution. Seems that ENTRPOINT and CMD are different. big surprise. I simply had to add the /bin/sh to the docker-compose file and remove the use of ENTRYPOINT from the Dockerfile.

Also, Stupidly I did not attach in the instance that I got the original error from that I was using ENTRYPOINT ["python"]. Removing that form the dockerfile and adding the bin/sh to the docker-compose file seemed to fix the problem. Both containers are running now.