Follow up from this progress update.
To support the release and PR testing process, we are working on deploying an instance of Gitlab and the Gitlab Runner services on our Kubernetes cluster. The runners will automatically run jobs on new releases and PRs.
These jobs will:
该提问来源于开源项目：spack/spack
分享 Here's a quick recap of my progress:
I was able to run the Gitlab and Gitlab Runner services using vanilla Docker. https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/docker/README.md
I confirmed correct operation in the vanilla Docker case by successfully running a test pipeline.
I moved on to investigating deployment of Gitlab on a Kubernetes cluster. I began evaluation of a beta tool for automating Kubernetes deployment. https://docs.gitlab.com/ce/install/kubernetes/gitlab_omnibus.html I learned that this tool is, more conceretely, a collection of files providing specifications for an automated Gitlab deployment on Kubernetes. This collection is called a "Helm Chart" and is processed using an automation tool called "Helm".
I moved on to evaluating the use of Helm for general Kubernetes automation. I concluded that the adoption of Helm is likely to prove fruitful, for the deployment of Gitlab as well as general Kubernetes deployment automation.
I carried out a number of preliminary operations on our running Kubernetes cluster on AWS, in preparation for performing test runs of the Gitlab Helm Charts and according to documentation. https://docs.gitlab.com/ce/install/kubernetes/gitlab_omnibus.html
Soon, I will try to run the charts against our cluster and see what happens. It's hard to say how far I'll get because the charts where designed to use GCP or Azure, and we're on AWS.
There's also a technical detail I read about in the documentation: It says that the charts that I'm about to try need a DNS service with a "wildcard" entry, which I only vaguely understand. If necessary, I might need help addressing this detail.
分享
