Have you ever heard OS called Alpine Linux?

It is very light weight, and not Debian or RedHat distribution.

The official website is here.
https://www.alpinelinux.org/

Because of this characteristic, it can be adapted docker container base image.

You can check out the container from Docker Hub, here.
https://hub.docker.com/_/alpine

I have adapted it in some projects at work and personal project.
We found too many disadvantages, I would like propose to reconsider adapting Alpine for actual product.

As far as I am concerned, the cases where you can take advantage of Alpine are very limited, and many projects will find more disadvantages rather than the benefits.

Here is the list of reasons why you should avoid alpine linux.

It uses unpopular package manager "apk"

It is common to use "yum" or "apt" as Linux package manager, or "Composer" or "pecl" as PHP package manager.

We often finish it after many struggles like reconfiguring package reference to install preferred version of libraries for the project, and adding other package managers such as "remi", "EPEL" and "pickle" over and over again.

It is important that "the problem can be solve easily" because you have to manage many package managers and set different configurations.

In particular, how easy we can find the solution is the key for development.

apk is not popular at all compared with yum and apt as package manager, it means there are few information on the internet.
So, it makes complicated to solve the problem.

There are some cases that you face difficult problems with yum, apk spur difficulty on to solve errors.

It doesn't matter for the quality of product how difficult to build development environment, it is the best way to simplify.

In addition, file extension of Android app is "apk" as well, so you will get more search result about Android app.
Then you will be struggling with filtering these result.

Some library versions are not updated

If you install some libraries using apk, there is high possibility that you can't install latest version(they may not be supported by apk).

In this case, you may need to get and compile source code.

This task will absorb your motivation.

This is totally waste of your time to have a headache for issue that is easily solved by other package manager.

It uses unpopular shell "ash"

Alpine adapts unpopular shell "ash", it makes difficult to create development environment.

By the way, I use default OS shell without any customization.(Well, I set some alias.)

I want to avoid to make it even more difficult to create development environment by adding some customization to the shell.

There was a period a shell called "fish" got attention, however, I completely ignore that trend and kept using default shell.
Because, I believe that "The number of disadvantages by customizing the shell > The number of advantages by customizing the shell" in most cases.

I do understand the advantages by customizing the shell, but sometimes it might make confusing issue when you create development environment.

It is okay if you use customized shell that you perfectly understand all parameters and behaviors. However, if you use the shell that other developer customized, you might face some extra unexpected issues.

Using unpopular shell means you will face similar issues.

In addition, "ash" has low google-ability such as "apk". So, when you face unexpected issues, you will be struggling.

It uses unpopular distribution.

First of all, if you use unpopular distribution, you often face unexpected tough issues.

This article is about some unpopular distributions which I gave a try.

Linux - The report of unpopular distributions

I finally decided to go with Ubuntu.

It is better to use popular distribution.

Creating Dockerfile tend to depend on each engineer's skill

It can be difficult to create Dockerfile because of reasons above.

It uses unpopular package manager and unpopular shell, and sometimes it is required stressful knowledge that you think it is a waste.
Technical debt increase when we use Alpine rather than Debian or RedHat.

The performance is low compared with other distributions.(it can be happened)

I found this interesting article.

軽量Dockerイメージに安易にAlpineを使うのはやめたほうがいいという話(You shouldn't use Alpine for lightweight Docker image without particular reason)

libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。
(libc is lacking general compatibility. When application uses native module bundle such as Ruby, Python, and Node.js, you might face the problem of performance or compatibility.)

I have made a React development environment in Alpine Docker image, however, the command "npm run watch" and "watch-poll" are too heavy and slow, which makes inconvenient to develop.
(But, the problem might be caused by the way I build. Fortunately it was only my personal project, so I left it like that.)

I used the development environment which had node-slims(node:16-slims) base image, the performance was OK.

To calculate these performance precisely, I have to prepare two exactly same environment with Alpine and node-slims.
But I'm not going to do it. I wait for the engineers who recommend Alpine prove Alpine has high performance.

There will be chaotic incident research after production.

When you use AWS service such as Fargate or ECS, you can deploy the containers without installing some applications and libraries in EC2.

But, it is common to face some problems that occurs in production or staging environment, but not local one.
In this case you will want to login the container directly to find out.
(Sometimes, you find some article state "When you use container, there are no difference between local and production environment, so, you don't worry about difference of these". Truth be told, while local environment doesn't use AWS resources, production environment use it such as RDS, ElastiCache, SQS and SES. if any kind of error has been produced in the connection or configuration, your application will not work properly.)

But, when you use Fargate, you will not be able to login like EC2 SSH.
(Internally, Fargate is managed by AWS dominant EC2. So, it is highly restricted for user access.)

If you use the AWS service "ECS Exec", you can login the uploaded container in Fargate, but it is required to install the application called SSM Agent.

But, Alpine has not and will not support SSM Agent. So, you have to do in an unofficial way.

I found this article.
Alpine Linux に amazon-ssm-agent をインストールする(How to install amazon-ssm-agent in Alpine Linux)

amazon-ssm-agent は Alpine Linux をサポートする予定はないとのこと。
(Alpine has not and will not support amazon-ssm-agent.)

It is possible installed, but the author do in an unofficial way.

I couldn't install it this way.

It often happens to get different result from the author's one since we have different environment, so, we have to solve these issue depending on the error messages.
But, it is complicated to fix some unexpected problems, because it is not easy to find right information.

When the application is launched in AWS, it is very important to have access to container, there is no other way to implement output log and deploy each time.

If it takes more than 20 minutes to deploy an application, we are risking engineer's motivation.

If you use AWS Fargate, you have to avoid Alpine, because container login function is not supported officially.

It is recommended Debian image in Dockerfile best practice in official Docker documentation.

Here is the reference from official documentation.
http://docs.docker.jp/engine/userguide/eng-image/dockerfile_best-practices.html

In terms of base image, use the official repository for the best possible result.

We recommend Debian image. It is well maintained and compact despite full-featured distribution.(Only under 150MB)

I suggest to follow best practice unless there are specific reasons to use Alpine, because official documentation said.

Deployment time is not reduced as much as you expected.

Truth be told, deployment time is not reduced even if you use Alpine.

It is common to think it will take less to deploy because it is light weight.
But, there are many processes to complete deployment. There is only 1 step of container upload time which get benefit from weight saving.

Also, when you upload some containers to AWS, they don't upload each one of them, but upload like broadcast delivery. It seems like process in parallel, so it will not produce difference of processing time.

To be specific, it doesn't mean "Deploying 100 containers takes 100 times longer than deploying 1". However both take almost same time.

Therefore, the benefit from weight saving of container is only the amount when you compare each container.
(I asked AWS specialist.)

I would rather find some disadvantages which sacrifices performance instead of weight saving.

Start-up time of the container might be faster, however ,most of engineers would choose
"the container which takes 5 minutes to start up, but 1 second for 'npm run watch' command"
over
"the one which takes 1 minute to start up, but 1 minute for 'npm run watch' command"

based on these disadvantages

I ended up writing a lot of disadvantages of Alpine unexpectedly.

But, these problems can be avoided easily by not using Alpine.

When you should use Alpine?

In my opinion, development and maintenance cost will increase just by adapting Alpine.
It is too stressful and exhausting job if there isn't infrastructure team with specialists of containers and deployment.

Sometimes it is required stressful knowledge that you think it is a waste, so, it is a quite tough work for backend engineers to do at the same time.

I really recommend to reconsider adapting Alpine even if you have external infrastructure specialists.
In many case, these wasteful knowledge will not be taken over unless you notice and ask for these information.
to keep facing technical debt is bad for your health because it is difficult to solve these issues

Summary

One day, I talked about Docker and building environment with an engineer. We both had a tough time using Alpine, so, we hit it off.
Then I decided to write about it.

If I have a opportunity to join a technical selection and someone propose using Alpine for container base image, I will definitely propose "NOOOO!!!! Use Debian or Debian Slim. NOT Alpine".
The objective of article is that.

You might feel this is debateable, however if you really want to use Alpine, you have to explain advantages outweigh the disadvantages listed above.