Gilson Melo
Senior Principal Product Manager
オラクルのパブリック・クラウドは、オープン・ソース・テクノロジーとそうしたテクノロジーをサポートするコミュニティに対応しています。クラウド・ネイティブ・テクノロジーおよびDevOps手法へのシフトが加速するなか、当社は多くの企業や組織から、クラウド・プロバイダーによる構築か否かに関係なく、クラウドのロックインを回避し、必要な処理を実行できる、パフォーマンスと信頼性の高いクラウドを求める声に接してきました。Oracle Cloud InfrastructureでのGitLabの運用は、DevOpsプラットフォームにおいて、1つのアプリケーションでDevOpsの全ライフサイクルをカバーできる選択肢となります。
GitLab CI/CDとOracle Cloud
GitLabは、単一のアプリケーションとして提供される、完全にオープン・ソースのDevOpsプラットフォームです。これにより、開発、セキュリティ、およびオペレーションの各チームによる協調的なソフトウエア構築に根本的な変革をもたらすことができます。またGitLab CI/CDパイプライン自動DevOps機能とOracle Cloud InfrastructureのContainer Engine for Kubernetesとを統合することで、クラウドにてコードを構築、テスト、デプロイ、モニターできる、信頼性と拡張性に優れた総合的なワークフロー・プラットフォームを持つことができます。
Container Engine for Kubernetesは、クラウドでのKubernetesクラスタのデプロイ、管理、および拡張を支援するサービスです。このサービスを利用することで、企業や組織はOracle Cloud Infrastructureで運用しているサービスとKubernetesとを統合して、動的にコンテナ化されたアプリケーションを構築することができます。
CI/CDワークフロー
共有リポジトリにあるチームのコードは、継続的インテグレーション（CI）により統合できます。開発者がプル・リクエストを使って新しいコードを共有すると、そのリクエストをトリガーとして、パイプラインにてコードの構築、テスト、検証が実施され、その後リポジトリにマージされます。CIは、開発サイクルの早い段階でのエラーの発見、統合上の課題の削減、構成上の問題の回避に効果的です。
継続的デリバリ（CD）は、CIで検証済みのコードが、構造化されたデプロイメント・パイプラインを通じて間違いなくアプリケーションにデリバリされるようにするものです。またCDは、各変更がリリース可能であるようにし、各リリースのリスクを低減し、より多くの価値を高い頻度で提供し、顧客から迅速かつ頻繁にフィードバックを得られるようにするものです。
こうしたCIとCDを組み合わせることで、迅速かつ効果的な構築が可能になります。この組み合わせは、開発プロセスの最適化にとって非常に重要です。
始めるには
まずは、Container Engine for KubernetesにてGitLab CI/CDサービスを構築およびデプロイするために必要なコンポーネントを確認しましょう。Container Engine for KubernetesにGitLabをインストールするには、Oracle Cloud Infrastructure（OCI）とkubectlコマンド・ラインをインストールおよび設定している、デスクトップ（クラウドVMまたはオンプレミス）が必要です。
さらに、インストールを進めるには、以下のコンポーネントも必要です。
- バージョン1.14.8以降のKubernetes
- バージョン2.14以降のHelm/Tiller
- ローカルの仮想クラウド・ネットワーク（VCN）セキュリティ・リストで公開されている、Kubernetesのポッドとワーカー・ノードに対応するサブネットCIDRおよびポート
デプロイメント・プロセス
Oracle Container Engine for KubernetesにGitLabをデプロイするには、デプロイメント・ガイドを確認し、以下のステップを実施します。
- 次のコマンドを実行します。その際、「example.com」の部分を実際のDNSに変更します。Helmにて別のネームスペースにGitLabのリソースをインストールしたい場合は、「–install」の後に「–namespace NEW_NAME_SPACE」を追加します。
helm repo add gitlab https://charts.gitlab.io/ helm repo update helm upgrade --install gitlab gitlab/gitlab --set externalUrl=http://gitlab.example.com \ --timeout 600s \ --set global.hosts.domain=example.com \ --set certmanager-issuer.email=me@example.com
- プロビジョニング・プロセスが完了したら、次のコマンドを実行してGitLabに割り当てる外部IPアドレスを指定します。
kubectl get services gitlab-nginx-ingress-controller
- ステップ1のDNSエントリ（例：gitlab.example.com）でGitLabを指定します。お使いのDNSゾーン管理サービスを使用して、DNSレコード・エントリを更新します。これを実施しないと、ステップ5にて「default backend – 404」というエラー・メッセージが表示されます。404エラー・メッセージが表示された場合は、DNSエントリを修正して、GitLab Runnerポッドを再作成します。
- DNSゾーン・レコードが作成されたら、次のコマンドを使用して、ダッシュボードでの接続に必要なbase64ルート・パスワードを取得します。
kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo " - すべてのポッドが稼働するまで待ち、その後次のステップに進みます。以下のスクリーンショットは、Helmを通じてインストールされるポッドの一覧になります。
- ブラウザを開き、DNSアドレスを入力し、その後にrootのユーザー名とbase64パスワードを使用します。
- 既存のContainer Engine for Kubernetesクラスタ情報をGitLabに追加します。Admin Areaメニューにて「Kubernetes」を選択し、「Add Kubernetes cluster」に続いて「Add existing cluster」タブをクリックし、次の情報を入力します。
- Name：~/.kube/configファイルにあるクラスタ名を入力します。
- Environment scope：「*」を入力します。
- API URL：次のコマンドを実行してAPI URLを取得します。
kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}' - CA Certificate：kubectl get secretsを実行します。リスト化されたsecretの1つに「default-token-xxxxx」に類似した名前があるはずです。そのトークン名をコピーし、次のコマンドに使用します。次のコマンドを実行して証明書を取得します。
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode - Token：GitLabでは、特定のネームスペースに対してスコープされるサービス・トークンを使用して、Kubernetesの認証を実施します。使用されるトークンは、クラスタ管理者権限を持つサービス・アカウントに属している必要があります。このサービス・アカウントを作成するには、次の手順を実行します。
- 次の内容にて、gitlab-admin-service-account.yamlという名前で、ファイルを作成します。
apiVersion: v1 kind: ServiceAccount metadata: name: gitlab-admin namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: gitlab-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: gitlab-admin namespace: kube-system
- 次のコマンドを実行して、このサービス・アカウントとクラスタのロール・バインディングをクラスタに適用します。
kubectl apply -f gitlab-admin-service-account.yaml
結果は次のとおりです。
serviceaccount "gitlab-admin" created clusterrolebinding "gitlab-admin" created
- Gitlab管理者サービス・アカウント用のトークンを取り出します。
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
- 次の内容にて、gitlab-admin-service-account.yamlという名前で、ファイルを作成します。
- 「Add Kubernetes Cluster」をクリックします。インスタンス・クラスタが追加されます。
- インスタンス・クラスタにて、次のコンポーネントをインストールします。
- Helm Tiller
- Ingress
- Cert-Manager
- Prometheus
- GitLab Runner
Ingressがインストールされると、新しいパブリックのOracle Cloud Infrastructureロードバランサがプロビジョニングされます。
- UIに提示されているとおりにベース・ドメインをロードバランサのパブリックIPアドレスに変更し（例：OCI_Public_IP.nip.io）、「Save Changes」をクリックします。詳しくは、GitLabのドキュメントを参照してください。
以上です。これで、GitLab CI/CDパイプラインのインストールとContainer Engine for Kubernetesとの統合が完了しました。ここからは、GitLab CI/CDのワークフローのテストに移ります。
Oracle Cloud InfrastructureレジストリにてGitLab CI/CDパイプラインを使用
ここでは例として、GitLab CI/CDワークフローを使用して、プライベートOracle Cloud Infrastructureのレジストリ・リポジトリからイメージをプルし、これを再構築し、新しいビルド名にてレジストリにプッシュ・バックする方法を紹介します。
- レジストリ・リポジトリにプライベート・イメージがある場合は、次のステップまでスキップしてください。プライベート・イメージがない場合は、Dockerイメージを作成してプライベート・レジストリ・リポジトリにこれをアップロードし、KubernetesのSecretを作成します（Secret情報には、レジストリのユーザー名とパスワードを使用します）。これらのステップについては、次のチュートリアルを参照してください。
- 次の変数をGitLabに追加します。「Settings」 > 「CI/CD」の順に進み、「Variables」を開いて、次の変数のキーと値を追加します。
- OKE_REGISTRY：レジストリ・リージョンのエンドポイント（例：iad.ocir.io）
- OKE_REGISTRY_IMAGE：レジストリ・イメージ（例：iad.ocir.io/tenancy_name/imagename:build）
- OKE_REGISTRY_NEW_IMAGE：ビルド・プロセスの後にレジストリにプッシュされる、レジストリ・イメージの新しいビルド・バージョン（例：iad.ocir.io/tenancy_name/imagename:new_image）
- OKE_REGISTRY_PASSWORD：Oracle Cloud Infrastructureの認証トークン詳しくは、こちらのドキュメントを参照してください。
- OKE_REGISTRY_USER：Oracle_Cloud_Infrastructure_tenancy_name/usernam
- 内部のブランク・プロジェクトを作成します（例：gitlab-docker-ocir-oke）。
- 新しいファイルを2つ（「Dockerfile」と「.gitla-ci.yml」）作成します。これらは、GitLabをContainer Engine for Kubernetesおよびレジストリで運用するための基本的な例にすぎません。実際に作成する際は、必要に応じて修正してください。
- .gitlab-ci.yml
docker-build-master: # Official docker image. image: docker:latest stage: build services: - name: docker:19.03.0-dind entrypoint: ["env", "-u", "DOCKER_HOST"] command: ["dockerd-entrypoint.sh"] variables: #CI_DEBUG_TRACE: "true" DOCKER_HOST: tcp://localhost:2375/ DOCKER_DRIVER: overlay2 DOCKER_TLS_CERTDIR: "" before_script: - docker login -u "$OKE_REGISTRY_USER" -p "$OKE_REGISTRY_PASSWORD" $OKE_REGISTRY script: - docker info - docker build --pull -t "$OKE_REGISTRY_IMAGE" . - docker tag "$OKE_REGISTRY_IMAGE" "$OKE_REGISTRY_NEW_IMAGE" - docker push "$OKE_REGISTRY_NEW_IMAGE" only: - master docker-build: # Official docker image. image: docker:latest stage: build services: - docker:19.03.0-dind before_script: - docker login -u "$OKE_REGISTRY_USER" -p "$OKE_REGISTRY_PASSWORD" $OKE_REGISTRY script: - docker info - docker build --pull -t "$OKE_REGISTRY_IMAGE" . - docker tag "$OKE_REGISTRY_IMAGE" "$OKE_REGISTRY_NEW_IMAGE" - docker push "$OKE_REGISTRY_NEW_IMAGE" except: - master
- Dockerfile
FROM nginx VOLUME /usr/share/nginx/html
これらのファイルを作成し、保存すると、GitLab Auto DevOpsによりパイプラインがトリガーされます。これにより、レジストリ・イメージがプルされ、新しいイメージが作成され、名前「$OKE_REGISTRY_NEW_IMAGE」を使用してそのイメージがタグ付けされて、レジストリにプッシュされます。
- .gitlab-ci.yml
- レジストリ・ダッシュボードを更新すると、新しいイメージが表示されます。
セットアップとテストは以上です。これで、GitLab CI/CDパイプラインのデプロイとContainer Engine for Kubernetesおよびレジストリとの統合が完了しました。
まとめ
Container Engine for KubernetesとGitLab CI/CDの統合ワークフローとを組み合わせることで、本番対応の堅牢かつ拡張性の高いDevOpsプラットフォームを獲得できます。詳細については、「Container Engine for Kubernetesの概要」およびGitlabのWebサイトを参照してください。Container Engine for KubernetesでのGitlabの運用を体験したい場合は、Oracle Cloud Infrastructureのアカウントを取得していただければ、すぐにテストを開始できます。
※本記事は、Max Verun (Principal Product Manager)による”Using the GitLab CI/CD Pipelines Integrated Workflow To Build, Test, Deploy, and Monitor Your Code with Container Engine for Kubernetes and Registry“を翻訳したものです。