Reading time: 4 minutes
One may ask why am I posting about technical stuff without proper technical details. Short answer is because I want to. These posts are short summaries of my life where IT takes a huge part of it. I like writing these posts as small essays and I will definitely post about something else at some point.
As per DevOps Adventure... there is one problem... as the time goes by, I am forgetting which specific challenges I was facing with my lab setup, so I have to admit, that if I would continue to spread it then with each chapter my content would have become slightly more boring than usual, so this Chapter is going to be the last one. But rest assured that the most challenging stuff was covered in the first 2 Chapters.
Next VMs I had to configure was VM2-GEN, VM3-LOW, VM4-HIGH and VM5-MISC.
It is a master node or control node or whatever you call it. It had to have the following:
Development environment, main machine holding my VS Code and self-hosted Git:
Production environment with Docker. Haven't actually properly utilized and had never gone public.
Actually I used this machine to run my blog at the time.
I have covered Portainer setup in Chapter 2. Here thing won't differ much except I had to just compose Portainer app on the VM2 and connect Portainer agent nodes to it from all other VMs except VM5. Being on the same subnet it wasn't hard to do, just some ClickOps stuff.
Semaphore is a GUI app for Ansible and many more. Essentially it's just a tool to run scripts on remote hosts via SSH (well, it was before...). Now it has grown to a standalone CI/CD tool, that can run e.g. Terraform. It was an easy thing to set up thanks to many tutorials you may find online, but it was also a bit of a dissapointment in the end, not the tool itself but the fact I didn't have a chance to actually use it. I was thinking about configuring simple tasks like running sudo apt update on each VM on schedule, but didn't make it in the end. Additionally Semaphore UI supports SSO, so I could easily configure it to be used with Authentik.
Same Traefik setup, nothing fancy, using the same compose file with some slight changes for each of the VMs. Obviously I had to add some changes to my DNS zone configuration, but this has been covered already.
This was fun. Gitea is actually a pretty lightweight self-hosted Git platform with many additional plugins you may use. You can configure CI/CD there as well, but I have never gone this far. Gitea also supports SSO with Authentik, so everything was working really smooth once things were configured.
And that was mostly it... I really liked to dig into networking issues I have had with this setup and it was way too fun to solve it, spending nights in front of the laptop after putting my kids to bed. Actually at that point I haven't yet had any LLM by my side, I was just cooking it the old-fashioned way. But the biggest help I got was from YouTube videos, man this is actually a one of a kind knowledge sharing platform, which is not yet obscured by the AI content the way blog articles are (mine are written by my "golden" hands with a lot of grammatical and lexical mistakes! not proud of mistakes, but the content is OG :D).
At some I point I will review my leftovers from this lab. I have saved most of my config files, compose files etc. So probably at some point I will just create a public GitHub repo to have it all in one place and share it with you.
P. S. Folks, never forget to install simplest intrusion prevention tools when you are using cloud services. Cloud provider IPs are known to the whole world, so any time you start a new VM keep in mind that it's already probed by malware makers, cred takers and botnet lovers <3 ("#nohate"). Simple tools like fail2ban will definitely make your life easier. And better use key log in for your SSH connection, that's also way more safer than password.
Be curios, proactive and safe!
BR,
Ed