単位
1. DevOps とクラウド AI の概要: 役割、境界、認証、セキュリティ、シークレット 2. 人工知能を使用した CI/CD パイプラインの設計: GitHub Actions と GitLab CI 3. コードとしてのインフラストラクチャの管理: Terraform と IaC を使用した人工知能 4. コンテナ化: 人工知能による Dockerfile とイメージの最適化 5. Kubernetes: マニフェスト、Helm、AI を活用したオーケストレーション 6. 監視と可観測性: メトリック、ログ、トレース、アラーム ルール 7. インシデント管理と事後分析: 人工知能による根本原因分析 8. クラウド コストの最適化 (FinOps): 人工知能を使用して無駄を探す 9. スクリプトとオートメーションの生成: Bash、Python、PowerShell 10. セキュリティと機密管理: DevSecOps と人工知能 11. 製品の検証、リリース戦略、エンドツーエンドの AI ワークフロー
ユニット 2 / 11

人工知能を使用した CI/CD パイプラインの設計: GitHub Actions と GitLab CI

利益:

  • CI/CD の概念、パイプラインの構造 (トリガー、ジョブ、ステップ、ランナー、アーティファクト)、GitHub Actions と GitLab CI の違いを理解し、人工知能に適切なコンテキストでパイプラインを生成させる能力
  • 秘密の参照、権限、人工知能によって生成されたパイプライン内の呼び出されるコンポーネントの存在をチェックして保護する機能
  • シークレットをプレーンテキストで書き込まない、最小限の権限を付与する、CI から分離することで展開を制御するという原則を適用する機能

最新のソフトウェアの中心は、コードが開発者のコ​​ンピュータから安全に顧客に届くまで通過する自動化されたパイプラインです。このパイプは CI/CD と呼ばれます。 CI (継続的インテグレーション) は、すべてのコード変更の自動コンパイルとテストです。その目的は、開発者がキーボードから離れる前にバグを発見することです。 CD (継続的デリバリー/デプロイメント) は、テストされたコードを自動的に準備したり、リリースしたりすることです。 CI/CD パイプラインは、これらのステップを順番に定義する構成ファイルであり、通常は YAML (人間が判読可能な構成テキスト形式) で記述されます。

これらの YAML ファイルを手動で作成するのは面倒で冗長で、エラーが発生しやすくなります。インデントが 1 スペースずれると、パイプライン全体が破損します。ここで AI が登場します。適切なコンテキストがあれば、数秒で実用的な草稿が作成されます。ただし、生成された各ステップが何を行うかを理解し、検証するのはあなたの仕事です。これは、コードを本番環境に運ぶパイプであるためです。

CI/CD パイプラインの構造

各パイプラインは、いくつかの基本概念で構成されています。以下のことを知らずに AI 出力を制御することはできません。

  • トリガー: 何がパイプラインを開始しますか?通常は、ブランチへのプッシュ、プル リクエスト (マージ リクエスト)、またはスケジュールです。
  • ジョブ: 一連のステップを実行する論理単位。たとえば、「テスト」、「ビルド」、「デプロイ」などです。
  • ステップ: ジョブ内の単一のコマンドまたはアクション。
  • ランナー: ジョブが実行される仮想マシンまたはコンテナー。
  • アーティファクト: 1 つのジョブによって生成され、後続のジョブによって使用される出力 (コンパイルされたファイルなど)。
  • Secret: Pipeline が使用する機密情報ですが、リポジトリにプレーン テキストで残すべきではありません。

GitHub Actions は、この定義を .github/workflows/*.yml ファイルに保持します。単位はワークフロー→ジョブ→ステップの階層です。一方、GitLab CI は、.gitlab-ci.yml ファイルの stage → job 構造を使用します。 AI は両方の構文を認識しますが、どちらが必要かを明示的に指定する必要があります。

ヒント: AI にパイプラインを要求するときは、プラットフォーム (GitHub Actions または GitLab CI)、言語/フレームワーク (Node、.NET、Python…)、トリガー、およびデプロイするかどうかを必ず指定します。これら 4 つの情報により、出力の有用性が 2 倍になります。

ステップバイステップ: AI を使用したパイプラインの設計

  1. 目標を明確にする。 「メインへのプッシュ時にテストを実行し、イメージをビルドしますが、タグがスローされた場合にのみデプロイする」のようなものです。
  2. スケルトンを製作してもらいます。 AIに基本的なワークフローを聞いてみましょう。
  3. 手順を読んで理解してください。各 run および uses 行が何を行うかを確認します。
  4. シークレット参照を確認します。シークレットは ${{ Secrets.NAME }} で呼び出されますか、それともコードに埋め込まれていますか?
  5. ローカル/CI で試してください。小規模なテスト リポジトリで実行し、赤と緑 (フェイルパス) の動作を確認します。
  6. 徐々に拡大していきます。最初に CI (テスト) を追加し、次にビルドし、最後にデプロイを追加します。

セキュリティ: パイプライン内のシークレットと権限

CI/CD は、機密情報が最も漏洩する場所の 1 つです。 3 つの黄金律:

  1. YAML のプレーンテキストでシークレットを決して書かないでください。プラットフォームのシークレット リポジトリ (GitHub Secrets、GitLab CI/CD 変数) を使用し、${{ Secrets.X }} で呼び出します。
  2. 最低限の特権。 Pipeline に与えるトークンには、必要な権限のみが与えられます。 GitHub Actions の権限: ブロックを使用してこれを絞り込みます。
  3. ログのシークレットを押さないでください。 echo $TOKEN のような行により、ログ内の秘密が明らかになります。プラットフォームはマスクしますが、注意も必要です。
注意: 便宜上、AI はサンプル パイプラインにパスワード: 123456 や広すぎる権限: すべて書き込みなどの埋め込み値を挿入することがあります。これを常に修正してください: シークレットを参照に変更し、アクセス許可を折りたたみます。

比較表

コンセプト

GitHub アクション

GitLab CI

設定ファイル

.github/workflows/*.yml

.gitlab-ci.yml

建物ユニット

ワークフロー → ジョブ → ステップ

ステージ→仕事

トリガー

10:

ルール: / のみ:

召喚の秘密

${{ Secrets.NAME }}

$NAME (CI/CD 変数)

準備完了コンポーネント

使用: action@v4

含める: /template

ランナー

実行中:

タグ:

ミニケース3個

ケース 1 — 6 時間 40 分に短縮されました。あるチームは手動のテスト、ビルド、デプロイのプロセスを自動化したいと考えていましたが、誰も YAML に精通していませんでした。彼らは、YZ を「Node.js プロジェクト、GitHub Actions、npm test および npm build をメインにプッシュし、v* タグでのみデプロイする」と説明しました。 AI は 40 行の実用的なスケルトンを生成しました。チームはすべての手順を検証し、40 分で稼働を開始しました。もし手書きで書いていたら、一日かかる作業だったでしょう。

ケース 2 — 認証でセキュリティ上の脆弱性が発見されました。エンジニアはAIにワークフローの展開を依頼しました。出力には、write-all という権限が含まれていました。これは、トークンがリポジトリ、パッケージ、その他すべてに書き込むことができることを意味します。エンジニアはこれに気づき、権限: { 内容: 読み取り、パッケージ: 書き込み } で絞り込みました。これにより、ハイジャックされた依存関係によってリポジトリ全体が置き換えられるリスクがなくなりました。

ケース 3 — 幻覚作用。あるチームは、AI が提案した次の使用法を実行しました。actions/deploy-to-aws@v3 行。そのような正式な措置はなく、AIが名前を付けました。パイプラインが「アクションが見つかりません」で爆発しました。レッスン: uses: で呼び出された各コンポーネントが実際に存在することを Marketplace で確認してください。

コピー可能な 4 つのテンプレート

1) 基本的な CI ワークフロー:

GitHub Actions の CI ワークフローを作成します。プロジェクト: [言語/フレームワーク]。トリガー: メイン ブランチへのプッシュおよびプル リクエスト。手順: 依存関係をインストールし、テストを実行し、lint を実行します。いいえ Deploy.Runner ubuntu-latest。秘密は必要ありません。 YAMLに注釈を付けます。

2) 導入された CD ワークフロー (安全):

[PLATFORM] のデプロイ ワークフローを作成します。これは「v*」タグでのみ機能します。対象: [メディア/クラウド]。ルール: - シークレットは決してプレーンテキストで書かず、${{ シークレットで呼び出してください。

3) 既存のパイプラインについて説明します。

次の [PLATFORM] パイプラインを 1 行ずつ説明します。各ジョブは何を行うのか、どのような順序で実行されるのか、どのようなシークレットを使用するのか、そしてその 2 つの最も危険な点は何ですか?最後に、3 つの改善点を提案します。パイプライン: [YAML CONTENT]

4) パイプラインを高速化します。

次の CI パイプラインは低速で実行されています (期間: [X 分])。キャッシュの使用状況、並列ジョブ、不要なステップを調べます。具体的で実行可能な加速に関する提案を 5 つ挙げ、それぞれの推定影響を書き留めます。パイプライン: [YAML]

弱いプロンプト / 強いプロンプト

弱み: 「GitHub Actions ワークフローを作成します。」

結果: どの言語、どのトリガー、デプロイメントがあるかどうかは不明です。 AI は汎用の Node インスタンスを提供しますが、おそらくプロジェクトには適合せず、シークレットをハードコーディングできます。

Strong: 「GitHub Actions ワークフローを作成します。Python 3.12 プロジェクト、プル リクエストとメイン プッシュで pytest + ruff を実行します。デプロイはしません。pip キャッシュで依存関係を加速します。シークレットは必要ありません。コメント付きで YAML をエクスポートします。」

違い: 2 番目のプロンプトでは、言語、トリガー、スコープ (展開なし)、期待されるパフォーマンス、およびセキュリティ制約が指定されます。出力は直接動作します。

よくある間違い

  • シークレットを YAML に埋め込む。プレーンテキストのパスワード/トークンは、最も一般的な CI の脆弱性です。
  • 広すぎる許可。すべて書き込みではなく、必要最小限のアクセス許可を与えます。
  • 存在しないアクション/テンプレートに依存しています。 AI が作成した use: ラインをマーケットプレイスで確認します。
  • CI を使用したデプロイの混乱。テストはプッシュごとに実行できますが、展開は制御され、承認される必要があります。
  • キャッシュを使用していません。実行のたびに依存関係を最初からインストールすると、パイプラインが数分遅くなります。
  • 最初のワークフローをメイン リポジトリで直接試します。まずテスト リポジトリで実行します。

要約すると

CI/CD パイプラインは、コードを本番環境に安全に移動する自動化されたパイプで、YAML で定義されます。 AI は、GitHub Actions と GitLab CI の実用的なブループリントをすぐに生成します。ただし、プラットフォーム、言語、トリガー、デプロイ範囲について明確にする必要があります。セキュリティには 3 つのルールがあります。参照によるシークレットの呼び出し、最小限の権限の付与、ログにシークレットを出力しないです。各 uses:/include: コンポーネントが実際に存在するかどうか、および各ステップが何を行うかを確認するのはあなたの責任です。

アプリケーションタスク

単純なサンプル プロジェクトを選択してください (あなたの言語の「hello world」でも十分です)。上記の「基本 CI ワークフロー」テンプレートを使用して AI にワークフローを生成させます。次に、(1) 各ステップの内容を自分の言葉で書きます。 (2) 秘密が埋め込まれておらず、権限が狭いことを確認します。 (3) 可能であれば、テストタンクで実行し、赤と緑の挙動を観察します。

チェックリスト

  • [ ] プラットフォーム、言語/フレームワーク、トリガー、およびデプロイ スコープをプロンプトに追加しました。
  • [ ] 生成された YAML での各ジョブとステップの動作を理解しました。
  • [ ] 平文の秘密はありません。すべて ${{ Secrets.X }} / CI 変数。
  • [ ] 権限を最小限の権限に絞りました。
  • [ ] 呼び出されたすべてのアクション/テンプレートが実際に存在することを確認しました。
  • [ ] デプロイメントステップを承認/保護で制御できるようにしました。
前へ 次へ