Attaching Networks to Docker Build

The docker build command is a vital element in the DevOps process. Unlocking the full potential of docker build opens up new use cases and prepares us for the future Buildx.

Attaching Networks to Docker Build

The docker build command is something I never gave much thought to as it just works. Run the command and out the other side is your newly built Docker image. That was easy! But it is not all sunshine and green grass in DevOps land.

If you have been wrangling code for a while, then eventually the command you have been using for years will suddenly stop working in a new environment.

docker build is a command that is part of the core functionality of Docker, and you become very intimate with this command when adding Docker commands to CI/CD pipelines. The `docker build` is especially vital, so when it stops working, it halts the entire development process.

Docker Build with GitLab runners

We use GitLab for all of our projects. Why do you ask? Have a look at the article Limit your Tech Toolset to understand our love for GitLab. GitLab uses runners which execute the steps in the build pipeline on a server located in the development or test environments.

The Windows runner is where the problem appeared. When I executed a build on the Windows runner `docker build` ran into an issue not being able to resolve DNS. As it turns out, this is a Windows limitation due to the number of default NAT networks allowed. Elton Stoneman identifies the issue as well as workarounds in his Docker Windows KB

Even with Elton's workaround, this was not solving my issue with DNS resolution on newly created Docker Networks. The other networks on the same host worked just fine. The build network was the problem child. I tried adding DNS to the network, populating the /etc/hosts with the DNS name/IP of the servers I was trying to reach, and much more with no luck.

It wasn't until I reverted to reading the docker build documentation that I stumbled upon the possibility to attach `docker build` to an existing network. It's in the documentation yet somewhat obscure with no examples or clear definition of what it does.

Excerpt from the Docker Build reference:

--network Set the networking mode for the RUN instructions during build

Yup, that's all you get. OK, OK. I explain how this works in the Workaround section.‌‌

Docker Build Workaround

The use case I have is I needed to connect docker build to a network which could resolve DNS. You may have another requirement which you want to connect to a network during Build to communicate to certain services or resources to help with the Build. After using the `--network` flag, I am finding a lot more use cases.

Workaround

  • docker network ls
  • Choose a known working network
  • docker build --network=<known working network name>

By default, Docker uses the default network for building. Setting the network manually ensures the network can access the internet.

The --network flag has fixed my Build and has opened up new use cases for builds.

Docker Build Going Forward

Now, the possibility of `docker build` is growing with every release. DockerCon SF 2019 the experimental feature docker buildx was announced. Buildx introduces the concept of build instances similar to the GitLab runner concept allowing for simultaneous builds to execute in isolated build environments. Build instances will improve performance and decrease build times for large projects. Win!

Another great feature in Buildx is the possibility to Build images for different architectures from the same build machine. Now, it is possible to build ARM, X86, and possibly RISC-V in the future all from the same build instance. We no longer need specialized build servers per CPU architecture, which will save us time and money as well.

The Buildx features still contain the experimental flag, but I predict these features will slowly start working their way into the production release. `docker build` continues to add functionality and will be even more critical going forward.

Great! I'll create an FAQ section based on the blog post "Attaching Networks to Docker Build" from brianchristner.io.

FAQ Section: Attaching Networks to Docker Build

How do I attach a network to a Docker build?

To attach a network to a Docker build, use the --network flag with the docker build command. For example:

docker build --network=<network-name> -t <image-name> .

Replace <network-name> with the name of your Docker network and <image-name> with your desired image name. This allows the build process to access network resources, such as downloading dependencies.

What are the benefits of attaching a network to a Docker build?

Attaching a network to a Docker build can improve the build process by allowing access to network resources. This is useful for downloading dependencies, accessing internal services, and performing build-time operations that require network access. It can also help in achieving more consistent and reproducible builds.

Can I use multiple networks during a Docker build?

No, you can only specify one network when using the --network flag with the docker build command. However, you can switch between different networks at different stages of the build process by using RUN instructions to connect and disconnect from networks as needed.

How do I troubleshoot network issues during a Docker build?

To troubleshoot network issues during a Docker build, you can:

  1. Check the network settings and ensure the specified network exists.
  2. Verify the network connectivity and DNS resolution within the build container.
  3. Use debugging tools like curl or ping within the build steps to diagnose connectivity issues.
  4. Review Docker daemon logs for any error messages related to networking.

Is it secure to attach networks to Docker builds?

Attaching networks to Docker builds can introduce security risks if not managed properly. Ensure that the network used is secure and restricts access to only necessary resources. Avoid exposing sensitive information or services to the build environment. Always follow best practices for Docker security, such as using minimal base images and keeping dependencies up to date.

Follow me

If you liked this article be sure to Follow Me on Twitter to stay updated!