{"id":5179,"date":"2019-02-24T14:15:36","date_gmt":"2019-02-24T13:15:36","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=5179"},"modified":"2023-06-09T12:07:36","modified_gmt":"2023-06-09T10:07:36","slug":"migrating-to-kubernetes-part-4-create-environments-via-gitlab","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/02\/24\/migrating-to-kubernetes-part-4-create-environments-via-gitlab\/","title":{"rendered":"Migrating to Kubernetes Part 4 – Create Environments via Gitlab"},"content":{"rendered":"\n

Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Connect Gitlab with Kubernetes<\/h2>\n

With the Review Apps Gitlab offers an excellent improvement of the Developer Experience. More or less Gitlab enables the management of environments. For each environment, there is a CI task to each set-up and tear down. It is important that the dynamic URL under which the environment can later be reached is made available to Gitlab. Then Gitlab will kick in and preview each Merge Request with the corresponding environment.<\/p>\n<\/div>\n\n\n\n\n\n\n\n

Before this part can be started some housework has to be done. First of all, a new deploy token must be obtained in Gitlab in the repository settings. This is necessary for the Kubernetes cluster to be able to access the Gitlab registry later to pull the Docker images. Make sure to name it gitlab-deploy-token<\/code> as it will be then available for use in the CI pipeline as an environment variable. As the scope only read_registry<\/code> is required.<\/p>\n<\/div>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Next, create a new cluster or connect an existing one. The dialogue can be found under Operations – Kubernetes. The nodes of the cluster can be set up with the smallest configuration. For a successful connection there were problems with the smallest machines of the Google Cloud – maybe this problem is solved by now – if not pick an instance type larger.<\/p>\n<\/div>\n\n\n\n

\"\"<\/figure>\n\n\n\n

After a short while, the cluster will be set up and can be used. Now Helm Tiller, Ingress and Cert-manager can be installed. The ingress installation takes some minutes, once succeeded the Ingress IP Address<\/code> will be available. In oder to skip the setup of a domain, this example uses XIP.io. The service provides DNS wildcard domains. The IP is simply used as subdomain of XIP.io. Therefore enter 35.184.252.80.xip.io<\/code> as Base domain<\/code> on the Kubernetes Page of Gitlab – make sure to replace the IP with the one displayed as `Ingress IP Address’. The cluster is now successfully set up and connected!<\/p>\n

Deploy Environments to Kubernetes<\/h2>\n

The required Gitlab File is comprehensive and therefore not fully explained. However, the most important steps are briefly summarized. The build stage will take care of createing a Docker image for both, server and client. In order to push this image into the Gitlab Registry a login is required – this can be done with the docker login<\/code>-command, the values are provided as environment variables by default in each job.<\/p>\n<\/div>\n\n\n\n