- 概要
- デフォルトで有効
- クイックスタート
- アプリケーション・プラットフォームやPaaSとの比較
- 特徴
- Kubernetesの要件
- 自動DevOpsベースドメイン
- 自動DevOpsの有効化/無効化
- 複数のKubernetesクラスターの使用
- 制限事項
- トラブルシューティング
- 開発者向けガイド
Auto DevOps
- GitLab 10.0で導入されました。
- 一般的にGitLab 11.0で利用可能です。
Auto DevOpsは、事前に定義されたCI/CD構成を提供し、アプリケーションの自動検出、ビルド、テスト、デプロイ、および監視を可能にします。 CI/CDのベストプラクティスとツールを活用することで、Auto DevOpsは、成熟した最新のソフトウェア開発ライフサイクルのセットアップと実行を簡素化することを目的としています。
概要
プロジェクトのビルド、デプロイ、モニタリングに必要なワークフローやプロセスを設定するために、多くの労力を費やすことになります。 会社にメンテナーすべきプロジェクトが何百、何千とある場合は、さらに悪化します。 新しいプロジェクトが絶えず立ち上がるため、ソフトウェア開発プロセス全体を管理するのは不可能なほど複雑になります。
Auto DevOps は、最小限の設定ですべてのプロジェクトのテスト、ビルド、パッケージ、デプロイ、監視に必要なすべての依存関係と言語テクノロジーを自動的に検出することで、シームレスなソフトウェア開発プロセスを提供します。 自動化により、プロジェクト全体の一貫性、プロセスのシームレスな管理、新しいプロジェクトの迅速な作成が可能になります。コードをプッシュすると、あとは GitLab が作業を行い、生産性と効率を向上させます。
Auto DevOpsの紹介については、GitLab 11.0のAutoDevOpsをご覧ください。
要件については、「Auto DevOpsの要件」を参照してください。
デフォルトで有効
GitLab 11.3で導入されました。
Auto DevOpsは、すべてのプロジェクトでデフォルトで有効になっており、各プロジェクト内のすべてのパイプラインで実行しようとします。 インスタンス管理者は、Auto DevOps設定でこのデフォルトを有効または無効にすることができます。 Auto DevOpsは、プロジェクトで明示的に有効になっていない場合、最初のパイプラインの失敗時に個々のプロジェクトで自動的に無効になります。
GitLab 12.7以降、Auto DevOps はDockerfile または一致する buildpackが存在する場合のみ、パイプライン上で自動的に実行されます。
プロジェクトにCI/CD設定ファイルが存在する場合、Auto DevOpsが有効になっているかどうかにかかわらず、CI/CD設定ファイルは引き続き使用されます。
クイックスタート
GitLab.comを使用している場合は、Google Kubernetes Engine(GKE)でGitLab.comとKubernetesクラスターを使用してAuto DevOpsを設定するためのクイックスタートガイドを参照してください。
GitLab のセルフマネージドインスタンスを使用する場合は、GKE にクラスターを設定する前に GoogleOAuth2 OmniAuth Providerを設定する必要があります。 プロバイダーを設定した後は、クイックスタートガイドの手順に従って作業を開始できます。
GitLab13.0以降では、Auto DevOpsを活用してAWS ECSにデプロイすることが可能です。
アプリケーション・プラットフォームやPaaSとの比較
Auto DevOpsは、アプリケーションプラットフォームやPlatform as a Service (PaaS)によく含まれる機能を提供します。 これは、Herokuが行った革新的な仕事からインスピレーションを受け、さまざまな点でそれを超えるものです：
- Auto DevOpsはどのKubernetesクラスターでも動作します。GitLabのインフラストラクチャでの動作に限定されることはありません（多くの機能はKubernetesなしでも動作することに注意してください）。
- 追加コストはかからず（インフラコストに上乗せされることはありません）、公開クラウド（GoogleKubernetes Engineなど）上のKubernetesクラスターやContainers as a Serviceを利用できます。
- Auto DevOpsには、セキュリティ・テスト、パフォーマンス・テスト、コード品質テストなどの機能があります。
- Auto DevOpsは、段階的な卒業パスを提供します。 高度なカスタマイズが必要な場合、まったく別のプラットフォームでやり直すことなく、テンプレートの変更を開始できます。 詳細については、カスタマイズのドキュメントをレビューしてください。
特徴
一連のステージで構成されるAuto DevOpsは、これらのベストプラクティスをシンプルかつ自動的な方法でプロジェクトにもたらします：
- オートビルド
- オートテスト
- オートコードの品質
- 自動SAST（静的アプリケーション・セキュリティ・テスト）
- 自動シークレット検出
- 自動依存関係スキャン
- 自動車免許コンプライアンス
- 自動コンテナスキャン
- オートレビューアプリ
- 自動DAST（動的アプリケーション・セキュリティ・テスト）
- 自動デプロイ
- 自動ブラウザ・パフォーマンス・テスト
- オートモニタリング
Auto DevOpsは多くの異なるコンポーネントに依存しているため、以下の基本的な知識を持っている必要があります：
Auto DevOpsはすべてのステージに優れたデフォルトを提供し、CIテンプレートを利用します。
Auto DevOpsの概要については、こちらのブログ記事をご覧ください。
Kubernetesの要件
Kubernetesの自動DevOps要件を参照してください。
自動DevOpsベースドメイン
Auto DevOpsのベースドメインは、Auto Review Apps、Auto Deploy、およびAuto Monitoringを使用するために必要です。 ベースドメインは、以下のいずれかの場所で定義できます：
- インスタンス、プロジェクト、グループのいずれであっても、クラスターの設定で
- または変数としてプロジェクトレベルで：
KUBE_INGRESS_BASE_DOMAIN - または変数としてグループレベルで：
KUBE_INGRESS_BASE_DOMAIN - またはインスタンス全体のフォールバックとして 管理エリア > [設定]の [継続的インテグレーションと配信] セクションにあります。
ベースドメイン変数KUBE_INGRESS_BASE_DOMAIN 、他の環境変数と同じ優先順位に従います。CI/CD変数が設定されておらず、クラスター設定が空白のままである場合、インスタンス全体のAuto DevOpsドメイン設定が設定されていれば、それが使用されます。
Auto DevOpsには、ベースドメインに一致するワイルドカードDNS Aレコードが必要です。ベースドメインがexample.comの場合、次のようなDNSエントリーが必要です：
*.example.com 3600 A 1.2.3.4
この場合、デプロイされたアプリケーションはexample.comから提供されます。1.2.3.4はロードバランサーの IP アドレスで、通常は NGINX です（要件を参照）。DNS レコードの設定はこのドキュメントの範囲外です。情報については DNS プロバイダーに確認してください。
また、nip.io のような無料の公開サービスを利用することもできます。nip.ioでは、Auto DevOps のベースドメインを1.2.3.4.nip.ioに設定します。
セットアップ完了後、すべてのリクエストはロードバランサーにヒットし、ロードバランサーはアプリケーションを実行しているKubernetesポッドにリクエストをルーティングします。
AWS ECS
AmazonECSのAuto DevOps要件を参照してください。
自動DevOpsの有効化/無効化
Auto DevOps を初めて使用する場合は、要件をレビューし、Auto DevOps をフル活用するために必要なコンポーネントがすべて利用可能であることを確認してください。 初めて使用するユーザーは、クイックスタートガイドに従ってください。
GitLab.comユーザーは、プロジェクトレベルでのみAuto DevOpsを有効または無効にすることができます。 セルフマネージドユーザーは、プロジェクト、グループ、インスタンスレベルでのみAuto DevOpsを有効または無効にすることができます。
プロジェクトレベル
有効になっている場合は、プロジェクトに.gitlab-ci.ymlがないことを確認するか、存在する場合は削除してください。
- プロジェクトの{設定} 設定 > CI/CD > Auto DevOpsに移動します。
- Default to Auto DevOps pipelineチェックボックスを選択して有効にします。
- (オプションですが、推奨）有効にすると、Auto DevOpsがアプリケーションのデプロイに使用するベースドメインを追加し、デプロイ戦略を選択できます。
- 変更を有効にするには、[変更を保存] をクリックします。
この機能を有効にすると、デフォルトブランチでAuto DevOpsパイプラインが起動します。
グループレベルで
GitLab 11.10 で導入されました。
グループレベルでAuto DevOpsを有効または無効にできるのは、管理者とグループオーナーだけです。
グループレベルで Auto DevOps を有効または無効にする場合、Auto DevOps がサブグループまたはプロジェクトで特に有効または無効になっていない限り、グループ構成はそのグループ内のサブグループおよびプロジェクトに暗黙的に使用されます。
グループレベルでAuto DevOpsを有効または無効にします：
- グループの{設定} 設定 > CI/CD > Auto DevOpsページに移動します。
- Default to Auto DevOps pipelineチェックボックスを選択して有効にします。
- 変更を有効にするには、[変更を保存] をクリックします。
インスタンスレベルで（管理者のみ）
インスタンスレベルで無効にした場合でも、グループオーナーとプロジェクトメンテナーは、それぞれグループレベルとプロジェクトレベルでAuto DevOpsを有効にすることができます。
- admin} 管理エリア > 設定 > 継続的インテグレーションとデプロイに移動します。
- Default to Auto DevOps pipeline for all projects]を選択して有効にします。
- (オプション）Auto DevOpsのベースドメインを設定し、Auto DeployアプリとAuto Reviewアプリが使用できるようにします。
- 変更を有効にするには、[変更を保存] をクリックします。
デプロイ戦略
GitLab 11.0で導入されました。
プロジェクトの Settings > CI/CD > Auto DevOpsでAuto DevOpsが使用するデプロイ戦略を変更できます。 以下のオプションが利用可能です：
-
本番環境への継続的デプロイ:
masterブランチを本番環境に直接デプロイする自動デプロイを有効にします。 -
時限付きインクリメンタル ロールアウトを使用した本番環境への継続的デプロイ:
INCREMENTAL_ROLLOUT_MODE変数をtimedに設定します。 本番環境へのデプロイは、ロールアウトの各インクリメント間に 5 分の遅延を設けて実行されます。 -
ステージングへの自動デプロイ、プロダクションへの手動デプロイ:
STAGING_ENABLEDとINCREMENTAL_ROLLOUT_MODE変数を1とmanualに設定します。 これは次のことを意味します：-
masterブランチは直接ステージングにデプロイされます。 - 手動アクションは、本番への段階的なロールアウトのために提供されます。
-
複数のKubernetesクラスターの使用
Auto DevOpsを使用する場合、Kubernetesクラスタ間は1:1で接続されているため、異なる環境を異なるKubernetesクラスタにデプロイすることができます。
Auto DevOpsが使用するデプロイジョブテンプレートは、現在3つの環境名を定義しています：
-
review/(で始まるすべてのreview/環境）。 stagingproduction
これらの環境はAuto Deployを使用するジョブに関連付けられます。そのため、環境スコープを除いて、異なるデプロイメントドメインを持つ必要があります。 上記のそれぞれについて、環境に応じて個別の変数KUBE_INGRESS_BASE_DOMAIN を定義する必要があります。
次の表は、3つの異なるクラスターを構成する方法の例です：
| クラスター名 | クラスター環境範囲 |
KUBE_INGRESS_BASE_DOMAIN 変数値
| 変数環境スコープ | 備考 |
|---|---|---|---|---|
| レビュー | review/*
| review.example.com
| review/*
| すべてのレビューアプリを実行するレビュークラスター。* はワイルドカードで、review/で始まるすべての環境名で使用されます。
|
| ステージング | staging
| staging.example.com
| staging
| (オプション）ステージング環境のデプロイを実行するステージング・クラスター。最初に有効にする必要があります。 |
| 生産 | production
| example.com
| production
| 本番環境のデプロイを実行するクラスター。インクリメンタルロールアウトを使用できます。 |
環境ごとに異なるクラスターを追加するには：
- プロジェクトの Operations > Kubernetesに移動します。
- 上の表から説明したように、それぞれの環境スコープでKubernetesクラスターを作成します。
- クラスタを作成したら、各クラスタに移動してIngressをインストールします。 IngressのIPアドレスが割り当てられるのを待ちます。
- 指定したAuto DevOpsドメインでDNSが設定されていることを確認してください。
- cloud-gear} Operations >Kubernetesから各クラスターのページに移動し、Ingress IPアドレスに基づいてドメインを追加します。
設定が完了したら、マージリクエストを作成し、review/* 環境スコープを持つ Kubernetes クラスターにアプリケーションがレビューアプリとしてデプロイされていることを確認することで、セットアップをテストできます。 同様に、他の環境も確認できます。
制限事項
以下の制限が適用されます。
非公開レジストリ対応
Auto DevOps で非公開コンテナレジストリを使用する文書化された方法は存在しません。 設定を簡素化し、予期せぬ問題を防ぐために、Auto DevOps で GitLab コンテナレジストリを使用することを強くお勧めします。
プロキシの背後にあるアプリケーションのインストール
GitLabのHelmインテグレーションは、プロキシ経由でのアプリケーションのインストールをサポートしていません。 プロキシ設定を行いたいユーザーは、PodPresetなどを使って、実行時にインストールポッドにプロキシ設定を注入する必要があります：
apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
name: gitlab-managed-apps-default-proxy
namespace: gitlab-managed-apps
spec:
env:
- name: http_proxy
value: "PUT_YOUR_HTTP_PROXY_HERE"
- name: https_proxy
value: "PUT_YOUR_HTTPS_PROXY_HERE"
トラブルシューティング
ビルドパックが選択できません
自動ビルドと自動テストでは、言語またはフレームワークの検出に失敗し、次のエラーが表示されることがあります：
Step 5/11 : RUN /bin/herokuish buildpack build
---> Running in eb468cd46085
-----> Unable to select a buildpack
The command '/bin/sh -c /bin/herokuish buildpack build' returned a non-zero code: 1
考えられる理由は以下の通りです：
- Rubyアプリは
Gemfile.NET Frameworkなしで書くことができますが、正しく検出さGemfileれるには.NET Frameworkが必要です。 - アプリケーションに対応するビルドパックが存在しない可能性があります。カスタムビルドパックを指定してみてください。
AutoDevOpsを拡張するパイプラインは、失敗のみ/失敗を除く
パイプラインが以下のメッセージで失敗した場合：
Found errors in your .gitlab-ci.yml:
jobs:test config key may not be used with `rules`: only
このエラーは、インクルードされたジョブのルール設定がonly またはexcept 構文で上書きされている場合に表示されます。 この問題を解決するには、以下のいずれかを行う必要があります：
-
only/except構文をルールに移行します。 - (一時的に）テンプレートをGitLab 12.10ベースのテンプレートに固定します。
Kubernetesネームスペースの作成失敗
GitLab がプロジェクト用の Kubernetes ネームスペースとサービスアカウントを作成できない場合、Auto Deploy は失敗します。 この問題のデバッグについては、失敗したデプロイジョブのトラブルシューティングを参照してください。
既存の PostgreSQL データベースを検出しました。
GitLab 13.0 にアップグレードした後、Auto DevOps でデプロイする際にこのメッセージが表示されることがあります：
Detected an existing PostgreSQL database installed on the
deprecated channel 1, but the current channel is set to 2. The default
channel changed to 2 in of GitLab 13.0.
[...]
Auto DevOpsはデフォルトで、アプリケーションと一緒にクラスタ内のPostgreSQLデータベースをインストールします。 GitLab 13.0でデフォルトのインストール方法が変更され、既存のデータベースをアップグレードするにはユーザーの関与が必要になりました。 2つのインストール方法があります：
- チャネル1（非推奨）：関連するHelmチャートの依存関係としてデータベースを引き込みます。 バージョン1.15までのKubernetesバージョンのみをサポートします。
- チャネル2（現在）：独立したHelmチャートとしてデータベースをインストールします。 Kubernetesバージョン1.16以降でクラスタ内データベース機能を使用するために必要です。
このエラーが表示された場合は、次のいずれかのアクションを実行してください：
-
警告を無視して、
AUTO_DEVOPS_POSTGRES_CHANNELを1に設定し、再デプロイすることで、安全にチャネル1の PostgreSQL データベースを使い続けることができます。 -
チャネル1のPostgreSQLデータベースを削除し、
AUTO_DEVOPS_POSTGRES_DELETE_V1を空でない値に設定して再デプロイすることで、新しいチャネル2のデータベースをインストールすることができます。危険:チャンネル 1 PostgreSQL データベースを削除すると、既存のチャンネル 1 データベースとそのすべてのデータが永久に削除されます。 データベースのバックアップとアップグレードの詳細については PostgreSQL のアップグレードを参照してください。 -
クラスタ内データベースを使用していない場合、
POSTGRES_ENABLEDをfalseに設定し、再デプロイすることができます。 このオプションは、チャート内のPostgreSQL依存関係を持たないカスタムチャートのユーザーに特に関連します。 データベースの自動検出は、リリースのpostgresql.enabledHelm値に基づいて行われます。この値は、チャートが変数を使用しているかどうかに関係なく、POSTGRES_ENABLEDCI変数に基づいて設定され、Helmによって永続化されます。
POSTGRES_ENABLED をPOSTGRES_ENABLED に設定すると、環境に存在するチャンネル1データベースが永久に削除されます。