Docker

tags : Containers

Ya allah.

History §

• Started out being built on top of LXC
• Later moved beyond LXC containers to its own execution environment called libcontainer.

FAQ §

How layers create bloat? §

RUN apt-get install foo
RUN foo generate-things
RUN apt-get uninstall foo

• This will effectively still have foo in the image. (It’s just masking)
• Layers can add bloat to a docker file. This depends very much on the specifics of what the RUN steps are doing and the order of them.
• Eg. Just changing files will often create a layer with another copy of those files with the different attributes (e.g. chmod). That means you have very similar content in two separate layers which creates bloat.
• Each “ALLCAPS” directive in a Dockerfile, like RUN, COPY, etc. are “layers” that get cached. So installing deps should be different layer than copying source code.

What’s the solution to layer bloat? §

• Deleting before creating the layer prevents them from ever actually being stored. You can do this with HEREDOC :)
• When developing scripts for running inside Docker, to copying of the script as late as possible in the Dockerfile so that the preceding layers can be reused
• It is possible with build stages/multi staged builds and copy from, but not super trivial.

What firewall changes does Docker do? §

See Firewalls

How does docker handle networking §

docker network ls --filter 'driver=bridge' # docker0 is default and is named "bridge"
docker network inspect <net_id>

IP and ports §

• Default network range for docker: 172.17.0.0/16 (TODO: Confirm this range, not that it matters for us)
  • Host: 172.17.0.1 (docker0 ip)
  • 1st container: 172.17.0.2, 2nd container: 172.17.0.3 etc.
• When setting port mapping, you can specify the IP, otherwise might get binded to 0.0.0.0

iptables changes §

• Creates these chains: DOCKER, DOCKER-USER, DOCKER-ISOLATION-STAGE1, and DOCKER-ISOLATION-STAGE2
  • DOCKER : Rules for docker
  • DOCKER-USER : Custom user rules that’ll go before docker’s rules.
• Any changes added to FORWARD chain will be evaluated after DOCKER and DOCKER-USER chains.
• docker0 : Rules are used in the FORWARD chain for forwarding packets on this interface to the running containers.

What’s dockers image format? §

It’s OCI but legacy.Maybe updated recently?

What about the scratch image? §

• It’s a very simple thing even simpler than busy box. Doesn’t even have a shell.
• You can attach a shell to it by running another container in its namespace etc. for debugging.

What’s Moby? §

• Umbrella project that develops components used by docker and other container engine. Docker(cli+dockerd) also fall under it.

RUN vs ARG vs CMD vs ENTRYPOINT §

• RUN
  • Executes commands in a new layer, creating a new image. Commonly used for installing software packages.
• CMD
  • Default set of arguments that are supplied to the ENTRYPOINT process.
  • docker run sets the CMD
• ENTRYPOINT
  • Docker’s default entrypoint is /bin/sh -c. So if you provide CMD without entrypoint, or docker run it, then CMD will be arg to sh -c and SIGTERM will go to pid1 and not to what you have in CMD.
  • Can be overridden with --entrypoint
• ARG
  • ARG is used to define a build-time variable, possibly with a default value embedded in the Dockerfile, which can be overridden at build-time (by passing —build-arg).
  • ENV overrides ARG, also if there is actual environment variable in the based image, that too would override ARG

Build Caching §

Theory §

• For anything complex prefer using buildx
• For build caching, we have
  • -mount=type=cache
    • Mount inside the temporary container
    • Useful when a step pulls down a lot of external dependencies that do not need to be in the image and can safely be reused between builds.
    • docs: https://docs.docker.com/build/guide/mounts/
  • --cache-to/from
    • Store the result of a build step and reuse the layer in future builds
    • Avoiding the need to RUN the command again.
    • Docs
      • https://docs.docker.com/reference/cli/docker/buildx/build/
      • https://docs.docker.com/build/ci/github-actions/cache/
  • Both of them serve different purpose, see this SO answer caching - Difference between —cache-to/from and —mount type=cache for the difference
• Optimal cache will be when we’re able to use both, but
  • To summarize, --mount type=cache doesn’t make sense with an “ephemeral builder” (Eg. github actions), but if we’re using a non-ephemeral machine to do our builds, then we can benifit from both -mount=type=cache and --cache-to/from
• --cache-to/from is more widely supported.

How we use it §

• imo just using --cache-to/from should be enough for most usecases for now
• But for fast local builds we’ll keep on using --mount=type=cache,target=$CACHE_DIR_OF_LANGUAGE_PKG_MGR
  • i.e having --mount=type=cache will not hurt us