Blog
コンテナはすべての問題を解決するわけではありませんが、それは始まりです
By Ryan Overton
コンテナは、プロジェクトのコストを削減し、時間を節約するのに役立ちます。 Kentico Xperience環境でそれらの可能性を最大限に活用するにはどうすればよいですか?私たちの記事で調べてください。
数か月前、私はコンテナを使用して、プロジェクトで新しい開発者を立ち上げるのにかかる時間を短縮する方法について書きました。ただし、これは、コンテナの利点を利用してコストを削減し、リソースを削減し、プロジェクトの時間を節約できる多くの方法の1つにすぎません。
コンテナとは何ですか?
環境でコンテナーを使用する必要がある理由を説明する前に、レベルを設定して、コンテナーと言うときに何について話しているのかを正確に理解しましょう。
コンテナーは、アプリケーションを環境間で迅速かつ確実に実行するために必要なすべてのコード、設定、および依存関係を、小さくて軽量な実行可能形式でパッケージ化するための標準化された方法です。
多くの場合、LinuxやWindowsなどのゲストオペレーティングシステムがホストオペレーティングシステム上で実行される仮想マシンと比較されます。ただし、ハードウェアスタックを仮想化する仮想マシンとは異なり、コンテナはハードウェアコンポーネントを抽象化し、オペレーティングシステムで仮想化します。これにより、さまざまな環境に簡単かつ確実に展開できます。
コンテナを活用する利点
移植性
コンテナには、アプリケーションの実行に必要なすべてのものが含まれています。そのおかげで、オンプレミスやクラウドなど、さまざまな環境間で簡単に移動できます。また、業界標準の形式を使用しているため、クラウドプロバイダー間を移動することもできます。一度ビルドすると、どこでも実行できます。
サンドボックス化
複数のコンテナを同じサーバー上で実行できますが、それらは分離された環境(サンドボックス)で実行され、アプリケーションを互いに分離して実行し続けます。一方のアプリケーションがもう一方のアプリケーションをクラッシュさせても、影響を受けません。または、考えられないことが起こり、1つのアプリケーションがハッキングされた場合、攻撃はそのアプリケーションのみに限定されます。
テスト容易性
コンテナは、アプリケーションの機能を確認するために必要なさまざまなソフトウェアテストが実行される、予測可能で反復可能な環境を提供します。テストの実行後に環境をリセットするために複雑なスクリプトは必要ありません。新しいテストが必要な場合は、すべてのテストデータで構成済みの新しいコンテナーを起動し、テストを実行して、完了したらコンテナーを破棄します。
パフォーマンス
オペレーティングシステムレイヤーが仮想化されているため、コンテナーはオペレーティングシステムを起動する必要がありません。彼らは数秒で起動することができます。したがって、アプリケーションの次のリリースまたはバグ修正が発生したときに、新しいコンテナーをすばやくスピンアップできます。新しい機能と修正は、後でではなく早く顧客の手に渡ります。
スケーラビリティ
上記のように、コンテナはほんの数秒でスピンアップできます。これにより、新しいコンテナをスピンアップし、アプリケーションをスケールアウトすることで、需要の増加に迅速に対応できます。アプリケーションの需要が落ち着いたら、余分なコンテナを破棄するだけです。
費用対効果
コンテナが提供する他の利点はすべて、環境でコンテナを使用したときに得られる全体的な節約に貢献します。コンテナを実行する場所を選択できるため、最も費用効果の高いホスティング環境を選択できます。フットプリントが小さく軽量であるということは、単一のサーバーでより多くのコンテナーを実行できることを意味します。同様に、アプリケーションをスケールアウトする場合、必要なサーバーは少なくなります。
テスト環境は迅速に作成できるため、不要なときにテスト環境を稼働させ続ける必要はありません。そうすることで、ソフトウェア開発ライフサイクル全体で総リソースを節約できます。
すべてをコンテナに切り替えます
すべてのアプリケーションをコンテナーに移動する必要があるように聞こえるかもしれませんが、タイトルが示すように、コンテナーはすべてのソフトウェアの問題を解決するわけではありません。
コンテナは悪いデザインや悪いコードを修正しません。
設計が不十分なモノリシックアプリケーションは、コンテナに入れるだけでは改善されません。展開は簡単かもしれませんが、コアは同じままで、設計が不適切なモノリシックアプリケーションです。改善する唯一の方法は、開発の時間と労力を介することです。コンテナは他のアプリケーションをセキュリティ違反から保護できますが、アプリケーション自体のセキュリティ違反を防ぐことはできません。
前述のように、コスト削減のかなりの部分は、上記で強調した他の利点からもたらされます。これらのメリットが減少すると、コスト削減も減少します。
いつコンテナを使用するか
コンテナは、マイクロサービスアーキテクチャの一部として使用されると、意味をなし、メリットを最大化し始めます。アプリケーションのさまざまな領域を個別にスケーリング、更新、および保守できます。このようにして、複数のチームがこれらの領域で作業し、お互いの足を踏むことなく、異なる時間にそれらを解放することができます。さらに、インフラストラクチャチームは、サーバーで実行されている多くのアプリケーションの依存関係の要件について心配する必要がなくなりました。
大企業や企業は、アプリケーションが実行されているインフラストラクチャの更新と変更が遅いことで長い間知られています。アプリケーションの依存関係がコンテナ内で統合および分離されているため、インフラストラクチャチームは、これらの依存関係を心配することなくサーバーとリソースの使用率を最大化することに集中でき、依存関係の競合を恐れることなくアプリケーションをシフトできます。
コンテナとKenticoXperience
Kentico Xperience環境をコンテナーに移行することを決定すると、新しい機会の世界が開かれます。前回の記事で説明したように、開発チームは、マシンの再構成について心配することなく、新しいプロジェクトをより迅速に立ち上げることができます。これにより、元のプロジェクトが終了した後も、チームはクライアントの要求に迅速に対応してサイトを更新できます。
Xperienceの新機能の頻度が増えるにつれ、最新バージョンへのテストと更新がより高速で信頼性が高くなり、必要に応じてすばやくロールバックできるため、お客様はこれらの機能にすばやくアクセスできるようになりました。
Webファーム環境をローカルでシミュレートできるなど、他のシナリオでは、チームは本番環境にアクセスすることなく、本番環境で行われていることをマシン上でより簡単に再現できます。
結論
コンテナが提供する計り知れないメリットを考えると、まだ検討されていない場合でも、短期的にはロードマップに含まれるはずです。そうでない場合は、この最後の考えを残しておきます。Google、YouTube、Gmail、および検索のすべてのアプリケーションは、すべてコンテナで実行されます。多分それは変更を検討し始める時です。