ニフクラがDevOpsサービスのBeta版を始めたと聞いたので触ってみることにしました。 公式サイトはこちらです（これを書いた当初はBeta版サービスとして提供されていましたが、現在は正式版として利用可能のようです）
このサービスはAll-in-one DevOpsなGitLab Serverをニフクラ上に展開します。GitLab自体はドキュメントのセットアップ手順にしたがって動かすことができますが、ニフクラがDevOpsサービスはボタンポチでいくつかの設定をするだけでセットアップ完了なので、「DevOps」を手軽に使い始められます。
ニフクラのDevOpsサービスをデプロイする
DevOpsサービスを展開すると2つのサーバーが実行され、すぐ使えるGitLab Serverが構築されます。基本設定で名前、ゾーン、サーバータイプ、ファイアウォール、ディスクサイズ、GitLabのrootユーザーのパスワードを設定します。設定はこれだけで、あとは数分で自動的に環境が作られます。
Betaサービス時点では無料で利用できますが、正式リリース時はサーバータイプとストレージサイズなどで価格が変わっていくと思われます。なお、DevOpsサーバーにはログインできません。
ファイアウォールの設定は事前に行っておく必要があります。今回は、次のような設定をしました。自分のネットワークから443ポートへのアクセスを許可します。現時点ではこれだけでOKです。
構築したDevOpsサーバーの基本情報を開いてみます。ここにはGitLab URLとレジストリURLが表示されています。GitLab URLの方にアクセスします。
するとGitLabのログイン画面が表示されます。デプロイ時に設定したパスワードを入力して、ログインしてください。
ニフクラでDevOpsを体験する
GitLabには無料版のGitLab CEおよびEEエディションでCI/CD機能が標準で提供されています。もちろんニフクラでデプロイしたGitLabも同様です。
GitLabでCI/CDを実際に動かすにはGitLab Runnerという、CIやCDを実行するための環境を用意する必要があります。GitLab Runnerは色々なモードで実行可能ですが、コンテナーの中でCI/CD処理を実行するDocker executerやKubernetes executerが使い回しに最適なモードです。
今回はDocker Executerとして実行してみようと思います。
ニフクラでGitLab Runner環境を用意する
DevOps環境を構築したので、GitLab Runner環境をニフクラで用意してみましょう。これにはニフクラのコンピューティングサービスを利用して、サーバーを作成します（課金が発生します）。
SSHキーの用意
サーバーを作成するにはまずSSHキーを用意する必要があります。SSHの鍵は既存の鍵を使うか、ニフクラで鍵を作成するかどちらか選んで作成します。作り方は特に難しくないためここでは省略します。
作成したSSHキーでログインして、DockerとRunner用のパッケージのインストールを行います。今回は行いませんが、Ansdibleで環境をセットアップできると環境構築の効率化ができるかもしれません。
サーバーファイアウォールの設定
次にファイアウォールの設定です。ここも複雑な設定はないため、詳細な手順は省略しますが、サーバーに作業環境からアクセスできるようにINルールとしてSSHとPingができるように、TCP/22番ポートとICMPを「接続しているIPアドレス」宛に対して許可しておくといいと思います。今回の用途ではそれ以外に利用しないので、その他のポートは開けないで構いません。OUTルールについては「プロトコル:ANY,接続先種別:ANY」を設定しました。
サーバー作成と注意点
次にサーバーを追加します。今回はDockerコンテナーを動かすためのサーバーを用意するので、CPUは2つ以上、メモリーは2GB以上、ストレージは40GB以上のマシンを作成します（あまり低スペックな環境にすると、正常に動かないと思います）。
まずはOSイメージを作成します。GitLabの関連パッケージが提供されている、サポートされているOSであればなんでも構いませんが、今回は「Ubuntu Server 20.04 LTS」をクリックします。
次の画面ではゾーンとタイプを選択します。ゾーンはサーバーを動かすリージョンを選択するものです。タイプはサーバーのスペックを示すものです。サーバースペック一覧から適切なタイプを選択します。性能差を示すレポートをもとにタイプを選択すれば良いでしょう。このレポートから、CPU性能とネットワーク性能に差があることがわかります。今回は「c-medium」を選択します。
次にサーバー名や料金プラン、SSHキー、ファイアウォールの設定を行います。グローバルIPアドレスも必要なので、「自動割り当て」で追加しておきます。次の画面でこれまでの内容を確認して「作成」ボタンを押すと、ニフクラ上にサーバーが作成されます。
DevOpsサーバーファイアウォールの設定
ここまでできたら、作成したサーバーがGitLabにアクセスできるようにします。 RunnerサーバーのIPアドレスを確認して、それをDevOpsサービスのファイアウォールに追加します。必要なのはTCP/443ポートへのアクセスだけですので、次のような感じで許可します。
GitLab Runnerをセットアップ
ニフクラで動くUbuntu Serverはデフォルトユーザーは「root」になっています。rootユーザーでログインします。
$ ssh -i ~/.ssh/mykey.pem root@[グローバルIPアドレス]
ログインできたらまず、Ubuntuのアップデートを行い、Dockerをインストールします（dbus-user-sessionはdocker loginをうまく動かすために追加しています）。rootユーザーなので、sudoは必要ありません。
# apt update && apt upgrade && apt install docker.io dbus-user-session
なお、次のような画面が現れた場合は「Keep the local version cuerrently installed」を選びます。
また次のようなメッセージが出た場合はNを入力してEnterキーを実行してください。何度か表示されますが、これはニフクラのUbuntuベースイメージが古いためです。最近のUbuntuではここまで確認されることはありません。
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** resolved.conf (Y/I/N/O/D/Z) [default=N] ?
終わったら、一旦再起動しましょう。
# reboot
再起動後、次を見ながらリポジトリーの追加とパッケージのインストールを行います。
現時点では次のような方法でインストール可能です。
Add the official GitLab repository: # curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash Install the latest version of GitLab Runner: # apt install gitlab-runner Or Install a specific version of GitLab Runner: # apt-cache madison gitlab-runner # apt install gitlab-runner=10.0.0
インストール後、Nodeとして使うためのセットアップを行います。GitLabではShared RunnerとSpecific Runnerの二つの方法でRunnerを動かすことが可能です。両者の違いは全てのプロジェクトで使うか、単独のプロジェクトで使うかという違いです。セキュリティを考慮して分離したいとか、重い処理をする可能性があるので単独にしたいということがなければ、Shared Runnerとして実行すれば良いでしょう。なおSpecific Runnerはプロジェクトに権限のあるユーザーであれば設定できますが、Shared RunnerはAdmin権限のあるユーザーのみ設定できるものです。
左上のメニューから「Admin」を選んでAdmin Areaを開きます。 「Over View -> Runner」を開くと、トークンキーとURLが表示されます。これをメモしておきます。
次にRunnerマシンでコマンドを実行して、GitLab Runnerをセットアップします（※印部分は置き換えてください）
# gitlab-runner register Runtime platform arch=amd64 os=linux pid=4390 revision=5316d4ac version=14.6.0 Running in system-mode. Enter the GitLab instance URL (for example, https://gitlab.com/): https://test-devops.jp-east-1.gitlab.devops.nifcloud.com ※ Enter the registration token: pV6h_rzigAmmDz-qJZn8 ※ Enter a description for the runner: [ubuntu]: git-lab-runner-on-nifclaud Enter tags for the runner (comma-separated): runner,docker Registering runner... succeeded runner=DUKEoHj3 Enter an executor: docker+machine, kubernetes, docker, docker-ssh, shell, ssh, virtualbox, custom, parallels, docker-ssh+machine: docker Enter the default Docker image (for example, ruby:2.6): ubuntu:latest Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! # gitlab-runner restart
以上でセットアップは完了です。しばらく待っていると、管理画面にGitLab Runnerが追加されます。
CIを試す
以上でGitLabによるCI/CDの実行に必要な環境は揃ったので、CI/CDを試してみましょう。 新しいプロジェクトを作成を選びます。
項目の中から「Create from template」を選びます。
いくつかテンプレートが表示されますので、今回は「Pages/Plain HTML」を選んでみます。
プロジェクト名やプロジェクトの公開レベルを設定します。PrivateかInternalで良いと思います。
テンプレートがインポートされます。インポート後、そのプロジェクトを開いてみます。
インポートしたプロジェクトはまだCI処理は行われません。
.gitlab-ci.ymlを開いて、次のようにtags: dockerを追加します。「This GitLab CI configuration is valid.」と表示されるのを確認したら、Commit messageを入力して「Commit changes」ボタンをクリックします。
image: alpine:latest pages: stage: deploy script: - echo 'Nothing to do...' artifacts: paths: - public only: - master tags: - docker
以上で、CI/CDするための設定が追加されたため、コードがコミットされるとtagsで指定したRunnerを使ってCI/CDの各処理が行われます。今回はCIまでを行っています。
ニフクラのDevOps + HatobaでDevOps環境を整える
DevOps環境（GitLab）の用意
ニフクラの「DevOps」サービスを使ってDevOpsサーバーを作成します。 ファイアウォールの設定が事前に必要です（クラスタノードへのログインはできません）。
Kubernetes GitLab Runnerの用意
次にニフクラの「Kubernetes Service Hatoba」サービスを使ってKubernetesクラスターを作成します。 ファイアウォールの設定が事前に必要です（クラスタノードへのログインはできません）。 利用できるKubernetesのバージョンは結構幅があります。ダッシュボードからバージョンの変更も可能みたいです。
ニフクラは基本的には以下に書かれているような設定をするだけでKubernetesクラスターを作成できて便利です。
クラスターができたらkubeconfigがダウンロードできるので、クライアントにkubectlとhelm v3のインストール、kubeconfigをダウンロードして展開すれば、操作可能になります。
操作クライアント環境の用意
kubectl CLIがインストールされていない場合は、事前にインストールします。
Hatobaを使ってKubernetesクラスターを作成したら、クラスターのKubeconfigをダウンロードします。
これを端末にダウンロードして、kubectlコマンドなどを使うことで、クラスターを利用できます。
$ mkdir ~/.kube/ （~/.kube/configにHatobaのkubeconfigを書き込む） $ chmod 600 ~/.kube/config $ kubectl get no NAME STATUS ROLES AGE VERSION pool1-inqoj Ready <none> 55m v1.20.1 pool2-u2omn Ready <none> 55m v1.20.1
helm CLIがインストールされていない場合は事前にインストールします。v2とv3があありますが、今回はv3のhelmをインストールしてください。
準備が完了したら、helmコマンドで、Kubernetesクラスターに対してGitLab Runnerのインストールをするための設定を行います。
$ helm repo add gitlab https://charts.gitlab.io $ helm show values gitlab/gitlab-runner > gitlab-runner-values.yaml （注1: GitLab CI/CDのRunnerの設定画面を開いて、クレデンシャルとGitLab URLを確認。gitlab-runner-values.yamlに記述する） # For Helm 3 $ helm install gitlab-runner -f gitlab-runner-values.yaml gitlab/gitlab-runner
注1: 共用のRunnerとする場合は、AdminエリアからRunnerの設定を開いて設定します。 （プロジェクト）専用のRunnerとする場合は、プロジェクトの設定からRunnerの設定を開いて設定します。
共用のRunnerと設定する場合のgitlab-runner-values.yamlの例
gitlabUrl: https://test-devops.jp-east-1.gitlab.devops.nifcloud.com runnerRegistrationToken: "pV6h_rzigAmmDz-qJZn8" rbac: create: true tags: "myhatoba"
設定をよしなに書き換えて実行すると、gitlab-runnerがクラスターで動き始めます。
$ helm install gitlab-runner -f gitlab-runner-values.yaml gitlab/gitlab-runner NAME: gitlab-runner LAST DEPLOYED: Wed Jan 12 17:18:03 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Your GitLab Runner should now be registered against the GitLab instance reachable at: "https://test-devops.jp-east-1.gitlab.devops.nifcloud.com" Runner namespace "default" was found in runners.config template.
実行してしばらくすると、GitLabのRunnerのページに現れます。
あとはいつものように、.gitlab-ci.ymlのタグでRunnerを呼び出すだけでGitLab CI/CD環境として利用できます。「Create new project」を実行して、テンプレートを作成からテンプレートを選んで、CI/CDを体験してみましょう。gitlab-runner-values.yamlで設定したタグを.gitlab-ci.ymlに書き込むことで、K8s HatobaをCI/CDのノードとして使ってくれます。
image: alpine:latest pages: stage: deploy script: - echo 'Nothing to do...' artifacts: paths: - public only: - master tags: - myhatoba
後はソースを変更してコミットするごとにKubernetes上にPodが作成され、その中でCIが実行されます。CIの処理が終わると、作成されたPodは削除されます。そのため、CIの処理ごとにクリーンな環境でテストを実行できるというわけです。
ニフクラのサービスのいい点、もう少しな点
最後にDevOpsサービスとKubernetesクラスタ構築サービスであるHatobaを使ったときに感じたこと、今後に期待することなどをまとめてみます。
DevOpsサービスの良い点
- 数個設定をするだけで「DevOps」を始められるのは良いところ
- 意外と面倒な証明書周りも設定済み
- コンテナイメージの格納のための設定（証明書含む）も設定済みですぐ使える
DevOpsサービスに今後期待したい点
- GitLab Serverが用意されるだけなので、全く初めての人は「次に何をすれば良いのか？」迷子になる
- GitLab Serverの中で１台目のRunnerが動くか、共用のRunnerが設定済みになっているといいのにと思う
- Hatobaと異なりGitLabのバージョンを選択できない点。デプロイした後はずっと同じバージョンを使い続ける必要がある？
- Ubuntuベースで動いているが、ベースOSのカーネルが異常に古い（GUIでアップデート管理できるようにするか、定期的にテンプレートをメンテしてほしい）
Hatobaの良い点
- 数個設定をするだけで「Kubernetes」を使い始められるのは良いところ
- 複数K8sクラスターバージョンが選べるのも良いところ
Hatobaの今後に期待したい点
- CNIとしてCanalを使っている。ネットワークポリシー機能を使えるCalicoだったらよかったのに
- 例えば特定のタグを持つPod同士のみ通信を許可する...のような柔軟なセキュリティ対策がとれる機能
- そのほかFWみたいな機能があったりしますが、それは他の手段で行えることなのでまあ良いとして...
- Ubuntuベースで動いているが、ベースOSのカーネルが異常に古い（GUIでアップデート管理できるようにするか、定期的にテンプレートをメンテしてほしい）
いろいろ書きましたが、ニフクラのDevOpsサービスとHatobaの組み合わせは簡単にCI/CD環境を作れて便利なので、DevOpsに興味はあるけど試せる環境がないというかたは、現在「DevOps導入支援！DevOps with GitLab無償キャンペーン」を実施中（2022年7月31日まで）とのことですので、 ニフクラで「DevOps」を触ってみてはいかがでしょうか？
（HatobaやGitLab Runnerの実行用の仮想マシンについては有料である点はご注意ください）
