0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

Auto DevOps

Posted at

Auto DevOps

(トップページはこちら) - (アプリケーションのデプロイとリリースを始める)

CI/CDパイプラインの構築は、多くの開発チームにとって時間のかかる作業です。設定ファイルの記述、セキュリティスキャンの導入、デプロイ戦略の実装など、本質的な開発作業以外に多くの時間を費やしています。GitLab Auto DevOpsは、この課題を解決します。最小限の設定で、ビルドからデプロイまでの完全なCI/CDパイプラインを自動的に構築し、開発チームが本来の開発作業に集中できるようにします。

本記事では、Auto DevOpsを構成する各ステージについて詳しく解説します。

1. Auto DevOpsの全体像

Auto DevOpsは、以下の3つのフェーズで構成されています。

1.1. 機能別ティア対応表

各機能がどのGitLabプランで利用可能かを整理しました。

ステージ Free Premium Ultimate
Auto Build ✓ ✓ ✓
Auto Test ✓ ✓ ✓
Auto Code Quality ✓ ✓ ✓
Auto SAST 一部 一部 ✓
Auto Secret Detection 一部 一部 ✓
Auto Dependency Scanning - - ✓
Auto Container Scanning - - ✓
Auto Review Apps ✓ ✓ ✓
Auto DAST - - ✓
Auto Browser Performance Testing - ✓ ✓
Auto Load Performance Testing - ✓ ✓
Auto Deploy ✓ ✓ ✓
Auto Code Intelligence ✓ ✓ ✓

2. ビルド・テストフェーズ

2.1. Auto Build - アプリケーションのビルド

Auto Buildは、アプリケーションをDockerイメージとしてビルドし、Container Registryにプッシュします。コミットSHAまたはタグでタグ付けされます。

ビルド方法の選択:

2.1.1. Dockerfileを使用したビルド

リポジトリのルートにDockerfileが存在する場合、docker buildを使用してイメージを作成します。

重要な設定:

Auto Review AppsやAuto Deployを使用する場合、以下のいずれかが必要です。

  • アプリケーションをポート5000で公開する（デフォルトのHelmチャートが想定）
  • Helmチャートをカスタマイズして別のポートを使用する

設定例（Dockerfile）:

# アプリケーションをポート5000で公開
EXPOSE 5000
CMD ["./app", "--port=5000"]

2.1.2. Cloud Native Buildpacksを使用したビルド

Dockerfileが存在しない場合、Cloud Native Buildpacksがアプリケーションを自動検出してビルドします。

デフォルト設定:

  • ビルダー: heroku/buildpacks:22
  • 検出方法: プロジェクトのファイル構造から言語を自動判定

カスタムビルダーの指定:

# .gitlab-ci.yml または CI/CD変数で設定
variables:
  AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER: "paketobuildpacks/builder:base"

言語別の必要ファイル:

言語 必要なファイル
Python Pipfileまたはrequirements.txt
Ruby GemfileまたはGemfile.lock
Node.js package.json
Java pom.xmlまたはbuild.gradle
Go go.mod
PHP composer.json

ビルドコンテナへのボリュームマウント:

特定のファイルやディレクトリをビルド時にマウントする必要がある場合、BUILDPACK_VOLUMES変数を使用します。

# 複数のボリュームをマウントする例
buildjob:
  variables:
    # パイプ（|）で区切って複数指定
    # 形式: ホストパス:コンテナパス:オプション（ro=読み取り専用、rw=読み書き可能）
    BUILDPACK_VOLUMES: /mnt/1:/etc/foo:ro|/mnt/2:/opt/foo:ro|/mnt/3:/var/opt/foo:rw

2.1.3. HerokuishからCloud Native Buildpacksへの移行

既存のHerokuish環境からCloud Native Buildpacksに移行する場合、以下の点に注意してください。

主な変更点:

  1. buildpackの形式

    • Heroku buildpackをCloud Native Buildpackに変換するにはcnb-shimを使用
    • BUILDPACK_URLはpackがサポートする形式である必要があります

  2. コマンドの実行方法

    • 旧: /bin/herokuish procfile exec コマンド
    • 新: /cnb/lifecycle/launcher コマンド

移行例:

# 旧（Herokuish）
variables:
  DATABASE_URL: "postgres://..."
script:
  - /bin/herokuish procfile exec bin/rails db:migrate

# 新（Cloud Native Buildpacks）
variables:
  DATABASE_URL: "postgres://..."
script:
  - /cnb/lifecycle/launcher bin/rails db:migrate

注意: Auto TestはまだHerokuishを使用しています。テストスイートの検出機能はCloud Native Buildpack仕様にまだ含まれていないためです。

2.2. Auto Test - 自動テストの実行

Auto Testは、HerokuishとHeroku buildpacksを使用して、プロジェクトを分析し、言語とフレームワークを検出して適切なテストを自動実行します。

重要: Auto Testは既存のテストを実行するだけです。テストが存在しない場合は、開発者が追加する必要があります。

技術的な制約:

Auto TestはTestpack APIを実装しているbuildpackのみをサポートします。Auto Buildでサポートされているすべてのbuildpackが、Auto Testでサポートされているわけではありません。

サポート対象のbuildpack:

✓ heroku-buildpack-ruby
✓ heroku-buildpack-nodejs
✓ heroku-buildpack-clojure
✓ heroku-buildpack-python
✓ heroku-buildpack-java
✓ heroku-buildpack-gradle
✓ heroku-buildpack-scala
✓ heroku-buildpack-play
✓ heroku-buildpack-php
✓ heroku-buildpack-go
✓ buildpack-nginx
✗ heroku-buildpack-multi（サポート対象外）

サポートされていないbuildpackが必要な場合は、カスタムbuildpackの使用を検討してください。

2.3. Auto Code Quality - コード品質の分析

Auto Code Qualityは、Code Qualityイメージを使用して静的解析とコードチェックを実行します。

機能:

  • 静的解析によるコード品質の評価
  • レポートをアーティファクトとして保存
  • マージリクエストウィジェットでソースブランチとターゲットブランチの差分を表示

利用可能なティア: GitLab Free以上（GitLab 13.2以降）

実用例:

マージリクエストを作成すると、コード品質スコアの変化が自動的に表示されます。新しいコードが既存のコードベースの品質を低下させていないかを確認できます。

3. セキュリティ・品質フェーズ

3.1. Auto SAST - 静的アプリケーションセキュリティテスト

Auto SASTは、コードに対して静的解析を実行し、潜在的なセキュリティ問題を検出します。

要件:

  • GitLab Runner 11.5以降

機能:

  • セキュリティレポートをアーティファクトとして保存
  • マージリクエストウィジェットでセキュリティ警告を表示（Ultimateライセンス）

利用可能なティア:

  • GitLab Ultimate 10.3で導入
  • GitLab 13.1以降は一部機能がすべてのティアで利用可能

検出例:

  • SQLインジェクションの脆弱性
  • クロスサイトスクリプティング（XSS）
  • 安全でない暗号化の使用
  • ハードコードされた認証情報

3.2. Auto Secret Detection - シークレット検出

Secret Detectionは、コード内に漏洩したシークレット（APIキー、パスワード、トークンなど）を検出します。

機能:

  • Secret Detection Dockerイメージを使用した検出
  • 検出結果をアーティファクトとして保存
  • マージリクエストウィジェットでセキュリティ警告を表示（Ultimateライセンス）

検出対象の例:

  • AWSアクセスキー
  • GitHubトークン
  • プライベートキー
  • データベース接続文字列
  • APIキー

3.3. Auto Dependency Scanning - 依存関係のスキャン

Dependency Scanningは、プロジェクトの依存関係を分析し、既知の脆弱性を検出します。

利用可能なティア: GitLab Ultimate

機能:

  • 依存関係の脆弱性を検出
  • CVE（Common Vulnerabilities and Exposures）データベースと照合
  • レポートをアーティファクトとして保存
  • マージリクエストウィジェットでセキュリティ警告を表示

実用例:

古いバージョンのライブラリに既知の脆弱性がある場合、マージリクエスト時に警告が表示され、アップデートを促します。

3.4. Auto Container Scanning - コンテナスキャン

Container ScanningはTrivyを使用してDockerイメージの脆弱性を検出します。

利用可能なティア: GitLab Ultimate

機能:

  • Dockerイメージのセキュリティ問題を検出
  • OSパッケージの脆弱性をスキャン
  • レポートをアーティファクトとして保存
  • マージリクエストで検出されたセキュリティ問題を表示

検出対象:

  • ベースイメージの脆弱性
  • インストールされたパッケージの脆弱性
  • 設定の問題

4. デプロイ・検証フェーズ

4.1. Auto Review Apps - レビュー環境の自動作成

Review Appsは、ブランチのコードに基づいた一時的なアプリケーション環境を自動作成します。開発者、デザイナー、QA、プロダクトマネージャーなどが、レビュープロセスの一環としてコード変更を実際に確認できます。

要件:

  • Kubernetesクラスタが利用可能であること
  • 要件が満たされない場合、ジョブは静かにスキップされます

機能:

  • 各ブランチに対してReview Appを自動作成
  • ユニークなURLを生成（例: 13083-review-project-branch-123456.example.com）
  • マージリクエストウィジェットにReview Appへのリンクを表示
  • ブランチまたはタグが削除されると、Review Appも自動削除

デプロイ方法:

  • auto-deploy-app Helmチャートを使用
  • Kubernetesの環境用ネームスペースにデプロイ
  • Local Tillerを使用

実用例:

4.2. Auto DAST - 動的アプリケーションセキュリティテスト

DASTは、OWASP ZAProxyを使用して、実行中のアプリケーションを分析し、潜在的なセキュリティ問題を検出します。

利用可能なティア: GitLab Ultimate

スキャン対象:

  • デフォルトブランチ: 専用にデプロイされたアプリケーション（スキャン後に削除）
  • フィーチャーブランチ: Review App

機能:

  • 実行時のセキュリティ脆弱性を検出
  • Security Dashboardとマージリクエストウィジェットに結果を表示

検出例:

  • 認証・認可の問題
  • セッション管理の脆弱性
  • 入力検証の不備
  • セキュリティヘッダーの欠落

4.2.1. DASTターゲットのカスタマイズ

自動デプロイされたReview Appsの代わりにカスタムターゲットを使用する場合:

variables:
  DAST_WEBSITE: "https://staging.example.com"

重要な警告:

DAST Full Scanが有効な場合、DAST_WEBSITEをステージング環境や本番環境に設定しないでください。DAST Full Scanはターゲットに対して積極的に攻撃を行うため、アプリケーションのダウンやデータの損失・破損につながる可能性があります。

4.2.2. DASTのスキップ設定

variables:
  # すべてのブランチでDASTをスキップ
  DAST_DISABLED: "true"
  
  # デフォルトブランチのみDASTをスキップ
  DAST_DISABLED_FOR_DEFAULT_BRANCH: "true"
  
  # フィーチャーブランチのみDASTをスキップ（Review Appもスキップされます）
  REVIEW_DISABLED: "true"

4.3. Auto Browser Performance Testing - ブラウザパフォーマンステスト

Auto Browser Performance Testingは、Sitespeed.ioを使用してWebページのブラウザパフォーマンスを測定します。

利用可能なティア: GitLab Premium、Ultimate

機能:

  • 各ページの総合パフォーマンススコアを含むJSONレポートを作成
  • デフォルトでReview環境と本番環境のルートページをテスト
  • ソースブランチとターゲットブランチのパフォーマンス差分を表示

追加URLのテスト:

ルートディレクトリに.gitlab-urls.txtファイルを作成します。

/
/features
/direction
/products
/about

測定される指標:

  • ページ読み込み時間
  • First Contentful Paint（FCP）
  • Largest Contentful Paint（LCP）
  • Time to Interactive（TTI）
  • Total Blocking Time（TBT）

4.4. Auto Load Performance Testing - 負荷パフォーマンステスト

Auto Load Performance Testingは、k6を使用してアプリケーションのサーバーパフォーマンスを測定します。

利用可能なティア: GitLab Premium、Ultimate

初期セットアップ:

  1. アプリケーション専用のk6テストスクリプトを作成
  2. 環境の動的URLをCI/CD変数経由で取得できるように設定

k6テストスクリプトの例:

import http from 'k6/http';
import { check } from 'k6';

export let options = {
  stages: [
    { duration: '30s', target: 20 },  // 30秒かけて20ユーザーまで増加
    { duration: '1m', target: 20 },   // 1分間20ユーザーを維持
    { duration: '30s', target: 0 },   // 30秒かけて0ユーザーまで減少
  ],
};

export default function() {
  // CI/CD変数から動的URLを取得
  let url = __ENV.CI_ENVIRONMENT_URL || 'http://localhost:5000';
  let response = http.get(url);
  
  check(response, {
    'ステータスコードが200': (r) => r.status === 200,
    'レスポンスタイムが200ms以下': (r) => r.timings.duration < 200,
  });
}

測定される指標:

  • リクエスト/秒
  • レスポンスタイム
  • エラー率
  • スループット

4.5. Auto Deploy - 自動デプロイ

Auto Deployは、アプリケーションをKubernetesクラスタまたはAmazon EC2に自動デプロイします。

デプロイタイミング:

ブランチまたはマージリクエストがプロジェクトのデフォルトブランチにマージされた後、production環境に自動デプロイされます。

デプロイ先:

  • Kubernetesクラスタ（プロジェクト名とユニークなプロジェクトIDに基づいたネームスペース、例: project-4321）
  • Amazon EC2

デフォルトの動作:

  • 本番環境へのデプロイのみ
  • ステージング環境やカナリア環境へのデプロイは、Auto DevOpsテンプレートに定義されているため、有効にすることが可能

カスタマイズ:

CI/CD変数を使用して、ポッドレプリカの自動スケーリングやHelmコマンドのカスタマイズが可能です。

variables:
  # ポッドレプリカ数の設定
  REPLICAS: "3"
  
  # カスタムHelmアップグレード引数
  HELM_UPGRADE_EXTRA_ARGS: "--timeout 600s --wait"

重要な警告 - Helmの操作について:

Helm以外の方法（Kubernetesを直接使用）でアプリケーションを操作しないでください。以下の問題が発生する可能性があります。

  1. Helmが変更を検出できず、Auto DevOpsによる後続のデプロイで変更が元に戻される
  2. 再デプロイで元に戻そうとしても、Helmは何も変更されていないと判断し、古い設定を再適用しない

正しい操作方法:

  • Helmチャートをカスタマイズする
  • CI/CD変数で設定を変更する
  • .gitlab/auto-deploy-values.yamlファイルで値をオーバーライドする

4.5.1. GitLab Deploy Tokens

Auto DevOpsが有効な場合、内部およびプライベートプロジェクトに対してGitLab Deploy Tokensが自動作成されます。

機能:

  • レジストリへの永続的なアクセスを提供
  • 手動で取り消した後は自動的に再作成されない

認証情報のフォールバック:

GitLab Deploy Tokenが見つからない場合、CI_REGISTRY_PASSWORDが使用されます。

注意: CI_REGISTRY_PASSWORDはデプロイ中のみ有効です。ポッドの退避後などに再度イメージをプルする必要がある場合、KubernetesはCI_REGISTRY_PASSWORDを使用してイメージを取得しようとするため、プルに失敗します。

4.5.2. Kubernetes 1.16以降への対応

Kubernetes 1.16以降では、extensions/v1beta1バージョンのDeploymentサポートが削除されました。

対応方法:

  1. GitLab 13.0以降で初めてデプロイする場合

    • 設定は不要です

  2. クラスタ内PostgreSQLを使用している場合

    • AUTO_DEVOPS_POSTGRES_CHANNELを1に設定している場合、PostgreSQLアップグレードガイドに従ってください
    • バージョン2を選択する前に、必ずデータベースをバックアップおよび復元してください

デフォルト値の変更:

deploymentApiVersion設定のデフォルト値がextensions/v1betaからapps/v1に変更されました。

4.5.3. データベースマイグレーション

PostgreSQLのデータベース初期化とマイグレーションは、CI/CD変数で設定できます。

DB_INITIALIZEの動作:

  • Helmのpost-installフックとして実行
  • 初回デプロイ時のみ実行（デプロイが成功した後は実行されません）
  • データベース初期化が必要なアプリケーションのために、GitLabは最初のリリースをアプリケーションデプロイなしで実行

DB_MIGRATEの動作:

  • Helmのpre-upgradeフックとして実行
  • アップグレード前に毎回実行

Railsアプリケーションの設定例:

variables:
  # データベース初期化（初回のみ実行）
  DB_INITIALIZE: "RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:setup"
  
  # データベースマイグレーション（アップグレード前に毎回実行）
  DB_MIGRATE: "RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:migrate"

注意: リポジトリにDockerfileが含まれていない場合、イメージはCloud Native Buildpacksでビルドされるため、コマンドの前に/cnb/lifecycle/launcherを付ける必要があります。

4.5.4. Workerプロセスの設定

一部のWebアプリケーションは、バックグラウンドタスクを実行するためにworkerプロセスを必要とします。

要件:

  1. ヘルスチェックへの対応

    • Workerはポート5000で成功したHTTPレスポンスを返す必要があります
    • Sidekiqの場合、sidekiq_alive gemを使用できます

  2. Redisインスタンスの準備

    • Auto DevOpsはRedisインスタンスをデプロイしません
    • 独自のRedisインスタンスを維持する必要があります
    • CI/CD変数K8S_SECRET_REDIS_URLにRedisインスタンスのURLを設定

Sidekiq workerの設定例:

.gitlab/auto-deploy-values.yamlファイルを作成します。

workers:
  # workerの名前（任意の名前を指定可能）
  tanaka:
    # レプリカ数
    replicaCount: 1
    
    # 起動コマンド
    command:
      - /cnb/lifecycle/launcher
      - sidekiq
    
    # 停止前に実行するコマンド（グレースフルシャットダウン）
    preStopCommand:
      - /cnb/lifecycle/launcher
      - sidekiqctl
      - quiet
    
    # 終了猶予期間（秒）
    terminationGracePeriodSeconds: 60

Redis接続の設定:

variables:
  # RedisインスタンスのURL
  K8S_SECRET_REDIS_URL: "redis://redis.example.com:6379/0"

4.5.5. コンテナ内でのコマンド実行

リポジトリにカスタムDockerfileが含まれていない場合、Auto Buildでビルドされたアプリケーションでは、コマンドを/cnb/lifecycle/launcherでラップする必要があります。

コマンドのラップが必要な場面:

  • kubectl execを使用したアタッチ
  • GitLab Webターミナルの使用

実行例:

# Railsコンソールの起動
/cnb/lifecycle/launcher procfile exec bin/rails c

# データベースマイグレーション
/cnb/lifecycle/launcher bin/rails db:migrate

# カスタムRakeタスク
/cnb/lifecycle/launcher bin/rake custom:task

4.6. Auto Code Intelligence - コードインテリジェンス

GitLab Code Intelligenceは、IDE（統合開発環境）に共通するコードナビゲーション機能を追加します。

機能:

  • 型シグネチャの表示
  • シンボルドキュメントの表示
  • 定義へのジャンプ

技術:

  • LSIFを使用
  • 現在はGo言語のみサポート

今後の展開:

より多くのLSIFインデクサーが利用可能になるにつれて、GitLabは他の言語のサポートを追加する予定です。

無効化:

このステージはデフォルトで有効です。無効にする場合:

variables:
  CODE_INTELLIGENCE_DISABLED: "true"

5. よくある設定パターン

5.1. 特定のステージを無効化する

variables:
  # テストをスキップ
  TEST_DISABLED: "true"
  
  # コード品質チェックをスキップ
  CODE_QUALITY_DISABLED: "true"
  
  # SASTをスキップ
  SAST_DISABLED: "true"
  
  # Secret Detectionをスキップ
  SECRET_DETECTION_DISABLED: "true"
  
  # Dependency Scanningをスキップ
  DEPENDENCY_SCANNING_DISABLED: "true"
  
  # Container Scanningをスキップ
  CONTAINER_SCANNING_DISABLED: "true"
  
  # DASTをスキップ
  DAST_DISABLED: "true"
  
  # Browser Performance Testingをスキップ
  BROWSER_PERFORMANCE_DISABLED: "true"
  
  # Load Performance Testingをスキップ
  LOAD_PERFORMANCE_DISABLED: "true"
  
  # Code Intelligenceをスキップ
  CODE_INTELLIGENCE_DISABLED: "true"

5.2. 環境別の設定

variables:
  # 本番環境のレプリカ数
  PRODUCTION_REPLICAS: "5"
  
  # ステージング環境のレプリカ数
  STAGING_REPLICAS: "2"
  
  # Auto DevOpsのドメイン
  AUTO_DEVOPS_DOMAIN: "example.com"
  
  # PostgreSQLの有効化
  POSTGRES_ENABLED: "true"
  
  # PostgreSQLのバージョン
  POSTGRES_VERSION: "13"

5.3. カスタムビルド設定

variables:
  # カスタムDockerイメージレジストリ
  CI_REGISTRY: "registry.example.com"
  
  # カスタムビルダー
  AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER: "paketobuildpacks/builder:base"
  
  # カスタムbuildpack
  BUILDPACK_URL: "https://github.com/example/custom-buildpack"
  
  # ビルド時のボリュームマウント
  BUILDPACK_VOLUMES: "/mnt/cache:/cache:rw"

6. まとめと次のステップ

GitLab Auto DevOpsは、ビルドからデプロイまでの一連のプロセスを自動化し、開発チームが本質的な開発作業に集中できるようにします。

Auto DevOpsの主な利点:

  1. 設定の簡素化 - 最小限の設定でCI/CDパイプラインを構築
  2. セキュリティの強化 - SAST、Secret Detection、Dependency Scanning、Container Scanning、DASTによる多層的なセキュリティチェック
  3. 品質の向上 - 自動テスト、コード品質分析、パフォーマンステストによる品質保証
  4. 迅速なフィードバック - Review Appsによる視覚的なレビューとフィードバック
  5. 自動デプロイ - マージ後の自動デプロイによる迅速なリリース

導入の推奨ステップ:

段階的な導入:

  1. フェーズ1: 基本的なCI/CD

    • Auto Build
    • Auto Test
    • Auto Code Quality

  2. フェーズ2: セキュリティ強化

    • Auto SAST
    • Auto Secret Detection
    • Auto Dependency Scanning（Ultimateプランの場合）
    • Auto Container Scanning（Ultimateプランの場合）

  3. フェーズ3: レビュープロセスの改善

    • Auto Review Apps

  4. フェーズ4: 高度なテスト

    • Auto DAST（Ultimateプランの場合）
    • Auto Browser Performance Testing（Premium/Ultimateプランの場合）
    • Auto Load Performance Testing（Premium/Ultimateプランの場合）

  5. フェーズ5: 本番デプロイ

    • Auto Deploy

次のアクション:

  1. プロジェクトでAuto DevOpsを有効化する
  2. 必要に応じてCI/CD変数を設定する
  3. .gitlab/auto-deploy-values.yamlでHelmチャートをカスタマイズする
  4. 段階的に各ステージを有効化し、チームのワークフローに統合する

これらのステージを理解し、適切に活用することで、開発チームは高品質なアプリケーションを効率的に提供できます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?