作者:想要把迩贴上私人标签92 | 来源:互联网 | 2023-02-07 10:41
我公司已经运行Kuberenetes一年多了,GitLab运行了大约6个月.我们最近升级到GitLab 9.x,并且无法通过Kube了解CI + app配置的决定.这个功能很棒,很想让它在我们的环境中工作.
似乎GitLab希望您只有一个集群设置,其中一个集群内的所有环境都被命名空间分解,这将等同于您的服务/应用程序和应用程序,这将等同于您的环境.这就是GitLab希望我的Kuberenetes环境看起来像一个单独的集群,您的服务被分解为命名空间:
namespace = hello-world
app = development
app = qa
app = production
在现实世界的例子中,我们更倾向于使用与单个集群相同的相反方案
DEVELOPMENT CLUSTER
namespace = development
app = hello-world
QA CLUSTER
namespace = qa
app = hello-world
PRODUCTION CLUSTER
namespace = production
app = hello-world
将命名空间作为应用程序并将应用程序作为环境,我们将无法升级到最新版本的kube而无需升级所有内容.也许我错过了一些东西,但是基于我正在阅读的东西,经过测试后,它看起来就像它的设计方式.
作为参考,这是我的CI现在看起来像是使部署板+终端满意
development:
<<: *deploy_definition
stage: development
environment: hello-world
script:
deploy.sh -a "hello-world"
但它应该是这样的
development:
<<: *deploy_definition
stage: development
environment: development
script:
deploy.sh -a "hello-world"
为了增加这种混淆,它们只为您提供了一个Kubernetes master来连接到集成选项卡.
这是正确的,还是我错过了什么?
1> lwolf..:
你说的没错.我发现它也令人沮丧.
但即使没有kubernetes集成,您也可以使用环境
development:
<<: *deploy_definition
stage: development
environment:
name: development
url: https://development.yourdomain.com
script:
deploy.sh -a "hello-world"
查看我最近写的关于从gitlab自动部署到kubernetes的配置的帖子.
http://blog.lwolf.org/post/how-to-create-ci-cd-pipeline-with-autodeploy-k8s-gitlab-helm/