5 ms·

What worries me about Alpine is that it invents YET-ANOTHER package manager(apk) . I think it claims that it builds on top of Gentoo... But could someone explai

What worries me about Alpine is that it invents YET-ANOTHER package manager(apk) . I think it claims that it builds on top of Gentoo... But could someone explain why Deb or rpm could not be used. Does using Deb or rpm screw up size or security in some way. We could also have gotten access to the Debian/Fedora repository in a pinch. Not all of us run statically compiled go executables and often have tons of dependencies that need to be installed for webapp. P.S. And the package manager apk is unfortunately named to conflict with IMHO the biggest package repo in the world:Android. It is virtually impossible to Google anything meaningful without running into android.

digi_owl 11y ago
From their wiki, the format itself it basically a tar.gz wrapped in a digital signature.
monkmartinez 11y ago
What is the fall back if a package is not available? For example, I was able to find an APK for python 3.5.1-r0. However, I can find nothing for Python 3.4 except a bug report and some hacky fixes. Also, it looks like running anything that require binaries that have compiled against glibc will be wonky as hell.
- jwatte 11y ago
  The whole point is: Do not run with glibc! If you need something that's not available, build it.
  - monkmartinez 11y ago
    Then I am debugging builds, no?
  - seanp2k2 11y ago
    We've been down this road many times before. It does not historically lead to happy places. Why will it be different this time?
  - FreeFull 11y ago
    And if it's a proprietary piece of software and you don't have the source code? Or you do have the source, but the build process is too convoluted to figure out?
    - newjersey 11y ago
      1. If it is proprietary, we don't need it in docker. If they want to play in this ecosystem, they have to make their source free. 2. If the build process is too convoluted, we try our best to simplify it. Building something like Mozilla Firefox might take a few hours the first time but it will not always take that long. I for one would fully support this new pro-source software distribution mechanism. We could probably use git tags to find out when we have updates if we could get people to agree on some kind of convention... Processor vendors should love this change because every server will build all the software it needs from source. Edit: downvoters, care to leave a note?
      - tokenizerrr 11y ago
        > Edit: downvoters, care to leave a note? Sure. You don't get to dictate what I run in MY docker containers hosted on MY private registry used in MY environment. If I want to run proprietary software in my docker containers, I damn well will. And I expect Docker not to work against that, if just for the reason that it works fine today, why not tomorrow?
        newjersey 11y ago
        You're more than welcome to build that from source too! Where you get the source code could still be a private, authenticated area. You could choose to never publish your docker files. That's fine. I'm just saying that we should move to a better model where if you distribute software, you should also distribute the source code (and hopefully build tools) for it. Why is this so difficult? It does not put any constraints on the user that vendors of proprietary software haven't artificially erected.
        11y ago
  - deleted 11y ago
    [deleted]
- vidarh 11y ago
  > What is the fall back if a package is not available? Then use another distro if you're not prepared to invest the effort into it. The point of people wanting to move Docker images to distros like Alpine is to minimize size. That matters if you're going for massive density etc., but depending on your use cases, using e.g. Ubuntu or Debian or Centos as a base can be just fine. It's worthwhile to move the official images to it because they are used so widely. It's not necessarily worth it for every random image someone puts together.
  - ageofwant 11y ago
    The official images are used so widely precisely because they are trivially extendable using apt. This will not be the case if they are based of something obscure.
- awinter-py 11y ago
  There are even more exciting libs like numpy/scipy which rely on a system BLAS package before they can even compile (and take forever). This is a problem that Ubuntu has made less difficult but a better solution would be package managers for C and fortran. If the 'alpine experiment' results in more work on portable build tools for complex projects, that's a win for the open source community.
JasonSage 11y ago
Alpine uses the musl libc and the OpenRC init system. In order for a deb or rpm package to install correctly, the binary would have to be built for musl already and the necessary information to set up services on the init system be provided. I don't know how the latter works for other package managers, be it in a way compatible with OpenRC or not. P.S. In my experience APK has been rock-solid and simple to use.
- sandGorgon 11y ago
  this is a huge blocker - we are already in a world where RPM and DEB dont get released in tandem. And it has taken millions of man hours to resolve deep problems in dependency resolution, circular dependencies,etc. For a startup like mine, I already estimate I'm installing hundreds of libraries (Ruby gems, Python wheels, etc). I'm pretty sure some of them are weird dependencies... but I have come to trust apt and dnf. There is zero reason for me to trust Alpine's new package manager that is managed by a single dev. Disk space is cheap - my time is not. This is the big blocker - if Alpine can figure out a way to co-exist with apt or dnf (pick your own poison), that makes it compelling. But then again, I would ask - can something like Alpine be achieved with debian or centos. Even if it is 3X the size (30mb) ? EDIT: I run a fat docker VM based on debian with nginx, rsyslog, postgresql and ruby+puma using supervisord. There is absolutely ZERO need for OpenRC. I have been running this in production for over 18 months since before Docker was this stable.
  - anon987 11y ago
    Ehh I wouldn't worry about it too much. The whole idea behind these skinny distros is there are few if any packages. Distros can also consider using something like rpm-ostree[1] for making skinny, RPM-based immutable file systems where you only update the "master" image then push it out. [1] https://wiki.gnome.org/Projects/OSTree https://wiki.gnome.org/Projects/OSTree
  - kylequest 11y ago
    The package ecosystem is the biggest challenge for Alpine. It's just not there and there's only so much you can do yourself. You need to have enough critical mass before the majority of the 3rd party providers begin to release packages for Alpine. There's a way to have small Docker images using the standard distros like Ubuntu where you get to use your favorite packages. DockerSlim [1] was created for this. It collects the artifacts your are actually using in the container throwing everything else away... Here are a few numbers to give you an idea (using on Ubuntu 14 base image): node: 431MB -> 14MB python: 433MB -> 15MB ruby: 406 MB -> 14MB java: 743MB -> 100MB It's a work in progress, so there might be corner cases where it's less than ideal. It's not tested well enough with "fat" images. Pull Requests are greatly appreciated :-) You also get auto-generated Seccomp (already usable) and AppArmor (WIP) profiles, so you don't have to create them manually. [1] http://dockersl.im http://dockersl.im
ape4 11y ago
The name conflict with Android make this the worse named piece of software. Any other name would be better.

digi_owl 11y ago

From their wiki, the format itself it basically a tar.gz wrapped in a digital signature.

monkmartinez 11y ago

What is the fall back if a package is not available? For example, I was able to find an APK for python 3.5.1-r0. However, I can find nothing for Python 3.4 except a bug report and some hacky fixes. Also, it looks like running anything that require binaries that have compiled against glibc will be wonky as hell.

jwatte 11y ago
The whole point is: Do not run with glibc! If you need something that's not available, build it.
- monkmartinez 11y ago
  Then I am debugging builds, no?
- seanp2k2 11y ago
  We've been down this road many times before. It does not historically lead to happy places. Why will it be different this time?
- FreeFull 11y ago
  And if it's a proprietary piece of software and you don't have the source code? Or you do have the source, but the build process is too convoluted to figure out?
  - newjersey 11y ago
    1. If it is proprietary, we don't need it in docker. If they want to play in this ecosystem, they have to make their source free. 2. If the build process is too convoluted, we try our best to simplify it. Building something like Mozilla Firefox might take a few hours the first time but it will not always take that long. I for one would fully support this new pro-source software distribution mechanism. We could probably use git tags to find out when we have updates if we could get people to agree on some kind of convention... Processor vendors should love this change because every server will build all the software it needs from source. Edit: downvoters, care to leave a note?
    - tokenizerrr 11y ago
      > Edit: downvoters, care to leave a note? Sure. You don't get to dictate what I run in MY docker containers hosted on MY private registry used in MY environment. If I want to run proprietary software in my docker containers, I damn well will. And I expect Docker not to work against that, if just for the reason that it works fine today, why not tomorrow?
      - newjersey 11y ago
        You're more than welcome to build that from source too! Where you get the source code could still be a private, authenticated area. You could choose to never publish your docker files. That's fine. I'm just saying that we should move to a better model where if you distribute software, you should also distribute the source code (and hopefully build tools) for it. Why is this so difficult? It does not put any constraints on the user that vendors of proprietary software haven't artificially erected.
        11y ago
- deleted 11y ago
  [deleted]
vidarh 11y ago
> What is the fall back if a package is not available? Then use another distro if you're not prepared to invest the effort into it. The point of people wanting to move Docker images to distros like Alpine is to minimize size. That matters if you're going for massive density etc., but depending on your use cases, using e.g. Ubuntu or Debian or Centos as a base can be just fine. It's worthwhile to move the official images to it because they are used so widely. It's not necessarily worth it for every random image someone puts together.
- ageofwant 11y ago
  The official images are used so widely precisely because they are trivially extendable using apt. This will not be the case if they are based of something obscure.
awinter-py 11y ago
There are even more exciting libs like numpy/scipy which rely on a system BLAS package before they can even compile (and take forever). This is a problem that Ubuntu has made less difficult but a better solution would be package managers for C and fortran. If the 'alpine experiment' results in more work on portable build tools for complex projects, that's a win for the open source community.

JasonSage 11y ago

Alpine uses the musl libc and the OpenRC init system. In order for a deb or rpm package to install correctly, the binary would have to be built for musl already and the necessary information to set up services on the init system be provided. I don't know how the latter works for other package managers, be it in a way compatible with OpenRC or not. P.S. In my experience APK has been rock-solid and simple to use.

sandGorgon 11y ago
this is a huge blocker - we are already in a world where RPM and DEB dont get released in tandem. And it has taken millions of man hours to resolve deep problems in dependency resolution, circular dependencies,etc. For a startup like mine, I already estimate I'm installing hundreds of libraries (Ruby gems, Python wheels, etc). I'm pretty sure some of them are weird dependencies... but I have come to trust apt and dnf. There is zero reason for me to trust Alpine's new package manager that is managed by a single dev. Disk space is cheap - my time is not. This is the big blocker - if Alpine can figure out a way to co-exist with apt or dnf (pick your own poison), that makes it compelling. But then again, I would ask - can something like Alpine be achieved with debian or centos. Even if it is 3X the size (30mb) ? EDIT: I run a fat docker VM based on debian with nginx, rsyslog, postgresql and ruby+puma using supervisord. There is absolutely ZERO need for OpenRC. I have been running this in production for over 18 months since before Docker was this stable.
- anon987 11y ago
  Ehh I wouldn't worry about it too much. The whole idea behind these skinny distros is there are few if any packages. Distros can also consider using something like rpm-ostree[1] for making skinny, RPM-based immutable file systems where you only update the "master" image then push it out. [1] https://wiki.gnome.org/Projects/OSTree https://wiki.gnome.org/Projects/OSTree
- kylequest 11y ago
  The package ecosystem is the biggest challenge for Alpine. It's just not there and there's only so much you can do yourself. You need to have enough critical mass before the majority of the 3rd party providers begin to release packages for Alpine. There's a way to have small Docker images using the standard distros like Ubuntu where you get to use your favorite packages. DockerSlim [1] was created for this. It collects the artifacts your are actually using in the container throwing everything else away... Here are a few numbers to give you an idea (using on Ubuntu 14 base image): node: 431MB -> 14MB python: 433MB -> 15MB ruby: 406 MB -> 14MB java: 743MB -> 100MB It's a work in progress, so there might be corner cases where it's less than ideal. It's not tested well enough with "fat" images. Pull Requests are greatly appreciated :-) You also get auto-generated Seccomp (already usable) and AppArmor (WIP) profiles, so you don't have to create them manually. [1] http://dockersl.im http://dockersl.im

ape4 11y ago

The name conflict with Android make this the worse named piece of software. Any other name would be better.