仮想化通信

日本仮想化技術株式会社の公式エンジニアブログ

k3sをGitLabのCI/CDで使う

GitLabにはCI/CDを実行する機能が標準で搭載されています。 あとはRunnerというものを追加してGitLabと紐づけすることで、CI/CDを実現することができます。

最近のGitLabはKubernetesと連携する機能も標準で搭載されており、関連付けしたKubernetes上でRunnerを実行できます。

GitLabとKubernetesクラスターの関連付けは次のドキュメントに書かれている方法で行います。「Creating the cluster」の方法はGoogle Kubernetes Engineを使う方法で、「Add existing Kubernetes cluster」の方がオンプレのKubernetesを使う方法です。

オンプレのKubernetesは最低限のKubertnetesの構成で構いません。例えばk3sも使うことができます。

k3s.io

今回はk3sでKubernetesをセットアップし、そのKubernetesをGitLab CI/CDで使ってみたいと思います。 なお、GitLabのインストールや初期設定はすんでいる前提での解説になっています。

k3sノードのセットアップ

まず、十分なスペックを持つx86_64なLinux環境を用意します。Linuxディストリビューションは特に問いません。好きなものを使ってください。 OSをセットアップ後、システムをアップデートしておきます。

このあと、k3sの導入に移るわけですが、k3sの使い方は公式サイトに書かれている通りです。ただし、一点だけ注意事項があります。 k3sを使ったKubernetes環境のデプロイは次のコマンド二つでできるのですが、

# curl -sfL https://get.k3s.io | sh -
# k3s kubectl get node

Kubeconfigのserver行をlocalhostからBind IPかFQDNアドレスに修正する必要があります(もちろんですが、FQDNアドレスでそのノードにアクセスする環境は名前引きができるようにする必要があります)。

k3sでは/etc/rancher/k3s/k3s.yamlにKubeconfigが保存されるので、このファイルを開いて次のように修正してください。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: hogehogehugahuga
(略)
    server: https://localhost:6443    #このように書かれているので、この行を
    server: https://esxinode3.maas:6443   #次のようにノードのIPアドレスかFQDNアドレスに書き換える
  name: default
contexts:
(略)

このファイルを編集後にcat /etc/rancher/k3s/k3s.yaml > ~/.kube/configコマンドで書き込んでください。 Kubernetesのセットアップについてはここで終了です。

GitLabにKubernetesを追加する

このあと、今回の例では「Add existing Kubernetes cluster」の方法でクラスターを追加するわけですが、この手順だとプロジェクトの「Operations > Kubernetes page」を開いて設定するように書かれています。

GitLabの管理者アカウントでログインしてAdmin Areaを開き、サイドメニューのKubernetesを開いてこの画面からKubernetesクラスターを追加すると、すべてのユーザーのプロジェクトで利用できるKubernetesクラスターとして追加できます。

f:id:virtualtech:20190912151334p:plain
GitLab Admin Area

f:id:virtualtech:20190912151411p:plain
Add K8s

追加に必要な入力項目は「Add existing Kubernetes cluster」と同じです。API URLとかCA certificateとかトークンキーとかをコマンドを実行して調べたものを入力していくだけです。思ったより簡単ですね。

入力後、次のような画面に切り替わるので、Applicationsの項目の「Helm Tiller」をインストールしたあと、「GitLab Runner」をインストールしてください。ここでインストールしたGitLab RunnerがShared Runnerになります。

f:id:virtualtech:20190912151619p:plain
Edit K8s Cluster

このような感じで、Runnerが登録されます。

f:id:virtualtech:20190912151723p:plain
GitLab Runner

GitLabのOutbound requestsの処理方法を変更

ローカルIPアドレスを持つノードをGitLabで使うには設定変更が必要です。

taikii.net

先に挙げたブログにも書かれているように、設定を変更します。esxinode3.maasというノードでk3sによるKubernetesコンテナーが動いているのを例とします。「Save changes」ボタンを押して設定を適用してください。

f:id:virtualtech:20190912152311p:plain

ここまでできたらGitLabのCI/CD機能でKubernetesを使うための設定は終わりです。あとはこちらのドキュメントのようにGitリポジトリー上に表記ルールに従った.gitlab-ci.ymlを用意すれば、CIおよびCDができるようになります。

タグはRunnerに設定されていたタグ(本例ではkubernetes)を指定します。

以下はJavaのソースをApache Antでビルドして実行する際の.gitlab-ci.ymlの例です。

stages:
  - buildrun

build-run:
  image: centos:7
  stage: buildrun
  script:
    - yum install -y java-1.8.0-openjdk-devel.x86_64 ant git
    - ant
  tags:
    - kubernetes

以下はパイプラインの画面です。.gitlab-ci.ymlにジョブを書けば書くほど、複雑なマップがこちらに表示されます。 あとは.gitlab-ci.ymlに色々書いていけば、今回省略した「CD」の方も自動化できます。

f:id:virtualtech:20190912153115p:plain
パイプライン

以下は実行結果のログです。処理が正常に行われれば次のステージの処理に移ります。失敗するとそこで止まります。

f:id:virtualtech:20190912153149p:plain
実行結果

今回の例は一つのステージしか定義していませんので、antコマンドが正常に通ったら緑色のチェックマークがコミットにつくでしょう。

f:id:virtualtech:20190912153726p:plain
pass

このように、GitLabでは簡単にKubernetesを使うことができます。 また、k3sでデプロイしたKubernetesクラスターであってもGitLabで使えることがわかりました。

k3sの使い道がまた増えたので、良かったと思います。