Many software developers find learning about the entire software development life cycle to be interesting. If you’re beginning a startup, or just want a good development playground to host your projects, this tutorial will show you an easy way, using free and open source software, to host your apps in a stable, scalable, secure environment using Gitlab and Kubernetes. You will pay for the servers and hosting services, but will own the entire stack that your code goes through. The monthly cost comes out to ~$57/month. This setup is meant for development, but can be updated for production environments as well.
Eventually, as a developer, you’re going to want to deploy an application. To clarify: we’re generally talking about web applications here, but you can apply some of these principles to hosting native applications and related services as well.
There are many ways to deploy an application. The learning progression is usually:
Build and run your software locally
Learn how to set up a static server (usually Linux) that mimics your local computer to run the software on the web
Learn how to build, deploy, scale, and distribute your application automatically
We’re going to aim for #3 in this tutorial. We’ll go over the costs at the end when we understand the scope of our tool-set, but the goal here is to get an effective kubernetes infrastructure, on servers we manage, with the minimum associated costs necessary.
Kubernetes is a collection of software that has made managing app deployments much simpler. With kubernetes, the idea is that you create a cluster of servers, and applications can request / be deployed with those resources.
There are a lot of hands-on items involved when traditionally managing an application. You have to:
Kubernetes helps with all of this. Most cloud providers have easy ways to make a cluster out of many servers for you. You would start by creating a cluster that will have X resources. For example, 3 servers— 4gb memory and 2cpu’s each. We now have a pool of 12gb memory and 6cpu’s that we can request from. When we deploy our app, we specify how much of those resources we want for however many deployments of that app we want. We can even say we want 2 replicas of the deployment, and have a load balancer split the traffic between them to help the load. Kubernetes will auto-restart our deployment pods if there is an issue, since they are doing health checks along the way. There’s many reasons to use kubernetes, and there’s probably an equal or greater amount of reasons to not use them.
This Medium article by Anne LoVerso does a great job of a quick high level overview of kubernetes using an aquarium as an analogy.
Many people would rightfully say this is overkill for deploying a startup app idea. Please consider this more a learning experiment, and a possibility of deployment options to choose from. For many startups, a simple $5/month server sometimes is more than enough for what they are trying to achieve.
What we use for this tutorial
We’ll make an email account using Protonmail. This will give us an email like
We’ll buy a domain from Google. This is where we can buy whatever-we-want.com
We’re going to be using Digitalocean as our web hosting company (a company you can buy servers from), simply because we believe they have the easiest to understand interface for a tutorial like this.
The narrative will assume you are going from just purchased a brand new computer (that runs Ubuntu Linux 20.04), to hosting a simple web application over the net. We will host the code in our own Gitlab server, and deploy the app on our domain using a kubernetes cluster using gitlab auto-deploy.
Some quick things to do before we get started:
Once the prerequisites are out of the way, we need to create a server that contains nothing but Gitlab on it. This will be our home base. Gitlab offers a free community edition which comes with plenty of good features (including their auto-deploy feature which we will use to push our code to a Kubernetes cluster). We’re going to try and maximize how many cool features we can get out of this server, while keeping it simple. Here is a good list of features Gitlab CE comes with out of the box.
This setup is nice because the server is only using however much storage it takes for the repositories and gitlab applications, and storing all other data, including backups, artifacts, registry images, and more into S3 storage. With Digitalocean’s S3 storage, we can also browse the files in their control panel.
We need a server with a compatible OS on that list, with at least 4GB of memory, and 4 CPU cores could support up to 500 users. We’re going to choose a server with 4GB of memory, and 2 CPU cores since it will just be us working on the machine for now. Theoretically you could probably support a few more users, but eventually you should upgrade your server if you have many concurrent users.
Now that we have a free Gitlab CE edition running on our server, we can add a kubernetes cluster to it and start to deploy applications.
Over the years we’ve evolved how we work on software. Gitlab is nice because they have been using best practices for years to try to simplify many parts for you. Here’s a quick list of what we accomplished today.
We have our own traditionally managed server that has Gitlab CE installed (digitalocean droplet)
We have our own kubernetes cluster with 1 one node (server) that connects to our gitlab (digitalocean kubernetes cluster)
softwaredevelopmentgroup on gitlab (because we scoped our cluster to the group)
These articles don’t really cover the idea of multiple kubernetes clusters, which you would want if you’re deploying an application to production and want to separate it out from the other servers. Gitlab makes this easy though, as you’d just have to add a new cluster to the group the same way we did before, but set the scope to
production. On the production cluster, you could install everything shown above EXCEPT the Gitlab Runner. Then you could have your review cluster do all the work, and the production cluster only handling the app. That would be a good start to productionize this setup. Keep in mind, you will need a new loadbalancer for each cluster you have if you want to expose it to the public on a domain.
For now though, since we’re just playing around, we have a great area we can start working on projects in our own space with, and to bring friends along to show and share.
Here is a quick picture to demonstrate the architecture of what we accomplished.
Here is a table outlining our monthly expenses:
|Digitalocean droplet||$20||This is our traditional server we SSH into and installed Gitlab CE on|
|Digitalocean k8s cluster||$20||A single node DO made kubernetes cluster that holds our apps and the software that helps deploy them|
|Digitalocean loadbalancer||$10||After we install Ingress on our k8s cluster, kubernetes uses cloud provider checking to see where the cluster was made. Since digitalocean also has loadbalancers available, kubernetes used our cloud provider here to make the loadbalancer through digitalocean|
|Digitalocean spaces||$5||We uses DO’s S3 Spaces as our storage medium for gitlab configured components|
|Domain name (80pxtesting.com)||$1||Our domain costs $12/year so we added $1 to the monthly expenses for it|
|Digitalocean volume storage||$0.08||After we install Prometheus on our cluster, k8s looks for volume storage through the cloud provider and provisions a 8 GB volume storage and mounts it to our cluster|
Our total cost is ~$57/mo + taxes.
That should be a good stopping place for now. Thank you very much for reading. That was a lot, and we covered such a breadth of ideas. It would be impossible to list all of the concepts and features you get from this setup, but perhaps that will entice you to try it yourself and explore and learn. Feel free to leave a comment if you have any questions.