test

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.

Intro

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:

  1. Build and run your software locally

    • A folder on your computer contains your source code
  2. Learn how to set up a static server (usually Linux) that mimics your local computer to run the software on the web

    • Your source code is potentially in a repository
    • May involve paying for a domain name (around $12 / year for the domain)
    • May involve paying for a small server (around $5 / month for a small server)
    • May involve some level of automation (you change the code, do something, and your server is updated with the new code)
  3. Learn how to build, deploy, scale, and distribute your application automatically

    • Your source code is in a repository, and contains information on how to build and deploy your app (And anything else you want to do with your code either before or after deploying)
    • Part of this could involve paying for a domain name, and paying for the associated costs from a web hosting company for things like kubernetes, load balancers, S3 storage, etc.
    • Your cost starts to depends on what features you have

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:

  • Create a server with your hosting provider
  • Configure it
  • Deploy your app on it
  • Create https certificates if you want them
  • Restart the server if there is an issue
  • Many more hidden hands-on items

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.

Disclaimer

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 ourusername@protonmail.com.

  • We are not affiliated with Protonmail

We’ll buy a domain from Google. This is where we can buy whatever-we-want.com

  • We are not affiliated with Google

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.

  • We are not affiliated with Digitalocean, but if you would like to use them, and support us, please use this referral link. Thanks!

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.

Prerequisites

Some quick things to do before we get started:

  1. Create a Protonmail email account
  2. Make an SSH key
  3. Buy a domain with Google domains
  4. Create a Digitalocean account

Create and configure Gitlab Community Edition

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.

  • Gitlab
  • Mattermost (Open source slack-like chat)
  • Docker registry

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.

The minimum requirements for Gitlab are here.

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.

  1. Let’s create a basic Ubuntu server using Digitalocean and set it up
  2. Create a Digitalocean Spaces service and create an API key for it for Gitlab
  3. Install Gitlab on our new server and configure it

Create a Kubernetes cluster and deploy an application to it from Gitlab

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.

  1. Create a kubernetes cluster in Digitalocean
  2. Connect a Digitalocean kubernetes cluster to gitlab
  3. Deploy an application on our Digitalocean kubernetes cluster

Final thoughts

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)

    • On it’s own this is massive… We now have a place to manage our projects, repositories, issues, groups, packages, and so much more
    • We made our own Digitalocean Spaces S3 storage and use it for nearly every configurable area on the Gitlab server
    • We also installed the included slack-like chat called Mattermost, so when we build our team we have an area on our own infrastructure to communicate
    • We also installed the included Docker registry to store our docker images
  • We have our own kubernetes cluster with 1 one node (server) that connects to our gitlab (digitalocean kubernetes cluster)

    • We can now deploy apps in our softwaredevelopment group on gitlab (because we scoped our cluster to the group)
    • We installed a Cert Manager that uses Let’s Encrypt to automatically handle our HTTPS certificates
    • We installed Ingress that added a Load Balancer to our account to help direct traffic from our domains to our kubernetes deployments (digitalocean loadbalancer)
    • We installed Prometheus so we can monitor our deployed applications (digitalocean volume storage for monitor logs)
    • We installed Gitlab Runner to help build and ship our applications

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.

80px testing architecture

Here is a table outlining our monthly expenses:

Product $/mo Description
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.

Quick pros:

  • We have a single control panel to add/remove/modify any of the settings and services related to our architecture. (The digitalocean web control panel)
  • We can deploy any app on servers we manage using kubernetes and gitlab
  • We have a lot of tools during our app development life cycle to help us debug, test, build, release, and much more to improve our codebase
  • Many areas to learn and explore and make work for your development flow

Quick cons:

  • $57/mo is expensive
  • There are a fair amount of assumptions and learning you must do to feel comfortable with this setup (hopefully this article helps!)
  • You can incur unknown charges if you don’t understand how kubernetes uses a cloud provider to request provisioning additional services

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.