ベースイメージとしてのアルパインの長所と短所

高山

 Alpineオペレーティングシステムは、セキュリティ指向のLinux配です。通常のLinuxディストリビューションます。システムのサイズとランタイムリソースの消費をAlpine採用musl libcしbusyboxて削減しますが、その機能はbusyboxはるかに完全であるため、オープンソースコミュニティによってますます支持されています。重量を抑えながらAlpine、独自のパッケージ管理ツールも提供しapkます。Webhttps://pkgs.alpinelinux.org/packagesサイトもapk、コマンドを使用してさまざまなソフトウェアを直接照会してインストールすることもできます。

1.長所と短所

 1.1。利点

• ミラーサイズが小さい

  Alpine目標は、基本イメージの構築コストを削減して、構築されたイメージが占めるスペースを少なくすることです。したがって、最下層は動的なリンク関係である必要があります。しかし、それは特別です。GLIBCのような重いダイナミックライブラリを使用しませんが、 busybox + musl libcを使用します。glibcと比較して、musl libcライブラリはより小さく、よりシンプルで安全であり、スペースを大幅に削減し、同じ対応する機能を維持します。 。

• パッケージ管理ツールは高速です

  コンテナはサイクル内で頻繁に変更されます。新しいイメージが定期的に作成され、一部のデバッグツールが実行中のコンテナに一時的にインストールされる場合があります。ソフトウェアパッケージのインストール速度が非常に遅い場合、すぐに我慢できなくなります。アルパインイメージの管理ツールは非常に高速で、ソフトウェアのインストールエクスペリエンスは非常にスムーズです。

 1.2.デメリット

• ニッチな不利

  CentOSやUbuntuのような一般的なオペレーティングシステムとは異なりAlpine、Red HatやCanonicalのような大企業によって維持されていませんが、非営利組織によって維持されているため、パッケージの数はこれらのディストリビューションよりも少なくなっています（デフォルトのすぐに使えるリポジトリでは、Alpineには10,000個のパッケージしかありませんが、Ubuntu、Debian、Fedoraにはすべて50,000個以上あります）。

  プロジェクトでmusllibcによってリンクされたバイナリファイルを使用する必要があるが、ツールAlpine自体がそれを提供しない場合は、自分でコンパイルしてパッケージ化する必要があります。このプロセス自体は非常に複雑であり、その方法を理解する必要があります。makeでコンパイルします。大規模なステージ状態では、エラーが発生したときにデバッグする必要があり、時間の無駄です。

• 根本的な依存関係の欠陥

  最下層は、依存ライブラリとしてmusl libcを使用します。サイズが小さいことは利点ですが、欠点もあります。glibcのような完全な基になるダイナミックライブラリを持つことはできません。多層構築プロセスでは、関連するものが発生する可能性があります。依存関係が見つかりません。この問題は、Alpineが基になる画像として多数のピットを生成する原因となる埋め込みポイントでもあります。

  musl libcは、組み込みシステムで一般的に使用されます。これは、そのようなシステム自体のリソースが非常に少なく、基盤となる大きなライブラリを使用するのに適していないため、このような小さなライブラリの依存関係を使用する必要があるためです。

2.一般的な問題

1. Alpineを使用したPythonDockerコンテナの構築は50倍遅くなります

   pythonspeed.com/articles/al…

   这是一篇博文中给出的数据验证，上面地址是他的具体情况链接， 这种情况是很好理解的，因为 Python 是一种解释型的语言，它内部的很多依赖都已经打包好了，用 PIP 可以直接进行一个引入安装，但这些都绑定了特定的 C 库，这就意味着在大多数使用 glibc 的镜像中都可以正常安装，但 Alpine 镜像就不行。如果非要在 Alpine 中安装，你需要安装很多依赖，重头构建，耗时又费力。

2. 构建多层容器镜像时发生错误

   github.com/elastic/ela…

   Docker 的容器概念本来就是一个分层的多层文件系统，从底层开始一层一层的添加所属层来增加对于业务层的支撑，但是在这个问题中在超过 4 层就发生了构建错误......

3. DNS 转发失败

   musl libc does not use domain or search directives in the /etc/resolv.conf file. For example, if you started your Docker daemon with --dns-search=service.consul, and then tried to resolve consul from within an Alpine Linux container, it would fail as the name consul.service.consul would not be tried. You will need to work around this by using fully qualified names.

   Another difference is parallel querying of name servers. This can be problematic if your first name server has a different DNS view (such as service discovery through DNS). For example, if you started your Docker daemon with --dns=172.17.42.1 --dns=10.0.2.15 where 172.17.42.1 is a local DNS server to resolve name for service discovery and 10.0.2.15 is for external DNS resolving, you wouldn't be able to guarantee that 172.17.42.1 will always be queried first. There will be sporadic failures.

   In both of these cases, it can help to run a local caching DNS server such as dnsmasq, that can be used for both caching and search path routing. Running dnsmasq with --server /consul/10.0.0.1 would forward queries for the .consul to 10.0.0.1.

4. 二进制编译不兼容

   While there are binaries that will run on musl libc without needing to be recompiled, you will likely encounter binaries and applications that rely on specific glibc functionality that will fail to start up. An example of this would be Oracle Java which relies on specific symbols only found in glibc. You can often use ldd to determine the exact symbol:

   # ldd bin/java
   /lib64/ld-linux-x86-64.so.2 (0x7f542ebb5000)
   libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f542ebb5000)
   libjli.so => bin/../lib/amd64/jli/libjli.so (0x7f542e9a0000)
   libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f542ebb5000)
   libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f542ebb5000)
   Error relocating bin/../lib/amd64/jli/libjli.so: __rawmemchr: symbol not found
   

   In this case, the upstream would need to remove the support for this offending symbol or have the ability to compile the software natively on musl libc. Be sure to check the Alpine Linux package index to see if a suitable replacement package already exists.

3、方案替换

 如果程序仅用到了标准库或者依赖项和程序本身使用的是同一种语言，且无需调用 C 库和外部依赖，那么使用 Alpine 作为基础镜像一般是没有啥问题的。

 一旦程序需要调用外部依赖，情况就复杂了，想继续使用 Alpine 镜像，就得安装这些依赖。

1. 依赖库有针对 Alpine 的安装说明，一般会说明需要安装哪些软件包以及如何建立依赖关系。
2. 依赖库没有针对 Alpine 的安装说明，我们可以通过对比找到与别的发行版的软件包相匹配的 Alpine 软件包。
3. 依赖库没有针对 Alpine 的安装说明，也没有与之对应的软件，这种情况就必须从源码开始构建。

 我们大概可以得出一个结论，Alpine 通过降低底层依赖来减少自身的一个体积成为了后续最大的问题隐患，在场景比较复杂的情况下我们就需要切换基础镜像，使用功能更加全面、体积也相对较为轻便的镜像。

 通过 Docker hub 中的镜像比对，可以选择几款替代品，虽然在相对体积上还是比不上 Alpine ，但是容器上面体积小并不是最重要的一个指标，在一定条件下一个持续稳健的容器比一个精细的容器要更加的好。

下表是仓库中最新的 Alpine 和其他基础镜像的镜像大小比对（只比较了一个操作系统下的情况）

IMAGE	DIGEST	OS/ARCH	COMPRESSED SIZE
alpine	4ff3ca912757	linux/amd64	2.67 MB
debian	3345381beaed	linux/amd64	28.3 MB
ubuntu	386bace9fb0d592	linux/amd64	29.01 MB
fedora	486fd5578f93	linux/amd64	56.2 MB

 虽然 docker 极力想要把基础镜像从 ubuntu 迁移到 alpine ，但是考虑到用户的选择问题，还是做出了妥协，从docker 官方发布的镜像的发行版中可以看出一些的端倪，可以使用 debian 作为基础镜像的替换，彼此之间的体积差异也不是很大。