Azure Dev Spaces と共に CI/CD を使用するUse CI/CD with Azure Dev Spaces

この記事では、Dev Spaces を有効にした状態で、Azure Kubernetes Service (AKS) への継続的インテグレーション/継続的配置 (CI/CD) を設定する方法について説明します。This article guides you through setting up continuous integration/continuous deployment (CI/CD) to Azure Kubernetes Service (AKS) with Dev Spaces enabled. AKS への CI/CD によって、コミットされたコードがソース リポジトリにプッシュされるたびに、アプリの更新プログラムを自動的にデプロイすることが可能になります。CI/CD to AKS allows app updates to be automatically deployed whenever committed code is pushed to your source repository. Dev Spaces を有効にしたクラスターと組み合わせて CI/CD を利用すると、チームが操作するアプリケーションのベースラインを最新の状態に保つことができるので便利です。Using CI/CD in conjunction with a Dev Spaces enabled cluster is useful because it can keep a baseline of the application up-to-date for the team to work with.

サンプルの CI/CD の図

この記事では、Azure DevOps を使って説明していますが、Jenkins、TeamCity などの CI/CD システムにも同じ概念が適用されます。Although this article guides you with Azure DevOps, the same concepts would apply to CI/CD systems like Jenkins, TeamCity, etc.

前提条件Prerequisites

サンプル コードのダウンロードDownload sample code

時間を節約するために、サンプル コードの GitHub リポジトリのフォークを作成しましょう。For the sake of time, let's create a fork of our sample code GitHub repository. https://github.com/Azure/dev-spaces ) に移動して、 [フォーク] を選択します。Go to https://github.com/Azure/dev-spaces and select Fork. フォーク プロセスが完了すると、リポジトリのフォーク済みバージョンがローカルに複製されます。Once the fork process is complete, Clone your forked version of the repository locally. 既定で master ブランチがチェックアウトされますが、azds_updates ブランチに時間を節約するためのいくつかの変更を組み入れてあり、フォーク時にこのブランチも転送されているはずです。By default the master branch will be checked out, but we've included some time-saving changes in the azds_updates branch, which should also have been transferred during your fork. azds_updates ブランチには、Dev Spaces チュートリアルのセクション内で手動実行するように示されている更新プログラムと、CI/CD システムのデプロイを効率化するために事前作成されたいくつかの YAML および JSON ファイルが含まれています。The azds_updates branch contains updates we ask you to make manually in the Dev Spaces tutorial sections, as well as some pre-made YAML and JSON files for streamlining the deployment of the CI/CD system. git checkout -b azds_updates origin/azds_updates のようなコマンドを使用して、ローカル リポジトリに azds_updates ブランチをチェックアウトできます。You can use a command like git checkout -b azds_updates origin/azds_updates to check out the azds_updates branch in your local repository.

Dev Spaces の設定Dev Spaces setup

azds space select コマンドを使用して、dev という新しい空間を作成します。Create a new space called dev using the azds space select command. dev 空間は、コードの変更をプッシュするために、CI/CD パイプラインによって使用されます。The dev space will be used by your CI/CD pipeline to push your code changes. また、dev に基づく "子空間" を作成するためにも使用されます。It will also be used to create child spaces based on dev.

azds space select -n dev

親 dev 空間を選択するように要求されたら、" <なし> " を選択します。When prompted to select a parent dev space, select <none>.

自分の開発スペースが作成された後は、ホストのサフィックスを確認する必要があります。After your dev space has been created, you need to determine the host suffix. Azure Dev Spaces イングレス コントローラーのホスト サフィックスを表示するには、azds show-context コマンドを使用します。Use the azds show-context command to show the host suffix of the Azure Dev Spaces Ingress Controller.

$ azds show-context
Name   ResourceGroup    DevSpace  HostSuffix
-----  ---------------  --------  ----------------------
MyAKS  MyResourceGroup  dev       fedcba098.eus.azds.io

上の例では、ホスト サフィックスは fedcba098.eus.azds.io です。In the above example, the host suffix is fedcba098.eus.azds.io. この値は、後でリリース定義を作成するときに使用します。This value is used later when creating your release definition.

開発者が dev から "子空間" を作成して大規模なアプリのコンテキスト内にある分離された変更をテストできるように、dev 空間には常に最新状態のリポジトリが含まれます。The dev space will always contain the latest state of the repository, a baseline, so that developers can create child spaces from dev to test their isolated changes within the context of the larger app. この概念については、Dev Spaces のチュートリアルで詳しく説明しています。This concept is discussed in more detail in the Dev Spaces tutorials.

ビルド定義の作成Creating the build definition

Web ブラウザーで Azure DevOps チーム プロジェクトを開き、" [パイプライン] " セクションに移動します。Open your Azure DevOps team project in a web browser and navigate to the Pipelines section. 最初に、Azure DevOps サイトの右上にあるプロファイル写真をクリックして、[プレビュー機能] ウィンドウを開き、" [YAML パイプライン作成の新しいエクスペリエンス] " を無効にします。First, click on your profile photo in the upper right of the Azure DevOps site, open the preview features pane, and disable the New YAML pipeline creation experience:

[プレビュー機能] ウィンドウを開く

無効にするオプション:The option to disable:

[YAML パイプライン作成の新しいエクスペリエンス] オプション

注意

Azure DevOps の "YAML パイプライン作成の新しいエクスペリエンス" プレビュー機能は、この時点では、事前定義されたビルド パイプラインの作成と競合します。The Azure DevOps New YAML pipeline creation experience preview feature conflicts with creating pre-defined build pipelines at this time. 事前定義されたビルド パイプラインをデプロイするために、今は無効にしておく必要があります。You need to disable it for now in order to deploy our pre-defined build pipeline.

azds_updates ブランチには、mywebapi および webfrontend に必要なビルド手順を定義した簡単な Azure パイプラインの YAML を組み込んでいます。In the azds_updates branch we've included a simple Azure Pipeline YAML that defines the build steps required for mywebapi and webfrontend.

選択した言語に応じて、パイプラインの YAML は samples/dotnetcore/getting-started/azure-pipelines.dotnetcore.yml と類似のパスにチェックインされています。Depending on the language you've chosen, the pipeline YAML has been checked-in at a path similar to: samples/dotnetcore/getting-started/azure-pipelines.dotnetcore.yml

このファイルからパイプラインを作成するには:To create a Pipeline from this file:

  1. DevOps プロジェクトのメイン ページ上で、[パイプライン] > [ビルド] の順に移動します。On your DevOps project main page, navigate to Pipelines > Builds.
  2. 新しいビルド パイプラインを作成するオプションを選択します。Select the option to create a New build pipeline.
  3. ソースとして [GitHub] を選択し、必要に応じて自分の GitHub アカウントを使って承認して、dev-spaces のサンプル アプリケーション リポジトリのフォーク済みバージョンから azds_updates ブランチを選択します。Select GitHub as the source, authorize with your GitHub account if necessary, and select the azds_updates branch from your forked version of the dev-spaces sample application repository.
  4. テンプレートとして、 [コードとしての構成] または [YAML] を選択します。Select Configuration as code, or YAML, as your template.
  5. この時点で、ビルド パイプラインの構成ページが表示されています。You are now presented with a configuration page for your build pipeline. 前述したように、 [...] ボタンを使用して [YAML ファイル パス] の言語固有パスに移動します。As mentioned above navigate to the language-specific path for the YAML file path using the ... button. たとえば、「 samples/dotnetcore/getting-started/azure-pipelines.dotnet.yml 」のように入力します。For example, samples/dotnetcore/getting-started/azure-pipelines.dotnet.yml.
  6. [変数] タブに移動します。Go to the Variables tab.
  7. dockerId を変数として手動で追加します。Azure Container Registry 管理者アカウントのユーザー名ですManually add dockerId as a variable, which is the username of your Azure Container Registry administrator account. (記事の「前提条件」に記載されています)。(Mentioned in the article prerequisites)
  8. dockerPassword を変数として手動で追加します。Azure Container Registry 管理者アカウントのパスワードです。Manually add dockerPassword as a variable, which is the password of your Azure Container Registry administrator account. セキュリティのために、dockerPassword は必ずシークレットとして指定 (鍵のアイコンを選択) します。Be sure to specify dockerPassword as a Secret (by selecting the lock icon) for security purposes.
  9. [保存してキューに登録] を選択します。Select Save & queue.

これで、GitHub フォークの azds_updates ブランチにプッシュされた任意の更新プログラムに対して mywebapi および webfrontend を自動的にビルドする CI ソリューションが作成されました。You now have a CI solution that will automatically build mywebapi and webfrontend for any update pushed to the azds_updates branch of your GitHub fork. Azure portal に移動し、自分の Azure コンテナー レジストリを選択して、 [リポジトリ] タブを参照することで、Docker イメージがプッシュされたことを確認できます。イメージがビルドされて、コンテナー レジストリに表示されるまで、数分かかる場合があります。You can verify the Docker images have been pushed by navigating to the Azure portal, selecting your Azure Container Registry, and browsing the Repositories tab. It may take several minutes for the images to build and appear in your container registry.

Azure Container Registry リポジトリ

リリース定義の作成Creating the release definition

  1. DevOps プロジェクトのメイン ページ上で、[パイプライン] > [リリース] の順に移動します。On your DevOps project main page, navigate to Pipelines > Releases

  2. まだリリース定義を含まないまったく新しい DevOps プロジェクトに取り組んでいる場合は、先へ進む前に、まず空のリリース定義を作成する必要があります。If you're working in a brand-new DevOps Project that doesn't yet contain a release definition, you'll need to first create an empty release definition before proceeding. 既存のリリース定義ができるまで、[インポート] オプションは UI に表示されません。The Import option doesn't display in the UI until you have an existing release definition.

  3. 左側にある [+ 新規] ボタンをクリックして、 [パイプラインのインポート] をクリックします。On the left, click the + New button, then click Import a pipeline.

  4. [参照] をクリックし、プロジェクトから samples/release.json を選択します。Click Browse and select samples/release.json from your project.

  5. [OK] をクリックします。Click OK. [パイプライン] ウィンドウがリリース定義の編集ページと共に読み込まれたことが確認できます。Notice the Pipeline pane has loaded with the release definition edit page. また、引き続き構成する必要があるクラスター固有の詳細を示した赤い警告アイコンがいくつかあることが確認できます。Also notice there are some red warning icons indicating cluster-specific details that still must be configured.

  6. [パイプライン] ウィンドウの左側で、 [成果物の追加] バブルをクリックします。On the left of the Pipeline pane, click the Add an artifact bubble.

  7. [ソース] ドロップダウンで、前に作成したビルド パイプラインを選択します。In the Source dropdown, select the build pipeline you created earlier.

  8. [既定のバージョン] では、 [ビルド パイプライン既定のブランチ (タグ付き) からの最新バージョン] を選択します。For the Default version, choose Latest from the build pipeline default branch with tags.

  9. [タグ] は空のままにします。Leave Tags empty.

  10. [ソース エイリアス]drop に設定します。Set the Source alias to drop. [ソース エイリアス] の値は事前定義済みのリリース タスクによって使用されるため、設定しておく必要があります。The Source alias value is used by the predefined release tasks so it must be set.

  11. [追加] をクリックします。Click Add.

  12. 次に、新しく作成された drop アーティファクト ソース上にある、以下に示すような稲妻アイコンをクリックします。Now click the lightning bolt icon on the newly created drop artifact source, as shown below:

    リリース アーティファクトの継続的配置の設定

  13. [継続的配置トリガー] を有効にします。Enable the Continuous deployment trigger.

  14. [パイプライン] の隣の [タスク] タブをポイントし、dev をクリックして、dev ステージ タスクを編集します。Hover over the Tasks tab next to Pipeline and click dev to edit the dev stage tasks.

  15. [接続の種類][Azure Resource Manager] が選択されていることを確認します。Verify Azure Resource Manager is selected under Connection Type. 3 つのドロップダウン コントロールが赤で強調表示されていることがわかります。リリース定義の設定and you see the three dropdown controls highlighted in red: Release definition setup

  16. Azure Dev Spaces で使用している Azure サブスクリプションを選択します。Select the Azure subscription you're using with Azure Dev Spaces. [承認] をクリックすることが必要な場合もあります。You also may need to click Authorize.

  17. Azure Dev Spaces で使用するリソース グループとクラスターを選択します。Select the resource group and cluster you're using with Azure Dev Spaces.

  18. [エージェント ジョブ] をクリックします。Click on Agent job.

  19. [エージェント プール][Hosted Ubuntu 1604](ホストされている Ubuntu 1604) を選択します。Select Hosted Ubuntu 1604 under Agent pool.

  20. 上部にある [タスク] セレクターをポイントし、prod をクリックして prod ステージ タスクを編集します。Hover over the Tasks selector at the top, click prod to edit the prod stage tasks.

  21. [接続の種類][Azure Resource Manager] が選択されていることを確認します。Verify Azure Resource Manager is selected under Connection Type. Azure Dev Spaces で使用している Azure サブスクリプション、リソース グループ、およびクラスターを選択します。and select the Azure subscription, resource group, and cluster you're using with Azure Dev Spaces.

  22. [エージェント ジョブ] をクリックします。Click on Agent job.

  23. [エージェント プール][Hosted Ubuntu 1604](ホストされている Ubuntu 1604) を選択します。Select Hosted Ubuntu 1604 under Agent pool.

  24. [変数] タブをクリックして、リリースの変数を更新します。Click the Variables tab to update the variables for your release.

  25. DevSpacesHostSuffix の値を、UPDATE_ME から自分のホスト サフィックスに更新します。Update the value of DevSpacesHostSuffix from UPDATE_ME to your host suffix. ホスト サフィックスは、前に azds show-context コマンドを実行したときに表示されたものです。The host suffix is displayed when you ran the azds show-context command earlier.

  26. 右上にある [保存] をクリックし、 [OK] をクリックします。Click Save in the upper-right, and OK.

  27. [+ リリース] ([保存] ボタンの横にある)、 [リリースの作成] の順にクリックします。Click + Release (next to the Save button), and Create a release.

  28. [アーティファクト] で、ビルド パイプラインから最新のビルドが選択されていることを確認します。Under Artifacts, verify the latest build from your build pipeline is selected.

  29. Create をクリックしてください。Click Create.

これで、自動化されたリリース プロセスが開始され、dev の最上レベルの空間にある Kubernetes クラスターに、mywebapi および webfrontend のチャートがデプロイされます。An automated release process will now begin, deploying the mywebapi and webfrontend charts to your Kubernetes cluster in the dev top-level space. Azure DevOps の Web ポータル上で、リリースの進行状況を監視できます。You can monitor the progress of your release on the Azure DevOps web portal:

  1. [パイプライン][リリース] セクションに移動します。Navigate to the Releases section under Pipelines.
  2. サンプル アプリケーションのリリース パイプラインをクリックします。Click on the release pipeline for the sample application.
  3. 最新のリリースの名前をクリックします。Click on the name of the latest release.
  4. [ステージ]dev ボックスをポイントし、 [ログ] をクリックします。Hover over dev box under Stages and click Logs.

すべてのタスクが完了すると、リリースが行われます。The release is done when all tasks are complete.

ヒント

"UPGRADE FAILED: timed out waiting for the condition" のようなエラー メッセージでリリースが失敗した場合、Kubernetes ダッシュボードを使用して、ご自身のクラスター内のポッドを調べてみてください。If your release fails with an error message like UPGRADE FAILED: timed out waiting for the condition, try inspecting the pods in your cluster using the Kubernetes dashboard. ポットがエラーになっており、エラー メッセージが "Failed to pull image "azdsexample.azurecr.io/mywebapi:122": rpc error: code = Unknown desc = Error response from daemon:Get https://azdsexample.azurecr.io/v2/mywebapi/manifests/122: unauthorized: authentication required" のように始まっている場合、クラスターがお使いの Azure コンテナー レジストリからプルするための承認を受けていないことが原因になっている可能性があります。If you see the pods are failing to start with error messages like Failed to pull image "azdsexample.azurecr.io/mywebapi:122": rpc error: code = Unknown desc = Error response from daemon: Get https://azdsexample.azurecr.io/v2/mywebapi/manifests/122: unauthorized: authentication required, it may be because your cluster has not been authorized to pull from your Azure Container Registry. お使いの Azure コンテナー レジストリからプルするように AKS クラスターを承認する」の前提条件を完了していることを確認してください。Make sure you have completed the Authorize your AKS cluster to pull from your Azure Container Registry prerequisite.

これで、Dev Spaces サンプル アプリの GitHub フォークに対応する CI/CD パイプラインを完全に自動化できました。You now have a fully automated CI/CD pipeline for your GitHub fork of the Dev Spaces sample apps. コードをコミットしてプッシュするたびに、ビルド パイプラインでは mywebapi および webfrontend イメージをビルドして、お使いのカスタム ACR インスタンスにプッシュします。Each time you commit and push code, the build pipeline will build and push the mywebapi and webfrontend images to your custom ACR instance. その後、リリース パイプラインでは、アプリごとの Helm チャートを Dev Spaces が有効になっているクラスター上の dev 空間にデプロイします。Then the release pipeline will deploy the Helm chart for each app into the dev space on your Dev Spaces-enabled cluster.

dev サービスへのアクセスAccessing your dev services

デプロイ後は、http://dev.webfrontend.fedcba098.eus.azds.io のようなパブリック URL を使って、webfrontenddev バージョンにアクセスできます。After deployment, the dev version of webfrontend can be accessed with a public URL like: http://dev.webfrontend.fedcba098.eus.azds.io. azds list-uri コマンドを実行して、この URL を調べることができます。You can find this URL by running the azds list-uri command:

$ azds list-uris

Uri                                           Status
--------------------------------------------  ---------
http://dev.webfrontend.fedcba098.eus.azds.io  Available

運用環境へのデプロイDeploying to Production

このチュートリアルで作成した CI/CD システムを使用して、特定のリリースを prod に手動で昇格するには:To manually promote a particular release to prod using the CI/CD system created in this tutorial:

  1. [パイプライン][リリース] セクションに移動します。Navigate to the Releases section under Pipelines.
  2. サンプル アプリケーションのリリース パイプラインをクリックします。Click on the release pipeline for the sample application.
  3. 最新のリリースの名前をクリックします。Click on the name of the latest release.
  4. [ステージ]prod ボックスをポイントし、 [デプロイ] をクリックします。Hover over the prod box under Stages and click Deploy. 運用環境への昇格Promote to production
  5. [ステージ]prod ボックスを再びポイントし、 [ログ] をクリックします。Hover over prod box again under Stages and click Logs.

すべてのタスクが完了すると、リリースが行われます。The release is done when all tasks are complete.

CI/CD パイプラインの Prod ステージでは、Dev Spaces イングレス コントローラーではなくロード バランサーを使用して、prod サービスへのアクセスが提供されます。The prod stage of the CI/CD pipeline uses a load balancer instead of the Dev Spaces Ingress controller to provide access to prod services. prod ステージにデプロイされるサービスには、DNS 名の代わりに IP アドレスでアクセスできます。Services deployed in the prod stage are accessible as IP addresses instead of DNS names. 運用環境では、独自のイングレス コントローラーを作成し、独自の DNS 構成に基づいてサービスをホストすることができます。In a production environment, you may choose to create your own Ingress controller to host your services based on your own DNS configuration.

webfrontend サービスの IP アドレスを確認するには、 [Print webfrontend public IP](webfrontend のパブリック IP を印刷する) ステップをクリックして、ログ出力を展開します。To determine the IP of the webfrontend service, click on the Print webfrontend public IP step to expand the log output. ログ出力に表示される IP アドレスを使用して、webfrontend アプリケーションにアクセスします。Use the IP displayed in the log output to access the webfrontend application.

...
2019-02-25T22:53:02.3237187Z webfrontend can be accessed at http://52.170.231.44
2019-02-25T22:53:02.3320366Z ##[section]Finishing: Print webfrontend public IP
...

運用環境における Dev Spaces のインストルメンテーションDev Spaces instrumentation in production

Dev Spaces のインストルメンテーションは、アプリケーションの通常の操作を妨害 "しない" ように設計されていますが、Dev Spaces が有効になっていない Kubernetes 名前空間内で運用環境のワークロードを実行することをお勧めします。Although Dev Spaces instrumentation has been designed not to get in the way of normal operation of your application, we recommend running your production workloads in a Kubernetes namespace that is not enabled with Dev Spaces. このタイプの Kubernetes 名前空間を使用する場合は、kubectl CLI を使用して運用環境の名前空間を作成するか、CI/CD システムによって最初の Helm デプロイ中にこれを作成できるようにしておく必要があります。Using this type of Kubernetes namespace means you should either create your production namespace using the kubectl CLI, or allow your CI/CD system to create it during the first Helm deployment. 空間を "選択する" か、Dev Spaces ツールを使用して空間を作成すると、Dev Spaces インストルメンテーションがその名前空間に追加されます。Selecting or otherwise creating a space using Dev Spaces tooling will add Dev Spaces instrumentation to that namespace.

次に、機能のデプロイ、'dev' 環境、"および" 運用環境のすべてを単一の Kubernetes クラスター内でサポートする名前空間の構造のサンプルを示します。Here is an example namespace structure that supports feature development, the 'dev' environment, and production, all in a single Kubernetes cluster:

名前空間の構造のサンプル

ヒント

prod 空間を既に作成済みであり、単純に Dev Spaces インストルメンテーションから (削除せずに) 除外したい場合、次の Dev Spaces CLI コマンドを使ってこれを実行できます。If you've already created a prod space, and would simply like to exclude it from Dev Spaces instrumentation (without deleting it!), you can do so with the following Dev Spaces CLI command:

azds space remove -n prod --no-delete

これを実行した後に prod 名前空間にあるすべてのポッドの削除が必要になる場合があります。そのため、Dev Spaces インストルメンテーションなしでの再作成が可能になっています。You may need to delete all pods in the prod namespace after doing this so they can be recreated without Dev Spaces instrumentation.

次のステップNext steps