Day 1: The Static Foundation - Automating Hugo Like a Pro

The first step in the 100-day DevOps and Solution Architecture journey, is learning how to build and deploy static websites with a simple continous integration and continuous CI/CD pipeline in bash. Most Developers never launched a single website or managed a basic VPS in their entire careers. This is concerning.

I’ve been coding for 20 years so I’ve seen the web cycle through endless bloat HTML 3, HTML 4, Flash, and now JavaScript bloat. For this project, I’m returning to the most efficient stack possible. Static sites with Hugo. (Video walkthrough available)

Why Hugo?

Hugo is a static site generator written in Go. It’s a single binary you can copy and paste around. THis means no need for any dependencies, no npm install hell, no broken dependencies, and zero maintenance. Plug and play ready. It’s perfect for documentation, blogs, and even commercial sites that need to be lightning fast. If you deploy a site with Hugo it’s going to be almost 100% secure (unless you manage to somehow add a NPM cryptobot to your local environment :facepalm:)

It has image processing built in (convert, resize, crop, rotate, filters). Javascript bundling (tree shaking, code splitting), sass processing and also tailwindcss. Contains a built in embedded web server for local development. Everything in one single binary.

If you’re a software developer or devops engineer chances are at one point in your life that you will need to build a site for yourself, someone else, a project you’re passionate about or just a documentation for a work project. Hugo is perfect for this job. It renders a static site from markdown or asciidoctor content (but it’s configurable to other formats aswell). COnfiguration is done with TOML or YAML which is the default DevOps configuration nowadays. So by using it you’lll most likely have shareable skills.

With jamstack you can easily add a headless cms or basic web shop to extend hugo and add dynamic features to it. Adding a hugo repository to git or fossil and a CI/CD pipeline can simplify content creation.

What You will accomplished today:

Initialize the site using the Relearn theme, which provides the professional “Technical Wiki” feel I want for this journey. You’ll learn how to set hugo up, experiment with it and as a bonus I’ll give you a simple CI/CD bash script to take your hugo output and publish it as a static site. We’ll cover the details of setting a Linux virtual private server for your website in future days;). For now stick to the basics.

Download hugo and place it in your $PATH.

1. Site Initialization:

hugo new site fullstackdevops.eu
cd fullstackdevops.eu
hugo mod init fullstackdevops.eu

What the above does is create a new directory and initialize hugo modules. So it can automatically fetch the layout template from github in the next step, otherwise you’d have to manually download and copy it to the layouts folder. Which you can do as an exercise, using git submodules as layouts is also a good way to get the newest version of a layout template. Feel free to change the site name to something of your own;)

There is a plethora of documentation out there on how to configure and use hugo, I’m not going to go into the details. There are even some books on this

2. Configuration (hugo.toml):

I’m using Hugo Modules to manage the theme. It keeps the repository clean.

baseURL = 'https://fullstackdevops.eu/'
languageCode = 'en-us'
title = 'Full Stack DevOps'

[module]
  [[module.imports]]
    path = 'github.com/McShelby/hugo-theme-relearn'

3. The Magic CI/CD Deployment PipeLine using Bash

Most people spend hours fighting GitHub Actions or complex CI/CD pipelines doing over engineering. I spent 5 minutes writing a Bash script which acts as a basic CI/CD pipeline. It’s fast, reproducible, and requires zero external dependencies.

This script builds the site, minifies the assets, tars the public folder, and ships it via SCP to a virtual private server (VPS)virtual machine on any cloud.

It uses basic unix and linux tools which are available by default on any linux distribution. These tools have existed for the past 30 years and will continue to exist in 30 or more. (ssh, scp, tar etc;).

build.sh

#!/usr/bin/env bash

# Build the site with garbage collection and asset minification on
hugo --gc --minify

# Package the public output folder as a gzipped tar - you can use lz4 or whatever yo uwant
tar -czvf fullstackdevops.eu.tar.gz public

# Ship it to the VPS (Custom SSH port for security)
scp -P 2327 fullstackdevops.eu.tar.gz fullstackdevops:~/

# Remote extraction into the web root
ssh fullstackdevops "tar --strip-components=1 -xf fullstackdevops.eu.tar.gz -C /var/www/fullstackdevops.eu"

Whenever I make any change in markdown I just run ./build.sh and the site is built and automatically updated;).

The Secret Sauce: SSH Config

To make the script above work, I use a simple ~/.ssh/config entry. This keeps my credentials and port settings out of the script and in my local environment where they belong. We will explore setting up SSH in future days;). If you don’t have SSH setup it will ask for a password, however, in my case, it will automatically work with no password.

Host fullstackdevops
  Hostname fullstackdevops.eu
  User youruser 
  Port 2233

Video Walkthrough

If you want to see exactly how I set this up and why I prefer this “Lean CI/CD” approach, check out my full video tutorial:

Automate Your Hugo Static Site Like a Pro CI/CD Made EASY

What’s Next?

Now that the “Press Release” platform is live, Day 2 begins. In the next days we’ll dive into the “Art of Writing”, setting up the Local Homelab, Using virtualbox and then going on to real virtualization used by big cloud providers with KVM and libvirt;).

Getting hugo up and running on public world facing Linux server involves some extra steps not yet discussed here( some of them are explained in the video referenced above), which if you’re new might seem overwhelming. STOP don’t jump for an API or cloud service, you CAN and will do these manually, start with the easiest of all. Static hosting then a VPS!

In future days I’ll show you how:

1. to setup your own Linux VPS - The above example expects thi
2. Install, configure and use caddy as a reverse proxy and static site hosting
3. Using SSH keys to login and automatically allow scp/ssh towork
4. Many more features

Security note

In enterprise reality we might add code review and a git hook or even IAM roles. Ssh key would not be given freely to developers for production access. But those steps can and will be easily automated in future days :-).
Enterprise vision and best practices are not always followed even in larger companies. (I’ve seen this!)

We want to follow the devops and agile mantra’s of working in iteration

Follow the journey at fullstackdevops.eu

Day 2: The Art of Writing - DevOps FullStack Secrets

Writing is an integral important part of what we do in the modern world and more so in the complex DevOps or Full Stack Development world. Indifferent if you’re a software engineer writing code or a devops engineer writing bash or terraform automation scripts. You’re writing. All the time. Writing is a form of communication we need and do on a daily basis; SMS, emails, documentation, executive summaries for management or explaining ideas to non technical customers . As any skill, writing improves with practice.

Writing is Thinking

Writing is thinking and writing WILL help you organize your thoughts and ideas. And writing helps us organize our memory. There’s ample research stating that writing IS one of the best psychotherapy emotional processing tool out there ¹ I know there’s a preconception of programmers and IT people being introverted and lacking intrapersonal communication skills. It doesn’t have to be that way. As you’ve mastered your craft, you too can master the art of communication.

Make your work visible

Most of the tech work we do is invisible and unknown to others (managers, colleagues, etc). Writing about it helps us document the steps we’ve taken. Writing improves our retention and understanding. It will also give you a chance to explain WHY an idea is good or bad. If you’re like me you may solve tens to hundreds of different problems a day. I used to document only the most complex problems. It’s very liberating when we can go back to our notes on a daily basis for things we’ve solved before or just to review ideas and solutions. In reality, we should aim to document anything which takes more than 5 minutes to solve. Take the time to document and write down the problems you had and how you solved them. Your our future self will thank you. And so will other people, How do you think the internet works?

Brain Overload - Externalize information through writing - Building a Second Brain

We can’t store everything in our brain. This is why it’s much more important to be able to know and be able to solve a problem than to learn a manual entry by heart but being unable to use it.

Afraid of sharing your writing? Thinking that it’s not that good? No need for perfection. 3 steps to success

1. just write everything down as in a brain dump without worrying about grammar, logic, order. Just write what comes to your mind ignoring your critical self. Keep it in a draft. Let it incubate, and come back later. 1 day later is perfect.
2. Read it, edit it and iterate as many times a you want. THe more you EDIT the better it becomes. The more you will train yourself to remove excess the more succint you can become. At the beginning you will probably write 3 A4 pages for an idea and then summarize it down to 1 A4 page.
3. AI atrophies your brain- You loose valuable creativity, thinking, memory and communication skills.. Don’t use AI unless you want to brainstorm or want to gather intel on how to present an idea to stakeholders but already provided it with a lot of ideas. Always use your OWN brain and thoughts. Instead of externalizing your thinking, you build valuable skills. Becoming irreplaceable. Your brain is accumulating cognitive debd when using AI assistants which impact creativity, critical thinking, memory and communication skills². All essential to succeed in life.

Do the above steps even if you never publish anything and decide to keep your documentation local.

Book Recommendations

I’d recommend reading 3 distinct books to get an idea of how to actually get things done by taking notes. You may also want to take hand notes instead of going 100% in the technology route;). Your hand brain pathways will thank you.

• Bullet journal method by Ryder Carroll
• How to take smart notes by Sonke Ahrens
• GTD getting things done by David Allen

Mix and match ideas and build your own system. Most important of all, keep it simple. Don’t overcomplicate. Interconnect your notes. It will take time but the results will be great.

I made a promise to myself to write more and I kept it, even if I didn’t publish most of what I wrote, I have more than 3000 A4 pages worth of notes and writing.

There is no perfect note taking app, just start taking notes

Start with Zim Desktop Wiki, it has everything you need. Yes, you can export to markdown,html, pdf. And you can collaborate with other technical people through git or fossil scm.

You can experiment with SilverBullet, VSCode + Foam(keeping this locally), or Vim/Neovim.

One pitfall is to try to search for the perfect note taking app. Please don’t start migrating your notes and going from one app to another. Don’t get caught up in the zettlekasten knowledge management trap either. All apps have pro’s and con’s.

I’ve been there and you will spend more time fiddling around making a system work for you instead of taking notes. This is not healthy nor sustainable I’ve actually built my own notes sytem twice and used things like vim and tens of different software.

You can use [hugo static site generator for documentation]((https://andreiclinciu.net/article/tech/hugo-golang-simplicity/), we talked about Hugo yesteday and even notes or something as simple as Fossil SCM + wiki

If you plan to collaborate with other non technical people then you might want to take a look into Wiki Go or usememos (not the react hook, the golang notes app)

I strongly recommend Zim Wiki or SilverBullet (which is programable)

Plaintext is the best format to use for documentation and notes

The best file format to use when writing ideas is not html, not some private binary format, nor word docx/odt. Keep it in plaintext.

Plaintext will be readable in 100 years, while we don’t know if binary formats will still work then.

There are quite some plaintext options including markdown, asciidoctor, html, etc.

Asciidoctor provides many extensions which are lacking in markdown.
It’s supported by github by default, it’s used to build books PDF’s and epub’s, you can template and design it. There’s even a presentation module with revealjs for asciidoctor. Even if you don’t use asciidoctor, keep your notes in markdown or a variant which will work on any device while used in any source control management system like Git or Fossil SCM.

Start Writing NOW

Download Zim Wiki or open any editor and start writing in asciidoctor or markdown NOW.

Tomorrow you’ll get started with Virtualbox Virtualizing Linux

Day 3: The Gateway to Linux - VirtualBox Virtualization & Beyond

If you want to master DevOps, you must first master Virtualization and Linux. It is the absolute backbone of everything we do—from the smallest local lab to the massive clusters at AWS and GCP.

Today, we are looking at the best entry point for anyone starting this journey: Oracle VirtualBox. (Formerly known as Sun Microsystems VirtualBox)

Why VirtualBox?

Oracle VirtualBox is fantastic for beginners. It’s a Type-2 hypervisor, meaning it runs on top of your existing Windows, Mac, or Linux OS. It’s the perfect “sandbox” where you can break things, delete partitions, and mess up configuration files without any risk to your host system. This is the FIRST step before actually installing Linux on a live system either as the sole or dual boot system.

There is no shame in using VirtualBox. Even as a Senior, I’ve used VirtualBox extensively up untill 5 years ago when I finally switched 100% to using LibVirt and KVM for all my virtualization needs. I appreciate its simplicity for quick tests and recommend it to complete beginners. It even supports:

• Terraform Providers: You can test out your terraform scripts!
• Vagrant Integration: For reproducible development environments.
• Snapshots: Take a snapshot in time of your virtual machine and the “magic” “Undo” button for your mistakes.

🎥 Tutorial: Try Linux WITHOUT Deleting Windows

The most important aspect in DevOps is learning and using Linux and Unix. If you’ve only used Windows or MacOS then experiment 1 month with using exclusively Linux in virtualbox in fullscreen. Meaning you

I’ve recorded a complete, step-by-step guide on how to get started. I recommend using Debian or Linux Mint (great for beginners) and I explain the “Why” behind virtual machines—from security to privacy.

What you’ll learn in the video:

• [00:00:13] What are VMs? Understanding how they slice your CPU and RAM.
• [00:01:25] Safety & Security: Using VMs to browse safely or test untrusted code.
• [00:02:39] Choosing a Distro: Why I recommend Linux Mint or Debian for starters.
• [00:05:56] Installation: Setting up your first VDI (Virtual Disk Image) and installing Linux.
• [00:12:19] Guest Additions: How to enable full screen and shared clipboards between your host and guest.

🚀 The “Unicorn” Path: Moving to KVM and Libvirt

While VirtualBox is a great teacher, “real world” production virtualization on Linux usually happens at a deeper level.

If you look under the hood of the world’s biggest clouds, you won’t find VirtualBox. You’ll find KVM (Kernel-based Virtual Machine) and Libvirt.

• Performance: It runs at near-native speeds because it’s part of the Linux kernel.
• Industry Standard: This is the tech that powers the modern internet.

Next up in the 100-Day Challenge: We are going to “level up.” I’ll show you how to set up KVM and Libvirt on Linux (day 5) to build a professional-grade private cloud 004-homelab-infrastructure)](003-homelab-infrastructure)

Homework: Follow the video, install a Linux VM (I recommend Debian), and try to navigate the terminal. If you’re feeling brave, try installing Whonix for ultimate privacy as I mentioned at [00:14:34]!

Find more guides and join the discussion at fullstackdevops.eu.