インフラストラクチャを自動化する方法

インフラストラクチャの自動化はコンテナ以前の一時的な解決策であったと考える人もいます。しかし今日では、IT 部門はそれを実現できます。

[[378951]]

標準化と自動化は、IT 業界においては新しい概念ではありません。では、なぜ最近、インフラストラクチャの自動化が注目されているのでしょうか?

答えは、コンテナ、オーケストレーション、その他の最新テクノロジーによってインフラストラクチャの自動化機能が拡張され、標準化などの利点がもたらされたことです。

Red Hat の CTO である Gordon Haff 氏は、次のように説明しています。「コンテナが登場する前は、インフラストラクチャの標準化とその自動化は一時的な対策だったと言えるでしょう。もちろん、組織には標準オペレーティング環境 (SOE) と、それらの SOE の構成と継続的な監視を自動化できる構成管理ツールがありました。しかし、特定のタスクを実行するには依然として多くのサーバーが必要であり、構成管理ソフトウェアが準拠を維持しようとしたとしても、展開されたコンテナ イメージは時間の経過とともに変化していました。」

効果的なインフラストラクチャ自動化の長年にわたる探求において、コンテナ化とオーケストレーションがその取り組みに新たな息吹を吹き込んだと彼は指摘した。

現代のインフラ自動化の3つの基本

ここでは、クラウドネイティブ テクノロジー (ハイブリッドまたはマルチクラウド シナリオ向け) を使用したインフラストラクチャ自動化への新しいアプローチの概念をまだ理解しつつある IT リーダーとチーム向けに、最新のインフラストラクチャ自動化の 3 つの基礎と、開始するためのヒントを紹介します。

（１）主要概念：コンテナとオーケストレーション

クラウド ネイティブ エコシステムはすでに巨大 (そしてまだ成長中) ですが、このコンテキストでインフラストラクチャの自動化について話すときに注目すべき主な領域は、コンテナと Kubernetes の 2 つです。コンテナ ランタイムとオーケストレーション オプションは複数ありますが、後者については、Kubernetes をデフォルトの選択肢として使用します。これは、Kubernetes が、現代のインフラストラクチャ自動化に不可欠なコンポーネントであるコンテナ オーケストレーションの明確なリーダーとなっているためです。

• 変わらないインフラ

これらのクラウド中心のテクノロジーは、Haff 氏が先に述べた不変のインフラストラクチャへの道を開きます。つまり、インフラストラクチャが一度導入されると、運用環境では変更されず、必要に応じて新しいバージョンに置き換えられます。また、この機能は Kubernetes などのツールを使用して自動的に開始 (またはシャットダウン) できるため、管理者はアプリケーションとインフラストラクチャの望ましい状態を宣言でき、その後、オーケストレーション プラットフォームが高度に自動化された方法でこれらの状態を管理します。

• マイクロサービスアーキテクチャ

ここでのもう 1 つの重要な概念はマイクロサービス アーキテクチャです。これは基本的に、アプリケーションを、より大きなシステムの一部として連携して動作できる小さな個別のコンポーネントに分割することを意味します。マイクロサービスには、他にもさまざまな利点がありますが、変更が行われるたびにアプリケーション全体を再入力 (および再デプロイ) する必要なく、チームが小規模なサービスを個別に管理できるという利点があります。マイクロサービスは、各サービスを個別にコンテナ化できるため、コンテナに最適です。すべてのアプリケーションがマイクロサービス アーキテクチャに適しているわけではないことに注意してください。ただし、それは問題ではありません。

次のようなアドバイスをする人もいます: 組織が単一のアプリケーション ポートフォリオから始める場合は、インフラストラクチャの自動化を短期プロジェクトとして考えないでください。代わりに、特に組織が既存のアプリケーションをマイクロサービスに分割している場合は、これを断片的なプロセスとして考えます。

「不変のインフラストラクチャへの道は、コンテナベースのアプリケーションの普及と導入以前に開発されたアプリケーションを持つ組織にとっては特に、時間がかかるかもしれません」と、OpsRamp のプロダクト マネージャーである Michael Fisher 氏は述べています。 「ただし、これは、アプリケーションが分離されたマイクロ フロントエンドとバックエンドで実行されるように構成されるまで、アーキテクチャの計画と開発が停止することを意味するものではありません。チームは、アプリケーション全体が変換されるまで、反復的にサービスの優先順位付けとコンテナ化を行う必要があります。」

インフラストラクチャ自動化への最新のアプローチは、クラウド プラットフォームとツールへの対応する移行に依存します。しかし、それは一夜にして達成できるものではありません。

フィッシャー氏は、この段階を単なる​​技術的なものではなく、イノベーションのプロセスと捉えていると述べた。「コンテナ化とは何かを理解するには、アプリケーションのコアサービスと構成要素を理解する必要がある」

特に組織がアプリケーション (または複数のアプリケーション) をマイクロサービスにリファクタリングする場合、コンテナ化への正しい道筋についてはさまざまな意見があります。

「これを行う最良の方法の 1 つは、エンド ユーザーが UI/UX 内で最も頻繁にアクセスする場所を把握し、そこから下に移動することです」とフィッシャー氏は述べています。 「このアプローチはしばしば『マイクロ フロントエンド』と呼ばれます。コンテナ化する必要があるものがわかれば、組織がサービスを実行するインフラストラクチャをスケールアウトするのに役立つツールは数多くあり、その中でも Kubernetes が最も人気があります。」

（２）主要概念：継続的インテグレーション（CI）/継続的デリバリー（CD）、ビルドパイプライン、ビルド成果物

組織が適切なワークロードをコンテナ化し、Kubernetes を学習したり、商用の Kubernetes プラットフォームを使用したりし始めたとしても、やるべきことはまだたくさんあります。

不変のインフラストラクチャの場合、サーバーなどの従来の用語は技術的にはまだ関連性があるものの、使用をやめる必要があります。代わりに、組織はビルド パイプラインと、その方程式のもう一方の側面であるビルド アーティファクトについて考え始める必要があります。これは、組織が不変のインフラストラクチャを自動的に導入、廃止、または置き換えるものです。

この点において、継続的インテグレーション (CI)/継続的デリバリー (CD) が重要な実践およびツールとなっています。ビルド フェーズは、本質的に強力な継続的インテグレーション (CI) / 継続的デリバリー (CD) パイプラインの基盤となります。

一般的に、パイプラインの概念は、インフラストラクチャの自動化について考える上で便利な方法です。パイプラインが導入されると、組織のコードと、コードが正しく実行されるために必要なすべてのものが、パイプラインのすべての段階 (ビルドからテスト、セキュリティ、展開まで) を通過し、組織によって指定された手順、または何かが標準を満たしていない場合にのみ、人間が積極的に関与することになります。

基本的に、継続的インテグレーション (CI)/継続的デリバリー (CD) パイプラインは、コンテナ化されたアプリケーションをコードからリポジトリまたは本番環境に、人手をあまりかけずに取り込む方法です。

Snow Software のチーフ インフラストラクチャ アーキテクトである Jesse Stockall が、コンテナ化されたアプリケーションと不変のインフラストラクチャを管理するための重要なアプローチについて説明します。これらのアプローチはすべて、標準オペレーティング環境 (SOE) でも起こり得る転用をコンテナとオーケストレーションがどのように防止できるかを示しています。

「コンテナ イメージは、プライベート イメージ リポジトリをビルド出力として使用する、繰り返し可能な自動ビルド パイプラインを使用して、信頼できるベース コンテナから構築する必要があります」と Stockall 氏は述べています。 「より細かく制御するために、ベース イメージをプライベート レジストリにコピーし、パブリック レジストリへのアクセスをブロックすることもできます。ビルド システムは、ベース イメージの新しいバージョンが利用可能になったことを検出して、変更を確認してイメージ構成を更新できるようにする必要があります。」

CI/CD パイプラインのその他の重要な要素には、テストと検証/コンプライアンスが含まれます。適切に実行されれば、セキュリティはあらゆる段階で不可欠なものになります。

「コンテナレジストリは、既知の脆弱なソフトウェアをスキャンし、不正なイメージがアップロードされるのをブロックする必要がある」とストックオール氏は述べた。 「イメージ構成とデプロイメント マニフェストの静的分析を使用して、ベース イメージのバージョンの欠落やデプロイメントのリソース制限など、一般的な構成ミスや省略を検出する必要があります。」

（３）キーコンセプト：クラウドネイティブツール

いくつかの原則は同じままですが、単一のツールとプロセスでは、インフラストラクチャの自動化に関して組織が望む成果を必ずしも得られるとは限りません。

これはセキュリティに少し似ています。組織が 10 年前に実行していたのと同じ境界ファイアウォールとエンドポイント ウイルス対策ソフトウェアを使用していて、まったく更新していない場合は、問題ありません。

インフラについても同様です。今日、ますます多くの組織が、クラウドネイティブ開発と、プライベートクラウドやオンプレミスのインフラストラクチャに適した多くのワークロードの両方に対処するためにハイブリッドクラウドを使用しています。そして、組織がこれらすべてを管理するのに役立つ洗練されたツールが数多くあります。

「この大きな変化は、インフラ自動化の再考につながった」とハフ氏は語った。 「Kubernetes はコンテナ オーケストレーションの標準になりました。これにより、コンテナ化された世界向けに特別に設計されたさまざまな自動化ツールが生まれました。」

「エコシステム」という用語は、テクノロジーの世界では緩く使われる傾向があります。しかし、クラウド コンピューティングの時代では、構築からセキュリティ、展開に至るまで、特にオープン ソースの場合、1 つのプロジェクトまたはプラットフォームが他のプロジェクトまたはプラットフォームに依存します。これにより、インフラストラクチャの自動化に「雪だるま式」効果が生まれます。

「CI/CD 分野のプロジェクトでは、ビルドおよびデプロイメント パイプライン用の Kubernetes ネイティブの開発パターンとプロセスを検討しています」と Haff 氏は述べています。 「これには、Tekton Pipelines や、Argo CD や Keptn などのデプロイメント自動化に特化した新しいプロジェクトが含まれます。組織では、この比較的新しいインフラストラクチャに最適化された Aqua や Snyk などの新しいセキュリティ ツールも数多く採用しています。」