2020. 2. 9. 01:54ㆍ카테고리 없음
There are, so says the old joke, 10 types of people in the world – those who understand binary. The student a short, self-contained problem that needs to be answered. Because it is too slow to update every position of Cv, we define a counter δv that. 11 https://registry.hub.docker.com/u/veluca93/oii-web/.
The answer is that our app was compiled inside the container. That means the container needs Go installed, and that means it needs Go’s dependencies, which means we need a package manager and really an entire OS.
In fact, if you look at the Dockerfile for golang:1.4, it starts with Debian Jessie, installs the GCC compiler and some build tools, curls down Go, and installs it. So we pretty much have a whole Debian server and the Go toolkit just to run our tiny app.
What can we do? Part 3: Compile! The way to improve is to do something a little off the beaten path. What we’re going to do is compile Go in our working directory, then add the binary into the container. That means a simple docker build won’t work. We need a multi-step container build: go build -o main. Docker build -t example-scratch -f Dockerfile.scratch.
And Dockerfile.scratch is simply: FROM scratch ADD main / CMD '/main' So what’s scratch? Scratch is a special docker image that’s empty. It’s truly 0B: REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE example-scratch latest ca1ad50c9256 About a minute ago 5.60 MB scratch latest 511136ea3c5a 22 months ago 0 B Also, our container is just that 5.6MB! But there’s one problem: $ docker run -it example-scratch no such file or directory Huh?
Docker-compose Is Sooo Slowww Issue 1395 Docker/for-machine
What does that mean? Took me a while to figure it out, but our Go binary is looking for libraries on the operating system it’s running in. We compiled our app, but it still is dynamically linked to the libraries it needs to run (i.e., all the C libraries it binds to). Unfortunately, scratch is empty, so there are no libraries and no loadpath for it to look in. What we have to do is modify our build script to statically compile our app with all libraries built in: CGOENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main. We’re disabling cgo which gives us a static binary. We’re also setting the OS to Linux (in case someone builds this on a Mac or Windows) and the -a flag means to rebuild all the packages we’re using, which means all the imports will be rebuilt with cgo disabled.
These settings changed in Go 1.4 but I found. Now we have a static binary! Let’s try it out: $ docker run -it example-scratch Get x509: failed to load system roots and no roots provided Great, now what? This is why I chose to use SSL in our example.
This is a really common gotcha for this scenario: to make SSL requests, we need the SSL root certificates. So how do we add these to our container?
Depending on the operating system, these certificates can be in many different places. If you look at Go’s x509 library, you can see all the locations where Go searches. For many Linux distributions, this is /etc/ssl/certs/ca-certificates.crt. So first, we’ll copy the ca-certificates.crt from our machine (or a Linux VM or an online certificate provider) into our repository. Then we’ll add an ADD to our Dockerfile to place this file where Go expects it: FROM scratch ADD ca-certificates.crt /etc/ssl/certs/ ADD main / CMD '/main' Now just rebuild our image and run it, and it works! Let’s see how big our app is now: REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE example-scratch latest ca1ad50c9256 About a minute ago 6.12 MB example-onbuild latest 9dfb1bbac2b8 19 minutes ago 520.7 MB example-golang latest 3e 19 minutes ago 520.7 MB golang onbuild 3be7ee2ec1ae 9 days ago 514.9 MB golang 1.4.2 13 9 days ago 514.9 MB golang latest 13 9 days ago 514.9 MB scratch latest 511136ea3c5a 22 months ago 0 B We’ve added a little more than half a meg (and most of this is from the static binary, not the root certs).
This is a really nice little container — it’ll be really easy to push and pull between registries. Conclusion Our goal in this post was to whittle down the container size for a Go application. Go is special in that it can create a statically linked binary that fully contains the application. Other languages can do this, but certainly not all of them. If we were to apply this technique of reducing container size to other languages, it would depend on what their minimal requirements are.
For example, a Java or JVM app could be compiled outside a container and then be injected into a container that only has a JVM (and its dependencies). This is at least smaller than a container with the JDK present.
I’m really looking forward to the strides the community makes in creating both minimal OSes for container guests, as well as aggressively trimming down the requirements for all kinds of languages. The great thing about the public Docker hub is these can be shared with everyone easily. PS: If you liked this article you might also be interested in one of our free eBooks from our Codeship Resources Library. Download it here.