Skip to content

CI

Jump to bottom
Takuya Murakami edited this page Aug 17, 2024 · 28 revisions

CI のメモ

リンク

基本

  • Gitlab CI を使っている
  • .gitlab-ci.yml が起点
  • ここから .gitlab-ci/ にある yml ファイルを include している
    • build.yml
    • lint.yml
    • terraform.yml
    • packet.yml
    • vagrant.yml
    • molecule.yml
    • テストの主体は packet である（バリエーションが多い)
  • ステージは以下の４つが定義されている。前の stage の job が全部完了したら次の stage にうつる
    • build: pipeline実行に必要な Docker Container を作る stage
    • test: lint とかいろいろ
    • deploy-part1
    • deploy-extended
  • Job は継承関係を設定できる。'extends' で親 Job を指定する
  • Runner は３種類ある (詳細は Ci-setup を参照)
    • packet
      • E2Eジョブ(時間かかるもの)を実行する Runner。Equinix Metal 上の VM で実行される。
    • Light
      • 短い Job を実行する。Euinix Metal で Pod 上で実行される
    • Auto scaling runners

テンプレート (基底 Job)

'.' で始まる Job は隠し Job であり、そのまま実行されない。親 Job (テンプレート) として使う

  • .job
    • 一番親？っぽい Job
    • コンテナを使う。コンテナイメージは "$CI_REGISTRY_IMAGE/pipeline:${CI_PIPELINE_ID}-${CI_COMMIT_SHORT_SHA}"
    • このコンテナは build フェーズで作っている
  • .job-moderated
    • .job を継承。依存関係 (needs) を追加しただけ
  • .testcases
    • テストケースを実行する親 Job
    • .job-moderated を継承
    • tests/scripts にある rebase.sh, testcases_prepare.sh, testcases_run.sh, testcases_cleanup.sh を実行する

共通 Job

  • ci-not-authorized
    • CI が許可されてるかどうかを最初に確認する Job。build フェーズで実行される
    • PRラベルに必要なものがついているか(ok-to-test/lgtm/approved)、または schedule/trigger かどうか、master ブランチかどうか、などをチェックする

build フェーズ

.gitlab-ci/build.yml

  • .build-container
    • コンテナをビルドする基底 job。build フェーズで実行される
    • kaniko executor でコンテナをビルドするらしい。
  • pipeline-image
    • PIPELINE_IMAGE をビルドする　Job
    • Dockerfile は pipeline.Dockerfile である
      • Ubuntu jammy がベース
      • python3, docker-ce などをインストールする
      • pip で必要なパッケージをインストール
      • Vagrant をインストールする

Testcases

実行は tests/scripts/testcases_run.sh がメイン処理である。

最初に CI platform の生成を行う。これは make で行う。Makefile は tests/Makefile にある

  • create-packet
    • Ansible で tests/cloud_playbooks/create-packet.yml playbook を実行する
    • このとき、files/{ジョブ名}.yml ファイルの内容が環境変数として取り込まれる (-e オプション)
  • create-tf
    • tests/scripts/create-tf.sh を実行する
  • create-vagrant
    • vagrant up を実行する
    • このとき、test/files/{ジョブ名}.rb の内容が設定ファイルとして読み込まれる

テストは、以下の内容を順次行う。

  • cluster.yml を実行し、クラスタデプロイを実行する
  • UPGRADE_TEST が 'basic', 'graceful' の場合、upgrade 用の playbook を実行する
    • ただし前バージョンからのアップグレードではない
  • RECOVER_CONTROL_PLANE_TEST=true の場合、reset.yml, recover-control-play.yml を実行する
  • Job名に 'collection' が含まれる場合、ansible-galaxy の collection build, collection install を実行する
  • tests/testcases ディレクトリにある以下の test case を実行する
    • 010_check-apiserver.yml
    • 015_check_nodes-ready.yml
    • 020_check-pods.running.yml
    • 030_check-network.yml
    • 040_check-network-adv.yml
    • 100_check-k8s-conformance.yml
  • IDEMPOT_CHECK=true の場合、冪等性テストを行う
  • REMOVE_NODE_CHECK=true の場合、remove-node.yml をテストする
  • RESET_CHECK=true の場合、reset.yml をテストする

packet

.gitlab-ci/packet.yml

以下の隠し Job がある

  • .packet
    • packet.yml の全 Job の基底Job
    • .testscases を継承
    • CI_PLATFORM は当然 packet
  • .packet_pr
    • PR発行時に実行される基底Job
    • deploy-part1 stage で実行する
  • .packet_pr_short
  • .packet_pr_manual
  • .packet_pr_extended
  • .packet_periodic
    • PERIODIC_CI_ENABLED=true の場合にのみ実行される

各 Job を ansible-playbook で実行する際、上述の通り files/{ジョブ名}.yml の内容が -e で取り込まれる

環境のバリエーションは一番多いように見える。

  • OS: ubuntu20, ubuntu22, ubuntu24, almalinux8, debian11, debian12, rockylinux8, rockylinux9, amazon linux 2, opensuse, fedora37, fedora38
  • container runtime: (containerd), crio, docker
  • network plugin: calico, kube-ovn, macvlan, cilium, flannel, ...

もちろん、全部の環境の組み合わせではない

terraform

elastx のテスト用っぽい

vagrant

Vagrant を使う。バリエーションは少ない。Ubuntu20 と fedora37 だけ。

molecule

Molecule は Ansible Role のテストツール コンテナランタイム周りをテストしている

  • no_container_engine
  • docker
  • containerd
  • cri-o
  • gvisor
  • youki
Clone this wiki locally