In one of the previous posts, I described the way I’m using GitLab to build and test images. Despite the fact that it’s pretty simple configuration and actual tests are run for less than a minute, complete pipeline takes around 20 minutes. Which seems very unreasonable. I spent some time digging out the problem and was able to reduce build time to around 3 minutes. Here are few things, that should be considered to optimize pipeline.
DynDNS is annoying/expensive I’m using different DynDNS services at home for the last few years. It’s easy to use, comes preinstalled on most of the routers. The only annoyance is the need to confirm each of your hosts every 30 days And it’s fine because you do not pay anything. Recently, I wanted to attach proper domain to my home server to be able to access my Kubernetes from the outside.
In my previous posts I described how to deploy GitLab to Kubernetes and configure GitLab-CI to build and test docker containers. In this one, I’m going to write about continues deployments. I assume that you already have Kubernetes cluster and application running, and you have some manual way of deploying your application to it. So I will not touch the basics of writing Kubernetes manifests. But I will briefly describe my own scripts and show how I configured GitLab-CI to automate deployment.
I spent some time recently researching how to build CI/CD pipeline to automate testing and deploying. Since I’m developing everything in containers and use Kubernetes to manage it GitLab with its CI runners and recent integrations with k8s seemed like a good option. In this post, I will describe the steps needed to get GitLab with GitLab Runner, up and running on top of Kubernetes. All manifests used in this post could be found here
It’s 4 months now since I migrated my infrastructure to CoreOS and Kubernetes. Now I can say that this was the right decision. Or, even, the best thing that happened to my servers :). Of course, there were some problems during this period, but mostly because of some misconfiguration from my side. Also, there was no single downtime because of infrastructure. My original post was very long and compicated. Actually, even I don’t want to reproduce all of this stuff ever again.