探索在 Kubernetes 上部署 GitLab 的逐步指南,並專注於 Omnibus 套件配置。了解如何設定 PostgreSQL、SMTP、Container Registry、Sidekiq、Prometheus 指標和備份。使用 Glasskube GitLab Kubernetes Operator 探索替代方案,簡化流程並將設定時間縮短至僅 5 分鐘。
在下面的評論中分享您的想法!讓我們知道您想要更多內容的主題。如果本指南有幫助,請點擊貓並留下一顆星,以支持我們建立更多以開發人員為中心的內容。您的回饋很重要!
[
](https://github.com/glasskube/operator)
GitLab 是一個以軟體工程團隊為導向的開源 DevSecOps 平台。
有兩種方式可用於在 Kubernetes 叢集上部署 GitLab:
1.GitLab雲端原生混合
2.GitLab包(綜合)
部署 GitLab Cloud 原生混合架構僅在查詢特定用例中才有意義。例如 - 如 GitLab 決策樹 所示 - 如果 GitLab 實例需要為至少 3,000 個使用者提供服務。對於這種部署,GitLab 元件將單獨安裝在不同的 docker 容器中。最低要求為 10 個節點,總共 19 個 vCPU 和 60 GB 內存,這將導致每月數千美元的雲端成本。
<img width="100%" style="width:100%" src="https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExbHl6eXltNWw0ZDNjbnNqbDdicXBpbzNpdX6e nlfaWQmY 3Q9Zw/2aIZfQdC2V7bBvU5t2/giphy.gif">
因此,在大多數情況下,GitLab 雲端原生是不需要的,而且過於複雜。
那麼,如何在 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 備份
建立 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 安裝提供了雲端原生資料庫。
<img width="25%" style="width:25%" src="https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExc2VydjJoN3BsN2RycDY5N3prZHhoaW8xdTYxenJoN3BsN2RycDY5N3prZHhoaW8xdTYxenhkbHdtBlcMpm30FmDFt0Fyg n;ipPlcmDMlcM40M400005450000200020025400000 mY3 Q9Zw/SVH9y2LQUVVCRcqD7o/giphy.gif">
為了確保您的 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 伺服器。
<img width="25%" style="width:25%" src="https://media.giphy.com/media/0IR3vO2bWY1AQPAsAn/giphy.gif">
在眾多功能中,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 中
Puma(Ruby 的 HTTP 伺服器)、Sidekiq(作業排程器)和 Gitaly(GitLabs Git 橋接器)都可以使用自訂數量的工作執行緒/執行緒來啟動。最佳配置在很大程度上取決於您的用例和需要支援的使用者數量。合理的最小配置是:
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9
GitLab 綜合包在鏡像中附帶了自己的 prometheus 實例。由於大多數 Kubernetes 叢集中已經存在 Prometheus 實例,因此可以安全地停用包含的 Prometheus。
prometheus_monitoring['enable'] = false
ServiceMonitor 可以用來告訴正在執行的 Prometheus 實例在下列連接埠上監視 GitLabs 元件所公開的指標端點:
8082(sidekiq)
9168(gitlab)
9236(義大利)
嗯,在 Kubernetes 上備份 GitLab 本身就是一個技術指南。最簡單的方法是使用 Velero 等備份解決方案備份完整的命名空間。
了解Glasskube GitLab Kubernetes Operator - 我們的開發團隊對繁瑣的配置過程、耗時的設定和不斷的故障排除感到沮喪的產物與 GitLab 部署相關。為了應對這些挑戰,我們精心設計了一個簡化整個體驗的解決方案。 Glasskube GitLab Kubernetes Operator 部署一個完全配置的 GitLab 實例,其所有功能均透過自訂資源定義 (CRD) 巧妙抽象化。感謝操作員,花費過多時間進行設定和更新的日子已經結束。現在,您可以在短短 5 分鐘內輕鬆啟動新的 GitLab 實例。嘗試一下並向我們提供反饋!
第一步是透過 Helm Chart 安裝 Glasskube:
helm repo add glasskube https://charts.glasskube.eu/
helm repo update
helm install my-glasskube-operator glasskube/glasskube-operator
完整的文件可以在我們的入門文件中找到。
重要
必須在「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
<img width="25%" style="width:25%" src="https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExa2RldHpiYnMzOWdlZTgwdWtqOHN3N3eG9I0NjVyd2l4m Y3Q9Zw/YRhUem7n2UaF9EK2PH/giphy.gif">
就是這樣!
完整的自訂資源文件可以在 Glasskube 文件中找到
關於 GitLab
<img width="25%" style="width:25%" src="https://media.giphy.com/media/v1.Y2lkPTc5MGI3NjExZDJsN2x6NTI0dWdhZW55MjBzMjFobHdtbDRtaHEycXlidWdhZW55MjBzMjFobHdtbDRtaHEycXlidWdhZW55MjBzMjFobHdtbDRtaHEycXlidGt. WQmY 3Q9Zw/945jGDodvZCDe/giphy.gif">
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)
星星冰塊:
glasskube/operator
原文出處:https://dev.to/glasskube/gitlab-on-kubernetes-the-ultimate-deployment-guide-188b