This happened randomly. Sometimes after a few hours, sometimes after a few days. I couldn't find a pattern. I checked RAM, disk, GPU, drivers, Docker, everything. All looked fine.

Turns out the problem was my CPU eating too much power. And the fix was literally one command.

Some Background

My server runs on an Intel i9-14900K with a Gigabyte motherboard and an NVIDIA RTX 4090. It handles PostgreSQL, Docker containers, Python scripts, and some web scraping workers. Nothing crazy. But every now and then, when multiple things run at the same time, the whole system just freezes.

No logs. No crash dump. No kernel panic. Just dead.

What Are PL1 and PL2?

Every Intel CPU has two power limits built in. Think of them as rules that tell the CPU how much electricity it's allowed to use.

PL1 (Power Limit 1) is the long-term limit. This is how much power the CPU can use continuously. All day, every day. Intel says for the i9-14900K, this should be 125 watts.

PL2 (Power Limit 2) is the short-term boost limit. When you suddenly need more power (compiling code, running heavy queries), the CPU is allowed to jump up to PL2 for a few seconds temporarily. Intel says this should be 253 watts. After a short burst, it must return to PL1.

So the normal behavior should look like this:

Normal load:    30W ... 50W ... 40W ... 60W
Sudden spike:   30W ... 50W ... 253W! ... 253W! ... back to 125W ... 60W ... 40W
                                ^^^^^^^^^^^^^^^^^^^^
                                PL2 boost (few seconds only)

The CPU goes fast when needed, then calms down. That's healthy.

What Was Wrong on My Server?

I checked my power limits with these commands:

PL1=$(cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw)
echo "PL1: $((PL1 / 1000000))W"

PL2=$(cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw)
echo "PL2: $((PL2 / 1000000))W"

Result:

PL1: 253W
PL2: 253W

Both set to 253W. That means there is no "calm down" phase. The CPU is allowed to pull 253 watts forever if the workload demands it. No speed limit. Full power all the time.

This is a known issue with Gigabyte motherboards (and ASUS, MSI too). They ship with power limits set to maximum by default. Why? Because higher power means higher benchmark scores. Looks great in reviews. Not so great for stability.

Why This Causes Freezes

Imagine a water pipe rated for 125 liters per minute. Someone removed the limit and now 253 liters can flow through it. Most of the time you only use 10-20 liters, so nothing happens. But when many taps open at once, 253 liters rush through. The pipe can't handle the pressure and bursts.

Same thing with the CPU. At idle, my server uses about 2-3 watts. Normal workload is maybe 30-60 watts. No problem. But when PostgreSQL runs a heavy query while Docker containers are scraping websites and Python scripts are processing data, all at once, the CPU pulls 200+ watts sustained. The chip gets extremely hot, the motherboard power delivery gets stressed, and the whole system locks up.

Intel actually acknowledged this problem for 13th and 14th gen CPUs. They released microcode updates and told everyone to set PL1 back to 125W. Many people were having crashes and didn't know why.

The Fix

Step 1: Check your current power limits

PL1=$(cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw)
echo "PL1: $((PL1 / 1000000))W"

PL2=$(cat /sys/class/powercap/intel-rapl:0/constraint_1_power_limit_uw)
echo "PL2: $((PL2 / 1000000))W"

If PL1 shows anything above 125W, that's your problem.

Step 2: Fix it right now (instant, no reboot)

echo 125000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw

That's it. One command. PL1 is now 125W. Your CPU will still boost to 253W for short bursts (PL2), but it won't stay there. It will always come back down to 125W.

Step 3: Verify it worked

PL1=$(cat /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw)
echo "PL1: $((PL1 / 1000000))W"

Should now show 125W.

Step 4: Make it permanent

The command above resets on reboot. You have two options to make it stick.

Option A: Fix in BIOS (recommended)

Reboot, enter BIOS (usually Del or F2 on Gigabyte boards), and look for one of these:

• "Package Power Limit 1" or "PL1"

• "Long Duration Power Limit"

• Usually under "Tweaker" or "Advanced CPU Settings"

Set it to 125. Save and exit.

Option B: Set it automatically on every boot

Create a systemd service:

sudo bash -c 'cat > /etc/systemd/system/cpu-power-limit.service << EOF
[Unit]
Description=Set CPU PL1 Power Limit to 125W
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/bash -c "echo 125000000 > /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw"

[Install]
WantedBy=multi-user.target
EOF'

sudo systemctl enable cpu-power-limit.service

Now every time the server boots, PL1 gets set to 125W automatically.

Step 5: Keep Intel microcode updated

Intel released microcode patches specifically for this issue. Make sure it's installed and won't get auto-removed:

sudo apt install intel-microcode
sudo apt-mark manual intel-microcode

Will This Make My Server Slower?

No. My server uses 2-3 watts at idle and maybe 30-60 watts during normal work. The 125W limit is more than double what I normally use. The only thing that changes is the CPU can't sustain 253W for minutes at a time anymore. For a server running databases and containers, you will never notice the difference.

Quick Summary

Server kept freezing randomly. No errors, no logs, just dead. Turned out the motherboard had CPU power limits set way too high (253W sustained instead of Intel's recommended 125W). Under heavy load, the CPU would pull too much power for too long and the system would lock up.

Fixed it with one command:

echo 125000000 | sudo tee /sys/class/powercap/intel-rapl:0/constraint_0_power_limit_uw

Then made it permanent in BIOS.

If you have a 13th or 14th gen Intel CPU and your system freezes randomly, check your PL1. There's a good chance your motherboard set it way too high.

Thanks!

Happy Debugging!!😀

Moral of the story: sometimes the fix isn't in the software. Sometimes your motherboard is just being too generous with the power, and your CPU doesn't know when to stop.

I pressed the power button on our office’s Ubuntu server. Fans started spinning. CPU light turned on. Everything sounded normal. But the monitor? Completely black. Nothing. Not even the BIOS screen showed up.

Great. Just great.

First Problem: No Display At All

Okay, so picture this. The machine is ON. I can hear it running. I can even see the CPU running (due to the awesome-looking LEDs😁). But the screen shows absolutely nothing. Not a single pixel.

I got scared. I thought the motherboard was dead. It's a Gigabyte board, and well... Gigabyte can be dramatic sometimes.

I tried everything. Different monitor, different cables, different ports. Nothing worked.

Then I thought, let me just leave it alone for a bit. Sometimes electronics just need a break. Like me.

So here's what I did:

1. Turned it off completely

2. Unplugged the power cable from the wall

3. Held the power button for 20 seconds (this drains leftover charge from the board)

4. Went to the washroom for a nature call

5. Came back after 30 minutes

Plugged it back in. Pressed power.

Display came on. Just like that.

I know it sounds like magic but it's actually a real thing. Motherboards hold residual charge in their capacitors. Sometimes that charge gets stuck in a weird state and the board refuses to POST. Draining it fully resets everything.

Okay cool. Hardware is alive. But...

Second Problem: Kernel Panic

Instead of my normal login screen, I got this:

KERNEL PANIC!
Please reboot your computer.
VFS: Unable to mount root fs on unknown-block(0,0)

For those who haven't seen this before, this is basically the Linux kernel saying "I woke up and I have no idea where the hard drive is. I give up."

That unknown-block(0,0) part means the kernel can't find ANY disk. Not because the disk is broken. But because it doesn't have the right drivers loaded to see the disk. The initramfs (a tiny filesystem that loads first and contains these drivers) was either missing or broken.

The Save: Booting an Older Kernel

Here's something beautiful about Ubuntu. It keeps your old kernels in the boot menu. So even when the latest one breaks, you can go back.

I rebooted, held Shift to open the GRUB menu, picked Advanced options, and selected the previous kernel.

It booted perfectly. Everything was fine.

So the disk was fine. Ubuntu was fine. It was just the new kernel that was broken.

Now I needed to find out why.

The Investigation

First thing I checked. What kernels are installed?

dpkg --list | grep linux-image

And I spotted it immediately:

ii  linux-image-6.14.0-37-generic    ...   (working kernel)
iF  linux-image-6.17.0-14-generic    ...   (broken kernel)

See that iF? The i means installed. The F means Failed to configure. The kernel package was downloaded and placed on the system, but something went wrong during setup. The initramfs was never built properly. That's why the kernel couldn't find the disk.

But what caused the failure?

The Root Cause: NVIDIA Said No

I ran this to try and fix things:

sudo apt --fix-broken install

And the error told me everything:

Error! Bad return status for module build on kernel: 6.17.0-14-generic
dkms autoinstall on 6.17.0-14-generic/x86_64 failed for nvidia(10)

There it is. My NVIDIA driver (version 575) could not compile against kernel 6.17. When Ubuntu installs a new kernel, it uses DKMS to rebuild all third-party drivers (like NVIDIA) for that kernel. NVIDIA's build failed. That failure broke the entire kernel installation chain. And that left me with a kernel that was half-installed and couldn't boot.

This is actually super common. Ubuntu's HWE (Hardware Enablement) kernels move fast. NVIDIA drivers don't always keep up. The new kernel lands, NVIDIA can't build against it, and boom, broken boot.

The Fix

Since this is a server, I don't need the bleeding edge kernel. Stability matters more. So the plan was simple. Remove the broken 6.17 kernel and stick with 6.14 which works perfectly.

But there was a small headache. Dependency chain. Package A depends on Package B which depends on Package C. You can't just remove one. You have to go in order.

The trick is to remove the meta-packages first, then the actual kernel:

# This one goes first. Breaks the dependency chain
sudo dpkg --force-remove-reinstreq --purge linux-generic-hwe-24.04

# Now these will work
sudo dpkg --force-remove-reinstreq --purge linux-headers-generic-hwe-24.04
sudo dpkg --force-remove-reinstreq --purge linux-image-generic-hwe-24.04
sudo dpkg --force-remove-reinstreq --purge linux-headers-6.17.0-14-generic
sudo dpkg --force-remove-reinstreq --purge linux-image-6.17.0-14-generic

Then clean up:

# Fix any leftover broken state
sudo apt --fix-broken install

# Remove old kernel configs that are just sitting around
dpkg --list | grep "^rc" | awk '{print $2}' | xargs sudo dpkg --purge

# Update the boot menu
sudo update-grub

And one more important step. Stop Ubuntu from pulling kernel 6.17 again on the next update:

sudo apt-mark hold linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04 linux-generic-hwe-24.04

Reboot. Clean boot. Everything works. Server is back.

Later, when NVIDIA releases a driver that supports kernel 6.17, I can unhold and upgrade:

sudo apt-mark unhold linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04 linux-generic-hwe-24.04
sudo apt upgrade

Things I Want You to Remember

Always keep at least two kernels. Ubuntu does this by default. Don't mess with it. That old kernel is your backup plan when things go wrong.

Learn the GRUB menu. Hold Shift during boot. It lets you pick which kernel to boot. This one trick has saved me more times than I can count.

NVIDIA and new kernels don't always get along. On a server, ask yourself. Do I really need the latest HWE kernel? If not, stick with what works.

Know your dpkg flags.

ii  = Installed and configured (all good)
iF  = Installed but FAILED to configure (this is your problem)
rc  = Removed but config files still there (needs cleanup)

unknown-block(0,0) is not a dead disk. It means the kernel doesn't have the drivers to see your disk. The initramfs is broken. Boot an older kernel and fix it from there.

The power drain trick works. No display at all? Unplug everything, hold the power button for 20 seconds, wait a while. It's not broscience. Capacitors really do hold charge that can cause weird behavior.

Quick Summary

Server wouldn't start. No display, fixed by draining power and waiting. Then Then kernel panic, caused by NVIDIA driver failing to build against kernel 6.17. Fixed by booting older kernel from GRUB, removing the broken kernel packages, and holding HWE updates until NVIDIA catches up.

Day well spent? Debatable. But hey, at least the server is running and I got a blog post out of it.

Tyastai haina ra?(Nepali😁) You always learn the most when things break.

If you hit something similar, hope this saves you some hours. And no, reinstalling Ubuntu is never the answer (I’ve done that a lot). I don't do that here. I debug.

$ tail -f /var/log/auth.log
Jan 18 10:23:45 server sshd: Failed password for invalid user admin from 185.234.x.x
Jan 18 10:23:47 server sshd: Failed password for root from 103.45.x.x
Jan 18 10:23:48 server sshd: Failed password for invalid user test from 45.227.x.x

Now, I use key-based authentication, so these bots weren't getting in. But still, watching strangers knock on your door all day is not fun. So I went down a rabbit hole and found this old-school technique called port knocking.

Honestly, it felt like something from a spy movie. And it really works.

So What is Port Knocking?

Imagine your server is like a hidden bar during prohibition. The door looks just like a regular wall with no signs or handles. But if you knock in a secret pattern - three knocks, pause, two knocks - the door suddenly appears and lets you in.

That's port knocking.

Your SSH port stays closed. Completely invisible to anyone scanning. But when you knock on a secret sequence of ports in the right order, the firewall opens SSH just for your IP.

1. You knock on port 7777
2. You knock on port 8888  
3. You knock on port 9999
4. Server goes "ah, it's you!" and opens SSH
5. You connect normally
6. When done, knock the reverse sequence to close it again

A little daemon called knockd listens for these patterns. When it sees the right sequence from your IP, it runs an iptables command to let you through. Everyone else just sees a closed port.

Let's Set It Up

I'm on Ubuntu, but this works on most Linux distributions with iptables. You'll need sudo access and ideally a cup of tea/coffee/lemon-tea (not any other beverage😁) because we're doing this step by step.

Prerequisites

Before we dive in, make sure you have:

• A Linux server (Ubuntu/Debian preferred, but any distro with iptables works)

• Sudo or root access

• SSH access to your server (obviously)

• A second terminal is ready (trust me on this one)

• Console access from your cloud provider as backup ( AWS, DigitalOcean, GCP, Vultr - they all have it)

That last point is important. If something goes wrong and you lock yourself out, console access is your "break glass in case of emergency" option. Don't skip setting this up.

Alright, let's do this.

Step 1: Move SSH to a Different Port

First things first. Let's get SSH off port 22. Every bot and their grandfather scans port 22. And here we're gonna be moving to a non-standard port.

sudo vim /etc/ssh/sshd_config

Find the Port line and change it:

# Change this
#Port 22

# To this
Port 13022

Why 13022? The 13th is my birthday date, unlucky for attackers, and 022 reminds me it's SSH. Pick whatever you like, just avoid obvious ones like 2222, 22222, etc.

Restart SSH:

sudo systemctl restart sshd

Now here's the important part. Don't close your current session. Open a new terminal and test:

ssh -p 13022 user@your-server-ip

If you can connect, great. If not, you still have your old session to fix things. Don't skip this step, or you might lock yourself out. Ask me how I know😞.

Step 2: Install knockd

sudo apt update
sudo apt install knockd -y

Step 3: Configure the Knock Sequence

Open the config:

sudo vim /etc/knockd.conf

Replace everything with:

[options]
    UseSyslog
    LogFile = /var/log/knockd.log

[openSSH]
    sequence    = 7777,8888,9999
    seq_timeout = 10
    command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 13022 -j ACCEPT
    tcpflags    = syn

[closeSSH]
    sequence    = 9999,8888,7777
    seq_timeout = 10
    command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 13022 -j ACCEPT
    tcpflags    = syn

Quick breakdown:

• sequence - your secret knock pattern

• seq_timeout - you have 10 seconds to complete the knock

• command - the iptables magic that runs when you knock correctly

• %IP% - automatically replaced with your IP

• tcpflags = syn - only listens for connection attempts

I'm using 7777, 8888, 9999 for this tutorial. For your actual server, pick something less obvious. Maybe your lucky numbers or a birthday. Just don't use 1234, 5678 - you get the idea.

Step 4: Tell knockd to Actually Start

By default, knockd is installed but disabled. Let's fix that:

sudo vim /etc/default/knockd

Change these:

START_KNOCKD=1
KNOCKD_OPTS="-i eth0"

For the interface name, check yours:

ip addr show

Look for the one with your public IP. Usually eth0 or ens3 or something similar.

Fire it up:

sudo systemctl start knockd
sudo systemctl enable knockd

Step 5: Lock the Door

Now the fun part. We block SSH by default, so only the knock can open it.

If you're using UFW, disable it first:

sudo ufw disable

We're using raw iptables here. You can also use the UFW command as explained here - Link.

# This keeps your current session alive - very important!
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow localhost
sudo iptables -A INPUT -i lo -j ACCEPT

# Block SSH by default
sudo iptables -A INPUT -p tcp --dport 13022 -j REJECT

# Save the rules so they survive reboot
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

That first rule is crucial. It tells iptables "don't kill existing connections." Without it, running the block rule would kick you out immediately. Not fun, SED LIFE!.

Do not close your current SSH session yet. Keep it open as a safety net while you test.

Testing Time

On your local machine, install the knock client:

# Ubuntu/Debian
sudo apt install knockd

# macOS
brew install knock

First, let's confirm the port is actually blocked:

ssh -p 13022 user@your-server-ip

You should get "Connection refused." Good. The door is locked.

Now perform the secret knock:

knock -v your-server-ip 7777 8888 9999

You'll see:

hitting tcp your-server-ip:7777
hitting tcp your-server-ip:8888
hitting tcp your-server-ip:9999

Quickly connect:

ssh -p 13022 user@your-server-ip

And you're in.

When you're done, close the door behind you:

knock -v your-server-ip 9999 8888 7777

Notice the reverse order. 9999, 8888, 7777. That's your "close" sequence.

No knock client? Telnet works too

telnet your-server-ip 7777
# Ctrl+C
telnet your-server-ip 8888
# Ctrl+C
telnet your-server-ip 9999
# Ctrl+C

You'll see "Connection refused" each time, but that's fine. The knock packets still get sent.

Making Life Easier with a Script

Typing the knock command every time gets old fast. Here's a simple script:

#!/bin/bash
# knock-ssh.sh

SERVER="your-server-ip"
SSH_PORT="13022"
USER="your-username"

echo "Performing secret knock..."
knock $SERVER 7777 8888 9999

sleep 1

echo "Opening the door..."
ssh -p $SSH_PORT $USER@$SERVER

echo "Closing the door..."
knock $SERVER 9999 8888 7777

Save it, make it executable:

chmod +x knock-ssh.sh
./knock-ssh.sh

One command to rule them all.

Watching the Magic Happen

Want to see Knockd in action? Check the logs:

sudo tail -f /var/log/knockd.log

When you knock correctly:

[2025-01-18 10:45:23] 203.0.113.50: openSSH: Stage 1
[2025-01-18 10:45:23] 203.0.113.50: openSSH: Stage 2
[2025-01-18 10:45:24] 203.0.113.50: openSSH: Stage 3
[2025-01-18 10:45:24] 203.0.113.50: openSSH: OPEN SESAME
[2025-01-18 10:45:24] openSSH: running command: /sbin/iptables -I INPUT -s 203.0.113.50 -p tcp --dport 13022 -j ACCEPT

"OPEN SESAME" - I didn't make that up, knockd actually says that. Whoever wrote this daemon had a sense of humor like mine!

A Few Things to Keep in Mind

Port knocking is clever, but it's not magic. Some limitations:

• If someone is watching your network traffic, they can see the knock sequence.

• Doesn't play well with CI/CD or automated deployments

• If Knockd crashes, you might lock yourself out😔

This is perfect for personal servers, homelabs, and dev boxes. For production with a team, you probably want a VPN or something like Teleport.

Some tips from experience:

• Always have console access as backup. Cloud providers have web-based consoles. Use them if you lock yourself out.

• Don't use sequential ports like 1000, 2000, 3000. Too easy to guess.

• Keep your knock sequence to yourself.

• Still use key-based SSH authentication. Port knocking is an extra layer, not a replacement.

Quick Reference

# Install
sudo apt install knockd

# Config file
/etc/knockd.conf

# Enable on boot
sudo vim /etc/default/knockd  # Set START_KNOCKD=1

# Start the service
sudo systemctl enable --now knockd

# Knock from client
knock -v server-ip port1 port2 port3

# Check logs
sudo tail -f /var/log/knockd.log

That's it. Your SSH server is now basically invisible. Port scanners see nothing. Bots find nothing to attack. Only you with the secret knock can get in.

My auth.log has been so much quieter since I set this up. No more watching random IPs fail to guess "admin" as a username fifty times a minute.

Hope this saves you some headaches, too.

#devops #security #linux #ssh #networking

Thanks! JADAU!

But Wait... There's More! (Bonus)

Port knocking works at the firewall level. You can use it for any port:

• PostgreSQL (5432)

• MySQL (3306)

• Redis (6379)

• Admin panels

• Internal APIs

• Literally anything

You just add more blocks in /etc/knockd.conf:

[openPostgres]
    sequence    = 5555,6666,7777
    seq_timeout = 10
    command     = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 5432 -j ACCEPT
    tcpflags    = syn

[closePostgres]
    sequence    = 7777,6666,5555
    seq_timeout = 10
    command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 5432 -j ACCEPT
    tcpflags    = syn

Different knock sequences for each service.

If you encounter mysterious missing space after updates, APFS snapshots are a common suspect. Here’s a clear, safe walkthrough I used to find the culprit and get my machine back to normal.

Why does this happen? (short)

APFS supports snapshots - point-in-time copies of the filesystem. macOS creates them during system updates (and Time Machine uses them too). Normally, they are cleaned up automatically, but sometimes old snapshots remain and quietly consume space.

Quick diagnosis: Where is the disk space going?

Run this to see top-level disk usage (sudo may be required):

sudo du -hxd1 / | sort -hr | head -20

In my case, the output showed:

218G    /System

That was the red flag. Drill into /System:

sudo du -hxd1 /System | sort -hr | head -20

I found /System/Volumes that consuming 140+ GB.

Finding APFS snapshots

List snapshots on the root APFS volume with:

sudo diskutil apfs listSnapshots /

This prints snapshots like com.apple.os.update-YYYY-... along with UUIDs. Those com.apple.os.update-* entries were left behind after macOS updates in my case.

Example output snippet:

Snapshots for APFS Volume with UUID: XXXXX-XXXX-...
Snapshot name: com.apple.os.update-2023-07-12-123456
Snapshot UUID: 01234567-89AB-CDEF-0123-456789ABCDEF
... (more snapshots)

Deleting snapshots (safe approach)

To remove a single snapshot:

sudo diskutil apfs deleteSnapshot / -uuid <SNAPSHOT-UUID>

Replace <SNAPSHOT-UUID> with the UUID from the list. Repeat for unwanted snapshots. Deleting update snapshots is safe if the system is fully booted into the new OS and you don't plan to roll back.

If snapshots refuse to go away or reference in-use files, try one of the following:

• Reboot into Safe Mode and try again.

• Boot to macOS Recovery and use Terminal from there to delete stubborn snapshots.

Note: on APFS, snapshots are a filesystem feature… deleting them frees the space they were holding, but if you're unsure, booting into Recovery is the safest route.

Optional: sweep caches and developer junk

After removing large snapshots, you can reclaim even more space by cleaning developer caches and unused container data. Use these commands carefully — they remove caches and unused Docker images/containers.

# Homebrew cleanup
brew cleanup

# Docker: remove all unused containers, networks, images (dangling and unreferenced)
docker system prune -af

# Remove user cache (be careful — this deletes files in ~/.cache)
rm -rf ~/.cache/*

# npm cache cleanup
npm cache clean --force

I ran these and got another chunk of space back.

Mini case/example — what I saw (real numbers)

• Free space before: ~5 GB

• Found: /System ~218 GB, /System/Volumes ~140+ GB

• Action: listed APFS snapshots, removed several com.apple.os.update-* snapshots, then ran cache and Docker cleanup

• Free space after: ~90+ GB

This saved me from a full macOS reinstall.

Sharp edges & gotchas

• APFS snapshots are powerful: deleting an update snapshot removes the ability to roll back to that update. Only delete snapshots when you're confident you won't need to revert.

• If macOS or Time Machine is actively using snapshots, the system may prevent deletion until you boot to Recovery or Safe Mode.

• Always double-check UUIDs before deleting. A typo can remove the wrong snapshot.

• rm -rf ~/.cache/* is destructive: back up anything you care about before mass-deleting caches.

• On FileVault-encrypted systems, be extra careful with disk utilities. If in doubt, boot into Recovery and work from there.

Extra tips

• Regular maintenance: run brew cleanup occasionally and prune Docker images you no longer need.

• Keep an eye on snapshots after system updates for a few days: sometimes automatic cleanup lags.

• If you use Time Machine, local snapshots can also consume space - tmutil listlocalsnapshots / shows local Time Machine snapshots.

Key Takeaways

• APFS snapshots can silently hog hundreds of GB — check them when disk usage looks wrong.

• Diagnose with sudo du -hxd1 / and sudo diskutil apfs listSnapshots /.

• Delete snapshots with sudo diskutil apfs deleteSnapshot / -uuid <UUID>; use Recovery Mode if needed.

• Clean developer caches and Docker artifacts (brew cleanup, docker system prune -af, npm cache clean --force) for extra space.

• Always double-check what you delete and keep backups for critical data.

If you're in Kathmandu or anywhere in the world and see a surprising /System volume, this process should help you breathe easy again… saved me from reinstalling macOS. Jadau! 🎉

In the rapidly evolving landscape of AI tools and integrations, the ability to extend AI capabilities through custom interfaces has become increasingly valuable. Today, I'm excited to share a project I've been working on: the Hashnode MCP Server. This tool bridges the gap between AI assistants and the Hashnode blogging platform, enabling seamless content creation, management, and retrieval directly through AI interactions.

In this article, I'll walk you through what the Model Context Protocol (MCP) is, how my Hashnode MCP server works, and how you can set it up to enhance your own content workflow.

Demo First? (😁)

• Create Article:

  

• Update Article

  

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is a framework that allows AI models to interact with external tools and data sources. It provides a standardized way for AI assistants to access additional capabilities beyond their built-in functions.

MCP servers act as intermediaries between AI models and external services, exposing a set of tools and resources that the AI can use to perform specific tasks. This extends what AI assistants can do without requiring them to have direct API access to every possible service.

Introducing the Hashnode MCP Server

The Hashnode MCP Server is a Python-based implementation that connects AI assistants to the Hashnode API. It allows AI models to perform various operations on Hashnode blogs, including:

• Creating and publishing new articles

• Updating existing articles

• Searching for articles by keywords

• Retrieving article details

• Getting user information

• Fetching the latest articles from a publication

This means that with the Hashnode MCP Server, you can ask an AI assistant to draft a blog post, publish it to your Hashnode blog, search for related content, or update existing articles—all without leaving your conversation with the AI.

How the Hashnode MCP Server Works

At its core, the Hashnode MCP Server is a bridge between AI assistants and the Hashnode GraphQL API. Here's how it works:

1. Connection: The MCP server establishes a connection with both the AI assistant and the Hashnode API.

2. Tool Exposure: It exposes a set of tools that represent different Hashnode operations.

3. Request Handling: When the AI assistant wants to perform an action, it sends a request to the MCP server.

4. API Interaction: The server translates this request into the appropriate GraphQL query or mutation for the Hashnode API.

5. Response Formatting: After receiving a response from Hashnode, the server formats it in a way that's easy for the AI to understand and present to the user.

The server is built using the FastMCP framework, which simplifies the process of creating MCP servers by handling the communication protocol details.

Setting Up the Hashnode MCP Server

Prerequisites

• Python 3.8 or higher

• A Hashnode account with a personal access token

• Basic familiarity with command-line operations

Installation Steps

1. Clone the repository:

    git clone https://github.com/sbmagar13/hashnode-mcp-server.git
    cd hashnode-mcp-server
   

2. Create a virtual environment:

    python -m venv .venv
    source .venv/bin/activate  # On Windows: .venv\Scripts\activate
   

3. Install dependencies:

    pip install -r requirements.txt
   

4. Set up environment variables: Create a .env file in the project root with the following content:

    HASHNODE_API_URL=https://gql.hashnode.com
    HASHNODE_PERSONAL_ACCESS_TOKEN=your_personal_access_token
   

   Replace your_personal_access_token with your actual Hashnode personal access token, which you can generate in your Hashnode account settings.

5. Run the server:

   You have two options for running the server:

   Option 1: Run the server manually

    python run_server.py
   

   Or directly using the root file:

    python mcp_server.py
   

   The server will start and listen for connections from AI assistants. By default, it runs on localhost:8000.

   Option 2: Let the MCP integration handle it automatically (I’ll be using this)

   When properly configured in Claude Desktop or Cline VSCode extension, the MCP integration will automatically start and manage the server process for you.

Important Note on File Structure

When configuring your MCP server in Claude Desktop or Cline VSCode extension, you should use the root mcp_server.py file directly rather than the files in the hashnode_mcp directory. The hashnode_mcp directory is primarily for packaging purposes.

For example, in your configuration, point to:

/path/to/your/hashnode-mcp-server/mcp_server.py

And not:

/path/to/your/hashnode-mcp-server/hashnode_mcp/mcp_server.py

This ensures you're using the most up-to-date version of the server with all features enabled. The root mcp_server.py file contains all the necessary functionality and doesn't require the package structure to operate correctly.

Using the Hashnode MCP Server with AI Assistants

Once your server is configured, you can connect compatible AI assistants to it. Unlike traditional API integrations that use URLs, MCP servers are typically configured directly in the AI assistant's configuration files, as we'll see in the next section.

The connection process generally involves:

1. Setting up the configuration file for your AI assistant (Claude Desktop or Cline VSCode extension)

2. Specifying the path to your Python interpreter and the MCP server script

3. Providing necessary environment variables like your Hashnode personal access token

After configuring the connection, you can start giving the AI commands related to your Hashnode blog. For example:

• "Create a new article about Python programming tips"

• "Update my article with ID 12345 to fix the code examples"

• "Get the latest articles from my blog"

• "Search for articles about machine learning"

The AI will use the MCP server to execute these commands and return the results.

Configuring MCP on Claude Desktop and Cline VSCode Extension

To use your Hashnode MCP Server with Claude AI, you'll need to configure it in either Claude Desktop or the Cline VSCode extension. Here's how to set it up in both environments:

Configuring MCP on Cline VSCode Extension

1. Open VS Code with the Cline extension installed.

2. Navigate to the Cline MCP settings file located at:

   • Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json

   • macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

   • Linux: Unfortunately, Claude Desktop is not available for Linux as of now (at the time of writing this article) (So you can use VSCode Cline Extension instead)

3. Add your Hashnode MCP server configuration to the file:

    {
      "mcpServers": {
        "hashnode": {
          "command": "/path/to/your/venv/bin/python",
          "args": [
            "/path/to/your/hashnode-mcp-server/mcp_server.py"  // Use the root mcp_server.py file
          ],
          "env": {
            "HASHNODE_PERSONAL_ACCESS_TOKEN": "your-personal-access-token"
          }
        }
      }
    }
   

   Note that the configuration points to the root mcp_server.py file, not the one in the hashnode_mcp directory.

4. Replace the paths and token with your actual values. For example:

    {
      "mcpServers": {
        "hashnode": {
          "command": "/Users/sagar/my_personal/hashnode-mcp-server/.venv/bin/python",
          "args": [
            "/Users/sagar/my_personal/hashnode-mcp-server/mcp_server.py"
          ],
          "env": {
            "HASHNODE_PERSONAL_ACCESS_TOKEN": "your-personal-access-token"
          }
        }
      }
    }
   

5. Save the file and restart VS Code or reload the window.

6. Open a new Cline conversation and test the connection by asking it to interact with your Hashnode blog.

Configuring MCP on Claude Desktop

1. Open Claude Desktop and navigate to the configuration file:

   • Windows: %APPDATA%\Claude\claude_desktop_config.json

   • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

   • Linux: Unfortunately, Claude Desktop is not available for Linux as of now (at the time of writing this article)

2. Add your Hashnode MCP server configuration to the file, using the same format as for the Cline VSCode extension. Make sure to point to the root mcp_server.py file:

    {
      "mcpServers": {
        "hashnode": {
          "command": "/path/to/your/venv/bin/python",
          "args": [
            "/path/to/your/hashnode-mcp-server/mcp_server.py"  // Use the root mcp_server.py file
          ],
          "env": {
            "HASHNODE_PERSONAL_ACCESS_TOKEN": "your-personal-access-token"
          }
        }
      }
    }
   

3. Save the file and restart Claude Desktop.

4. Test the connection by asking Claude to perform a simple operation like "Get the latest articles from my Hashnode blog."

Troubleshooting Connection Issues

If you encounter connection issues:

1. Verify the server is running by checking the terminal where you started the MCP server.

2. Check the paths in your configuration are correct and point to the right Python interpreter and script.

3. Ensure your environment variables are properly set, especially the Hashnode personal access token.

4. Check the server logs for any error messages.

5. Try restarting both the MCP server and the Claude application.

Example: Creating a New Article

Let's walk through a practical example of using the Hashnode MCP Server to create and publish a new article:

1. Start the server as described above.

2. Connect your AI assistant to the MCP server.

3. Ask the AI to create an article:

    Create a new article titled "Getting Started with Python" with the following content:
   
    # Getting Started with Python
   
    Python is one of the most popular programming languages today. In this article, we'll explore the basics of Python and how to get started.
   
    ## Installation
   
    First, you need to install Python...
   
    [rest of the article content]
   
    Tags: python, programming, beginners
   

4. The AI will use the MCP server to:

   • Format the request for the Hashnode API

   • Send the creation request

   • Return the result, including the article ID and URL

5. You can then ask the AI to:

   • Publish the article immediately

   • Save it as a draft

   • Make further edits

Advanced Features

Timeout Handling

The Hashnode MCP Server includes robust timeout handling for API requests. This is particularly important for operations like article creation and updates, which might take longer to process. If a request times out, the server provides helpful error messages and suggestions.

Error Management

The server includes comprehensive error handling to provide clear feedback when issues occur. This makes troubleshooting easier and improves the user experience.

Pagination Support

For operations that might return large amounts of data, like searching for articles, the server supports pagination to manage the response size and improve performance.

Potential Use Cases

The Hashnode MCP Server opens up numerous possibilities for content creators:

1. Automated Content Creation: Generate draft articles based on outlines or topics.

2. Content Management: Update, organize, and manage your blog without leaving your AI assistant.

3. Research Assistance: Search your existing content to find relevant articles or avoid duplication.

4. Batch Operations: Perform bulk updates or content audits across your blog.

5. Integration with Workflows: Incorporate blog publishing into broader AI-assisted workflows.

Technical Architecture

The project is organized with a clean, modular structure:

• mcp_server.py: Root server implementation that can be run directly

• hashnode_mcp/: Core package containing the modular functionality

  • mcp_server.py: Package version of the server implementation

  • utils.py: Utility functions for formatting responses and GraphQL queries

• examples/: Example usage scripts

• tests/: Test suite for verifying functionality

• run_server.py: Entry point for running the server using the package version

While the project includes a package structure (hashnode_mcp/) for organization and potential distribution, users can simply run the root mcp_server.py file directly without needing to use the package. This provides flexibility in how you choose to deploy the server.

The server uses asynchronous programming with Python's asyncio and httpx libraries for efficient API communication. GraphQL queries and mutations are defined as constants, making them easy to maintain and update.

Future Enhancements

There are several exciting possibilities for future development:

1. Additional Hashnode Features: Support for more Hashnode API capabilities like managing comments, series, and newsletters.

2. Analytics Integration: Retrieving and analyzing blog performance metrics.

3. Content Optimization: AI-assisted SEO optimization for articles.

4. Multi-User Support: Enhanced capabilities for team publications.

5. Webhook Support: Responding to events from your Hashnode blog.

Conclusion

The Hashnode MCP Server represents a powerful bridge between AI assistants and content creation on Hashnode. By enabling AI models to interact directly with your blog, it streamlines the writing and publishing process, making content creation more efficient and accessible.

Whether you're a solo blogger looking to optimize your workflow or part of a content team seeking to scale your production, this tool offers valuable capabilities for integrating AI into your content strategy.

I'm excited to see how others in the community will use and extend this project. The code is open-source and available on GitHub, so feel free to fork it, contribute, or adapt it to your specific needs.

Resources

• GitHub Repository

• Hashnode API Documentation

• Model Context Protocol Documentation

Thanks!

Have you integrated AI tools into your content workflow? Share your experiences in the comments below!

I get it, I spent a lot of time trying to find the perfect guide myself. So I wrote this to save you the trouble I went through. (Now this article is always a go-to solution for me too😎)

You’ve landed in the right place.

In this tutorial, you’ll learn how to resize your EC2 instance’s disk without detaching the volume or restarting the server(Easily). AWS provides a block storage solution, EBS, for the instance. EBS’ Elastic Volumes feature allows you to increase volume size while the volume is still in use, making the resizing process much easier and faster without any downtime of the server.

Before extending the size of your EBS volume, It’s good to take a backup of your data with EBS Snapshot. It’s the best practice as if anything goes wrong, you can always restore the data.

Create Snapshot

To take a snapshot of your volume,

• Go to EBS volume attached to your instance from EC2 Dashboard.

• Click on Actions and Create Snapshot.

• Add the description value as you wish.

• You can add tags also.

• Click on Create Snapshot. It may take some time.

Resize The EBS Volumes of EC2 Instance:

After creating a snapshot of your volume, now it’s time to increase your disk space.

Steps:

• First Go to Services > EC2 > Instances.

• Go to the EBS volume attached to your instance.

• From Actions click on Modify Volume.

• Add your desired size, I will be replacing 8 with 30.

• You’ll get a confirmation pop-up. Click on Modify.

Resizing the EBS:

You have successfully added a new volume size to your instance, but you aren’t using the new volume size. For this, SSH to your server or instance and run: df -h

Here, you can see our disk partition is still using 8GB. Check the partition size by running commands lsblk and blkid.1

Here, xvda1 is your current volume with 8GB and xvda with 30GB.

<aside> 📌 *xvda1 or similar is for Xen Virtual Machine based server. For NVMe (Non-Volatile Memory Express) solid-state drive (SSD) based device, it will be nvme0n1p1 or similar.*

</aside>

Now extend the partition:

# For xvda1 partition
$ sudo growpart /dev/xvda 1
# For nvme0n1p1 partition
$ sudo growpart /dev/nvme0n1 1

And, extend the volume:

$ sudo xfs_growfs /dev/xvda1
$ sudo xfs_growfs /dev/nvme0n1p1

Type df -h to check the volume size, it must show 30GB.

In our case, since the file system is XFS, we have to use xfs_growfs tool.

For file systems ext4, ext2, and ext3 you have to use sudo resize2fs /dev/xvda1 OR sudo resize2fs /dev/nvme0n1p1.

Conclusion

In this way, the volume is now resized and ready to be used without any downtime.

Thank you!

Terraform

Terraform, a Go-based program released by Hashicorp in 2014, is used to build, change, and version control your infrastructure(IaC). This has an extremely strong and user-friendly Command Line Interface.

Prerequisites

• Basics of Terraform – IaC (Terraform CLI)

• Command Line basics

Terraform CLI Tips and Cheatsheets

Installation

Install through curl

$ curl -O <https://releases.hashicorp.com/terraform/1.9.7/terraform_1.9.7_linux_amd64.zip>
$ sudo unzip terraform_1.9.7_linux_amd64.zip -d /usr/local/bin/
$ rm terraform_1.9.7_linux_amd64.zip

Install using tfenv (Terraform Version Manager)

First of all, download the tfenv binary and put it in your PATH.

$ git clone <https://github.com/tfutils/tfenv.git> ~/.tfenv
$ echo 'export PATH="$HOME/.tfenv/bin:$PATH"' >> $HOME/bashrc

Then, you can install the desired version of Terraform:

$ tfenv install 1.9.7

Usage

Version Check

$ terraform --version

Terraform v1.9.7
on linux_amd64

Terraform init

The following command is used to initialize the terraform project:

$ terraform init

It’s the first command you need to execute. Unless terraform plan, apply, destroy and import will not work. This command terraform init will install the followings:

• Terraform modules

• Backend

• Provider(s) plugins

You can initialize the Terraform without any input prompt. To do this, run the following command:

$ terraform init -input=false

Also, if you want to change the backend configuration during the init command, run the following command:

$ terraform init -backend-config=proj/s3.dev.tf -reconfigure

Here, reconfigure is used to tell Terraform to not copy the existing state to the new remote state location.

Terraform Get

This command is very useful when you have defined some modules. And if you edit modules, you need to get modules content again.

$ terraform get -update=true

When using modules, the first thing you’ll need to do is a terraform get. This appends modules to the .terraform directory. Unless you do another terraform get -update=true, you’ve effectively vendored those components.

Terraform Plan

The plan step validates the configuration for execution and creates a plan to be applied to the target infrastructure provider.

$ terraform plan -out plan.out

It’s a crucial Terraform tool that lets users know the actions Terraform will do before making any changes, providing confidence that a modification will have the desired effect once deployed.

When you execute terraform plan, Terraform will scan all *.tf files in your directory and create the plan.

Terraform Apply

Now it’s time to execute the plan:

$ terraform apply plan.out

Terraform can guarantee that the execution plan will not change by generating it and applying it in the same command without the need to write it to disk. This decreases the possibility of potentially sensitive data being left behind or being incorrectly checked into version control.

$ terraform apply

• Apply and Auto Approve

$ terraform apply -auto-approve

• Apply and Define New Variables Value

$ terraform apply -auto-approve -var tags-repository_url=${GIT_URL}

• Apply Only One Module

$ terraform apply -target=module.s3

This -target option works with terraform plan too.

Terraform Destroy

$ terraform destroy

Delete all the resources!

A deletion plan can be created before:

$ terraform plan –destroy

• target option allows to destroy only one resource, for example, an S3 bucket :

$ terraform destroy -target aws_s3_bucket.my_bucket

Debugging in Terraform

In Terraform terraform console command is useful for testing interpolations before using them in configurations. Terraform console will read the configured state even if it is remote.

$ echo "aws_iam_user.sagar.arn" | terraform console

arn:aws:iam::123456789:user/sagar

Graph in Terraform

$ terraform graph | dot –Tpng > graph.png

Visual representation (graph) of Terraform resources.

Terraform Validate

The validate command is used to validate/check the syntax of the Terraform files. A syntax check is done on all the Terraform files in the directory and will display an error if any of the files don’t validate. The syntax check does not cover every syntax common issue.

$ terraform validate

Providers

You can use a lot of providers/plugins in your Terraform definition resources, so it can be useful to have a tree of providers used by modules in your project.

$ terraform providers
.
├── provider.aws ~> 4.49.0
├── module.my_module
│   ├── provider.aws (inherited)
│   ├── provider.null
│   └── provider.template
└── module.elastic
└── provider.aws (inherited)

State

Pull Remote State in A Local Copy

$ terraform state pull > terraform.tfstate

Push State in a Remote Backend storage

$ terraform state push

This command is useful if, for example, you originally use a local tf state and then you define backend storage, in S3 or Consul…

How to Tell to Terraform You Moved a Resource in A Module?

If you moved an existing resource in a module, you need to update the state:

$ terraform state mv aws_iam_role.role1 module.mymodule

How to Import Existing Resources in Terraform?

If you have an existing resource in your infrastructure provider, you can import it in your Terraform state:

$ terraform import aws_iam_policy.elastic_post

arn:aws:iam::123456789:policy/elastic_post

Workspaces

To manage multiple distinct sets of infrastructure resources/environments.

Instead of creating a directory for each environment to manage, we need to just create needed workspace and use them:

Create Workspace

This command creates a new workspace and then select it

$ terraform workspace new dev

Select a Workspace

$ terraform workspace select dev

List Workspaces

$ terraform workspace list

default
* dev
staging

Show Current Workspace

$ terraform workspace show

dev

Tools

1. jq

jq is a command-line JSON processor. It’s very lightweight and it can be used with Terraform output to make Terraform more powerful.

Installation

For Linux:

$ sudo apt-get install jq

or

$ yum install jq

For OS X:

$ brew install jq

Usage

For example, we defined outputs in a module and when we execute terraform apply outputs are displayed:

$ terraform apply

...
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:
elastic_endpoint = vpc-toto-12fgfd4d5f4ds5fngetwe4.ap-south-1.es.amazonaws.com

We can extract the value that we want to use in a script for example. With jq it’s easy:

$ terraform output -json

{
    "elastic_endpoint": {
        "sensitive": false,
        "type": "string",
        "value": "vpc-toto-12fgfd4d5f4ds5fngetwe4.ap-south-1.es.amazonaws.com"
    }
}

$ terraform output -json | jq '.elastic_endpoint.value'

"vpc-toto-12fgfd4d5f4ds5fngetwe4.ap-south-1.es.amazonaws.com"

2. Terraforming

If you have an existing AWS account for example with existing components like S3 buckets, SNS, VPC … You can use the Terraforming tool, a tool written in Ruby, which extracts existing AWS resources and converts them to Terraform files!

Installation

$ sudo apt install ruby 
# OR 
$ sudo yum install ruby

and

$ gem install terraforming

Usage

Pre-requisites:

As in Terraform, you need to set AWS credentials:

$ export AWS_ACCESS_KEY_ID="an_aws_access_key"
$ export AWS_SECRET_ACCESS_KEY="a_aws_secret_key"
$ export AWS_DEFAULT_REGION="eu-central-1"

You can also specify the credential profile in ~/.aws/credentials and with –profile option.

$ cat ~/.aws/credentials

[sagar]
aws_access_key_id = xxx
aws_secret_access_key = xxx
aws_default_region = eu-central-1

$ terraforming s3 --profile sagar

Example

$ terraforming --help

Commands:
terraforming alb # ALB
...
terraforming vgw # VPN Gateway
terraforming vpc # VPC

$ terraforming s3 > aws_s3.tf

Note: Terraform can’t extract API gateway resources for the moment so you need to write it manually.

Conclusion

In this article, I talked about some of the important Terraform CLI tips and cheatsheets. There is still a lot more than this, but you can go and explore them yourself. Thank you!

You need to lint the container docker images to enforce security aspects of container images which minimize the attack layers by hardening the individual container images. It is the best security practice pattern to use linting along with vulnerability scanning.

Dockle

Dockle is a linter for container images. Dockle, in comparison to other linters, gives us confidence that our container images were built in accordance with well-known, proven security best practices. Dockle, for example, verifies many best practices specified as part of the CIS benchmarks. It is also critical to remember that Dockle does not lint Dockerfiles. Container images are linted.

Prerequisites

• Understanding of Docker

• docker configured on your system

Set Up: Linting Docker image with Dockle

Now, you know a bit about Dockle. So, let’s get dive into the practical implementation of Dockle:

Dockle Installation

On Linux

You can install Dockle on Linux in a different way according to your distribution. [In my case, I’m using Arch-based Linux so I’ll be using Arch User Repository(AUR)] {First Priority :-)}

For Arch-based distro

# clone the repo
$ git clone <https://aur.archlinux.org/dockle-bin.git>

$ cd dockle-bin

# build and install the package
$ makepkg -sri

For Ubuntu/Debian

$ VERSION=$(
 curl --silent "<https://api.github.com/repos/goodwithtech/dockle/releases/latest>" | \\
 grep '"tag_name":' | \\
 sed -E 's/.*"v([^"]+)".*/\\1/' \\
) && curl -L -o dockle.deb <https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.deb>

# Extract and delete the pakage
$ sudo dpkg -i dockle.deb && rm dockle.deb

For RHEL/CentOS

$ VERSION=$(
 curl --silent "<https://api.github.com/repos/goodwithtech/dockle/releases/latest>" | \\
 grep '"tag_name":' | \\
 sed -E 's/.*"v([^"]+)".*/\\1/' \\
) && rpm -ivh <https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.rpm>

On Windows

Run the following in the command prompt:

$ VERSION=$(
 curl --silent "<https://api.github.com/repos/goodwithtech/dockle/releases/latest>" | \\
 grep '"tag_name":' | \\
 sed -E 's/.*"v([^"]+)".*/\\1/' \\
) && curl -L -o dockle.zip <https://github.com/goodwithtech/dockle/releases/downlLinting docker image with dockleoad/v${VERSION}/dockle_${VERSION}_Windows-64bit.zip>

# Extract and delete the ZIP archive
$ unzip dockle.zip && rm dockle.zip
$ ./dockle.exe [IMAGE_NAME]

On macOS

For Mac, you can use Homebrew;

$ brew install goodwithtech/r/dockle

Implementation: Linting docker image with Dockle

It’s time to lint some images now that you’ve installed Dockle-CLI on your machine. If you’re already using container technologies, you probably have some container images on your local machine. However, for the sake of demonstration, let’s create a simple web server image.

Create and build a sample web server image

To do so create a file Dockerfile and add the following lines:

FROM nginx:alpine
EXPOSE 80

Build the container by running the following command:

$ docker build -t example:latest .

Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM nginx:alpine
alpine: Pulling from library/nginx
c158987b0551: Pull complete 
1e35f6679fab: Pull complete 
cb9626c74200: Pull complete 
b6334b6ace34: Pull complete 
f1d1c9928c82: Pull complete 
9b6f639ec6ea: Pull complete 
ee68d3549ec8: Pull complete 
Digest: sha256:dd8a054d7ef030e94a6449783605d6c306c1f69c10c2fa06b66a030e0d1db793
Status: Downloaded newer image for nginx:alpine
 ---> 1e415454686a
Step 2/2 : EXPOSE 80
 ---> Running in bbfb3fd7cb20
Removing intermediate container bbfb3fd7cb20
 ---> 0ccb22ae7702
Successfully built 0ccb22ae7702
Successfully tagged example:latest

Linting docker image with Dockle

Now, let’s lint the container image using the Dockle CLI command:

$ dockle example:latest

Output:

linting docker image with dockle

Explanation

As you can see, we have a number of warnings and information. Although we can address the majority of the issues by updating our Dockerfile, CIS-DI-0005 requires you to configure your local Docker installation to sign container images (Docker Content Trust). We can also address DKL-DI-0006 by constructing our image with a tag other than the latest. First, let’s address any issues that we discovered in the Dockerfile. Update the Dockerfile as shown in the example below:

FROM nginx:alpine
EXPOSE 80

# Adding health check to address CIS-DI-0006
HEALTHCHECK --interval=30s --timeout=2s --start-period=5s --retries=3 CMD curl -f <http://localhost/index.html> || exit 1

# Add a new user in a group(new in this case)
RUN addgroup -S cloudyfox && adduser -S sagar -G cloudyfox \\
 && mkdir -p /var/run/nginx /var/tmp/nginx \\
 && chown -R sagar:cloudyfox /usr/share/nginx /var/run/nginx /var/tmp/nginx

# Copy custom NGINX configuration to the image
COPY nginx.conf /etc/nginx/nginx.conf

# Switch user context to address CIS-DI-0001
USER sagar:cloudyfox

Now, again create a nginx.conf configuration file in the same directory as Dockerfile and add the following snippet:

worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid    /var/run/nginx/nginx.pid;
events {
  worker_connections 1024;
}
http {
  client_body_temp_path /var/tmp/nginx/client_body;
  fastcgi_temp_path /var/tmp/nginx/fastcgi_temp;
  proxy_temp_path /var/tmp/nginx/proxy_temp;
  scgi_temp_path /var/tmp/nginx/scgi_temp;
  uwsgi_temp_path /var/tmp/nginx/uwsgi_temp;
  include    /etc/nginx/mime.types;
  default_type application/octet-stream;
  log_format main '$remote_addr - $remote_user [$time_local] "$request" '
           '$status $body_bytes_sent "$http_referer" '
           '"$http_user_agent" "$http_x_forwarded_for"';
  access_log /var/log/nginx/access.log main;
  sendfile    on;
  keepalive_timeout 65;
  include /etc/nginx/conf.d/*.conf;
}

Finally, let’s build again our Dockerfile with the tag as 0.1.0 which addresses DKL-DI-0006:

$ docker build -t example:0.1.0 .

Sending build context to Docker daemon  4.096kB
Step 1/6 : FROM nginx:alpine
 ---> 1e415454686a
Step 2/6 : EXPOSE 80
 ---> Using cache
 ---> 0ccb22ae7702
Step 3/6 : HEALTHCHECK --interval=30s --timeout=2s --start-period=5s --retries=3 CMD curl -f <http://localhost/index.html> || exit 1
 ---> Running in ad633cc5a53f
Removing intermediate container ad633cc5a53f
 ---> 85e8fae17637
Step 4/6 : RUN addgroup -S cloudyfox && adduser -S sagar -G cloudyfox  && mkdir -p /var/run/nginx /var/tmp/nginx  && chown -R sagar:cloudyfox /usr/share/nginx /var/run/nginx /var/tmp/nginx
 ---> Running in 197fe5351548
Removing intermediate container 197fe5351548
 ---> 3f2d6651de9e
Step 5/6 : COPY nginx.conf /etc/nginx/nginx.conf
 ---> 1902f88b672c
Step 6/6 : USER sagar:cloudyfox
 ---> Running in b4d9cd554de9
Removing intermediate container b4d9cd554de9
 ---> bc03ec6dd426
Successfully built bc03ec6dd426

Now, lint the docker image:

$ dockle example:0.1.0

INFO    - CIS-DI-0005: Enable Content trust for Docker
        * export DOCKER_CONTENT_TRUST=1 before docker pull/build

And let’s enable Content trust for Docker:

$ export DOCKER_CONTENT_TRUST=1

Again build the new version with 0.1.1 and lint the docker container image:

$ docker build -t example:0.1.1 .

Now, you don’t see any warnings or findings, which means you have successfully passed the dockle linting test.

That’s it.

Conclusion

In this, we practically went through linting the Docker image with Dockle, why container images should be linted, and how we can use dockle as a linter along with the installation process.

In short, you learned linting container images with Dockle which will discover weak container images and provide detailed information about how to improve, harden, and optimize our container images.

Thank you!

In this article, we will install MongoDB on an EC2 instance in AWS. Installing MongoDB on EC2 via aptitude is very simple. To install MongoDB on your EC2 Ubuntu system you can follow the official MongoDB-org package, which MongoDB Inc. maintains.

Prerequisites

AWS Account

Launch EC2 Instance

Pick any AMI (for this I am using Ubuntu 20.04), select the desired instance type, Storage, and configure the proper VPC, subnet, etc.

Create or pick an existing security group that has an SSH port enabled in the inbound rule.

Launch the instance by creating a new one or using an existing keypair. For detailed instructions on launching instances, follow the official documentation.

Install MongoDB on EC2

SSH into the server instance by running the following command: (Make sure your instance’s private key directory)

$ chmod 400 <keypair name> $ ssh -i ~/dir/<keypair name> ubuntu@<EC2 instance IP address>

Now, import a private key repository package for MongoDB to install on your server:

$ wget -qO - https://www.mongodb.org/static/pgp/server-4.2.asc | sudo apt-key add -

And add sources to your system:

$ echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.2.list

Update the package:

$ sudo apt update

Now you’re ready to install MongoDB on your system:

$ sudo apt install -y mongodb-org

You’ve successfully installed MongoDB on your system, let’s start the mongo service and verify:

$ sudo systemctl start mongod $ sudo systemctl status mongod

You can enable the service to start every time you reboot the system by running the following command:

$ sudo systemctl enable mongod

Here, you’ve successfully installed MongoDB on your Ubuntu Server in AWS.

Connect To Remote MongoDB Server

In this section, we’ll set up user authentication for Mongo so that we can read and write to the MongoDB server.

User Setup

SSH into the server and type mongo to run Mongo shell. For this tutorial, I'm gonna set up a user sagar and give read-write access to the example_db database.

use example_db

db.createUser({ user: 'sagar', pwd: 'my-password', roles: [{ role: 'readWrite', db:'example_db'}] })

Enable MongoDB access to all IPs

Edit /etc/mongod.conf file:

$ sudo nano /etc/mongod.conf

Look for the net line and comment out the bindIp line under it, which is currently limiting MongoDB connections to.

Note: do not comment out the bindIp line without enabling authorization, authorization can be enabled by un-commenting # security section and adding authorization: 'enabled'.

# network interfaces net: port: 27017 # bindIp: 127.0.0.1 <-- comment out this

security: authorization: 'enabled'

Open port 27017 on your EC2 server

Go to Security Groups of your instance.
Edit the inbound rule on your server's security group by allowing Custom TCP on the port 27017 (you can set the traffic source as anywhere 0.0.0.0/0 or as per your requirements).

Restart and Check the Status of Mongo Daemon

Restart:

$ sudo service mongod restart

Check the status:

$ sudo service mongod status

If anything goes wrong or not, you can always check the logs:

$ sudo tail -f /var/log/mongodb/mongod.log

Accessing MongoDB

Using Mongo Shell:

Access the remote Mongo Database we just set up:

$ mongo -u sagar -p my-password <Instance's public IP>/example_db

Here you go, now you can read and write within the example_db database without ssh.

Using Mongo Client:

Host = mongodb://sagar:my-password@<Instance's public IP>/example_db Port = 27017 (default)

Fix-1 Cannot access from other IPs

By default, the MongoDB server only allows connections from localhost(127.0.0.1). So, if you face an issue connecting the database, you can fix this by binding all IPs.

To allow connections from elsewhere in your VPC edit /etc/mongod.conf:

Look for the net line and replace bindIp value with 0.0.0.0, ::, to bind all IPV4 and IPV6 addresses, which is currently limiting MongoDB connections to localhost.

# network interfaces net: port: 27017 bindIp: 127.0.0.1 # change this to 0.0.0.0, to bind to all IP addresses

Note: make sure you have enabled authorization on security: section by adding authorization: 'enabled'(as we've already done above), to forbid the access to Mongo database on your server.

Restart the Mongo daemon(MongoDB).

Now, you’re good to go ahead.

Conclusion

In this tutorial, you have successfully learned to install MongoDB on EC2 and access from the shell as well as Mongo clients.

Thanks!

keep supporting!!

In Elastic Stack—

• ElasticSearch is used to store data.

• Filebeat transfers the logs into ElasticSearch through LogStash

• LogStash filters the logs

• Kibana helps in visualizing the data and navigating the logs.

In this article, we’re going to deploy ElasticStack on AWS EC2 using Terraform.

Why run your own Elastic Stack on AWS EC2 instead of hosted services

We can create ElasticSearch in AWS either by using Elastic Cloud or by using AWS ElasticSearch Service(OpenSearch). But running our own ElasticSearch on AWS EC2 instead of hosted services has the following advantages:

• Cheaper

• Full control over configuration, accessibility, and visibility.

• Easy plugins installation

• Access logs

• Perform any configuration changes

• No boundary in choosing any instance type

PREREQUISITES

• AWS and Terraform Knowledge

• AWS Credentials

Creating Elastic Stack on AWS EC2

Here we’ll create an elastic stack in a VPC, and set up Filebeat on EC2 which helps to view logs, and then, LogStash to apply some filters to the data/logs. All the logs are created and stored inside /var/log. Filebeat takes all these logs and sends them to LogStash. LogStash then applies filters to send them to ElasticSearch.

Finally, Kibana will be configured to display logs from ElasticSearch. Which can be accessed from the Kibana dashboard.

Configuration Set-Up(Important)

To set up the configuration for each component, first, we need to install components on our EC2 server. For the sake of simplicity, we’ll be using Terraform data_template method to replace the default file. And it must be done before starting the component.

1. VPC, subnets set-up

#basic setup
resource "aws_vpc" "elastic_stack_vpc"{
  cidr_block = cidrsubnet("172.20.0.0/16",0,0)
  tags={
    Name="example-elasticsearch_vpc"
  }
}
resource "aws_internet_gateway" "elastic_stack_ig" {
  vpc_id = aws_vpc.elastic_vpc.id
  tags = {
    Name = "example_elasticsearch_igw"
  }
}
resource "aws_route_table" "elastic_stack_rt" {
  vpc_id = aws_vpc.elastic_vpc.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.elastic_internet_gateway.id
  }
  tags = {
    Name = "example_elasticsearch_rt"
  }
}
resource "aws_main_route_table_association" "elastic_stack_rt_main" {
  vpc_id         = aws_vpc.elastic_vpc.id
  route_table_id = aws_route_table.elastic_rt.id
}
resource "aws_subnet" "elastic_stack_subnet"{
  for_each = {ap-south-1a=cidrsubnet("172.20.0.0/16",8,10),ap-south-1b=cidrsubnet("172.20.0.0/16",8,20)}
  vpc_id = aws_vpc.elastic_vpc.id
  availability_zone = each.key
  cidr_block = each.value
  tags={
    Name="elasticsearch_subnet_${each.key}"
  }
}

Now, Setup ElasticSearach Cluster:

2. ElasticSearch cluster set-up

In this, we’ll set up a two-masternode and one-datanode ElasticSearch cluster in different AZs. In the security group for ElasticSearch, add the inbound access rule to port 9200. This is required so that Kibana can access it.

# elasticsearch security group
resource "aws_security_group" "elasticsearch_sg" {
  vpc_id = var.vpc_id
  description = "ElasticSearch Security Group"
  ingress {
    description = "ingress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 22
    protocol = "tcp"
    to_port = 22
  }
  ingress {
    description = "ingress rules"
    from_port = 9200
    protocol = "tcp"
    to_port = 9300
    security_groups = [aws_security_group.kibana_sg.id] # Kibana security group to access ElasticSearch
  }

  ingress {
    description = "ingress rules"
    from_port = 9200
    protocol = "tcp"
    to_port = 9300
    security_groups = [var.lambda_sg] # If you're using lambda to access ES.
  }

  egress {
    description = "egress rules"
    from_port   = 0
    protocol    = "-1"
    to_port     = 0
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags={
    Name="elasticsearch_sg"
  }
}

ElasticSearch master nodes:

# Elastic-Search master nodes
resource "aws_key_pair" "elastic_ssh_key" {
  key_name="elasticsearch_ssh"
  public_key= file("~/.ssh/elasticsearch_keypair.pub")
}
resource "aws_instance" "elastic_nodes" {
  count                  = 2
  ami                    = var.elastic_aws_ami
  instance_type          = var.elastic_aws_instance_type
  # subnet_id              = aws_subnet.elastic_subnet[var.azs[count.index]].id
  subnet_id              = var.public_subnet_ids[count.index]
  vpc_security_group_ids = [aws_security_group.elasticsearch_sg.id]
  key_name               = aws_key_pair.elastic_ssh_key.key_name
  iam_instance_profile   = "${aws_iam_instance_profile.elastic_ec2_instance_profile.name}"
  associate_public_ip_address = true
  tags = {
    Name = "elasticsearch dev node-${count.index}"
  }
}
data "template_file" "init_elasticsearch" {
  depends_on = [ 
    aws_instance.elastic_nodes
  ]
  count          = 2
  template = file("./elasticsearch/configs/elasticsearch_config.tpl")
  vars = {
    cluster_name = "elasticsearch_cluster"
    node_name    = "node_${count.index}"
    node         = aws_instance.elastic_nodes[count.index].private_ip
    node1        = aws_instance.elastic_nodes[0].private_ip
    node2        = aws_instance.elastic_nodes[1].private_ip
    node3        = aws_instance.elastic_datanodes[0].private_ip
  }
}

data "template_file" "init_backupscript" {
  depends_on = [ 
    aws_instance.elastic_nodes
  ]
  count          = 2
  template = file("./elasticsearch/configs/s3_backup_script.tpl")
  vars = {
    cluster_name = "elasticsearch_cluster"
    node         = aws_instance.elastic_nodes[count.index].private_ip
    node1        = aws_instance.elastic_nodes[0].private_ip
    node2        = aws_instance.elastic_nodes[1].private_ip
    node3        = aws_instance.elastic_datanodes[0].private_ip
  }
}

resource "aws_eip" "elasticsearch_eip"{
    count     = 2
    instance  = element(aws_instance.elastic_nodes.*.id, count.index)
    vpc       = true

    tags = {
    Name = "elasticsearch-eip-${terraform.workspace}-${count.index + 1}"
  }
}

resource "null_resource" "move_es_file" {
  count          = 2
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("~/.ssh/elasticsearch_keypair.pem")
     host        = aws_instance.elastic_nodes[count.index].public_ip
  } 
  provisioner "file" {
    content      = data.template_file.init_elasticsearch[count.index].rendered
    destination  = "elasticsearch.yml"
  }

  provisioner "file" {
    content      = data.template_file.init_backupscript[count.index].rendered
    destination  = "s3_backup_script.sh"

  }

}
resource "null_resource" "start_es" {
  depends_on     = [ 
    null_resource.move_es_file
  ]
  count          = 2
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("~/.ssh/elasticsearch_keypair.pem")
     host        = aws_instance.elastic_nodes[count.index].public_ip
  }
  provisioner "remote-exec" {
    inline = [
      "#!/bin/bash",
      "sudo yum update -y",
      "sudo yum install java-1.8.0 -y",
      "sudo rpm -i <https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.16.1-x86_64.rpm>",
      "sudo systemctl daemon-reload",
      "sudo systemctl enable elasticsearch.service",
      "sudo chmod -R 777 /etc/elasticsearch",
      "sudo sed -i 's@-Xms1g@-Xms${aws_instance.elastic_nodes[count.index].root_block_device[0].volume_size/2}g@g' /etc/elasticsearch/jvm.options",
      "sudo sed -i 's@-Xmx1g@-Xmx${aws_instance.elastic_nodes[count.index].root_block_device[0].volume_size/2}g@g' /etc/elasticsearch/jvm.options",
      # "sudo sed -i 's/#network.host: 192.168.0.1/network.host: 0.0.0.0/g' /etc/elasticsearch/elasticsearch.yml",
      "sudo rm /etc/elasticsearch/elasticsearch.yml",
      "sudo cp elasticsearch.yml /etc/elasticsearch/",
      "sudo systemctl start elasticsearch.service",
    ]
  }
}

# Elastic-Search data nodes setup
resource "aws_key_pair" "elastic_datanode_ssh_key" {
  key_name="elasticsearch_datanode_ssh"
  public_key= file("~/.ssh/elasticsearch_keypair.pub")
}
resource "aws_instance" "elastic_datanodes" {
  count                  = 1
  ami                    = var.elastic_aws_ami
  instance_type          = var.elastic_aws_instance_type
  # subnet_id              = aws_subnet.elastic_subnet[var.azs[count.index]].id
  subnet_id              = var.public_subnet_ids[count.index]
  vpc_security_group_ids = [aws_security_group.elasticsearch_sg.id]
  key_name               = aws_key_pair.elastic_ssh_key.key_name
  iam_instance_profile   = "${aws_iam_instance_profile.elastic_ec2_instance_profile.name}"
  associate_public_ip_address = true
  tags = {
    Name = "elasticsearch dev node-${count.index + 2}"
  }
}
data "template_file" "init_es_datanode" {
  depends_on = [ 
    aws_instance.elastic_datanodes
  ]
  count          = 1
  template = file("./elasticsearch/configs/elasticsearch_datanode_config.tpl")
  vars = {
    cluster_name = "elasticsearch_cluster"
    node_name    = "datanode_${count.index}"
    node         = aws_instance.elastic_datanodes[count.index].private_ip
    node1        = aws_instance.elastic_nodes[0].private_ip
    node2        = aws_instance.elastic_nodes[1].private_ip
    node3        = aws_instance.elastic_datanodes[0].private_ip
  }
}

data "template_file" "init_backupscript_datanode" {
  depends_on = [ 
    aws_instance.elastic_datanodes
  ]
  count          = 1
  template = file("./elasticsearch/configs/s3_backup_script.tpl")
  vars = {
    cluster_name = "elasticsearch_cluster"
    node         = aws_instance.elastic_datanodes[count.index].private_ip
    node1        = aws_instance.elastic_nodes[0].private_ip
    node2        = aws_instance.elastic_nodes[1].private_ip
    node3        = aws_instance.elastic_datanodes[0].private_ip
  }
}

# Uncomment following if you want to attach elastic IP to your data nodes.
# resource "aws_eip" "elasticsearch_datanode_eip"{
#     count     = 1
#     instance  = element(aws_instance.elastic_datanodes.*.id, count.index)
#     vpc       = true

#     tags = {
#     Name = "elasticsearch-eip-datanode-${count.index + 1}"
#   }
# }

resource "null_resource" "move_es_datanode_file" {
  count          = 1
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("~/.ssh/elasticsearch_keypair.pem")
     host        = aws_instance.elastic_datanodes[count.index].public_ip
  } 
  provisioner "file" {
    content      = data.template_file.init_es_datanode[count.index].rendered
    destination  = "elasticsearch_datanode.yml"
  }

  provisioner "file" {
    content      = data.template_file.init_backupscript_datanode[count.index].rendered
    destination  = "s3_backup_script.sh"

  }

}
resource "null_resource" "start_es_datanodes" {
  depends_on     = [ 
    null_resource.move_es_datanode_file
  ]
  count          = 1
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("~/.ssh/elasticsearch_keypair.pem")
     host        = aws_instance.elastic_datanodes[count.index].public_ip
  }
  provisioner "remote-exec" {
    inline = [
      "#!/bin/bash",
      "sudo yum update -y",
      "sudo yum install java-1.8.0 -y",
      "sudo rpm -i <https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.16.1-x86_64.rpm>",
      "sudo systemctl daemon-reload",
      "sudo systemctl enable elasticsearch.service",
      "sudo chmod -R 777 /etc/elasticsearch",
      "sudo sed -i 's@-Xms1g@-Xms${aws_instance.elastic_datanodes[count.index].root_block_device[0].volume_size/2}g@g' /etc/elasticsearch/jvm.options",
      "sudo sed -i 's@-Xmx1g@-Xmx${aws_instance.elastic_datanodes[count.index].root_block_device[0].volume_size/2}g@g' /etc/elasticsearch/jvm.options",
      # "sudo sed -i 's/#network.host: 192.168.0.1/network.host: 0.0.0.0/g' /etc/elasticsearch/elasticsearch.yml",
      "sudo rm /etc/elasticsearch/elasticsearch.yml",
      "sudo cp elasticsearch_datanode.yml /etc/elasticsearch/elasticsearch.yml",
      "sudo systemctl start elasticsearch.service"
    ]
  }
}

3. Set-up Kibana

resource "aws_security_group" "kibana_sg" {
  vpc_id = aws_vpc.elastic_stack_vpc.id
  ingress {
    description = "ingress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 22
    protocol = "tcp"
    to_port = 22
  }
  ingress {
    description = "ingress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 5601
    protocol = "tcp"
    to_port = 5601
  }
  egress {
    description = "egress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 0
    protocol = "-1"
    to_port = 0
  }
  tags={
    Name="kibana_security_group"
  }
}

Kibana:

# Kibana setup
resource "aws_instance" "kibana" {
  depends_on = [ 
    null_resource.start_es
   ]
  ami                    = "ami-0ed9277fb7eb570c9"
  instance_type          = "t2.small"
  subnet_id              = aws_subnet.elastic_subnet[var.az_name[0]].id
  vpc_security_group_ids = [aws_security_group.kibana_sg.id]
  key_name               = aws_key_pair.elastic_ssh_key.key_name
  associate_public_ip_address = true
  tags = {
    Name = "kibana"
  }
}
data "template_file" "init_kibana" {
  depends_on = [ 
    aws_instance.kibana
  ]
  template = file("./configs/kibana_config.tpl")
  vars = {
    elasticsearch = aws_instance.elastic_nodes[0].public_ip
  }
}
resource "null_resource" "move_kibana_file" {
  depends_on = [ 
    aws_instance.kibana
   ]
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("elasticsearch_keypair.pem")
     host        = aws_instance.kibana.public_ip
  } 
  provisioner "file" {
    content     = data.template_file.init_kibana.rendered
    destination = "kibana.yml"
  }
}

resource "null_resource" "install_kibana" {
  depends_on = [ 
      aws_instance.kibana
   ]
  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("elasticsearch_keypair.pem")
    host        = aws_instance.kibana.public_ip
  } 
  provisioner "remote-exec" {
    inline = [
      "sudo yum update -y",
      "sudo rpm -i <https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.16.1-x86_64.rpm>",
      "sudo rm /etc/kibana/kibana.yml",
      "sudo cp kibana.yml /etc/kibana/",
      "sudo systemctl start kibana"
    ]
  }
}

4. Set-up LogStash

This takes up logs sent by Filebeats and applies filters to them before sending them to ElasticSearch. For this, add the inbound rule to port 5044.

resource "aws_security_group" "logstash_sg" {
  vpc_id = aws_vpc.elastic_stack_vpc.id
  ingress {
    description = "ingress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 22
    protocol = "tcp"
    to_port = 22
  }
  ingress {
    description = "ingress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 5044
    protocol = "tcp"
    to_port = 5044
  }
  egress {
    description = "egress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 0
    protocol = "-1"
    to_port = 0
  }
  tags={
    Name="logstash_sg"
  }
}

LogStash:

resource "aws_instance" "logstash" {
  depends_on = [ 
    null_resource.install_kibana
   ]
  ami                    = "ami-04d29b6f966df1537"
  instance_type          = "t2.large"
  subnet_id              = aws_subnet.elastic_subnet[var.az_name[0]].id
  vpc_security_group_ids = [aws_security_group.logstash_sg.id]
  key_name               = aws_key_pair.elastic_ssh_key.key_name
  associate_public_ip_address = true
  tags = {
    Name = "logstash"
  }
}

data "template_file" "init_logstash" {
  depends_on = [ 
    aws_instance.logstash
  ]
  template = file("./logstash_config.tpl")
  vars = {
    elasticsearch = aws_instance.elastic_nodes[0].public_ip
  }
}

resource "null_resource" "move_logstash_file" {
  depends_on = [ 
    aws_instance.logstash
   ]
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("tf-kp.pem")
     host        = aws_instance.logstash.public_ip
  } 
  provisioner "file" {
    content     = data.template_file.init_logstash.rendered
    destination = "logstash.conf"
  }
}

resource "null_resource" "install_logstash" {
  depends_on = [ 
      aws_instance.logstash
   ]
  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("tf-kp.pem")
    host        = aws_instance.logstash.public_ip
  } 
  provisioner "remote-exec" {
    inline = [
      "sudo yum update -y && sudo yum install java-1.8.0-openjdk -y",
      "sudo rpm -i <https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.16.1-x86_64.rpm>",
      "sudo cp logstash.conf /etc/logstash/conf.d/logstash.conf",
      "sudo systemctl start logstash.service"
    ]
  }
}

5. Filebeat Setup

It takes logs from /var/logs/ and sends them to LogStash on port 5044.

resource "aws_security_group" "filebeat_sg" {
  vpc_id = aws_vpc.elastic_stack_vpc.id
  ingress {
    description = "ingress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 22
    protocol = "tcp"
    to_port = 22
  }
  egress {
    description = "egress rules"
    cidr_blocks = [ "0.0.0.0/0" ]
    from_port = 0
    protocol = "-1"
    to_port = 0
  }
  tags={
    Name="filebeat_sg"
  }
}

Filebeat:

resource "aws_instance" "filebeat" {
  depends_on = [ 
    null_resource.install_logstash
   ]
  ami                    = "ami-04d29b6f966df1537"
  instance_type          = "t2.large"
  subnet_id = aws_subnet.elastic_subnet[var.az_name[0]].id
  vpc_security_group_ids = [aws_security_group.filebeat_sg.id]
  key_name               = aws_key_pair.elastic_ssh_key.key_name
  associate_public_ip_address = true
  tags = {
    Name = "filebeat"
  }
}

resource "null_resource" "move_filebeat_file" {
  depends_on = [ 
    aws_instance.filebeat
   ]
  connection {
     type        = "ssh"
     user        = "ec2-user"
     private_key = file("tf-kp.pem")
     host        = aws_instance.filebeat.public_ip
  } 
  provisioner "file" {
    source      = "filebeat.yml"
    destination = "filebeat.yml"
  }
}

resource "null_resource" "install_filebeat" {
  depends_on = [ 
    null_resource.move_filebeat_file
   ]
  connection {
    type        = "ssh"
    user        = "ec2-user"
    private_key = file("tf-kp.pem")
    host        = aws_instance.filebeat.public_ip
  } 
  provisioner "remote-exec" {
    inline = [
      "sudo yum update -y",
      "sudo rpm -i <https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.16.1-x86_64.rpm>",
      "sudo sed -i 's@kibana_ip@${aws_instance.kibana.public_ip}@g' filebeat.yml",
      "sudo sed -i 's@logstash_ip@${aws_instance.logstash.public_ip}@g' filebeat.yml",
      "sudo rm /etc/filebeat/filebeat.yml",
      "sudo cp filebeat.yml /etc/filebeat/",
      "sudo systemctl start filebeat.service"
    ]
  }
}

Now, you have successfully set up Elastic Stack on AWS EC2 using Terraform.

Visit, <public_ip_of_any_es_node>:9200/_cluster/health to see ElasticSearch Status

Visit, <public_ip_of_any_es_node>:9200/_cat/nodes?v to see ElasticSearch nodes

Visit, <public_ip_of_kibana_instance>:5601/_cluster/health to see Kibana

After accessing Kibana, go to settings > Index Patterns > Add the logstash index

To check logs, SSH into each component and run the command:

$ sudo systemctl status <component-name> -l

Then SSH int Filebeat EC2 instance and add sample .log file inside /var/log/ . And you can search for the logs inside the Kibana dashboard.

For a sample log run the following and see a record on Kibana:

echo "echo 'This is a sample log for test' >> /var/log/test-log.log" | sudo bash

That’s It.

Conclusion

Congratulations, you have successfully learned about how to set up Elastic Stack on AWS EC2 using Terraform.

Thank You!

Docker is a Containerization platform that simplifies packaging, deploying, and running applications. It bundles applications and their dependencies into CONTAINERS, ensuring consistent behavior across different environments. Docker enhances efficiency and reliability, supports microservices and scalable applications, and provides tools for managing containers and secure environments. Dockerfiles define application environments, and container images can be shared across teams. Docker revolutionizes modern software development by improving development, testing, and deployment processes.

What is containerization? 📦

Containerization is a lightweight form of virtualization that encapsulates an application and its dependencies into a unit called a "container." This container includes everything needed to run the application, ensuring it works consistently across different environments. Unlike traditional virtual machines, containers share the host system's OS kernel, making them more efficient and faster to start. This approach simplifies deployment, enhances scalability and portability, and enables rapid, reliable development.

By isolating applications, containerization minimizes software conflicts and streamlines management.

Difference between VMs & Containers

Learning Resource:

Containers vs VM - Difference Between Deployment Technologies - AWS

Advantages of Containerization

• Increased Portability

• Easier Scalability

• Easy and Fast Deployments

• Better Productivity

• Improved Security

• Consistent test environment for development and QA.

• Cross-platform packages called images.

• Isolation and encapsulation of application dependencies.

• Ability to scale efficiently, easily, and in real time.

• Enhances efficiency via easy reuse of images.

Disadvantage

• Compatibility issue: Windows container won’t run on Linux machines and vice-versa

Other disadvantages(I’m Marcopolo of these discoveries) 😎

• Counter-productivity or efficiency-draining issue: Hard to turn a 5-minute task into a 5-hour task

• Troubleshooting issue: It will be hard, to be able to find tons of dependency issues

Installation:

Get Docker

Docker Architecture

Docker uses a client-server architecture to manage and run containers:

1. Docker Client:

   • The Docker client is the command-line interface (CLI) or graphical user interface (GUI) that users interact with to build, manage, and control Docker containers.

   • It sends commands to the Docker daemon to perform various tasks.

2. Docker Daemon:

   • The Docker daemon is a background process that manages Docker containers on a host system.

   • It listens for Docker API requests and takes care of building, running, and managing containers.

3. Docker Registry:

   • Docker images can be stored and shared through Docker registries.

   • A Docker registry is a repository for Docker images, and it can be public (like Docker Hub) or private.

4. Docker Hub:

   • Docker Hub is a cloud-based registry service provided by Docker, where users can find, share, and store Docker images.

   • It serves as a central repository for Docker images.

Here's a high-level overview of how Docker components interact:

• The Docker client sends commands to the Docker daemon and receives information about containers and images.

• Docker images are fetched or built from the Docker registry.

• The Docker daemon handles the creation, starting, stopping, and management of containers.

Docker Workflow

More on Docker? - Ufffsss!!!!!

Dockerfile Instructions

Please click here.

Docker Image

A Docker image is a read-only template with instructions to create a container on the Docker platform. It is the starting point for anyone new to Docker.

Time for a Hands-On? - YEAHHHHH!!!!!

Challenges 😎

Challenge 1

Run a container with the nginx:1.14-alpine image and name it webapp

docker run -p 5000:80 --name webapp -d nginx:1.14-alpine

Challenge 2

Containerize Python application and push the image to DockerHub

Step 1 - Create Python/NodeJS app. (Clone from GitHub) =>Python OR NodeJS

Step 2 - Write Dockerfile for the app

Step 3 - Create image for the app

Step 4 - Run the container for the app

Step 5 - If it works push the image on DockerHub

ENV variables

• Purpose: Environment variables in Docker are used to configure applications, control runtime behavior, and manage sensitive information.

• Configuration: They replace hardcoded values in configuration files, enabling flexibility across different environments.

• Dynamic Behavior: Environment variables can control feature toggles, logging levels, and runtime environments.

• Secrets Management: Sensitive data like passwords or API keys can be securely injected into containers using environment variables.

• Setting Variables:

  • Use ENV instruction in Dockerfile to set variables during image build.

  • Pass variables with -e or --env flag in docker run command.

  • Define them in docker-compose.yml under the environment key.

  • In Docker Swarm, set them with docker service create/update or in a Docker Compose file for Swarm.

• Flexibility and Portability: Environment variables make Dockerized applications easier to manage and deploy across diverse environments.

Challenge 3

Run a container named shrawan-app using image sbmagar/blogging-app and set the environment variable APP_COLOR to green. Make the application available on port 75666 on the host. The application listens on port 5000.

• Solution

    docker run -d \\
    --name shrawan-app \\
    -p 75666:5000 \\
    -e APP_COLOR=green \\
    sbmagar/blogging-app
  

Commands & Arguments

Here, I'll just talk about main two arguments: CMD and ENTRYPOINT 😎:

CMD

# Use a base image
FROM alpine:latest

# Run a sleep command when the container starts
CMD ["sleep", "3600"]

CMD ["sleep", "3600"] ✅

CMD ["sleep 3600"] ❌

it's recommended to use the first form (CMD ["sleep", "3600"]) to specify the command and its arguments as separate elements in a JSON array for clarity and to ensure proper execution.

ENTRYPOINT

ENTRYPOINT is a Dockerfile instruction that sets the main command to run when a container starts. It ensures the specified command is executed, unlike CMD which provides default arguments to the command.

FROM alpine:latest

# Set the sleep command as the entry point
ENTRYPOINT ["sleep"]

# Set a default sleep time of 3600 seconds (1 hour)
CMD ["3600"]

Explanation:

• This Dockerfile starts with a base image of Alpine Linux.

• The ENTRYPOINT instruction specifies that the sleep command will be the main command to run when the container starts.

• The CMD instruction sets a default argument for the sleep command, specifying the sleep time in seconds. In this case, the default sleep time is 3600 seconds (1 hour).

Override arguments

docker run my_image **1800**   # Sleeps for 1800 seconds (30 minutes)

Communication Between containers.

for multiple containers dependent on one another we can command line argument —link

When using the --link option in Docker:

• A secure tunnel is created between containers for communication.

• Environment variables are set in the destination container, providing details about the linked container.

• Docker updates the /etc/hosts file in the destination container to resolve the hostname of the linked container.

• Access to exposed ports in the linked container is provided.

• Example

  1. Run MySQL Container: Start the MySQL container with a name mysql-container, exposing port 3306:

      docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=password -d mysql:latest
     

  2. Create a .NET Core Application: Assume you have a .NET Core application that needs to connect to the MySQL database. Build the .NET Core application and create a Docker image for it. Here's a simple Dockerfile assuming the application is published to a folder named app:

      FROM mcr.microsoft.com/dotnet/core/runtime:latest
      WORKDIR /app
      COPY ./app .
      ENTRYPOINT ["dotnet", "YourApp.dll"]
     

  3. Run .NET Core Application Container Linked to MySQL: Now, run the .NET Core application container, linking it to the MySQL container:

      docker run --name dotnet-app --link mysql-container:mysql -d your-dotnet-image:latest
     

In this example:

• -name mysql-container names the MySQL container mysql-container.

• e MYSQL_ROOT_PASSWORD=password sets the MySQL root password.

• -name dotnet-app names the .NET Core application container dotnet-app.

• -link mysql-container:mysql links the .NET Core application container to the MySQL container with the alias mysql.

• d runs both containers in detached mode.

Inside the .NET Core application container, you can access the MySQL database using the hostname mysql and the exposed port. Ensure your .NET Core application is set up to connect to MySQL using the correct hostname and port.

Docker Compose

To run multiple containers with one command, use a configuration file. Here are some Docker commands:

• docker run --name redis redis:alpine

• docker run --name redis -d redis:alpine

• docker rm redis

• docker run --name redis -d redis:alpine

• docker run --name luckydrawapp --link redis:redis -p 5000:5000 luckydraw-app:latest

• docker rm luckydrawapp

• docker run --name luckydrawapp --link redis:redis -d -p 8085:5000 luckydraw-app:latest

version: '3.0'
services:
    redis:
        image: redis:alpine
    luckydrawapp:
        image: luckydraw-app:latest
        ports:
            - 5000:5000

Docker Volumes

Docker volumes allow you to save data created and used by Docker containers. They enable data sharing between a host machine and Docker containers or between different containers.

Types of Volumes

1. Named Volumes: Managed by Docker, easier to use and manage.

2. Host Volumes: Maps a directory from the host machine into the container.

3. Anonymous Volumes: Similar to named volumes but managed by Docker with a randomly generated name.

Commands:

1. Create a named volume:

    docker volume create my_volume
   

2. Run a container with a named volume:

    docker run -v my_volume:/path/in/container image_name
   

3. List all volumes:

    docker volume ls
   

4. Inspect a volume:

    docker volume inspect my_volume
   

5. Remove a volume:

    docker volume rm my_volume
   

6. Mount a host directory as a volume:

    docker run -v /host/path:/container/path image_name
   

Dockerfile Example

# Define a volume
VOLUME /data

# Set working directory
WORKDIR /data

# Copy files into the container
COPY . /data

Docker Compose Example

version: '3.8'

services:
  app:
    image: my_app_image
    volumes:
      - my_volume:/app/data

volumes:
  my_volume:
    external: true

Key Points

• Volumes are useful for persisting data even if containers are removed.

• They can be shared between containers.

• Docker volumes are stored in a part of the host filesystem managed by Docker.

These notes provide a solid overview of Docker volumes, including practical examples and commands. They cover named, host, and anonymous volumes, along with how to create, run, list, inspect, and remove volumes. Examples using Dockerfile and Docker Compose are also included. Let me know if you need more details on any topic!

https://docs.docker.com/compose/

https://docs.docker.com/engine/reference/commandline/compose/

What you’ll get

You’ll learn to:

• Install a local Kubernetes instance by using minikube on Linux, macOS, or Windows.

• Expose ingress for services outside of the Kubernetes cluster.

• Additionally, configure the hostname to your ingress IP.

Minikube

minikube is an open-source utility that allows you to quickly deploy a local Kubernetes cluster on your personal computer. By using virtualization technologies, minikube creates a virtual machine (VM) that contains a single-node Kubernetes cluster. VMs are virtual computers and each VM is allocated its own system resources and operating system.

The latest minikube releases also allow you to create your cluster by using containers instead of virtual machines. Nevertheless, this solution is still not mature, and it is not supported for this course.

And, minikube is compatible with Linux, macOS, and Windows operating systems.

Note: Installing a local Kubernetes cluster needs administrative privileges in your system. If you do not have administrative privileges then you can’t use the Kubernetes cluster locally. In such a case, you can use a remote Kubernetes cluster. e.g. Redhat’s OpenShift

Prerequisites

• At least 2 GB of free memory

• 2 CPUs or more

• At least 20 GB of free disk space

• A locally installed hypervisor (using a container runtime is not supported in this course)

Let’s install minikube first.

Note: You must install or enable hypervisor technology on your system before installing minikube. Hypervisor is software that is used to create and manage virtual machines on a shared physical hardware system.

Step-1: Install minikube

This tutorial is for Linux systems only, to set up on MacOS or Windows follow the official documentation: minikube installation.

The preferred hypervisor for Linux systems is kvm2. minikube communicates with the hypervisor using the libvirt virtualization API libraries.

Note: Prefix the following commands with sudo if you are running a user without administrative privileges.

Install virtualization libraries (for other than Ubuntu use respective package manager and libraries — google it):

# For Ubuntu/Debian
$ sudo apt update
$ sudo apt -y install qemu-kvm libvirt-daemon bridge-utils virtinst libvirt-daemon-system

Start the libvirtd service:

$ systemctl start libvirtd
$ systemctl enable libvirtd

OR,

You can use VirtualBox to use Minikube.

To install VirtualBox run the following command in Linux:

# for Arch Linux
$ sudo pacman -S virtualbox 

# for Ubuntu
$ sudo apt-get update
$ sudo apt-get install virtualbox
$ sudo apt-get install virtualbox—ext–pack

1.2) Install Minikube on Linux

• If your system contains a package manager or software manager including minikube, then use it and verify the version matches the minimum requirements.

$ sudo apt install minikube

# For Arch Linux
$ sudo pacman -S minikube

1.3) Start Minikube Cluster on Linux

To initialize your minikube cluster, use the minikube start command. (I’m using Arch Linux with virtualbox — you can use kvm2)

$ minikube start --driver=virtualbox minikube v1.33.1 on Arch "rolling" ▪ KUBECONFIG=/home/sagar/.kube/confi
✨ Using the virtualbox driver based on existing profile
👍 Starting control plane node minikube in cluster minikube
🔄 Restarting existing virtualbox VM for "minikube" ...
🎉 minikube 1.26.1 is available! Download it: 
💡 To disable this notice, run: 'minikube config set WantUpdateNotification false' 🐳 Preparing Kubernetes v1.33.1 on Docker 24.0.5 ... ▪ kubelet.housekeeping-interval=5m ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5 ▪ Using image kubernetesui/dashboard:v2.3.1 ▪ Using image kubernetesui/metrics-scraper:v1.0.7 ▪ Using image k8s.gcr.io/ingress-nginx/controller:v1.1.1 ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1 ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
🔎 Verifying Kubernetes components...
🔎 Verifying ingress addon...
🌟 Enabled addons: storage-provisioner, default-storageclass, ingress, dashboard
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaul

Note: To set the default driver, run the commandminikube config set driver DRIVER.

Step-2: Verify Minikube installation

Use the minikube status command to validate that the minikube installation is running successfully:

$ minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

If any errors please ensure the driver is set up correctly or refer to Minikube Get Started documentation for troubleshooting.

Step-3: Add extensions to Minikube

To add more features to your minikube, it provides an add-on-based extension system so that one can add more features by installing the needed add-ons.

To view the list of add-ons available and installation status use the following command:

$ minikube addons list

minikube addons list
|-----------------------------|----------|--------------|--------------------------------|
|         ADDON NAME          | PROFILE  |    STATUS    |           MAINTAINER           |
|-----------------------------|----------|--------------|--------------------------------|
| ambassador                  | minikube | disabled     | third-party (ambassador)       |
| auto-pause                  | minikube | disabled     | google                         |
| csi-hostpath-driver         | minikube | disabled     | kubernetes                     |
| dashboard                   | minikube | disabled     | kubernetes                     |
| default-storageclass        | minikube | enabled ✅   | kubernetes                     |
| efk                         | minikube | disabled     | third-party (elastic)          |
| freshpod                    | minikube | disabled     | google                         |
| gcp-auth                    | minikube | disabled     | google                         |
| gvisor                      | minikube | disabled     | google                         |
| helm-tiller                 | minikube | disabled     | third-party (helm)             |
| ingress                     | minikube | disabled     | unknown (third-party)          |
| ingress-dns                 | minikube | disabled     | google                         |
| istio                       | minikube | disabled     | third-party (istio)            |
...

In my output, you can see I have only default add-ons (Right tick with enabled status). Other are available add-ons for your Minikube.

To enable add ons run the following command:

$ minikube addons enable ingress

    ▪ Using image k8s.gcr.io/ingress-nginx/controller:v1.1.1
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
    ▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled

As in my Output, versions and docker images can vary in your case, but make sure the final validation is successful.

Also, let’s enable the dashboard add-on with the following command:

$ minikube addons enable dashboard

    ▪ Using image kubernetesui/dashboard:v2.3.1
    ▪ Using image kubernetesui/metrics-scraper:v1.0.7
💡  Some dashboard features require the metrics-server addon. To enable all features please run:
        minikube addons enable metrics-server
🌟  The 'dashboard' addon is enabled

Now see the addons status by re-running the list command:

$ minikube addons list

|-----------------------------|----------|--------------|--------------------------------|
|         ADDON NAME          | PROFILE  |    STATUS    |           MAINTAINER           |
|-----------------------------|----------|--------------|--------------------------------|
| ambassador                  | minikube | disabled     | third-party (ambassador)       |
| auto-pause                  | minikube | disabled     | google                         |
| csi-hostpath-driver         | minikube | disabled     | kubernetes                     |
| dashboard                   | minikube | enabled ✅   | kubernetes                     |
| default-storageclass        | minikube | enabled ✅   | kubernetes                     |
| efk                         | minikube | disabled     | third-party (elastic)          |
| freshpod                    | minikube | disabled     | google                         |
| gcp-auth                    | minikube | disabled     | google                         |
| gvisor                      | minikube | disabled     | google                         |
| helm-tiller                 | minikube | disabled     | third-party (helm)             |
| ingress                     | minikube | enabled ✅   | unknown (third-party)          |
| ingress-dns                 | minikube | disabled     | google                         |
| istio                       | minikube | disabled     | third-party (istio)            |
| istio-provisioner           | minikube | disabled     | third-party (istio)            |
...

As you can see, from my output, dashboard, and ingress are enabled.

Note: Here, Ingress is installed so that an IP is assigned to the minikube using that we can expose our kubernets cluster to outside the cluster. i.e. access from outside K8s cluster.

Once the dashboard is enabled you can open it by using the minikube dashboard command. This command will open the dashboard in your web browser.

$ minikube dashboard 🤔 Verifying dashboard health ...
🚀 Launching proxy ...
🤔 Verifying proxy health ...
🎉 Opening  in your default browser...
Gtk-Message: 14:38:42.184: Failed to load module "appmenu-gtk-module"
Opening in existing browser session.

Browser output:

Press Ctrl+C in the terminal to stop the connection.

Step-4: Enable external access to Minikube Ingress

Now using the external Minikube IP and hostname associated with our Ingress we can access from outside the Kubernetes cluster.

4.1) External access to Minikube

Routing traffic from your local machine to your Minikube Kubernetes cluster requires two steps.

First, you must find the local IP assigned to your Ingress add-on. To find the ingress IP run the following command:

$ minikube ip

192.168.59.109

Your IP might be different as it depends on your virtual environment configuration.

Now you can access Kubernetes applications from outside the K8s cluster (from a local machine) using this IP.

Additional Step

In this step, you will be configuring the hostname to your Minikube ingress IP, so that you can use hostname instead of IP.

To do this follow the steps:

# Linux or MacOS
$ sudo nano /etc/hosts

For windows go to C:\\Windows\\System32\\drivers\\etc\\hosts and edit with administrative privileges.

 test.example.com

Replace with your minikub ingress IP. In my case hosts file look like this:

# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1       localhost
::1             localhost
127.0.1.1       arch_linux

# Minikube ingress IP
192.168.59.109  dev.sagar.com

Here, I have declared dev.sagar.com as the hostname for my kubernetes minikube ingress IP.

 test.example.com

Note: If you delete and recreate your minikube cluster, then you have to update IP address assigned to the hosts file accordingly.

Now, you can access services in the cluster with the hostname and the relative path associated with the ingress. For example, if your application is mapped to the path /demoapp you can access it using the hostname http://test.example.com/demoapp. For my case http://dev.sagar.com/demoapp.

That’s it!

In this tutorial, we talked about how we can create a local Kubernetes cluster with Minikube and make it accessible from the outside of the Kubernetes cluster.

Thank you!

It's not required to use Let's Encrypt to obtain an SSL, you have the flexibility to use any Certificate Authority you choose.

This is the tutorial to help you to install the Let's Encrypt client on Ubuntu 20.04 Linux system.

Prerequisites:

• A running Ubuntu system with non-root, sudo enabled user.

• A fully registered domain name pointed to the ubuntu server.

• Server running engine Nginx or apache. (We will use Nginx for this tutorial)

• Port 80 or 443 must be unused on your server.

Note: Installation method is the same for Apache too, only the plugins used are different.

Installation:

1. Installing Certbot

Snap package is the easiest way for installing certbot on the Ubuntu system. Snap packages work on nearly all Linux flavors, but they required that you've installed snapd first in order to manage snap packages. Actually, Certbot is a third-party service that makes it easier to install Let's Encrypt. First SSH to the server, update the repository server:

sudo apt update && upgrade -y

After the system has been successfully updated and upgraded, download services or packages that support(is required) the running of Certbot Let's Encrypt.

sudo apt install certbot python3-certbot-nginx

Once done, confirm the Nginx Virtualhost configuration. The nginx virtualhost is the one that guarantees success in installing Let's Encrypt. And Certbot will check Nginx to generate SSL using Let's Encrypt.

2. Nginx Virtualhost configuration

To create a Certbot SSL certificate, make sure the domain or subdomain is registered on the Virtualhost Nginx web server.

Open the file vim /etc/nginx/sites-available/your_domain.conf and edit server_name with your domain.

vim /etc/nginx/sites-available/your.domain.conf

...
...
server {
         listen 80 default_server;
         root /var/www/html;
         if ($http_user_agent ~* LWP::Simple|BBBike|wget) {
         return 403;
         }
         index index.html index.htm index.nginx-debian.html;
         server_name your.domain.com
         return 404;
...
...

If server_name matches the target Let's Encrypt is going to register. Test the Nginx service.

Nginx testing:

After the configuration has been saved, use the following command to check the status:

nginx -t

On correct configuration output will be:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart the Nginx service:

sudo systemctl restart nginx

3. Allow HTTPS

You have to open ports 80 and 443, namely HTTP and HTTPS to be able to enter and exit the server through the firewall.

Check the firewall status:

ufw status

If the firewall is Inactive, you can continue to the next step. But firewall turn on is recommended since it protects the server from external attacks.

Now, add permissions for ports 80 and 443 i.e HTTP and HTTPS:

ufw allow http
ufw allow https
ufw allow ssh

Then enable Firewall/UFW:

ufw enable

check status:

ufw status

Output will be:

Status: active

To                         Action      From
--                         ------      ----
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
244                        ALLOW       Anywhere
80/tcp (v6)                ALLOW       Anywhere (v6)
443/tcp (v6)               ALLOW       Anywhere (v6)
244 (v6)

Finally, you can run Certbot and generate certificates.

4. Generate SSL

Since we're using Nginx plugin we can create certificate for DNS your.domain.com as:

certbot --nginx -d your.domain.com

Which will create certificate for the domain we are requesting, answer some questions for SSL. (email, agree terms, etc.) After that Let's Encrypt SSL certificate will be generated in /etc/nginx/sites-available/ directory for your domain.

Output

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

The certificate is only valid for 90 days, we must renew the certificate every time it expires. Good thing is Certbot that has been installed already provides a service for updating scrips to cron-job (/etc/cron.d/).

systemctl status certbot.timer

Output will be:

● certbot.timer - Run certbot twice daily
   Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Thu 2021-12-23 00:56:59 UTC; 1 months 17 days ago
  Trigger: Wed 2022-02-09 23:47:10 UTC; 18h left

This command will run twice a day and will renew every 30 days from the expiration date.

Test the update and ensure the renewal process works:

certbot renew --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/your.domain.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for your.domain.com
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/your.domain.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/your.domain.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for your.domain.com
Waiting for verification...
Cleaning up challenges

That's it.

If the automatic renewal fails, Certbot sends an error message to the email that was registered at the time of generating the certificate.

Explore more DevOps blogs of mine: https://scanskill.com/profile/sagar

Thank you!

GitLab Server

GitLab allows you to host an on-premise GitLab server(or Git repository) that can be accessed from LAN(or WAN if you have a public IP address).

We can install the GitLab server either on a container environment like docker or on the host machine. In this, I’ll install it on the host machine (i.e. Ubuntu 20.04 machine).

Prerequisites

• Machine with at least 2 cores and 4GB of memory.

On-Premise GitLab Server

On-Premise Installation

Step-1: Update System and Install Required Dependencies

Open the terminal on the server(machine) and run the following commands:

$ sudo apt update
$ sudo apt upgrade -y

After running these, let’s install some dependencies by running:

$ sudo apt install -y ca-certificates curl openssh-server tzdata perl

Step-2: Install Postfix for Email Notifications (Optional)

Optionally, if you want to use the same system or server to send email notifications to users, then you can install postfix, an open-source mail transfer agent.

$ sudo apt install postfix -y

While installing Postfix you’ll be asked to set it up, select ‘Internet Site’ option and add your DNS for mail name and configure other required things.

Further, you’ll need to install the mailutils package:

$ sudo apt install mailutils

OR, you can set up SMTP server to send email notifications instead of Postfix. To do this, you need to first install GitLab and edit /etc/gitlab/gitlab.rb.

Step-3: Add GitLab Package Repository and GPG Key

As the GitLab is not available on the base repository of Ubuntu. You need to add the GitLab package repository and GPG key by running the following command:

$ curl -sS <https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh> | sudo bash

Here, I’ve added a package repository for GitLab Enterprise Edition, you can also add for GitLab Community Edition.

After adding the repository package, you can see the repository contents in:

$ cat /etc/apt/sources.list.d/gitlab_gitlab-ce.list

Step-4: Install GitLab EE on Ubuntu (22.04 | 20.04 | 18.04)

Now update the system again and install GitLab EE on the machine:

$ sudp apt update
$ sudp apt install gitlab-ee

You’ll see output similar:

It looks like GitLab has not been configured yet; skipping the upgrade script.

       *.                  *.
      ***                 ***
     *****               *****
    .******             *******
    ********            ********
   ,,,,,,,,,***********,,,,,,,,,
  ,,,,,,,,,,,*********,,,,,,,,,,,
  .,,,,,,,,,,,*******,,,,,,,,,,,,
      ,,,,,,,,,*****,,,,,,,,,.
         ,,,,,,,****,,,,,,
            .,,,***,,,,
                ,*,.


     _______ __  __          __
    / ____(_) /_/ /   ____ _/ /_
   / / __/ / __/ /   / __ `/ __ \\
  / /_/ / / /_/ /___/ /_/ / /_/ /
  \\____/_/\\__/_____/\\__,_/_.___/


Thank you for installing GitLab!

Now edit external_url in /etc/gitlab/gitlab.rb to set hostname. You can also configure other parameters. Replace gitlab.example.com with valid domain name.

$ sudo nano /etc/gitlab/gitlab.rb
external_url "<http://gitlab.example.com>"

OR, If you’re not going to use DNS. You can simply use your server’s IP address like in my case my local machine’s IP as:

external_url "<http://10.10.5.55>"

When done start GitLab by running the following command:

$ sudo gitlab-ctl reconfigure

After successful reconfiguration, check the status of GitLab:

$ sudo gitlab-ctl status

The output will be similar:

run: alertmanager: (pid 92581) 18s; run: log: (pid 92343) 80s
run: gitaly: (pid 92590) 18s; run: log: (pid 91561) 189s
run: gitlab-exporter: (pid 92551) 20s; run: log: (pid 92078) 98s
run: gitlab-kas: (pid 92520) 22s; run: log: (pid 91845) 175s
run: gitlab-workhorse: (pid 92531) 21s; run: log: (pid 91985) 117s
run: grafana: (pid 92610) 17s; run: log: (pid 92471) 38s
run: logrotate: (pid 91486) 202s; run: log: (pid 91494) 201s
run: nginx: (pid 91993) 114s; run: log: (pid 92013) 110s
run: node-exporter: (pid 92540) 21s; run: log: (pid 92049) 104s
run: postgres-exporter: (pid 92601) 18s; run: log: (pid 92367) 76s
run: postgresql: (pid 91693) 184s; run: log: (pid 91704) 183s
run: prometheus: (pid 92560) 20s; run: log: (pid 92297) 88s
run: puma: (pid 91904) 132s; run: log: (pid 91917) 129s
run: redis: (pid 91521) 196s; run: log: (pid 91538) 193s
run: redis-exporter: (pid 92553) 20s; run: log: (pid 92217) 94s
run: sidekiq: (pid 91922) 126s; run: log: (pid 91934) 122s

Step-5: GitLab Web Interface

Once the installation completes, open your URL set up as external_url http://gitlab.example.com on your browser. In my case, I have set it up locally using my server’s IP address. So, I can access it through http://10.10.5.55/

Now, first, you can log in as a root user using username as root and password from /etc/gitlab/intial_root_password. (The password for root user is randomly generated and stored for 24 hours only.)

To check the password run the following:

$ cat /etc/gitlab/initial_root_password

# WARNING: This value is valid only in the following conditions
#          1. If provided manually (either via `GITLAB_ROOT_PASSWORD` environment variable or via `gitlab_rails['initial_root_password']` setting in `gitlab.rb`, it was provided before database was seeded for the first time (usually, the first reconfigure run).
#          2. Password hasn't been changed manually, either via UI or via command line.
#
#          If the password shown here doesn't work, you must reset the admin password following <https://docs.gitlab.com/ee/security/reset_user_password.html#reset-your-root-password>.

Password: dfdfkOtOjWp7v70OjkjtadsdfsafsadnSJAhcDbCNo9nTNGVC5UoSCyE=

# NOTE: This file will be automatically deleted in the first reconfigure run after 24 hours.
Copy the password and login:

After logging in, first reset the root user password. To do this, go to root user profile > Preferences > Password. Change.

You can start, stop or restart all the GitLab components by using the following commands:

$ sudo gitlab-ctl start
$ sudo gitlab-ctl restart
$ sudo gitlab-ctl stop

Also, you can start individual components also:

$ sudo gitlab-ctl restart prometheus

ok: run: prometheus: (pid 2673) 8s

This is all you need to set up GitLab Server on Ubuntu Server.

GitLab Runner

GitLab Runner can be installed:

• In a container(Docker, K8s, or OpenShift)
• By downloading binary manually
• By using repository packages

In this, we’ll be installing Runner on the local machine as I have to deploy microservices on the same machine where GitLab and Runner will be running.

GitLab Runner – Installation

If you’re using a different server for a runner than that GitLab is configured, you need to first ssh into the server and follow the following steps. Otherwise, you can directly follow from step-1.

Step-1: Add Official Repository

First, add the official GitLab Runner Repository using the below command. You can find the Official Repository here.

$ curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

Step-2: Install Runner on Ubuntu (22.04 | 20.04 | 18.04)

Run the following command to install GitLab Runner:

$ sudo apt update
$ sudo apt install gitlab-runner

(Optional) To install a specific version:

$ sudo apt install gitlab-runner=10.0.0

After Installation, check the GitLab Runner version:

$ sudo gitlab-runner --version

Output:

Version:      15.0.0
Git revision: febb2a09
Git branch:   15-0-stable
GO version:   go1.17.7
Built:        2022-05-19T20:03:43+0000
OS/Arch:      linux/amd64

To check the status:

$ sudo gitlab-runner status

Output:

Runtime platform                                    arch=amd64 os=linux pid=29368 revision=febb2a09 version=15.0.0
gitlab-runner: Service is running!

You can Start, Stop, and Restart GitLab Runner by running the following:

$ sudo gitlab-runner start
$ sudo gitlab-runner stop
$ sudo gitlab-runner restart

Step-3: Grant Permission to GitLab Runner User

After successful installation, you’ll see a gitlab-runner user in /home directory. And you need to grant the sudo permission to the gitlab-runner user. For this, open visudo file:

$ sudo visudo

Add the following in sudoers group and set NOPASSWD also as shown below:

gitlab-runner ALL=(ALL:ALL) ALL

gitlab-runner ALL=(ALL) NOPASSWD: ALL

Output:

GNU nano 4.8                                /etc/sudoers.tmp
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root    ALL=(ALL:ALL) ALL
gitlab-runner ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
gitlab-runner ALL=(ALL) NOPASSWD: ALL

Step-4: Register GitLab Runner

Now, it’s time to register GitLab Runner to GitLab Server which was set up before.

• Log in to GitLab Server with username and password(create a user if you haven’t already and create a project).
• Navigate to Settings and click on CI/CD and click on Expand of Runners section.

• Copy the URL and registration token. And register the runner.

  $ gitlab-runner register --name project-name-runner --url http://10.10.5.55/ --registration-token  GR1348941Ah6PxTBi5S5asJ7fzYSa
  

  OR,

$ sudo gitlab-runner register

Note: During registration, you’ll be asked some questions such as tags, name, executor etc., Select executor as shell (If you’re using docker you can select docker or docker+machine as an executor). Since I’m deploying on the same machine I will select executor as shell. Or you can select whatever as per your requirements.

Now you have successfully performed GitLab Runner Registration. Check on the GitLab CI/CD > Runners section, you’ll see the newly registered runner.

Error: This job is stuck because the project doesn’t have any runners online assigned to it. Go to Runners page.

It’s due to tags you’ve added during configuration, but not added to your CI/CD job. To solve this, you can add tags to your CICD jobs Or do the following:

• Go to Settings > CI/CD > Runners (Click on Expand)
• Click on the edit icon of the newly created runner. And check Run untagged jobs box.

And here it is, you have successfully installed and registered gitlab-runner for your projects.

Uninstalling GitLab Runner

To completely remove gitlab-runner run the following commands:

$ sudo apt purge --autoremove -y gitlab-runner
$ sudo apt-key del 51312f3f
$ sudo rm -rf /etc/apt/sources.list.d/runner_gitlab-runner.list
$ sudo deluser --remove-home gitlab-runner
$ sudo rm -rf /etc/gitlab-runner

CI/CD for Containerized Applications

My project structure:

.
├── Dockerfile
├── .env
├── .git
├── .gitignore
├── .gitlab-ci.yml
├── package.json
├── README.md
├── .sample.env
└── src

Step-1: Configure .gitlab-ci.yml File

Now it’s time to configure CI/CD for containerized applications to deploy on the same machine where the GitLab Runner is set up. For this, let’s configure .gitlab-ci.yml file as:

stages:   
  - build
  - deploy

before_script:
    - IMAGE_TAG="$(echo $CI_COMMIT_SHA | head -c 8)"

dev-build-job:
  stage: build
  script:
    # - export DOCKER_HOST=tcp://0.0.0.0:2375/
    - cp $ENV_FILE .env
    - docker build -t $APP_NAME:latest .
  only:
    - dev
  tags:
    - cloudyfox

dev-deploy-job:
  stage: deploy
  script:
    - docker container rm -f $APP_NAME || true
    - docker run -d -p $PORT:$PORT --name $APP_NAME $APP_NAME:latest
  only:
    - dev
  tags:
    - cloudyfox

Step-2: Add Required Variables and Deploy

Here, the pipeline has two stages: build and deploy. IMAGE_TAG variable is used to tag docker images later.

In the build stage, $ENV_FILE variable is copied from the GitLab variables to the project root directory as it is in the .gitignore file. So, create ENV_FILE File variable with the value of .env file. To do so, Go to GitLab Server and navigate to Settings > CI/CD > Variables (Click on Expand). And add a new File variable.

Also, I have added APP_NAME and PORT variables as they are required for me.

In the deploy stage, the docker built in the previous build stage is deployed by deleting a container of the same name if running which is deployed then deploys our docker container.

In this way, you can deploy all the containerized microservices to the machine. Whenever you push the changes to the remote repository, a new docker version will be built and run on the machine(where all GitLab, and Runner are configured.).

Configuring Nginx As a Load Balancer

Let’s say you have successfully run all the micro applications using different ports on the server. Then you have to set up the Nginx load balancer to handle the requests. So that you can handle it in accordance with the users’ requests.

Since my GitLab server is running in the same local host, I need to use a different port to serve microservices. So, let’s start by configuring NGINX on the server.

Step-1: Install NGINX

$ sudo apt update
$ sudo -H apt install nginx-common nginx-full

Start Nginx:

$ sudo nginx

And start Nginx then check the status:

$ sudo systemctl start nginx
$ sudo systemctl status nginx

Output:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-06-15 09:05:01 +0545; 5h 20min ago
       Docs: man:nginx(8)
    Process: 875 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, stat>
    Process: 1065 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUC>
   Main PID: 1066 (nginx)
      Tasks: 5 (limit: 9408)
     Memory: 4.7M
     CGroup: /system.slice/nginx.service
             ├─1066 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
             ├─1067 nginx: worker process
             ├─1068 nginx: worker process
             ├─1069 nginx: worker process
             └─1070 nginx: worker process

You can Start, Stop, and Restart Nginx as:

$ sudo systemctl start nginx
$ sudo systemctl stop nginx
$ sudo systemctl restart nginx

Step-2: Configure Nginx Load Balancer for Dockerized Apps

To configure Nginx as Loadbalancer, first, remove default conf file, /etc/nginx/sites-enabled/default and create /etc/nginx/conf.d/lb.conf with following content(change as your requirements)

I’ll be routing all microservices which are running in different ports to http://10.10.5.55:9999. (as http://10.10.5.55 (port 80) is already used by the GitLab server)

The requests for different services will be load balanced as:

upstream user {
    server 127.0.0.1:5001;
}
upstream content {
    server 127.0.0.1:5002;
}
upstream discussion {
    server 127.0.0.1:5003;
}
upstream payment {
    server 127.0.0.1:5004;
}
upstream read {
    server 127.0.0.1:5007;
}
upstream subscription {
    server 127.0.0.1:5005;
}
upstream card {
    server 127.0.0.1:5006;
}
server {
    listen 9999;
    server_name localhost;
    location /api/user {
        proxy_pass http://user/api/user;
    }
    location /api/content {
        proxy_pass http://content/api/content;
    }
    location /api/discussion {
        proxy_pass http://discussion/api/discussion;
    }
    location /api/payment {
        proxy_pass http://payment/api/payment;
    }
    location /api/read {
        proxy_pass http://read/api/read;
    }
    location /api/subscription {
        proxy_pass http://subscription/api/subscription;
    }
    location /api/card {
        proxy_pass http://card/api/card;
    }
}

Here, every service has a different request URI, and all will be routed accordingly.

server_name is your domain name(if you have configured it previously), for me it’s localhost.

And test the syntax:

$ sudo nginx -t

Output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Now, restart the Nginx service:

$ sudo service nginx restart

Go to the browser and run http://10.10.5.55:9999/. You’ll get successful output. (Change 10.10.5.55 with your server’s IP or domain name)

In my case:

And that’s all for Nginx Loadbalancer(reverse-proxy) configuration.

Conclusion

Here you go, you have successfully configured GitLab server, GitLab Runner, CI/CD for dockerized microservices, and NGINX as a load balancer(reverse-proxy) at once.

Explore more blogs of mine: https://scanskill.com/profile/sagar/

Thank you!

Gunicorn

Now, install Gunicorn. It's production grade WSGI server.

For now, since we want to use default django's built-in server, create production compose file:

version: '3.5'

services:
    app:
        build:
            context: .
        command: gunicorn personal.wsgi:application --bind 0.0.0.0:8000
        volumes:
            - static_data:/vol/static
        ports:
            - "8000:8000"
        restart: always
        env_file:
            - .env.prod
        depends_on:
            - app-db

    app-db:
        image: postgres:12-alpine
        ports:
            - "5432:5432"
        restart: always
        volumes:
            - postgres_data:/var/lib/postgresql/data:rw
        env_file:
            - .env.prod
volumes:
    static_data:
    postgres_data:

Here, we're using commang gunicorn instead of django server command. we can static_data volume as it's not needed in production. For now, let's create .env.prod file for environemental variables:

DEBUG=0
DJANGO_ALLOWED_HOSTS=localhost 127.0.0.1 [::1]
DB_ENGINE=django.db.backends.postgresql_psycopg2
POSTGRES_HOST_AUTH_METHOD=trust
POSTGRES_USER=sagar
POSTGRES_PASSWORD=********
POSTGRES_DB=portfolio_db_prod
POSTGRES_HOST=app-db
POSTGRES_PORT=5432

Add both files to .gitignore file if you want to keep them out from version control. Now, down all containers with -v flag, -v flag removes associated volumes:

$ docker-compose down -v

Then, re-build images and run the containers:

$ docker-compose -f docker-compose.prod.yml up --build

Run with -d flag if you wan't to run services in background. If any error when running, check errors with command:

$ docker-compose -f docker-compose.prod.yml logs -f

Wow, let's create production Dockerfile as Dockerfile.prod with production entrypoint.prod.sh file inside scripts directory of the root. entrypoint.prod.sh script file:

#!/bin/sh

if [ "$DATABASE" = "postgres" ]
then
    echo "Waiting for postgres..."
    while ! nc -z "$POSTGRES_HOST" "$POSTGRES_PORT"; do
      sleep 0.1
    done
    echo "PostgreSQL started"
fi

exec "$@"

Dockerfile.prod file with scripts permission:

FROM python:3.8.9-alpine as builder

ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONNUNBUFFERED 1

RUN apk update
RUN apk add postgresql-dev gcc python3-dev musl-dev libc-dev linux-headers

RUN apk add jpeg-dev zlib-dev libjpeg

RUN pip install --upgrade pip
COPY ./requirements.txt .
RUN pip wheel --no-cache-dir --no-deps --wheel-dir /wheels -r requirements.txt

#### FINAL ####

FROM python:3.8.9-alpine

RUN mkdir /app
COPY . /app
WORKDIR /app

RUN apk update && apk add libpq
COPY --from=builder ./wheels /wheels
COPY --from=builder ./requirements.txt .
RUN pip install --no-cache /wheels/*
#RUN pip install -r requirements.txt

COPY ./scripts /scripts
RUN chmod +x /scripts/

RUN mkdir -p /vol/media
RUN mkdir -p /vol/static
RUN chmod -R 755 /vol

ENTRYPOINT ["/scripts/entrypoint.prod.sh"]

Here we used a multi-stage build as it reduces final image size. 'builder' is a temporary image that's used just to build python wheels with dependencies, that are copied to the Final stage. we can create a non-root user. Because that is the best practice to be safe from attackers. Now, update the compose production file with docker production file:

version: '3.5'

services:
    app:
        build:
            context: .
            dockerfile: Dockerfile.prod
        command: gunicorn personal.wsgi:application --bind 0.0.0.0:8000
        volumes:
            - static_data:/vol/static
        expose:
            - "8000:8000"
        restart: always
        env_file:
            - .env.prod
        depends_on:
            - app-db

    app-db:
        image: postgres:12-alpine
        ports:
            - "5432:5432"
        restart: always
        volumes:
            - postgres_data:/var/lib/postgresql/data:rw
        env_file:
            - .env.prod
volumes:
    static_data:
    postgres_data:

Rebuild, and run:

$ docker-compose -f docker-compose.prod.yml down -v
$ docker-compose -f docker-compose.prod.yml up -d --build
$ docker-compose -f docker-compose.prod.yml exec app python manage.py migrate --noinput

Ngnix

Nginx really gives you the ultimate power. You can do whatever you want. Let's add Nginx to act as a reverse proxy for Gunicorn. Add service on docker-compose file (production):

version: '3.5'

services:
    app:
        build:
            context: .
            dockerfile: Dockerfile.prod
        command: gunicorn personal.wsgi:application --bind 0.0.0.0:8000
        volumes:
            - static_data:/vol/static
            - media_data: /vol/media
        ports:
            - "8000:8000"
        restart: always
        env_file:
            - .env.prod
        depends_on:
            - app-db

    app-db:
        image: postgres:12-alpine
        ports:
            - "5432:5432"
        restart: always
        volumes:
            - postgres_data:/var/lib/postgresql/data:rw
        env_file:
            - .env.prod

    proxy:
        build: ./proxy
        volumes:
            - static_data:/vol/static
            - media_data:/vol/media
        restart: always
        ports:
            - "8008:80"
        depends_on:
            - app
volumes:
    static_data:
    media_data:
    postgres_data:

Inside root directory create a proxy(whatever you want to name it) directory and add a configuration file, in my case I have created default.conf file as:

server {
    listen 80;

    location /static {
        alias /vol/static;
    }

    location /media {
        alias /vol/media;
    }

    location / {
        uwsgi_pass app:8000;
        include /etc/nginx/uwsgi_params;
    }
}

And create uwsgi_params file for this.

uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length;
uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param DOCUMENT_ROOT $document_root;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_ADDR $server_addr;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param SERVER_NAME $server_name;

Also, add a Dockerfile inside the proxy directory for Nginx configuration:

FROM nginxinc/nginx-unprivileged:1-alpine

COPY ./default.conf /etc/nginx/conf.d/default.conf
COPY uwsgi_params /etc/nginx/uwsgi_params

You can use expose instead of ports in docker-compose.prod.yml file for app service:

app:
        build:
            context: .
            dockerfile: Dockerfile.prod
        command: gunicorn personal.wsgi:application --bind 0.0.0.0:8000
        volumes:
            - static_data:/vol/static
            - media_data:/vol/media
        expose:
            - 8000
        restart: always
        env_file:
            - .env.prod
        depends_on:
            - app-db

Again, re-build run and try:

$ docker-compose -f docker-compose.prod.yml down -v
$ docker-compose -f docker-compose.prod.yml up -d --build
$ docker-compose -f docker-compose.prod.yml exec web python manage.py migrate --noinput
$ docker-compose -f docker-compose.prod.yml exec web python manage.py collectstatic --no-input --clear

Ensure the app is running in http://localhost:8008.

That's it.

Thank You!

Previous: Part-1

Prerequisites

First, ensure the following is installed on your machine:

• Python 3.7 or higher(I've used python 3.8.9)
• Python pip
• Git and a GitHub account
• Docker and docker-compose

Let's jump directly to dockerization of Django web application. I'm sure you have Django project set up on your system.

Docker

After installation of docker, add a Dockerfile to the root directory of your project:

FROM python:3.8.9-alpine

WORKDIR /app

ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONNUNBUFFERED 1

RUN pip install --upgrade pip
COPY ./requirements.txt .

RUN pip install -r requirements.txt

COPY . .

Here, we used an alpine-based docker image for python 3.8.9. Then we set two environmental variables:

• PYTHONDONTWRITEBYTECODE (which prevents writing pyc files)
• PYTHONUNBUFFERED (which prevents buffering stdout and stderr)

And, we updated the pip version and copied the requirements.txt file to the working directory, and installed requirements. After that, we finally copied our project to the working directory(/app).

Now, create a docker-compose.yml file to the project root and add services:

version: '3.5'

services:
    app:
        build: .
        command: python manage.py runserver 0.0.0.0:8000
        volumes:
            - static_data:/vol/web
        ports:
            - "8000:8000"
        restart: always
        env_file:
            - ./.env

Create .env file at the root (the same directory containing docker-compose.yml) and edit as:

DEBUG=1
SECRET_KEY=foo
DJANGO_ALLOWED_HOSTS=localhost 127.0.0.1 [::]

Update DEBUG, ALLOWED_HOSTS variables in settings.py:

DEBUG = int(os.environ.get("DEBUG", default=0))
ALLOWED_HOSTS = os.environ.get("DJANGO_ALLOWED_HOSTS").split(" ")

'DJANGO_ALLOWED_HOSTS' should be a single string of hosts with a space between each. For example: 'DJANGO_ALLOWED_HOSTS=localhost 127.0.0.1 [::1]'

In docker-compose file, build: . means it will build image from the root Dockerfile we have created before.

Now, build the image:

$ docker-compose build

Use sudo if needed. Run the container once the image is built:

$ docker-compose up -d

Postgres

Add new service to the docker-compose.yml file, and update django database settings, with Psycopg2. Lets add new service named as app-db:

version: '3.5'

services:
    app:
        build: .
        command: python manage.py runserver 0.0.0.0:8000
        volumes:
            - static_data:/vol/web
        ports:
            - "8000:8000"
        restart: always
        env_file:
            - ./.env
        depends_on:
            - app-db

    app-db:
        image: postgres:12-alpine
        ports:
            - "5432:5432"
        restart: always
        volumes:
            - postgres_data:/var/lib/postgresql/data:rw
        env_file:
            - .env
# you can also use environmental variables directly as following:
#(remember variables for postgres should be named exactly as given below)
#        environment:
#            - POSTGRES_HOST_AUTH_METHOD=trust
#            - POSTGRES_USER:sagar
#            - POSTGRES_PASSWORD:********
#            - POSTGRES_DB:portfolio_db
#            - TZ:Asia/Kathmandu

We will just use the official Postgres docker image and postgres_data is the persistent data volume within docker. It should suffice

DEBUG=1
DJANGO_ALLOWED_HOSTS=localhost 127.0.0.1 [::1]
POSTGRES_HOST_AUTH_METHOD=trust
POSTGRES_USER=sagar
POSTGRES_PASSWORD=********
POSTGRES_DB=portfolio_db
POSTGRES_HOST=app-db
POSTGRES_PORT=5432

Update the DATABASES dict in settings.py:

DATABASES = {
    'default': {
        'ENGINE': os.environ.get("DB_ENGINE", "django.db.backends.sqlite3"),
        'NAME': os.environ.get("POSTGRES_DB", os.path.join(BASE_DIR, "db.sqlite3")),
        'USER': os.environ.get("POSTGRES_USER", "default_user"),
        'PASSWORD': os.environ.get("POSTGRES_PASSWORD", "default_password"),
        'HOST': os.environ.get("POSTGRES_HOST", "localhost"),
        'PORT': os.environ.get("POSTGRES_PORT", "5432"),

    }
}

Here, the database is configured based on the environment variables that we just defined. Take note of the default values. Update the Dockerfile to install the appropriate packages required for Psycopg2:

From python:3.8.9-alpine

WORKDIR /app

PYTHONDONTWRITEBYTECODE 1
ENV PYTHONNUNBUFFERED 1

#psycopg2 dependencies installation
RUN apk update
RUN apk add postgresql-dev gcc python3-dev musl-dev libc-dev linux-headers

RUN pip install --upgrade pip
COPY ./requirements.txt .

RUN pip install -r requirements.txt

COPY . .

Add Psycopg2 to requirements.txt. Make sure everytime you install packages, they are added to requirements.txt file. (pip freeze > requirements.txt)

Build the new image with two services:

$ docker-compose up -d --build

Then run the migrations:

$ docker-compose exec app python manage.py migrate --noinput

Operations to perform:
  Apply all migrations: admin, auth, blogs, contenttypes, django_summernote, portfolio, sessions, works
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying blogs.0001_initial... OK
  Applying django_summernote.0001_initial... OK
  Applying django_summernote.0002_update-help_text... OK
  Applying portfolio.0001_initial... OK
  Applying sessions.0001_initial... OK
  Applying works.0001_initial... OK
  Applying works.0002_auto_20200325_1330... OK
  Applying works.0003_auto_20200325_1411... OK
  Applying works.0004_auto_20200325_1413... OK
  Applying works.0005_auto_20200325_1417... OK
  Applying works.0006_remove_work_image... OK
  Applying works.0007_work_image... OK

If any error, run docker-compose down -v to remove the volumes along with the containers. Then re-build and run migrations.

Ensure database tables are created:

$ docker-compose exec app-db psql --username=user --dbname=portfolio_db

$ sudo docker-compose exec app-db psql --username=sagar --dbname=portfolio_db
psql (12.7)
Type "help" for help.

portfolio_db=# \c portfolio_db
You are now connected to database "portfolio_db" as user "sagar".
portfolio_db=# \l
                               List of databases
     Name     | Owner | Encoding |  Collate   |   Ctype    | Access privileges 
--------------+-------+----------+------------+------------+-------------------
 portfolio_db | sagar | UTF8     | en_US.utf8 | en_US.utf8 | 
 postgres     | sagar | UTF8     | en_US.utf8 | en_US.utf8 | 
 template0    | sagar | UTF8     | en_US.utf8 | en_US.utf8 | =c/sagar         +
              |       |          |            |            | sagar=CTc/sagar
 template1    | sagar | UTF8     | en_US.utf8 | en_US.utf8 | =c/sagar         +
              |       |          |            |            | sagar=CTc/sagar
(4 rows)

portfolio_db=# \dt
                   List of relations
 Schema |             Name             | Type  | Owner 
--------+------------------------------+-------+-------
 public | auth_group                   | table | sagar
 public | auth_group_permissions       | table | sagar
 public | auth_permission              | table | sagar
 public | auth_user                    | table | sagar
 public | auth_user_groups             | table | sagar
 public | auth_user_user_permissions   | table | sagar
 public | blogs_category_post          | table | sagar
 public | blogs_comment                | table | sagar
 public | blogs_post                   | table | sagar
 public | blogs_post_categories        | table | sagar
 public | django_admin_log             | table | sagar
 public | django_content_type          | table | sagar
 public | django_migrations            | table | sagar
 public | django_session               | table | sagar
 public | django_summernote_attachment | table | sagar
 public | portfolio_contact            | table | sagar
 public | works_category_work          | table | sagar
 public | works_work                   | table | sagar
 public | works_work_categories        | table | sagar
(19 rows)

portfolio_db=#

Now add entrypoint.sh script inside scripts directory:

#!/bin/sh

if [ "$DATABASE" = "postgres" ]
then
    echo "Waiting for postgres..."
    while ! nc -z "$POSTGRES_HOST" "$POSTGRES_PORT"; do
      sleep 0.1
    done
    echo "PostgreSQL started"
fi

# It's okay to run the following two, flush and migrate commands on development mode(when debug mode is on) but not recommended
# for production:

# python manage.py flush --no-input
# python manage.py migrate

exec "$@"

Update Dockerfile with file permissions, and also add DATABASE variable to .env file.

From python:3.8.9-alpine

WORKDIR /app

PYTHONDONTWRITEBYTECODE 1
ENV PYTHONNUNBUFFERED 1

#psycopg2 dependencies installation
RUN apk update
RUN apk add postgresql-dev gcc python3-dev musl-dev libc-dev linux-headers

RUN pip install --upgrade pip
COPY ./requirements.txt .

RUN pip install -r requirements.txt

COPY . .
COPY ./scripts /scripts

RUN chmod +x /scripts/*

RUN mkdir -p /vol/web/media
RUN mkdir -p /vol/web/static

RUN chmod -R 755 /vol/web

ENTRYPOINT ["/scripts/entrypoint.sh"]

Edit .env file:

DEBUG=1
DJANGO_ALLOWED_HOSTS=localhost 127.0.0.1 [::1]
POSTGRES_HOST_AUTH_METHOD=trust
POSTGRES_USER=user
POSTGRES_PASSWORD=password
POSTGRES_DB=portfolio_db
POSTGRES_HOST=app-db #from docker-compose
POSTGRES_PORT=5432
DATABASE=postgres

Now, re-build, run and try http://localhost:8000/

Next: Django, Postgres, Gunicorn, Nginx with Docker ( Part-2 )