概要

今回は、Kubernetes上でGitLabを構築する方法を紹介します。

環境

  • Kubernetes 1.14

GitLabとは

GitLabは、Gitというバージョン管理システムを使用したコラボレーションツールです。

一言で言うならば、自分で管理するGitHubのようなものです。

GitHubのような所にファイルをアップロードできない理由がある企業や、全員に公開されていないプライベートリポジトリが欲しい時に使うことができます。

GitLabと似たような名前のサービスにGitLab.comというものがありますが、これは自分自身のサーバにGitLabをインストールするのではなく、GitLabを開発している会社が提供しているGitLabを使うことができるサービスです。

GitLabには、Core EditionとEnterprise Editionの２つの種類があります。
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の公式のイメージを使用します。

Docker

次のような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の面倒な部分としてデプロイに失敗した場合、デバッグが大変というのがあるように私は感じています。

１つの成功例として使われれば、幸いです。