I've been dabbling with Docker to run services on my new Raspberry Pi and being a beginner at Docker myself, it was hard sometimes to debug why a docker container was failing as soon as it was started. Since a container "stays alive" only until its CMD
process is running, there is no way to do a quick look-see inside the container if it has already Exited.
To change the Dockerfile
to perform trial and error means that you will have to rebuild it again - which is time consuming.
One way to keep a container running without having to do this, is to override the Dockerfile
command from the docker-compose.yml
file.
For example:
version: "3"
services:
redis:
image: redis
web:
image: web:v001
build:
context: .
dockerfile: Dockerfile
ports:
- "3000:3000"
volumes:
- .:/opt/www
depends_on:
- redis
And in the Dockerfile
you have a command:
FROM node:14-alpine
ENV APP_PATH /opt/www
RUN mkdir -p $APP_PATH
WORKDIR $APP_PATH
COPY package.json ./
COPY yarn.lock ./
RUN yarn
COPY . .
RUN yarn build
CMD yarn start
EXPOSE 3000
Anytime CMD yarn start
fails, the container exits and is no more accessible for debugging.
Modify docker-compose.yml
to include command
override.
version: "3"
services:
redis:
image: redis
web:
image: web:v001
build:
context: .
dockerfile: Dockerfile
command: "tail -f /dev/null" # <--- <--- <---
ports:
- "3000:3000"
volumes:
- .:/opt/www
depends_on:
- redis
Now, when you start the container using docker-compose up -d
, the container stays running.
Next, use docker ps -a
to list all containers and obtain the hash for the container id.
Then, run sh
within the container by: docker exec -it <sha> sh
.
If everything goes well, you should see the shell prompt within the container:
/opt/www #
Now, you may debug for missing files, env vars, or even try to run yarn start
and see why it is failing.