我有一个自托管的gitlab,我想部署应用程序。我正在尝试部署运行程序,以便gitlab可以连接到kubernetes集群。我的kubernetes集群启用了RBAC。
这是我为跑步者准备的gitlab-ci.yml:
services:
- docker:18-dind
stages:
- deploy
deploy:
image:
name: thorstenhans/helm3:latest
entrypoint: ["/bin/sh", "-c"]
stage: deploy
environment:
name: staging
kubernetes:
namespace: runners
script:
- echo ${CI_JOB_NAME}
- helm version
- kubectl version
- helm repo add gitlab https://charts.gitlab.io/
- helm install gitlab/gitlab-runner --version 0.20.0 -f values.yml
这是values.yml文件:
## The GitLab Server URL (with protocol) that want to register the runner against
## ref: https://docs.gitlab.com/runner/commands/README.html#gitlab-runner-register
##
gitlabUrl: https://gitlab.mydomain.com/
## The registration token for adding new Runners to the GitLab server. This must
## be retrieved from your GitLab instance.
## ref: https://docs.gitlab.com/ee/ci/runners/
##
runnerRegistrationToken: "registration code here"
## Set the certsSecretName in order to pass custom certificates for GitLab Runner to use
## Provide resource name for a Kubernetes Secret Object in the same namespace,
## this is used to populate the /etc/gitlab-runner/certs directory
## ref: https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates
##
#certsSecretName:
## Configure the maximum number of concurrent jobs
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
concurrent: 10
## Defines in seconds how often to check GitLab for a new builds
## ref: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section
##
checkInterval: 30
## For RBAC support:
rbac:
create: false
## Run the gitlab-bastion container with the ability to deploy/manage containers of jobs
## cluster-wide or only within namespace
clusterWideAccess: true
## If RBAC is disabled in this Helm chart, use the following Kubernetes Service Account name.
##
# serviceAccountName: default
## Configuration for the Pods that the runner launches for each new job
##
runners:
## Default container image to use for builds when none is specified
##
image: ubuntu:18.04
## Run all containers with the privileged flag enabled
## This will allow the docker:stable-dind image to run if you need to run Docker
## commands. Please read the docs before turning this on:
## ref: https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-dind
##
privileged: false
## Namespace to run Kubernetes jobs in (defaults to 'default')
##
# namespace:
## Build Container specific configuration
##
builds:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
## Service Container specific configuration
##
services:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
## Helper Container specific configuration
##
helpers:
# cpuLimit: 200m
# memoryLimit: 256Mi
cpuRequests: 100m
memoryRequests: 128Mi
如何为gitlab创建服务帐户,以便它可以在整个群集范围内部署应用程序?
答案 0 :(得分:0)
您可以在gitlab documentation中找到此信息。
启用RBAC支持
如果您的群集启用了RBAC,则可以选择让图表创建自己的服务帐户,也可以自己提供一个。
要让图表为您创建服务帐户,请将rbac.create设置为true:
rbac:
create: true
要使用现有的服务帐户,请使用:
rbac:
create: false
serviceAccountName: your-service-account
所以您必须将values.yaml更改为
rbac:
create: false
clusterWideAccess: true
serviceAccountName: your-service-account
有有关rbac和服务帐户的相关文档。
还有另外一个stackoverflow帖子和一个gitlab问题,应该有助于为您的用例创建服务帐户。
答案 1 :(得分:0)
您可以使用:
<块引用>最终目标:在连接的 GitLab CI yml 中执行所有 helm 操作 集群存储库(与在服务器上运行相比)。
参见 GitLab 14.0(2021 年 6 月)
<块引用>在此版本中,我们不再使用基于 CI/CD 模板的集群管理方法。
集群管理是管理 Kubernetes 集群以提高在集群上运行的应用程序可用性的能力。
旧方法隐藏了太多逻辑,限制了应用的自定义和扩展。
使用新方法,您可以轻松地从项目模板创建集群管理项目并完全控制您的应用程序。
使用新模板创建的项目包含集群管理作业所需的代码,包括 built-in support for several applications。您可以轻松地将项目扩展到其他应用程序并完全拥有它们。
此外,将使用 Helm v3 安装新应用程序。如果您以前使用 Helm v2 安装了 GitLab 托管应用程序,请检查 Helm migration guide 和 GitLab Managed Apps migration guide。 CI/CD 作业输出还将指导您完成这些迁移。
在 GitLab 14.0 中,集群管理项目仅支持基于证书的集群集成。我们计划在下一个版本中添加对 GitLab Kubernetes 代理的支持。
参见 Documentation 和 Issue。