<p>Go static build and dockerize it, the easy way: <a href="https://gitlab.com/snippets/1689274">https://gitlab.com/snippets/1689274</a></p>
<hr/>**评论：**<br/><br/>voidpirate: <pre><p>Kelsey Hightower has written about this topic in the past: <a href="https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07" rel="nofollow">https://medium.com/@kelseyhightower/optimizing-docker-images-for-static-binaries-b5696e26eb07</a></p>
<p>Take a look at how cert bundles are being included, did you try your example with any SSL calls?</p></pre>Cvballa3g0: <pre><p>This.</p>
<p>I read that you need the certs, so people use alpine and install cacerts. </p></pre>tcrypt: <pre><p>If you use a 2-stage build process with Alpine or the Golang image as a base you should be able to copy /etc/ssl/certs/ca-certificates.crt from the first image to the second:</p>
<pre><code>COPY --from=0 /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/ca-certificates.crt
</code></pre>
<p>Edit: I said "container" but meant "image".</p></pre>Rhelza: <pre><p>Ya, <a href="https://github.com/containous/traefik/blob/master/Dockerfile" rel="nofollow">Traefik</a> does this, though they have the certs versioned within the repo, the approach is pretty much the same anyway.</p>
<pre><code>FROM scratch
COPY script/ca-certificates.crt /etc/ssl/certs/
COPY dist/traefik /
EXPOSE 80
ENTRYPOINT ["/traefik"]
</code></pre></pre>epiris: <pre><p>Go binaries are static by default. Also note that I would highly suggest staying away from upx in general unless absolutely required. If you do use it curate and test your options or your destined to segfault with brute usage. Basic binary stripping via upx or (safer bet strip <bin>) is going to be safe and give a decent result. In the world of 10tb hard drives I think shaving 20%-50% more of a few mb isn’t worth the risk.</p></pre>RufusROFLpunch: <pre><p>I don't know if this is strictly always true. I have found that I sometimes need a CGO_ENABLED=0 to enforce static builds.</p></pre>epiris: <pre><p>It's definitely the default, it just can't be strictly <em>honored</em> for all builds.</p></pre>arp242: <pre><p>Note that <code>strip <bin></code> isn't safe and can cause problems for Go files. The recommended way is to use <code>go install -ldflags='-s -w'</code>.</p>
<p>As for whether it's worth it, there are more considerations than just disk size; not everyone always has a 300Mbit internet connection, and things can add up quite fast if you have dozens or even hundreds of Go binaries.</p></pre>epiris: <pre><blockquote>
<p>Note that strip <bin> isn't safe and can cause problems for Go files. The recommended way is to use go install -ldflags='-s -w'</p>
</blockquote>
<p>I would report the problems you are facing because I imagine they are a bug. Go produces elf binaries. They have a standard- nothing special about the implementation of strip in the Go linker other than it's faster because it does not need to shell out to strip an existing object file. Both implementations will strip the elf files section header of dwarf fields and remove symbol information (symtab) which is where a majority of the savings comes from. This doesn't affect stack traces in Go programs because they are stored in a separate symbol table (gosymtab).</p>
<p>You can easily test this with something like:</p>
<pre><code>go build -ldflags '-s -w' -o s1; go build -o s2 && strip s2
diff -y <(readelf -a s1) <(readelf -a s2)
du -b s1 s2
./s1; ./s2; # works fine
go build -o s3 && upx --brute
./s3 # I've never seen this work, only segfault for even a basic println.
</code></pre>
<p>The data will more or less be the same, though strip may save a small bit of data through more sophisticated restructuring, but it's output should always be legal. On the other hand UPX is much more aggressive and can do things like change the entry address of the program which is not legal for a Go program. Which is why I warned against it.</p>
<p>I do agree though that if you were to strip and doing it at build time is an option using ldflags would make more sense. The take away I was going for here is other than stripping the symbol table and dwarf info there is not much else you can safely do without some intricate knowledge of the specific program you're compiling.</p>
<blockquote>
<p>As for whether it's worth it, there are more considerations than just disk size; not everyone always has a 300Mbit internet connection, and things can add up quite fast if you have dozens or even hundreds of Go binaries.</p>
</blockquote>
<p>I can't say for certain that a group of people out their are not facing productivity issues due to network connectivity, and are only being saved by shaving 30-40% off their "hundreds" of Go binaries. I can say for certain I do not believe most Go developers are part of this group.</p></pre>arp242: <pre><p><code>strip</code> not always working is somewhere in the FAQ, or something rsc (or someone else "of authority") has said. I forgot the details, but it's a known issue, and I believe there are no efforts to fix it right now.</p></pre>epiris: <pre><p>I see, perhaps if you remember where you saw such a thing you could share, until then I’ll go with the empirical facts I listed. I did find <a href="https://dominik.honnef.co/posts/2016/10/go-and-strip/" rel="nofollow">this</a> though when typing “golang faq strip rsc” which seems to explain why some people believe it’s broken. Anyways no big deal really it’s a pretty trivial matter I just wanted to prevent people from using upx as mentioned by the poster. </p></pre>nashkara: <pre><blockquote>
<p>If you do use it curate and test your options or your destined to segfault with brute usage.</p>
</blockquote>
<p>I had a really difficult time parsing this sentence. I'm guessing you were saying:</p>
<blockquote>
<p>If you do use it, curate and test your options or you're destined to segfault with brute usage.</p>
</blockquote></pre>
