Hitachi Group OSS AdventCalendar # 2 The 24th day will be posted by OSS Solution Center Kamiyama.
In the previous article (1st day, 1st day) (https://qiita.com/hi-naoya/items/d325a57d24a39e4d03e8), I described how to embed a certificate in a Docker image. This time, I would like to write some advanced editions.
Multi-stage build is a feature introduced in the Docker 17.05 migration that allows you to build an image in multiple stages. Before the advent of multi-stage builds, it was difficult to reduce the capacity of the image because the image included packages that were required only at the time of build, but in multi-stage builds, by separating the builds in multiple stages, It is easy to separate the packages required only at build time from the image (execution environment) to be finally distributed.
Regardless of the OS, you need to install something such as the ** ca-certificates ** package, and if you want to create an environment with a minimum principle, it will be a bit unpleasant.
In such a case, you can create a beautiful image by using Docker's multi-stage build.
FROM ubuntu as certs
RUN apt-get update -y && apt-get install -y ca-certificates
COPY self-signed.cert /usr/local/share/ca-certificates/extra/self-signed.crt
RUN update-ca-certificates
FROM ubuntu
COPY --from=certs /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
This will install the certificate enrollment tool (** update-ca-certificates ) and copy and enroll the oleore certificate as usual in the first build. And the second build will only bring the output of ** update-ca-certificates ** ( /etc/ssl/certs/ca-certificates.crt **) to the new image.
The final image will look like this:
--There are system-trusted certificates (/etc/ssl/certs/ca-certificates.crt ), including oleore certificates. - update-ca-certificates ** is not installed --Temporary file for registration (/usr/local/share/ca-certificates/extra/self-signed.crt **) does not exist
Multi-stage builds are very useful for creating beautiful images.
So far, we have dealt with how to register a certificate when it is based on OS or middleware ... In reality, you often want to register a certificate with a specific service (Jenkins, etc.). It may be an inefficient or evil method because it is selfish. If there is a better way, please let us know in the comments!
Let's take Jenkins as an example to find out how to register a certificate. Certificate registration must be done with root privileges, but many images have execute privileges other than root.
So, first of all, let's look at how to make an image ... If you look at Jenkins on Docker Hub, the Dockerfile is not published.
In this case, check the Docker image itself.
docker pull jenkins
docker history jenkins | grep "USER"
In this way, get the jenkins image and see how the history command created the image. At this time, narrow down by "USER" that sets the execution user of the container you want to know this time.
Then
<missing> 2 years ago /bin/sh -c #(nop) USER [jenkins] 0B
In this way, you can see that it is set to the "jenkins" user.
Next, I would like to specify the OS, but if the Dockerfile is not published, I have no choice but to check it. I often
docker run jenkins apt
And so on, I hit the package manager and check for the presence or absence of commands. There is an image that sometimes even erases the package manager, and it may not be possible to identify it with this method, but empirically I was able to identify it almost with this method.
Once you understand this, all you have to do is write the following Dockerfile and build it.
FROM jenkins
USER root
COPY self-signed.cert /usr/local/share/ca-certificates/extra/self-signed.crt
RUN update-ca-certificates
USER jenkins
This will create an image that correctly recognizes the oleore certificate.
This time, when registering an SSL certificate, I wrote how to make the image smaller and how to incorporate it into the first-look image. There is a part of groping around here, so if there is a better way, I would like to improve it.