Well, as I promised the last time (a long, long time ago), let’s have a look at GCP’s external load balancer now. While sharing some features with internal load balancer, it has something unique as well:
- ELB meant to be accessed from outside, and “outside” is kind of global, so ELB will tend to use global and regional building blocks.
- It knows about existence of HTTP(S) and can use that knowledge to route traffic to more than one backend service, using URL as a map.
- It also acts as a proxy, so if e.g. SSL ELB is used, it will terminate SSL session way before traffic hits actual instances.
At the moment of writing GCP supports four breeds of ELBs: HTTP, HTTPS, SSL Proxy and TCP Proxy. The one which seems to be the most complex is HTTPS, so for today’s dissecting session let’s prefer that guy over the others.
Continue reading “Configuring External Load Balancer with Deployment Manager”
It’s interesting how some tools that try to look simpler and be more user friendly, actually make the things way more complex. Back in a day it was like this with the
git, when I had to read ‘Pro GIT’ book and switch to command line, so GUI clients finally started to make sense. It was then with Kubernetes, when it took switching to
kubectl apply and YAML configurations in order to make sense of
kubectl run and
And the same thing is now with GCP’s load balancers. Putting aside the question why there are so many of them, it’s really hard to see what they are made of. All these wizards and checkboxes completely hide the picture of what exactly those load balancers will be made of and why so. Continue reading “Configuring Internal Load Balancer with Deployment Manager”
I’ve been using Gitlab CI for a while now and until certain point it worked really well. We had three build servers (GitLab runners) in the beginning, and when number of teammates or build steps and therefore commits and build jobs increased, I’d just add one more server to handle an extra load and felt that problem was solved.
Not for long. When number of servers climbed to more than ten, it became obvious that simply adding servers one by one doesn’t work anymore. It was both expensive to have all of them running all the time and it still wasn’t enough to handle occasional spikes of commits. Not to mention that during the nights and weekends those servers were doing absolutely nothing.
The whole thing needs to be dynamic and fortunately GitLab CI supports autoscaling out of the box. Documentation is a little bit confusing but in reality it’s very easy to get started. So here’s the plan: let’s try it!
Continue reading “Autoscaling build servers with Gitlab CI”