t also adds complexity to the Dockerfile language when there are clear workarounds. Don't push so much config in the parent Dockerfile and leave if for the inheriting images instead. (aka: stop sourcing random images on docker hub :D)

Since docker 17.05 there is also a new way to do multi-stage builds that removes most of the need for this issue (this is a single Dockerfile):

First import the original image

FROM nginx AS source-image

Second step of the build, start with an empty image

FROM scratch

Copy the data from the original image

COPY --from=source-image / /

Re-define all the config

EXPOSE 80
STOPSIGNAL SIGTERM
CMD ["nginx", "-g", "daemon off;"]

EDIT: Forgot to say, the second solution squashes all previous layers. I don't think it's a big deal but it's good to know.

Quand on utilise une image comme celle là, il ne faut pas faire n'importe quoi comme installer des packages php5-extensions, ce n'est pas du tout prévu... Il faut suivre la doc et utiliser les outils mis à dispo sinon on se retrouve un Dockerfile qui n'a aucun sens...

Dans ma todo : migrer ces "choses" pour utiliser une image debian de base

Mieux vaut être sous GNU/Linux

docker stop command send SIGTERM to pid1 inside the container to let a chance to stop gracefully (https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/)
Unfortunatly some software ignore SIGTERM and need to be stopped by their own command (hello opendj)

To do so, in the Dockerfile, in the CMD, I use a script like this :
/thecommand/tostart/thesoftware/inbackground
trap "/thecommand/tostop/thesoftware" SIGTERM
while true; do sleep 1; done

so my script is run with PID1, docker stop sends SIGTERM, my script catch (trap) the signal, and run the command to stop gracefully

I don't know if this shit is expected (normal behaviour or not) but this is annoying

bash :

$ toto=tata
$ echo $toto
tata

$ toto='tata'
$ echo $toto
tata

$ toto="tata"
$ echo $toto
tata

avec docker run -e

$ docker run -e toto=tata -it debian:jessie bash
root@5de64152ed05:/# echo $toto
tata

$ docker run -e toto='tata' -it debian:jessie bash
root@99a6b62f595c:/# echo $toto
tata

$ docker run -e toto="tata" -it debian:jessie bash
root@ab7581c30734:/# echo $toto
tata

avec docker run --env-file:

$ cat env.file
toto="tata"
$ docker run -it --env-file env.file debian:jessie bash
root@805480de4a52:/# echo $toto
"tata"

$ cat env.file
toto='tata'
$ docker run -it --env-file env.file debian:jessie bash
root@004b88cc448d:/# echo $toto
'tata'

$ cat env.file
toto=tata
$ docker run -it --env-file env.file debian:jessie bash
root@2ca9908d1cdf:/# echo $toto
tata

avec docker compose:

$ cat docker-compose.yml
version: '2'
services:
foo:
image: debian:jessie
container_name: foo
environment:

• toto1=tata
• toto2="tata"
• toto3='tata'
  command: tail -f /var/log/dmesg

docker-compose up -d
docker exec -it foo bash

root@71a9a886cc24:/# echo $toto1
tata
root@71a9a886cc24:/# echo $toto2
"tata"
root@71a9a886cc24:/# echo $toto3
'tata'

Compose file version 2.1 and up

Healthcheck configuration can now be done in the service definition using
the healthcheck parameter
Containers dependencies can now be set up to wait on positive healthchecks
when declared using depends_on. See the documentation for the updated
syntax.