Hacker News new | past | comments | ask | show | jobs | submit login
Setting Up a Software Development Environment on Alpine Linux (overops.com)
110 points by quickthrower2 35 days ago | hide | past | web | favorite | 55 comments



> Ubuntu is 188 MB

Ubuntu is 88MB:

  ubuntu  bionic  47b19964fb50  5 weeks ago  88.1MB
Definitely not Alpine levels of small, sure, but the size in the article is off by a digit. But not that big, either, and I find a huge number of devs are more familiar with Ubuntu.

I'm also throwing Python into the container, so the base container size is very quickly dwarfed by that. I think if you're using something like golang or Rust, the gains would be a lot more meaningful.


Not sure why the obsession with OS size. I don't mind having a 1GB OS that has really good functionality vs a 50MB one that has none. I do want size to be a factor for server based images which is a different beast altogether.


Bandwidth; we deploy frequently, and pushing images around is a fairly hefty part of that deploy, and the less the better. OS images don't update too often, thankfully, and Docker will only upload layers if needed, but it's still much easier to push 5MB than 80-200MB, so Alpine does have a distinct advantage there. 1GB is pushing it, a bit. (We also put much of our tooling on the host VM; generally, this can suffice IME.)

While my office has a great connection, my ISP at home is less so, particularly in the up direction. On mobile, pushing 80-200MB up is essentially not going to happen, both because it eats into my data caps quickly, and because mobile latency is such that that's really slow.


I agree and that's why I said server based images should be small but for user based OSes, for development work or browsing, size should be the last thing on the feature list. It's the development mindset that is pushing for small OS sizes and we should put that in the backburner in exchange for a good user experience.


In some cases, I think users may want that 50 MB OS so that they can add functionality as they need it. Sure, the 1 GB OS comes with some neat built in functionality, but how much of that is unnecessary for your use cases?


I think that comes in under GP's exception for server images.


I think containers have a lot to do with this in a big way. When you are making a container for every app, the OS base size really starts adding up. As a one time fee the disk space for an OS image is not a big deal, but when you have to pay that disk space for every app, then that really adds up.


If you structure your images well you don't pay the base image cost for every app, the layer is cached and stored once on disk.


They did some rearranging. Trusty was 188MB, Bionic is 88MB



The images get even smaller after Bionic!


That's great to hear. I quoted Bionic simply b/c it's the LTS, and a lot of places (mine included) only use those.

(It is honestly hard enough to get people to take the time to upgrade between those. We had finally gotten the last bits off precise I feel like when bionic came out.)


I have Alpine+gnome running on my little Dell Inspiron 5000 and I love it. It's super snappy where even Lubuntu was sluggish.

There are some missing luxuries like obconf and Emacs gui, but I mainly use it for browsing and sshing into Debian servers where I can just use vim anyway.

It was actually really straightforward to setup, too.


Neat guide, but I really don't understand why you'd even want Alpine as a daily driver, unless you're _really_ limited on performance.


Agree— the justification given in the article is needing the environment set up in order to port some software to it, but you don't need a development environment for that, only a build environment. Using containers or even just a chroot (https://wiki.alpinelinux.org/wiki/Installing_Alpine_Linux_in...) would be far more straight forward.

Now, if you want to try native Alpine as your desktop just for the fun of it, that's fine, but it's going to be a pretty constrained environment, and may not have been worth the several hours it took to get it going.


It's a simple, elegant system that does what I need. And needing so little resources really makes a difference even when you have a more powerful machine.


Like emulating x86 on iOS[1], for example?

[1]: https://github.com/tbodt/ish


Something about using the words “emulating x86 on iOS” and “daily driver” together doesn’t sit right with me...


It's quite ironic that the biggest usage of Alpine, a distro whose tagline is "Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.", is Docker, which is an almost completely opposite technology: vastly overcomplicated, insecure, and bloated. I'd be interested to hear what the Alpine maintainers think of their biggest user...


> I'd be interested to hear what the Alpine maintainers think of their biggest user...

The creator of Alpine Linux, Natanael Copa, reportedly went to work for Docker, so presumably Natanael thinks it's a reasonable use-case. Solomon Hykes, Docker's CTO at the time, posted about it on HN: https://news.ycombinator.com/item?id=11000827

Alpine Linux, as I understand it, strives to be a lightweight and minimalist distribution of Linux. That's exactly what you'd want to run as a container, assuming you are going to run a Linux distribution and one that's different than the production host system.


Aren’t minimalist operating systems often meant to run as guests under more complicated virtualization layers? Limited driver support, for example, can be an important part of the minimalism.


People believe that security is like salt. Just sprinkle it on top and it somehow makes the whole thing better.


It could be fair to call the docker ecosystem bloated and insecure, but I would argue that a single (Alpine based) docker container is a secure, simple, and elegant solution.


Docker is vastly over complicated? It’s one file jotting down a setup, and two commands, build and run and your up and going. How could it possibly be simpler? Bloated? It takes up almost no space and the docker image containers in large part thanks to alpine run less than 50MiB unless you are using huge dependencies at which point there is no way around it anyway. As for insecure, what’s the issue? We’re running untrusted code in containers and have had no issues but I’d love to hear where the model breaks down.


out of curiousity, where you say Docker is "insecure" what specific aspects of Docker were you thinking of?


The docker daemon runs as a privileged user, so if you're able to break out of the container (which has been shown possible recently) then you can compromise the entire host OS.


Could you provide a reference for how to break our?


https://www.twistlock.com/labs-blog/breaking-docker-via-runc...

This is from a CVE that was released a little over a month ago.


That was a runc vuln, which affected other conatinerization solutions on Linux, not just docker.

Also it didn't really have anything to do with the Docker daemon running as root, it was triggered by the use of root users in containers (blocked if the user didn't do that, had decent SELinux setups or used user namespaces)


Is there a distro comparable to Alpine but based on glibc? I'm aware of various workarounds / hacks for glibc support in Alpine, just curious if there is a distro that doesn't have the issue out of the box.


Void (Linux) has glibc and musl flavors.


Debian?

For upthread comparison, the debian:stable-slim container is 22MB.

That includes perl, tzdata, apt, bash, coreutils/util-linux and... basically nothing else. It's a very minimal rootfs that can still be easily extended. (The standalone perl docker image is over 300MB.)


Regarding the Java notes in the article, the announcement of Java 12 today had this:

"The Alpine Linux build previously available on this page was removed as of JDK 12 GA. It’s not production-ready because it hasn’t been tested thoroughly enough to be considered a GA build. Please use the early-access JDK 13 Alpine Linux build in its place."


This is thoroughly good stuff. Thanks to the author for the work they put into this.


I like to set up mini dev environments in Alpine Docker containers when I'm testing or trying out a new stack, and for the most part really like this pattern. That said, I run into a lot of issues that I think are musl related. The best part though is that when I finally get things working, everything is documented nice and declaratively between the Dockerfile and the docker-compose file, so I can come back to it later or clone it for a different project and it just works.


Pardon my ignorance, but what's the nature of these musl-related issues? Is it because some programs or libraries use glibc specific-features/bugs? Or is it something else? Does glibc have their own non-standard functions?


Pre built jvm binaries that are dynamically linked to glibc are an example.

"At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2"

https://www.musl-libc.org/faq.html

Some of the differences are listed here: https://wiki.musl-libc.org/functional-differences-from-glibc...


That reminded me that I noticed from the java 12 link on the front page, that they mention early access builds of java 13 for alpine. https://jdk.java.net/13/


Can anyone compare Alpine Linux with Void Linux, their pros and cons?


I don't claim to be an expert, but my understanding is that Alpine is mainly focused on small size, so musl libc, lack of systemd, etc, are means to that end.

Void seems to be more focused on power user experience, in the vein of Gentoo / Arch. So glibc or musl as an option, lack of systemd, and a pacman-like package manager (xbps) are all means to that end.

Alpine gets lots of usage as a Docker base layer due to that small size. Void certainly could be used as a Docker base image, but that's much less common than Alpine because the image sizes are probably roughly comparable to Debian and when running in a container the systemd vs not-systemd choice becomes less relevant.


Void: Rolling release, musl and glibc variants.

Alpine: Stable releases that are supported 2 years, musl-only. EDIT: Oops, forgot that "edge" is a rolling release.

I personally prefer Void for desktop and Alpine for servers/containers/appliances, but either could be used for either.


Alpine is magic. No fluff, no bloat, simple really, really well-designed setup- and package-tools. Including a full OS installation and setup, I can go from blank machine (or vps) to functioning, customized server in less than ten minutes if I absolutely have to. Good repos with everything I could ask for. Oh, and OpenRC, no systemd nonsense. I need really convincing reasons to ever build a server on anything else.


What does devops mean? I keep seeing that word.


If you're a low-level employee, it means someone who hooks up Jenkins to other crap. If you're a manager, it's a position you're hiring for. If you're upper management or executive, it's a methodology to solve business problems and improve output. If you're C-level, it's a cool buzz word.


This is a cynical and funny comment, but I see from your profile you have a wiki with a good definition that’s probably worth linking to (https://devops.yoga/overview.html).


C-suite porn.


They'd never get off, there's no pie charts


System and network administration as a software development target.


"DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market."

From AWS's What is Devops? https://aws.amazon.com/devops/what-is-devops/


About $150k a year.


Can anyone explain what the deal is with companies who have 1000 general blog posts, and then separately, a product they're selling? Is it just to bring in traffic that will hopefully buy their product?


Yes mostly, but it might also be considered a very roundabout evergreen recruiting advertisement, "Oh look they are using X and Y to build Z! I bet that would be a cool place to work if the opportunity arose."


More posts -> more backlinks -> higher domain authority -> higher search result ranking in search engines


More like try and attract potential employees by seeming cool and working on interesting problems


Slightly off-topic question: I use Windows as my OS of choice. If I want to run my browser in a Linux VM via Virtualbox, would Alpine be a good choice?

Or is there something even better/lighter?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: