コンテナを展開する際に考慮すべき6つの重要な要素

[51CTO.com クイック翻訳] コンテナは強力で、アプリケーションやサービスの提供が簡単です。コンテナの目的は変数を減らし、それによって簡素化と効率性の向上を図ることですが、考慮すべき複雑な要素が数多くあります。企業の世界では、次の 6 つの要素を考慮することが重要です。

[[259224]]

1. パフォーマンス

開発者はパフォーマンスの観点から潜在的な問題について考えないことが多いですが、Web ブラウザを使用してアプリケーションにアクセスするからといって、大量の同時トランザクションを処理できるとは限りません。実際にテストしてみないと、その処理能力はわかりません。

Kubernetes はスケーラブルですが、多くのリソースも消費します。コンテナは、アーキテクチャ上の問題を解決し、必要な依存関係がすべて整っていることを確認するのに役立ちますが、展開後にパフォーマンスが自動的に保証されるわけではありません。

基盤となる言語ランタイム環境、Web サーバー、OpenSSL などのライブラリの品質はすべてパフォーマンスに影響を与えます。 Linux ディストリビューションには、回帰テストを実行し、さらに重要なことに、アーキテクチャ全体のパフォーマンスを最適化する意欲的なパフォーマンス エンジニアのチームがあることを確認してください。

2. 互換性

Linux の世界では、さまざまなプログラムがカーネル上で実行されます。ほとんどのプログラムは、カーネルとインターフェースする API (syscall レイヤー) を使用します。 Linux で syscall レイヤーを使用する必要がある場合は、前方互換性が重要です。

Linux の父、Linus Torvalds は、カーネルは下位互換性を破壊してはならないという厳格なルールを持っています。システムコール層は機能を壊さないようにするため、コンテナは常に前方互換性があります。

古いカーネルで新しいコンテナイメージを実行すると何が起こりますか?あるいは、syscall レイヤーから ioctl、/dev、/proc などの API に移行すると何が起こるでしょうか?

互換性には時間と空間の制約があり、適切な設計とテストが役立ちます。コンテナ イメージとホスト用の Linux ディストリビューションは、これらの問題について深く考える必要があります。そうしないと、ユーザーは悪い状態に陥ってしまいます。これは、カーネル レベル、コンパイラ レベル (gcc)、ライブラリ レベル (glibc)、および syscall インターフェイス外の API にも当てはまります。

もう 1 つの問題は、C ライブラリに関連する syscall 関数のみを使用する場合は問題がない可能性があることです。しかし、アプリケーションが、ioctl /proc や /dev などの他のカーネル API を使用するトラブルシューティングや監視コンポーネントなど、アプリケーションの一部ではない補助ソフトウェアを呼び出す可能性が高く、これが問題を引き起こす可能性があります。

コンテナ ホストをアップグレードすると、コンテナを実行できなくなる可能性があります。仮想マシンの世界では、一般的にそのことを心配する必要はありません (ただし、仮想化でも、一部のアーキテクチャやチップセットが問題を引き起こす可能性があります)。ただし、物理サーバーの世界では、一部のアーキテクチャやチップセットが問題を引き起こす可能性があります。

3. 既存のインフラストラクチャとの統合

サポートされているソフトウェアおよびハードウェア エコシステムは、基盤となる Linux ディストリビューションに対応しています。 ARM サポートが必要な場合は必須です。サポート可能性を考慮する – これは、ハードウェアのコンテナ ホストとソフトウェアのコンテナ イメージの両方に適用されます。

この「購入基準」は、コンテナ イメージとコンテナ ホストを選択するときに忘れられがちです。ただし、Linux ディストリビューションのエコシステム (ハードウェアとソフトウェア) は、コンテナ ホスト (ハードウェア) とコンテナ イメージ (ソフトウェア) で利用できるエコシステムであることを忘れないでください。 Linux ディストリビューションが特定のハードウェアまたはクラウド プロバイダーをサポートしている場合、コンテナー ホストはスムーズに実行されます。

アプリケーションが特定の Linux ディストリビューション用に設計および構築されている場合は、そのアプリケーションをその Linux ディストリビューションに基づくコンテナ イメージに配置する方がはるかに簡単になります。

4. セキュリティ

コンテナ イメージが本番環境にデプロイされると、アプリケーションとそのすべての依存関係が危険なインターネットに公開されます。これには、データ侵害、トロイの木馬イメージなどが含まれます。コンテナ環境用のコンテナ イメージとコンテナ ホストを選択するときは、これらすべての側面を考慮してください。

おそらく、Red Hat コンテナー カタログからコンテナー イメージをダウンロードせず、疑わしい Web サイトからダウンロードすることを選択した可能性があります。これは悪い考えだ。既知の適切なコンテナから開始しないと、知らないうちに誰かが悪意のあるコードを挿入する可能性があります。

安全性の観点から、コンポーネントの品質を知ることは非常に重要です。常に信頼できるソースを使用してください。覚えておいてください: コンテナはダウンロードした日は良いかもしれませんが、数年後には壊れている可能性があります。

5. サイズ

コンテナは多くのビルド操作を実行し、コンテナが再構築されるたびにアプリケーションが再コンパイルされます。

現在、開発者はイメージ内のすべての責任を負います。 1年後、あるライブラリのコードが下位互換性を失ってコンテナが壊れた場合、誰がそれを修正するのでしょうか? 「yum update」のような操作を行うだけの人ではなく、開発スキルを持つ人である必要があります。アプリケーションを再コンパイルする必要があるかもしれません。

もう 1 つの方法は、openssl を使用して動的にコンパイルされた Web サーバー ソフトウェアなどのパッケージを含むベース イメージをビルドすることです。パフォーマンスの問題は、yum update を実行して新しいパッケージを取得することで修正できます。これはコードを変更するよりもはるかに簡単ですが、最終的な画像は大きくなります。

ソフトウェアを追加すると、ベースイメージのサイズは 400 MB でも 500 MB でも問題になりません。

開発されているコンテナ化されたアプリケーションには、主に 2 つの種類があります。 1 つは Linux ベース イメージ上に構築され、もう 1 つはゼロから構築されます。

どちらのアプリケーションでも、コンテナ イメージをコンテナ ホストにプルするのに必要な時間に影響するため、ユーザーはコンテナ イメージのサイズに敏感になることがよくあります。最初からビルドして静的にコンパイルされたバイナリをデプロイする場合は、小さなベースイメージを選択するか、最初からビルドすることが重要です。

企業内で使用されるソフトウェアのエコシステム全体を構築する場合、ベース レイヤーは共有およびキャッシュされることが多いため、サプライ チェーン全体 (すべての RPM パッケージと依存関係) のサイズを考慮することがより重要になります。脅威にさらされる表面領域を減らすための鍵は、ライブラリと言語ランタイム環境の重複コピーを減らし、それによって環境全体のフットプリントを減らすことです。

6. サポート

サポートには、ライフサイクル サポートとホワイト グローブ サポートの 2 つの主な種類があります。

ライフサイクルによって、コンテナ イメージ (RPM または Debs) 内の特定のプログラムに対してサポートが提供される期間とリリースされるパッチが決まります。

ホワイト グローブ サポートでは、チケットを送信したり、ホットフィックスを取得したり、アップストリームの変更を提唱したりできます。

コンテナ化されたアプリケーションをどのくらいの期間サポートするかによって、どちらも非常に重要です。

アプリケーションは予想以上に長く実行されるため、ライフサイクル サポート コンテキストは重要です。おそらく3年から5年、あるいはそれ以上でしょう。アプリケーション/システムには多数のインスタンスが存在し、長年にわたって実行されています。 yum update を実行する前に、ベースイメージをどのくらいの期間サポートするかを考慮する必要があります。その後、振り出しに戻ってコードを変更し、ライブラリの別のバージョンを実装し、開発者の手に渡すことになりますが、これにはコストがかかる可能性があります。

自問してみてください:コンテナ イメージに更新はありますか?何かが壊れたら、誰かに電話して修理してもらえますか?固有の問題がある場合、開発パッチをリクエストできますか?チケットを送信してパッチをリクエストできることは、単に yum update を実行することと同じレベルのサポートではありません。

元のタイトル: コンテナを展開する際に考慮すべき 6 つの重要な要素、著者: Scott Matteson

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。