DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

シーケンシャルAnsibleプレイブックを使用したマルチステージデプロイメントの習得

Ansibleを使用して複雑なマルチステージアプリケーションデプロイメントを設計および実行する方法を学びます。このガイドでは、明確なデプロイメントフェーズのためのシーケンシャルプレイブックの作成、効果的なエラーハンドリングの実装、ロールバック戦略の開発について説明します。実践的な例とベストプラクティスを使用して、堅牢で自動化されたアプリケーションデリバリーを習得します。

シーケンシャルAnsibleプレイブックを使用したマルチステージデプロイメントの習得

「ファイルをコピーしてサービスを再起動する」だけでは不十分な場合、マルチステージAnsibleデプロイメントが必要になります。実際のデプロイメントでは、データベースマイグレーション、フィーチャーフラグの変更、パッケージのロールアウト、サービスのリロード、ヘルスチェック、そして新しいバージョンが失敗した場合のロールバックパスが必要になる場合があります。これらすべてが境界の不明確な1つの大きなプレイブックに含まれている場合、失敗したデプロイメントはすべて読解作業に変わります。

シーケンシャルプレイブックは、各ステージに明確な役割を与えます。CI/CDパイプライン、AWX、Ansible Automation Platform、または単純なシェルスクリプトから実行できます。重要なのは、ボタンを押すツールではありません。重要なのは、デプロイメントに順序があり、各ステージを安全に再試行でき、障害処理が明示的であることです。

マルチステージデプロイメントにシーケンシャルプレイブックを使用する理由

アプリケーションのデプロイには、ファイルのコピーだけでは不十分な場合がよくあります。以下のような作業が必要になる場合があります：

  • 環境の準備： ディレクトリの作成、権限の設定、依存関係のインストール。
  • データベースの更新： スキーママイグレーションの実行、初期データのシード。
  • アプリケーションコードのデプロイ： 新しいコードバージョンの転送、サービスの再起動。
  • サービスの設定： アプリケーション設定の更新、デーモンのリロード。
  • デプロイ後のチェック： スモークテストの実行、サービスの可用性の確認。

順序が重要なのは、一部の操作はロールバックが簡単で、他の操作はそうではないからです。以前のリリースへのシンボリックリンクを元に戻すのは通常簡単です。破壊的なデータベースマイグレーションを元に戻すのは簡単ではないかもしれません。この違いは、誰かがYAMLを書く前にデプロイメント計画を形作る必要があります。

これらを個別のシーケンシャルプレイブックに分割すると、いくつかの利点が得られます：

  • モジュール性： 各プレイブックは単一のステージに焦点を当てているため、理解、保守、再利用が容易になります。
  • 可読性： 複雑なロジックが管理しやすいチャンクに分割されます。
  • 制御： 特定のステージを独立して、またはより大きなワークフローの一部として実行できます。
  • エラーの分離： あるステージで障害が発生した場合、原因を特定し、デプロイメントの他の部分に影響を与えずに特定の変更をロールバックすることが容易になります。
  • 冪等性： 適切に作成されたプレイブックは本質的に冪等であり、複数回実行しても1回実行した場合と同じ効果が得られます。これは安全な再試行にとって重要です。

トレードオフがあります。個別のプレイブックはオーケストレーション作業を追加します。変数、アーティファクト、ステータスをあるステージから別のステージに移動する必要がある場合があります。小規模な内部サービスの場合は、タグ付きブロックを持つ1つのプレイブックで十分な場合があります。マイグレーションとロールバック要件を持つ顧客向けアプリケーションの場合、通常は追加の構造が価値があります。

マルチステージデプロイメントワークフローの設計

Ansibleコードを書く前に、デプロイメントステージを計画します。論理的なステップ、その依存関係、実行順序を特定します。一般的なワークフローは次のようになります：

  1. デプロイ前チェック： ターゲット環境が準備できていることを確認します。
  2. データベースマイグレーション： 必要なデータベーススキーマの変更を適用します。
  3. アプリケーションデプロイ： アプリケーションコードの新しいバージョンをデプロイします。
  4. サービスの再起動/リロード： 新しいコードでアプリケーションサービスをオンラインにします。
  5. デプロイ後検証： テストを実行してデプロイメントの成功を確認します。

各ステージについて、どのAnsibleタスクが必要で、どのプレイブックにそれらを含めるかを検討します。

また、どのステージが本番状態を変更できるかを決定します。スモークテストプレイブックは、静かに設定を修復するべきではありません。プリフライトプレイブックは、それがデプロイメント契約の一部でない限り、不足しているパッケージをインストールするべきではありません。読み取り専用のチェックを変更ステップから分離しておくと、ワークフローを信頼しやすくなります。

実用的なディレクトリレイアウトは次のとおりです：

deploy/
  inventories/
    staging.ini
    production.ini
  group_vars/
    all.yml
    production.yml
  playbooks/
    00-preflight.yml
    01-migrate-db.yml
    02-deploy-app.yml
    03-reload-services.yml
    04-smoke-test.yml
    rollback-app.yml

数字は魔法ではありません。ファイルリストとCIログで順序を表示するだけです。

プレイブックのシーケンシャル実行

Ansibleは、--playbook-dirおよびansible-playbookコマンドを使用して、プレイブックを次々に実行する簡単な方法を提供します。最も簡単な方法は、CI/CDパイプラインまたはコマンドラインでコマンドをチェーンすることです。

次のプレイブックファイルがあるとします：

  • 01-database-migration.yml
  • 02-deploy-application.yml
  • 03-restart-services.yml
  • 04-smoke-tests.yml

次のようにシーケンシャルに実行できます：

ansible-playbook -i inventory.ini 01-database-migration.yml
ansible-playbook -i inventory.ini 02-deploy-application.yml
ansible-playbook -i inventory.ini 03-restart-services.yml
ansible-playbook -i inventory.ini 04-smoke-tests.yml

実際には、失敗したステージがパイプラインを停止するように、そのシーケンスをラップします：

set -euo pipefail

ansible-playbook -i inventories/production.ini playbooks/00-preflight.yml
ansible-playbook -i inventories/production.ini playbooks/01-migrate-db.yml
ansible-playbook -i inventories/production.ini playbooks/02-deploy-app.yml
ansible-playbook -i inventories/production.ini playbooks/03-reload-services.yml
ansible-playbook -i inventories/production.ini playbooks/04-smoke-test.yml

set -eはそれ自体ではデプロイメント戦略ではありませんが、最悪の間違いを防ぎます：何も起こらなかったかのように失敗したステージの後に続行することです。CIシステムは通常、独自の障害動作を提供しますが、同じ考え方が適用されます。

ansible-playbook --skip-tagsまたは--limitの使用

より高度なシナリオでは、複数の論理ステップを1つのプレイブックに組み合わせるが、タグを使用して実行を制御することができます。ただし、真のマルチステージ分離のためには、通常、個別のプレイブックが推奨されます。プレイブックのサブセットを実行したり、特定のプレイブックをスキップしたりする場合は、コマンドライン引数を使用できます。

プレイブックのスキップ： 03-restart-services.ymlが一時的なサービス問題のために失敗した場合、原因を修正した後にそのステージのみを再実行する可能性があります。以前のステージが後続のステージが依存するアーティファクトや状態を生成する場合、盲目的にステージをスキップしないでください。

特定のステージへの制限： --limitフラグを使用して、特定のホストまたはグループに実行を制限することもできます。これはテストに役立ちます。

ローリングデプロイメントの場合、--limitは影響範囲を減らすこともできます：

ansible-playbook -i inventories/production.ini playbooks/02-deploy-app.yml --limit web_canary

1つのホストまたは1つの小さなグループに対してデプロイメントを実行し、検証してから、残りのフリートに続行します。これは、ロードバランサーがリロードまたは再起動の前にホストのドレインをサポートしている場合に特に便利です。

エラーハンドリングとロールバック戦略の組み込み

堅牢なデプロイメントには、問題が発生した場合の計画が必要です。

ignore_errorsとfailed_when

デフォルトでは、タスクが失敗するとAnsibleは実行を停止します。この動作を制御できます：

  • ignore_errors: true：タスクが失敗した場合でもプレイブックの続行を許可します。これは、重要でないタスクや、後続のタスクでクリーンアップまたは補償を行う場合に慎重に使用します。
  • failed_when:：タスクが失敗したと見なされるカスタム条件を定義します。これは、予期される致命的でないエラーを処理したり、特定の結果を検証したりする場合に強力です。
- name: サービスステータスの確認（致命的でない可能性あり）
  command: systemctl status myapp
  register: service_status
  ignore_errors: true

- name: サービスがアクティブでない場合に失敗
  fail:
    msg: "サービスmyappが実行されていません！"
  when: "service_status.rc != 0"

ignore_errorsは控えめに使用してください。多くの場合、結果を登録して明確な決定を下す方が適切です。無視された障害でいっぱいのデプロイメントログは、人々が障害の読み取りをやめることを教えます。

コマンドについては、存在する場合は目的に特化したモジュールを優先します。たとえば、ansible.builtin.service、ansible.builtin.systemd、ansible.builtin.copy、ansible.builtin.template、およびパッケージモジュールをシェルアウトの代わりに使用します。モジュールは通常、より優れた冪等性と、より明確なchangedおよびfailed状態を提供します。

ロールバックプレイブック

重要なデプロイメントでは、専用のロールバックプレイブックを用意します。これらのプレイブックは、対応するデプロイメントプレイブックによって行われた変更を元に戻すように設計する必要があります。

  • 01-database-migration-rollback.yml：スキーマの変更を元に戻します。
  • 02-deploy-application-rollback.yml：以前のアプリケーションバージョンをデプロイするか、バックアップを復元します。
  • 03-restart-services-rollback.yml：以前の状態でサービスを再起動します。

データベースのロールバックには特別な注意が必要です。新しいスキーマを使用して書き込みが開始された後、一部のマイグレーションは安全に元に戻せない場合があります。より安全なパターンは、多くの場合、拡張と縮小です：後方互換性のあるスキーマ変更を追加し、新旧両方の形状で動作できるアプリケーションコードをデプロイし、必要に応じてデータをバックフィルし、後続のデプロイメントで古い列またはフィールドを削除します。

そのモデルでは、ロールバックは通常、アプリケーションコードを元に戻し、互換性のあるスキーマをそのままにしておくことを意味し、プレッシャーのかかる状況で危険なデータベース変更を元に戻そうとはしません。

ロールバックトリガーの例： CI/CDパイプラインで04-smoke-tests.ymlプレイブックが失敗した場合、ロールバックプレイブックを逆順で実行します。

# 04-smoke-tests.ymlが失敗した場合：
ansible-playbook -i inventory.ini 03-restart-services-rollback.yml
ansible-playbook -i inventory.ini 02-deploy-application-rollback.yml
ansible-playbook -i inventory.ini 01-database-migration-rollback.yml

block、rescue、alwaysの使用

Ansibleのblock、rescue、always構造は、単一のプレイブック内でエラーを処理するためのより構造化された方法を提供します。プレイブック間のシーケンスには使用されませんが、失敗する可能性のある一連のタスクをカプセル化し、失敗した場合の対処を定義するのに優れています。

- block:
    - name: 新しいアプリケーションコードのデプロイ
      copy:
        src: /path/to/new/app/
        dest: /var/www/myapp/

    - name: アプリケーションサービスの再起動
      service:
        name: myapp
        state: restarted

  rescue:
    - name: 以前のバージョンへのロールバックを試行
      copy:
        src: /path/to/old/app/
        dest: /var/www/myapp/

    - name: ロールバック後のアプリケーションサービスの再起動
      service:
        name: myapp
        state: restarted

  always:
    - name: デプロイメント試行のログ記録
      debug:
        msg: "デプロイメント試行が終了しました。"

このアプローチは、単一のデプロイメントステージプレイブック内で関連するタスクをグループ化するのに役立ちます。

プレイブック間のロールバックについては、オーケストレーターに決定を任せます。CIパイプラインは、後のステージが失敗した場合にのみロールバックプレイブックを実行できます。AWXジョブワークフローは、同じ成功および失敗ブランチを視覚的にモデル化できます。ロールバックコマンドは退屈で練習されたものにしてください。

ステージ間でのリリース状態の受け渡し

シーケンシャルプレイブックは、多くの場合、共有リリース識別子を必要とします。たとえば、デプロイステージはどのアーティファクトをインストールするかを知る必要があり、スモークテストはどのバージョンを期待するかを知る必要があり、ロールバックは以前のバージョンを知る必要があります。

その状態を明示的に渡します：

ansible-playbook -i inventories/production.ini playbooks/02-deploy-app.yml \
  -e release_version=2026.05.24.3 \
  -e artifact_url=https://artifacts.example.com/myapp/2026.05.24.3.tar.gz

プレイブック内で、何が変更されたかを記録します：

- name: 現在のリリースマーカーを書き込む
  ansible.builtin.copy:
    dest: /opt/myapp/current-release.txt
    content: "{{ release_version }}\n"
    owner: root
    group: root
    mode: "0644"

そのマーカーはインシデント時に役立ちます。誰かがホストにSSHで接続したとき、ホストが実行していると信じているバージョンを確認できます。また、スモークテストプレイブックにマーカーを読み取らせ、期待されるリリースと比較させることもできます。

高度な考慮事項

プレイブック間の状態管理

場合によっては、あるプレイブックのタスクがその結果を別のプレイブックに通知する必要があります。これは次の方法で実現できます：

  • ファクトキャッシング： ファクトキャッシングが有効な場合、あるプレイブックによって収集されたファクトは、同じAnsibleセッション内で実行される後続のプレイブックで利用可能になります。
  • 一時ファイル/データベース： 重要なステータス情報または出力を一時ファイルまたは専用のステータステーブルに書き込み、後続のプレイブックが読み取ることができるようにします。

隠れた状態よりも明示的な状態を優先します。ファクトキャッシングは便利ですが、値が古い場合や、あるランナーでキャッシュが有効で別のランナーで無効な場合に混乱を招く可能性があります。リリースファイル、アーティファクトメタデータ、CI変数、デプロイメントレコードは検査が容易です。

バージョン管理とオーケストレーションツール

複雑なオーケストレーションの場合は、シーケンシャルAnsibleプレイブックをより高レベルのツールに統合することを検討します：

  • CI/CDパイプライン： Jenkins、GitLab CI、GitHub Actions、CircleCIなどのツールは、マルチステージデプロイメントの定義とトリガーに優れています。パイプライン設定内でansible-playbookコマンドのシーケンスを定義します。
  • Ansible Tower/AWX： エンタープライズグレードのオーケストレーションには、Ansible Tower（現在はAutomation Platform）またはそのオープンソース版であるAWXが、複数のプレイブックをチェーンできる複雑なジョブテンプレートをスケジュール、監視、管理するための堅牢なUIを提供します。

複数の人が同じシステムをデプロイする場合、集中オーケストレーションは利便性よりも制御に関係します。一貫したインベントリ、資格情報、監査ログ、承認、およびどのステージが失敗したかの可視的な履歴を提供します。これらの詳細は、本番インシデント中に重要です。

詳細制御のためのタグ付け

個別のステージに個別のプレイブックを推奨しますが、プレイブック内でタグを使用することもできます。単一のステージ（データベースマイグレーションなど）用の非常に大きなプレイブックがある場合、特定のタスクにタグを付け、ansible-playbook --tags <tag_name>を使用してそれらのみを実行できます。

これは、ステージ間のシーケンスよりも、ステージ内の詳細制御に関するものです。

マルチステージデプロイメントのベストプラクティス

  • プレイブックの焦点を絞る： 各プレイブックは1つのことをうまく実行する必要があります（例：データベースマイグレーション、アプリケーションデプロイ）。
  • プレイブックに明確に名前を付ける： ステージと順序を反映する命名規則を使用します（例：01-、02-）。
  • 冪等性を実装する： すべてのタスクが冪等であることを確認し、安全な再試行を可能にします。
  • ロールバックをテストする： ロールバック手順を定期的にテストして、期待どおりに機能することを確認します。
  • バージョン管理を使用する： すべてのプレイブックとインベントリファイルをバージョン管理システム（Gitなど）に保存します。
  • オーケストレーションを自動化する： CI/CDパイプラインまたはAnsible Tower/AWXなどのツールを使用して、シーケンシャルプレイブックの実行を自動化します。
  • ワークフローを文書化する： ステージ、その目的、依存関係、ロールバック手順を明確に文書化します。
  • スモークテストを現実的にする： 実際のエンドポイント、ログインパス、キュー worker、または重要なバックグラウンドジョブを確認します。単なるプロセスチェックでは不十分です。
  • 本番インベントリを保護する： ステージングと本番には個別のインベントリと資格情報を使用します。--limitのタイプミスで間違った場所にデプロイしないようにします。
  • 可能な場合はシリアルロールアウトを使用する： serialを使用すると、一度に数台のホストを更新し、フリート全体が影響を受ける前に停止できます。
- name: アプリケーションを段階的にデプロイ
  hosts: web
  serial: 2
  tasks:
    - name: リリースをインストール
      ansible.builtin.unarchive:
        src: "{{ artifact_path }}"
        dest: /opt/myapp/releases/{{ release_version }}
        remote_src: true

serialを使用すると、Ansibleはホストをバッチで処理します。アプリケーションをアクティブなリクエストをドロップせずに再起動できない場合は、ロードバランサーのドレインと組み合わせます。

具体的なデプロイメントフロー

Webアプリケーションの安全なAnsibleデプロイメントは次のようになります：

00-preflight.ymlは、ディスク容量をチェックし、ターゲットリリースが存在することを確認し、データベース接続を検証し、ホストが期待される環境にあることを確認します。システムは変更しません。

01-migrate-db.ymlは、後方互換性のあるマイグレーションのみを実行します。マイグレーションバージョンを記録し、データベースが要求されたリリースよりすでに進んでいる場合は失敗します。

02-deploy-app.ymlは、アーティファクトをダウンロードし、バージョン管理されたリリースディレクトリに解凍し、設定をテンプレート化し、currentシンボリックリンクを更新します。まだサービスは再起動しません。

03-reload-services.ymlは、各ホストをロードバランサーからドレインし、サービスをリロードまたは再起動し、ローカルヘルスエンドポイントを待ってから、ホストをサービスに戻します。

04-smoke-test.ymlは、ユーザーがたどるのと同じパスを通じてパブリックエンドポイントを呼び出します。ロードバランサーのデフォルトページからの単なる200ではなく、レスポンス本文またはバージョンエンドポイントをチェックします。

このフローは、1コマンドの再起動よりも低速です。また、デプロイが途中で失敗した場合の理由を推論するのがはるかに簡単です。

これを機能させる習慣

シーケンシャルAnsibleプレイブックは、各プレイブックが狭い契約を持つ場合に最も効果的です：何を期待するか、何を変更するか、成功をどのように証明するか、失敗した場合の対処法。その契約は、YAMLファイルの数よりも重要です。

実際のリスクを反映するステージから始めます：プリフライト、マイグレーション、デプロイ、リロード、スモークテスト、ロールバック。コマンドは退屈に保ちます。必要になる前にロールバックをテストします。デプロイメントが壊れた場合、正確にどのステージが失敗したかを指摘し、自動化ツリー全体を再読することなく次のステップを決定できる必要があります。