一部の人々は、Linuxディストリビューションはもはやコンテナーとは関係がないと言います。ディストロレスコンテナやスクラッチコンテナなどの代替アプローチが大流行しているようです。私たちは、私たちの選択の二次的影響を通して考えるよりも、ファッションセンスと即時の感情的な満足に基づいてテクノロジーの決定を検討し、行っているようです。次のような質問をする必要があります。これらの選択は、6か月後のメンテナンスにどのように影響しますか？エンジニアリングのトレードオフは何ですか？このパラダイムシフトは、大規模なビルドシステムにどのように影響しますか？
見るのはイライラします。エンジニアリングが測定可能なトレードオフ（長所と短所、さまざまなアプローチのコストとメリット）を伴うゼロサムゲームであることを忘れた場合、私たちは自分自身に不利益をもたらし、雇用主に不利益をもたらし、最終的には不利益をコーディングします。最後に、私たちはすべてのメンテナを（メンテナを歓迎します！）彼らが行う仕事に感謝しないことによって不利益をもたらします。
この問題を理解するには、そもそもなぜLinuxディストリビューションを使い始めたのかを調査する必要があります。理由をカーネルと他のパッケージの2つの主要なバケットにグループ化します。カーネルのコンパイルは実際にはかなり簡単です。 SlackwareとGentoo（私はまだ私の心の中にソフトスポットがあります）は私たちにそれを教えてくれました。
一方、使用可能なLinuxシステム用にパッケージ化する必要のある膨大な量の開発およびランタイムソフトウェアは、気が遠くなる可能性があります。さらに、何百万ものパッケージの順列をインストールして連携させることができる唯一の方法は、古いパラダイムを使用することです。つまり、コンパイルして、モノとして一緒に出荷します（つまり、Linuxディストリビューション）。では、なぜLinuxディストリビューションはカーネルとすべてのパッケージを一緒にコンパイルするのでしょうか。シンプル：物事が連携して機能することを確認します。
まず、カーネルについて話しましょう。カーネルは特別です。コンパイルされたカーネルなしでLinuxシステムを起動するのは少し難しいです。これはLinuxオペレーティングシステムのコアであり、システムの起動時に最初に依存するものです。カーネルには、コンパイル時にさまざまな構成オプションがあり、ハードウェアとソフトウェアの実行方法に多大な影響を与える可能性があります。このバケットの2番目の問題は、コンパイラ、Cライブラリ、インタプリタなどのシステムソフトウェアを、カーネルに組み込んだオプションに合わせて調整する必要があることです。 Gentooはこれを内臓的な方法で教えてくれたので、誰もがミニチュアのディストリビューションメンテナーになりました。
恥ずかしいことに（私は過去5年間コンテナーを扱ってきたので）、ごく最近カーネルをコンパイルしたことを認めなければなりません。 OpenStack仮想マシン、ラップトップのKVM仮想マシン、およびContainer Development Kit（CDK）でOpenShiftを実行できるように、ネストされたKVMをRHEL7で動作させる必要がありました。 #justsayin言うまでもなく、私は当時、まったく新しい4.XカーネルでRHEL7を起動しました。他の優れたシステム管理者と同様に、いくつかの重要な構成オプションとパッチを見逃しているのではないかと少し心配していました。そしてもちろん、私は持っていた いくつかのことを逃した。スリープモードが正しく機能しなくなり、ドッキングステーションが正しく機能しなくなり、他にも多数の小さなランダムエラーが発生しました。しかし、ラップトップ上の単一のKVM仮想マシンでのOpenStackでのOpenShiftのライブデモには十分に機能しました。さあ、それはちょっと楽しいですよね？しかし、私は逸脱します…
それでは、他のすべてのパッケージについて説明しましょう。カーネルと関連するシステムソフトウェアはコンパイルが難しい場合がありますが、ワークロードの観点から見ると、はるかに大きな問題は、何千ものパッケージをコンパイルして、使用可能なLinuxシステムを提供することです。各パッケージには、対象分野の専門知識が必要です。一部のソフトウェアでは、 ./ configureの3つのコマンドのみを実行する必要があります。 、作成 、およびインストールを行う 。他のユーザーは、ユーザーの追加から etc での特定のデフォルトの構成に至るまで、多くの専門知識を必要とします。 インストール後のスクリプトを実行し、systemdユニットファイルを追加します。使用する可能性のある何千もの異なるソフトウェアに必要な一連のスキルは、1人の人間にとっては気が遠くなるようなものです。ただし、いつでも新しいソフトウェアを試すことができる使いやすいシステムが必要な場合は、新しいソフトウェアの使用方法を学ぶ前に、新しいソフトウェアをコンパイルしてインストールする方法を学ぶ必要があります。これは、LinuxディストリビューションのないLinuxです。これは、Linuxディストリビューションを放棄したときに同意するエンジニアリング上の問題です。
重要なのは、すべてを一緒に構築して、適切なレベルの信頼性で動作するようにする必要があることです。また、使用可能なパッケージのコホートを構築するには、大量の知識が必要です。これは、単一の開発者やシステム管理者が合理的に学習して保持するよりも多くの知識です。私が説明したすべての問題は、コンテナホスト（カーネルとシステムソフトウェア）とコンテナイメージ（システムソフトウェアと他のすべてのパッケージ）に当てはまります。重複に注意してください。コンテナイメージには、コンパイラ、Cライブラリ、インタプリタ、およびJVMも含まれています。
あなたはすでにこれを知っていますが、Linuxディストリビューションが解決策です。読むのをやめて、最寄りのパッケージメンテナ（メンテナを呼んでください！）にeカードを送ってください（待ってください、私はちょうど私の年齢をあげましたか？）。真面目な話ですが、これらの人々はたくさんの仕事をしていて、それは本当に過小評価されています。 Kubernetes、Istio、Prometheus、Knative：私はあなたを見ています。あなたがメンテナンスモードになり、使いすぎで、過小評価されるとき、あなたの時間も来ています。この同じ記事を、おそらくKubernetesについて、約7〜10年後にもう一度書きます。
ゼロから構築することとベースイメージから構築することにはトレードオフがあります。
ベースイメージからのビルドには、ほとんどのビルド操作がパッケージのインストールまたは更新にすぎないという利点があります。これは、Linuxディストリビューションのパッケージメンテナによって行われる大量の作業に依存しています。また、今から6か月後（または10年後）のパッチ適用イベント（RHELを使用）は、開発者イベントではなく、運用/システム管理者イベント（yum update）であるという利点もあります（コードを選択して理由を理解する必要があります）。関数の引数は機能しなくなりました。
それを少しダブルクリックしてみましょう。アプリケーションコードは、JSONマングライブラリからオブジェクトリレーショナルマッパーに至るまで、多くのライブラリに依存しています。 LinuxカーネルやGlibcとは異なり、これらのタイプのライブラリは、APIの互換性を損なうことをほとんど考慮せずに変更されます。つまり、3年後、パッチ適用イベントは、yum updateイベントではなく、コード変更イベントになる可能性があります。セキュリティチームがエクスプロイトをブロックするファイアウォールハックを見つけることができない場合、開発者は午前2時にページングされます。
ベースイメージからの構築は完璧ではありません。ドラッグされるすべての依存関係のサイズなどの欠点があります。これにより、ほとんどの場合、コンテナイメージは最初から構築するよりも大きくなります。もう1つの欠点は、常に最新のアップストリームコードにアクセスできるとは限らないことです。これは開発者にとってイライラする可能性があります。特に、何かを戸外に出したいだけの場合は、アップストリームのメンテナがずっと変更していると3年間考えていなかったライブラリを確認するためにページングされるほど、イライラすることはありません。 。
あなたがWeb開発者であり、私に目を向けているなら、私はあなたに一言あります：DevOps。つまり、私の友人、ポケットベルを持っているということです。
スクラッチビルドには、非常に小さいという利点があります。コンテナー内のLinuxディストリビューションに依存しない場合は、多くの制御が可能です。つまり、ニーズに合わせてすべてをカスタマイズできます。これは最善のモデルであり、特定のユースケースで有効です。もう1つの利点は、最新のパッケージにアクセスできることです。 Linuxディストリビューションが何かを更新するのを待つ必要はありません。あなたが管理しているので、新しいソフトウェアを組み込むためにエンジニアリング作業をいつ費やすかを選択します。
すべてを管理するにはコストがかかることを忘れないでください。多くの場合、新しい機能を備えた新しいライブラリに更新すると、不要なAPIの変更がドラッグされます。これは、コードの非互換性を修正することを意味します（つまり、ヤクを剃ります）。アプリケーションが機能しない午前2時にヤクを剃るのは楽しいことではありません。幸いなことに、コンテナを使用すると、翌営業日にヤクをロールバックして剃ることができますが、それでもビジネスに新しい価値、アプリケーションに新しい機能を提供するための時間に食い込みます。システム管理者の生活へようこそ。
そうは言っても、ゼロから構築することが理にかなっている場合があります。静的にコンパイルされたGolangプログラムとCプログラムは、スクラッチ/ディストロレスビルドの2つの適切な候補であることを完全に認めます。これらのタイプのプログラムでは、すべてのコンテナービルドがコンパイルイベントです。 3年後もAPIの破損について心配する必要がありますが、Golangショップの場合は、時間をかけて修正するためのスキルセットが必要です。
基本的に、Linuxディストリビューションは、通常のLinuxシステムまたはコンテナーを使用して時間を節約するために多くの作業を行います。メンテナが持っている知識は途方もないものであり、実際に評価されることなく非常に活用されています。コンテナの採用は、さらに抽象化されているため、問題をさらに悪化させています。
コンテナホストを使用すると、Linuxディストリビューションは、小さなARMシステムから、巨大な128 CPU x86ボックス、クラウドプロバイダーVMに至るまで、幅広いハードウェアエコシステムへのアクセスを提供します。動作するコンテナエンジンとコンテナランタイムをすぐに利用できるので、コンテナを起動するだけで、他の誰かに動作させることを心配させることができます。
コンテナイメージの場合、Linuxディストリビューションを使用すると、プロジェクト用の大量のソフトウェアに簡単にアクセスできます。ゼロから構築する場合でも、パッケージメンテナがどのように物を構築して出荷したかを確認する可能性があります。優れたアーティストは優れた泥棒です。したがって、この作業を過小評価しないでください。
それで、Fedora、RHEL（Frantisek、あなたは私のヒーローです）、Debian、Gentoo、および他のすべてのLinuxディストリビューションのすべてのメンテナーに感謝します。私は「コンテナの男」ですが、あなたの仕事に感謝しています。