Building the registry image

Docker's registry server is a fully functional image registry, but it's just the API server it doesn't have a Web UI like Docker Hub. It's an open source application hosted on GitHub in the docker/distribution repository. To build the application locally, you would need to install the Go SDK first. If you've done that, you can run a simple command to compile the application:

go get github.com/docker/distribution/cmd/registry

But if you're not a regular Go developer, you don't want the overhead of installing and maintaining the Go tools on your local machine just so you can build the registry server when you want to update it. It would be better to package the Go tools into a Docker image and set up the image so that when you run a container, it builds the registry server for you. You can do this with the same multi-stage build approach I demonstrated in Chapter 3, Developing Dockerized .NET Framework and .NET Core Applications.

The multi-stage pattern has a lot of advantages. First, it means that your application image can be kept as lightweight as possible you don't need to package the build tools along with the runtime. Secondly, it means that your build agent is encapsulated in a Docker image so that you don't need to install those tools on your build server. Third, it means that developers can use exactly the same build process that the build server uses, so you avoid a situation where developer machines and the build server have different toolsets installed, with the risk of them drifting and causing build issues.

The Dockerfile for dockeronwindows/ch04-registry:2e uses the official Go image, which has a Windows Server Core variant on Docker Hub. The builder stage uses that image to compile the registry application:

# escape=`
FROM golang:1.11-windowsservercore-1809 AS builder

ARG REGISTRY_VERSION="v2.6.2"

WORKDIR C:gopathsrcgithub.comdocker
RUN git clone https://github.com/docker/distribution.git; `
cd distribution; `
git checkout $env:REGISTRY_VERSION; `
go build -o C:out egistry.exe .cmd egistry

I'm using an ARG instruction to specify the version of the source code to build the GitHub repository has tags for each released version, and I'm defaulting to version 2.6.2. Then I use git to clone the source code and switch to the labelled version of the code, and use go build to compile the application. The Git client and the Go tools are all in the base golang image. The output will be registry.exe, a native Windows executable which doesn't need Go installed to run.

The final stage of the Dockerfile uses Nano Server as the base, which can run the Go application just fine. Here's the whole application stage:

FROM mcr.microsoft.com/windows/nanoserver:1809

ENV REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY="C:data"
VOLUME ${REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY}
EXPOSE 5000

WORKDIR C: egistry
CMD ["registry", "serve", "config.yml"]

COPY --from=builder C:out egistry.exe .
COPY --from=builder C:gopathsrcgithub.comdocker...config-example.yml .config.yml

There's nothing complicated in this stage. It begins by setting up the image:

  1. REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY is an environment variable that the registry uses as the base path to store data.
  2. VOLUME is created for the registry data by using the path that was captured in the environment variable.
  3. Port 5000 is exposed, which is the conventional port to use for Docker registries.

The remainder of the Dockerfile sets up the entrypoint for containers and copies the compiled binary and the default configuration file from the builder stage.

Docker containers in Windows Server 2016 had a different implementation of volumes the target directory inside the container was actually a symbolic link rather than a normal directory. That caused issues with Go, Java, and other languages. There was a workaround that was made possible by using mapped drives, but that's no longer needed. If you see any Dockerfiles that use a G: drive, they're based on Windows Server 2016 and can be simplified for Windows Server 2019 just by using the C: drive.

Building the registry image is the same as any other image, but when you use it to run your own registry, there are some important factors to consider.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.216.254