イメージのサイズは、アプリケーションの速度とサイズに大きな影響を与える可能性があります。 イメージをスリムにすると、ビルド時間が短縮されるだけでなく、アプリケーションのフットプリントの最適化にも役立ちます。 しかし、コンパクトでLinuxフレンドリーなアプリケーションをうまくデプロイするには、それらをクロスプラットフォームユニットにパッケージ化することを意味します。 そこで役立つのが、コンテナと BusyBox Dockerオフィシャルイメージ です。
BusyBox コンテナー イメージは非常に軽量です。 ほとんどのタグは 900KB 未満 (アーキテクチャによって異なります) であるため、開発者がそのスリムさに惹かれる Alpine イメージよりもさらに小さくなります。
BusyBoxのコンパクトなサイズは、最初のアップロードとダウンロードの時間を大幅に短縮することで、より迅速な共有を可能にします。 この小さな基本イメージは、アプリケーションの攻撃対象領域を減らすこともできます。
このガイドでは、BusyBox の概要、その使用方法、ベスト プラクティスの共有、コンテナー イメージの使用方法を紹介します。
BusyBoxとは何ですか?
人々はしばしばこのオープンソースプロジェクトを「組み込みLinuxのスイスアーミーナイフ」と呼んでいます。 BusyBoxは、複数の一般的なUNIXユーティリティ(またはアプレット)を1つの実行可能なバイナリにパッケージ化します。 これにより、独自のLinuxディストリビューションを作成できます。 また、Docker イメージを使用すると、さまざまな環境で BusyBox を使用できます。
小型ながらも強力なこの 1 つの実行可能ファイルには、UNIX の主要なコマンドの約 400 つが含まれています。 また 、多くのGNUユーティリティ (例: shellutils と fileutils) を、完全なディストリビューションで同等のものに置き換えてください。 完全な機能が欠けているものもありますが、それらの主な機能はそのままであり、開発者に妥協を強いることはありません。
どのバージョンのBusyBoxを使用すればよいですか?
BusyBox は、一般的なシェル コマンドの使用エクスペリエンスを再現するのに役立ちます。 一部のLinuxディストリビューションはGNUの coreutils パッケージを使用してこれらのコマンドを出荷しますが、他のディストリビューションは代わりにBusyBoxを選択しました。 これは最も完全な環境ではありませんが、使いやすく軽量な環境を必要とする開発者に最適です。
このソフトウェアスイートには、さまざまなビルド済みバイナリバージョンがあり、Docker Hubで 30 を超えるイメージタグをサポートしています。 それぞれに、CPU と依存関係ごとに独自の Linux バイナリ バリアントが含まれており、イメージのサイズと機能が異なります。
また、各イメージタグは、さまざまな libc バリエーションに対して構築されています。 各イメージと musl、uClibc、dietlibc、glibc との関係がビルドにどのような影響を与えるかを理解するには、この 比較表をご覧ください。 これは、特定のユースケースに適した画像を選択するのに役立ちます。
そうは言っても、BusyBoxは何に最適ですか? さっそく見ていきましょう。
BusyBoxのユースケース
Linuxの開発者のユースケースはかなり異なりますが、ここで取り上げるいくつかの興味深い例があります。
1. 組み込みシステム用のディストリビューションを構築
組み込みシステムは、利用可能なリソースが限られていることで知られており、必要な機能のみを含む微小サイズのディストリビューションが必要です。 飾り気や余分な依存関係の余地はほとんどありません。 そのため、組み込みLinuxのバージョンは合理化され、目的に合わせて構築されるのが最善です。 これはBusyBoxが優れているところです。
BusyBoxはかなりモジュール化されています。 ビルドに適した画像を選択できます。 ただし、コンパイル中にコマンドや機能を選択することもできます。
必要のないものを(ある程度)まとめる必要はありません。 通常、Linuxカーネル上で実行します。 ただし、実装をコンテナ化すると、このカーネルをコンテナ自体に含める必要がなくなります。 BusyBoxは、組み込みシステムのカーネルを活用し、スペースを節約します。
特定の画像内の各アプレットの動作によって、特定の埋め込み環境内でどのように機能するかが決まります。 BusyBoxを使用すると、構成ファイル、ディレクトリ、およびインフラストラクチャを変更して、選択した組み込みシステムに最適にすることができます。
2. Kubernetes Initコンテナの活用
BusyBox Docker公式イメージは、Kubernetes initContainer 機能でもうまく機能します。 これらの 特殊な コンテナ(この例では)は、Pod内のアプリケーションコンテナの前に実行されます。
init コンテナーには、アプリケーション イメージの外部にあるスクリプトやその他のユーティリティを含めることができます。 これらの「通常の」コンテナの初期化は、これらのコンポーネントを最初にスピンアップするk8sに依存する場合があります。 ただし、タスクが終了するまで、常に同期的に実行されます。
また、これらのコンテナーは、厳密に構成されたリソース制限に準拠し、ボリュームをサポートし、セキュリティ設定を尊重します。
しかし、あなたは何のために使う initContainer ことができますか? k8sのドキュメントによると、次のことができます。
- ポッドがスピンアップしたときに サービスが 作成されるのを待ちます
- APIからリモートサーバーにPodを登録する
- 割り当てられた期間待ってから、アプリ コンテナーを最終的に開始します
- Git リポジトリをボリュームに複製する
- 値入力から構成ファイルを自動的に生成する
Kubernetesは、その構成ファイルを使用して、これらのプロセスがどのように発生するかを、シェルコマンドとともに指定します。 このファイルでは、選択したタグを使用して、BusyBox Dockerイメージを指定できます。 Kubernetes はイメージをプルし、一意の ID を割り当てながら、そこからコンテナーを作成して起動します。
BusyBox と Docker で init コンテナーを使用すると、重要なワークフローを開始する前にアプリ コンテナーを準備できます。
3. HTTP Web サーバーの実行
BusyBoxコンテナイメージが基本的なLinux環境の作成に役立つと述べたことを覚えていますか? その環境を使用して、コンパイルされたLinuxアプリケーションを実行し、カスタム実行可能ファイルを作成できます。 次に、これらの実行可能ファイルは Web アプリをサポートできます。
たとえば、開発者のSoham Kamaniは、この方法を使用して、 Goサーバーを利用したWebアプリをサポートしています。 Sohamは、次の方法でこれを達成しました。
- Docker CLI を使用して一般的なコマンドを実行するための BusyBox コンテナーの作成。
- カスタムGolang "hello world"プログラムを作成し、それをサポートするコンパニオン
Dockerfileを作成した後にカスタム実行可能ファイルを実行します。 - BusyBox をベースとして使用して Docker イメージをビルドして実行します。
server.goファイルの作成、コンパイル、および Docker コンポーネントを使用した Web サーバーとしての実行。
BusyBoxを使用すると、このワークフローに取り組み、スリムで最終的な画像を作成できます。 これにより、アプリケーションを効果的に実行、繁栄、拡張、およびデプロイできる環境が作成されます。 視覚的なインターフェイスを好む場合は、 Docker Desktop を使用してイメージとコンテナーを簡単に管理することもできます。
チュートリアル全体を読み、GitHub でサンプル コードを表示できます。Goベースのサーバー展開をもっと検討したいですか? Caddy 2の画像ガイドをご覧ください。
これは、BusyBoxのユースケースをすべて網羅したリストではありません。 しかし、これらの例は、単純なLinuxベースのイメージでも、いかに創造的になることができるかを示しています。
BusyBox イメージの使用を開始する
その機能を調べたので、BusyBoxをインストールしてDockerで使用を開始する方法を学びましょう。
ステップ 1: Docker イメージを実行する
まず、次のコマンドを使用してBusyBoxをシェルとして実行します。
$ docker run -it --rm busybox
これにより、BusyBoxシステム sh内でコマンドを実行できるようになります。 このフラグは -it 両方 -i を結合し -t 、開いたまま STDIN にして疑似 tty を割り当てます。 これにより -tty 、コンテナ内に仮想ターミナルセッションを作成するようにDockerに指示されます。 --rmフラグを使用すると、コンテナを整理し、終了時にファイルシステムを削除するようにDockerに指示します。
ステップ 2: Dockerfile を作成する
次に、静的にコンパイルされたバイナリの を作成します Dockerfile 。 基本的な BusyBox Dockerfile は次のようになります。
FROM busybox
COPY ./my-static-binary /my-static-binary
CMD ["/my-static-binary"]
注: このコンパイルは、Docker コンテナーなどの別の場所で完了する必要があります。 Alpine を使用できますが、拡張機能が必要ない場合は、代わりに BusyBox を使用できます。
Step 3: バリエーションを選択
最後に、常にニーズに最も適したバリアントを選択してください。 次のいずれかを使用できます。
busybox:uclibc (英語)busybox:glibc (日本語)busybox:musl (英語)
オプション 1 と 3 は静的にコンパイルされますが、 glibc Debian に由来します。
Docker と BusyBox は同等のシンプルさ
BusyBoxは、単純なLinuxを愛する開発者にとって不可欠なツールです。 これにより、簡素化された(しかし適応可能な)Linux環境内で、強力でカスタマイズされたLinux実行可能ファイルを作成できます。 ユースケースは多様であり、BusyBox画像は肥大化の軽減に役立ちます。
DockerとBusyBoxはどちらも、Kubernetesなどの一般的な関連テクノロジーを含めながら、うまく連携します。 画像のサイズが小さいにもかかわらず、常に進化している多くのエキサイティングな開発の可能性を解き放ちます。 Docker Hub にアクセスして詳細を確認し、最初の BusyBox イメージをすばやく取得してください。