次の方法で共有

環境内の Linux VM にデプロイする

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

Azure Pipelines 環境内のリソースとして仮想マシンを追加し、デプロイの対象にすることができます。 継続的インテグレーションと継続的デプロイ (CI/CD) ワークフローの場合、環境のデプロイ履歴は、トリガーされるコミットに戻る各 VM の追跡可能性を提供します。

この記事では、環境内の複数の Linux 仮想マシン (VM) リソース へのデプロイ用に Azure DevOps パイプラインを設定する方法について説明します。 これらの手順では、JavaScript または Java アプリをビルドしてデプロイしますが、Web デプロイ パッケージを発行する任意のアプリに合わせて調整できます。

デプロイ ジョブの対象となる環境とリソースの詳細については、 jobs.deployment.environment YAML スキーマ定義を参照してください。 デプロイ ジョブの詳細については、 jobs.deployment の定義を参照してください。

前提条件

また、JavaScript または Node.js アプリの場合:

重要

  • アプリをデプロイするには、ターゲット環境の VM リソースに、必要なすべてのソフトウェア、依存関係、アクセス許可、およびログインがインストールおよび構成されている必要があります。
  • GitHub ソース コードを使用するには、 GitHub サービス接続が必要です。 GitHub では、サインイン、Azure Pipelines GitHub アプリのインストール、または Azure Pipelines の承認を求めるメッセージが表示される場合もあります。 各プロセスを完了するには、画面の指示に従います。 詳細については、「Github リポジトリへのアクセス」を参照してください。

環境を作成して Linux VM を追加する

Azure Pipelines プロジェクトで、「環境の作成と VM の追加」の手順に従って、環境を作成し、Linux VM を環境リソースとして 追加します。

コピーしたエージェント登録スクリプトを各 VM で実行して、環境に登録します。 対話型のプロンプトに応答して、個々の VM にタグを割り当てることもできます。

ビルド パイプラインを作成して実行する

コード リポジトリの main ブランチにコミットがある場合は常に、アプリをビルドしてデプロイする CI パイプラインを作成します。

YAML パイプラインを作成する

  1. Azure DevOps プロジェクトで、[ パイプライン>新しいパイプライン ] または [パイプラインの作成] を選択し、ソース コードの場所として GitHub を選択します。
  2. リポジトリの選択画面で、フォークしたサンプル リポジトリを選択します。
  3. [パイプラインの構成] 画面で、[スタート パイプライン] を選択します。
  4. パイプライン YAML の確認画面で、ランタイムに応じて、生成されたスターター コードを次のコードに置き換えます。

ビルド ジョブを追加する

Build ジョブは、プロジェクトをビルドしてテストするタスクを実行し、ビルド出力をdropの場所にアップロードします。 このジョブは、Linux 環境の VM ではなく、パイプライン poolで指定されたビルド エージェントで実行されます。

次のパイプラインは、npm を使用して Node.js プロジェクトをビルドしてテストし、出力をパッケージ化してドロップ場所にアップロードします。

trigger:
- main

pool:
  vmImage: ubuntu-latest

jobs:  
- job: Build
  displayName: Build
  steps:
  - task: UseNode@1
    inputs:
      version: '16.x'
    displayName: 'Install Node.js'
  - script: |
      npm install
      npm run build --if-present
      npm run test --if-present
    displayName: 'npm install, build and test'
  - task: ArchiveFiles@2
    displayName: 'Archive files'
    inputs:
      rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
      includeRootFolder: false
      archiveType: tar
      tarCompression: gz
      archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).gz
      replaceExistingArchive: true
  - upload: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).gz
    artifact: drop

詳細については、「gulp を使用して Node.js アプリをビルドする」でビルドを作成する手順を確認してください。

パイプラインを実行する

azure-pipelines.yml ファイルをリポジトリに保存し、CI/CD パイプラインを開始するには、[保存して実行] を選択し、[保存して再度実行] を選択します。

パイプラインが完了したら、ジョブ の概要 ページを表示して、ビルド ジョブが正常に実行され、 1 つの発行済み 成果物が [関連] の下に表示されることを確認します。

デプロイ ジョブを追加して実行する

デプロイ ジョブは、preDeploy、deploy、routeTraffic、およびpostRouteTrafficライフサイクル フックを 1 回実行し、on: successまたはon: failureを実行します。 環境 VM にデプロイする場合、 preDeploy フェーズは、環境 VM ではなく、ビルド エージェントで実行されます。 その他のすべての手順は、環境内の登録済み VM で実行されます。

  1. オプションの preDeploy ステップは、デプロイ前に実行されます。 この手順は、オーケストレーション、VM と成果物の準備、正常性チェックに使用できます。
  2. deploy手順では、デプロイ オブジェクトをターゲット環境の VM にデプロイします。
  3. オプションの routeTraffic ステップでは、トラフィックの切り替えを適用できます。
  4. オプションの postRouteTraffic ステップでは、正常性チェックと通知を実行できます。
  5. カスタム on.failure と on.success の手順では、通知または回復を提供できます。

resourceType: VirtualMachineを使用する環境へのデプロイ ジョブでは、環境 VM が Bash や Azure CLI などのすべてのパイプライン タスクを実行できる必要があります。 preDeployの手順を使用して、ターゲット VM に必要なソフトウェアとアクセス許可をインストールできます。

たとえば、デプロイ手順で Azure CLI を使用する場合、エージェント VM には Azure CLI がインストールされ、エージェント ユーザーの PATH で使用できる必要があります。 エージェント ユーザーには、CLI を実行するためのアクセス許可が必要であり、Azure に対して認証する必要があります。 エージェント ユーザーを sudoers に追加したり、インストールを自動化するために環境変数を設定したりする必要がある場合があります。

preDeploy スクリプトを使用して、ターゲット VM に Azure CLI をインストールできます。 Azure に対して認証するには、az loginを実行するか、自動化のために、サービス プリンシパルを定義し、az login --service-principalの手順でpreDeployを実行します。

デプロイ ジョブを追加する

次のデプロイ ジョブの例は、 Build ジョブが正常に完了したときに開始されます。 パイプラインにジョブを追加する手順は以下の通りです。

  1. [概要] ページの右上にある [その他のアクション] アイコンを選択し、[パイプラインの編集] を選択して、パイプラインの末尾に次のコードを追加します。 <environment-name>を、作成した環境の名前に置き換えます。

    必要に応じて、 tags パラメーターを使用し、VM に対して定義した <VMtag> を指定することで、環境から特定の VM を選択してデプロイを受け取ることができます。

    - deployment: VMDeploy
  displayName: Web deploy
  dependsOn: Build
  condition: succeeded()
  environment:
    name: <environment-name>
    resourceType: VirtualMachine
    tags: <VMtag> # VMs to deploy to

  2. strategy ジョブにdeploymentを追加します。 runOnce 配置戦略は最も単純であり、strategyを指定しない場合は既定で実行されます。 この戦略では、並列処理やトラフィック管理を行わずに、環境内の各 VM でデプロイ手順を 1 回実行します。

      strategy:
     runOnce:
       deploy:
          steps:
          - script: echo my first deployment

  3. デプロイ ジョブを追加したら、[ 検証して保存] を選択し、[ 保存] を選択し、[ 実行] を選択して、もう一度 [実行 ] を選択します。 このジョブを実行するたびに、デプロイ履歴は環境に対して記録されます。

    Note

    環境を使用するパイプラインを初めて実行するときは、エージェント プールと環境にアクセスするためのパイプラインのすべての実行に対するアクセス許可を付与する必要があります。 パイプライン実行の概要画面でジョブの横にある待機中シンボルを選択し、[許可] を選択して必要なアクセス許可を付与します。

ローリング デプロイ戦略

あなたはrunOnceの代わりにrollingを使用するデプロイメント戦略を使用できます。 ローリング デプロイ戦略では、並列処理、正常性チェック、トラフィック ルーティングを調整できます。 runOnce戦略は一度に 1 つの VM で実行されますが、ローリング デプロイは、設定に応じて、最大 5 つのターゲット VM のmaxParallelで並列に実行できます。

maxParallel パラメーターは、使用可能な状態を維持する必要がある VM の数または割合を設定し、アプリが要求を処理できるようにし、デプロイ中の全体的なダウンタイムを減らします。 このパラメーターは、デプロイの成功と失敗の条件も決定します。

ローリング デプロイ戦略の詳細については、 jobs.deployment.strategy.rolling スキーマ定義を参照してください。

デプロイ ジョブの例

VM リソースへのデプロイでは、必要なすべてのアプリ、依存関係、およびアクセス許可が VM にインストールおよび構成されている必要があります。 これらの要件を手動でプレインストールするか、パイプラインでインストールまたは実装する必要があります。

VM リソースへの Java アプリのデプロイは自己完結型であるため、実装が簡単です。 Java 仮想マシン (JVM) は VM エージェントにプレインストールされることが多く、アプリの依存関係、アクセス許可、パッケージ管理について心配する必要はありません。 JAR ファイルをダウンロードし、 java -jarで実行するだけです。

Node.js アプリでは、Node、場合によっては npm 依存関係、および systemd などのサービス マネージャーが各エージェント VM に存在し、構成されている必要があります。 自動化するには、パイプライン デプロイ スクリプトが非インターアクティブであり、アプリのサービスを再起動して管理できる必要があります。

JavaScript アプリの次の YAML rolling デプロイ ジョブは、ステージの正常な完了 Build によって異なります。 デプロイ ジョブでは、各エージェント VM に次の要件が既にプレインストールまたは事前構成されていることを前提としています。 完全な自動化のために、これらのアプリとサービスをパイプラインの一部として VM にインストールして構成できます。

  • Node.js 16.x がインストールされており、ビルド エージェントの PATH で npm を使用できます。
  • /etc/systemd/system /pipelines-javascript.service など、Node.js アプリを起動するサービス用に構成された systemd サービス ファイルを使用する Systemd。
  • 必要なコマンドに対して、エージェントユーザーがパスワードなしで sudo を実行できるように、NOPASSWD: を /etc/sudoers で設定します。
  • /opt/pipelines-javascript またはその他のデプロイターゲットに対するエージェントユーザーの書き込み権限。

ヒント

ほとんどの Node.js アプリでは、デプロイ ジョブを使用するのではなく、 Azure App Service にデプロイするか、Microsoft がホストするエージェントで通常のパイプライン ジョブを使用することを検討してください。 この方法の方が簡単で、VM 環境を管理する運用上のオーバーヘッドを回避できます。 特定の VM リソースへのデプロイは、VM サーバー、高度なオーケストレーション、またはレガシ インフラストラクチャを直接制御する必要があるシナリオに最適です。

- stage: Deploy
  displayName: Rolling Deploy to VMs
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: RollingDeploy
    displayName: Rolling deploy to Ubuntu VMs
    environment:
      name: <environment-name>
      resourceType: VirtualMachine
    strategy:
      rolling:
        maxParallel: 1   #or 2 for parallel. For percentages, use x%
        preDeploy:
          steps:
          - download: current
            artifact: drop
          - script: echo "Pre-deploy on $(hostname)"
        deploy:
          steps:
          - script: |
              echo "Unpacking Node.js app on $(hostname)"
              sudo mkdir -p /opt/pipelines-javascript
              sudo tar -xzf $(Pipeline.Workspace)/drop/$(Build.BuildId).tar.gz -C /opt/pipelines-javascript --strip-components=1
              cd /opt/pipelines-javascript
              echo "Installing production dependencies"
              sudo npm ci --only=production
              echo "Restarting Node.js service"
              sudo systemctl restart pipelines-javascript
            displayName: 'Extract, install, and restart Node.js service'
        routeTraffic:
          steps:
          - script: echo "Routing traffic on $(hostname)"
        postRouteTraffic:
          steps:
          - script: echo "Post-route health check on $(hostname)"
        on:
          failure:
            steps:
            - script: echo "Deployment failed on $(hostname)"
          success:
            steps:
            - script: echo "Deployment succeeded on $(hostname)"

環境内のパイプラインの追跡可能性にアクセスする

[環境 のデプロイ ] タブには、コミットと作業項目の完全な追跡可能性と、環境のクロスパイプラインデプロイ履歴が表示されます。

[デプロイ] ビューのスクリーンショット。

関連するコンテンツ

  • Last updated on