by Krystian Rybka 
April 12. 2019
Not every project is friendly enough to allow the developer for running it locally on their computer and checking the recent changes. Almost every production environment has its clone for staging purposes. Sometimes environments have several database instances, several backend services, and some logs are collected from the whole system meanwhile. In this situation, the number of elements and dependents could become insane.
Fortunately, containerization methods connected with Continuous Integration and Continuous Deployment (CI and CD) are here to save the day. For some time, GitLab and Google have been collaborating to integrate Kubernetes GitLab clusters that run on the Google Kubernetes Engine (GKE) which is the part of Google Cloud Platform. Since 2018, using only one form, you can pin the GitLab project to the GKE cluster. After that, deploy the code in the sandbox or developer environment before deployments in a production environment. Just as much as you want.
Okay, now let's dig a little bit deeper. Where in Kubernetes can you test branches different than Master? The answer is dynamic environments. You run them temporality, only when it's necessary.
In the era of cloud solutions, platforms like Google Cloud charge us as a flat hourly rate or based on the resources that you use, such as the number of vCPUs, memory, or GPUs in your deployment. Dynamic environments allow for testing huge solutions at a lower cost than classic solutions. Why? We borrow advanced (and hella expensive!) Google infrastructure for a short period of time. For example, you can check new functionalities on the test branch.
Review Apps is a collaboration tool that allows designers and product managers to see your changes without a need to check out your branch and run your changes in a sandbox environment. Using it, you can deploy your changes wherever you want.
Are you ready to get your hands dirty? I hope so because I will show you the way to cut costs even more. Use your own Kubernetes cluster. We decided to make it this way.
Is deploying Kubernetes on bare metal hard? You can find instructions saying that you can do it in about ten minutes. But if it's your first time, I really doubt it. And don't feel bad about it - just check some instructions if you're curious.
Good news is that I have a protip which can help you to spin up your own Kubernetes cluster in ONE MINUTE. Guess I got your attention now :)
Also known as "You don’t need to figure Kubernetes out all on your own", is an open source software stack to run and manage Kubernetes clusters. It's delivered as docker image so assuming you have Docker installed (at least version 18.06.2) it comes down to executing following command:
$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher:latest
A dashboard will be available at https://<server_ip>. Once the server is running, log in and follow the instructions.
A friendly reminder here: This command does not enable persistent storage for the server and should only be used in a test environment. To enable persistence, add -v /opt/rancher:/var/lib/rancher to the command to bind a host volume to the container.
The dashboard is pretty self-explanatory, but right next to "Launch kubectl" (get familiar with at least basic kubectl commands) there is "Kubeconfig file" button - it contains all information needed to connect your GitLab with Rancher (which is basically Kubernetes with additional management features and GUI).
Rancher allows you to manage your Kubernetes cluster from GUI and command line as well. From my perspective, you can have more control when using self-made YAML files and deploy them manually with the kubectl console. However, there is also nothing wrong with deploying by clicking in the GUI - furthermore, Rancher can help by automatically creating service for deployment or spin up an Ingress instance with few clicks.
After connecting your GitLab project to your Kubernetes cluster, you need to create a .GitLab-ci.yml file. So far, you've been probably using files containing this kind of stuff:
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
only:
- master
In the case of dynamic environments the address will appear as a variable:
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
only:
- branches
except:
- master
I advise you to get familiar with GitLab documentation on this topic.
After a correct configuration, you'll be able to preview your deploy using the button. You can see it clearly in the merge request view:
There you are. Now you're a proud owner of tidy and manageable one-place traditional environments (staging, prod) along with dynamic ones (feature) in one view of Rancher. Now with only one click you can scale them and browse logs of every one of them. A passed pipeline is automatically deployed on Kubernetes and ready to review.
As you've probably noticed, it's not a step-by-step guide. It rather shows some concept and tools that will allow you to make one click app review possible. Feel free to explore the starlig world of Kubernetes and GitLab CI/CD features!
Do you have other optimization hacks? Let's discuss it in the comments!
Best free network monitoring tools - they don't fall behind paid equivalents!
Have an idea ? Let’s talk
Fill up the form and we will contact you shortly.
ServoCode Sp. z o.o.
Jasionka 954E, 36-002 Jasionka, Poland
NIP: 8133719852
REGON: 364182909
KRS: 0000611643
Your message has been sent!
Your message has been sent!