AzureArcを理解する

Microsoftの2019Ignite会議でのより興味深い発表の1つは、ハイブリッドクラウドアプリケーションインフラストラクチャの新しい管理ツールであるAzureArcでした。Arcは、Azureの概念に基づいて構築されており、Azure Portalからオンプレミスのリソースを管理し、ポリシーとサービスを仮想マシンとKubernetesにデプロイできるように設計されています。また、AzureのSQLデータベースとPostgreSQL Hyperscaleのコンテナ化されたバージョンが含まれており、KubernetesベースのハイブリッドアプリケーションにAzure整合性のあるデータオプションを提供します。

Azure Arcは、Azure ResourceManagerモデルをサーバーとKubernetesクラスターにまで拡張します。どこにいてもクラウドのようにリソースを管理するように設計されており、Azureのリソースツールをコントロールプレーンとして扱います。これにより、ほとんどの管理ツールよりもはるかに高いレベルになります。たとえば、Windows Serverネットワークで実行されている仮想マシンで使用している場合は、Hyper-V管理ツールを使用してVMを管理し、AzureArcを使用してVMで実行されているサーバー構成とアプリケーションを管理します。

サーバーでのAzureArcの使用

「どこにいても」は、AzureArcの背後にある重要な原則です。アプリケーション管理に重点を置いているため、インフラストラクチャに依存しません。管理するVMは、データセンター、ホスティング施設、または管理された共有環境の仮想サーバーとして実行できます。

Azure Arcを使用したサーバー管理が公開プレビューになり、WindowsおよびLinux用の接続されたマシンエージェントがAzureArcサービスへの接続を処理します。クラウドに接続すると、リソースグループの一部であるAzureリソースであるかのようにクラウドの管理を開始できます。これにより、PowerShellベースのポリシーを接続されたサーバーに展開し、ジャストインタイム管理と目的の状態構成を提供するために行われた作業を活用できます。管理対象サーバーには、SSLを介したAzureArcへの接続が必要です。

Azure Arcによって管理されるサーバーは、物理サーバーである必要はありません。それらは仮想マシンにすることができます。これにより、エージェントをデプロイする前に、エージェントをVMベースイメージにプリロードできます。サービスのセットアップの一環として、Azure Arcは、Azureに接続してサーバーをリソースとして追加する前に、接続されていないサーバーで実行されるカスタムスクリプトを生成し、エージェントをダウンロードしてインストールします。

AzureArcでのKubernetesアプリケーションの管理

Microsoftは、AzureArcのKubernetesサポートをパブリックプレビューで利用できるようにしていません。それでも、サービスのプライベートアクセスプレビューに制限されています。ただし、Azure ApplicationPlatformの製品ディレクターであるGabeMonroyは、Igniteで短いデモンストレーションを行いました。

Monroyは、Azure Portalを使用して、AzureARMベースのポリシーを使用して管理されている実行中のKubernetesクラスターを最初に示しました。彼が使用した最初のポリシーは、クラスターが使用するネットワークポートを制御し、不要なポートをロックダウンしてクラスターの攻撃対象領域を減らしました。同じポリシーを使用して、企業のグローバルインフラストラクチャ全体のすべてのクラスターを管理できます。ポリシーを一度作成し、このように何度も使用することで、エラーのリスクを最小限に抑えることができます。すべてのポリシーを事前にテストすることで、グローバルに展開したときにポリシーが機能することを確認できます。

ポリシーベースのアプローチのもう1つの利点は、クラスターが準拠していない場合にクラスターをロックダウンできることです。クラスターがすべてのポリシーに準拠していることを報告するまで、アプリケーション開発チームはコードをデプロイできません。ネットワーク内のすべてのKubernetesクラスターにAzureArcエージェントをデプロイすると、すべてのポリシーとすべてのデプロイを管理するための1つのペインができます。

物理サーバーとKubernetesのインストールを直接管理する方法がないことに注意することが重要です。 Azure Portalが提供するのは、クラスターで実行されているポリシーとコードだけです。ポリシーを使用してクラスターの動作を定義できますが、KubernetesランタイムとAzureArcエージェントがインストールされていない限り新しいノードをデプロイすることはできません。新しいクラスターがデプロイされてAzureArcに接続されるとすぐに、ポリシーが自動的に適用され、すべてを手動で構成しなくてもセキュリティポリシーが適切に適用されるようになります。

デモンストレーションの興味深い側面の1つは、Azure ArcをGitHubに接続し、Kubernetes名前空間またはクラスターのいずれかを対象とし、特定のリポジトリからのデプロイを処理するポリシーでした。このポリシーを使用すると、リポジトリへのプルリクエストは、更新されたアプリケーションのデプロイをトリガーします。同じポリシーを使用して、構成後すぐに新しいクラスターにコードをロードできます。コードの将来の更新は自動的に展開され、すべてのサイトで最新バージョンが実行されたままになります。

KubernetesとAzureArcエージェントがプリロードされた新しいサーバーのセットが、新しいエッジサイトに配信されることは容易に想像できます。WANに接続して電源を入れると、最新のポリシーが自動的に読み込まれ、準拠すると、アプリケーションがダウンロードされ、最小限の人的操作で操作が開始されます。

新しいクラウド中心のアプリファースト管理モデルの導入

Azure Arcは、特にグローバルネットワーク全体でのアプリケーションの展開を自動化するために使用される場合は、新世代のポリシー駆動型アプリケーション管理ツールの最初のものと考えるのがおそらく最善です。それをgitopsフローに統合することは理にかなっています。プルリクエストがマージされたときに、Arcを使用してアプリケーションのデプロイをトリガーし、ホストのKubernetesクラスターまたは仮想マシンに適切なセキュリティポリシーが適用されるようにします。

マイクロソフトのクラウドに対する見方は、オンプレミスシステムがなくなることはなく、エッジ展開の重要性が増すにつれて、オンプレミスの定義が増えるだけであるというものです。これは、オンプレミスシステムがそうすべきではないという意味ではありません。クラウドテクノロジーやクラウドに基づいた作業方法の恩恵を受けません。Azure Arcは、セキュリティコンプライアンスを確保するためのポリシーを使用して、アプリケーションのインフラストラクチャを自動化することに重点を置いています。

あなたがそれについて考えるとき、これはdevopsの論理的な拡張であり、クラウド環境の管理の第3層への移行の一部です。Azure Arcは、VMベースかコンテナベースかに関係なく、アプリケーション仮想インフラストラクチャに重点を置いて、アプリケーション操作をインフラストラクチャ操作から分離しています。

ハイブリッドクラウド環境では、アプリケーションチームが基盤となる物理インフラストラクチャについて何も知る必要はありません。代わりに、別のチームが物理サーバー、ホストオペレーティングシステム、ハイパーバイザー、Kubernetesのインストールを担当し、アプリケーションチームがエッジ、ハイパーコンバージドシステム、従来のデータセンターなどでアプリケーションを管理するためにAzureArcなどのツールを使用します。クラウド、すべて同じクラウドホストコンソールから。

コンテナーと仮想化を使用してインフラストラクチャを実行する方法、およびdevopsを使用してアプリケーションを構築および管理する方法を変更しました。2つのアプローチをまとめるためのツールを提供してみませんか?Azure Arcを使用すると、devops方程式のops側は、アプリケーションをインフラストラクチャから分離するためのプラットフォームを取得し、クラウドでホストされる新しいコントロールプレーンからそれらのアプリケーションを管理および制御する機能を備えています。これは魅力的なビジョンであり、Microsoftがどのようにそれを提供するかを見るのは興味深いでしょう。