Categories
Blog

How i built my own deployment and why – Part 1

This is a story about how i came in touch with cloud deployment and in the end built my own.In my previous time i learned a lot about application development and only rarely had to deal with deploying software or managing infrastructure. This story goes from Apache and “www-data” via kubernetes, netlify, heroku to self hosted. It usually includes docker.

Ok. So why did i build it myself? Initially i would have loved to deploy everything like i would if i was serious about production deployment but there is just no way i would pay ~100€ a month for a few websites or “petstore” services. I also wanted to be close to what i do at work: writing scaleable, reliable and maintainable applications and deploying them to the cloud. I’ll explain more about why i do it in the next part.

It all started a few years ago when Docker really took up the pace and you just could’t ignore it anymore. With docker everything (looking from a hosting perspective) is the same. It is the point where infrastructure ends and application starts.Intrigued by that i wanted to deploy my code like that. Soon after that Kubernetes was released to the public and minikube was THE tool to run it locally (or on a cloud instance in this case (so i thought)).

“Sounds great” i thought sice that would give me the opportunity to learn Kubernetes like a pro and still manage costs. You may already think that this is stupid since this setup implies there is a bare metal server, running a VM, running another VM (minikube), running Kubernetes pods, running my Docker containers. You’re right. But that did not stop me. Soon i discovered that its impossible since a VM requires kernel stuff that you simply dont get in a cloud VM instance.

I took a deep breath. My dream was shattered into a thousand pieces.

For a “minimum viable deployment” it seemed reasonable to deploy by hand using a ssh connection to the host and running my containers using `docker-compose up -d`. Together with nginx and Let’s encrypt this seemed like a solid setup for now. I simply exposed ports from the containers and and configured nginx to proxy to `localhost:8888` for example, do the SSL stuff, redirects, and loadbalancing.. Since cloud hosters usually have a configurable firewall around the Virtual Private Network (VPC) where the VM is hosted, i used that to limit connections to port 80(HTTP), 443(HTTPS) and 22(SSH).

Perfect, i thought to myself.

Of course there is a lot of manual work involved but at the pace i was working on my private software (and therefore my deployment as well) it felt good for now. As a general rule you should only automate work once you do it often enough manually and are getting annoyed by it.

Of course this wasn’t the end.

Categories
Blog

Hello this is blog.

Of course i had to start a blog again.

Luckily this time i already have a follow up post in mind.