7 ms·

I have quit using Alpine. It caused to many issues in production. For some workloads in GO for instance you can use Scratch directly. But slim and distroless ar

I have quit using Alpine. It caused to many issues in production. For some workloads in GO for instance you can use Scratch directly. But slim and distroless are my preferred base images.

mt42or 5y ago
Yes we have experienced many issues with Alpine too. Ubuntu with 25MB compressed is ok.
- hericium 5y ago
  Until it's not. Well working deb/apt is replaced by some self-sabotage called snap before up-to-date packages land there.
  - heavyset_go 5y ago
    Are people actually using Snap in containers? It feels like a convenience feature for desktop users.
    - ZiiS 5y ago
      They don't give you the choice. Applications are only avaliable as either a snap or an deb. With many you might want to containerise (ie Chromium for CI) being snaps. I dont belive they can work in unpriviledged docker containers.
      - yunohn 5y ago
        Which apps are you using via Docker, that are only available as a snap?
      - shaicoleman 5y ago
        There are Chromium debs for Ubuntu 20.04 available from the Linux Mint repo. To get it Chromium under docker, I'm using the following params: --headless --no-sandbox --disable-gpu --window-size=1920,1080 --disable-dev-shm-usage
      - heavyset_go 5y ago
        I understand that, it's just my impression with using Snap that it's used to ship desktop applications in a consistent way.
    - bigpod 5y ago
      you cannot use snap inside a docker or any other OCI container, first of all snap is a containerised package as well so it doesnt make much sense but what is more important it requires SystemD and as far as i know if systemd isnt PID 1 snap deamon wont run and its CLI will output it cant run.
  - paskozdilar 5y ago
    Snap is horrible. The software required for running a Snap Store instance is proprietary [0], and there are no free software implementations as far as I know. Also, the default client code hardcodes [1] Canonical snap store, so you have to patch and maintain your own version of snapd if you want to self-host. Snapd also hardcodes auto-updates that are also impossible to turn off without patching and maintaining your own version of snapd / blocking the outgoing connections to Canonical servers, so snapd is also horrible for server environments. To top that, the developers have this "I know what's good for you, you don't" attitude [2] that so much reminds me of You Know Who. [0] https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/ https://www.techrepublic.com/article/why-canonical-views-the... [1] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ https://www.happyassassin.net/posts/2016/06/16/on-snappy-and... [2] https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707 https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
    - paskozdilar 5y ago
      That being said, I was wondering how many people actually find the Snap system and ecosystem useful. Reverse engineering snapd (which is licensed under GPLv3) and snap app format in order to create a compatible server would be a fun project.
    - dontcare007 5y ago
      So,another systemd in the making... how long until snap takes over dns resolution...
      - paskozdilar 5y ago
        Say what you want about systemd, but it is still Free Software.
    - johnisgood 5y ago
      Yep. I am trying my best to boycott Canonical and their closed source Snap which is akin to Apple Store or Play Store, but for desktop... for... LINUX. Goes against the philosophy in every way imaginable.
- deleted 5y ago
  [deleted]
Beltalowda 5y ago
What issues did you experience with Alpine and Go?
unmole 5y ago
> I have quit using Alpine. As I said to the author of TFA a few days ago: Alpine delenda est.
wereHamster 5y ago
What go build options are recommended to have go output a static binary (that can run inside a scratch image)?
- onei 5y ago
  If you're using plain Go, you get static binaries for free. If you're linking against so C library you might be out of luck. You can try setting CGO_ENABLED=0 in your environment, but I've had mixed success in practice.
  - dimitrios1 5y ago
    CGO_ENABLED=0 has always worked for me in production, but it did come with some tradeoffs, notably, network performance.
  - throwaway894345 5y ago
    I’ve only had success with CGO_ENABLED. If you depend on a C library, then obviously it won’t work, but mercifully few ago programs depend on C libraries (not having straight C ABI compatibility is a real blessing since virtually none of the ecosystem depends on C and its jerry rigged build tooling).
  - wereHamster 5y ago
    Well this is not what I'm seeing. I need to add -ldflags "-linkmode external -extldflags -static" to the go build command otherwise the binary doesn't run inside a scratch image.
burnoutgal 5y ago
Personally I hate scratch images because once you lose busybox, you lose the ability to exec into containers. It's a great escape hatch for troubleshooting.
- kevin_nisbet 5y ago
  There are a few options that help here. With host access, I tend to just use nsenter most of the time to do different troubleshooting. It can be a bit of a pain doing network troubleshooting though since the resolv.conf will be different without the fs namespace. And kubernetes has debug containers and the like now.

I have quit using Alpine. It caused to many issues in production. For some workloads in GO for instance you can use Scratch directly. But slim and distroless are my preferred base images.

mt42or 5y ago

Yes we have experienced many issues with Alpine too. Ubuntu with 25MB compressed is ok.

hericium 5y ago
Until it's not. Well working deb/apt is replaced by some self-sabotage called snap before up-to-date packages land there.
- heavyset_go 5y ago
  Are people actually using Snap in containers? It feels like a convenience feature for desktop users.
  - ZiiS 5y ago
    They don't give you the choice. Applications are only avaliable as either a snap or an deb. With many you might want to containerise (ie Chromium for CI) being snaps. I dont belive they can work in unpriviledged docker containers.
    - yunohn 5y ago
      Which apps are you using via Docker, that are only available as a snap?
    - shaicoleman 5y ago
      There are Chromium debs for Ubuntu 20.04 available from the Linux Mint repo. To get it Chromium under docker, I'm using the following params: --headless --no-sandbox --disable-gpu --window-size=1920,1080 --disable-dev-shm-usage
    - heavyset_go 5y ago
      I understand that, it's just my impression with using Snap that it's used to ship desktop applications in a consistent way.
  - bigpod 5y ago
    you cannot use snap inside a docker or any other OCI container, first of all snap is a containerised package as well so it doesnt make much sense but what is more important it requires SystemD and as far as i know if systemd isnt PID 1 snap deamon wont run and its CLI will output it cant run.
- paskozdilar 5y ago
  Snap is horrible. The software required for running a Snap Store instance is proprietary [0], and there are no free software implementations as far as I know. Also, the default client code hardcodes [1] Canonical snap store, so you have to patch and maintain your own version of snapd if you want to self-host. Snapd also hardcodes auto-updates that are also impossible to turn off without patching and maintaining your own version of snapd / blocking the outgoing connections to Canonical servers, so snapd is also horrible for server environments. To top that, the developers have this "I know what's good for you, you don't" attitude [2] that so much reminds me of You Know Who. [0] https://www.techrepublic.com/article/why-canonical-views-the-snap-ecosystem-as-a-compelling-distribution-agnostic-solution/ https://www.techrepublic.com/article/why-canonical-views-the... [1] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ https://www.happyassassin.net/posts/2016/06/16/on-snappy-and... [2] https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707 https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
  - paskozdilar 5y ago
    That being said, I was wondering how many people actually find the Snap system and ecosystem useful. Reverse engineering snapd (which is licensed under GPLv3) and snap app format in order to create a compatible server would be a fun project.
  - dontcare007 5y ago
    So,another systemd in the making... how long until snap takes over dns resolution...
    - paskozdilar 5y ago
      Say what you want about systemd, but it is still Free Software.
  - johnisgood 5y ago
    Yep. I am trying my best to boycott Canonical and their closed source Snap which is akin to Apple Store or Play Store, but for desktop... for... LINUX. Goes against the philosophy in every way imaginable.
deleted 5y ago
[deleted]

Beltalowda 5y ago

What issues did you experience with Alpine and Go?

unmole 5y ago

> I have quit using Alpine. As I said to the author of TFA a few days ago: Alpine delenda est.

wereHamster 5y ago

What go build options are recommended to have go output a static binary (that can run inside a scratch image)?

onei 5y ago
If you're using plain Go, you get static binaries for free. If you're linking against so C library you might be out of luck. You can try setting CGO_ENABLED=0 in your environment, but I've had mixed success in practice.
- dimitrios1 5y ago
  CGO_ENABLED=0 has always worked for me in production, but it did come with some tradeoffs, notably, network performance.
- throwaway894345 5y ago
  I’ve only had success with CGO_ENABLED. If you depend on a C library, then obviously it won’t work, but mercifully few ago programs depend on C libraries (not having straight C ABI compatibility is a real blessing since virtually none of the ecosystem depends on C and its jerry rigged build tooling).
- wereHamster 5y ago
  Well this is not what I'm seeing. I need to add -ldflags "-linkmode external -extldflags -static" to the go build command otherwise the binary doesn't run inside a scratch image.

burnoutgal 5y ago

Personally I hate scratch images because once you lose busybox, you lose the ability to exec into containers. It's a great escape hatch for troubleshooting.

kevin_nisbet 5y ago
There are a few options that help here. With host access, I tend to just use nsenter most of the time to do different troubleshooting. It can be a bit of a pain doing network troubleshooting though since the resolv.conf will be different without the fs namespace. And kubernetes has debug containers and the like now.