はじめに ITコンサルタントのKです。以前、Webサービスの新規開発に関わっておりました。機能開発の段階だったので、機能やビジネスロジックが正しいことの評価が大半で、運用の評価はもっと先という段階でした。 昨今のモダナイゼーションにおいて、開発と運用は切り離せない関係にあります。クライアントサーバー方式からクラウドネイティブなWebサービスへと進化させるプロジェクトを例に、 「継続的な価値提供」を支えるプロセスと品質の考え方 を、鉄道の仕組みになぞらえて紐解いてみたいと思います。 プロジェクトの背景：目指すのは「リカーリング型」への転換 プロジェクトは、レガシーな業務アプリをフルスクラッチでクラウド化するものです。単に「動けばいい」のではなく、ビジネスモデルを フロー型（切り売り）からリカーリング型（継続収益）へ転換すること を目的としています。 開発体制は社員が要件を作成後、開発と評価をそれぞれ別の会社に委託するという建付けです。開発会社が要件をプロダクトバックログに落とし込み、Agile開発で設計から結合テストまで実施します。評価会社はシステムテスト以降の担当です。 運用は自社で担当していましたが、サーバーの監視、障害対応、セキュリティ対策（パッチ適用、ウイルス対策）、バックアップというレガシーなインフラエンジニアでした。 顧客満足度を支える5つの要素 継続的な収益を得るためには、ユーザーにとっての「負」を排除し続けなければなりません。 直感的なUI/UX : 迷わず使える操作性 過不足ない機能性 : 障害やムダがなく、必要十分な機能 高速なレスポンス : ストレスのない処理速度 信頼性 : 高いSLAと安定稼働 保守の迅速性 : 障害修正や機能追加のスピード感 これらの価値を「当たり前」のものとして提供し続けることが、LTV（顧客生涯価値）の最大化に直結し、解約率の低減を実現します。 DevOpsの「8の字ループ」を鉄道に見立ててみる 開発と運用の連携を語る際によく使われる「DevOpsの8の字ループ」は、子供の頃に遊んだ 「プラレールの線路」 を思い出します。左右のループは、それぞれ「開発」と「運用」という別の組織（鉄道会社）が運営し、繋がった線路を相互に乗り入れます。 開発ループ ：　新たな価値を積んだコンテナ（機能）を載せ、運用へ送り出す。 運用ループ ：　現場の利用状況や障害という「情報」を載せて、開発へフィードバックする。 鉄道における「安定稼働」と「迅速さ」を両立させる知見は、そのままDevOpsのプラクティスに当てはめることができると思い、鉄道での取り組みを調べてみました。 鉄道の仕組みとDevOps施策の比較 鉄道の仕組みとDevOps・Agile・SREの施策を比較すると、同じような仕組みがあることがわかります。 顧客満足度の向上 を目的に据え、「SLI/SLOと基盤整備」・「エラーバジェットにより自動制御」・「開発と運用の相互協力」・「継続的な強靭性向上」といったステップで上記施策を選択・実行し、成熟度を高めていくことになるでしょう。 項目 鉄道における仕組み DevOps (全体像) Agile (開発側の動き) SRE (運用側の動き) 衝突防止 信号・閉塞 (区間内の車両制限) CI/CDパイプライン (自動テスト/ゲート) WIP制限 (開発速度の維持) カナリア・Blue-Greenデプロイ (段階的リリース) ATC (自動速度制御) 継続的モニタリング (ログ/メトリクス) スプリントの中止 (PO判断) エラーバジェット (SLOに基づくリリース制限) 相互乗り入れ 車両規格統一・乗務員訓練 シフトレフト/ライト (開発・運用境界の解消) シフトライト (運用考慮の設計・非機能要件) シフトレフト (開発段階での信頼性への関与) 無線/信号共通化 (リアルタイム監視) APM (性能監視/最適化) アジャイルKPI (進捗・ベロシティ計測) SLI・SLO (可観測性の監視) 貨物効率化 規格化コンテナ (積み替え容易) コンテナ化 (環境依存解消・スケーリング) マイクロサービス化（機能の独立・パッケージ化） コンテナ運用 (安定運用と負荷・効率の最適化) コンテナ/列車位置管理 (リアルタイム情報提供) バリューストリームの可視化 (進捗のリアルタイム共有) カンバン (作業フローの可視化) コンテナ運用ツール (デプロイ・監視・スケーリング・保守) 強靭性 災害時の迂回・縮退運転計画 マルチクラウド・マルチリージョン (即時に稼働移動) フィーチャーフラグによる縮退運転機能 (基幹機能の維持) カオスエンジニアリング (耐障害性テスト) 品質管理の変革：評価部門は「門番」から「パートナー」へ この「鉄道網」のようなプロセスを回すとき、品質保証のあり方も変わらなければなりません。 前プロジェクトにおける評価部門は、リリース直前に立ちはだかる「門番」でしたが、保守運用が中心となるモダナイズ後の世界では、 「信頼性のガードレールを構築するパートナー」 への転換が求められます。 具体的な施策 SLO （サービスレベル目標）の共有 : 「不具合ゼロ」ではなく、SLOを全員の共通ゴールにします。これにより、全員が「攻め（新機能）」と「守り（信頼性）」のバランスを自分事として考えられるようになります。 エラーバジェットとバックログの連動 : エラーバジェット（許容できる失敗の枠）が枯渇した際、即座に「信頼性向上タスク」を優先するルールをバックログ運用に組み込みます。POが責任を持ち、新規機能と改善を両立します。 テストの自動化とテスト環境のコード化 : 評価部門はテストを代行するのではなく、開発・運用がセルフまたはCI/CDで利用できる「高精度なテスト環境（IaC、AIエージェント指示書（AGENTS.md））」と「自動テストスイート」を提供します。AI駆動開発では評価ハーネスを構築します。 SRE視点での信頼性テスト 独立した評価部門が関わる場合、以下のようなテストを「開発の早い段階（シフトレフト）」と「リリース後の運用段階（シフトライト）」に分けて組み入れます。継続的にテストできるよう「テストを自動化し、開発・運用に環境をフィードバックする仕組み」を構築することで「安定稼働」と「迅速さ」に貢献できます。 テスト種別 内容 SREにおける目的 負荷・ストレステスト 限界値やスパイクアクセスを確認 SLOを維持できる最大キャパシティの把握 カオスエンジニアリング 意図的に障害を注入 自己修復能力と監視・発報の妥当性確認 DR（災害復旧）テスト リージョン切り替え等を試行 RTO（目標復旧時間）がSLO内かの確認 オブザーバビリティテスト 擬似異常によるアラート確認 「未知の異常」を検知できるかの確認 最後に：外部委託における「SRE」の法的リスクと対策 ここまではプロセスや文化の話でしたが、実務上の大きな壁となるのが 「委託契約」 です。安全な運行を支えるのは、車両や信号（技術）だけでなく、鉄道会社間の『運行規定（ルール）』であるのと同様に、ITの世界でも『契約』が重要です。SREのアプローチを外部委託する場合、以下の4点に注意が必要です。 準委任契約における「善管注意義務」 ： エラーバジェット枯渇による「開発停止」が、委託範囲に含まれていないと、発注側から「予定の成果が出ない」とクレームになり、受注側は「契約外の改善を強いられた」と紛争化するリスクがあります。 請負契約における納期遅延 ： SREの判断でデプロイを止めた場合、法的観点では「発注者側の都合による履行不能」とみなされ、ベンダーから納期延長や追加費用を請求される根拠になり得ます。 偽装請負の懸念 ： 発注側のSREチームが、ベンダーの開発者に対して直接「予算が尽きたからバグ修正に全リソースを割け」と細かく指示を出すと、指揮命令権の問題（偽装請負）が生じる可能性があります。 納品物の著作権 ： AI駆動開発における評価基盤の構築（ハーネスエンジニアリング等）において、AIエージェントを活用して評価プロセスを自動化する際に、テスト観点等をルールとして提供することがあります。再利用性が高い知見をそのまま納品することになるので、著作権への配慮や暗号化するなどの対応が必要となります。 解決のためのアクション これらのリスクを避けるためには、契約段階で 「SLA/SLOの仕組みそのもの」を合意事項に組み込む ことが不可欠です。「エラーバジェットが枯渇した際は、優先順位を動的に変更する」というルールを業務範囲として定義しておくことが、健全なDevOps運用の第一歩となります。 モダナイゼーションは、単なる技術の刷新ではありません。開発・運用・そして契約を含めた「文化の刷新」であることを、改めて意識していきたいものです。 The post 「止まらない鉄道」に学ぶ、モダンなシステム開発とSREの品質管理　〜業務システムのクラウド化と、評価部門の新たな役割〜 first appeared on Sqripts .

はじめに こんにちは、サイオステクノロジーの小沼 俊治です。 「理屈はいいから、まずは実際に CI/CD パイプラインというものを動かして体験してみたい」。 本記事は、そんな方々に向けて、ソフトウェア開発に不可欠な CI/CD の基礎を手を動かしながら学習できる、実践的な入門ガイドとして用意しました。 単なるビルドやデプロイの自動化にとどまらず、近年その重要性が叫ばれている「サプライチェーンセキュリティ（SBOM の活用）」や「脆弱性可視化」、さらには検証フェーズとして独立したジョブで実行する「動的セキュリティテスト（DAST）」までを包括したパイプライン環境を無料で体験できるハンズオンを提供します。 本ハンズオンでは、以下のオープンソース・プロダクトのみで構成された環境をコンテナを使って一括で立ち上げ、ソースコードのコミットからセキュリティチェック、そして本番デプロイに至るまでの一連の流れを体験していただきます。 Jenkins: パイプライン実行 GitLab: ソースコード管理 Dependency-Track: SBOM / 脆弱性可視化 Google OSV (Open Source Vulnerabilities): 脆弱性データベース Artifactory: アーティファクト管理 Ansible: デプロイプロセス自動化 OWASP ZAP: 動的セキュリティテスト (DAST) なお、本記事は「CI/CD のプロセスそのもの」を体感していただくことを主目的としています。そのため、複雑になりがちな環境構築の手順解説はあえて割愛しており、「まずは動かしてみたい」という方に最適です。もし環境構築の裏側に興味を持っていただいた場合は、ぜひ GitHub リポジトリの設定ファイルを解析してみてください。 構成概要 ハンズオン環境の構成 筆者が動かした際の主な構成要素は以下の通りです。 Windows 11 Professional WSL 2.5.9.0 Ubuntu 24.04.3 LTS Docker Engine 28.4.0 Jenkins GitLab 18.2.4 Dependency-Track JFrog Artifactory OSS Ansible OWASP ZAP Windows (WSL) 以外のOSをご利用の方も、条件が満たしていれば以下の手順からハンズオンを進められます。 Ubuntu (Linux) 環境の方: WSL の構築は不要なため、「 Docker Engine 環境の構築 」章から開始してください。 macOS 環境の方: Docker Desktop for Mac などでコンテナ実行環境が準備済みであれば、「 ハンズオンに必要なコマンドの準備 」章から開始してください。 ハンズオンを構成する環境は以下の通りです。 CI/CD パイプラインを構成するツール群、およびデプロイ先となるサーバーをすべてコンテナとして構築します。 Jenkins：CI/CD の中核として、ジョブやパイプラインの実行を管理します。 GitLab：ビルド対象となるソースコードを管理します。本ハンズオンでは、ここでのマージがパイプラインを起動するトリガーとなります。 Dependency-Track：ビルド時にパッケージと一緒に生成したソフトウェア部品表（SBOM）を取り込み、脆弱性の有無を分析・可視化します。 Artifactory：Maven リポジトリのプロキシとして機能するほか、ビルドして生成された成果物（アーティファクト）をプロダクション環境（本番環境）へデプロイするために保管します。 Ansible：事前に定義された Playbook（インストール手順書）に従い、Artifactory にあるアーティファクトを利用してプロダクション環境へデプロイします。 OWASP ZAP：Jenkins の verify-dast-webapp ジョブから Docker-out-of-Docker (DooD) の仕組みを利用してコンテナを一時的に構築し、動的セキュリティテスト（DAST）を実施します。 Web アプリケーション（Ubuntu）：デプロイ対象となるプロダクション環境のアプリケーションサーバーです。 Dependency-Track コンテナの構築には、OWASP Foundation が公開している docker-compose の YAML ファイルを取得して使用します。 https://dependencytrack.org/docker-compose.yml Artifactory コンテナの構築には、JFrog 社が公開している docker-compose の YAML ファイルを取得して使用します。 Community – Download Artifactory OSS デプロイ対象の Web アプリケーションは、プレゼンテーション層のフロントエンド、アプリケーション層の Web API、そしてデータ層のデータベースから成る三層アーキテクチャーで構成されています。 このうち「フロントエンド」と「Web API」を CI/CD パイプラインによるデプロイの対象とし、データベース（MySQL）については、コンテナ構築時に作成した環境をそのまま利用するためデプロイ対象になりません。 CI/CD の実演では、以下のリポジトリから Web アプリケーションのソースコードをダウンロードし、ハンズオン環境内に構築した GitLab のリポジトリへコミットすることで、CI/CD の一連の流れを体験します。 Toshiharu-Konuma-sti/hands-on-rollingdice-webapp 単にツールを動かすだけでなく、シーンごとに以下の登場人物になりきって実際の開発現場を想定したロールプレイング形式で進めます。 開発担当：ソースコードの実装や修正を行い、GitLab へコミットします。レビューアーへレビュー依頼として、マージリクエスト（プルリクエスト）を作成します 。 レビューアー：開発担当から起案されたマージリクエストを元にコードをレビューし、問題なければマージを行います 。 運用担当：CI/CD パイプラインの実行状況を監視します。 ユーザー：プロダクション環境へデプロイされた Web アプリケーションを操作して楽しみます 。 環境構築や各種設定に使用するそれぞれのファイルは、以下の GitHub リポジトリで公開しています。 Toshiharu-Konuma-sti/hands-on-jenkins $ tree ~/handson/hands-on-jenkins/ hands-on-jenkins/ |-- container/ …… 「環境構築」章でコンテナ作成で使う素材 | |-- docker-compose.yml | |-- docker-compose-webapp.yml | : | |-- setup/ …… 「環境構築」章でツール準備の環境準備に必要な素材 | |-- SETUP_HANDS-ON.sh | : | `-- try-my-hand/ …… 「ハンズオン実施」章で CI/CD の実演を進める環境 |-- PREPARE_LOCAL_GIT_REPO_TO_PUSH.sh : CI/CD の概要 ハンズオンで実演する CI/CD の流れを DevOps のライフサイクル（Infinity Loop）に当てはめると、以下の工程が該当します。 Code (GitLab)：ソースコードの開発とレビューを実施し、バージョン管理ツールでソースコードを管理します。 Build (Jenkins)：バージョン管理ツールから取得したソースコードをビルドしてローンチ候補のパッケージを生成します。 Test (Jenkins, Dependency-Track, OWASP ZAP)：ローンチ候補のソースコードやパッケージを元にテストやセキュリティ検査を実施します。 Release (Artifactory)：ローンチ対象のパッケージをアーティファクト管理ツールに保存・管理します。 Deploy (Ansible)：アーティファクト管理ツールからパッケージを取得し、プロダクション環境へインストールします。 CI/CD のハンズオンでは、Operate（運用）、Monitor（監視）、Plan（計画）の工程は対象外となります。 開発者によるソースコードの開発から、プロダクション環境へデプロイするまでの一連の CI/CD フローを示します。 GitLab：開発を終えたソースコードを開発者がプッシュし、レビューアーがソースコードをマージします。これを契機に、Webhook で Jenkins へ最新版のソースコードが登録されたことを通知します。 Jenkins（ビルドジョブ）：通知を受けると GitLab からソースコードを取得し、ビルドを行ってパッケージを生成してからテストを実行します。テストに成功するとパッケージを Artifactory に登録します。 Artifactory：デプロイ対象のパッケージ（アーティファクト）を保管・管理します。 Jenkins（デプロイジョブ）：デプロイ実行の司令塔となり、Ansible と連携してプロダクション環境を最新の構成に更新します。 Ansible：Artifactory にある最新のアーティファクトを利用し、人手を介さずにプロダクション環境へ自動的にデプロイします。 DASTは、本来ビルドジョブ内で自動実行するのが理想です。しかし、スキャン完了までに10分以上かかる場合があるため、本ハンズオンではスムーズな進行を優先し、専用ジョブ（verify-dast-webapp）として独立させています。 DevOps の Code 工程において、品質を担保しつつ効率的にソースコードの開発を進めるには、適切なソースコード管理（ブランチ戦略）が欠かせません。 本ハンズオンでは GitHub Flow をベースとした手法を用いて、プロダクション環境用の main ブランチと開発作業用のブランチを明確に分けることで、安全で効率的な開発フローを実現します。 各ブランチの役割は以下の通りです。 main ブランチ：プロダクション環境と常に同じ状態を保つ「安定版」のブランチです。このブランチへのマージがプロダクション環境へのデプロイのトリガーとなります。 feature/* ブランチ：新しい機能の開発を行うためのブランチです。 main から枝分かれして作成し、開発とコードレビューが完了した後に、再び main へマージします。 hotfix/* ブランチ：プロダクション環境で発生した緊急のバグ修正専用のブランチです。通常の開発とは別に、迅速な対応が求められる際に利用します。 開発者は feature/* や hotfix/* といった作業ブランチを作成して開発を進めます。直接 main ブランチに開発した差分をコミットしません。 開発が完了した作業ブランチは、必ずレビューアーの承認を経てから main ブランチにマージされます。 基礎環境の構築 WSL 環境の構築 Windows PC（社用標準 PC）の場合には、 以下手順を参考に WSL と Linux ディストリビューション（Ubuntu）環境を用意します。 初期環境構築: WSL 環境 on Windows Docker Engine 環境の構築 コンテナ環境を使うため、以下手順を参考に Ubuntu へ Docker Engine 環境を用意します。 初期環境構築: Docker Engine on Ubuntu ハンズオンに必要なコマンドの準備 本ハンズオンの実施には、以下のコマンドやランタイムが必要です。 これらは主に、環境構築やリポジトリ準備を行う際に使用します。 JDK 21：Jenkins の設定を操作する CLI ツール（ jenkins-cli ）の実行環境として必要です。 通信先となる Jenkins サーバーが JDK 21 で稼働しているため、クライアント側もバージョンを統一する必要があります。 利用箇所： CI/CD 連携設定スクリプトの実行 （Jenkins ジョブ登録時） jq コマンド：API のレスポンス（JSON 形式）から、特定の値を抽出・整形するために使用します。 利用箇所： CI/CD 連携設定スクリプトの実行 （GitLab 連携設定時） unzip コマンド：GitHub から取得した Web アプリケーションのソースコード（Zip 形式）を展開するために使用します。 利用箇所： ローカルリポジトリ準備スクリプトの実行 （既存のアプリ開発を模した「ローカルリポジトリ環境」の準備時） インストールされていない場合は、以下手順を参照して Ubuntu 環境へ用意します。 初期環境構築: ユーティリティツール on Ubuntu CI/CD 環境の構築 GitHub からハンズオン用のリポジトリ取得 ハンズオンを進めるための環境構築用の設定ファイルやスクリプトを含んだリポジトリを GitHub からダウンロードして取得します。 本章ではターミナルを使用してハンズオン用の作業ディレクトリを作成して作業を実施します。 $ mkdir -p ~/handson/ $ cd ~/handson/ 「 $ git clone 」コマンドで本ハンズオン用のリポジトリを取得します。 $ git clone https://github.com/Toshiharu-Konuma-sti/hands-on-jenkins.git $ cd hands-on-jenkins/ コンテナ構築スクリプトの実行 本章ではターミナルを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-jenkins/container/ コンテナ構築用に用意してあるスクリプトを実行して、CI/CD 環境の各種コンテナを構築します。 $ ./CREATE_CONTAINER.sh コンテナが構築されてから Jenkins と GitLab の初期パスワードの準備までに少々時間がかかるので、暫く待った後に info オプションを付けてスクリプトを実行すると、Jenkins および GitLab の初期パスワードと、後続の環境構築手順概要を表示することができます。 $ ./CREATE_CONTAINER.sh info /************************************************************ * Information: * - Navigate to Web ui tools with the URL below. * - Jenkins: http://localhost:8080 * - Artifactory: http://localhost:8082 * - GitLab: http://localhost:13000 * - Dependency-Track: http://localhost:8981 * - Navigate to the deployed webapp with the URL below. * - webapp: http://localhost:8181 ***********************************************************/ - Password: - Jenkins Default: 66aa56faf61f47ddaed8c0f5777679a6 - GitLab root user: fNvqnjyFC08DMXNov1X0z+zLrc2rxY7CbjMI1SZMFu4= - Setup Instructions: 1. Go to Jenkins and apply JCasC: /var/jenkins_home/my-config/jcasc/jenkins.yaml : なお、コンテナ構築スクリプトで実行する内容は以下を参照してください。 コンテナ構築スクリプトの解説 Jenkins の基礎設定 本章ではブラウザを用いて作業を実施します。 初期セットアップ Jenkins で推奨されているプラグインのインストールと Admin ユーザの作成を行います。 Jenkins へブラウザでアクセスし、初期パスワードを入力のうえ「Continue」ボタンをクリックしてセットアップを開始します。 http://localhost:8080 Administrator password：テキストボックス上部に書かれている、Jenkins コンテナ内のファイルパスから取得して入力します。（「 コンテナ構築スクリプトの実行 」章を参照、もしくは、ターミナルで $ docker container exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword コマンドを実行して取得できます） 「Install suggested plugins」を選び、推奨するプラグインをインストールします。 インストールの経過をしばらく待ちます。 Admin ユーザーを作ります。 ユーザー名：「admin」を入力します。 パスワード：「password」を入力します。（別の値を入力した場合は「 variables.sh#L14 」の定義も変更します） フルネーム：「admin」を入力します。 メールアドレス：「admin@example.com」を入力します。 URL はデフォルト値のままで変更せずに「Save and Finish」ボタンをクリックします。 「Restart」ボタンをクリックすれば、初期セットアップは完了です。 JCasC の適用 Jenkins の各種設定は、画面右上の歯車アイコンをクリックすると表示する「Jenkins の管理」で GUI で設定を行いますが、本ハンズオンでは Jenkins Configuration as Code（JCasC）を使い、設定ファイル（yaml）から一括で適用します。設定される内容は以下章を参照してください。 JCasC 適用内容の解説 トップ画面に遷移したら画面右上の歯車アイコンをクリックすると表示する「Jenkinsの管理」メニューをクリックします。 Jenkins の管理項目から「Configuration as Code」を選択します。 画面中央の「Setup configuration」ボタンをクリックします。 「Path or URL」へ JCasC の実装で用意した YAML ファイルのパスを入力し、「Apply configuration」ボタンをクリックして JCasC ファイルを適用させます。 Path or URL：「/var/jenkins_home/my-config/jcasc/jenkins.yaml」を入力します。（ファイルの中身は「 jenkins.yaml 」を参照） JCasC で定義された各種設定が反映されました。 Artifactory のリポジトリ作成 本章ではブラウザを用いて作業を実施します。 ローカルリポジトリ作成 Jenkins のジョブでビルドしたアーティファクトを格納するリポジトリを用意します。 ブラウザで Artifactory へアクセスして、admin ユーザーで初期パスワードを入力してログインします。 http://localhost:8082 Username：「admin」を入力します。 Password：初期パスワードの「password」を入力します。 Welcome 画面にて「Create a Repository」ボタンをクリックします。 画面右上の「Create a Repository > Local」のメニューを選択します。 パッケージタイプの一覧から「Gradle」を選択します。 New Local Repository 画面にて「Repository Key」にリポジトリ名を入力して「Create Local Repository」ボタンをクリックします。 Repository Key：「hands-on-rollingdice-webapp-webapi」を入力します。 表示されたポップアップウィンドウで「Add Users」は押さずに、ウィンドウの右上の×ボタンで閉じます。 ここまでの「hands-on-rollingdice-webapp-webapi」リポジトリを作った同じ手順で、「hands-on-rollingdice-webapp-webui」リポジトリも作ります。 リポジトリの作成で入力する値は以下の通りです。 パッケージタイプ：「Gradle」を選択します。 Repository Key：「hands-on-rollingdice-webapp-webui」を入力します。 リモートリポジトリ作成 ビルドする際に Maven Repository をプロキシしてキャッシュとして機能するリポジトリを用意します。 リポジトリ一覧画面で右上にある「Create a Repository」ボタンをクリックすると表示するメニューから「Remote」を選択します。 Select Package Type で「Gradle」を選択して New Remote Repository 画面に遷移します。画面内で「Repository Key」にリポジトリ名を入力して「Create Remote Repository」ボタンをクリックしてリポジトリーを作成ます。 Repository Key：「maven-central-remote」を入力します。 URL：デフォルトで入っている URL のままにします。 バーチャルリポジトリ作成 ここまでに作成したローカルリポジトリとリモートリポジトリを一つにまとめ、単一のアクセスポイントで機能するリポジトリを用意します。 リポジトリ一覧画面で右上にある「Create a Repository」ボタンをクリックすると表示するメニューから「Virtual」を選択します。 Select Package Type で「Gradle」を選択して New Remote Repository 画面に遷移します。画面内で「Repository Key」にリポジトリ名を入力したら「Repositories」セクションまで画面をスクロールします。 Repository Key：「gradle-virtual」を入力します。 Repositories セクションで左側リストに表示されているここまでの手順で作成した Available Repositories（ローカルリポジトリ2つと、リモートリポジトリ1つ）を「>>」ボタンをクリックして、右側リストの Selected Repositories に移します。「Create Virtual Repository」ボタンをクリックしてリポジトリーを作成します。 ハンズオンで必要なローカルリポジトリ、リモートリポジトリ、およびバーチャルリポジトリが全て揃った状態のリポジトリ一覧画面は、以下の構成になります。 CI/CD 環境セットアップスクリプトの実行 Jenkins へのジョブ登録や GitLab のプロジェクト作成などを、スクリプトを使って一気に行います。これにより、複雑な連携設定を手動で行う手間を省きます。 本章ではターミナルを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-jenkins/setup/ セットアップ用に用意してあるスクリプトを実行して、CI/CD 環境の各種設定を行います。コンテナ構築直後は GitLab が完全に起動していない場合があり、スクリプトは GitLab の Web API が応答するまで自動的にリトライを繰り返しますので、完了するまでそのままお待ちください。 $ ./SETUP_HANDS-ON.sh コマンドが足りずにスクリプトが終了した際は、以下を参照してインストールしてください。 初期環境構築: ユーティリティツール on Ubuntu セットアップ用のスクリプトで実行する内容は以下を参照してください。 CI/CD 環境セットアップスクリプトの解説 CI/CD の実演 環境構築が完了しましたので、いよいよここから実際の開発フローによる CI/CD を体験していきます。 「 CI/CD の概要 」章でも説明した CI/CD フローを、開発者、レビューアー、運用者などの役割を演じながら、コードの変更がどのようにパイプラインを通過し、プロダクション環境へデプロイされるかを確認しましょう。 GitLab ローカルリポジトリ準備 GitLab 上のリポジトリを確認し、ローカル環境にソースコードを準備します。まずは開発担当の視点から開始します。 初期状態のリモートリポジトリ確認 CI/CD の実演で使用するリポジトリが作成されているか確認します。 ブラウザで GitLab へアクセスして、root ユーザーでログインします。 http://localhost:13000/root/webapp-webapi ユーザー名：「root」を入力します。 パスワード：gitlab コンテナ内の「/etc/gitlab/initial_root_password」に書かれている初期パスワードを入力します。 （「 コンテナ構築スクリプトの実行 」章を参照、もしくは $ docker container exec gitlab cat /etc/gitlab/initial_root_password コマンドで取得できます） Web API のソースコードを管理する「webapp-webapi」リポジトリが存在していて、「README.md」ファイルのみが存在する初期状態であることを確認します。 同様にフロントエンドのソースコードを管理する「webapp-webui」リポジトリについても確認します。 なお、「webapp-webapi」と「webapp-webui」のリポジトリは、「 CI/CD 連携設定スクリプトの実行 」章で実行したスクリプトで作成しています。 ローカルリポジトリ準備スクリプトの実行 通常であれば、ここで初期状態の Git リポジトリを git clone してゼロから Web アプリケーションのソースコードを実装するところですが、本ハンズオンでは CI/CD の体験に集中するため、「実装済みのソースコード」を一括で適用するスクリプトを用意しています。これにより、面倒な準備なしで、すぐに CI/CD の実演（ハンズオン）を始められる状態を作ります。 本章ではターミナルを用いて以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-jenkins/try-my-hand/ GitLab から初期状態のリモートリポジトリを取得して、実装された Web アプリケーションのソースコードをローカルリポジトリへ用意するスクリプトを実行して、リモートリポジトリへプッシュできる状態を準備します。 $ ./PREPARE_LOCAL_GIT_REPO_TO_PUSH.sh 本ハンズオンでは一からのコーディング作業を省略するため、以下のリポジトリから各種ハンズオン向けに用意してある Web アプリケーションのソースコードを取得し、実装が完了した状態を再現して進めます。 Toshiharu-Konuma-sti/hands-on-rollingdice-webapp ローカルリポジトリ準備スクリプトで実行する内容は以下を参照してください。 ローカルリポジトリ準備スクリプトの解説 GitLab リモートリポジトリ更新（webapi） ローカルリポジトリに Web アプリケーションの実装が完了しました。 ここからは、この変更をリモートリポジトリへ反映し、CI/CD パイプラインを始動させるまでの流れを体験します。 ローカルからリモートリポジトリへプッシュ ローカルリポジトリに実装した Web アプリケーションをリモートリポジトリへ反映して CI/CD の実演を本格的に開始します。 「webapp-webapi」リポジトリから開始するため、以下のディレクトリで作業を実施します。 $ cd ~/handson/hands-on-jenkins/try-my-hand/webapp-webapi/ 既に Web アプリケーションが実装された状態を再現しているため、ローカルリポジトリにソースコードや設定ファイルの差分が生じていることが確認できます。 $ git status ブランチ feature/sample 追跡されていないファイル: (use "git add <file>..." to include in what will be committed) .gitattributes .gitignore RUN.sh build.gradle : nothing added to commit but untracked files present (use "git add" to track) 差分のファイルをコミット対象として登録します。 $ git add . リモートリポジトリへプッシュするためにローカルリポジトリへ登録します。 $ git commit -m "implement the source code of the web app" 28 files changed, 2009 insertions(+) create mode 100644 .gitattributes : create mode 100644 src/test/java/jp/sios/apisl/handson/rollingdice/webapp/webapi/util/UtilEnvInfoTest.java ローカルリポジトリで開発した開発用ブランチ ( feature/sample ) をリモートリポジトリへプッシュします。 $ git push --set-upstream origin feature/sample Username for 'http://localhost:13000': root Password for 'http://root@localhost:13000': Enumerating objects: 63, done. : branch 'feature/sample' set up to track 'origin/feature/sample'. Username for ‘http://localhost:13000’：「root」を入力します。 Password for ‘http://localhost:13000’：gitlab コンテナ内の「/etc/gitlab/initial_root_password」に書かれている初期パスワードを入力します。 （「 コンテナ構築スクリプトの実行 」章を参照、もしくは、ターミナルで $ docker container exec gitlab cat /etc/gitlab/initial_root_password コマンドを実行することで取得できます） リモートリポジトリでマージリクエスト作成 ソースコードのプッシュが完了したら、GitLab 城で「マージリクエスト（プルリクエスト）」を作成してレビューを依頼します。 ブラウザで GitLab にアクセスし、トップページ、もしくはリポジトリページに「Create merge request」ボタンが掲示されている場合には、該当のボタンをクリックしてマージリクエストの作成を開始します。 http://localhost:13000/root/webapp-webapi 「Create merge request」ボタンが掲示されていない場合には、左ペインのメニューから「Pinned > Merge requests」を選択し、画面中央部にある「New merge reuqest」ボタンを押下してマージリクエストの作成を開始します。 マージリクエストの対象となるマージしたいブランチを指定して、「Compare branches and continue」ボタンをクリックします。 Source branch：マージしたい開発した最新のソースコードを含む「 feature/sample 」ブランチを指定します。 Target branch：マージ先となるプロダクション環境と同じ状態を保っている「 main 」ブランチを指定します。 マージリクエストの情報を入力するフォームが表示されるので、Title、Description など必要な項目の入力を進めます。 情報の入力フォームの画面下部に存在する「Create merge request」ボタンをクリックしてマージリクエストを作成します。 出来上がったマージリクエストをレビューアーに提示して、開発担当からレビューアーにバトンタッチしてレビューフェーズに進みます。 GitLab でコードレビューとマージ 開発担当がコーディングしたソースコードや設定ファイルをレビューアーがレビューを実施し、品質に問題が無ければ承認、およびマージして、DevOps の Code 工程を完了します。この章はレビューアーの視点になります。 レビューアーとしてブラウザで GitLab にアクセスし、左ペインのメニュー一覧より「Merge requests」を選択してマージリクエストの一覧を表示します。一覧に開発担当が作成したレビュー待ちのマージリクエストがあるので、クリックしてレビューを開始します。 http://localhost:13000/dashboard/merge_requests マージリクエストがアクティブになりましたので、「Change」タブをクリックして差分表示に切り替えます。 マージ前後の差分表示になっているので、こちらを利用してソースコードの変更点をレビューします。 レビューが問題なければ「Overview」タブをクリックして「Approve」ボタンをクリックして承認します。続けて「Merge」ボタンをクリックすると開発用の「 feature/sample 」ブランチが「 main 」ブランチへマージされレビューは完了です。 直後に GitLab から Jenkins へ Webhook で「 main 」ブランチにマージが発生したことの通知が飛び、Jenkins ではビルドジョブが自動的に開始します。次章でその様子を確認しましょう。 Jenkins ビルドジョブ実行（webapi） GitLab で「 main 」ブランチへのマージが完了すると、Jenkins 側で自動的にビルドジョブが開始されます。 その様子と、実行されたセキュリティチェックの結果を確認しましょう。この章は開発担当がメインとなりますが、レビューアーと運用担当も関わりを持ちます。 ビルドジョブ実行確認 ビルドジョブが実行されるので確認します。 ジョブの一覧から自動的に実行開始された「build-webapp-webapi」ジョブをクリックして詳細情報に遷移します。 Stage View で、ビルドジョブを構成するステージが順に実行されていることと、各ステージの処理に掛かった時間も確認することができます。 順にステージの実行を繰り返し、「Declarative: Post Actions」ステージまで到達するとジョブも完了です。Stage View の最左列のジョブ番号（例：[#1]）をクリックしてビルドジョブの結果詳細を見てみましょう。 ビルドジョブ結果確認 ビルドジョブの完了後、生成された各種レポートや成果物を確認してプロダクトの品質を評価します。 本ハンズオンのパイプラインには、「品質（Quality）」と「セキュリティ（Security）」の検証に加え、「仕様の可視化（Visibility）」を行うため、以下のプロセスが組み込まれています。 これらの結果から改善点を見つけ出し、コードを修正して再びプッシュする ―― このサイクルを回すことで、品質と安全性を継続的に向上させます。 SCA (Software Composition Analysis)：Dependency-Track を使用し、利用している OSS ライブラリに既知の脆弱性がないかを分析します。 単体テスト (Unit Testing)：JUnit を使用し、プログラムの機能が正しく動作するかを検証します。 SAST (Static Application Security Testing)：SpotBugs と PMD を使用し、ソースコード等の不具合やセキュリティホールの原因となる記述を検出します。 Linter：CheckStyle を使用し、コードの書き方（インデントや命名規則など）が規約に沿っているかをチェックします。 ドキュメント生成 (Documentation)：ソースコードから Javadoc や OpenAPI 仕様書を自動生成し、実装と乖離のない最新の仕様を可視化します。 ビルドジョブの結果ページでは、脆弱性の解析や静的コード解析などの各種結果のサマリー表示と、結果の詳細情報へ遷移するリンクで構成されています。 Dependency-Track と連携した脆弱性解析の結果レポートです。一覧の各行で「Name」列の先頭にある「+」ボタンをクリックすると、展開表示で各脆弱問題に対する対処方法も確認できます。 JUnit による単体テストの実行結果のレポートです。アプリケーションを構成するパッケージごとに、単体テストの実行に掛かった所要時間、成功数や失敗数などが確認できます。 単体テストのカバレッジのレポートです。テストコードがプロダクションのソースコードをどれだけ網羅しているか確認することができます。 SpotBugs による静的な検証結果のレポートです。実行時エラーに繋がるバグの発見など、動かなくなるリスクの回避を手助けします。 PMD による静的な検証結果のレポートです。非効率や冗長なコードなどによる、保守しにくいリスクの回避を手助けします。 CheckStyle による静的な検証結果のレポートです。コーディング規約の違反など、読みにくいリスクの回避を手助けします。 ソースコードから生成された Javadoc 形式のプログラム仕様書を確認できます。 Web API を対象とした「build-webapp-webapi」ビルドジョブでは、ソースコードから生成された OpenAPI 形式の API 仕様書も確認できます。 GitLab リモートリポジトリ更新 ～ Jenkins ビルドジョブ実行（webui） ここまでの手順で、Web API のソースコードを管理する「webapp-webapi」リポジトリのビルドまでが完了しました。次は、フロントエンドのソースコードを管理する「webapp-webui」リポジトリを対象に同じ手順を実行してビルドまで実施します。以下の各章内の説明で「webapi」を「webui」に読み替えて実行します。 GitLab リモートリポジトリ更新（webapi） 対象ディレクトリを webapp-webui に読み替えて、プッシュおよびマージリクエストの作成を行います。 GitLab でコードレビューとマージ 対象リポジトリを webapp-webui に読み替えて、コードレビューおよびマージを行います。 Jenkins ビルドジョブ実行（webapi） Jenkins 上で build-webapp-webui ジョブが実行されることを確認します。 Artifactory リポジトリ確認 Jenkins で「build-webapp-webapi」と「build-webapp-webui」の各ビルドジョブが完了すると、各ビルドジョブでリリースされたアーティファクトが Artifactory に登録されていることが確認できます。これがデプロイの原資となります。この章あたりから、運用担当がメインとなってきますが、開発担当とレビューアーも関わりを持ちます。 Artifactory の画面上部で「Platform」タブがアクティブな状態で、左ペインのメニューから「Artifactory > Artifacts」を選択するとリポジトリツリーが表示します。ツリーから事前に作成したローカルリポジトリをクリックしてツリーを展開すると、ローカルリポジトリに登録されたアーティファクトを表示することができます。 一覧で一つアーティファクトを選んでいる状態で、「Properties」タブをアクティブにするとビルド時の情報が確認できます。 「apisl.handson.rollingdice.webapp.webapi-0.0.1-SNAPSHOT.jar」と「apisl.handson.rollingdice.webapp.webui-0.0.1-SNAPSHOT.jar」のアーティファクトが登録されていることが確認できたら、アプリケーションレイヤーにデプロイする Jenkins のデプロイジョブの実行に進みます。 Jenkins デプロイジョブ実行 Jenkins のデプロイジョブから Ansible と連携して、Artifactory に登録されているアーティファクトをアプリケーションレイヤーのアプリケーションサーバーにデプロイし、Web アプリケーションを構築します。この章は運用担当の視点になります。 Jenkins のジョブ一覧から「deploy-webapp」デプロイジョブを選択します。 デプロイジョブは Jenkins 自身でジョブを開始するため、左ペインのメニューから「ビルド実行」をクリックしてジョブを実行します。 全てのタスクが完了すると Web アプリケーションの構築が完了しました。 このジョブの中で、Ansible が Playbook に従って「アーティファクトのダウンロード」「インストール」「サービスの再起動」を自動的に行っています。 Webアプリケーション実行 Jenkins のデプロイジョブで Web アプリケーションが構築されているので、アクセスしてアプリケーションが動いているか確認しましょう。この章はユーザーによる利用がメインとなりますが、サービス稼働の裏方として運用担当、開発担当とレビューアーも関わりを持ちます。 ブラウザで Web アプリケーションにアクセスしてデプロイ結果を確認します。 http://localhost:8181 画面が表示され、サイコロを振るなどの操作ができれば成功です！CI/CD による開発からアプリケーションの稼働開始までの一連の流れは以上となります。 Web アプリケーションの稼働確認で改善点や改修点が見つかった場合には、GitLab のローカルリポジトリでソースコードや設定ファイルの改修を行って、再度「 GitLab リモートリポジトリ更新（webapi） 」章の手順から実行し直すことで、常に「コード」と「環境」が一致した状態を保ちながら、安全かつ高速に機能改善（継続的デリバリー）を行うことが可能になります。 Jenkins DAST（動的アプリケーションセキュリティテスト）ジョブ実行 診断ツール「OWASP ZAP」を利用した DAST ジョブを実行します。通常、DAST はビルドジョブの一環として自動化することが一般的ですが、スキャン完了までに時間を要する（10分以上）傾向があるため、本ハンズオンではパイプラインの即応性と実演の円滑さを考慮し、ビルドジョブとは切り離した独立したジョブとして用意しています。 Jenkins のジョブ一覧から「verify-dast-webapp」検証ジョブを選択します。 検証ジョブは Jenkins 自身でジョブを開始するため、左ペインのメニューから「ビルド実行」をクリックしてジョブを実行します。 全てのタスクが完了すると DAST の検証が完了しました。左ペインのメニューで「DAST Scan Report (webapi)」および「DAST Scan Report (webui)」をクリックすると、DAST の検証結果が確認できます。 検出されたリスクがあれば、レベルや検出に至った経緯が掲載されているので、改善に向けた検討を試みてください。 GitLab CI/CD 実行 本ハンズオンでは Jenkins を利用した CI/CD の体験をメインとしているが、GitLab CI/CD による簡易な CI/CD も体験できます。 「webapp-webapi」リポジトリを選んでいる状態で左ペインのメニューから「Build > Pipelines」を選びます。GitLab CI/CD を実行するために画面右上にある「New pipeline」ボタンをクリックします。 Run new pipeline 画面に遷移してきたら「New pipeline」ボタンをクリックします。 パイプラインの「launchers」のボックス内で、「trigger-build-release」ジョブ名の右隣にある再生ボタンをクリックして、ビルドジョブを起動します。 ビルドジョブが走り出し、その配下にあるステップが順番に実行されている様子が確認できます。 「trigger-build-release」ジョブ配下の全てのステップが完了したら、左ペインのメニュー「Deploy > Pakage registry」より、アーティファクトが保存されているのを確認します。 続いて「Deploy > Pages」にて、「trigger-build-release」ジョブの実行中に生成されたテスト結果や仕様書が閲覧できます。 アーティファクトが出来上がったので、アプリケーションサーバーへデプロイします。左ペインのメニュー「Build > Pipelines」で遷移し、「trigger-build-release」ジョブを起動したパイプラインをアクティブにします。今度は「trigger-deploy」の右隣にある再生ボタンをクリックしてジョブを開始します。 「trigger-deploy」ジョブの全てのステップが完了するとアプリケーションサーバーにデプロイも完了しています。 説明は割愛しますが、「webapp-webui」リポジトリも同様にパイプラインでジョブを実行したら、Web アプリケーションにアクセスしてお試しください。 DevOps の実演（CI/CD + オブザーバビリティー） 前提条件 本章を進めるには、「 Webアプリケーション実行 」章までの手順がすべて完了していることが必須となります。以下の状態になっていることを確認してから開始してください。 コンテナ環境の稼働：Jenkins を含む CI/CD ハンズオン環境のコンテナ群が起動していること。 デプロイの実績：パイプラインを通じて、プロダクション環境へ一度はデプロイが成功し、Web アプリケーションが稼働していること。 DevOps 統合環境の概要 本ハンズオンの CI/CD 環境でアプリケーションレイヤーを軸に、「 Grafana OSS LGTM スタックで体験する『オブザーバビリティー入門』 」のオブザーバビリティー環境を追加構築することで、DevOps のハンズオン環境を用意します。 CI/CD 環境：アプリケーションレイヤーに最新のソースコードで実装された Web アプリケーションを提供します。また、オブザーバビリティーによって見つかった改善点を改修した Web アプリケーションも更新提供できます。 オブザーバビリティー環境：CI/CD 環境によって提供された Web アプリケーションを観測し、安定稼働していることの確認や、時によっては改善箇所の発見を行います。 CI/CD のハンズオン環境では、DevOps ライフサイクルの Code から Deploy までが範囲でしたが、オブザーバビリティー環境を足すことによって、DevOps ライフサイクルの循環を体験することが可能になります。 Code から Deploy：本ハンズオン「 CI/CD の概要 」の説明を参照してください。 Operate（Web アプリケーション）：デプロイされたアプリケーションが稼働し、オブザーバビリティーに必要なテレメトリーデータ（ログ、メトリクス、トレース）を継続的に出力します。 Monitor（Grafana LGTM Stack）：収集したデータをダッシュボードで可視化・分析し、アプリケーションの健全性やボトルネック、エラーの発生をリアルタイムに検知します。 Plan：監視データから得られた客観的な事実に基づいて改善点や修正方針を策定し、次の開発サイクル（Code）へとフィードバックします。 構築手順 ブラウザで Jenkins にアクセスし Web アプリケーションを Grafana へのメトリクス送信に対応したジョブ（「deploy-webapp-with-grafana」デプロイジョブ）でデプロイし直します。 http://localhost:8080 ターミナルを使い、Web アプリケーションのメトリクス収集用として NodeExporter をサイドカーコンテナで立ち上げます。 $ cd ~/handson/hands-on-jenkins/container/ $ ./CREATE_CONTAINER.sh up-exporter Grafana のハンズオン環境のリポジトリを GitHub から取得します。 $ cd ~/handson/ $ git clone https://github.com/Toshiharu-Konuma-sti/hands-on-grafana.git CI/CD のハンズオン環境に対し、Web アプリケーションを除く Grafana 関連のコンテナ群を追加で立ち上げます。 $ cd ~/handson/hands-on-grafana/container/ $ ./CREATE_CONTAINER.sh up-to-jenkins DevOps フィードバックループの体験 ブラウザで Web アプリケーションにアクセスし、サイコロを振ってアプリケーションを楽しみます。 http://localhost:8181 Web アプリケーションを動かすことでテレメトリーデータが Grafana に送られますので、ブラウザで Grafana にアクセスします。 http://localhost:3000 Grafana で各種テレメトリーデータを確認します。Grafana で確認する際の操作手順については、以下のハンズオン資料を確認してください。 Grafana OSS LGTM スタックで体験する『オブザーバビリティー入門』 Grafana で観測した結果から Web アプリケーションのソースコードを改修してます。以下のソースコード改修例は、観測結果から「タイトルの視認性を上げたい」などの改善点が見つかったと仮定してソースコードを改修しています。 $ cd ~/handson/hands-on-jenkins/try-my-hand/webapp-webui/ $ vim src/main/resources/templates/include/title.html $ git diff src/main/resources/templates/include/title.html diff --git a/src/main/resources/templates/include/title.html b/src/main/resources/templates/include/title.html index 51f33eb..7fa53b1 100644 --- a/src/main/resources/templates/include/title.html +++ b/src/main/resources/templates/include/title.html @@ -1,3 +1,3 @@ <div> - <h1>Let's pray for a good eye!!</h1> + <h1>Let's pray for a good eye!! v2</h1> </div> 改修が完了したらコミット・プッシュを行い、以下手順で再度 CI/CD を回します。これにより、改善されたアプリケーションがプロダクション環境へリリースされ、再び「Operate」→「Monitor」へと続く DevOps の無限ループが回り始めます。 CI/CD の実演 以上で、DevOps の実演を含めた CI/CD のハンズオンはすべて終了です。お疲れ様でした！ コードのコミットからデプロイ、そして稼働状況の観測から次の改善へ。この一連の「DevOps ループ」が実際に回る様子を通して、CI/CD とオブザーバビリティーが連携することでどのように継続的な改善が実現されるのか、その「手応え」を感じていただけたなら幸いです。 続く Appendix では、このハンズオン環境を裏で支えている設定ファイルやスクリプトについて解説します。「どうやってこの環境を作ったのか詳しく知りたい！」という方は、ぜひこのままご覧ください。 Appendix ハンズオン環境の構築や設定手順で利用した各種スクリプトや設定ファイルの実装内容について解説します。 docker-compose / Dockerfile の解説 jenkins/Dockerfile 「 container/jenkins/Dockerfile#L3-L4 」に記述した Jenkins CLI コマンドを実行して、「 container/jenkins/my-config/ref/plugins.txt 」で列記した以下のプラグインがインストールされたコンテナを用意します。 Configuration as Code：Jenkins Configuration as Code （JCasC）による設定ができるようにします。 SSH Credentials：SSH ノードや Git 接続に必要な SSH 認証情報（秘密鍵やパスワードなど）を暗号化して安全に管理できるようにします。 GitLab：GitLab でコミットやマージなどのイベント発生時に、WebHook を受信してジョブが実行できるようにします。 Pipeline: Stage View：ジョブのページで Stage View を表示できるようにします。 Coverage：単体テストのカバレッジを確認できるようにします。 Warnings：コーディングルール（CheckStyle、PMDなど）の結果を確認できるようにします。 Javadoc：ソースコードから Javadoc 形式で仕様書を生成できるようにします。 Generic Tool：JCasCで「tool:」セクションが使えるようにします。 OWASP Dependency-Track：ビルド時に生成した SBOM を Dependency-Track へ自動送信し、脆弱性解析結果を連携・確認できるようにします。 JFrog：ジョブから JFrog Platform（Artifactory）にアクセスしやすくします。 コンテナ構築スクリプトの解説 「 コンテナ構築スクリプトの実行 」章で使用する「 container/CREATE_CONTAINER.sh 」スクリプトの処理内容について解説します。 Artifactory 構築用の YAML ファイル取得 Artifactory コンテナを構築するための docker-compose YAML ファイルを取得します。JFrog 社が公開しているファイルを利用して構築するため、以下 OSS 版のダウンロードページより、Linux Installer で「Docker Compose」を選択した際に表示される Download URL から tar.gz ファイルを取得します。 Community – Download Artifactory OSS 取得した tar.gz ファイルを解凍すると artifactory-oss-{version}/templates/ ディレクトリ配下に、いくつか docker-compose YAML ファイルが存在しているが、その中から Artifactory と PostgerSQL コンテナを構築する「 docker-compose-volumes.yaml 」を利用します。 Web アプリ向け MySQL 設定ファイル取得 本ハンズオン、および、Grafana LGTM スタックのハンズオン向けに用意した Web アプリケーションのリポジトリから MySQL 設定用のファイルを取得します。Clone で取得するのではなく、リポジトリを zip 圧縮したファイルで取得します。 Toshiharu-Konuma-sti/hands-on-rollingdice-webapp 取得した zip ファイル解凍すると hands-on-webapp-rolling-dice-main/mysql/ ディレクトリ配下に、MySQL を設定するファイルが存在するので、これらファイルを Web アプリケーション構築用の docker-compose-webapp.yaml ファイルに定義した MySQL コンテナから volume 参照して利用します。 コンテナ構築のコマンド実行 本ハンズオンで利用するコンテナは 3 種類の docker-compose YAML ファイルを利用して構築するため、これらのファイルを指定して docker-compose コマンドを実行します。 $ docker-compose \ -f docker-compose.yml \ -f docker-compose-webapp.yml \ -f docker-compose-volumes.yaml \ up -d -V --remove-orphans ネットワークへ登録 Artifactory コンテナは JFrog 社で公開している docker-compose YAML ファイルで構築しているため、ハンズオン用に独自で運用している Docker ネットワークに後から追加します。 $ docker network connect hands-net artifactory $ docker network connect intra-net artifactory $ docker network connect intra-net postgresql JCasC 適用内容の解説 「 JCasC の適用 」章で使用する Jenkins Configuration as Code（JCasC）ファイル「 container/jenkins/my-config/jcasc/jenkins.yaml 」で適用する内容について解説します。 master ノードのラベル付与 「Jenkins の管理 > System Configuration > Nodes」のノード一覧にある「master」ノードに、デフォルトでは付与されていないラベルを付与します。JCasC ファイルでは「 container/jenkins/my-config/jcasc/jenkins.yaml#L8 」の定義が該当します。 ラベル：「master」を付与します。 ノード追加 「Jenkins の管理 > System Configuration > Nodes」でノードを追加します。JCasC ファイルでは「 container/jenkins/my-config/jcasc/jenkins.yaml#L10-L32 」の定義が該当します。 エージェントノードとしてあらかじめ登録しておくことで、Jenkins の起動時に jenkins-agent や ansible コンテナへ自動的に SSH 接続されます。これにより、デプロイジョブ側で個別に SSH 接続処理を実装することなく、直接 Ansible を操作してデプロイを実行できるようになります。 追加するノード情報は以下の通りです。 ノード名「jenkins-agent-node」を追加します。 ラベル：「jenkins-agent」を入力します。 ホスト：「jenkins-agent」を入力します。 ノード名「ansible-node」を追加します。 ラベル：「ansible」を入力します。 ホスト：「ansible」を入力します。 各ノード共通で以下情報を登録します。 リモートFSルート：「/root」を入力します。 起動方法：「SSH経由でUnixマシンのスレーブエージェントを起動」を入力します。 認証情報：「root/*******」を選択します。 Host Key Verification Strategy：「Non Verifying Verification Strategy」を選択します。 ツール（Plugin）設定 「Jenkins の管理 > System Configuration > Tools」でインストール済みの中から以下のプラグインを設定します。JCasC ファイルでは「 container/jenkins/my-config/jcasc/jenkins.yaml#L34-L50 」の定義が該当します。 Gradle（初期セットアップの Suggested Plugin でインストール） JFrog（コンテナ作成時に Jenkins CLI でインストール） Gradle に設定する内容は以下の通りです。 name：「my-gradle」を入力します。 自動インストール：「On」でチェックを入れます。 アーカイブダウンロードURL：「https://services.gradle.org/distributions/gradle-9.6.0-bin.zip」を入力します。 バージョン：「Gradle 9.0.0」を選択します。 JFrog に設定する内容は以下の通りです。 name：「my-jfrog-cli」を入力します。 自動インストール：「On」でチェックを入れます。 Version：最新版をインストールするため空欄のままにします。 外観設定 「Jenkins の管理 > System Configuration > Appearance」で外観を設定します。JCasC ファイルでは「 container/jenkins/my-config/jcasc/jenkins.yaml#L52-L57 」の定義が該当します。 外観で設定する内容は以下の通りです。 Pipeline Stages Show pipeline stages on job page：「On」にします。 Show stage names by default：「On」にします。 Show stage durations by default：「On」にします。 Pipeline Graph Show pipeline graph on build page：「On」にします。 クレデンシャル追加 「Jenkins の管理 > Security > Credentials」で認証情報を登録します。JCasC ファイルでは「 container/jenkins/my-config/jcasc/jenkins.yaml#L59-L81 」の定義が該当します。 「Stores scoped to Jenkins」の表で Store = System 行の Domains 列で「(global)」をクリックしてグローバルドメイン画面に遷移します。 「+ Add Credentials」ボタンをクリックして「Jenkins-Agent SSH 接続用」、「Ansible SSH 接続用」、「Artifactory Push 用」と「Dependeny-Track SBOM 登録用 API Key」の4つの認証情報を作ります。 「Jenkins-Agent SSH 接続用」は以下の値を入力してから「Create」ボタンをクリックして作成します。 種類：「ユーザー名とパスワード」を選択します。 スコープ：「グローバル」を選択します。 ユーザー名：「root」を入力します。 パスワード：「password」を入力します。 ID：「jenkins-agent-node-credential」を入力します。 「Ansible SSH 接続用」は以下の値を入力してから「Create」ボタンをクリックして作成します。 種類：「ユーザー名とパスワード」を選択します。 スコープ：「グローバル」を選択します。 ユーザー名：「root」を入力します。 パスワード：「password」を入力します。 ID：「ansible-node-credential」を入力します。 「Artifactory Push 用」は以下の値を入力してから「Create」ボタンをクリックして作成します。 種類：「ユーザー名とパスワード」を選択します。 スコープ：「グローバル」を選択します。 ユーザー名：「admin」を入力します。 パスワード：「password」を入力します。 ID：「artifactory-app-credential」を入力します。 「Dependeny-Track SBOM 登録用 API Key」は以下の値を入力してから「Create」ボタンをクリックして作成します。 種類：「Secret Text」を選択します。 スコープ：「グローバル」を選択します。 シークレット：SETUP のスクリプトで埋めるので適当な文字をを入力します。 ID：「dependency-track-api-key」を入力します。 Artifactory 設定 「Jenkins の管理 > System Configuration > System」で JFrog のプラグイン情報を設定します。JCasC ファイルでは「 container/jenkins/my-config/jcasc/jenkins.yaml#L90-L96 」の定義が該当します 「JFrog Plugin Configuration」セクションで以下の値を入力します。 Server ID：「my-artifactory」を入力します。 JFrog Platform URL：「 http://artifactory:8081 」を入力します。 Credentials：「admin/******」を選択します。 Allow HTTP Connections：On でチェックを入れます。 CI/CD 環境セットアップスクリプトの解説 「 CI/CD 環境セットアップスクリプトの実行 」章で使用する「 SETUP_HANDS-ON.sh 」スクリプトの処理内容について解説します。 必須コマンドの存在確認 CI/CD の連携をスクリプトで行う際に必要となるコマンドがインストールされているかどうかを確認します。コマンドの存在が確認できなかった場合には、スクリプトは停止しますので、手作業でコマンドのインストールをお願いします。詳細な実行内容は以下実装を確認してください。 setup/SETUP_HANDS-ON.sh#L10 Jenkins ジョブ登録 Jenkins CLI クライアントをダウンロードして、Jenkins CLI でジョブを登録します。 $ wget -O jenkins-cli.jar http://localhost:8080/jnlpJars/jenkins-cli.jar $ java -jar jenkins-cli.jar -s http://localhost:8080/ -auth admin:password create-job build-webapp-webapi < ./jenkins/jobs/config-build-webapp-webapi.xml $ java -jar jenkins-cli.jar -s http://localhost:8080/ -auth admin:password create-job build-webapp-webui < ./jenkins/jobs/config-build-webapp-webui.xml $ java -jar jenkins-cli.jar -s http://localhost:8080/ -auth admin:password create-job deploy-webapp < ./jenkins/jobs/config-deploy-webapp.xml 詳細な実行内容は以下実装を確認してください。 step11-jenkins_create_job.sh Dependency-Track 設定 Admin 初期パスワード変更 Admin ユーザーの初期パスワードを変更します。詳細な実行内容は以下実装を確認してください。 step21-dtrack_change_admin_password.sh OSV 有効化 Google 提供の OSV を脆弱性判定ソースとして有効化します。初期同期の時間を最小限に抑えるため、対象エコシステムを「Maven」のみに限定し、設定後は即座に同期を実行します。詳細な実行内容は以下実装を確認してください。 step22-dtrack_enable_osv.sh Dependency-Track API Key の Jenkins 連携 Jenkins ジョブと Dependency-Track 間の脆弱性スキャン連携における認証を設定します。Dependency-Track の「Administrators」チームで生成した API Key を、Jenkins の認証情報（Credentials）へ同期します。詳細な実行内容は以下実装を確認してください。 step23-dtrack_generate_apikey_and_update_jenkins_secret.sh GitLab Admin 設定 Administrator 権限が必要な Admin area の GitLab 環境全般の各種設定を行います。詳細な実行内容は以下実装を確認してください。 step31-gitlab_update_admin_setting.sh GitLab export からのインポート有効化 GitLabトップページに移り左ペイン最下部から「Admin」ボタン押下 左ペインから「Settings > General」選択 「Import and Export settings」セクションを選択 「GitLab export」をOn Auto DevOps pipeline無効化 GitLabトップページに移り左ペイン最下部から「Admin」ボタン押下 左ペインから「Settings > CI/CD」選択 「Continuous Integration and Deployment」セクションを選択 「Default to Auto DevOps pipeline for all projects」をOff Webhook 許可設定 ローカルネットワーク内にWebhookを送信するには、ここでOn設定をする必要がある Filtering outbound requests | GitLab Docs CIDR計算すると分かるが、コンテナのIPアドレスは「172.16.0.0/12」に当てはまる 手順は以下の通り GitLabトップページに移り左ペイン最下部から「Admin」ボタン押下 左ペインから「Settings > Network」選択 「Outbound requests」セクションを選択 「Allow requests to the local network from webhooks and integrations」をOn 「Save changes」ボタン押下 GitLab リポジトリ設定 リポジトリ作成 事前にエクスポートして用意してあるファイルをインポートして、初期状態のリポジトリを Web UI、Web API の2つ分を用意します。 「Create a project」→「Create a blank project」押下 以下入力して「Create project」押下 Project name = webapp-webapi Project URLで「root」選択 Visibility levelで「Public」選択 「Create project」押下 同様に「Project name = webapp-webui」も作成します。 詳細な実行内容は以下実装を確認してください。 step32-gitlab_import_repository.sh リポジトリへ WebHook 登録 「webapp-webapi」「webapp-webui」の各リポジトリでマージイベント発生時に、各リポジトリに対応する Jenkins のビルドジョブへ Webhook を送信するための設定を行います。 GitLabトップページ移り「webapp-webui」プロジェクトをアクティブにする プロジェクト画面の左ペインより「Settings > Webhooks」を選択 「Add new webhook」押下 以下入力 Name = jenkins-build-webapi URL = http://jenkins:8080/project/build-webapi Secret tokne に Jenkins でジョブに発行したTokenを入力（1234567890abcdefghijklmnopqrstuvwxyz） Trigger は「Merge request events」のみ「On」にする Enable SSL verification = Off 「Add webhook」押下 事前にプロジェクトに「マージリクエスト（＝プルリク）」を作ったうえで、リストに移ったら登録したWebhookの右側にある「Test > Merge request events」でテストを実施し、画面上部に「Hook executed successfully: HTTP 200」で成功（マージリクエストが存在しない状態だと、いくらテスト実行してもエラーとなる） 詳細な実行内容は以下実装を確認してください。 step33-gitlab_setting_repository_webhook.sh GitLab CI/CD 向け設定 Jenkins ではなく、GitLab CI/CD でビルドやデプロイを行うために必要な各種設定を行います。 リポジトリへ CI/CD 変数登録 GitLab CI/CD からデプロイする際に Ansible へアクセスするために必要な変数を設定します。詳細な実行内容は以下実装を確認してください。 step34-gitlab_setting_repository_variable.sh グループ Runner 紐付け用のグループ作成 GitLab CI/CDの実行環境を一元管理するため、グループ Runner の紐付け対象となる専用グループを新規に作成します。詳細な実行内容は以下実装を確認してください。 step35-gitlab_create_group.sh グループ Runner 作成 先に作ったグループを紐づけてグループ Runner を作成します。詳細な実行内容は以下実装を確認してください。 step36-gitlab_create_group_runner.sh ローカルリポジトリ準備スクリプトの解説 「 ローカルリポジトリ準備スクリプトの実行 」章で使用する「 PREPARE_LOCAL_GIT_REPO_TO_PUSH.sh 」スクリプトの処理内容について解説します。 リモートからローカルリポジトリ取得 Web API のリモートリポジトリを取得して、開発作業を進めるためにローカルリポジトリへディレクトリを遷移します。 $ git clone http://localhost:13000/admin/webapp-webapi.git $ cd webapp-webapi/ 手順説明では Web API を対象に進めますが、Web API が終わったら手順のコマンドに書かれている「webapp-webapi」を「webapp-webui」に差し替えて、フロントエンドも同様の流れで実施します。 ローカルリポジトリへ開発ブランチ作成 アプリケーションを開発を GitHub flow ベースのソースコード管理に準じて進めるために、開発用のブランチを作成して、該当のブランチがアクティブにします。 $ git checkout -b feature/sample $ git branch -a * feature/sample main remotes/origin/HEAD -> origin/main remotes/origin/feature/sample remotes/origin/main ローカルリポジトリで Web アプリケーション開発 本来であれば、Web アプリケーションをゼロから実装してリポジトリに登録するのが理想的な手順ではありますが、本ハンズオンでは Web アプリケーションの開発ではなく、CI/CD の実施を体験することが主な目的となるため、既に開発されている以下の Web アプリケーションのソースコードを利用して、開発したつもりで進めます。 Toshiharu-Konuma-sti/hands-on-rollingdice-webapp Web アプリケーションのリポジトリをダウンロードするディレクトリを作成します。 $ mkdir ~/handson/hands-on-jenkins/download/ 圧縮形式のリポジトリをダウンロードします。 $ curl -LO \ --output-dir ~/handson/hands-on-jenkins/download/ \ https://github.com/Toshiharu-Konuma-sti/hands-on-rollingdice-webapp/archive/refs/heads/main.zip 圧縮しているリポジトリを展開します。 $ unzip -o ~/handson/hands-on-jenkins/download/main.zip -d ~/handson/hands-on-jenkins/download/ 展開したリポジトリから Web アプリケーションのソースコードを、CI/CD 実演用のリポジトリに移動して持ってきます。「webapi」が終わったら「webui」に置き換えて実行します。 $ mv -f \ ~/handson/hands-on-jenkins/download/hands-on-rollingdice-webapp-main/webapi/* \ ~/handson/hands-on-jenkins/try-my-hand/webapp-webapi/ $ mv -f \ ~/handson/hands-on-jenkins/download/hands-on-rollingdice-webapp-main/webapi/.git* \ ~/handson/hands-on-jenkins/try-my-hand/webapp-webapi/ GitLab CI/CD の各リポジトリ設定 「webapp-webapi」「webapp-webui」の各リポジトリで、GitLab CI/CD を動かす設定ファイルは以下の通りです。 Web API https://github.com/Toshiharu-Konuma-sti/hands-on-rollingdice-webapp/blob/main/webapi/.gitlab-ci.yml https://github.com/Toshiharu-Konuma-sti/hands-on-rollingdice-webapp/tree/main/webapi/.gitlab-ci Web UI https://github.com/Toshiharu-Konuma-sti/hands-on-rollingdice-webapp/blob/main/webui/.gitlab-ci.yml https://github.com/Toshiharu-Konuma-sti/hands-on-rollingdice-webapp/tree/main/webui/.gitlab-ci まとめ Jenkins や GitLab をはじめとするすべてオープンソース（OSS）のプロダクトを組み合わせ、ソースコードのコミットからビルド、セキュリティ検査、デプロイ、そしてオブザーバビリティーと連携したフィードバックループに至るまで、CI/CD および DevOpsの一連の流れをハンズオン形式で体験していただきました。 今回のハンズオンで体験・学習できる主なポイントは以下の通りです。 オール OSS で揃う DevSecOps 環境 Jenkins、GitLab、Dependency-Track、Artifactory OSS、Ansible、OWASP ZAP などのオープンソースのみをコンテナで一括構築し、手軽に実践的な CI/CD環境を用意できること。 シフトレフトを意識した多角的なセキュリティ＆品質検証 単体テストや静的解析（SAST: SpotBugs/PMD）だけでなく、SCA（Dependency-TrackによるSBOM・脆弱性可視化）やDAST（OWASP ZAP）まで組み込んだ、安全なサプライチェーンセキュリティのプロセス。 仕様書自動生成とアーティファクト管理 JavaDoc や OpenAPI Spec 形式の仕様書自動生成による最新仕様の可視化と、Artifactory を用いた成果物の一元管理。 継続的な改善を回す DevOps フィードバックループ デプロイして終わりではなく、Grafana 等のオブザーバビリティー環境と連携することで、アプリケーションの稼働状況を観測し、次のコード改修（Plan/Code）へと循環させる「DevOpsの無限ループ」を体感できること。 「CI/CD」や「DevSecOps」、「シフトレフト」といった概念は、言葉や図で理解しようとすると難しく感じられがちですが、実際に手元でコンテナを動かし、パイプラインが実行されてアプリが更新される様子を目の当たりにすることで、その本質やメリットを実感していただけたのではないでしょうか。 本ハンズオンで使用したスクリプトや設定ファイルはすべてGitHubで公開していますので、環境構築の裏側の仕組みを解析してみたり、ご自身の開発アプリを載せてカスタマイズしてみたりと、CI/CD・DevOps 実践の第一歩としてぜひご活用ください。 最後までお読みいただき、ありがとうございました ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Jenkins + GitLab などで体験する『CI/CD入門』 first appeared on SIOS Tech Lab .

本記事は 2026 年 7 月 14 日に公開された Jishnu Dasgupta と Chetan Dharma の “ Automated Incident Remediation with AWS DevOps Agent and Kiro CLI ” を翻訳したものです。 はじめに インシデント修正の自動化、つまり調査結果を人手をかけずにデプロイ済みの修正へとつなげることは、AWS 上で分散ワークロードを運用するオペレーションチームにとって次の課題です。現在、インシデントが深夜 2 時に発生すると、オンコール担当のエンジニアは Amazon CloudWatch 、デプロイパイプライン、アプリケーションログをまたいでテレメトリを突き合わせ、その後手動で修正を書いてデプロイする必要があります。これには通常数時間かかります。 AWS DevOps Agent は、インシデントを自律的に調査し、根本原因を特定し、数分で修正計画を生成することで、この前半部分を解決します。プレビュー期間中、お客様やパートナーからは MTTR が最大 75% 短縮、調査速度が最大 80% 向上、根本原因の特定精度が 94% という結果が報告されました。 しかし、調査と修正の提案はあくまで半分にすぎません。調査結果を読み、修正を書き、テストし、デプロイする作業は依然として人手が必要です。この後半部分も自動化できたらどうでしょうか。 前回の記事「 AWS DevOps Agent によるエージェント型 AI を活用した自律的インシデント対応 」では、AWS DevOps Agent を設定してアプリケーションを監視し、自律的な調査をトリガーし、本番デプロイのベストプラクティスに従う方法を紹介しました。また、Amazon CloudWatch アラームが発生した際に調査を自動的にトリガーする仕組みを示す コードサンプル も公開しています。この 2 つの記事により、Amazon CloudWatch アラームをきっかけに AWS DevOps Agent の調査をトリガーし、修正計画を生成できるようになりました。 本記事では、AWS DevOps Agent の修正計画の出力を、 AWS CodeBuild 上でヘッドレスモードで動作する Kiro CLI と統合して、修正のループをエンドツーエンドで完結させる方法を紹介します。AWS DevOps Agent が修正分析を完了すると、イベント駆動型のパイプラインが調査結果を自動的に Kiro CLI へルーティングします。Kiro CLI はコードベースに修正を適用し、人によるレビュー用の pull request を作成し、承認後にデプロイをトリガーします。結果として、L1/L2 インシデントは検知からデプロイ済みの修正まで、最小限の人手介入で完了します。唯一人が介在するのは pull request の承認だけです。 サンプルの CloudFormation アプリケーションを使い、インフラのコード、異常発生用のスクリプト、イベントルーティング、そしてすべてを機能させる Kiro CLI の steering 設定を含めた、ソリューション全体を解説します。ソースコードはすべて、付随する aws-samples の リポジトリ で公開されています。 ソリューションの概要 AWS 上で稼働する典型的な Web アプリケーションを考えてみましょう。 Application Load Balancer の背後にフロントエンドがあり、バックエンドの計算処理は Amazon EC2 、データベースは Amazon RDS で構成され、ソースコードと CloudFormation テンプレートは AWS CodeCommit に置かれています。この環境で何か問題が発生すると、本ソリューションは 2 つの AWS フロンティアエージェント — 自律的な調査と修正を行う AWS DevOps Agent、そして自動的なコード修正を行う Kiro CLI — を、完全サーバーレスのイベント駆動型ブリッジでつなぎ、インシデントからデプロイ済みの修正までアプリケーションを進めます。 図 1 – ソリューションアーキテクチャ 仕組み インシデントの発生 – アプリケーションで問題が発生します。CPU 使用率の上昇、エラー率の上昇、応答速度の低下などです。Amazon CloudWatch アラームが発生します。 DevOps Agent による調査 – アプリケーションが Agent Space にオンボードされている AWS DevOps Agent が、メトリクス、ログ、デプロイ履歴を自律的に突き合わせ、根本原因を特定して修正計画を生成します。 EventBridge による信号のルーティング – Amazon EventBridge のルールが Mitigation Completed イベント（ソース: aws.aidevops）を検知し、 AWS Lambda 関数を呼び出します。 Lambda による抽出とキューイング – AWS Lambda 関数が AWS DevOps Agent の API を呼び出して修正の要約と実行計画を取得し、そのペイロードを Amazon SQS キューに送信します。 CodeBuild による Kiro CLI の実行 – Amazon SQS キューにメッセージが届くと、 SQS イベントソースマッピング を持つ AWS Lambda 関数が AWS CodeBuild の実行をトリガーし、メッセージの内容を環境変数として渡します。AWS CodeBuild は、修正のペイロードを修正用プロンプトとして使い、 ヘッドレスモード （ --no-interactive --trust-tools=read,write,grep,shell ）で Kiro CLI を実行します。 Kiro CLI による修正の適用 – リポジトリの構成と修正の規約を記述した steering ファイル に従い、Kiro CLI は CloudFormation テンプレートやアプリケーションコードを修正し、フィーチャーブランチにコミットして pull request を作成します。 人による承認とパイプラインによるデプロイ – 開発者が pull request をレビューします。承認されてマージされると、関連するデプロイパイプラインがトリガーされ、変更が実行されます。 前提条件 このウォークスルーを進めるには、以下が必要です。 AWS DevOps Agent へアクセスできる AWS アカウント 設定済みの Agent Space Pro、Pro+、Power のいずれかのサブスクリプションを持つ Kiro CLI（ ヘッドレスモードの API キー に必要） 適切な認証情報で設定済みの AWS CLI アカウントの AWS CodeCommit リポジトリに push したサンプル リポジトリ 完了したら、 Readme ファイルに従って、上記のアーキテクチャを実装・実行するためのコンポーネントをセットアップしてください。以下のセクションでは、このアーキテクチャを支えるために構築されたコンポーネントについて説明します。 修正イベントの取得 AWS DevOps Agent は、調査や修正の状態が変化するたびに、 Amazon EventBridge のデフォルトイベントバスへライフサイクルイベントを発行します。各イベントはソース aws.aidevops を使用し、 Mitigation Completed、Investigation Completed、Mitigation Failed のように、具体的な内容を示す detail-type を持ちます。本記事では、修正が正常に完了した瞬間という単一の信号に焦点を当てます。 EventBridge のルールと Lambda による抽出 Mitigation Completed の detail-type に一致する Amazon EventBridge の ルール が、AWS Lambda 関数を呼び出します。イベントのペイロードには（agent_space_id、task_id、execution_id という）メタデータが含まれており、これにより AWS Lambda 関数は AWS DevOps Agent を呼び出し、修正の要約（どのアクションを取るべきか、その理由）と実行計画（ステップバイステップの手順）という 2 つの重要なオブジェクトを取得できます。この構造化されたペイロードは、後続の処理のために Amazon SQS キューへ発行されます。 Kiro CLI によるヘッドレスな修正 修正のペイロードが Amazon SQS キューに届くようになったので、次はアプリケーションとインフラのリポジトリをチェックアウトし、コードベースに対して Kiro CLI エージェントを実行し、変更を push できるコンピューティング環境が必要です。AWS CodeBuild はこれに適しています。オンデマンドのコンピューティングを提供し、AWS CodeCommit とネイティブに統合され、永続的なインフラを必要としません。 Kiro CLI 2.0 ではヘッドレスモードが導入され、対話的なターミナルなしでデプロイパイプライン内でプログラムから実行できるようになりました。（AWS Secrets Manager に保管された）API キーで認証し、プロンプトを渡すと、Kiro CLI は対話型の体験と同じツール、同じエージェント、同じ機能でエンドツーエンドに実行します。 CodeBuild による修正のオーケストレーション Amazon SQS キューにメッセージが届くと、トリガー用の AWS Lambda 関数が Amazon SQS のメッセージ本文を環境変数として渡し、AWS CodeBuild の実行を開始します。AWS CodeBuild の buildspec は、次のような単純な手順で構成されています。 インストール: Kiro CLI をインストールし、環境を設定します。KIRO_API_KEY は AWS Secrets Manager から自動的に取得され、ハードコードされることはありません。 プロンプトの生成: Python スクリプトが、構造化された修正のペイロードを自然言語の修正用プロンプトに変換します。内容を検査して、変更がインフラ向けかアプリケーションコード向けかを分類し、アクション、判断理由、具体的な指示を含む、絞り込んだプロンプトを生成します。 フィーチャーブランチの作成: 追跡できるよう、agent space と実行 ID にもとづいて名付けた新しいブランチをチェックアウトします。 Kiro CLI の実行: 生成したプロンプトとともに、Kiro CLI をヘッドレスモードで呼び出します（ kiro-cli chat --no-interactive --trust-tools=read,write,grep,shell "生成したプロンプト" ）。承認を行う人間がいないため、 --trust-tools フラグは最小権限の原則に従って特定のツールカテゴリのみを自動承認します。 検証とコミット: ガードレールが変更を検査します。ファイル数の上限、保護対象ファイルの検出、Python の構文検証（py_compile）、YAML の lint です。すべてのチェックを通過すると、変更がコミットされ push されます。 pull request の作成: 修正のアクションをタイトルとし、AWS DevOps Agent の判断理由を説明文に含めた AWS CodeCommit の pull request を作成します。 steering ファイル Kiro CLI が修正において効果的なのは、単に一般的なコードを生成するからではなく、 steering ファイル によるものです。steering は、リポジトリの構成、コーディング規約、意思決定のフレームワークといった、プロジェクトに関する永続的な知識を Kiro に与えます。 このソリューションでは、steering ファイルが自動修正のガードレールとして機能します。次の内容を定義しています。 リポジトリの構成 – 各ディレクトリをその用途に対応付けます。 意思決定のフレームワーク – 変更をインフラ向けかアプリケーション向けかに分類するルールです。 スコープの制約 – 1 回の修正につき最大 3 ファイルまで、新規ファイルの作成禁止、新規依存関係の追加禁止、削除の禁止です。 保護対象ファイル – buildspec、インフラのパイプラインテンプレート、ブリッジのコード、そして steering ファイル自体は、明示的に変更禁止です。 フェイルセーフ – プロンプトが曖昧であったり、Kiro が何を変更すべきか判断できない場合は、推測するのではなく変更を行いません。 この steering ファイルはリポジトリにコミットされているため、すべての AWS CodeBuild の実行時に自動的に読み込まれます。これにより、Kiro CLI は大規模なリファクタリングではなく、対象を絞った予測可能な変更を行えます。 pull request からデプロイまで ここまでで、自動化されたパイプラインはその役割を果たしています。Kiro CLI が修正計画を分析し、適切なファイルを変更し、フィーチャーブランチ上に pull request を作成しました。pull request の説明文には、何を変更したか、なぜ変更したか（AWS DevOps Agent の判断理由そのもの）、そして元のインシデントまで完全に追跡できる agent space と実行 ID が含まれています。 ここで、human-in-the-loop によるゲートが機能します。開発者が pull request をレビューし、変更が正しく、適切な範囲に収まっており、デプロイして安全であることを確認します。この承認のステップは意図的なものです。エージェントによる調査、分析、修正の提案は信頼していますが、最終的なデプロイの判断は人が行います。 pull request が承認されメインブランチにマージされると、デプロイパイプラインが承認された変更を対象の環境に反映します。 Amazon CloudWatch アラームからデプロイ済みの修正までの一連のサイクルは、数時間ではなく数分で完了し、唯一の手動ステップは pull request のレビューです。L1/L2 インシデントを大量に扱う組織にとって、これは運用にかかる負担の軽減と復旧の高速化に直結します。 クリーンアップ 継続的な課金を避けるため、このウォークスルーで作成したリソースを削除してください。完全な削除手順については Readme を参照してください。 まとめ 本記事では、AWS DevOps Agent の修正出力を Kiro CLI と統合し、クローズドループのインシデント修正パイプラインを構築する方法を紹介しました。この 2 つのフロンティアエージェントを連携させることで、オペレーションチームはインシデントの検知から、pull request の承認という単一の人的タッチポイントを経て、デプロイ済みの修正までを実現できます。 このアプローチは、エンタープライズのオペレーションに次のような明確な効果をもたらします。 MTTR の短縮 – これまで手動での調査と修正に数時間を要していた L1/L2 インシデントが、数分で解決できるようになります。 オペレーターの生産性向上 – エンジニアは、その場対応の消火作業から、対象を絞った AI 生成の修正をレビューし承認する作業へと移行できます。 一貫した修正 – steering ファイルがチームの規約と意思決定のフレームワークを体系化することで、インシデントの発生時期や頻度にかかわらず、すべての自動修正が同じ基準に従うようになります。 始めてみたい方は、aws-samples の リポジトリ から完全な実装を clone し、AWS DevOps Agent のドキュメントで最初の Agent Space を設定し、Kiro CLI のドキュメントで steering ファイル駆動のコード生成についてさらに詳しく確認してください。ご質問や、このパターンをどのように応用したかを共有したい場合は、以下にコメントを残すか、リポジトリで issue を開いてください。 翻訳は App Dev Consultant の宇賀神が担当しました。 Jishnu Dasgupta Jishnu Dasgupta は、製造業と自動車業界を専門とする AWS のシニアソリューションアーキテクトです。AWS 上でのアプリケーションの構築、移行、モダナイゼーションを専門としています。その専門知識と経験を活かし、AWS のお客様が最適化された、スケーラブルで目的に適したアーキテクチャを AWS 上で構築できるよう支援しています。 Chetan Dharma Chetan Dharma は、大規模なグローバル企業の技術変革を推進してきた 20 年以上の経験を持つ、シニア AI ソリューションアーキテクトです。投資銀行、物流、自動車、デジタルネイティブ企業といった分野で、現場のエンジニアリングからアーキテクチャ、そして AI 変革のアドバイザーへとキャリアを重ねてきました。