5 ms·

I just became familiar with the Alpine base images. Curious to know what the benefit conferred by it being 'glibc-based' is exactly?

CraftThatBlock 7y ago
Mostly compatibility. GNU's libc and Alpine's libc implementation should match the same ABI but might not be 100% the same
- devy 7y ago
  Yeah, because of that, it's really hard to get Alpine-based Docker images to work in some situations, for instance: this: https://github.com/grpc/grpc/issues/18150#issuecomment-479994767 https://github.com/grpc/grpc/issues/18150#issuecomment-47999... And this: https://github.com/pypa/manylinux/issues/37 https://github.com/pypa/manylinux/issues/37 I use Python. Anytime you need to compile the source to build a pip package and that the upstream package developer decided that they don't support Alpine's libc implementation (aka musl) then you will have a big problem, unless you can control your dependencies and include as few pip packages that requires compilation or find binary builds.
tyingq 7y ago
Alpine uses musl instead of glibc. That works well for most things, but not all things. For example, there are some JVM implementations that don't like musl unless you do quite a lot of work.
- iagooar 7y ago
  > Alpine uses musl instead of glibc. That works well for most things, but not all things. It works well until it doesn't. And screws up your whole deployment pipeline.
  - techntoke 7y ago
    How so? If you have a deployment pipeline, wouldn't you just detect failures?
  - ptsneves 7y ago
    Never understood the whole alpine thing. I would say most sysadmins doing docker stuff do not understand the concept of what is a libc and its variants to understand the consequences of their choices. Hell I work in embedded and have worked with ulibc or musl and have been bitten quite hard. Some calls not working as expected are loads of fun. All for a few MB, when it could be done just using a proper small base image like has been suggested above.
avip 7y ago
The standard benefits of using something mainstream vs. something niche - x100 more scenarii tested in the wild. In my limited experience, some things don't compile targetting musl. If everything works alpine is sup. Else, it may be fairly difficult (and mostly unjustified) to fix.
yegle 7y ago
For one: with musl you can't reuse anylinux Python packages on PyPI (e.g. lxml) and you'll have to have GCC to build and install those packages.
gauravphoenix 7y ago
Also, I beg you to not use Alpine. It is horrible from the security perspective. The Alpine team doesn't have sufficiently staffed security folks to upgrade packages when vulnerabilities are found. Most popular Linux distro vendors publish OVAL data[1] which can be used to find and fix vulnerable packages. But not with Alpine [2] [1] Example- https://www.redhat.com/security/data/oval/ https://www.redhat.com/security/data/oval/ [2] This is the closest you can get- https://github.com/alpinelinux/alpine-secdb https://github.com/alpinelinux/alpine-secdb

CraftThatBlock 7y ago

Mostly compatibility. GNU's libc and Alpine's libc implementation should match the same ABI but might not be 100% the same

devy 7y ago
Yeah, because of that, it's really hard to get Alpine-based Docker images to work in some situations, for instance: this: https://github.com/grpc/grpc/issues/18150#issuecomment-479994767 https://github.com/grpc/grpc/issues/18150#issuecomment-47999... And this: https://github.com/pypa/manylinux/issues/37 https://github.com/pypa/manylinux/issues/37 I use Python. Anytime you need to compile the source to build a pip package and that the upstream package developer decided that they don't support Alpine's libc implementation (aka musl) then you will have a big problem, unless you can control your dependencies and include as few pip packages that requires compilation or find binary builds.

tyingq 7y ago

Alpine uses musl instead of glibc. That works well for most things, but not all things. For example, there are some JVM implementations that don't like musl unless you do quite a lot of work.

iagooar 7y ago
> Alpine uses musl instead of glibc. That works well for most things, but not all things. It works well until it doesn't. And screws up your whole deployment pipeline.
- techntoke 7y ago
  How so? If you have a deployment pipeline, wouldn't you just detect failures?
- ptsneves 7y ago
  Never understood the whole alpine thing. I would say most sysadmins doing docker stuff do not understand the concept of what is a libc and its variants to understand the consequences of their choices. Hell I work in embedded and have worked with ulibc or musl and have been bitten quite hard. Some calls not working as expected are loads of fun. All for a few MB, when it could be done just using a proper small base image like has been suggested above.

avip 7y ago

The standard benefits of using something mainstream vs. something niche - x100 more scenarii tested in the wild. In my limited experience, some things don't compile targetting musl. If everything works alpine is sup. Else, it may be fairly difficult (and mostly unjustified) to fix.

yegle 7y ago

For one: with musl you can't reuse anylinux Python packages on PyPI (e.g. lxml) and you'll have to have GCC to build and install those packages.

gauravphoenix 7y ago

Also, I beg you to not use Alpine. It is horrible from the security perspective. The Alpine team doesn't have sufficiently staffed security folks to upgrade packages when vulnerabilities are found. Most popular Linux distro vendors publish OVAL data[1] which can be used to find and fix vulnerable packages. But not with Alpine [2] [1] Example- https://www.redhat.com/security/data/oval/ https://www.redhat.com/security/data/oval/ [2] This is the closest you can get- https://github.com/alpinelinux/alpine-secdb https://github.com/alpinelinux/alpine-secdb