阿川私房教材：
學 JavaScript 前端，帶作品集去面試！

63 個專案實戰，寫出作品集，讓面試官眼前一亮！

小編精選 - 技術文章翻譯 · 12月05日

🚀 Kubernetes 上的 GITLAB：終極部署指南！ 🌟

TL；DR 🔍

探索在 Kubernetes 上部署 GitLab 的逐步指南，並專注於 Omnibus 套件配置。了解如何設定 PostgreSQL、SMTP、Container Registry、Sidekiq、Prometheus 指標和備份。使用 Glasskube GitLab Kubernetes Operator 探索替代方案，簡化流程並將設定時間縮短至僅 5 分鐘。

我們需要您的回饋！ 🫶

在下面的評論中分享您的想法！讓我們知道您想要更多內容的主題。如果本指南有幫助，請點擊貓並留下一顆星，以支持我們建立更多以開發人員為中心的內容。您的回饋很重要！

[ Glasskube Github

](https://github.com/glasskube/operator)

讓我們開始吧🏌️

GitLab 是一個以軟體工程團隊為導向的開源 DevSecOps 平台。

有兩種方式可用於在 Kubernetes 叢集上部署 GitLab：

1.GitLab雲端原生混合

2.GitLab包（綜合）

GitLab 雲端原生混合

部署 GitLab Cloud 原生混合架構僅在查詢特定用例中才有意義。例如 - 如 GitLab 決策樹所示 - 如果 GitLab 實例需要為至少 3,000 個使用者提供服務。對於這種部署，GitLab 元件將單獨安裝在不同的 docker 容器中。最低要求為 10 個節點，總共 19 個 vCPU 和 60 GB 內存，這將導致每月數千美元的雲端成本。

因此，在大多數情況下，GitLab 雲端原生是不需要的，而且過於複雜。

那麼，如何在 Kubernetes 上部署 GitLab Omnibus？

Kubernetes 上的 GitLab Omnibus

使用「omnibus」這個名稱，GitLab 也發布了一體化軟體包，這些軟體包可以作為docker 映像[hub.docker.com/r/gitlab/gitlab-ce](https://hub.docker. com /r/gitlab/gitlab-ce)，可以透過環境變數輕鬆配置。正確進行設定可以輕鬆在 Kubernetes 上部署 GitLab。

應正確配置以下重要元件，以便歸檔合理的 Kubernetes 設定：

1.PostgreSQL資料庫

SMTP配置
Kubernetes 上的 GitLab 容器註冊表
Sidekiq、Gitaly 和 Puma 配置
普羅米修斯指標
Kubernetes 上的 GitLab 備份

Kubernetes 上的 GitLab：設定外部 PostgreSQL 資料庫

建立 PostgreSQL 資料庫可以使用 CloudNativePG PostgreSQL Operator 來完成。安裝完 Operator 後，可以透過套用 Kubernetes CR 來部署新的 Postgres 叢集：

kind: Cluster
apiVersion: postgresql.cnpg.io/v1
metadata:
  name: gitlab
spec:
  enableSuperuserAccess: false
  instances: 2
  bootstrap:
    initdb:
      database: gitlabhq_production
      owner: gitlab
  storage:
    size: 20Gi

重要的是，資料庫名稱為“gitlabhq_product”，而配置的“gitlab”資料庫使用者是資料庫的擁有者。在本例中，我們建立了一個由兩個 PostgreSQL 副本組成的集群，以確保資料庫保持可用，即使執行主副本的節點發生故障也是如此。這稱為高可用性 (HA)。

現在，我們建立了自己的 PostgreSQL 集群，必須在「gitlab.rb」檔案中停用綜合映像中包含的資料庫。

postgresql['enable'] = false

gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = 'gitlab-pg-rw'
gitlab_rails['db_password'] = '<your-password>'

很好，我們已經為 GitLab 安裝提供了雲端原生資料庫。

Kubernetes 上的 GitLab：設定 SMTP 憑證

為了確保您的 GitLab 實例能夠傳送電子郵件，您需要設定 SMTP 伺服器。這也可以在 gitlab.rb 檔案中完成。

gitlab_rails['smtp_enable'] = ...
gitlab_rails['smtp_address'] = ...
gitlab_rails['smtp_port'] = ...
gitlab_rails['smtp_user_name'] = ...
gitlab_rails['smtp_password'] = ...
gitlab_rails['smtp_tls'] = ...
gitlab_rails['gitlab_email_from'] = ...

例如，可以在 Brevo 平台上建立用於交易電子郵件的免費 smtp 伺服器。

Kubernetes 上的 GitLab：容器註冊表

在眾多功能中，GitLab 支援充當容器註冊表。這是透過捆綁 docker 容器註冊表的參考實作來實現的，但預設情況下它是禁用的，因為正確設定它相當麻煩。

重要

重要的是要了解 GitLab 綜合容器中的所有請求將首先由內部 nginx 伺服器處理，然後分發到元件。

容器註冊表僅適用於 TLS 加密連接，因此我們需要透過入口負載平衡器停用 TLS 終止，並將加密流量直接傳送到 GitLab 容器。如果使用 NGINX 入口控制器，可以透過在入口中新增以下註解來完成：「nginx.ingress.kubernetes.io/ssl-passthrough: true」。

之後，必須套用以下gitlab.rb配置：

registry['enable'] = true
gitlab_rails['registry_enabled'] = true
registry['token_realm'] = "https://" + ENV['GITLAB_HOST']
gitlab_rails['registry_enabled'] = true
gitlab_rails['registry_host'] = ENV['GITLAB_REGISTRY_HOST']
gitlab_rails['registry_api_url'] = "http://localhost:5000"

registry_external_url 'https://' + ENV['GITLAB_REGISTRY_HOST']
registry_nginx['redirect_http_to_https'] = true
registry_nginx['listen_port'] = 5443
registry_nginx['ssl_certificate'] = "/etc/gitlab/ssl/tls.crt"
registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/tls.key"
registry_nginx['real_ip_trusted_addresses'] = ['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16']
registry_nginx['server_names_hash_bucket_size'] = 128

此外，可以配置 S3 儲存桶（或相容的雲端儲存端點），以便所有影像層不會儲存在磁碟區內，而是儲存在可擴充的 S3 中

Kubernetes 上的 GitLab：Sidekiq、Gitaly 和 Puma 配置

Puma（Ruby 的 HTTP 伺服器）、Sidekiq（作業排程器）和 Gitaly（GitLabs Git 橋接器）都可以使用自訂數量的工作執行緒/執行緒來啟動。最佳配置在很大程度上取決於您的用例和需要支援的使用者數量。合理的最小配置是：

puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

Kubernetes 上的 GitLab：Prometheus 指標

GitLab 綜合包在鏡像中附帶了自己的 prometheus 實例。由於大多數 Kubernetes 叢集中已經存在 Prometheus 實例，因此可以安全地停用包含的 Prometheus。

prometheus_monitoring['enable'] = false

ServiceMonitor 可以用來告訴正在執行的 Prometheus 實例在下列連接埠上監視 GitLabs 元件所公開的指標端點：

8082（sidekiq）
9168（gitlab）
9236（義大利）

Kubernetes 上的 GitLab：備份

嗯，在 Kubernetes 上備份 GitLab 本身就是一個技術指南。最簡單的方法是使用 Velero 等備份解決方案備份完整的命名空間。

玻璃立方體 GitLab Kubernetes Operator

了解Glasskube GitLab Kubernetes Operator - 我們的開發團隊對繁瑣的配置過程、耗時的設定和不斷的故障排除感到沮喪的產物與 GitLab 部署相關。為了應對這些挑戰，我們精心設計了一個簡化整個體驗的解決方案。 Glasskube GitLab Kubernetes Operator 部署一個完全配置的 GitLab 實例，其所有功能均透過自訂資源定義 (CRD) 巧妙抽象化。感謝操作員，花費過多時間進行設定和更新的日子已經結束。現在，您可以在短短 5 分鐘內輕鬆啟動新的 GitLab 實例。嘗試一下並向我們提供反饋！

安裝 Glasskube 運算符

第一步是透過 Helm Chart 安裝 Glasskube：

helm repo add glasskube https://charts.glasskube.eu/
helm repo update
helm install my-glasskube-operator glasskube/glasskube-operator

完整的文件可以在我們的入門文件中找到。

部署 GitLab

重要

必須在「LoadBalancer」或「Ingress Host」上設定 DNS 專案。 SSL 憑證是

如果配置了“ClusterIssuer”，則由“LoadBalancer”或“cert-manager”自動產生。

gitlab.yaml

apiVersion: "v1"
kind: "Secret"
metadata:
  name: "gitlab-smtp"
stringData:
  username: "..."
  password: "..."
---
apiVersion: v1
kind: Secret
metadata:
  name: gitlab-registry-secret
stringData:
  accessKey: "..."
  secretKey: "..."
---
apiVersion: "glasskube.eu/v1alpha1"
kind: "Gitlab"
metadata:
  name: "gitlab"
spec:
  host: "gitlab.mycompany.eu"
  sshEnabled: true
  sshHost: "ssh.gitlab.mycompany.eu"
  smtp:
    host: "..."
    port: 465
    fromAddress: "[email protected]"
    authSecret:
      name: "gitlab-smtp"
    tlsEnabled: true
  registry:
    host: "registry.gitlab.mycompany.eu"
    storage:
      s3:
        bucket: gitlab-registry
        accessKeySecret:
          name: gitlab-registry-secret
          key: accessKey
        secretKeySecret:
          name: gitlab-registry-secret
          key: secretKey
        region: ...

kubectl apply -f gitlab.yaml

就是這樣！

完整的自訂資源文件可以在 Glasskube 文件中找到

關於 GitLab

在 Kubernetes 上部署 GitLab Runner

GitLab 上的運作程序是為持續整合和持續交付 (CI/CD) 管道提供支援的執行代理。

他們負責執行作業，即管道中的各個步驟或任務。

Glasskube Gitlab Kubernetes Operator 讓在 Gitlab 中新增執行器變得如此簡單。首先，需要透過「https://{{host}}/admin/runners/new」建立一個新的執行程式。之後，這些執行器令牌只需加入到「gitlab.yaml」規格中，Glasskube Kubernetes Operator 將自動產生並將這些執行器與 Gitlab 實例連接起來。

  runners:
    - token: glrt-xxxxXX-xxxxxXXXXX # can be generated at https://{{host}}/admin/runners/new

完整的自訂資源文件可以在關於 [GitLab runner] 的 Glasskube 文件中找到(https://glasskube.eu/docs/crd-reference/gitlab/runner/)

現在安裝完成了。 Kubernetes Operator 的更新將自動更新 GitLab。

結論

在 Kubernetes 上為少於 1000 個使用者部署 GitLab 實例不應該使用 GitLabs 雲端原生混合 Helm Charts 來完成，而應該使用專門安裝的 GitLab Omnibus 套件與雲端原生基礎架構結合來完成。 Glasskube Kubernetes 操作員負責處理這個問題。

[![玻璃立方體Github](

https://cms.glasskube.eu/uploads/CTA_51bbe3bb2a.png）

](https://github.com/glasskube/operator)

星星冰塊：