Azure Managed Service Column ＜Azure運用コラム＞Azure DevOps で DevOps を実現する

はじめに

DevOpsとは？導入するメリットとAzureを活用した環境構築方法を解説 にて DevOps という概念を紹介しました。一言でいうと「開発と運用が相互に協力して開発することで、システムやサービスを迅速かつ確実にユーザに届ける取り組み」を意味します。これにより、顧客満足度を上げてビジネスの価値を高めることが目的です。

DevOps はあくまで概念ですから、実際に取り入れるには「プロセスの定義」と「それを実現するツール」が必要になります。本コラムでは、Azure のサービス “Azure DevOps” を使った DevOps の一例として、Azure Pipelines によるワークフローの自動化を紹介します。

DevOps のライフサイクル

ツールを使って自動化する前に、何を自動化するのかを明確にしておきましょう。DevOps の主要なアプローチの仕方に、以下のライフサイクルを回していく、というのがあります。

1. 計画
2. コード(開発)
3. ビルド
4. テスト
5. デプロイ(リリース)
6. モニタリング(運用)
7. フィードバック

このライフサイクルを以下に迅速に回していくか、が DevOps 実現のキモになります。

“ビルド” “テスト” “デプロイ” の3フェーズはいわゆる CI/CD に相当する部分です。この部分のワークフローを CI/CD ツールによって自動化することが DevOps 実現の第一歩となります。

Azure DevOps の要素

Azure DevOps は DevOps を実現するためのツール群です。以下の要素から成り立っています。

1. Azure Pipeline（CI/CD ツール）
2. Azure Boards（進捗管理ツール）
3. Azure Repos（バージョン管理ツール）
4. Azure Test Plans（手動テスト管理ツール）
5. Azure Artifacts（パッケージ管理ツール）

全ての要素を使う必要はありません。一部の要素を使い慣れたツールに置き換えることも可能です。今回は、Azure Repos と Azure Pipelines を使います。

デプロイ先としての App Service

Azure Pipelines のデプロイ先は、仮想マシン、Kubenetes、Azure Functions、あるいは Azure 以外のクラウドなど、場所を選びません。今回は、もっとも相性のよい App Service にデプロイすることとします。

App Service は PaaS に相当するサービスで、ミドルウェアレイヤまでを Azure が用意してくれます。ユーザはアプリケーションを App Service にデプロイするだけで、Web サービスを公開することができます。

App Service には “スロット” と呼ばれるアプリケーションの格納先を複数、作成することができます。また、このスロットはスワップすることができ、例えばステージングスロットと本番スロットをスワップことで、瞬時にアプリケーションを本番公開することができます。もし、問題が発生した場合は再スワップすることで簡単にロールバックすることができます。

Azure Pipeline を使ってビルドからデプロイまでを自動化

1. CI/CD のワークフローを考える

まずは、アプリケーション開発からリリースまでのワークフローを具体的に考える必要があります。チームやプロジェクトよって最適なワークフローは異なると思いますが、以下のような形が一般的だと思います。これらの各フェーズは、Azure Pipelines での “ステージ” という概念に対応します。

1. ビルド : アーティファクトの作成
2. テスト : ステージング環境へデプロイ
3. デプロイ : 本番環境へデプロイ

以降の手順では、簡単な PHP アプリケーションを例として、上記のパイプラインを作ることにします。”コード” が完了している (アプリケーションが出来ている) ことを前提とし、”ビルド” “テスト” “デプロイ” という、3つのステージから成るパイプラインを作ることにしましょう。

“ビルド” では、パイプラインの実行環境内で php のインストールなどを行い、アーティファクトというパッケージを作成します。

“テスト” では、App Service のステージングスロットにアーティファクトをデプロイします。ステージングスロットなので、一般ユーザには公開されていません。この段階でアプリケーションの動作確認を行います。

“デプロイ” では、一般ユーザにアプリケーションを公開します。オンラインリリースをするためにスロットスワップによる公開とし、また、スワップ前には管理者による “承認” を行うフローとします。

2. App Service を用意する

Azure ポータルより、[App Serivce] の画面を開いて、App Service を作成します。 以下のように、[ランタイムスタック] や [オペレーションシステム] を選択しましょう。[App Service プラン] は後ほど、ステージングスロットという機能を使うために “S1” を選んでおきます。

“App Service プラン” というのは App Service の実行環境となるリソースのことで、実体は Azure VM の集合体です。ユーザ視点では、どの Azure VM を使っているのかはブラックボックスになっており、単純に「スペックを指定してリソースを買う」という形になります。

購入した App Service プランの上に幾つ App Service を使っても料金は変わりませんが、CPU やメモリは共有することになります。リソースが足りなくなったら、スケールアップやスケールアウトを行うことができます。

App Service を作成したら、[デプロイスロット] メニューを開いて、ステージング用のスロットを追加します。[スロットの追加] をクリックして、以下のように追加してください。

3. Azure DevOps の初期設定を行う

Azure DevOps の初期設定を行います。Azure ポータルにて “Azure DevOps organizations” と検索すると Azure DevOps へのリンクが書いてあるページに飛びます。リンクを開くと、以下のように Azure DevOps のトップページが表示されます。

初回のアクセスでは、[組織] と [プロジェクト] を聞かれます。ここの構造設計は色々なやり方がありますが、基本的には言葉通り捉えてもらって構いません。[Visibility] は匿名アクセスを禁止するために “Private” で作成します。

弊社の場合、SS という部署にてコラムを作成するプロジェクトを進めているので、それぞれ “rworks-ss”、”column” としました。

4. Azure Repos にてリポジトリを作成する

コードを格納するリポジトリを用意します。既に GitHub をお持ちの方はそれを使うこともできますが、今回は Azure DevOps の機能である Azure Repos を使うことにします。

左メニューより [Repos] > [Files] をクリックし、画面上部にある “column” をクリックします。プルダウンメニューが表示されますので、”New repository” をクリックしてください。

リポジトリ名を聞かれますので、今回は “sample” としてみます。README や .gitignore を同時に作ることも出来ます。[Create] ボタンを押すとリポジトリが作成されます。

[Clone] をクリックして表示される画面から URL と Credentials をコピーし、自分の端末にリポジトリをクローンしましょう。以下は私の端末に clone した様子です。

[: ~/column]
 >>> git clone https://rworks-ss@dev.azure.com/rworks-ss/column/_git/sample
Cloning into 'sample'...
Password for 'https://rworks-ss@dev.azure.com':
remote: Azure Repos
remote: We noticed you're using an older version of Git. For the best experience, upgrade to a newer version.
remote: Found 3 objects to send. (13 ms)
Unpacking objects: 100% (3/3), done.
[: ~/column]
 >>> ls
sample

簡単なサンプルファイルを作成して、push してみましょう。

[: ~/column/sample]
 >>> cat index.php
<?php

echo "Hello World!";
[: ~/column/sample]
 >>> git add index.php
[: ~/column/sample]
 >>> git commit
[main 380dd48] add index.php
 1 file changed, 3 insertions(+)
 create mode 100644 index.php
[: ~/column/sample]
 >>> git push
Password for 'https://rworks-ss@dev.azure.com':
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 328 bytes | 328.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Analyzing objects... (3/3) (6 ms)
remote: Storing packfile... done (52 ms)
remote: Storing index... done (40 ms)
To https://dev.azure.com/rworks-ss/column/_git/sample
   6de1759..380dd48  main -> main

Azure Repos 上のリポジトリに反映されているので、確認してみてください。

5. Azure Pipelines にてパイプラインを作成する

いよいよ、パイプラインを作成します。左メニューより [Pipelines] > [Pipelines] を開き、[Create Pipeline] をクリックします。(備考 : YAML パイプラインと Release パイプライン)

利用するリポジトリサービスを聞かれるので、”Azure Repos” を選択します。

先程選んだ “sample” リポジトリを選択します。

コードを読んで判断してくれたのでしょうか？パイプラインのサンプルを幾つか提示してくれます。今回は “PHP as Linux Web App on Azure” を利用します。

“PHP as Linux Web App on Azure” を選択すると、デプロイ先を指定するウィザードが開かれます。App Service の存在する Azure サブスクリプションを選択し、あらかじめ作成しておいた “rworks-php” を選択します。

すると、以下のような YAML ファイルが自動生成されます。

少し内容の解説をします。大きく分けて “trigger”、”variables”、”stage” の3つのカテゴリに分かれています。

“trigger” はパイプラインの実行トリガを指定する箇所で、master ブランチが指定されています。”variables” は変数を定義する箇所です。”stages” がパイプラインのワークフローを定義する箇所で、既に “Build” “Deploy” の2つのステージが作成されています。(ステージの中身は長いので隠しています。)

6. パイプラインのステージを編集する

作成されたパイプラインのステージを編集していきましょう。”Build” ステージはそのまま利用して、”Test” と “Deploy” を新たに作成することにします。

自動作成された “Deploy” ステージをお手本にして、”task” の箇所を実行したいアクションに書き換えます。task というのはデフォルトで用意されている関数のようなものです。以下のように、YAML エディタの右側にたくさんの task が用意されていますから、適切なものを選んで必要な引数を入力すると YAML を自動作成してくれます。

以下は、”Test” ステージの YAML です。task は “Azure App Service Deploy” を使いました。スロット “stg” にデプロイを行います。

- stage: Test
  displayName: 'Test Stage (Deploy Stage Slot)'
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: DeploymentJob
    pool:
      vmImage: $(vmImageName)
    environment: $(environmentName)-stg
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Deploy Azure Web App : rworks-php'
            inputs:
              azureSubscription: $(azureSubscription)
              appType: 'webAppLinux'
              appName: 'rworks-php'
              deployToSlotOrASE: true
              resourceGroupName: 'AzureMenu-rg'
              slotName: 'stg'
              package: '$(Pipeline.Workspace)/drop/$(Build.BuildId).zip'

“Deploy” ステージの YAML です。task は “Azure App Service manage” を使いました。スロットスワップを行う task です。

- stage: Deploy
  displayName: 'Deploy Stage (Swap Slots)'
  dependsOn: Test
  condition: succeeded()
  jobs:
  - deployment: DeploymentJob
    pool:
      vmImage: $(vmImageName)
    environment: $(environmentName)
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureAppServiceManage@0
            inputs:
              azureSubscription: $(azureSubscription)
              Action: 'Swap Slots'
              WebAppName: 'rworks-php'
              ResourceGroupName: 'AzureMenu-rg'
              SourceSlot: 'stg'

最後に、”承認” を追加します。承認は “environment” に対して設定します。コード内の environment に着目してください。”Test” と “Deploy” で environment が異なっています。

コード中で指定した environment は、左メニューの [Pipelines] > [Environments] 内で定義します。以下の通り、コード内で指定した environment と同名のものを2つ、用意します。

“Deploy” ステージにて指定している environment の “rworks-php” を開き、右上のハンバーガーメニューから [Approvals and checks] をクリックします。チェック方法を聞かれるので、”Approvals” を選択し、承認するユーザを指定します。

以上で、目的としていたワークフローと同じパイプラインを作成することができました。

7. パイプラインを実行する

いよいよ、パイプラインを実行します。[Pipelines] > [Pipelines] を開いて、実行したいパイプラインのハンバーガーメニューから [Run Pipeline] をクリックしましょう。

ワークフローが表示され、今どこのステージが実行中なのかが見て分かるようになっています。各ステージをクリックすると、ジョブの実行状況や実行ログをみることもできます。

“Deploy” ステージにたどり着くと、”Wait” 状態になりました。

ここで、ステージングスロットの URL をクリックして、アプリケーションが正しくデプロイされているか見てみます。”Hello World” と表示されていますね。

ステージングスロットでの動作確認に問題がなかったので、承認しましょう。”Deploy” ステージをクリックし、”Approve” をクリックします。パイプラインが再開し始めます。

App Service の URL をクリックすると、デフォルトページだったものが…

PHP の “Hello World” に置き換わりました！

以上でパイプラインの作成は終わりです。パイプラインは自由にカスタマイズできるので、作り込むことで更に柔軟な処理の自動化を実現することができます。ARM Template を使ってインフラ環境の構築も自動化したり、様々な Azure サービスと連携したりすることも出来ます。

まとめ

Azure Pipelines を使うことで、”ビルド” → “テスト” → “デプロイ” という一連のワークフローを自動化することができました。実際のケースでは、デプロイして新しいアプリケーションをリリースしたらおしまいではありません。継続的に “モニタリング” して、”フィードバック” を行い、次のアプリケーションバージョンを “計画” して、”開発” と、ライフサイクルを回し続けていかなければなりません。

本番環境にデプロイすることのハードルが下がれば、新しいアプリケーションをリリースまでの時間を大幅に短縮することができるはずです。これが、本来の DevOps の目的となります。

（本文へ戻る）

Tag： Azure DevOps

• 

  Azure Virtual Machinesとは？初心者向けに概要とメリット、機能について解説

• 

  RBAC（ロールベースアクセス制御）とは？Azureを安全に利用するための権限管理