DevOps パターン

  • [アーティクル]

1 つの場所からコードを作成して、ローカル データセンター、プライベート クラウド、またはパブリック クラウドに存在する可能性がある開発環境、テスト環境、運用環境内の複数のターゲットにデプロイします。

コンテキストと問題

アプリケーション デプロイの継続性、セキュリティ、および信頼性は、組織にとって非常に重要であり、開発チームにも欠かせません。

アプリでは、多くの場合、ターゲット環境ごとにリファクタリングされたコードを実行する必要があります。 これは、アプリが完全に移植可能ではないことを意味します。 環境が変わるたびに更新、テスト、および検証を行う必要があります。 たとえば、開発環境で記述したコードは、テスト環境で動作するように書き直す必要があり、最終的に運用環境に配置するときにも書き直す必要があります。 さらに、このコードは特にホストに関連付けられます。 これにより、アプリの保守のコストと複雑さが増加します。 アプリの各バージョンは、各環境に関連付けられます。 複雑さと重複が増加すると、セキュリティとコード品質のリスクが高まります。 また、復元に失敗したホストを削除したり、需要の増加に対応するために追加のホストをデプロイしたりするときに、コードを簡単に再デプロイできません。

ソリューション

DevOps パターンを使用すると、複数のクラウドで実行されるアプリをビルド、テスト、およびデプロイできます。 このパターンは、継続的インテグレーションと継続的デリバリーのプラクティスを統合したものです。 継続的インテグレーションにより、チーム メンバーがバージョン コントロールに変更をコミットするたびにコードがビルドおよびテストされます。 継続的デリバリーでは、ビルドから運用環境までの各手順が自動化されます。 これらのプロセスが合わさって、多様な環境にまたがったデプロイをサポートするリリース プロセスになります。 このパターンでは、コードのドラフトを記述して、同じコードを構内環境、さまざまなプライベート クラウド、およびパブリック クラウドにデプロイできます。 環境の違いに合わせて、コードを変更するのではなく構成ファイルを変更する必要があります。

DevOps pattern

オンプレミス、プライベート クラウド、パブリック クラウドの各環境にわたって一貫した開発ツールのセットを使用して、継続的インテグレーションと継続的デリバリーのプラクティスを実装することができます。 DevOps パターンを使用してデプロイしたアプリとサービスは、交換可能で、これらの場所のどこでも実行でき、オンプレミスとパブリック クラウドの機能を活用できます。

DevOps リリース パイプラインを使用すると、次のことができます。

  • 単一リポジトリへのコード コミットに基づいて、新しいビルドを開始します。
  • ユーザー受け入れテストのため、新しくビルドされたコードをパブリック クラウドに自動的にデプロイします。
  • コードがテストに合格したら、自動的にプライベート クラウドにデプロイします。

問題と注意事項

DevOps パターンは、ターゲット環境に関係なく、デプロイ間の一貫性を確保することを目的としています。 ただし、機能は、クラウド環境とオンプレミス環境で異なります。 次の点を考慮してください。

  • デプロイ内の関数、エンドポイント、サービス、その他のリソースはデプロイ先の場所で利用できますか?
  • 構成成果物は、クラウドをまたいでアクセスできる場所に格納されていますか?
  • デプロイ パラメーターはすべてのターゲット環境で機能しますか?
  • リソース固有のプロパティはすべてのターゲット クラウドで使用できますか?

詳細については、「クラウドの一貫性のための Azure Resource Manager テンプレートを開発する」を参照してください。

また、このパターンの実装方法を決めるときには、以下の点に注意してください。

スケーラビリティ

デプロイ自動化システムは、DevOps パターンの主要な制御ポイントです。 実装は異なる可能性があります。 適切なサーバー サイズの選択は、予想されるワークロードのサイズによって異なります。 VM の方がコンテナーよりスケーリングのコストが高くなります。 ただし、スケーリングのためにコンテナーを使用するには、コンテナーでビルド プロセスを実行する必要があります。

可用性

DevPattern のコンテキストにおける可用性とは、ワークフローに関連付けられているすべての状態情報 (テスト結果など)、コードの依存関係、または他の成果物を復旧できることを意味します。 可用性の要件を評価するには、次の 2 つの一般的なメトリックを検討します。

  • 目標復旧時間 (RTO) は、システムなしで継続できる時間を示します。

  • 目標復旧時点 (RPO) は、サービスの中断がシステムに影響を及ぼす場合に、失われても差し支えないデータの量を示します。

実際には、RTO と RPO は冗長性とバックアップを意味します。 グローバル Azure クラウドでは、可用性は、Azure の一部であるハードウェアの復旧の問題ではなく、DevOps システムの状態を確実に維持することを表します。 Azure Stack Hub では、ハードウェアの復旧について考慮することが必要になる場合があります。

デプロイの自動化に使用されるシステムを設計する際のもう 1 つの重要な考慮事項は、アクセス制御と、クラウド環境へのサービスのデプロイに必要な権限の適切な管理です。 デプロイを作成、削除、または変更するには、どのような権限が必要ですか? たとえば、通常、Azure でリソース グループを作成するために必要な権限のセットと、リソース グループにサービスをデプロイするために必要な権限のセットは別のものです。

管理の容易性

DevOps パターンに基づいたシステムの設計では、各サービスの自動化、ログ記録、アラートをポートフォリオ全体で考慮する必要があります。 共有サービス、アプリケーション チーム、またはその両方を使用します。また、セキュリティ ポリシーとガバナンスも追跡します。

運用環境と開発/テスト環境を、Azure または Azure Stack Hub 上の別々のリソース グループにデプロイします。 その後、各環境のリソースを監視し、リソース グループ別に課金コストをロール アップすることができます。 セットとしてリソースを削除することもできます。これはテスト デプロイの場合に便利です。

このパターンを使用する状況

このパターンは次の状況で使用します。

  • コードを、開発者のニーズを満たす環境で開発し、新しいコードの開発が困難な可能性があるソリューション固有の環境にデプロイできる場合。
  • DevOps パターンの継続的インテグレーションと継続的デリバリーのプロセスに従うことができる限り、開発者が希望するコードとツールを使用できる場合。

このパターンは次の場合は推奨されません。

  • インフラストラクチャ、リソースのプロビジョニング、構成、ID、およびセキュリティ タスクを自動化できない場合。
  • チームで継続的インテグレーション/継続的開発 (CI/CD) アプローチを実装するためにハイブリッド クラウド リソースにアクセスできない場合。

次のステップ

この記事で紹介したトピックの関連情報:

ソリューションの例をテストする準備ができたら、DevOps ハイブリッド CI/CD のソリューション デプロイ ガイドに進んでください。 デプロイ ガイドでは、コンポーネントをデプロイしてテストするための詳細な手順について説明します。 ハイブリッドの継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインを使用して Azure と Azure Stack Hub にアプリをデプロイする方法を学習します。