GitLab + GitLab Runner(Docker) の構築７

GitLab Runner(Docker)の登録

前回の記事で、GitLab Runner のインストールが終わりましたので、いよいよ Shared Runner として Docker Executor の登録を行います。

GitLab に root または管理者ユーザとしてログインして「管理エリア」から「CI/CD」「Runner」を選択します。

GitLab 画面からの操作

 

「新規インスタンスRunner」ボタンを押して、次の画面で Runner を登録するコマンドを生成させます。

設定値

プラットフォーム Linux
タグ shared
タグのないジョブの実行 チェック
Runnerの説明 Shared Runner
.gitlab-ci.yml でタグを指定すると、そのタグが設定された Runner が実行されます。今回はタグのないジョブの実行を許可しているので、タグを設定していなくても、この Runner が実行されることになります。ここにチェックを入れない場合は、必ず .gitlab-ci.yml でタグとして shared を指定する必要があります。
「ランナー作成」ボタンを押すと、GitLab Runner を登録するためのコマンドが表示されます。
ステップ１に表示されたコマンドをコピー（右にあるコピーボタン）します。
GitLab Runner gitlab-runner register で登録
GitLab Runner にログインしてコピーしたコマンドを sudo で実行します。
sudo gitlab-runner register --url https://xxx.xxx.xxx --token xxxxxxxxxxxxxxxxxxxxxx

のようになるはずです。

途中、入力を促されます。URLはそのままRETURNでよいですが、Executor は docker を指定します。default Docker image は alpine:latest を指定しました。ruby:2.7 でもかまいません。実際に動かす際は .gitlab-ci.yml で指定することになります。

Enter the GitLab instance URL そのままRETURN
Enter a name for the runner. This is stored only in the local config.toml そのままRETURN
Enter an executor: … docker
Enter default Docker image … alpine:latest
GitLab Runner 登録確認

先程の GitLab の画面に戻って「View runners」ボタンを押下します。

オンラインになっていれば、正しく設定されています。

動作確認

テスト用にプロジェクトを作成して、そのプロジェクトに .gitlab-ci.yml を作成して、Pythonの簡単なプログラム hello.py を作成しました。

.gitlab-ci.yml

image: python:latest

stages:
  - test
  
job_1:
  stage: test
  script:
    - python hello.py

Dockerイメージは python:latest を使用します。

stage としては test を定義します。

job_1 を test stage で、python hello.py を実行するように定義します。

hell.py

print("Hello, World!")

Git push されたタイミングで .gitlab-ci.yml の内容がパイプラインとして実行されます。実行結果は「パイプライン」で確認できます。

パイプラインの中を表示（「成功」リンクをクリック）すると、

job_1 が成功していいます。job_1 の中を表示（「job_1」リンクをクリック）すると、

実行されたジョブのログが表示されます。ログの最後のほうに、python hello.py が実行されて、「Hello, World!」が表示されて、job succeeded となっていることがわかります。

以上で、GitLab Runner を Docker Executor で動かすことができました。.gitlab-ci.yml の書き方は公式サイトや、以前の記事で紹介した『GitLab実践ガイド 第２版  （インプレス）』を参考にしてください。私自身も勉強がさらに必要です。

AWS Kubernetes との連携

GitLab 「操作」にある「Kubernetes クラスター」の機能を使って Kubernetes と連携が可能です。これは『GitLab実践ガイド 第２版  （インプレス）』で紹介されており、GitLab.com と AWS を使って実際に動かすことができることを前回紹介しました。

ローカルの環境でこれを動かすためには、さらに様々なハードルがあります。今回の一連の記事では詳しく言及しません。ただ、私が躓いたハードルだけ紹介しておきます。

ちなみに AWS の Kubernetes との連携を試される場合はAWSから請求がきます。無料で使えるものではありません。月当たり数千円は覚悟しておいてください。

buildah がエラーとなって実行できない

Docker コンテナで chroot がうまくいかないためか、セキュリティがらみのエラーが発生して package を作成できません。GitLab.com では問題なく動作するので、Executor の違いや設定の違いによるものだと思われます。セキュリティ面でよくないので推奨できないのですが、GitLab Runner の設定ファイル /etc/gitlab-runner/config.toml の設定で [runners.docker] に、

security_opt = ["seccomp:unconfined","apparmor:unconfined"]

を追記することで、無理矢理動かすことができます。正しい対処法が今もわかっていません。もし正しい対処法があれば教えてください。

kubernetes への deply に失敗する

/dev/fuse がない云々のエラーが発生します。上記、[runners.docker] の設定に、

devices = ["/dev/fuse"]

を追記することで、回避することができます。

リバースプロキシの設定

これは、おま環の問題となります。Kubernetes とのやり取りに wss を使っていることに起因します。単に 443 の / をリダイレクトするだけではうまく連携できないのです。/-/kubernetes-agent/ をリダイレクトするとともに wss 特有の設定が必要です。

server {
        listen 443;
        server_name gitlab.xxx.xxx.xxx;
        ssl on;
        ssl_certificate /etc/nginx/cert/gitlab/gitlab.xxx.xxx.xxx.crt;
        ssl_certificate_key /etc/nginx/cert/gitlab/gitlab.xxx.xxx.xxx.key;

        location / {
                proxy_pass https://xxx.xxx.xxx.xxx;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_redirect http:// https://;
        }
        location /-/kubernetes-agent/ {
                proxy_pass https://xxx.xxx.xxx.xxx;
                proxy_set_header Host $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;

                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }

}

wss 特有な設定とは

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;

です。

まとめ

以上で一連の「GitLab + GitLab Runner(Docker) の構築」の記事を終了します。

実際は、お金を払ってクラウドの GitLab や GitHub を使うほうが苦労がなくてよいでしょうが、GitHub に相当する環境を、個人や組織で実現するには GitLab をオンプレミスで運用できるのは魅力的な選択肢です。

私も、今回、構築した環境を有効活用していけるようにしていきたいと考えています。何か新しい事柄や問題があったら、ここで記事にしたいと思います。

タイトルとURLをコピーしました