This project shows how a common multi-component workload, in this case GitLab, can be deployed on Kubernetes Cluster. GitLab is famous for its Git-based and code-tracking tool. GitLab represents a typical multi-tier app and each component will have their own container(s). The microservice containers will be for the web tier, the state/job database with Redis and PostgreSQL as the database.
By using different GitLab components (NGINX, Ruby on Rails, Redis, PostgreSQL, and more), you can deploy it to Kubernetes. This example is also deployable using Databases for PostgreSQL in IBM Cloud as the database.
The user interacts with GitLab via the web interface or by pushing code to a GitHub repository. The GitLab container runs the main Ruby on Rails application behind NGINX and gitlab-workhorse, which is a reverse proxy for large HTTP requests like file downloads and Git push/pull. While serving repositories over HTTP/HTTPS, GitLab utilizes the GitLab API to resolve authorization and access and serves Git objects.
After authentication and authorization, the GitLab Rails application puts the incoming jobs, job information, and metadata on the Redis job queue that acts as a non-persistent database.
Repositories are created in a local file system.
The user creates users, roles, merge requests, groups, and more—all are then stored in PostgreSQL.
The user accesses the repository by going through the Git shell.
For more info in installing helm, you can find the official documentation here. The helm version that you install should be the same version or a previous version to the version of the cluster (i.e. the Server version in helm version). If the helm version is newer than the cluster, the command may not work as expected.
4. Configure GitLab and Install
You can find the official helm chart repo for Cloud Native GitLab deployment here. This can guide you in configuring your own deployment for production use.
A sample configuration config.yaml in this repo can help you get started with GitLab in IKS. This yaml file is configured to use the provided ingress controller with IKS. The components (Gitaly, Postgres, Redis, Minio) will not use any persistent storage for now.
Modify config.yaml file to use your own Ingress Subdomain, certificate, and IP.
$ bx cs cluster-get <CLUSTER_NAME>
## You should look for these values
## ...
## Ingress Subdomain: anthony-dev.us-south.containers.appdomain.cloud
## Ingress Secret: anthony-dev
## ...
To get the ALB (Application Load Balancer) IP address of your cluster:
$ bx cs albs --cluster <CLUSTER_NAME>
## Get the IP Address from the public ALB
## ALB ID Enabled Status Type ALB IP Zone
## private-...-alb1 false disabled private - -
## public-...-alb1 true enabled public 169.XX.XX.XX dal13
You can now fill in your own values of INGERSS_SUBDOMAIN, INGRESS_SECRET, and ALB_IP in config.yaml
To try GitLab with persistent storage, you can explore config-persistent.yaml and use that instead of config.yaml. This will use dynamic storage provisioning that's provided with IKS.
You can learn how to expose the port 22here with the ingress controller to clone repositories using SSH.
Troubleshooting
If a pod doesn't start examine the logs.
kubectl get pods
kubectl logs <pod name>
Cleanup
To delete your GitLab installation:
$ helm delete gitlab --purge
License
This code pattern is licensed under the Apache Software License, Version 2. Separate third party code objects invoked within this code pattern are licensed by their respective providers pursuant to their own separate licenses. Contributions are subject to the Developer Certificate of Origin, Version 1.1 (“DCO”) and the Apache Software License, Version 2.
请发表评论