GitLab-Omnibus Helm Chart
Note:.
- This chart has been tested on Google Kubernetes Engine and Azure Container Service.
This chart is beta, and is the best way to install GitLab on Kubernetes today.A newcloud native GitLab chartis in development with increased scalability and resilience, among other benefits. Once available, the cloud native chart will be the recommended installation method for Kubernetes, and this chart will be deprecated.
For more information on available GitLab Helm Charts, please see ouroverview.
This work is based partially on:https://github.com/lwolf/kubernetes-gitlab/. GitLab would like to thank Sergey Nuzhdin for his work.
Introduction
This chart provides an easy way to get started with GitLab, provisioning an installation with nearly all functionality enabled. SSL is automatically provisioned viaLet's Encrypt.
This Helm chart is in beta, and is suited for small to medium deployments. It will be deprecated by thecloud native GitLab chartonce available. Due to the significant architectural changes, migrating will require backing up data out of this instance and importing it into the new deployment.
The deployment includes:
- AGitLab OmnibusPod, including Mattermost, Container Registry, and Prometheus
- An auto-scalingGitLab Runnerusing the Kubernetes executor
- Redis
- PostgreSQL
- NGINX Ingress
- Persistent Volume Claims for Data, Registry, Postgres, and Redis
Limitations
- This chart is in beta, and suited for small to medium size deployments.High AvailabilityandGeoare not supported.
- A new generationcloud native GitLab chartis in development, and will deprecate this chart. Due to the difficulty in supporting upgrades to the new architecture, migrating will require exporting data out of this instance and importing it into the new deployment. We plan to release the new chart in beta by the end of 2017.
For more information on available GitLab Helm Charts, please see ouroverview.
Prerequisites
- At least4 GB of RAM available on your cluster. 41GB of storage and 2 CPU are also required.
- Kubernetes 1.4+ with Beta APIs enabled
- Persistent Volumeprovisioner support in the underlying infrastructure
- Awildcard DNS entry, which resolves to the external IP address
- The
kubectl
CLI installed locally and authenticated for the cluster - TheHelm clientinstalled locally on your machine
Networking Prerequisites
This chart configures a GitLab server and Kubernetes cluster which can support dynamicReview Apps, as well as services like the integrated容器注册表andMattermost.
To support the GitLab services and dynamic environments, a wildcard DNS entry is required which resolves to theLoad BalancerorExternal IP. Configuration of the DNS entry will depend upon the DNS service being used.
External IP (Recommended)
To provision an external IP on GCP and Azure, simply request a new address from the Networking section. Ensure that the region matches the region your container cluster is created in. Note, it is important that the IP is not assigned at this point in time. It will be automatically assigned once the Helm chart is installed, and assigned to the Load Balancer.
Now that an external IP address has been allocated, ensure that the wildcard DNS entry you would like to use resolves to this IP. Please consult the documentation for your DNS service for more information on creating DNS records.
Finally, set thebaseIP
setting to this IP address whendeploying GitLab.
Load Balancer IP
If you do not specify abaseIP
, an IP will be assigned to the Load Balancer or Ingress. You can retrieve this IP by running the following commandafterdeploying GitLab:
kubectl get svc -w --namespace nginx-ingress nginx
The IP address will be displayed in theEXTERNAL-IP
field, and should be used to configure the Wildcard DNS entry. For more information on creating a wildcard DNS entry, consult the documentation for the DNS server you are using.
For production deployments of GitLab, we strongly recommend using anExternal IP.
Configuring and Installing GitLab
For most installations, only two parameters are required:
baseDomain
: thebase domainof the wildcard host entry. For example,mycompany.io
if the wild card entry is*.mycompany.io
.legoEmail
: Email address to use when requesting new SSL certificates from Let's Encrypt.
Other common configuration options:
baseIP
: the desiredexternal IP addressgitlab
: Choose thedesired edition, eitheree
orce
.ce
is the default.gitlabEELicense
: For Enterprise Edition, thelicensecan be installed directly via the Chartprovider
: Optimizes the deployment for a cloud provider. The default isgke
forGoogle Kubernetes Engine, withacs
also supported for theAzure Container Service.
For additional configuration options, consult thevalues.yaml.
选择不同的GitLabrelease version
The version of GitLab installed is based on thegitlab
setting (seesectionabove), and the value of the corresponding helm setting:gitlabCEImage
orgitabEEImage
.
gitlab:CEgitlabCEImage:gitlab/gitlab-ce:9.5.2-ce.0gitlabEEImage:gitlab/gitlab-ee:9.5.2-ee.0
The different images can be found in thegitlab-ceandgitlab-eerepositories on Docker Hub.
Persistent storage
Note:If you are using a machine type with support for less than 4 attached disks, like an Azure trial, you should disable dedicated storage for Postgres and Redis.
By default, persistent storage is enabled for GitLab and the charts it depends on (Redis and PostgreSQL).
Components can have their claim size set from yourvalues.yaml
, along with whether to provision separate storage for Postgres and Redis.
Basic configuration:
redisImage:redis:3.2.10redisDedicatedStorage:trueredisStorageSize:5GipostgresImage:postgres:9.6.3# If you disable postgresDedicatedStorage, you should consider bumping up gitlabRailsStorageSizepostgresDedicatedStorage:truepostgresStorageSize:30GigitlabRailsStorageSize:30GigitlabRegistryStorageSize:30GigitlabConfigStorageSize:1Gi
Routing and SSL
Ingress routing and SSL are automatically configured within this Chart. An NGINX ingress is provisioned and configured, and will route traffic to any service. SSL certificates are automatically created and configured bykube-lego.
Note:Let's Encrypt limits a single TLD to five certificate requests within a single week. This means that common DNS wildcard services likexip.ioandnip.ioare unlikely to work.
Installing GitLab using the Helm Chart
Note:You may see a temporary error message
SchedulerPredicates failed due to PersistentVolumeClaim is not bound
while storage provisions. Once the storage provisions, the pods will automatically start. This may take a couple minutes depending on your cloud provider. If the error persists, please review theprerequisitesto ensure you have enough RAM, CPU, and storage.
Add the GitLab Helm repository and initialize Helm:
helm repo add gitlab https://charts.gitlab.iohelm init
Once you have reviewed theconfiguration settingsyou can install the chart. We recommending saving your configuration options in avalues.yaml
file for easier upgrades in the future.
For example:
helminstall--namegitlab-fvalues.yaml gitlab/gitlab-omnibus
or passing them on the command line:
helminstall--namegitlab--setbaseDomain=gitlab.io,baseIP=1.1.1.1,gitlab=ee,gitlabEELicense=$LICENSE,legoEmail=email@gitlab.com gitlab/gitlab-omnibus
Updating GitLab using the Helm Chart
Note: If you are upgrading from a previous version to 0.1.35 or above, you will need to change the access mode values for GitLab's storage. To do this, set the following in
values.yaml
or on the CLI:gitlabDataAccessMode=ReadWriteManygitlabRegistryAccessMode=ReadWriteManygitlabConfigAccessMode=ReadWriteMany
Once your GitLab Chart is installed, configuration changes and chart updates should be done usinghelm upgrade
:
helm upgrade-fvalues.yaml gitlab gitlab/gitlab-omnibus
Upgrading from CE to EE using the Helm Chart
If you have installed the Community Edition using this chart, upgrading to Enterprise Edition is easy.
If you are using avalues.yaml
file to specify the configuration options, edit the file and setgitlab=ee
. If you would like to run a specific version of GitLab EE, setgitlabEEImage
to be the desired GitLabdocker image. Then you can usehelm upgrade
to update your GitLab instance to EE:
helm upgrade-fvalues.yaml gitlab gitlab/gitlab-omnibus
You can also upgrade and specify these options via the command line:
helm upgrade gitlab--setgitlab=ee,gitlabEEImage=gitlab / gitlab-ee: 9.5.5-ee。0 gitlab / gitlab-omnibus
Uninstalling GitLab using the Helm Chart
To uninstall the GitLab Chart, run the following:
helm delete gitlab
Troubleshooting
gitlab-omnibus
versions prior to 0.1.35
Storage errors when updatingUsers upgradinggitlab-omnibus
from a version prior to 0.1.35, may see an error like:Error: UPGRADE FAILED: PersistentVolumeClaim "gitlab-gitlab-config-storage" is invalid: spec: Forbidden: field is immutable after creation
.
This is due to a change in the access mode for GitLab storage in version 0.1.35. To successfully upgrade, the access mode flags must be set toReadWriteMany
as detailed in theupdate section.