What are debian:buster-slim advantages vs alpine ones?

[Constantine Vassilev]

All examples in Google Cloud Run for building

Golang Docker images are based on Debian.

FROM golang:alpine AS builder

...

FROM debian:buster-slim

...

What are debian:buster-slim  advantages vs alpine ones?

[Amit Saha]

Besides the size of the images, one key difference would be the underlying C library - Debian would be glibc and Alpine would be libmusl

So advantages would be if knowing that libc is available.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2433a1dd-c3ea-4c5c-9f6e-d1595cef99f9n%40googlegroups.com.

[ksbh...@gmail.com]

https://hub.docker.com/r/bitnami/minideb/ is a good alternative.

Regards

– Bhaskar

[Constantine Vassilev]

What about the size of images? For pure Golang project what are the advantages of glibc?

For a project I have to present pro and cons before the team to decide.

[Space A.]

Hi Constantine,

In our project we'd chosen debian-slim images vs alpine few years ago due to a number of reasons, if I recall arguments were like:

1. presence of libc

2. bugs and performance issues of alpine

3. security issues of alpine

4. debian is more suitable for testing with huge amount of tools available out of the box, if needed

After all, talking about saving few tens of megs of hdd space per image (it's the main reason for ppl selecting alpine) is ridiculous nowadays IMO.

среда, 16 декабря 2020 г. в 20:10:49 UTC+3, Constantine Vassilev:

[Zach Hoffman]

In our project we'd chosen debian-slim images vs alpine few years ago due to a number of reasons, if I recall arguments were like:

1. presence of libc

 

There are reasons to choose other images over Alpine, but IMO avoiding musl libc is not one of them. In the case of x86_64 architecture, if you symlink ld-musl-x86_64.so.1 to ld-linux-x86-64.so.2, you can use musl libc in place of glibc, which is functional for most use cases.

See this example Dockerfile to use a linux/arm64 Go release with an Alpine base image:

FROM alpine:3.12

RUN ln -s lib lib64 && \

ln -s ld-musl-x86_64.so.1 lib/ld-linux-x86-64.so.2

RUN set -o pipefail && \

wget -O- https://golang.org/dl/go1.15.6.linux-amd64.tar.gz | \

tar xzC usr/local && \

rm -r usr/local/go/pkg/linux_amd64_race

ENV PATH=${PATH}:/usr/local/go/bin \

GOPATH=/go

Binaries built using this approach can run on other linux/amd64 platforms, even though CGO was not disabled.

As a side note, the resultant image for the above Dockerfile is 369MB, whereas golang:alpine is only 299MB. The size difference is /usr/local/go/pkg/linux_amd64_race, which golang:alpine does not include (but golang:buster, for example, does).

-Zach

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9f0bd697-286f-455a-afef-4a49e98fea80n%40googlegroups.com.

[Justin Israel]

On Friday, December 18, 2020 at 10:31:46 AM UTC+13 za...@zrhoffman.net wrote:

In our project we'd chosen debian-slim images vs alpine few years ago due to a number of reasons, if I recall arguments were like:

1. presence of libc

 

There are reasons to choose other images over Alpine, but IMO avoiding musl libc is not one of them. In the case of x86_64 architecture, if you symlink ld-musl-x86_64.so.1 to ld-linux-x86-64.so.2, you can use musl libc in place of glibc, which is functional for most use cases.

My experience in maintaining  github.com/gographics/imagick  is that the use of an alpine image led to a lot of support tickets. As it turns out, libmusl doesn't work well with ImageMagick. So I just avoid it, as you would need to be sure your C dependencies are happy with it first. 

[Mirko Friedenhagen]

Just to followup here: in the company I work for we discarded usage of Alpine and settled on Debian because:

* Alpine has no process for handling CVEs

* Alpine's musl libc has subtle differences to glibc which led to strange problems (we use Java a lot)

* When building images for Python or Ruby precompiled modules with C-bindings on pypi.org are normally built for glibc, so build times got bigger

And finally: the size of the base image does not matter that much: 

* We have a Kubernetes cluster where a typical node runs 140 pods

* Now if most of these pods share the same debian:buster-slim base (or in our case debian:buster-slim + adoptopenjdk base),

  the base images' sizes are really not very relevant.

Best regards

Mirko

[Miguel Angel Rivera Notararigo]

Most of the issues presented here are only relevant for CGO and other programming languages, not Go.

Also, could anyone share references about the security problems in Alpine? I may say Windows is more secure and faster than Linux (or the opposite), but without any evidence, it is just a conjecture.

Some of the advantages from Alpine for me:

* Image size. My internet connection is 1mbps (my country sucks) and I usually have to share it with 15 other devices, so 100MB is a lot for me.

* Simplicity. It is easier to become a US citizen than having your package in the Debian stable branch. Haha just kidding, but it is pretty hard and a lot of organizational complexity happens there [1]. If you use apt to install some tools, you will get old releases (which is good for end-users or servers, they are really well tested, but we are developers, and in production you should probably use `scratch` with distributed tracing, logging, etc...). Mirroring Debian repositories takes a lot of storage space (the last time I did, it was ~250GB) because you have to download every release and you need special tools [2] for that (you can setup a proxy instead, but internet access is required most of the time), also the mirror gets invalidated every in a while, so you are forced to update or you will end up with a broken environment. For an Alpine mirror you only need rsync and some options for excluding unneeded releases, so less storage space is required (3.12 is <20GB). (Again, my country sucks, so I need a mirror, or I will wait more than 30 minutes every time I have to install some packages).

* Consistency. If your build scripts work on Alpine, they will probably work in any Unix (or at least Linux) environment.

I don't consider deployment advantages because as I said, I prefer deploying my binaries with `scratch`, but if I have to use `alpine`, I would say:

* Minimalism. It is not just only about numbers, but philosophy [3], Alpine keeps everything as minimal as it can, packages are usually split into `package`, `package-docs` (man pages), `package-{bash,zsh,...}-completion`, so you get what you need, no more, no less. 

* Security. The attack surface is very small and C binaries are compiled with some good security options.

Don't take me wrong, I love Debian, it was my very first Linux distribution. If CGO is a requirement and musl doesn't work out of the box, you should choose `debian`, otherwise, I strongly recommend `alpine`.

[1]: https://www.debian.org/releases/

[2]: https://www.debian.org/mirror/ftpmirror

[3]: https://wiki.alpinelinux.org/wiki/Alpine_Linux:Overview

[Space A.]

We don't have a CGO in our project. We want libc and we value it because it's a gold standard which makes things stable and predictive. After all, container must just work, so we focus on our services other that testing and troubleshooting some side technology.

For issues you can take a look at their github and this will also give you some basic idea what process of mitigation is like. You will not find issues older than 2019 however.

воскресенье, 20 декабря 2020 г. в 21:53:08 UTC+3, ntr...@gmail.com: