4 ms·

Why not? Let's run the numbers. * http://wiki.alpinelinux.org/wiki/Special:ActiveUsers http://wiki.alpinelinux.org/wiki/Special:ActiveUsers 14 active users. T

by _euvw 11y ago

Why not? Let's run the numbers. * http://wiki.alpinelinux.org/wiki/Special:ActiveUsers http://wiki.alpinelinux.org/wiki/Special:ActiveUsers 14 active users. That is not a lot. In fact, that is tiny. Maybe their redmine has more? http://bugs.alpinelinux.org/projects/alpine http://bugs.alpinelinux.org/projects/alpine says 16 users in the 'developers' group. But maybe they're very pro-active on the mailinglist? Let's check their security announce list: * http://lists.alpinelinux.org/alpine-security/ http://lists.alpinelinux.org/alpine-security/ 1 message. From 2009. Hmm. Well, their alpine-devel list then? 5110 messages in 10 years. 9 Messages per week. By comparison: the debian developers mailinglist had 492 messages in November 2015 alone. So even though Alpine Linux looks nice and lean, it is maintained by a very small group of developers. Now. If building your own container were very very hard, I'd sure understand grasping for something like Alpine. But here's how you build an Ubuntu Trusty container: debootstrap --variant="minbase" --include="systemd-sysv" trusty ${TMPDIR} ${UBUNTU_MIRROR} chroot ${TMPDIR} dpkg-divert --local --rename --add /sbin/initctl ln -sf /bin/true /sbin/initctl dpkg-divert --local --rename /usr/bin/ischroot ln -sf /bin/true /usr/bin/ischroot Just tarball it and throw it in 'docker import'. Your done. Need to add or remove software? Use Ansible to configure specific containers with specific confgurations. Need security-updates? chroot into the folder, apt-get update; apt-get upgrade. Throw the new tarball into docker import again. You use long-term supported methods and systems. There are tens of thousands of packages. Bazillions of PPAs to use. Edit: typo in codesnippet

woah 11y ago
You're probably right, but have you ever thought that maybe Debian has so much mailing list activity because it is such a huge project? There's something to be said for lightweight software. Of course, workaday devs should use the accepted best practices, but can't people experiment with better techniques until they have been proven out?
- mverwijs 11y ago
  A huge community and installable packages does not mean you need to use all those packages. The smallest container I've built is about 90MB, using Ubuntu. That is pretty lightweight. Of course, the container doesn't actually do anything.... Another thing to consider: if you software works inside you self-built Ubuntu container you can be pretty sure it works on any Ubuntu install anywhere. Even if your company does not use containers everywhere, your developers can. Edit: typo and sentence finishing.
nalck 11y ago
OpenBSD is likewise developed by a small number of users. A Linux distribution is arguably easier to maintain for a smaller group because the core components are developed upstream. Alpine does well at making security measures like SELinux accessible. Meta-distributions like Debian serve a different purpose.
- mverwijs 11y ago
  Alpine Linux supporting selinux is only relevant in this discussion if you run Alpine as the container host. To the Alpine containers it is of no consequence. OpenBSD has more than a great track record on security, maintainability, community spirit. As has Debian. Alpine, after ten years, was simply not on the radar as a distro. It is merely developers that do not seem to care about the actual systems these containers are built from that find Alpine interesting. It's small, so even on a 3g connection you can download those containers and get the functionality a developer seeks. Fast. And that is fine. It gets alpha code out in a timely manner without too many resources. Just do not pretend that this way of working will deliver sustainable, maintainable and consistent code that will work just as well inside as well as outside containers. Maintained, secure, stable and proven distributions have served any purpose given in the past. From embedded systems to HPCs, from trading floors to satellites. Saying any of the "old school" distro's are a bad fit for running in a container is a display of ignorance at best.
  - felixgallo 11y ago
    quantity-of-people-involved is a terrible, irrelevant metric for code quality.
    - smt88 11y ago
      Maybe, but it's a fantastic metric when guessing how many undiscovered bugs and security vulnerabilities there are. GP also goes into some detail about the amount of discussion and updates to Alpine Linux, which are excellent metrics for code quality.
      - 11y ago
mvc 11y ago
We took alpine, added the oracle jre, and use it as a base image for our clojure apps. Seems to be a reasonable choice for that use-case since you just need something that will start your jar. I'd have thought the same would be true for apps written in Go.
- _6d9t 11y ago
  You can actually take things way further in Go: https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/ https://blog.codeship.com/building-minimal-docker-containers...

by _euvw 11y ago

woah 11y ago

You're probably right, but have you ever thought that maybe Debian has so much mailing list activity because it is such a huge project? There's something to be said for lightweight software. Of course, workaday devs should use the accepted best practices, but can't people experiment with better techniques until they have been proven out?

mverwijs 11y ago
A huge community and installable packages does not mean you need to use all those packages. The smallest container I've built is about 90MB, using Ubuntu. That is pretty lightweight. Of course, the container doesn't actually do anything.... Another thing to consider: if you software works inside you self-built Ubuntu container you can be pretty sure it works on any Ubuntu install anywhere. Even if your company does not use containers everywhere, your developers can. Edit: typo and sentence finishing.

nalck 11y ago

OpenBSD is likewise developed by a small number of users. A Linux distribution is arguably easier to maintain for a smaller group because the core components are developed upstream. Alpine does well at making security measures like SELinux accessible. Meta-distributions like Debian serve a different purpose.

mverwijs 11y ago
Alpine Linux supporting selinux is only relevant in this discussion if you run Alpine as the container host. To the Alpine containers it is of no consequence. OpenBSD has more than a great track record on security, maintainability, community spirit. As has Debian. Alpine, after ten years, was simply not on the radar as a distro. It is merely developers that do not seem to care about the actual systems these containers are built from that find Alpine interesting. It's small, so even on a 3g connection you can download those containers and get the functionality a developer seeks. Fast. And that is fine. It gets alpha code out in a timely manner without too many resources. Just do not pretend that this way of working will deliver sustainable, maintainable and consistent code that will work just as well inside as well as outside containers. Maintained, secure, stable and proven distributions have served any purpose given in the past. From embedded systems to HPCs, from trading floors to satellites. Saying any of the "old school" distro's are a bad fit for running in a container is a display of ignorance at best.
- felixgallo 11y ago
  quantity-of-people-involved is a terrible, irrelevant metric for code quality.
  - smt88 11y ago
    Maybe, but it's a fantastic metric when guessing how many undiscovered bugs and security vulnerabilities there are. GP also goes into some detail about the amount of discussion and updates to Alpine Linux, which are excellent metrics for code quality.
    - 11y ago

mvc 11y ago

We took alpine, added the oracle jre, and use it as a base image for our clojure apps. Seems to be a reasonable choice for that use-case since you just need something that will start your jar. I'd have thought the same would be true for apps written in Go.

_6d9t 11y ago
You can actually take things way further in Go: https://blog.codeship.com/building-minimal-docker-containers-for-go-applications/ https://blog.codeship.com/building-minimal-docker-containers...