Super small Docker image based on Alpine Linux
github.com
github.com
And there are FAR more important concerns:
- Are the packages in your base system well maintained and updated with security fixes?
- Does your base system have longevity? Will it still be maintained a few years from now?
- Does it handle all of the special corner cases that Docker causes?
That's why I use https://github.com/phusion/baseimage-docker
What would you suggest? Debian? Ubuntu LTS?
RHEL/CentOS 6 provides Ruby 1.8.7 and a 2.6.32 kernel. It can be made to run with docker, but it's unsupported and it won't be easy.
RHEL/CentOS 5 provides Ruby 1.8.5. The 2.6.18 kernel it comes with won't even run go binaries such as docker, much less lxc. Yes this is ancient. It was released in 2007 and it will be supported until 2017.
The value that stable, long term support distros provide shouldn't be underestimated.
You wouldn't believe how fast you can get a gentoo machine up and running compared to other distros. Build for a minimum common architechture (all intel binaries are based on Sandy Bridge, all ARM based on Rockchip RK3088), and installing for new computer is little more than untarring a bunch of binaries to /. My record is 5 minutes for a full KDE Plasma 5.5 software stack.
And then - a logger daemon. Guess mounting /dev/log into a container is too complex if you care about this?
Logrotate - sure, useful - but if you care about logs and aren't sending them to your logger daemon or /dev/null, you probably want to store them externally - in a volume or mounted host directory - and have a separate container taking care of that.
The ssh server... Containers are no vm's, if you have to log in on a container running in production - you're doing something wrong - unless that container's only job is running SSH (which can be useful for example for Jenkins build slaves).
Cron - again - same thing: run in a separate container and give access to the exact things your cronjob needs.
That is for me the essential thing about containers: separate everything. But sure, you could treat containers as a special VM only for one service - nobody is going to stop you. I however prefer isolating every single process and explicitly telling it how to communicate with other processes. It's sane from many perspectives: security, maintainability, flexibility and speed.
For stuff like you mention - you should maybe reconsider not using containers if you're on a pay-per-container platform? They are just a tool, and certainly don't fit every single use-case. Also - paying per container seems like a silly thing to do - since containers can be very short-lived. Resource-based billing would be a better fit - although that could be tricky to measure I guess.
But of course, if you can afford to use that in production it probably doesn't matter very much, and you might choose a different platform if it bugs you. Just came to mind because I just was wondering how to split stuff up.
> No well, written software won't spawn zombie-processes - sorry.
And yet it happens.
> The ssh server... Containers are no vm's, if you have to log in on a container running in production - you're doing something wrong
The SSH server is incredibly useful for diagnosing problems in production, so I for one applaud it (although it's not really necessary anymore with docker exec).
> Cron - again - same thing: run in a separate container and give access to the exact things your cronjob needs.
Or just run it in-container to keep your service clusters together.
> That is for me the essential thing about containers: separate everything.
It's a question of degree. Where you draw the line is almost always a personal, aesthetic choice.
I can understand that argument. It's an edge case, and building a sane Dockerfile on top of Alpine that runs applications through S6 (or runit), which developers use for their applications is the way to go for me. This is what phusion baked in?
>The SSH server is incredibly useful [...] (although it's not really necessary anymore with docker exec).
It's an additional attack vector and, by your own admission, it's useless. docker exec has been baked into docker for over a year.
>Or just run [cron] in-container to keep your service clusters together.
Per-container cron sounds painful. Then you have to deal with keeping every container's system time in sync with the host (yes, they can deviate). Not only that, if you have a periodic cron job that runs an app to update some database value, scaling becomes bottlenecked and race conditions (and data races) can get introduced. You are prevented from running multiple instances of one application to alleviate load because the container has the side-effect of running some scheduled job. Cron should be separate.
One can also choose the degree to which they want to throw out good practices that prevent them from repeating others' mistakes.
Strange, I have been running software in docker for almost 2 years in production on 6 docker hosts running a ton of containers these days, and yes - a lot of this software spawns child-processes.
In all this time I have never seen zombie processes with one major execption: Phusion Passenger to run our Redmine instance. If you run this under supervisord as 'init' process - you indeed notice the init process cleaning up "zombie processes" at startup like this:
2015-12-24 01:00:32,273 CRIT reaped unknown pid 600) 2015-12-24 01:00:34,774 CRIT reaped unknown pid 594) 2015-12-24 01:00:35,802 CRIT reaped unknown pid 610)
So that case for me is the exception, and I do use an init process (supervisord) to run only apache with passenger. Note that using Apache with PHP or plain does not leak zombie processes.
The real problem with splitting things into a bunch of containers is that the story around container orchestration is still poor. Kubernetes is the leader here, but running a production-ready cluster takes some work (besides Google Container Engine, there are some nice turn-key solutions for spinning up a cluster on AWS but they come with short-lived certificates and rigid CloudFormation scripts which create separate VPCs; so you have to setup your own PKI and tweak CloudFormation scripts).
Other than that, there's no problem running postgres itself in a container - as long as your data is stored in a volume ending up being bind-mounted on the local disk, and not on the layered filesystem - otherwise performance will suffer badly.
And yes - orchestration - especially on small-scale - is still a sore point. All the tools like kubernetes seem to focus on large scale and scaling multiple instances of the same containers - which is not what I and many people need. Something like docker-composer, but in daemon form would be nice.
Agreed about not shoehorning things into containers. Redis, for instance, should be ran with custom kernel parameters (transparent huge pages disabled), so doesn't fit well in the container paradigm since containers share the same kernel.
A container is whatever you want it to be. Single process? Sure. Full OS? Sure. Somewhere in between? Sure.
Containers are not new technology, and they were not invented by Docker or Linux. An artificially-constrained view of what a container is (or should be) that's driven by one tool's marketing (Docker) isn't helpful.
It simply makes no sense to add additional unnecessary overhead and complexity to something that is essentially very lightweight. If you want a full-blown OS - a VM is much better suited at that, and modern hypervisors come with a ton of bells and whistles to help you manage full-os environments.
Not everyone is of the caliber that tends to browse HN. Not everyone adapts to new technology as quickly as people around here tend to, especially if that new technology requires a huge upheaval in the way that things have been done for the last 10 or 15 years. Using containers the same way we do VMs provides a lot of the benefits of containers without requiring a drastic change from other departments.
I agree on the advantages on LXC though. Many hosting companies use it. Why fix it if it ain't broken?
> Modern KVM has a comparable density to containers (except for memory)
It does, but the memory can make a big difference if you're running microservices. If I'm guesstimating I'm thinking there's probably about a 200MB difference in memory usage between a good container image and a VM. With microservices that can grow quite a bit. Let's say 4 microservices, needing at least 2 of each for redundancy, you're already looking at a difference of 1.6GB of memory. If you need to massively scale those that's .8GB of memory for every host you add, not including any efficiency gains from applications running on containers rather than VMs (which is going to be largely negligible unless we're talking a massive scale).
Yes, and it increases the attack surface even more in some scenarios. Now, an unprivileged user can create new namespaces and do all sorts of things which were previously limited to root.
With "clear containers" (very minimal KVM VMs), you get the overhead down to <20MB:
https://lwn.net/Articles/644675/
Also, RAM is cheap.
Here's Stephane Graber's blog on it: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-con...
Also, note that with LXD/LXC the "default" container is now unprivileged. Also with LXD/LXC the LXC command syntax is now simplified even more than it was with traditional LXC but with the added power of being able to orchestrate and manage LXC containers either remotely or locally.
LXC also supports Nested LXC.
The scheduled release of LXC 2.0 and LXD 1.0 sometime around mid to late January.
This will also include support for live migration/CRIU.
https://insights.ubuntu.com/2015/06/11/how-many-containers-c...
I've had upto 512 LXC nested containers running quagga for bgp & osp to simulate "the internet". My machine is an i7 laptop and this used less than 8-10 gigs of ram to run.
fyi the github of "The Internet" setup was from the 2014 NSEC conference where they used it so the participants had a large internet routing simulation available to test security.
The github for "The Internet" simulation is here:
https://github.com/nsec/the-internet
"The Internet" creates 1 single LXC parent/master container and then 500+ Nested LXC containers each running quagga & setup for the simulation used.
http://www.stackengine.com/container-memory-usage-or-size-ma...
A smaller distro might even statically compile most things - Alpine does. If you dynamically link shared libraries, the whole library is loaded into memory to serve the process. If you statically link, only the actually used part of the library is included in the binary.
Statically linked binaries can't share the library in memory between each other like dynamically linked binaries can, but if all your processes are running in separate containers, they won't share those libraries anyway (unless they're all in a VM and the rarely used "samepage merging" is enabled for the VM).
Finally ... simplicity has knock-on effects. Making things simpler and smaller (not easier), and reducing the number of moving parts in the implementation, makes cleaning up more stuff easier.
Here's a quick demo based on the trivial example of the memcached docker images I mentioned in another thread:
vagrant@dockerdev:/host/scratch/janus-gateway$ sudo docker run --name=mc_big --detach --publish=11212:11211 --user=nobody sylvainlasnier/memcached /usr/bin/memcached -v -m 64 -c 1024
67c0e406245d341450c5da9ef03cbf60a8752433a4ace7471e2a478db9a62e07
vagrant@dockerdev:/host/scratch/janus-gateway$ sudo docker run --name=mc_small --detach --publish=11213:11211 --user=nobody ploxiln/memcached /bin/memcached -v -m 64 -c 1024
11037b69acfbc0de7601831634751cd342a7bafe9a25749285bc2c2803cc1768
vagrant@dockerdev:/host/scratch/janus-gateway$ top c -b -n1 | grep 'COMMAND\|memcached'
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5984 nobody 20 0 316960 1192 768 S 0.0 0.1 0:00.02 /usr/bin/memcached -v -m 64 -c 1024
6091 nobody 20 0 305256 780 412 S 0.0 0.0 0:00.00 /bin/memcached -v -m 64 -c 1024
Within the context of "an important concern" though; the difference in RES and SHR between the two is about ~330kb. I suspect most people wouldn't find that significant particularly given memcached's common use cases.
One really easy and relevant example, sizes of docker images for running memcached:
vagrant@dockerdev:~$ sudo docker images | grep memcached
memcached latest 0868b36194d3 2 weeks ago 132.2 MB
sylvainlasnier/memcached latest 97a88c3744ef 13 months ago 297.4 MB
ploxiln/memcached 2015-07-08 aa4a87ee2c05 5 months ago 7.453 MB
As another example, a co-worker recently was working with some (out-of-tree) gstreamer plugins, and the most convenient way to do so was with a docker image in which all the major gstreamer dependencies, the latest version of gstreamer, and the out-of-tree plugins were built from source. The offered image was over 10GB and 30 layers, took quite a while to download, and a surprising number of seconds to run. With just a few tweaks it was reduced to 1.1GB and a handful of layers which runs in less than a second. It was just a total lack of care for efficiency that made it 10x less efficient in every way, enough to actually reduce developer productivity.
Size matters.
Developers, especially good developers (or hell, even just competent) are more than worth the effort put into improving their productivity, and the good ones will usually intuitively have a grasp of the XKCD time trade-off graph and reduce or eliminate delays themselves given the chance.
That being said, even in this day and age of extremely cheap cycles, non-volatile and volatile storage, and insane throughput, making something like VM/chroot images smaller can lead to higher productivity in that you can spin them up faster, or spin up tons more in paralell than you would normally think of. Having the option to do such can help shape alternate modes of development and open up possibilities previously undreamt of ("spin up 1000 docker images? Can't do that because they each need 200MB RAM and I only have 32GB of RAM").
It's normal for common tools to be SUID root - it's necessary for operation on a normal machine. Do you really need 30+ SUID binaries inside your Docker container built for one thing?
Docker seems to present an ideal situation for stripping such potential exploit vectors back.
Perhaps loud suggestions like these are necessary due to a bias in the group that uses Docker. 20% people that really know what they're doing and have chosen Docker for a specific reason, and the hangers-on who try to emulate them by using the same tools.
Docker is an interesting, useful, and extremely overhyped tool. I may be wrong, but I feel like its popularity has caused a bunch of people who don't really need Docker to use it. Besides popularity, they can't really explain why they are using it over something like LXC or FreeBSD jails.
I imagine (again, no data to back this up) that this same large percentage of people are also the ones that just keep using the default Ubuntu image once they finish the "Get Started" tutorial.
I'm glad to see suggestions like this gaining popularity. If you're going to make the most of Docker, I think there's value to be found in really committing to the mindset of a 'purpose-built, no-frills environment for running a single process.'
From what I can tell right now, a huge number of people are using Docker "sort of like a VM but you need more of them, and Git is integrated and you have to tell it to do something or it stops running".
- Python-slim uses debian:jessie
- Ruby-slim uses debian:jessie
- Node-slim uses debian:jessie
Your web application is probably going to pull in from one of those run-times which automatically sets you up to use jessie.
I'd also like to see someone take a random large project and see if their native extensions compile under Alpine without any other dependencies and to compare the final image size of a real world web app with alpine vs jessie.
It's sort of a micro benchmark to compare it like this because a project with 75 gems/packages and a couple of native extensions that need to be compiled will drastically increase the size of your image, with or without Alpine.
I absolutely do think it's worth optimizing your images, but this seems like something that may end up being quite personal to your app because it will require a bit of tinkering to get everything your app needs to work. I also wouldn't bother doing it until I was constantly pulling them down in production to auto-scale.
*edit: which is what you were saying all along, and this didn't sound enough like "yes I agree"
As for the edit, sorry about that. I edited my comment about a minute after posting it.
The real problem with musl in these environments is its DNS behavior, particularly if you're running on a platform like Kubernetes that uses DNS search domains for service discovery. Not hard to work around, but the workarounds are a bit, er, inelegant. See http://www.openwall.com/lists/musl/2015/09/04/4 and https://github.com/gliderlabs/docker-alpine/issues/8
Is the common procedure in the Docker world to build an application image that includes all the build tools that were used to build native dependencies? That seems like it does generate a pretty large image.
I figured I'd take a three-step approach to my first node.js app in Docker:
1. Build an image to build my dependencies. This uses the same base image as step #2 will, but installs all the development tools and libraries (eg. build-essentials, libpq5-dev), and then outputs a .tar.gz to a shared volume containing my node_modules folder.
2. Build an image with my dependencies; imports the runtime versions of any libraries (eg. libpq5), imports & expands the .tar.gz generated by #1.
3. Build an image with my application, FROM the image in #2.
The process is optimized by having the automation check for the existence of #2 by hashing the contents of the relevant Dockerfiles, and the package.json list of dependencies, and doing a `docker pull` with that hash to see if I've already built #2. If so, my build just needs to build #3.
It's a bit more complex (Hello, everything in Docker-land), but ends up being pretty powerful. But your post makes me think I've over-complexified it a bit.
Initially we did a lot of cloning from source and compiling/installing dependencies, but it's very slow, there's a lot of wasted time in rebuilding identical code, and it's hard to provide patches and upgrades to customers.
I guess I just don't see the time vs. effort value in optimizing most smaller projects.
For example, that 75 gem project may take 5 minutes to build once but after that it takes 10 seconds to build and push a version that updates the app code.
I'm ok with this pattern for most of my projects because you can easily get by with 1 host to serve tens of thousands of requests a month on most typical projects. It's not like I'm spinning up and destroying dozens of instances a day where the network overhead is a legit concern (if I were, then I would optimize).
Please stop using Ubuntu as your base images people!
There's no excuse for using a full Linux distribution (especially one that's really aimed at the desktop) for a container unless you're doing a staged migration or something along those lines.
* Edit: Formatting.
This, great hardware support, and decent stability are the main reason I use Debian-based distros. Almost anything is a deb away.
I think Ubuntu images are a symptom of a much more serious disease: Ubuntu usage in general. Ubuntu is not really concerned with software freedom (its origin was Debian-plus-proprietary-blobs), nor does it strongly care about privacy (although it can be shamed into doing the right thing), nor does it care terribly much about getting along with everyone else (c.f. Mir vs. Wayland).
As a distro for my family, it's fine. But I expect my fellow developers to run something which indicates more technological prowess than does Ubuntu: Debian or Arch or Gentoo or Slackware are all good choices for different reasons.
With One-Service-Per-Docker I think about migrating back to Debian, as I can chose the version of my service myself (with curl if needed) and don't need the newest versions in my base image.
I have the feeling with Docker over time Debian might have a comeback.
I did more than Debian, Redhat, Mandriva, Gentoo and other could do even though they had a longer head start.
Once I run that on my desktop, I don't really want to learn another distro, I'll just use that the server as well.
> run something which indicates more technological prowess than does Ubuntu:
There one difference between how I develop -- I don't develop to show my technological prowess, in fact when I do that, I start making mistakes and generate complicated and hard to maintain systems.
They did, and they should be congratulated for that. I like to believe that Debian learnt a hard lesson from its long delay.
> Once I run that on my desktop, I don't really want to learn another distro, I'll just use that the server as well.
Ubuntu on the server has essentially been Debian unstable-ish. It's not really a case of learning another distro.
Your argument would also apply to running OS X Server, and I don't think anyone outside of Cupertino thinks that's a good idea…
> There one difference between how I develop -- I don't develop to show my technological prowess
If you like, substitute 'competence' for 'prowess.' Running Ubuntu is like running Windows: it's popular; it's not really wrong; it even has advantages; but running Windows doesn't indicate any level of competence. In Bayesian terms, P(competence | Ubuntu) < P(competence | ~Ubuntu).
And it does! Old work had a few in house servers with OS X. If it was free, we'd see a lot more of it, I am convinced.
> If you like, substitute 'competence' for 'prowess.' Running Ubuntu is like running Windows: it's popular;
Isn't the ability to quickly ship a stable, reliable product that customers are happy to pay for, a better sign of competence than say picking Slack or FreeBSD for server for now good reason except to show competence?
The question is who is the show of competence for? Other developers, customers, management? I can see developers boasting who knows how to configure and run obscure distros and use exotic functional languages and that's cool. I was just saying after a while you realize that show of prowess is not what is important.
Sure! What I'm saying is that if someone is unable or unwilling to run something other than Ubuntu then I suspect he is less likely to be able to build that stable, reliable product in the first place.
It's like how I suspect I'm likely to have a better meal if the cook prepares it from fresh ingredients than if everything comes pre-made off of a truck.
Hey, what does 'Ubuntu' mean anyway?
It's a South African word meaning, "doesn't know how to install Debian"* 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 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/
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
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
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.
Alpine does well at making security measures like SELinux accessible. Meta-distributions like Debian serve a different purpose.
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.
GP also goes into some detail about the amount of discussion and updates to Alpine Linux, which are excellent metrics for code quality.
Code quality has nothing to do with how much jibber-jabber there is on some mailing list, nor with how widely used a piece of code is. It has to do with the actual code.
In the case of Alpine Linux (which I've never used), probably 50% of the code is the linux kernel itself, another 20% is musl and busybox, and the rest is random gnu utilities. Which of those things is 'low quality' and has 'undiscovered bugs and security vulnerabilities' that broken, random, low-quality high-politics tire fires like most linux distributions don't have?
But conversely, is it not intrinsically obvious that not having the grotesque pile of random freshman desktop apps and terrible init systems that other distros have, could reduce the attack surface to a point where a single organization could conceivably make sense of it?
Furthermore, the problem I have with Alpine-based containers is that using those as the basis of tooling used for building your own product, your own product will have a hard time becoming maintainable, sustainable an secure.
I've had developers doing make; make install in Dockerfiles just because Alpine doesn't have some library or version packaged.
Containerization brings all manner of sweetness to the table, but the current way it is used is a throwback to 1998.
Not having desktop software inside a small container does reduce the attack surface. Debian, Ubuntu, Centos can handle that requirement just fine. What is your point?
While you're at it, please show me the Debian, Ubuntu, or CentOS distribution that doesn't have desktop bus installed. I'll wait.
> why are you trying to create FUD about how Alpine Linux is unmaintainable, unsustainable, and insecure?
I never tried to make that claim.
What I am trying to say is that if YOU built YOUR software against Alpine, IT will be hard to maintain/sustain/insecure. Because your software will probably have dependencies. Dependencies not found in Alpine. And now you have to maintain and test those dependencies. You'll have to keep informed on all the security advisories of those dependencies. All the changelogs. And by then, you've started to reinvent wheels that the fine folks of Debian, Ubuntu, Centos have invented already.
That is a resource drain on companies that is inefficient and cumbersome with little to no added value.
> While you're at it, please show me the Debian, Ubuntu, or CentOS distribution that doesn't have desktop bus installed.
A container is not the same beast as a distribution. It does not have the same requirements. It is just a tarball. And you can throw anything into it, or out of it.
I'm just saying to use debootstrap to throw stuff in that tarball so you have the benefits of an enterprise-level, proven distribution, instead of using this something that has not yet proven itself. So if you ever need to take your software OUT of the container and run it on an AWS instance, or on your own hardware, you'll have no problem with it.
In short: I see no added value for Alpine. It does not address my operational concerns, and raises a bucketload of new ones when I compare it to Debian, Ubuntu or Centos.
I'd have thought the same would be true for apps written in Go.
Or better yet, keep 6 distinct containers like you should, and use docker-compose to spin them up together. Makes upgrades easier because you can simply point to a newer version of whatever service containers you're using without having to take out everything.
If you're using containers as a VM, you're essentially adding overhead for no good reason.
[1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb... [2]: https://phusion.github.io/baseimage-docker/
One interesting thing about Alpine is that it uses MUSL[2] for its libc. If you want the bare minimum image size, you can use a scratch or busybox image and statically compile your binaries[3].
[1] https://docs.docker.com/compose/
[3] http://blog.xebia.com/create-the-smallest-possible-docker-co...
The only problem is that the package library is not as extensive as Ubuntu or Arch. https://pkgs.alpinelinux.org/packages
Alpine has a tiny footprint, which is great for wrapping Node.js which itself is tiny; But wait, there's more, Alpine has a great package-manager similar to apt, called apk -- this is what sold me on it over BusyBox.
I've been struggling to find a lightweight PHP image, they're all huge. I'm starting to see a big advantage for Go in the container world where I've seen containers 10MB in size instead of the 200-600MB I'm getting in Python, PHP or Ruby. The nature of these dynamic languages and their libraries I guess.
at the very least, it's probably not worth spending too much time on, because you'd get better optimisations from doing other things
[1]: https://developer.atlassian.com/blog/2015/08/minimal-java-do...
Love Alpine though I did run into an annoying nginx permission issue: http://lists.alpinelinux.org/alpine-user/0002.html
Although with 3.3 that isn't necessary anymore if you use the --no-cache flag.
the thing is, what do you gain out of using Ubuntu over alpine? chances are that its very little. the gains of using alpine are a more efficient, faster deployment system
*edit: also, downloads don't just happen in a data centre. chances are your (or many) office connections just really... well, are not very good. also, think of Australia. please think of Australia (our internet is something of a dire situation)
When I deploy, I generate the slug using slugbuilder, push it to a local storage on the same network, and each docker task is instructed to pull the "latest" slug from the slug storage. Containers start after a code update in a couple of seconds.
Continuous deployment can be easy achieved by copying slug from staging to production, similar to how pull docker image each time is currently done.
[0] https://github.com/flynn/flynn/tree/master/slugrunner [1] https://github.com/flynn/flynn/tree/master/slugbuilder
It's not about only size (though getting something that's 10x-20x smaller is helpful)
It's about getting only what you need, reducing security issues, disk usage, memory usage, etc
It does look like a fix is on the way though.
This right here. There's so many here decrying Alpine who can't see the bigger picture: having options for different Docker deployments will create possibilities currently undreamt of. Maybe you can't use it on your project; fine, keep on keepin' on with what suits you best, but don't knock another project just for a different approach, especially when it might have huge benefits to the overall environment in the future.
Since I've never even heard of Alpine before today, I'd say you are at the very least giving up on a community of users and support, but maybe Alpine will gain a large community and this is the start?
> ...
> (5/5) Installing nodejs (0.10.33-r0)
They should really update their examples, as that makes it look worse than it actually is (the current repository contains 4.2.3).
And while I'm at it: "use % as a wildcard" on the package page? Really?
If heading this route, perhaps Guix or Nix are a nice option too. As you can get something declarative and with traceable builds.
I'm hoping a minimal distro that has a nix-like package manager gets mainstream soon.
[0]: https://news.ycombinator.com/item?id=10783021 [1]: https://news.ycombinator.com/item?id=10782946
Not if you're spinning up new hosts via autoscaling.
This runs against the notion of minimalism in the context of a harness for containers in my view.