Auto DevOpsを使用してGoogle Kubernetes Engineにアプリケーションをデプロイします。

このチュートリアルでは、Google Kubernetes Engine(GKE) にアプリケーションをデプロイする方法の例を通して、AutoDevOpsを使い始める手助けをします。

GitLabネイティブのKubernetesインテグレーションを使っているので、Google Cloud Platformコンソールを使って手動でKubernetesクラスターを作成する必要はありません。GitLabテンプレートから作成したアプリケーションを作成し、デプロイしています。

これらの手順は、自分で管理するGitLabインスタンスでも使えます。自分のRunnerが設定され、Google OAuthが有効になっていることを確認してください。

プロジェクトを Google Kubernetes Engine にデプロイするには、以下の手順に従います：

  1. Googleアカウントの設定
  2. Kubernetesクラスターを作成し、エージェントをデプロイします。
  3. テンプレートから新しいプロジェクトを作成します。
  4. エージェントの設定
  5. Ingressのインストール
  6. Auto DevOpsの設定
  7. Auto DevOpsを有効にしてパイプラインを実行
  8. アプリケーションのデプロイ

Google アカウントの設定

Kubernetesクラスターを作成してGitLabプロジェクトに接続する前に、Google Cloud Platformのアカウントが必要です。GmailやGoogle Driveにアクセスするためのアカウントなど、既存のGoogleアカウントでサインインするか、新しいアカウントを作成します。

  1. Kubernetes Engineドキュメントの“Before you begin “セクションに記載されている手順に従って、必要なAPIと関連サービスを有効にします。
  2. Google Cloud Platformで課金アカウントを作成していることを確認します。
note
Google Cloud Platform(GCP) の新規アカウントには$300のクレジットが付与され、Googleとのパートナーシップにより、GitLabとGoogle Kubernetes Engineのインテグレーションを開始するために、GitLabは新規GCPアカウントに$200の追加クレジットを提供することができます。このリンクからクレジットを申請してください。

Kubernetesクラスターを作成します。

Google Kubernetes Engine(GKE) 上に新しいクラスターを作成するには、Create a Google GKE clusterガイドの手順に従って、Infrastructure as Code (IaC) アプローチを使用します。このガイドでは、Terraformを使用してGKEクラスターを作成し、Kubernetes用のGitLabエージェントをインストールする新しいプロジェクトを作成する必要があります。このプロジェクトにはGitLabエージェントの設定があります。

テンプレートからアプリケーションプロジェクトを作成します。

GitLab プロジェクトのテンプレートを使って始めましょう。その名前が示すように、これらのプロジェクトは有名なフレームワークで作られた骨組みのないアプリケーションを提供します。

caution
クラスター管理用のプロジェクトと同じレベルかそれ以下のグループ階層にアプリケーションプロジェクトを作成します。そうしないと、エージェントの作成者が失敗します。
  1. 左サイドバーの上部にある「新規作成({plus})」と「新規プロジェクト/リポジトリ」を選択します。
  2. テンプレートから作成」を選択します。
  3. Ruby on Railsテンプレートを選択します。
  4. GitLab Ultimate プランで利用できる機能を利用できるように、プロジェクト名を付け、オプションで説明を付けて公開します。
  5. Create projectを選択します。

これで、GKE クラスターにデプロイするアプリケーション・プロジェクトができました。

エージェントの設定

アプリケーションプロジェクトをデプロイするためにKubernetes用のGitLabエージェントを設定する必要があります。

  1. クラスターを管理するために作成したプロジェクトに移動します。
  2. エージェント設定ファイル(.gitlab/agents/gke-agent/config.yaml)に移動し、編集します。
  3. ci_access:projects 属性を設定します。アプリケーションのプロジェクトパスをidとして使用します：
ci_access:
  projects:
    - id: path/to/application-project

Ingressのインストール

クラスターが稼働したら、インターネットからアプリケーションにトラフィックをルーティングするためのロードバランサーとして NGINX Ingress Controller をインストールする必要があります。GitLabCluster管理プロジェクトテンプレートを使うか、Google Cloud Shellを使って手動でNGINX Ingress Controllerをインストールします：

  1. クラスターの詳細ページに移動し、詳細設定タブを選択します。
  2. Google Kubernetes Engineへのリンクを選択し、Google Cloud Console上のクラスターにアクセスします。
  3. GKE クラスターページで、[Connect] を選択し、[Run in Cloud Shell] を選択します。

  4. Cloud Shellが起動したら、以下のコマンドを実行してNGINX Ingress Controllerをインストールします：

    helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace gitlab-managed-apps --create-namespace
   
# Check that the ingress controller is installed successfully
kubectl get service ingress-nginx-controller -n gitlab-managed-apps

Auto DevOpsの設定

以下の手順に従って、Auto DevOpsに必要なベースドメインとその他の設定を構成します。

  1. NGINXをインストールしてから数分後、ロードバランサーがIPアドレスを取得するので、以下のコマンドで外部IPアドレスを取得します：

    kubectl get service ingress-nginx-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'

    名前空間を上書きした場合はgitlab-managed-apps を置き換えてください。

    次のステップで必要になるので、このIPアドレスをコピーしてください。

  2. アプリケーション・プロジェクトに戻ります。
  3. 左サイドバーで、Settings > CI/CDを選択し、Variablesを展開します。
    • アプリケーションデプロイメントドメインを値として、KUBE_INGRESS_BASE_DOMAIN というキーを追加します。この例では、ドメイン<IP address>.nip.io を使用します。
    • KUBE_NAMESPACE というキーに、デプロイの対象となるKubernetesネームスペースの値を追加します。環境ごとに異なる名前空間を使用できます。環境を設定し、環境スコープを使用します。
    • path/to/agent/project:gke-agent のような値でKUBE_CONTEXT というキーを追加します。環境スコープを選択します。
    • 変更を保存を選択します。

Auto DevOpsを有効にしてパイプラインを実行します。

Auto DevOpsはデフォルトで有効になっていますが、Auto DevOpsはインスタンスレベル(セルフマネージドインスタンスの場合)とグループレベルの両方で無効にすることができます。Auto DevOpsが無効になっている場合は、以下の手順で有効にしてください：

  1. 左側のサイドバーで、[Search]を選択するか、または[Go to]を選択してアプリケーションプロジェクトを見つけます。
  2. Settings > CI/CDを選択します。
  3. Auto DevOpsを展開します。
  4. Default to Auto DevOps pipelineを選択すると、さらに多くのオプションが表示されます。
  5. デプロイ戦略では、パイプラインがデフォルトブランチで正常に実行された後、アプリケーションを本番環境にデプロイするための継続的デプロイ戦略を選択します。
  6. 変更を保存を選択します。

  7. .gitlab-ci.yml ファイルを編集して Auto DevOps テンプレートを組み込み、変更をmaster ブランチにコミットします：

    include:
- template: Auto-DevOps.gitlab-ci.yml

コミットによってパイプラインが起動するはずです。次のセクションでは、パイプラインで各ジョブが何を行うのかを説明します。

アプリケーションのデプロイ

パイプラインが実行されるとき、それは何をしているのでしょうか？

パイプラインのジョブを表示するには、パイプラインのステータスバッジを選択します。パイプラインのジョブが実行されているときはアイコンが表示され、ジョブが完了するとページを更新せずに{status_success}（成功）または{status_failed}（失敗）に更新されます。

ジョブはステージに分けられます：

Pipeline stages

  • ビルド- アプリケーションはDockerイメージをビルドし、プロジェクトのコンテナレジストリにアップロードします（Auto Build）。

  • Test- GitLabはアプリケーションに対して様々なチェックを実行しますが、test を除く全てのジョブはテストステージで失敗しても構いません：

    • test ジョブは言語とフレームワークを検知してユニットテストとインテグレーションテストを実行します(Auto Test)。
    • code_quality ジョブはコードの品質をチェックし、失敗することを許可します(Auto Code Quality)。
    • container_scanning ジョブは、Docker コンテナに脆弱性があるかどうかをチェックし、失敗することを許可します(Auto Container Scanning)。
    • dependency_scanning ジョブはアプリケーションに脆弱性の影響を受けやすい依存関係があるかどうかをチェックし、失敗することを許可します(Auto Dependency Scanning)。
    • -sast をサフィックスとするジョブは、現在のコードの静的解析を実行し、潜在的なセキュリティ問題をチェックします。
    • secret-detection のジョブは漏えいしたシークレットをチェックし、失敗してもかまいません(Auto Secret Detection)。
    • license_scanning ジョブは非推奨であり、何の結果も出しません。失敗してもかまいません(Auto License Compliance)。

  • レビュー- デフォルトブランチのパイプラインには、このステージとdast_environment_deploy ジョブが含まれます。詳細については、動的アプリケーションセキュリティテスト(DAST) を参照してください。

  • 本番- テストとチェックが終わると、アプリケーションはKubernetesにデプロイされます（Auto Deploy）。

  • パフォーマンス- デプロイされたアプリケーションでパフォーマンステストが実行されます（Auto Browser Performance Testing）。

  • クリーンアップ- デフォルトブランチのパイプラインには、このステージとstop_dast_environment ジョブが含まれます。

パイプラインを実行した後、デプロイされたウェブサイトを表示し、それを監視する方法を学ぶ必要があります。

プロジェクトの監視

アプリケーションのデプロイに成功したら、[Operate (オペレーション)] > [Environments (環境)] に移動して、[Environments (環境)]ページでそのウェブサイトを表示し、健全性を確認できます。このページにはデプロイされたアプリケーションの詳細が表示され、右側の列には一般的な環境タスクにリンクするアイコンが表示されます：

Environments

  • ライブ環境を開く({external-link}) - 本番環境にデプロイされたアプリケーションの URL を開きます。
  • Monitoring({chart}) - PrometheusがKubernetesクラスターに関するデータを収集するメトリクスページを開き、メモリ使用量、CPU使用量、レイテンシに関してアプリケーションがクラスターにどのような影響を与えるかを表示します。
  • Deploy to({play} ) - デプロイできる環境のリストを表示します。
  • Terminal({terminal}) - アプリケーションが動作しているコンテナ内でウェブターミナルセッションを開きます。
  • 環境への再デプロイ({repeat}) - 詳細は、再試行とロールバックを参照してください。
  • 環境の停止({stop}) - 詳しくは環境の停止をご覧ください。

GitLab は環境情報の下にデプロイボードを表示し、四角は Kubernetes クラスター内のポッドを表し、その状態を色分けして表示します。デプロイボードの四角にカーソルを合わせるとデプロイの状態が表示され、四角を選択するとそのポッドのログページに移動します。

note
この例では、現時点でアプリケーションをホストしているポッドは1つだけですが、設定 > CI/CD > 変数で REPLICAS CI/CD 変数を定義することで、さらにポッドを追加できます。

ブランチでの作業

次に、アプリケーションにコンテンツを追加するための機能ブランチを作成します：

  1. プロジェクトのリポジトリで、次のファイルにアクセスしてください:app/views/welcome/index.html.erb 。このファイルには段落のみを記述します：<p>You're on Rails!</p>.
  2. GitLabWeb IDEを開いて変更を行います。

  3. ファイルを編集します：

    <p>You're on Rails! Powered by GitLab Auto DevOps.</p>

  4. ファイルをステージします。コミットメッセージを追加し、コミットを選択して新しいブランチとマージリクエストを作成します。

    Web IDE commit

マージリクエストを送信すると、GitLab はパイプラインとその中のすべてのジョブを実行します。

数分後、テストが失敗しました。これは、あなたの変更によってテストが「壊れた」ことを意味します。失敗したtest ジョブを選択すると、そのジョブについての詳細な情報を見ることができます：

Failure:
WelcomeControllerTest#test_should_get_index [/app/test/controllers/welcome_controller_test.rb:7]:
<You're on Rails!> expected but was
<You're on Rails! Powered by GitLab Auto DevOps.>..
Expected 0 to be >= 1.

bin/rails test test/controllers/welcome_controller_test.rb:4

壊れたテストを修正するには

  1. マージリクエストに戻ります。
  2. 右上の「Code」を選択し、「Open in Gitpod」を選択します。
  3. 左側のファイルディレクトリでtest/controllers/welcome_controller_test.rb ファイルを探し、それを選択して開きます。
  4. 7行目をYou're on Rails! Powered by GitLab Auto DevOps.
  5. コミットを選択します。
  6. 左側の列のUnstaged changes で、チェックマークアイコン({stage-all}) を選択して変更をステージします。
  7. コミットメッセージを書き、コミットを選択します。

マージリクエストの概要ページに戻ると、テストがパスしただけでなく、レビューアプリケーションとしてデプロイされたアプリケーションも表示されるはずです。View app ボタンを選択することで、デプロイされた変更を確認することができます。

マージリクエストをマージすると、GitLab はデフォルトブランチでパイプラインを実行し、アプリケーションを本番環境にデプロイします。

結論

このプロジェクトを実施した後は、Auto DevOps の基本をしっかりと理解しているはずです。アプリケーションのビルドとテストからデプロイと監視まで、すべてGitLabで行うようになりました。Auto DevOpsはその自動的な性質にもかかわらず、あなたのワークフローに合わせて設定やカスタマイズを行うこともできます。さらに読むのに役立つリソースをいくつか紹介します：

  1. Auto DevOps
  2. 複数のKubernetesクラスター
  3. 本番環境へのインクリメンタルなロールアウト
  4. CI/CD変数で不要なジョブを無効化
  5. 独自のビルドパックを使用してアプリケーションを構築