ノート:
- このチュートリアルでは、Oracle Cloudへのアクセスが必要です。無料アカウントにサインアップするには、Oracle Cloud Infrastructure Free Tierの開始を参照してください。
- Oracle Cloud Infrastructureの資格証明、テナンシおよびコンパートメントに例の値を使用します。演習を終える際は、これらの値をクラウド環境に固有の値に置き換えてください。
GitLab CI/CDからOCI Container Engine for Kubernetesにデプロイ
イントロダクション
DevOpsとクラウドネイティブ開発の急速に進化する状況では、バージョン管理システムとコンテナ・オーケストレーション・プラットフォーム間の合理化された統合の必要性が重要になる可能性があります。Oracle Cloud Infrastructure Container Engine for Kubernetes(OKE)は、コンテナ化されたアプリケーションを管理するための堅牢でスケーラブルなソリューションを提供します。ただし、一部のチームには、Oracle Cloud Infrastructure (OCI)ネイティブのDevOpsサービスの代替案を探すための特定のプリファレンスおよび要件がある場合があります。
GitLabは、汎用的で包括的なバージョン管理と継続的インテグレーションおよび継続的デリバリ/デプロイメント(CI/CD)プラットフォームであり、これらのプリファレンスを満たすだけでなく、OCI DevOpsサービスの魅力的な代替機能も提供します。このチュートリアルでは、GitLabをOracle Cloud Infrastructure Container Engine for Kubernetes (OKE)にシームレスに接続するプロセスを順を追って説明します。このチュートリアルで示す統合は、既存のGitLabソリューションを使用するように整列するだけでなく、バージョン管理、継続的インテグレーションおよびKubernetesオーケストレーションのための統合ソリューションをチームに提供します。
後続の項では、この統合を行うための2つの異なるアプローチを紹介します。
-
アプローチ1: Oracle Cloud Infrastructureコマンドライン・インタフェース(OCI CLI)から生成された短期間のトークンを使用します。OKEクラスタ・アクセス手順を使用してクラスタ用に
kubeconfig
ファイルを設定すると、デフォルトでは、存続期間の短いクラスタ・スコープのユーザー固有の認証トークンを生成するOCI CLIコマンドが含まれています。CLIコマンドで生成される認証トークンは、Kubernetesコマンドライン・ツール(kubectl)およびKubernetesダッシュボードを使用してクラスタにアクセスする個々のユーザーを認証するのに適しています。ただし、このアプローチは、本番環境ではなくテスト目的で制限することをお薦めします。 -
アプローチ2: Kubernetesサービス・アカウントの使用。アプローチ1から短期間で生成された認証トークンは、CI/CDツールなどのクラスタにアクセスするプロセスおよびツールの認証には適していません。クラスタへのアクセスを確保するために、このようなツールには、ユーザー固有でない長期間の認証トークンが必要です。これは、Kubernetesサービス・アカウントを使用して実現できます。
目的
-
GitLabランナーを構成します。
-
CI/CDパイプラインを設定します。
前提条件
-
アクティブなOCIアカウント。
-
パブリック・エンドポイントを含む実行中のOKEクラスタ。Container Engine for Kubernetesの概要を参照してください。
-
十分な権限を持つGitLabアカウント。
アプローチ1: 短期間で生成されたトークンを使用して、GitLab CI/CDからOKEにデプロイ
タスク1: OCIコンピュート・インスタンスの準備
仮想マシン(VM)など、GitLabランナーのOCIコンピュート・インスタンスが必要になります。
-
VMにkubectlをインストールします。詳細は、Linuxでのkubectlのインストールおよび設定を参照してください。
-
OCI CLIをインストールし、OCIテナンシへの認証用の構成ファイルを作成します(または、クラスタ・アクセス・ステップの実行時に作成するよう求められます)。詳細は、OCI CLIのインストールおよびSDKおよびCLIの構成ファイルを参照してください。
-
OKEクラスタへのアクセスを設定します。「クラスタへのアクセス」に移動し、OCIコンソールから「ローカル・アクセス」の手順をクリックします。
-
VMにGitLabランナーをインストールします。rootユーザーで次のコマンドを実行します。
sudo curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash sudo yum install -y gitlab-runner
GitLab Runnerの動作を確認します。
gitlab-runner list
タスク2: GitLabランナーおよびプロジェクトの構成
-
GitLabにログインし、「プロジェクト」に移動して新しいプロジェクトを作成するか、既存のプロジェクトを使用します。
-
ランナーを作成するか、既存のランナーを使用します。新しいランナーを作成するには、「設定」、「CI/CD」、「ランナー」および「展開」に移動します。「新規プロジェクト・ランナー」をクリックし、「プラットフォーム」(Linuxなど)を選択し、デプロイ・パイプラインの構成時に後で
.gitlab-ci.yaml
ファイルで使用するタグを追加して、「ランナーの作成」をクリックします。 -
VMにランナーを登録します。
ノート:後で必要な場合は、ランナー認証トークンをノートにとります。
-
gitlab-runner register
コマンドを実行し、次の情報を入力します。- GitLabインスタンスURL: デフォルト値の
https://gitlab.com
を受け入れます。 - ランナー名:
config.toml
ファイルでローカルに有効です。たとえば:gitlab-oke-runner
。 - エグゼキュータの入力: shell。この値を使用して、kubectlおよびOCI CLIがインストールされているローカル・マシンでCI/CD命令を実行することを選択します。
- GitLabインスタンスURL: デフォルト値の
-
ランナー構成は、ファイル
$HOME/.gitlab-runner/config.toml
で確認できます。
-
タスク3: CI/CDパイプラインの設定
-
GitLabプロジェクトをローカル・マシンにクローニングします。
-
ビルドおよびデプロイ手順を含む
.gitlab-ci.yaml
という名前のファイルをプロジェクト・ディレクトリに作成します。「デプロイ」セクションで、ランナーの作成時に設定したランナー・タグを必ず含めてください。$ cat ~/demo-oke/.gitlab-ci.yml stages: - build - deploy build_job: stage: build script: - echo "Building the ServiceAccount project..." deploy_job: stage: deploy script: - echo "Deploying an nginx pod to the OKE cluster" - kubectl run nginx --image=nginx tags: - shell-executor
-
変更をGitLabプロジェクトにプッシュし、「ビルド」および「ジョブ」に移動して、ビルド・パイプラインおよびデプロイ・パイプラインがトリガーされて正常に実行されていることを確認します。
パイプラインは、OKEクラスタにnginxポッドをデプロイしました。
ノート:タグとキーをノートにとります。ローカル・マシン・リソースを使用するシェル・エグゼキュータを選択します。それ以外の場合は、たとえばDockerを選択した場合は、kubectl (およびアプローチ1のOCI CLI)をコンテナにインストールするイメージを指示で指定する必要があります。
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx 1/1 Running 0 47h
アプローチ2: Kubernetesサービス・アカウントを使用したGitLab CI/CDからOKEへのデプロイ
アプローチ1からタスク1、2および3を繰り返して、ローカルVMの設定(kubectl、OCI CLI、GitLab Runnerのインストール)、ランナーの登録、パイプライン・ファイル.gitlab-ci.yaml
の作成を行います。
タスク1: Kubernetesサービス・アカウントの作成およびトークンの追加
-
Kubernetesサービス・アカウントを作成し、そのトークンを
kubeconfig
ファイルに追加します。詳細は、Kubeconfigファイルへのサービス・アカウント認証トークンの追加を参照してください。ノート: OCI CLIの短命トークンではなく、サービス・アカウントが使用されていることを確認します。
-
現在のコンテキストの
kubeconfig
ファイルに指定したユーザーを、次のkubectlコマンドを使用して作成した新しいサービス・アカウント・ユーザーに設定します。kubectl config set-context --current --user=<service-account-name>
たとえば次のようにします。
kubectl config set-context --current --user=kubeconfig-sa
Kubernetesサービス・アカウントを使用してGitLabからOKEにデプロイする場合、プロセスでは、サービス・アカウント資格証明を使用してKubernetesクラスタでGitLabを認証します。
次のステップ
これらのタスクを使用すると、GitLab CI/CDパイプラインを使用してOKEにデプロイできます。これらのタスクは、他のCI/CDツールのリファレンスとして使用できます。この統合により、継続的な統合と配信が容易になり、OKEへのアプリケーションの迅速な反復およびデプロイメントが可能になります。
このチュートリアルでは、シェル・エグゼキュータを使用して、直接シナリオをテストおよび処理します。または、Dockerエグゼキュータなど、別のエグゼキュータを選択できます。このような場合、パイプラインはローカル・マシンではなくDockerコンテナ内で実行されます。Dockerエグゼキュータで実行するには、必要なユーティリティを含むDockerイメージを指定する必要があります。そのため、特定のパイプライン要件を満たすには、kubectlやOCI CLIなどのツールを組み込むことで、カスタム・イメージの作成が不可欠になる場合があります。
関連リンク
承認
- 著者 - Adina Nicolescu (シニア・クラウド・エンジニア)、Guido Alejandro Ferreyra (プリンシパル・クラウド・アーキテクト)
その他の学習リソース
docs.oracle.com/learnの他のラボをご覧いただくか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。
製品ドキュメントは、Oracle Help Centerを参照してください。
Deploy to OCI Container Engine for Kubernetes from GitLab CI/CD
F92406-01
February 2024
Copyright © 2024, Oracle and/or its affiliates.