Our next speaker, just admitted to me, he is not a go developer.
Wow, exciting.
People like that, you know, the go developer for some reason?
So why did I invite Dimash for you today?
Well, you don't build Go, oh well, we don't write Go, but you build it.
And this is most interesting, because those go binaries, they get them everywhere.
And we want to know how this is called, we've written very badly, and it's a positive
compiler.
A positive entry.
And yeah, hello, welcome.
My name is Dimitri.
I am an OS distribution developer.
So I've built lots of operating systems.
I am the Indian developer.
I'm a bunch of core developer.
I started Intel Clear Linux project currently working at Chingar Building WulfioS.
And I'm mostly focused on building production grade container images, such that all the
go code that I compile over a thousand projects, we deploy it in Kubernetes clusters in
production for ourselves and our customers.
And this talk I'm going to dwell into how we build all of the go projects that we ship.
And hopefully, such that other people adopt our best practices.
It will be Linux focused, right, such that majority of this applies to Linux binaries on
x86 and ARM.
However, most of it is transferable to go on other operating systems and architectures as
well.
But you may need to do your own testing.
Yeah, I've been doing this for a while, so hopefully you'll find something useful here.
First we'll start with simple things.
So by default, when you run go build, it will produce binaries with debug symbol attached.
I do want to ask you a question, who has here run GTB or DELF on a go binary to debug
it?
OK, that's a lot.
Keep your hand up if you've done it, well, the binary you're attaching to is running
in a production cluster.
OK, still a few hands.
OK, I want to posit that the debug information is often unused in production, right?
Such that when you build your production container, you can strip that.
So there is LD flags, dash W flag, which will remove debug symbols from the binary
you produce.
And if you want to keep a copy of your debug information, there is another option where
you can use strip and you can strip debug and store it in your debug info server, which
you are running locally.
Because then GTB can still connect, and you can still get all of your debug information
for the five people who connect to their production binaries, right?
They're saving on the binary stage.
It can be like 35, 40% of the binary size, such that you can potentially, you know,
half of all of your container sizes.
Next up, trim path.
So when you build binary, it encodes the file path of your build system inside the
binaries for majority of files that you're compiling.
It leaks the username, it leaks the file system layout of your build infrastructure into
the binary.
And if you strip that.