コードとしてのインフラストラクチャー

多くの組織は、コードベースの定義 (多くの場合に IaC (Infrastructure as code) と呼ばれます) を用いた IT インフラストラクチャーをデプロイすることの検討を始めるか、すでに実際の適用を開始しています。 通常、このプロセスには次の手順が含まれます。

  1. CloudFormation、Terraform、ARM テンプレート、Bicep などの自動化用言語を選択します。
  2. 仮想ネットワークの構成、仮想マシンの仕様、受信ロード バランサーやリバース プロキシーなど、さまざまなインフラストラクチャー設定を定義します。
  3. 手動で起動したツールまたはその他の自動化プロセスから、その環境の「ビルド」を実行します。

IaC によるデプロイの結果として得られるリソース群は、個別に構成と設定を選択して手動でデプロイすることも可能です。しかし、IaC を用いれば、高い一貫性を保って自動的に再デプロイしたり、新たな仕様に合わせて微調整することができます。

ArcGIS は一般に、多くの IaC 手法やシステムと互換性があり、これらは多くの場合、AWS CloudFormation、Azure ARM テンプレート、GCP Cloud Deployment Manager など、特定のクラウド環境またはシステム内で動作するように設計されています。 また、Esri は特定のプロバイダー、特に AWS CloudFormation テンプレートと Azure ARM テンプレート用のツールも構築しており、これらのツールを今後の構成や拡張の基盤として使用できます。

IaC プロバイダーまたはツールを使用してインフラストラクチャーがデプロイされてから、ArcGIS ソフトウェアを手動または自動でこれらのシステムにデプロイできます。 詳細については、ArcGIS ソフトウェアのデプロイメントの自動化をご参照ください。

一部の IaC パターンは、頻繁に変更がインフラストラクチャーにプッシュされるか、そのコードが変更されるたび、頻繁にデプロイするように設計されています。 ArcGIS Pro と ArcGIS Enterprise はどちらも比較的安定して一貫性のあるネットワークおよびインフラストラクチャー環境に依存しているため、このパターンを ArcGIS システムに合わせるのが難しい場合があります。 したがって、IaC の変更が必要な場合は、エンタープライズ IT システムに変更を進めるときは常にそうであるように、これらの変更を慎重に進めるか (計画、テスト、レビュー、調整)、またはこれらのシステムを、ソフトウェア デプロイメントの自動化を可能にする他の DevOps スタイルのツールと組み合わせて、システム全体を定期的な頻度で再構築およびデプロイできるようにすることをお勧めします。

IaC と ArcGIS

コードとしてのインフラストラクチャーを ArcGIS を併用する際の追加推奨事項:

  • IaC は、インフラストラクチャーとベースライン構成を維持するには優れたツールですが、システム状態の維持には適していません。 ArcGIS システムの「状態」には、ユーザー、アイテム、コンテンツ、サービス、およびデータが含まれます。 IaC により適切な「ハードウェア」の準備とソフトウェアのインストールは行えますが、システム状態の復元は複雑で時間がかかることがあります。
  • IaC を使用してプロジェクトの早い段階で、または新しい環境用にハードウェアをデプロイすることは、既存の環境の更新を試みるよりも簡単です。 更新により、ネットワーク構成、コンピューターの名前付け、ストレージまたはファイアウォールのルール、またはソフトウェアが依存する他の条件が調整される場合があり、ソフトウェアがその変更を認識していない、または準備ができていない場合、これらのインフラストラクチャー レベルの変更によって不安定な状態や、サービスの中断が引き起こされる可能性があります。 動作中の ArcGIS システムを車にたとえると、運転中にタイヤを交換したり、エンジンが動いている間にガソリンからディーゼルに交換するようなことは期待できません。
  • 他の IaC 言語またはプロバイダーも、多くの場合は ArcGIS と互換性があります。 一般に、可能な IaC 手法を検討するときは、ハードウェアとインフラストラクチャーに必要な手動の構成手順を検討し、それらをシーケンシャルに自動化することを試みて、それが完了したらソフトウェアのデプロイと構成に進みます。

DevOps、CI/CD、および ArcGIS

DevOps という用語は、一般にコードドリブンのデプロイメント ワークフローを指します。これは、コミットやリリースによって何かが自動的にデプロイされ、以前存在していたものに置き換わります。 この領域で使用される他の用語には、継続的インテグレーション (CI) や、継続的デプロイ (CD) があり、多くの場合、CI/CD として組み合わされます。 これらの用語は、ソフトウェア エンジニアリングの世界と、アプリケーションの開発およびカスタム ソフトウェア アプリケーションの構築から来ており、ソフトウェアのリリースをサポートするに、継続的なデプロイとテストが行われます。

ArcGIS は商用の既製ソフトウェア パッケージなので、多くの組織がカスタム アプリケーションの開発に CI/CD や DevOps を現在使用している方法とは多少異なります。 ArcGIS がデプロイされると、ArcGIS Enterprise では状態や構成 (ポータル コンテンツ、サービス、ユーザー コンテンツ、構成) の作成が開始されます。 ArcGIS Enterprise または新しい ArcGIS Online 組織を再デプロイすると、バックアップが復元されない限り、既存の状態が破棄されるため、作成した内容を表示できなくなります。

DevOps を ArcGIS システムで適切に使用するには、組織は次のいずれかを行う必要があります。

  • 固定されたコンテンツ セットや慎重に管理されたコンテンツを使用して、非常に厳格なデプロイメントを維持します。このデプロイメントは、「空白」のシステムから自動的にデプロイできます。 たとえば、ファイル ベースのデータの静的セットを含む単一のビューアー アプリケーションを、Web サービスの自動公開や更新も含めて、夜間にデプロイできます。
  • WebGISDR などを使用して状態を抽出し、システム コンポーネントと基本構成を再デプロイしたうえで、状態を再デプロイする、信頼性の高い方法を特定します。
Top