コンテナ構築の7つのベストプラクティス

コンテナと Kubernetes は急速に人気を集めていますが、まず 1 つのことを明確にする必要があります。それは、コンテナと Kubernetes はすべてのタイプのアプリケーションの構築に適しているわけではないということです。 「できる」と「すべき」を明確に区別する必要があります。たとえば、コンテナ内で実行するように特別にアプリケーションを構築し、Kubernetes を使用してオーケストレーションすること (「クラウド ネイティブ」開発とも呼ばれます) は、これらのテクノロジを使用して既存のモノリシック アプリケーションを管理することとは大きく異なります。

実際、コンテナ分野に参入したばかりのチームにとって、コンテナと Kubernetes 専用の新しいアプリケーションを構築することは、理想的な出発点となることがよくあります。 「コンテナとオーケストレーションは、クラウドネイティブアプリケーションの構築、展開、実行に重要なツールです」と、Aqua Securityの戦略担当副社長、Rani Osnat氏は述べています。 「コンテナを使い始めたばかりの人には、新しいシンプルなアプリケーションをテストケースとして使用することをお勧めします。」

コンテナと Kubernetes を使用してアプリケーションを開発する方法について、Osnat 氏と他のクラウド ネイティブ テクノロジーの専門家に意見を聞き、次の 6 つのベスト プラクティスをまとめました。

現代建築を考え、建てる

50 年前の家屋の建築方法やスタイルが現代の建築とは大きく異なるのと同様に、ソフトウェアの構築でも同じことが起き、可能な限り新しいツールや方法を使用する必要があります。

SADA CTO の Miles Ward 氏は、「アプリケーションを構築する場合は、必ず最新の方法を使用してください」と述べています。 Ward 氏はまた、マイクロサービスと 12 要素方法論が現代のアプリケーション開発における中核原則となるべきだと指摘しました。

Ward 氏は、マイクロサービスとコンテナ テクノロジーはうまく連携できるものの、ほとんどの開発シナリオでは実際にはそのような組み合わせは必要ないと述べました。 「マイクロサービスはKubernetesと同一視されることが多いが、これは必ずしも必要ではない。モノリシック開発も、モノリスとして展開し、同じコードベース上で異なるエンドポイントとしてスケールアウトできる限り、同様に適用可能である」とウォード氏は強調した。 「12 ファクター手法についても同じことが言えます。これは確かに良い出発点ですが、不可欠な教義ではありません。」

Osnat 氏は次のようにアドバイスしています。「コンテナを最大限に活用するには、アプリケーションをマイクロサービスとして設計します。マイクロサービスでは、個々のコンテナは更新されても正常に実行できます。同時に、コンテナ イメージが独立したリリース ユニットを表すように設計を構築し、効果的な CI/CD メカニズムを実装する必要があります。」

「現代的な」開発は、さまざまな方法で定義されることが多いです。コンテナと Kubernetes 用のアプリケーションを構築する場合は、適切なパッケージングとテクノロジーの展開オプションを選択する必要があります。さらに 2 つの例を見てみましょう。

• コンテナ イメージを、独立してスケーリングできる論理ユニットとして定義します。データベース、ログ記録、監視、負荷分散、およびユーザー セッション コンポーネントをコンテナまたはコンテナのグループとして実装します。
• クラウドネイティブ API の使用を検討してください。Kubernetes には強力な API 拡張メカニズムがあります。これをコンテナ ツールと統合すると、コマンドライン ユーティリティや認証など、エコシステム内の既存のソリューション オプションをすぐに使用できるようになります。

ソフトウェア開発の観点から見ると、「モダン」であることも良いことです。 「最近の言語やフレームワークの最も優れた点は、コンテナとうまく連携することです」と、Harness の DevOps アドボケートである Ravi Lachhman 氏は述べています。 「ほんの数年前まで、Java などの言語はコンテナの境界を強制するのに苦労していました。現在では、Kubernetes などのコンテナやオーケストレーション ツールの登場により、言語やフレームワークは新しいパラダイムを採用しています。」

CI/CDと自動化の力を活用する

自動化はコンテナ オーケストレーション システムの重要な機能であり、コンテナで実行されるさまざまなアプリケーションを構築する上でほぼ中核的な要素となっています。自動化がなければ、最新のアプリケーションの運用上の負担は膨大になる可能性があります。

Brillio のチーフ アーキテクトである Chander Damodaran 氏は、「アプリケーションとサービスを自動化して構築すると、リスク レベルを大幅に削減できます。サービスとコンポーネントの数が増えると、アプリケーションとサービスの運用が解決不可能な問題になる可能性があります」とアドバイスしています。

適切に設計された CI/CD パイプラインは、開発およびデプロイメント プロセスのすべての段階に可能な限り自動化を導入します。これは、人気の新しいトレンドとなっています。自動化の価値は別の観点からも理解できます。自動化により、特に開発の初期段階で避けられないエラーを排除しやすくなります。

「新しいプラットフォームを使用するには多くの試行錯誤が必要であり、Kubernetes だけではこうした試行で起こり得るエラーを相殺するには不十分です」と Harness の Lachhman 氏は指摘します。 「堅牢な継続的デリバリー パイプラインを構築することによってのみ、テスト、セキュリティ、変更管理ポリシーなどの信頼性の高い標準を確立し、アプリケーションを効率的に実行し続けることができます。」

コンテナイメージを可能な限り軽量に保つ

コンテナと Kubernetes を使用してアプリケーションを開発する際のもう 1 つの重要な原則は、パフォーマンス、セキュリティ、およびその他の関連要件を満たすために、イメージを可能な限り軽量に保つことです。

「本当に必要なものだけを残してください」と、THoughtWorks の CTO オフィスの主任技術者、ケン・マグラージ氏は言います。 「イメージには、メインアプリケーションに必要のない追加パッケージが含まれていることがよくあります。」したがって、シェル ユーティリティを含め、アプリケーションに必要のない他のすべてのパッケージを削除します。これにより、画像のサイズが縮小されるだけでなく、攻撃対象領域も縮小されます。

CloudBolt の製品マーケティング責任者である Nilesh Deo 氏も同意しています。 「開発者は、アプリケーション開発へのアプローチを再考する必要があります。たとえば、より小さなコンテナとベースイメージを作成します。イメージが小さいほど、読み込みが速くなり、アプリケーションの実行が速くなります。」

鏡を盲目的に信じてはいけない

ソフトウェア開発では、「車輪の再発明」を避けるために、既存のコンポーネントを再利用することがよくあります。これはコンテナ開発の場合に特に当てはまります。しかし、セキュリティの観点からは、画像を盲目的に信頼することはできず、画像にセキュリティ上の欠陥がないか特に注意する必要があります。

「多くの人は、何らかのアプリケーション スタックがインストールされていることに気づかずに、リポジトリから直接イメージを選択します」と Mugrage 氏は言います。 「これらのイメージは品質が低いことが多く、無視できないセキュリティ上の問題さえあります。私たちが使用するすべてのイメージは、たとえ私たち自身のリポジトリからのイメージであっても、展開パイプラインで実行する前に脆弱性とコンプライアンスをスキャンする必要があります。」

最初から観測性、テレメトリ、監視を計画する

障害はコンテナとマイクロサービスの一部です。もちろん、ここでの重点は、障害を完全に回避することではなく、障害管理にあります。 Kubernetes の自己修復機能は間違いなくその最大の魅力の 1 つですが、ユーザーが適切な可視性を持つことも必要です。この分野では、可観測性、テレメトリ、監視メカニズムが最も重要な機能になります。

Sentry.io のソフトウェア エンジニアである Andrei Zbikowski 氏は、「Kubernetes には、包括的な監視のベスト プラクティスを満たす復元力メカニズムが組み込まれています」と述べています。 「自己修復機能により、特定のパラメータが正常性要件を満たしていない場合に、障害が発生したコンテナを再起動したり、他のコンテナを終了して置き換えたりすることができます。この機能により、アプリケーションを長時間正常に実行し続けることができますが、他の問題を隠す可能性もあります。」

ズビコウスキー氏は、コードの可視性が欠如していると、アプリケーションがいつでもエラーをスローする可能性があるが、管理者は動作指標が正常であるためすべてが順調であると誤って確信していると付け加えた。 「コンテナ/バックエンド システムだけでなく、アプリケーションも監視することが非常に重要です。包括的な監視アプローチには、大きな影響が発生する前に問題を特定して修正できるように、問題の可視性を幅広く高める機能が必要です。」

「最初から観測性と監視の要件を考慮する必要があります」とマグラージ氏は言う。 「分散アプリケーションのトラブルシューティングは難しく、アプリケーション設計に組み込む必要があります。後から追加された監視ソリューションは効果がないことがよくあります。」

Red Hat のテクニカル プロフェッショナル エバンジェリストである Gordon Haff 氏は、次のように述べています。「さまざまなクラウド ネイティブ テクノロジー ツールを使用すると、アプリケーションに複雑な監視、トレース、サービス メッシュ、ダッシュボードを構築できます。たとえば、Prometheus、Jaeger、Kiali、Istio はすべてこのカテゴリに含まれます。ただし、ツールの種類が多岐にわたるため、テクノロジーの選択が困難になっています。」

ステートレスアプリケーションから始めることを検討する

一般的に、ステートレス アプリケーションの実行は、ステートフル アプリケーション (データベースなど) の実行よりもはるかに簡単です。 Kubernetes オペレーターが追加されると、状況は変わってきます。ただし、Kubernetes を使い始めたばかりのチームにとっては、ステートレス アプリケーションを実行する方がよい選択肢となる可能性があります。

Plotly の共同創設者である Chris Parmer 氏は、次のように述べています。「ベスト プラクティスを 1 つだけ選ぶとしたら、ステートレス アプリケーションから始めることをお勧めします。ステートレス バックエンドを使用すると、開発チームは長時間実行される接続や変更可能な状態がないことを確認できるため、スケーリングの難しさが大幅に軽減されます。開発者は、ダウンタイムなしでアプリケーションを簡単に展開できるため、エンド ユーザーのリクエストを異なるコンテナーに並行して配信できます。」

Parmer 氏は、Kubernetes 上でコンテナを実行する主な利点はスケーラビリティであり、ステートレス アプリケーションを使用するとこの利点を活用できると指摘しました。

「ステートレス アプリケーションとは、開発チームが組織のビジネス ニーズに合わせてコンテナをより簡単に移行および拡張できることを意味します。コンテナを自由に追加または削除することもできます。ステートレス バックエンドに基づく Web アプリケーション フレームワークを使用することで、Kubernetes クラスターを最大限に活用できます」とパーマー氏は述べています。

コンテナの構築は簡単ではない

現在に至るまで、Kubernetes には基礎となるシステムを本当に簡単に理解できる抽象化がまだ存在していません。少なくとも、現在のソリューションでは使いやすくすることしかできません。 「それは決して簡単なことではありません。そうでなければ誰もがKubernetesを構築していたでしょう」と、Red Hat OpenShiftの最高技術マーケティングマネージャー、クリス・ショート氏は語った。 「私たちは、クラスターの状態や基盤となるインフラストラクチャの「存在感」、さらには管理の必要性さえも排除しながら、コンテナをオーケストレーションします。etcd は Kubernetes に大きく依存しており、多くのベンダーがそれを隠そうとしています。Kubernetes には、ネットワーク、セキュリティ、その他多くの複雑な要素が関係しています。失敗を覚悟して初めて、チームは Kubernetes の探求の第一歩を踏み出し、真に「現代的な」アーキテクチャに対する正しい考え方を身に付けることができます。」