Alpine Linux can be one of the most useful tools in your DevOps arsenal once you know how to use it.
Depending on the complexity of your use case, it will be a true test of your Docker skills and once you get it down you will have learned so much along the way… or you may just be able to use a default image and be fine with no hassle! Regardless here you’ll learn what the hype about Alpine Linux containers is all about and how you can go about creating them when you need to.
You’ve probably seen a lot of Docker image tags ending in
:alpine-edge, and are wondering
what the heck those mean. At its core, Alpine Linux is a much more minimal Linux distribution that does not
come with as many built-in features. This is intended though, because with less of what you don’t need
you can build the image to have only what you do need. This helps cuts down the size of your images
which ultimately decreases the time that it takes to start your containers. Additionally your container will be optimized to run
operations only useful for your application. This means no Bloat-ware that takes up your system
resources in these containers!
This is what makes Alpine Suckless.
For most of you that can use a standard docker image for your use case like
python:3-alpine, that is all
you really need to know about Alpine because all of the build work is already done for you. For the rest
of you who need to know how it works, strap in!
Let’s take a look at an example Alpine Dockerfile that builds all of the system libraries and dependencies that you need to run curl
--no-cache option for the apk package manager is important because it allows all of the source files
used to build the shared objects and executables to be deleted from the system after building. This means that you will
only be left with the executables after the command runs. This can be an issue for specific builds where
the libraries of certain packages are required to build or use other packages.
The solution to this problem is to use the
--virtual option when installing apk packages which
allows you to specify a virtual directory to temporarily store all of the libraries, source code, and executables inside of
and manually delete that directory after you’ve built the package that you need by running
apk del .dir-name at any point in the image build process that you would like. Or, if you need
those libraries and shared objects during production usage, you can simply run
apk add package-name
and it will keep everything like a normal package manager would.
Consider installing vim which requires gcc to build:
Here you download and build gcc and then build vim but are only left with the vim executable because you delete the directory where gcc was installed and now gcc is no longer installed
This is the crux of most peoples strife’s with Alpine Linux: build dependency issues. Since Alpine
is able to give you such small images, it sometimes has to compromise with compatibility with
specific packages, and when packages update and you’re building using
:alpine-latest, you’re in for
some big trouble if those packages don’t. Better hope you have your Docker build layers cached up to
that point in the Dockerfile!
The art of creating a good, minimal Alpine Linux container comes from being very intimate with your library versions and build requirements. The only thing that will help you with this is practice, so go try making an alpine version of your build!