被引用回数
レビュー環境
レビュアー環境は1時間後に自動的にアンインストールされます。レビュアー環境をより長く維持する必要がある場合、環境ページで環境を固定できます。しかし、Cleanup
ステージでジョブを手動でトリガーしてください。これにより、クラスターが他のマージリクエストのレビューアプリを実行するのに十分なリソースを確保できます。
詳細は環境ドキュメントをご覧ください。
OpenShift CI クラスター
Googleクラウド上のOpenShiftクラスターを管理し、QAスイートなどの受け入れテストに使用します。
これらのクラスターに接続するためのkubeconfigファイルは1Password cloud-native vaultに保存されています。ocp-ci
を検索してください。
このプロジェクトでは、CIクラスターはscripts/create_openshift_cluster.sh
。KUBECONFIG_OCP_4_7
という CI 変数は、スクリプトが kubeadmin としてクラスターに接続できるようにします。4_7
は、対象となる OpenShift クラスターのメジャーバージョンとマイナーバージョンを指します。
このスクリプトの使用方法については、OpenShift クラスターセットアップドキュメントを参照してください。
“公開 “クラスターと “開発 “クラスター
このプロジェクトでは、2組の OpenShift CI クラスターをメンテナーしています:
-
public
CIクラスターは、gitlab.com
の日常的なCIパイプラインを担当します。 -
dev
CI クラスターはdev.gitlab.org
でタグ付けと公式リリースの作成を担当しています。
すべてのクラスターは、そのセットに関係なく、OpenShiftクラスター設定ドキュメントとスクリプトを使用して作成されます。公開にデプロイされた OpenShift バージョンごとに、同じバージョンが dev にデプロイされた対応するクラスターがあります。両方のクラスターはcloud-native
GCP プロジェクトにデプロイされ、DNS ベースドメインにk8s-ft.win
を使用します。
OpenShiftクラスターのスケーリング
OpenShiftクラスタはmachineset
リソースをプールするためにsを machineset
使用します。machineset
デフォルトのデプロイには4つの machineset
s があり、そのうち2つが利用されています。このアプローチを維持し、2つのアクティブなmachineset
s を2ノードにスケールします。
$ export KUBECONFIG=~/work/ocp/kubeconfig_4_8
$ oc get machinesets -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
ocp-ci-4717-abcde-worker-a 1 1 1 1 59d
ocp-ci-4717-abcde-worker-b 1 1 1 1 59d
ocp-ci-4717-abcde-worker-c 0 0 59d
ocp-ci-4717-abcde-worker-f 0 0 59d
スケールダウン中にワークロードを処理するための一時的なキャパシティを作成します:
$ oc scale --replicas=1 machineset ocp-ci-4717-abcde-worker-c -n openshift-machine-api
machineset.machine.openshift.io/ocp-ci-4717-abcde-worker-c scaled
$ oc get machinesets -n openshift-machine-api
NAME DESIRED CURRENT READY AVAILABLE AGE
ocp-ci-4717-abcde-worker-a 1 1 1 1 59d
ocp-ci-4717-abcde-worker-b 1 1 1 1 59d
ocp-ci-4717-abcde-worker-c 1 1 59d
ocp-ci-4717-abcde-worker-f 0 0 59d
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ocp-ci-4717-abcde-master-0.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-1.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-2.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-a-wz8ts.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-b-shnf4.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-c-5gq6r.c.cloud-native-123456.internal NotReady worker 15s v1.20.0+2817867
machineset
のひとつをスケールダウンします:
oc scale --replicas=0 machineset ocp-ci-4717-abcde-worker-a -n openshift-machine-api
スケールダウンが完了するまで待ちます:
$ oc scale --replicas=2 machineset ocp-ci-4717-abcde-worker-a -n openshift-machine-api
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ocp-ci-4717-abcde-master-0.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-1.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-2.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-b-shnf4.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-c-5gq6r.c.cloud-native-123456.internal Ready worker 7m18s v1.20.0+2817867
必要なノード数までスケールアップします:
$ oc scale --replicas=2 machineset ocp-ci-4717-abcde-worker-a -n openshift-machine-api
machineset.machine.openshift.io/ocp-ci-4717-abcde-worker-a scaled
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ocp-ci-4717-abcde-master-0.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-1.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-master-2.c.cloud-native-123456.internal Ready master 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-a-n7qvs.c.cloud-native-123456.internal Ready worker 72s v1.20.0+2817867
ocp-ci-4717-abcde-worker-a-sqn77.c.cloud-native-123456.internal Ready worker 73s v1.20.0+2817867
ocp-ci-4717-abcde-worker-b-shnf4.c.cloud-native-123456.internal Ready worker 59d v1.20.0+2817867
ocp-ci-4717-abcde-worker-c-5gq6r.c.cloud-native-123456.internal Ready worker 11m v1.20.0+2817867
外部DNS
external-dnsは、ci/scripts/install_external_dns.shを使用してBitnami Helm Chartを使用してインストールされています。このツールは、外部に面した LoadBalancers として作成された NGINX Ingress コントローラサービスの DNS エントリを作成し、QA ジョブがテスト用のインスタンスに到達できるようにします。
設定
ジョブのタイムアウト
設定するには、deploy/chart/values.yaml
のenv
の値を更新します。
Kubernetes CIクラスタ
Google CloudのKubernetesクラスタをGKEを使って管理しています。これらのクラスターは、OpenShift CI クラスターで実行されるのと同じ受け入れテストを実行するために使用されます。
クラスターはcharts/gitlab
のgke_bootstrap_script.sh スクリプトを使って作成します。
$ CLUSTER_NAME='gitlab-operator' \
PROJECT='cloud-native-182609' \
REGION='europe-west3' \
ZONE_EXTENSION='a' \
USE_STATIC_IP='false' \
EXTRA_CREATE_ARGS='' \
./scripts/gke_bootstrap_script.sh up
demo/.kube/config
が生成され、kubectl
またはk9s
を使ってクラスターに接続し、開発者に提供することができます。
次に、新しいクラウドDNSレコードセットを作成してクラスターのエンドポイントIPアドレスに接続します。
$ ENDPOINT="$(gcloud container clusters describe gitlab-operator --zone europe-west3-a --format='value(endpoint)')"
$ gcloud dns record-sets create gitlab-operator.k8s-ft.win. \
--rrdatas=$ENDPOINT --type A --ttl 60 --zone k8s-ftw
クラスターを作成してDNSで接続したら、./scripts/install_certmanager
スクリプトを実行してLetsencrypt TLS証明書をセットアップします。
$ KUBECONFIG=demo/.kube/config \
CLUSTER_NAME=gitlab-operator \
BASE_DOMAIN=k8s-ft.win \
GCP_PROJECT_ID=cloud-native-182609 \
./scripts/install_certmanager.sh 'kubernetes'
クラスターのドメインに対してワイルドカード証明書がイシューされると、クラスターはテストを実行できるようになります。
CIクラスターの場合、Googleクラウドの認証ドキュメントの手順に従って、Googleクラウドのサービスアカウントを作成します。これにより、このプロジェクトのCI変数KUBECONFIG_GKE
とGOOGLE_APPLICATION_CREDENTIALS
を生成することができます。scripts/create_gcloud_sa_kubeconfig.shを参照してください。これらの kubeconfigconfig ファイルは 1Password cloud-native vault に保存されます。保管庫を検索して、gitlab-operator
.
Kubernetesクラスターのスケーリング
GKE クラスターにワーカーノードを追加または削除するには gcloud CLI を使用します。Google CloudのWeb UIを使用することもできます。
たとえば、gitlab-operator
CI クラスターを 4 ノードにスケールします:
$ gcloud container clusters resize \
gitlab-operator --num-nodes 4
QAパイプライン
デフォルトでは、QA パイプラインには Smoke スイート (基本的な機能が動作していることを迅速に確認するための、高速なエンドツーエンドの機能テストの小さなサブセット) が含まれます。追加のテストが必要な場合は、qa_<cluster>_full_suite_manual_trigger
ジョブを使用して、特定のクラスター用のエンドツーエンドテストのフルスイートで手動 QA パイプラインをトリガーすることができます。
テストの失敗をデバッグするには、QA の失敗を調査するガイドに従ってください。