Docker

• Dockerfile - file used to define the image that will represent your service. It’ll define the necessary OS, the dependencies that must be installed, the source code, the env vars, the commands to build and run the app/service in the server

• Image - The ‘blueprint’ of your service. The ‘class’ that defines the service. This is the package that has it all that’s needed to run your service. It’s created from a Dockerfile with the docker build command:

  docker build -t image-name .
  

  -t tags the image with a name, . tells where to look for the Dockerfile.

• Container - An instance of an image. The ‘object’ created from the ‘class’. You can have multiple containers running from the same image.
  It’s created from an image with the docker run command:

  docker run -d -p 3000:3000 --name container-name image-name
  

  -d runs the container in detached mode (in the background), -p maps the host port to the container port.

• docker exec - A command that allows you to run commands in a running container. Used to interact, explore and debug the container.

  docker exec -it container-name /bin/bash
  

  -it allows interactive terminal access.

  To run a command in background, instead:

  docker exec -d container-name mkdir /tmp/mydir
  

• compose.yml - file that defines how to run the service defined in a specific Dockerfile. Can have multiple related services needed for the app to run together. Eg: a rails web app, its redis and postgresql db services. Volumes are listed and ‘bind’ed here.
  The command docker compose up reads this file and starts the services defined in it.

• docker init - A command like git init and bundle init. Creates the Dockerfile and compose.yml files for you when run from a project’s root.

• dev container - It’s a “development container” where you have a running container that has the code, its dependencies and all the tools needed to develop the code. It allows you to edit your code as if it was in the container itself.
  A project needs a .devcontainer/devcontainer.json file to define the dev container settings. Opening it in vscode with the ‘dev container’ extension will make it to detect the dev container. Once it does its work, you’ll see that the code is in the container (as if you COPY’d it from host to container, and then docker-exec’d into it). From there you can run the project commands.
  This doesn’t seem to be absolutely necessary.
  And this is different from the “production container” that we normally build with the help of the project’s Dockerfile. That one is a representation of the server that’s going to run in production. A “dev container” is not that.

• Documentation:
  • https://docs.docker.com/reference/dockerfile/
  • https://docs.docker.com/reference/compose-file/
  • https://containers.dev/implementors/json_reference/
• Useful Reads:
  • https://codefresh.io/blog/docker-anti-patterns/
• Questions:
  • What are layers?
  • How does caching work?
  • How volumes and network interfaces work?

28 Sep 2025