Container images also represent binaries, since they contain the running application, including runtime and operating system binaries. In order to build container images, base images and all artifacts that are added at build time need to be present. If they don't already exist on the build environment, base images are retrieved implicitly.
For each build step defined in the Dockerfile, an image layer is added on top of the previous layer. Last but not least, the application that was built just before is added to the container image build. As shown previously, Java EE application containers consist of an installed and configured application server that auto-deploys the web archive at runtime.
This image build is orchestrated by the CI server as part of the pipeline. One solution is to have the Docker runtime installed, in the same way as the Maven build system. The pipeline step then simply invokes an image build similar to docker build -t docker.example.com/hello-cloud:1 . in the job workspace directory. The Docker image build, for example, takes the WAR file under Maven's target directory and adds it into the container.
The built image is tagged with an image name and unique tag, depending on the build number or some other unique information. Docker image names imply the registry they will be pushed to. An image identifier such as docker.example.com/hello-cloud:1 will implicitly be transmitted from and to the host docker.example.com. The pipeline pushes the image to the Docker registry in most cases, a company-specific registry.
Depending on the company's workflow, Docker images can be re-tagged as part of the pipeline as well. For example, special tags such as the latest tag can refer to the actual latest built versions and so on. This is accomplished by explicitly re-tagging the image, so that two identifiers point to the same image. Unlike Java archives, Docker images can be re-tagged without changing their contents. The second tag needs to be pushed to the repository, as well. However, the rest of this chapter will show you that it's not required to refer to images using latest versions, such as the Docker latest tag. In fact, similar to snapshot versioning it's advisable to avoid latest versions. Being explicit in all artifact versions is less prone to error.
Some engineers argue that running Docker builds inside the CI server may not be the best idea if the CI server itself runs as a Docker container. Docker image builds start temporarily running containers. It is certainly possible to either run containers in a container or connect the runtime to another Docker host, without opening the whole platform to potential security concerns. However, some companies choose to build the images outside of the CI server instead. For example, OpenShift, a PaaS built on top of Kubernetes, provides build functionality that comprises a CI server as well as image builds. It is therefore possible to orchestrate image builds from the CI server which are then built in the OpenShift platform. This provides an alternative to building container images directly on the CI server.