DevOps パターンDevOps pattern

1 つの場所からコードを作成して、ローカル データセンター、プライベート クラウド、またはパブリック クラウドに存在する可能性がある開発環境、テスト環境、運用環境内の複数のターゲットにデプロイします。Code from a single location and deploy to multiple targets in development, test, and production environments that may be in your local datacenter, private clouds, or the public cloud.

コンテキストと問題Context and problem

アプリケーション デプロイの継続性、セキュリティ、および信頼性は、組織にとって非常に重要であり、開発チームにも欠かせません。Application deployment continuity, security, and reliability are essential to organizations and critical to development teams.

アプリでは、多くの場合、ターゲット環境ごとにリファクタリングされたコードを実行する必要があります。Apps often require refactored code to run in each target environment. これは、アプリが完全に移植可能ではないことを意味します。This means that an app isn't completely portable. 環境が変わるたびに更新、テスト、および検証を行う必要があります。It must be updated, tested, and validated as it moves through each environment. たとえば、開発環境で記述したコードは、テスト環境で動作するように書き直す必要があり、最終的に運用環境に配置するときにも書き直す必要があります。For example, code written in a development environment must then be rewritten to work in a test environment and rewritten when it finally lands in a production environment. さらに、このコードは特にホストに関連付けられます。Furthermore, this code is specifically tied to the host. これにより、アプリの保守のコストと複雑さが増加します。This increases the cost and complexity of maintaining your app. アプリの各バージョンは、各環境に関連付けられます。Each version of the app is tied to each environment. 複雑さと重複が増加すると、セキュリティとコード品質のリスクが高まります。The increased complexity and duplication increase the risk of security and code quality. また、復元に失敗したホストを削除したり、需要の増加に対応するために追加のホストをデプロイしたりするときに、コードを簡単に再デプロイできません。In addition, the code can't be readily redeployed when you remove restore failed hosts or deploy additional hosts to handle increases in demand.

解決策Solution

DevOps パターンを使用すると、複数のクラウドで実行されるアプリをビルド、テスト、およびデプロイできます。The DevOps Pattern enables you to build, test, and deploy an app that runs on multiple clouds. このパターンは、継続的インテグレーションと継続的デリバリーのプラクティスを統合したものです。This pattern unites the practice of continuous integration and continuous delivery. 継続的インテグレーションにより、チーム メンバーがバージョン コントロールに変更をコミットするたびにコードがビルドおよびテストされます。With continuous integration, code is built and tested every time a team member commits a change to version control. 継続的デリバリーでは、ビルドから運用環境までの各手順が自動化されます。Continuous delivery automates each step from a build to a production environment. これらのプロセスが合わさって、多様な環境にまたがったデプロイをサポートするリリース プロセスになります。Together, these processes create a release process that supports deployment across diverse environments. このパターンでは、コードのドラフトを記述して、同じコードを構内環境、さまざまなプライベート クラウド、およびパブリック クラウドにデプロイできます。With this pattern, you can draft your code and then deploy the same code to a premise environment, different private clouds, and the public clouds. 環境の違いに合わせて、コードを変更するのではなく構成ファイルを変更する必要があります。Differences in environment require a change to a configuration file rather than changes to the code.

DevOps パターン

オンプレミス、プライベート クラウド、パブリック クラウドの各環境にわたって一貫した開発ツールのセットを使用して、継続的インテグレーションと継続的デリバリーのプラクティスを実装することができます。With a consistent set of development tools across on-premises, private cloud, and public cloud environments, you can implement a practice of continuous integration and continuous delivery. DevOps パターンを使用してデプロイしたアプリとサービスは、交換可能で、これらの場所のどこでも実行でき、オンプレミスとパブリック クラウドの機能を活用できます。Apps and services deployed using the DevOps Pattern are interchangeable and can run in any of these locations, taking advantage of on-premises and public cloud features and capabilities.

DevOps リリース パイプラインを使用すると、次のことができます。Using a DevOps release pipeline helps you:

  • 単一リポジトリへのコード コミットに基づいて、新しいビルドを開始します。Initiate a new build based on code commits to a single repository.
  • ユーザー受け入れテストのため、新しくビルドされたコードをパブリック クラウドに自動的にデプロイします。Automatically deploy your newly built code to the public cloud for user acceptance testing.
  • コードがテストに合格したら、自動的にプライベート クラウドにデプロイします。Automatically deploy to a private cloud once your code has passed testing.

問題と注意事項Issues and considerations

DevOps パターンは、ターゲット環境に関係なく、デプロイ間の一貫性を確保することを目的としています。The DevOps Pattern is intended to ensure consistency across deployments regardless of the target environment. ただし、機能は、クラウド環境とオンプレミス環境で異なります。However, capabilities vary across cloud and on-premises environments. 次の点を考慮してください。Consider the following points:

  • デプロイ内の関数、エンドポイント、サービス、その他のリソースはデプロイ先の場所で利用できますか?Are the functions, endpoints, services, and other resources in your deployment available in the target deployment locations?
  • 構成成果物は、クラウドをまたいでアクセスできる場所に格納されていますか?Are configuration artifacts stored in locations that are accessible across clouds?
  • デプロイ パラメーターはすべてのターゲット環境で機能しますか?Will deployment parameters work in all the target environments?
  • リソース固有のプロパティはすべてのターゲット クラウドで使用できますか?Are resource-specific properties available in all target clouds?

詳細については、「クラウドの一貫性のための Azure Resource Manager テンプレートを開発する」を参照してください。For more information, see Develop Azure Resource Manager templates for cloud consistency.

また、このパターンの実装方法を決めるときには、以下の点に注意してください。In addition, consider the following points when deciding how to implement this pattern:

スケーラビリティScalability

デプロイ自動化システムは、DevOps パターンの主要な制御ポイントです。Deployment automation systems are the key control point in the DevOps Patterns. 実装は異なる可能性があります。Implementations can vary. 適切なサーバー サイズの選択は、予想されるワークロードのサイズによって異なります。The selection of the correct server size depends on the size of the expected workload. VM の方がコンテナーよりスケーリングのコストが高くなります。VMs cost more to scale than containers. ただし、スケーリングのためにコンテナーを使用するには、コンテナーでビルド プロセスを実行する必要があります。To use containers for scaling, however, your build process must run with containers.

可用性Availability

DevPattern のコンテキストにおける可用性とは、ワークフローに関連付けられているすべての状態情報 (テスト結果など)、コードの依存関係、または他の成果物を復旧できることを意味します。Availability in the context of the DevPattern means being able to recover any state information associated with your workflow, such as test results, code dependencies, or other artifacts. 可用性の要件を評価するには、次の 2 つの一般的なメトリックを検討します。To assess your availability requirements, consider two common metrics:

  • 目標復旧時間 (RTO) は、システムなしで継続できる時間を示します。Recovery Time Objective (RTO) specifies how long you can go without a system.

  • 目標復旧時点 (RPO) は、サービスの中断がシステムに影響を及ぼす場合に、失われても差し支えないデータの量を示します。Recovery Point Objective (RPO) indicates how much data you can afford to lose if a disruption in service affects the system.

実際には、RTO と RPO は冗長性とバックアップを意味します。In practice, RTO, and RPO imply redundancy and backup. グローバル Azure クラウドでは、可用性は、Azure の一部であるハードウェアの復旧の問題ではなく、DevOps システムの状態を確実に維持することを表します。On the global Azure cloud, availability isn't a question of hardware recovery—that's part of Azure—but rather ensuring you maintain the state of your DevOps systems. Azure Stack Hub では、ハードウェアの復旧について考慮することが必要になる場合があります。On Azure Stack Hub, hardware recovery may be a consideration.

デプロイの自動化に使用されるシステムを設計する際のもう 1 つの重要な考慮事項は、アクセス制御と、クラウド環境へのサービスのデプロイに必要な権限の適切な管理です。Another major consideration when designing the system used for deployment automation is access control and the proper management of the rights needed to deploy services to cloud environments. デプロイを作成、削除、または変更するには、どのような権限が必要ですか?What rights are needed to create, delete, or modify deployments? たとえば、通常、Azure でリソース グループを作成するために必要な権限のセットと、リソース グループにサービスをデプロイするために必要な権限のセットは別のものです。For example, one set of rights is typically required to create a resource group in Azure and another to deploy services in the resource group.

管理の容易性Manageability

DevOps パターンに基づいたシステムの設計では、各サービスの自動化、ログ記録、アラートをポートフォリオ全体で考慮する必要があります。The design of any system based on the DevOps pattern must consider automation, logging, and alerting for each service across the portfolio. 共有サービス、アプリケーション チーム、またはその両方を使用します。また、セキュリティ ポリシーとガバナンスも追跡します。Use shared services, an application team, or both, and track security policies and governance as well.

運用環境と開発/テスト環境を、Azure または Azure Stack Hub 上の別々のリソース グループにデプロイします。Deploy production environments and development/test environments in separate resource groups on Azure or Azure Stack Hub. その後、各環境のリソースを監視し、リソース グループ別に課金コストをロール アップすることができます。Then you can monitor each environment's resources and roll up billing costs by resource group. セットとしてリソースを削除することもできます。これはテスト デプロイの場合に便利です。You can also delete resources as a set, which is useful for test deployments.

このパターンを使用する状況When to use this pattern

このパターンは次の状況で使用します。Use this pattern if:

  • コードを、開発者のニーズを満たす環境で開発し、新しいコードの開発が困難な可能性があるソリューション固有の環境にデプロイできる場合。You can develop code in one environment that meets the needs of your developers, and deploy to an environment specific to your solution where it may be difficult to develop new code.
  • DevOps パターンの継続的インテグレーションと継続的デリバリーのプロセスに従うことができる限り、開発者が希望するコードとツールを使用できる場合。You can use the code and tools your developers would like, as long as they're able to follow the continuous integration and continuous delivery process in the DevOps Pattern.

このパターンは次の場合は推奨されません。This pattern isn't recommended:

  • インフラストラクチャ、リソースのプロビジョニング、構成、ID、およびセキュリティ タスクを自動化できない場合。If you can't automate infrastructure, provisioning resources, configuration, identity, and security tasks.
  • チームで継続的インテグレーション/継続的開発 (CI/CD) アプローチを実装するためにハイブリッド クラウド リソースにアクセスできない場合。If teams don't have access to hybrid cloud resources to implement a Continuous Integration/Continuous Development (CI/CD) approach.

次のステップNext steps

この記事で紹介したトピックの関連情報:To learn more about topics introduced in this article:

ソリューションの例をテストする準備ができたら、DevOps ハイブリッド CI/CD のソリューション デプロイ ガイドに進んでください。When you're ready to test the solution example, continue with the DevOps hybrid CI/CD solution deployment guide. デプロイ ガイドでは、コンポーネントをデプロイしてテストするための詳細な手順について説明します。The deployment guide provides step-by-step instructions for deploying and testing its components. ハイブリッドの継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインを使用して Azure と Azure Stack Hub にアプリをデプロイする方法を学習します。You learn how to deploy an app to Azure and Azure Stack Hub using a hybrid continuous integration/continuous delivery (CI/CD) pipeline.