OpenShift 上の GitLab Runner Operator についてのガイド

2023年 6月 2日Tayler Geiger24 分 (読了時間の目安)

継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインは先進的なソフトウェア開発に欠かせないものとなり、開発者はコードの変更を迅速かつ効率的にビルド、テスト、デプロイできるようになりました。CI/CD パイプラインは、アプリケーションのビルドおよびデプロイのプロセスを自動化することで、コードの品質を向上させ、エラーを削減し、新しい機能やアプリケーションの市場投入時間を短縮するのに役立ちます。

GitLab Runner は、GitLab.com およびセルフホスト型 GitLab インスタンスで CI/CD ジョブを処理するアプリケーションです。GitLab.com は、サイトのユーザー間で共有される独自のホスト型 Runner を提供しますが、複数の異なるインストールタイプを使用してプロジェクトに専用プライベート Runner を設定することもできます。クラウドで独自のパイプライン・インフラストラクチャを管理することを好む企業または個人は、OpenShift で Red Hat 認定 Operator として利用できる GitLab Runner Operator を使用して、GitLab Runner をクラウドネイティブにすばやく簡単にインストールできます。

GitLab Runner Operator のシンプルさと機能性を紹介する手段として、Fedora Linux のエキサイティングな進展にも焦点を当て、GitLab Runner Operator を使用してカスタム Fedora Silverblue ベースイメージを構築するのも面白いのではないかと考えました。

Fedora Silverblue は、Fedora Linux の最先端のイミュータブルなディストリビューションです。先頃、ハイブリッドイメージおよびパッケージ管理システム rpm-ostree が、OCI コンテナからブートできるようになりました。これにより、ユーザーや企業は、Dockerfile と Containerfile の馴染みのあるワークフローを使用して、カスタマイズした独自のベースイメージを構築できます。

以下のチュートリアルでは、GitLab Runner Operator を使用して、Fedora Silverblue イメージ用の完全に自動化されたビルドシステムをセットアップします。

前提条件

このチュートリアルでは扱いませんが、事前に設定してインストールしておく必要があるリソースがいくつかあります。

OpenShift クラスタ
既存の Fedora Silverblue インストール (実際にカスタムイメージを使用したい場合)
GitLab.com アカウント

GitLab Runner Operator のインストールと設定

OpenShift クラスタのサイドバーで [Operators] 見出しを開き、 [OperatorHub] をクリックします。GitLab Runner Operator を検索し、[Certified] オプションをクリックします (コミュニティバージョンの Operator も利用できますが、このチュートリアルでは OpenShift 認定バージョンのみを使用します)。 [Install] をクリックする前に、Operator の説明の [Prerequisites] セクションに注意してください。GitLab Runner Operator を使用するには、まず cert-manager をインストールする必要があります。

oc apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.yaml

その後、 [Install] をクリックして GitLab Runner Operator をインストールします。

次の画面で、デフォルトのインストールオプションを変更するように求められます。特定の名前空間を指定する場合は、ここで指定してください。それ以外の場合は、デフォルトを使用して続行します。また、 [Update approval] は [Automatic] に設定したままにすることをお勧めします。これは Operator を使用する主要なメリットの 1 つだからです。

インストールが完了するまでしばらく待ってから、 [Installed Operators] 、[GitLab Runner Operator] の順に移動します。先ほどと同じ情報テキストが表示され、 [Provided APIs] の下に Runner インスタンスを作成できるリンクが表示されます。下にある情報テキストには Runner を GitLab リポジトリにリンクするための手順が記載されています。これに従っていきます。

Runner インスタンスの作成と登録

1.登録トークンシークレットの作成

まず、GitLab の登録トークンを使用してシークレットを作成します。これは、新しい Runner がリポジトリに登録するために使用します。GitLab.com またはプライベート GitLab インスタンスを開き、登録するリポジトリを開きます。[Settings]、[CI/CD] の順に移動します。 [Runners] というタイトルのセクションを展開し、 [Project Runners] セクションを探します。ここに、Runner インスタンスの登録に使用する登録トークンと URL があります。

GitLab.com を使用している場合は、 [Shared runners] セクションにも注意してください。これらは GitLab.com が提供するパブリック Runner です。独自のプライベート Runner を使用したいので、このプロジェクトでは共有 Runner を無効にします。

リポジトリの登録トークンを runner-registration-token フィールドに挿入して、シークレットを作成します。これは、Web コンソールまたはターミナルインタフェースを使用して実行できます。 gitlab-runner-secret.yml という名前のファイルを作成して、クラスタに追加しました。

apiVersion: v1
kind: Secret
metadata:
  name: gitlab-runner-secret
type: Opaque
stringData:
  runner-registration-token: YOUR_TOKEN_HERE

oc apply -f gitlab-runner-secret.yml

2.ConfigMap を使用した Runner の設定

Runner を作成する前に、いくつかのカスタマイズオプションを使用して ConfigMap を作成する必要もあります。GitLab Runner は通常、 config.toml ファイルを使用して設定できます。Kubernetes のコンテキストでは、 config.toml ファイルを含む ConfigMap を使用して、これらのカスタマイズを追加することができます。

OpenShift クラスタの環境でビルドコンテナを実行しているので、ビルドコンテナが昇格された特権なしで、非 root ユーザーとして実行されるようにする必要があります (注：特権ビルド環境が必要であるとわかっている場合は回避策がありますが、ここでは非 root セットアップを使用します)。以下では、Runner pod を非 root ユーザー 1000 として実行するように指定するシンプルな config.toml を示します。

[[runners]]
  name = "gitlab-runner"
  url = "https://gitlab.com"
  executor = "kubernetes"
  [runners.kubernetes]
    [runners.kubernetes.pod_security_context]
      run_as_non_root = true
      run_as_user = 1000

これを ConfigMap としてクラスタに追加するには、次のようにします。

oc create configmap my-runner-config --from-file=config.toml

3.Runner インスタンスの起動

これで、実際の Runner インスタンスを作成できるようになりました。Web コンソールで GitLab Runner Operator ページの [Create instance] をクリックするか、ターミナルを介して実行できます。いずれにせよ、カスタムリソース定義の記述に正しい GitLab URL、登録トークンシークレットの名前、ConfigMap の名前が含まれ、タグに「openshift」が含まれていることを確認します (最後の項目の「openshift」タグは、ジョブをクラスタに渡すために必要です)。以下は gitlab-runner.yml という名前の基本的な CRD で、上記の基準をすべて満たしています。

apiVersion: apps.gitlab.com/v1beta2
kind: Runner
metadata:
 name: gitlab-runner
spec:
 gitlabUrl: https://gitlab.com
 token: gitlab-runner-secret
 tags: openshift
 config: my-runner-config

クラスタにインストールします。

oc apply -f gitlab-runner.yml

これで、Web コンソールから、またはターミナルで oc get runner を使用して、新しい Runner のステータスを確認することができます。さらに、GitLab プロジェクトの CI/CD 設定を確認して、Runner がリポジトリに正しくリンクされていることも確認する必要があります。 [Assigned project runners] という見出しの下に、作成してインストールした CRD と同じ名前の Runner が表示されていることを確認します。

Runner を使用して Silverblue イメージをビルドする

1.GitLab CI/CD パイプラインジョブの定義

Runner がインストール、設定され、プロジェクトにリンクされたので、イメージビルドを定義する GitLab CI ファイルを記述できるようになりました。GitLab は、さまざまなプロジェクトタイプ向けの gitlab-ci.yml ファイル構造の例を多数提供しています。ここでは独自のファイルを記述し、 buildah を利用して Silverblue イメージをビルドします。

使用する gitlab-ci.yml は次のようになります。

stages:
  - build

buildah-build:
  stage: build
  tags:
    - openshift
  image: quay.io/buildah/stable
  variables:
    STORAGE_DRIVER: vfs
  script:
    - export HOME=/tmp
    - buildah login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
    - buildah build -t "$CI_REGISTRY_IMAGE:latest" .
    - buildah push "$CI_REGISTRY_IMAGE:latest"
    - buildah logout "$CI_REGISTRY"

このファイルには、注意すべき重要な要素が複数あります。

前述したとおり、GitLab Runner Operator がこのジョブを選択できるように少なくとも openshift タグを含める必要があります。
ビルドイメージとして、Quay.io にホストされている安定した公式の Buildah イメージを使用しています。
ストレージドライバーを vfs に設定しました。これは overlayFS での多重オーバーレイに関する問題を考慮に入れているためです。 vfs を使用することが今のところ最も簡単なソリューションです。
確実に書き込みができるよう、 $HOME を /tmp に変更します。OpenShift のほとんどのコンテナファイルシステムは読み取り専用であるためです。

最後の scriptセクションは、ビルドジョブが実行するコマンドのリストです。ここでは、GitLab CI の事前定義済み変数を利用して、GitLab コンテナレジストリにサインインし、イメージをビルドしてタグ付けし、最後にイメージをレジストリにプッシュしてからログアウトします。

2.カスタム Silverblue イメージの Containerfile の作成

gitlab-ci.yml をリポジトリに追加した後、ビルドする Containerfile も追加する必要があります。カスタム Fedora Silverblue イメージの作成では、 Universal Blue コミュニティで行われている素晴らしい取り組みを活用しました。このコミュニティは、さまざまなユースケースに対応するさまざまなバージョンの Silverblue の開発に取り組んでいます。また、Fedora Silverblue システム用のカスタマイズされたイミュータブルなベースイメージを作成することに関心があるユーザーやチームにとって最適なリソースとなっています。

毎日使っている OpenShift や Operator の各ツールの最新リリースをすべて含むベースイメージを作成できれば有益ではないかと考えました。毎日ビルドするように設定するので、最新の Fedora パッケージでベースイメージが更新されるだけでなく、OpenShift や Operator ツールの最新バージョンを常に使用できます。通常、最新バージョンへの更新には手動での操作が必要ですが、これも不要になります。

ARG FEDORA_MAJOR_VERSION=38

FROM quay.io/fedora-ostree-desktops/silverblue:${FEDORA_MAJOR_VERSION}
# Starting with Fedora 39, the new official location for these images is quay.io/fedora/fedora-silverblue
# See https://pagure.io/releng/issue/11047 for more information

# Install Openshift tools -- oc, opm, kubectl, operator-sdk, odo, helm, crc from official OpenShift sources
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/latest/opm-linux.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/operator-sdk/latest/operator-sdk-linux-x86_64.tar.gz | tar xvzf - --strip-components 2 -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/linux/oc.tar.gz | tar xvzf - -C /usr/bin
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/helm/latest/helm-linux-amd64 -o /usr/bin/helm && chmod +x /usr/bin/helm
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/odo/latest/odo-linux-amd64 -o /usr/bin/odo && chmod +x /usr/bin/odo
RUN curl -SL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/crc/latest/crc-linux-amd64.tar.xz | tar xfJ - --strip-components 1 -C /usr/bin

# Install awscli
RUN curl -SL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && unzip awscliv2.zip && ./aws/install --bin-dir /usr/bin --install-dir /usr/bin

# Install overrides and additions, remove lingering files
RUN rpm-ostree install podman-docker
RUN rm -rf aws && \
    rm -f awscliv2.zip && \
    rm -f /usr/bin/README.md && \
    rm -f /usr/bin/LICENSE

この Containerfile の内容を簡単にまとめてみます。

まず、ビルドする Fedora のバージョンを指定します。この場合は最新の安定バージョンであるバージョン 38 です。
次に、ビルドに使用するベースイメージを指定します。ここでは、 FEDORA_MAJOR_VERSION を置換した後の silverblue:38 です (これらのイメージの場所については、Containerfile のコメントを参照してください)。
最も大きなセクションでは、いくつかの curl コマンドを実行して、インストールするすべての OpenShift プログラムをダウンロードし、それらのバイナリを /usr/bin ディレクトリに配置します。
また、 awscli をインストールします。このコマンドでは .zip ファイルを展開し、インストールスクリプトを実行します。
最後に、 rpm-ostree を使用して、Fedora パッケージリポジトリから podman-docker をインストールします ( dockerの実行に慣れている人のために、基本的にあらゆる docker コマンドを podman のエイリアスに指定します)。その後、 awscli の展開で残っているいくつかのファイルを削除します。

前述のとおり、Silverblue のカスタマイズに関するその他のアイデアについては、 Universal Blue のコミュニティをご覧ください。私はこのワークフローを学ぶ際にこのコミュニティの取り組みを大いに活用しました。そして彼らはすでに、Silverblue の起動可能な OCI 機能を使った多数の新しい画期的なアプリケーションに取り組んでいます。

3.パイプラインジョブの使用と監視

buildah が Containerfile 引数として現在の作業ディレクトリを使用するように gitlab-ci.yml で指定しているため、この Containerfile (またはビルドする Containerfile や Dockerfile) をプロジェクトリポジトリのルートに追加する必要があります。このリポジトリですべての変更をコミットした方法によっては、パイプラインジョブの失敗に関する通知をすでに受け取っているかもしれません。または、これらすべての変更をこれから一度にコミットするのであれば、ビルドジョブの実行の最初の試行が開始されます。ビルドのログを確認するには、GitLab.com プロジェクトページの [CI/CD] 見出しに移動し、 [Pipelines] または [Jobs] をクリックして、 buildah-build という名前のジョブの出力が表示されるまでクリックしていきます。

すべてが適切に設定されていれば、作成した gitlab-ci.yml と Containerfile の各手順を記述するログが表示され、終了時には最後に「Job succeeded」と表示されます。ジョブが成功すると、完成したコンテナもプロジェクトレジストリで確認できます。左側のナビゲーションバーで [Packages and registries] 、 [Container Registry] の順にクリックします。「latest」という 1 つのタグが付けられた、プロジェクトに基づく名前のイメージが 1 つあるはずです。このイメージは、 registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME} に配置されます。

作成したジョブは main ブランチにコミットするごとに実行されますが、この動作は gitlab-ci.yml ファイルでカスタマイズできます。定期的にビルドするようスケジュールする場合は、リポジトリページの CI/CD 設定の [Schedule] セクションでスケジュールできます。 [New schedule] をクリックして、パイプラインのタイミングと頻度を設定します。GitLab.com パイプラインのスケジューリングの詳細については、こちらをご覧ください。カスタム Silverblue イメージを作成するなら、公式イメージのビルド頻度に合わせて毎日 1 回以上ビルドするとよいでしょう。

カスタムイメージの使用

このイメージを実際に Silverblue のブート可能なベースとして使用するには、まず公式イメージから Fedora Silverblue をインストールする必要があります (既存のインストールがない場合)。インストールが完了した後にログインすると、インストールをカスタムイメージにリベースできます。

注意すべき点 として、OCI イメージからのブートはまだ実験的な機能であるため、個人用マシンまたは実稼働マシンでこれを使用する場合は、自分自身の最善の判断と裁量に従ってください。ただし、Silverblue は破損に対する回復力を持つように構築されているため、カスタムイメージが期待どおりに機能しない場合でも、元のベースイメージにロールバックできるはずです。この元のベースを削除しないようにするために、 sudo ostree admin pin 0 を実行して現在のイメージを固定します。これにより、以降の更新で参照が失われることがなくなります。Silverblue は通常、現在と以前のイメージの参照のみを保持するためです。実際にカスタムイメージにリベースするには、次のコマンドを実行します。

rpm-ostree rebase ostree-unverified-registry:registry.gitlab.com/{YOUR_USERNAME}/{YOUR_REPOSITORY_NAME}:latest

次に再起動します。

再起動後、 rpm-ostree status の出力を見れば、カスタムイメージが実行されていることを確認できます。現在のデプロイメント (識別のため左側に丸印が付きます) に、カスタムイメージの ostree-unverified-registry URI が表示されていることを確認してください。また、 oc、 operator-sdk、 helm など、追加した OpenShift ツールをターミナルで実行してみることもできます。

rpm-ostree status の出力に、古いベース参照を持つ固定されたデプロイメントがあることも確認します。ロールバックするには、 rpm-ostree rollback を実行して再起動します。Fedora Silverblue 管理の詳細については、このドキュメントを参照してください。

結果

すべてが何の問題もなく進んだ場合、OpenShift クラスタで実行され、定期的に新しいカスタム Silverblue イメージを作成するセルフホスト型の CI/CD パイプラインが完成しました。Runner は、ビルドジョブタグを再設定したり、同時に処理できるジョブを増やすためにより多くの Runner を作成したりする必要がない限り、手動での介入を必要としません。ビルドは、 main ブランチに新しいコードをコミットしたときと、スケジュールした間隔で開始されます。カスタムイメージを Silverblue インストールで実行している場合、 rpm-ostree update を実行するだけで毎日の更新を取得できます。

このチュートリアルの例では、GitLab Runner Operator と GitLab CI/CD システムの機能を簡単に説明しています。両方とも、より高度な CI/CD のニーズに対応することができます。認定 GitLab Runner Operator を OpenShift で実行することで、Runner 自体の手動セットアップと保守作業の多くが不要になり、時間と労力が解放され、ビルドの実際の内容と設定に当てることができます。

このチュートリアルで使用したすべてのテキストファイルを格納した参照リポジトリをこちらに作成しました。また、以下の参考情報のリストもご覧ください。

執筆者紹介

Tayler Geiger

さらに調べる

チャンネル別に見る

すべてのチャンネルを見る