この記事は、2026 年 9 月 1 日に Training and Certification Blog Editor によって執筆された「 Certification updates from AWS Training and Certification: September 2026 」を翻訳したものです。 AWS 認定は、クラウドに関わる役割の変化を反映して、3 つの認定を更新します。対象は AWS Certified Machine Learning Engineer – Associate (MLA-C02)、AWS Certified Solutions Architect – Professional (SAP-C03)、AWS Certified Developer – Associate (DVA-C03) です。このブログでは、変更内容、変更の理由、および重要な日程についてお伝えします。 ベータ登録受付中: AWS Certified Machine Learning Engineer – Associate (MLA-C02) AWS Certified Machine Learning Engineer – Associate (MLA-C02) のベータ版への登録が、英語で受け付けを開始しました。現行バージョン (MLA-C01) の英語での受験最終日は 2026 年 9 月 28 日です。現行バージョン (MLA-C01) は、2027 年 1 月 14 日の一般提供開始まで、日本語・韓国語・簡体字中国語で引き続き受験できます。 機械学習 (ML) エンジニアの役割は進化しています。今日の ML エンジニアは、従来のモデルを構築・デプロイするだけではありません。生成 AI ソリューションの実装、基盤モデルや大規模言語モデル (LLM) の活用、エージェンティック AI ワークフローのオーケストレーション、そして AI のプロダクション規模での運用が求められています。こうした変化に対応するため、更新された試験 (MLA-C02) では、従来の ML エンジニアリングに加え、生成 AI・エージェンティック AI・基盤モデル / LLM ワークロードが出題範囲に含まれます。この認定資格は、Amazon SageMaker AI や Amazon Bedrock、その他の AWS サービスを使用して、AWS 上で ML および生成 AI ソリューションを構築・デプロイ・維持・監視する能力を検証します。 対象者 更新された AWS Certified Machine Learning Engineer – Associate は、プロダクション環境で ML および生成 AI ソリューションを構築・運用する専門家を対象としています。主な対象ロールは以下のとおりです。 エンドツーエンドの ML ライフサイクル管理を担う ML エンジニア・MLOps エンジニア 基盤モデルと生成 AI アプリケーションを運用化する LLMOps エンジニア ML データパイプラインを構築・管理するデータエンジニア ML / 生成 AI 機能をアプリケーションに統合するソフトウェア開発者 ML エンジニアリングの役割に移行するデータサイエンティスト ML システムを設計する ML アーキテクトおよびソリューションアーキテクト 推奨経験 Amazon SageMaker AI、Amazon Bedrock その他の AWS サービスを使った ML エンジニアリングの実務経験 1 年以上 バックエンドソフトウェア開発者、DevOps エンジニア、データエンジニア、データサイエンティストなど関連職務での実務経験 1 年以上 従来の ML と生成 AI の両方に関する経験 備考: この認定資格は ML エンジニアと MLOps エンジニアが、従来の ML と生成 AI の両方にわたる最新スキルを保有していることを検証します。チームが今日のビジネス目標を達成するプロダクションレベルのソリューションを提供できることを確認できます。 MLA-C02 の変更点と変更理由 試験のドメイン構成は変わりません。新しいドメインの追加もありません。ただし、ML エンジニアの役割が実務においてどのように広がっているかに合わせた、主要な追加事項を反映しています。 生成 AI の実装: 生成 AI ソリューションの構築とデプロイ、基盤モデルのファインチューニング、検索拡張生成 (RAG) アーキテクチャの実装 エージェンティック AI: AI エージェントと複雑なワークフローのオーケストレーション 基盤モデルと LLM: 大規模言語モデルの選定・カスタマイズ・運用化 Amazon Bedrock: 生成 AI ワークロード向けの Amazon Bedrock 機能の拡張されたカバレッジ 責任ある AI の実践: 従来の ML と生成 AI の両方にわたる、責任ある AI 実装に関するガイダンスの更新 既存のタスクステートメントとスキルは現在の業界慣行に合わせて更新されており、認定資格がこれまで検証してきたコアな ML エンジニアリングの能力は引き続き含まれています。 注: 詳細なタスクステートメントを含む完全な 試験ガイド が公開されています。 重要な日程 2026 年 9 月 1 日: ベータ登録開始 (英語のみ)、試験ガイド公開 2026 年 9 月 28 日: MLA-C01 英語受験の最終日 (日本語・韓国語・簡体字中国語は MLA-C02 のベータ期間中も引き続き利用可能) 2026 年 9 月 29 日: MLA-C02 ベータ版受験開始 2027 年 1 月 14 日: MLA-C02 一般提供開始 (全言語)、MLA-C01 全言語での廃止 ベータ試験の詳細 試験時間: 170 分 問題数: 85 問 受験料: ¥11,000 (税込) 言語: 英語のみ 受験方式: Pearson VUE (テストセンターまたはオンライン監督) MLA-C01 と MLA-C02、どちらを受験すべきか? 英語で受験する方は、以下を参考にしてください。 MLA-C01 (2026 年 9 月 28 日まで): すでに試験準備ができており、早めに認定資格を取得したい場合はこちらを選択してください。取得した資格は元の有効期限まで有効です。 MLA-C02 ベータ版 (現在登録受付中): 従来の ML と生成 AI の両方のスキルを証明する認定資格を取得したい場合はこちらを選択してください。 日本語、韓国語、簡体字中国語で受験する方は、MLA-C02 の一般提供開始日である 2027 年 1 月 14 日まで、MLA-C01 の受験が可能です。 もうすぐ登場: AWS Certified Solutions Architect – Professional (SAP-C03) AWS Certified Solutions Architect – Professional が更新となります。更新された試験 (SAP-C03) の登録は 2026 年 10 月 27 日に開始し、一般提供は 2026 年 11 月 17 日から始まります。現行バージョン (SAP-C02) が受験できる最終日は 2026 年 11 月 16 日です。SAP-C03 は、開始時点で現在サポートされている全言語で提供されます。 ソリューションアーキテクトの役割は拡大しています。今日のアーキテクトは、高可用性でコスト効率の高いシステムを設計するだけではありません。生成 AI とエージェント型アーキテクチャの統合、ポスト量子暗号の実装、サービスとしてのレジリエンスパターンの設計、スタック全体への DevSecOps 自動化の組み込みが求められています。こうした変化に対応するため、更新された試験 (SAP-C03) では、AI/ML 統合を含むクラウドネイティブアーキテクチャ、セキュリティとコンプライアンス設計、コスト最適化、レジリエンスとビジネス継続性、オペレーショナルエクセレンスを含む、AWS Well-Architected Framework に沿った最適化された AWS ソリューションを設計する能力を検証します。 対象者 更新された AWS Certified Solutions Architect – Professional は、複雑なマルチアカウント環境において複数のアプリケーションやプロジェクトをまたいで専門的なガイダンスを提供する、経験豊富なアーキテクトを対象としています。主な対象となる役割は以下のとおりです。 エンタープライズグレードのクラウドシステムを設計するソリューションアーキテクト マルチアカウントガバナンス戦略をリードするクラウドアーキテクト 最新のレジリエンスとセキュリティパターンを実装するインフラアーキテクト クラウドネイティブおよび AI 統合アーキテクチャについてチームを導くテクニカルリード 推奨経験 AWS サービスを使用したクラウドソリューションの設計および実装に関する 2 年以上の実務経験 クラウドアプリケーションの要件を評価し、AWS 上での実装に関するアーキテクチャの推奨事項を提示する能力 最新のクラウドネイティブ、サーバーレス、および AI 統合アーキテクチャ全体にわたるガイダンスの提供経験 備考: この認定資格は、ソリューションアーキテクトが従来のインフラ設計と最新の AI 統合クラウドアーキテクチャの両方にわたる最新スキルを保有していることを検証します。AWS サービスの幅広い機能を活用したエンタープライズグレードのソリューションを提供できることを確認できます。 SAP-C03 の変更点と変更理由 アーキテクトの役割が実務においてどのように広がったかを反映して、以下の内容が追加されました。 生成 AI とエージェンティック AI (新スキル 11 項目): Amazon Bedrock を使用した生成 AI 統合の設計、Amazon Bedrock AgentCore を使用した AI エージェントアーキテクチャ、RAG アーキテクチャ、コンテンツフィルタリングのための Amazon Bedrock Guardrails、AI 運用のための人間による監視ワークフロー レジリエンスエンジニアリング: AWS Fault Injection Service、AWS Resilience Hub、Amazon Application Recovery Controller、AWS Systems Manager による自動化されたランブック クラウドネイティブパターン (新スキル 7 項目): サーバーレスデータパイプライン、AWS Step Functions を使用した耐障害性のあるワークフロー、Amazon VPC Lattice と Amazon ECS Service Connect によるサービスメッシュ、コンテナイメージセキュリティ、マルチテナントアーキテクチャ、リアルタイムデータアーキテクチャ DevSecOps と可観測性 (新スキル 6 項目): パイプラインの脆弱性スキャン、マルチアカウントデプロイメントパイプライン、コンテナ監視、AI/ML メトリクス監視、合成モニタリングとリアルユーザーモニタリング データと分析 (新スキル 3 項目): AWS Lake Formation と Apache Iceberg を使用したデータレイクハウスアーキテクチャ、リアルタイムおよびバッチ分析パイプライン、AWS Clean Rooms によるクロスアカウントデータ共有 ポスト量子暗号: ML-DSA と ML-KEM を使用した AWS KMS SAP-C03 の 5 つのドメイン: クラウドネイティブアーキテクチャの設計と実装 セキュリティ、コンプライアンス、ガバナンス コスト最適化されたアーキテクチャ設計 レジリエンス、移行、ビジネス継続性 オペレーショナルエクセレンスと自動化 既存のタスクステートメントとスキルは現在の業界慣行に合わせて更新されており、本認定がこれまで検証してきたコアなアーキテクチャの能力は引き続き含まれています。 注: 詳細なタスクステートメントを含む完全な試験ガイドは、登録開始日の 2026 年 10 月 27 日に公開される予定です。 重要な日程 2026 年 10 月 27 日: 登録開始 (全言語) 2026 年 11 月 16 日: SAP-C02 受験最終日 2026 年 11 月 17 日: SAP-C03 一般提供開始 一般提供試験の詳細 試験時間: 180 分 問題数: 75 問 受験料: ¥44,000 (税込) 言語: 現在サポートされている全言語 受験方式: Pearson VUE (テストセンターまたはオンライン監督) SAP-C02 と SAP-C03、どちらを受験すべきか? SAP-C02 (2026 年 11 月 16 日まで): すでに試験準備ができており、早めに認定資格を取得したい場合はこちらを選択してください。取得した資格は元の有効期限まで有効です。 SAP-C03 を待つ (2026 年 10 月 27 日登録開始): 従来のアーキテクチャ能力に加えて、クラウドネイティブ、生成 AI / エージェンティック AI、および最新のレジリエンスエンジニアリングスキルを検証する認定資格を取得したい場合はこちらを選択してください。 もうすぐ登場: AWS Certified Developer – Associate (DVA-C03) AWS Certified Developer – Associate が更新となります。更新された試験 (DVA-C03) の登録は 2026 年 10 月 27 日に開始し、一般提供は 2026 年 12 月 1 日から始まります。現行バージョン (DVA-C02) の最終受験日は 2026 年 11 月 30 日です。DVA-C03 は、開始時点でサポートされている全言語で提供されます。 開発者の役割は進化しています。今日の開発者は、単にアプリケーションコードを書くだけではありません。AI 支援開発ツールを使ってコードを生成、レビュー、最適化し、マネージド型 AI サービスをアプリケーションに統合し、AI エージェントのインタラクションをセキュアに保つことが求められています。今や AI 支援開発はオプションの追加機能ではなく、中核的な能力となっています。この進化に対応するため、更新された試験 (DVA-C03) では、最新のツールと AI 支援開発ワークフローを使用して、AWS 上でクラウドベースのアプリケーションを開発、テスト、デプロイ、デバッグする能力を検証します。 対象者 更新された AWS Certified Developer – Associate は、AWS サービスを使用してアプリケーションを構築、テスト、デプロイ、デバッグする開発者を対象としています。主な対象ロールは以下のとおりです。 クラウドネイティブアプリケーションを構築するソフトウェア開発者 AWS サービスと AI 機能をアプリケーションに統合するバックエンドエンジニア CI/CD パイプラインとデプロイメントを管理する DevOps 担当者 アプリケーションの各レイヤーにまたがって開発を行うフルスタック開発者 推奨経験 AWS サービスを使用したアプリケーションの開発、保守に関する 1 年以上の実践経験 1 つ以上の高水準プログラミング言語への習熟 AI 支援開発ツールとワークフローの使用経験 アプリケーションライフサイクル管理と CI/CD パイプラインの理解 備考: この認定資格は、開発者が従来のクラウド開発と AI 支援開発ワークフローの両方にわたる最新スキルを保有していることを検証します。チームが最新のツールを使用して、高品質で安全なアプリケーションをリリースできることを確認できます。 DVA-C03 の変更点と変更理由 開発者の役割が実務においてどのように広がったかを反映して、以下の内容が追加されました。 新タスク 2.3 AI セキュリティ (5 スキル): AI サービスのアクセス管理、データプライバシー制御 (VPC エンドポイント、入出力が AI モデルのトレーニングに使用されないことの保証)、コンテンツフィルタリングとプロンプトインジェクション対策、AI エージェントインタラクションのセキュリティ (ツール使用の認可、セッション分離、人間参加型承認フロー)、監視ログ内の機密コンテンツの保護 全ドメインにわたる AI 支援開発: コード生成と自動レビュー (ドメイン 1)、テスト自動化とリグレッションテスト (ドメイン 3)、自動デプロイ承認を含む CI/CD ワークフロー支援 (ドメイン 3)、エラー分析とトラブルシューティング提案 (ドメイン 4)、パフォーマンス最適化の推奨事項 (ドメイン 4) コンテナ管理: Amazon ECR を使用したコンテナイメージのビルドと管理、Amazon ECS、Amazon EKS、AWS Fargate を使用したコンテナ化アプリケーションのデプロイ 新たにスコープに含まれるサービス: Amazon Bedrock、Amazon Bedrock AgentCore、Amazon Q、Kiro、Amazon Data Firehose、AWS PrivateLink 主な統合・整理 Amazon DynamoDB: 4 つの個別スキルを 1 つの包括的なスキルに統合 セキュリティ (暗号化と機密データ): 2 タスクにまたがる 13 スキルを 1 タスクの 7 スキルに統合 テスト: 2 タスクにまたがる 11 スキルを 1 タスクの 5 スキルに統合 可観測性: 8 スキルを 5 スキルに統合 最適化: 9 スキルを 6 スキルに統合 4 つのドメインは変更なし: AWS サービスを使用した開発 (30%) セキュリティ (26%) テストとデプロイ (22%) トラブルシューティングと最適化 (22%) スコープ外: プロンプトエンジニアリング、RAG 設計、AI モデルの選定、Amazon SageMaker AI、AI ガバナンスフレームワーク設計。 既存のタスクステートメントとスキルは現在の業界慣行に合わせて更新されており、認定資格がこれまで検証してきたコアな開発能力は引き続き含まれています。 注: 詳細なタスクステートメントを含む完全な試験ガイドは、登録開始日の 2026 年 10 月 27 日に公開される予定です。 重要な日程 2026 年 10 月 27 日: 登録開始 (全言語) 2026 年 11 月 30 日: DVA-C02 最終受験日 2026 年 12 月 1 日: DVA-C03 一般提供開始 一般提供試験の詳細 試験時間: 130 分 問題数: 65 問 (採点対象 50 問、採点対象外 15 問) 受験料: ¥22,000 (税込) 合格スコア: 1,000 点満点中 720 点 言語: 現在サポートされている全言語 受験方式: Pearson VUE (テストセンターまたはオンライン監督) DVA-C02 と DVA-C03、どちらを受験すべきか? DVA-C02 (2026 年 11 月 30 日まで): すでに試験準備ができており、早めに認定資格を取得したい場合はこちらを選択してください。取得した資格は元の有効期限まで有効です。 DVA-C03 を待つ (2026 年 10 月 27 日登録開始): AI 支援開発スキルと AI サービス向けのモダンなセキュリティプラクティスを証明する認定資格を取得したい場合はこちらを選択してください。 今すぐ始めよう クラウドに関わる役割は進化しており、これらの認定資格もその変化に合わせて更新されています。ML パイプラインの構築、生成 AI を活用したエンタープライズアーキテクチャの設計、AI 支援ツールを使ったアプリケーション開発のいずれであっても、AWS Certification はあなたのスキルをサポートします。 AWS 認定資格について詳しく見る AWS Skill Builder で学習を始める AWS 認定資格パスを探す 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

はじめに 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 .