KubernetesでGitLabを動かす方法
概要
今回は、Kubernetes上でGitLabを構築する方法を紹介します。
環境
- Kubernetes 1.14
GitLabとは
GitLabは、Gitというバージョン管理システムを使用したコラボレーションツールです。
一言で言うならば、自分で管理するGitHubのようなものです。
GitHubのような所にファイルをアップロードできない理由がある企業や、全員に公開されていないプライベートリポジトリが欲しい時に使うことができます。
GitLabと似たような名前のサービスにGitLab.comというものがありますが、これは自分自身のサーバにGitLabをインストールするのではなく、GitLabを開発している会社が提供しているGitLabを使うことができるサービスです。
GitLabには、Core EditionとEnterprise Editionの2つの種類があります。
Core Editionは、無料で使うことができるバージョンで、Enterprise Editionと比べて機能がいくつか制限されています。
Enterprise Editionは、企業などで使う場合に使えるような機能をCore Editionに追加したものです。こちらのバージョンは、お金を払って使う必要があります。
そのため、今回はCore Editionの方をインストールします。
インストールについて
ここでは、GitLabをKubernetesをインストールします。
GitLabをKubernetesに配置する方法として、Helmというものを使う方法がよく紹介されていますが、今回はそれを使わずにKubernetesのDeployment等を使用して動かします。
Volume
まず、GitLabのデータを保存するためのVolumeを用意します。
ここでは、NFSのボリュームをマウントする方法を紹介します。そのため、それぞれの環境にあわせて内容を書き換えてください。
apiVersion: v1
kind: PersistentVolume
metadata:
name: gitlab-pv
labels:
name: gitlab-pv
spec:
capacity:
storage: "100Gi"
accessModes:
- ReadWriteOnce
nfs:
server: xxx
path: xxx
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: gitlab-config-pv
labels:
name: gitlab-config-pv
spec:
capacity:
storage: "100Mi"
accessModes:
- ReadWriteOnce
nfs:
server: xxx
path: xxx
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gitlab-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: "100Gi"
selector:
matchLabels:
name: gitlab-pv
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gitlab-config-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: "100Mi"
selector:
matchLabels:
name: gitlab-config-pv
Volumeは、PersistentVolumeとPersistentVolumeClaimを使用して用意しています。
内容としては、GitLabのデータを保持するVolumeと設定を保持するVolumeを作成しています。
設定
Volumeを用意したら、次のURLを参考に設定を書いていきます。
files/gitlab-config-template/gitlab.rb.template · master · GitLab.org / omnibus-gitlab · GitLab
設定は、gitla-config-pvのVolumeの中にgitlab.rbという名前で保存します。
基本的にコピペで全ての内容を一度書き込み、必要なところを適当にコメントインして変更する方法がいいと思います。
Deployment
Volumeの用意をしたら、GitLabをデプロイします。
GitLabのイメージはDocker Hubに公開されているGitLabの公式のイメージを使用します。
次のようなDeploymentを用意します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: gitlab
labels:
app: gitlab
spec:
selector:
matchLabels:
app: gitlab
template:
metadata:
labels:
app: gitlab
spec:
containers:
- image: gitlab/gitlab-ce:latest
name: gitlab
volumeMounts:
- name: gitlab-config-persistent-storage
mountPath: /etc/gitlab
- name: gitlab-persistent-storage
mountPath: /var/opt/gitlab
volumes:
- name: gitlab-config-persistent-storage
persistentVolumeClaim:
claimName: gitlab-config-pvc
- name: gitlab-persistent-storage
persistentVolumeClaim:
claimName: gitlab-pvc
Volumeをマウントするパスについては、設定ファイルであるgitlab.rbの内容を書き換えることで変えることもできますが、今回はデフォルトの場所を指定します。
Service
GitLabのデプロイが終わっても、このままではすぐに使用することができません。
そのため、Serviceを作成して、アクセスできるようにする必要があります。
Serviceの部分は、Kubernetesの環境によって、抽象化されているため例えばGCPではGoogle Cloud Load Balancingが使われるなど、具体的な内容は変わります。
今回はNodePortを使用してアクセスする方法を紹介します。
apiVersion: v1
kind: Service
metadata:
labels:
app: gitlab-outside
name: gitlab-outside
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30000
protocol: TCP
selector:
app: gitlab
このサービスを使う場合、http://kubernetesのNodeのIP:30000 にアクセスすることでGitLabを使用できますが、これはあまり実用的でないです。
それぞれの環境にあったServiceを各自で用意しましょう。
さいごに
Kubernetesの面倒な部分としてデプロイに失敗した場合、デバッグが大変というのがあるように私は感じています。
1つの成功例として使われれば、幸いです。