Linux

Stop killing your pods just to give them more RAM

If your pants feel a little tight after a large Thanksgiving meal, the logical solution is to discreetly unbutton them. You do not typically hire a hitman to assassinate yourself, clone your DNA in a vat, and grow a slightly wider version of yourself just to digest dessert. Yet, for nearly a decade, this is exactly how Kubernetes handled resource management.

When an application slowly consumed all its allocated memory, the standard orchestration response was absolute, violent destruction. We did not give the application more memory. We shot it in the head, deleted its entire existence, and span up a brand new replica with a slightly larger plate. Connections dropped. Warm caches evaporated. State was lost in the digital wind.

Thankfully, the era of the Kubernetes firing squad is drawing to a close. In-place pod resizing has officially graduated to stable General Availability in Kubernetes v1.35, and it changes the fundamental physics of how we manage workloads. We can finally stop burning down the house just to buy a bigger sofa.

Let us explore how this works, why it is practically miraculous, and how to use it without accidentally angering the Linux kernel.

The historical absurdity of pod resource management

Before in-place resizing, if you wanted to change the CPU or memory allocated to a running pod, the workflow was brutally simplistic. You updated your Deployment specification with the new resource requests and limits. The Kubernetes control plane saw the discrepancy between the desired state and the current state. The control plane then instructed the Kubelet to terminate the old pod and create a new one.

Think of taking your car to the mechanic because you need thicker tires. Instead of swapping the tires, the mechanic puts your car into an industrial crusher, hands you an identical car with thicker tires, and tells you to reprogram your radio stations. Sure, the rolling update strategy ensured you had a backup car to drive while the primary one was being crushed, but the specific pod doing the heavy lifting was gone.

For stateless microservices written in Go, this was barely an inconvenience. For a massive Java Virtual Machine holding gigabytes of cached data, or a machine learning inference service handling a traffic spike, a restart was a traumatic event. It meant minutes of downtime, CPU spikes during startup, and a slew of unhappy alerts.

Enter the era of in-place resizing

The magic of Kubernetes v1.35 is that the “resources.requests” and “resources.limits” fields within a pod specification are no longer immutable. You can edit them on the fly.

Under the hood, Kubernetes is finally taking full advantage of Linux control groups (cgroups). A container is basically just a regular Linux process trapped in a highly restrictive administrative box. The kernel has always had the ability to move the walls of this box without killing the process inside. If a container needs more memory, the kernel simply adjusts the cgroup memory limit. It is like a landlord quietly sliding a partition wall outward while you are still sleeping in your bed.

Here is a sanitized example of how you might update a running pod. Notice how we are just applying a patch to an existing, actively running resource.

# We patch the running pod to increase memory limits
# No restarts, no dropped connections, just instant gratification
kubectl patch pod bloated-legacy-api-7b89f5c -p '{"spec":{"containers":[{"name":"main-app","resources":{"limits":{"memory":"4Gi"}}}]}}'

It feels almost illegal the first time you do it. The pod keeps running, the uptime counter keeps ticking, but suddenly the application has breathing room.

The bureaucratic lifecycle of asking for more RAM

Of course, you cannot just demand more resources and expect the universe to instantly comply. The physical node hosting your pod must actually have the spare CPU or memory available. To manage this negotiation, Kubernetes introduces a new field in the pod status called resize.

This field tracks the bureaucratic process of your resource request. It is very much like dealing with the Department of Motor Vehicles, but measured in milliseconds. The statuses are surprisingly descriptive.

First, there is Proposed. This means your request for more resources has been acknowledged. The paperwork is on the desk, but nobody has stamped it yet.

Second, we have “InProgress”. The Kubelet has accepted the request and is currently asking the container runtime (like containerd or CRI-O) to adjust the cgroup limits. The walls are physically moving.

Third, you might see Deferred. This is the orchestrator politely telling you that the node is currently full. Your pod is on a waitlist. As soon as another pod terminates or frees up space, your resize request will be processed. You do not get an error, but you also do not get your RAM. You just wait.

Finally, there is Infeasible. This is Kubernetes looking at you with deep, profound disappointment. You probably asked for 64 Gigabytes of memory on a tiny virtual machine that only has 8 Gigabytes total. The API server essentially stamps your form with a big red “DENIED” and moves on with its life.

Negotiating with stubborn runtimes using resize policies

Not all applications are smart enough to realize they have been gifted more resources. Node.js or Go applications will happily consume newly available CPU cycles without being told. Java applications, on the other hand, are like stubborn mules. If you start a JVM with a maximum heap size of 2 Gigabytes, giving the container 4 Gigabytes of memory will accomplish absolutely nothing. The JVM will stubbornly refuse to look at the new memory until you reboot it.

To handle these varying levels of application intelligence, Kubernetes gives us the resizePolicy array. This allows you to define exactly how the Kubelet should handle changes for each specific resource type.

apiVersion: v1
kind: Pod
metadata:
  name: stubborn-java-beast
spec:
  containers:
  - name: heavy-calculator
    image: corporate-repo/calculator:v4
    resizePolicy:
    - resourceName: cpu
      restartPolicy: RestartNotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        memory: "2Gi"
        cpu: "1"
      limits:
        memory: "4Gi"
        cpu: "2"

In this configuration, we are telling Kubernetes a very specific set of rules. If we patch the CPU limits, the Kubelet will adjust the cgroups and leave the container alone (RestartNotRequired). The application will just run faster. However, if we patch the memory limits, the Kubelet knows it must restart the container (RestartContainer) so the application can read the new environment variables and adjust its internal memory management.

The vertical pod autoscaler is your marital therapist

Manually patching pods in the middle of the night is still a terrible way to manage infrastructure. The true power of in-place resizing is unlocked when you pair it with the Vertical Pod Autoscaler.

Historically, the VPA was a bit of a brute. It would watch your pods, realize they needed more memory, and then mercilessly murder them to apply the new sizes. It was effective, but highly destructive.

Now, the VPA features a magical mode called InPlaceOrRecreate. Think of this mode as a highly skilled couples therapist. It sits quietly in the background, observing the relationship between your application and its memory usage. When the application needs more space to grow, the VPA simply slides the walls outward without causing a scene. It only resorts to the nuclear option of recreating the pod if an in-place resize is technically impossible.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: smooth-scaling-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend-service
  updatePolicy:
    # The magic word that prevents the firing squad
    updateMode: "InPlaceOrRecreate"

With this single setting, your stateful workloads, long-running batch jobs, and memory-hungry APIs can seamlessly adapt to traffic spikes without ever dropping a user request.

The fine print and the rottweiler problem

As with all things in distributed systems, there are rules. You cannot cheat the laws of physics. If a node is completely exhausted of resources, your in-place resize will sit in the Deferred state forever. You still need the Cluster Autoscaler to add fresh physical nodes to your cluster. In-place resizing is a tool for distributing existing wealth, not for printing new money.

Furthermore, we must talk about the danger of scaling down. Increasing memory is a joyous occasion. Reducing memory limits on a running container is like trying to take a juicy steak out of the mouth of a hungry Rottweiler.

The Linux kernel takes memory limits very seriously. If your application is currently using 3 Gigabytes of memory, and you smugly patch the pod to limit it to 2 Gigabytes, the kernel does not politely ask the application to clean up its garbage. The Out Of Memory killer wakes up, grabs an axe, and immediately slaughters your application.

Always scale down memory with extreme caution. It is almost always safer to wait for a natural deployment cycle to reduce memory requests than to try to forcefully shrink a running process.

In the end, in-place pod resizing is not just a neat party trick. It is a fundamental maturation of Kubernetes as an operating system for the cloud. We are no longer treating our workloads like disposable cattle to be slaughtered at the first sign of trouble. We are treating them like slightly demanding house pets. Just give them the bigger bowl of food and let them sleep.

April 5, 2026 by DevOps stuff Kubernetes SRE stuff

Managing the emotional stability of your Linux server

Thursday, 3:47 AM. Your server is named Nigel. You named him Nigel because deep down, despite the silicon and the circuitry, he feels like a man who organizes his spice rack alphabetically by the Latin name of the plant. But right now, Nigel is not organizing spices. Nigel has decided to stage a full-blown existential rebellion.

The screen is black. The network fan is humming with a tone of passive-aggressive silence. A cursor blinks in the upper-left corner with a rhythm that seems designed specifically to induce migraines. You reboot. Nigel reboots. Nothing changes. The machine is technically “on,” in the same way a teenager staring at the ceiling for six hours is technically “awake.”

At this moment, the question separating the seasoned DevOps engineer from the panicked googler is not “Why me?” but rather: Which personality did Nigel wake up with today?

This is not a technical question. It is a psychological one. Linux does not break at random; it merely changes moods. It has emotional states. And once you learn to read them, troubleshooting becomes less like exorcising a demon and more like coaxing a sulking relative out of the bathroom during Thanksgiving dinner.

The grumpy grandfather who started it all

We lived in a numeric purgatory for years. In an era when “multitasking” sounded like dangerous witchcraft and coffee came only in one flavor (scorched), Linux used a system called SysVinit to manage its temperaments. This system boiled the entire machine’s existence down to a handful of numbers, zero through six, called runlevels.

It was a rigid caste system. Each number was a dial you could turn to decide how much Nigel was willing to participate in society.

Runlevel 0 meant Nigel was checking out completely. Death. Runlevel 6 meant Nigel had decided to reincarnate. Runlevel 1 was Nigel as a hermit monk, holed up in a cave with no network, no friends, just a single shell and a vow of digital silence. Runlevel 5 was Nigel on espresso and antidepressants, graphical interface blazing, ready to party and consume RAM for no apparent reason.

This was functional, in the way a Soviet-era tractor is functional. It was also about as intuitive as a dishwasher manual written in cuneiform. You would tell a junior admin to “boot to runlevel 3,” and they would nod while internally screaming. What does three mean? Is it better than two? Is five twice as good as three? The numbers did not describe anything; they just were, like the arbitrary rules of a board game invented by someone who actively hated you.

And then there was runlevel 4. Runlevel 4 is the appendix of the Linux anatomy. It is vaguely present, historically relevant, but currently just taking up space. It was the “user-definable” switch in your childhood home that either did nothing or controlled the neighbor’s garage door. It sits there, unused, gathering digital dust.

Enter the overly organized therapist

Then came systemd. If SysVinit was a grumpy grandfather, systemd is the high-energy hospital administrator who carries a clipboard and yells at people for walking too slowly. Systemd took one look at those numbered mood dials and was appalled. “Numbers? Seriously? Even my router has a name.”

It replaced the cold digits with actual descriptive words: multi-user.target, graphical.target, rescue.target. It was as if Linux had finally gone to therapy and learned to use its words to express its feelings instead of grunting “runlevel 3” when it really meant “I need personal space, but WiFi would be nice.”

Targets are just runlevels with a humanities degree. They perform the exact same job, defining which services start, whether the GUI is invited to the party, whether networking gets a plus-one, but they do so with the kind of clarity that makes you wonder how we survived the numeric era without setting more server rooms on fire.

A Rosetta Stone for Nigel’s mood swings

Here is the translation guide that your cheat sheet wishes it had. Think of this as the DSM-5 for your server.

  • Runlevel 0 becomes poweroff.target
    Nigel is taking a permanent nap. This is the Irish Goodbye of operating states.
  • Runlevel 1 becomes rescue.target
    Nigel is in intensive care. Only family is allowed to visit (root user). The network is unplugged, the drives might be mounted read-only, and the atmosphere is grim. This is where you go when you have broken something fundamental and need to perform digital surgery.
  • Runlevel 3 becomes multi-user.target
    Nigel is wearing sweatpants but answering emails. This is the gold standard for servers. Networking is up, multiple users can log in, cron jobs are running, but there is no graphical interface to distract anyone. It is a state of pure, joyless productivity.
  • Runlevel 5 becomes graphical.target
    Nigel is in full business casual with a screensaver. He has loaded the window manager, the display server, and probably a wallpaper of a cat. He is ready to interact with a mouse. He is also consuming an extra gigabyte of memory just to render window shadows.
  • Runlevel 6 becomes reboot.target
    Nigel is hitting the reset button on his life.

The command line couch

Knowing Nigel’s mood is useless unless you can change it. You need tools to intervene. These are the therapy techniques you keep in your utility belt.

To eyeball Nigel’s default personality (the one he wakes up with every morning), you ask:

systemctl get-default

This might spit back graphical.target. This means Nigel is a morning person who greets the world with a smile and a heavy user interface. If it says multi-user.target, Nigel is the coffee-before-conversation type.

But sometimes, you need to force a mood change. Let’s say you want to switch Nigel from party mode (graphical) to hermit mode (text-only) without making it permanent. You are essentially putting an extrovert in a quiet room for a breather.

systemctl isolate multi-user.target

The word “isolate” here is perfect. It is not “disable” or “kill.” It is “isolate”. It sounds less like computer administration and more like what happens to the protagonist in the third act of a horror movie involving Antarctic research stations. It tells systemd to stop everything that doesn’t belong in the new target. The GUI vanishes. The silence returns.

To switch back, because sometimes you actually need the pretty buttons:

systemctl isolate graphical.target

And to permanently change Nigel’s baseline disposition, akin to telling a chronically late friend that dinner is at 6:30 when it is really at 7:00:

systemctl set-default multi-user.target

Now Nigel will always wake up in Command Line Interface mode, even after a reboot. You can practically hear the sigh of relief from your CPU as it realizes it no longer has to render pixels.

When Nigel has a real breakdown

Let’s walk through some actual disasters, because theory is just a hobby until production goes down and your boss starts hovering behind your chair breathing through his mouth.

Scenario one: The fugue state

Nigel updated his kernel and now boots to a black screen. He is not dead; he is just confused. You reboot, interrupt the boot loader, and add systemd.unit=rescue.target to the boot parameters.

Nigel wakes up in a safe room. It is a root shell. There is no networking. There is no drama. It is just you and the config files. It is intimate, in a disturbing way. You fix the offending setting, type exec /sbin/init, and Nigel reboots into his normal self, slightly embarrassed about the whole episode.

Scenario two: The toddler on espresso

Nigel’s graphical interface has started crashing like a toddler after too much sugar. Every time you log in, the desktop environment panics and dies. Instead of fighting it, you switch to multi-user.target.

Nigel is now a happy, stable server with no interest in pretty icons. Your users can still SSH in. Your automated jobs still run. Nigel just doesn’t have to perform anymore. It is like taking the toddler out of the Chuck E. Cheese and putting him in a library. The screaming stops immediately.

Scenario three: The bloatware incident

Nigel is a production web server that has inexplicably slowed to a crawl. You dig through the logs and discover that an intern (let’s call him “Not-Fernando”) installed a full desktop environment six months ago because they liked the screensaver.

This is akin to buying a Ferrari to deliver pizza because you like the leather seats. The graphical target is eating resources that your database desperately needs. You set the default to multi-user.target and reboot. Nigel comes back lean, mean, and suddenly has five hundred extra megabytes of RAM to play with. It is like watching someone shed a winter coat in the middle of July.

The mindset shift

Beginners see a black screen and ask, “Why is Nigel broken?” Professionals see a black screen and ask, “Which target is Nigel in, and which services are active?”

This is not just semantics. It is the difference between treating a symptom and diagnosing a disease. When you understand that Linux doesn’t break so much as it changes states, you stop being a victim of circumstance and start being a negotiator. You are not praying to the machine gods; you are simply asking Nigel, “Hey buddy, what mood are you in?” and then coaxing him toward a more productive state.

The panic evaporates because you know the vocabulary. You know that rescue.target is a panic room, multi-user.target is a focused work session, and graphical.target is Nigel trying to impress someone at a party.

Linux targets are not arcane theory reserved for greybeards and certification exams. They are the foundational language of state management. They are how you tell Nigel, “It is okay to be a hermit today,” or “Time to socialize,” or “Let’s check you into therapy real quick.”

Once you internalize this, boot issues stop being terrifying mysteries. They become logical puzzles. Interviews stop being interrogations. They become conversations. You stop sounding like a generic admin reading a forum post and start sounding like someone who knows Nigel personally.

Because you do. Nigel is that fussy, brilliant, occasionally melodramatic friend who just needs the right kind of encouragement. And now you have the exact words to provide it.

December 22, 2025 by Cloud stuff DevOps stuff Linux Stuff SRE stuff

127.0.0.1 and its 16 million invisible roommates

Let’s be honest. You’ve typed 127.0.0.1 more times than you’ve called your own mother. We treat it like the sole, heroic occupant of the digital island we call localhost. It’s the only phone number we know by heart, the only doorbell we ever ring.

Well, brace yourself for a revelation that will fundamentally alter your relationship with your machine. 127.0.0.1 is not alone. In fact, it lives in a sprawling, chaotic metropolis with over 16 million other addresses, all of them squatting inside your computer, rent-free.

Ignoring these neighbors condemns you to a life of avoidable port conflicts and flimsy localhost tricks. But give them a chance, and you’ll unlock cleaner dev setups, safer tests, and fewer of those classic “Why is my test API saying hello to the entire office Wi-Fi?” moments of sheer panic.

So buckle up. We’re about to take the scenic tour of the neighborhood that the textbooks conveniently forgot to mention.

Your computer is secretly a megacity

The early architects of the internet, in their infinite wisdom, set aside the entire 127.0.0.0/8 block of addresses for this internal monologue. That’s 16,777,216 unique addresses, from 127.0.0.1 all the way to 127.255.255.254. Every single one of them is designed to do one thing: loop right back to your machine. It’s the ultimate homebody network.

Think of your computer not as a single-family home with one front door, but as a gigantic apartment building with millions of mailboxes. And for years, you’ve been stubbornly sending all your mail to apartment #1.

Most operating systems only bother to introduce you to 127.0.0.1, but the kernel knows the truth. It treats any address in the 127.x.y.z range as a VIP guest with an all-access pass back to itself. This gives you a private, internal playground for wiring up your applications.

A handy rule of thumb? Any address starting with 127 is your friend. 127.0.0.2, 127.10.20.30, even 127.1.1.1, they all lead home.

Everyday magic tricks with your newfound neighbors

Once you realize you have a whole city at your disposal, you can stop playing port Tetris. Here are a few party tricks your localhost never told you it could do.

The art of peaceful coexistence

We’ve all been there. It’s 2 AM, and two of your microservices are having a passive-aggressive standoff over port 8080. They both want it, and neither will budge. You could start juggling ports like a circus performer, or you could give them each their own house.

Assign each service its own loopback address. Now they can both listen on port 8080 without throwing a digital tantrum.

First, give your new addresses some memorable names in your /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows).

# /etc/hosts

127.0.0.1       localhost
127.0.1.1       auth-service.local
127.0.1.2       inventory-service.local

Now, you can run both services simultaneously.

# Terminal 1: Start the auth service
$ go run auth/main.go --bind 127.0.1.1:8080

# Terminal 2: Start the inventory service
$ python inventory/app.py --host 127.0.1.2 --port 8080

Voilà. http://auth-service.local:8080 and http://inventory-service.local:8080 are now living in perfect harmony. No more port drama.

The safety of an invisible fence

Binding a service to 0.0.0.0 is the developer equivalent of leaving your front door wide open with a neon sign that says, “Come on in, check out my messy code, maybe rifle through my database.” It’s convenient, but it invites the entire network to your private party.

Binding to a 127.x.y.z address, however, is like building an invisible fence. The service is only accessible from within the machine itself. This is your insurance policy against accidentally exposing a development database full of ridiculous test data to the rest of the company.

Advanced sorcery for the brave

Ready to move beyond the basics? Treating the 127 block as a toolkit unlocks some truly powerful patterns.

Taming local TLS

Testing services that require TLS can be a nightmare. With your new loopback addresses, it becomes trivial. You can create a single local Certificate Authority (CA) and issue a certificate with Subject Alternative Names (SANs) for each of your local services.

# /etc/hosts again

127.0.2.1   api-gateway.secure.local
127.0.2.2   user-db.secure.local
127.0.2.3   billing-api.secure.local

Now, api-gateway.secure.local can talk to user-db.secure.local over HTTPS, with valid certificates, all without a single packet leaving your laptop. This is perfect for testing mTLS, SNI, and other scenarios where your client needs to be picky about its connections.

Concurrent tests without the chaos

Running automated acceptance tests that all expect to connect to a database on port 5432 can be a race condition nightmare. By pinning each test runner to its own unique 127 address, you can spin them all up in parallel. Each test gets its own isolated world, and your CI pipeline finishes in a fraction of the time.

The fine print and other oddities

This newfound power comes with a few quirks you should know about. This is the part of the tour where we point out the strange neighbor who mows his lawn at midnight.

  • The container dimension: Inside a Docker container, 127.0.0.1 refers to the container itself, not the host machine. It’s a whole different loopback universe in there. To reach the host from a container, you need to use the special gateway address provided by your platform (like host.docker.internal).
  • The IPv6 minimalist: IPv6 scoffs at IPv4’s 16 million addresses. For loopback, it gives you one: ::1. That’s it. This explains the classic mystery of “it works with 127.0.0.1 but fails with localhost.” Often, localhost resolves to ::1 first, and if your service is only listening on IPv4, it won’t answer the door. The lesson? Be explicit, or make sure your service listens on both.
  • The SSRF menace: If you’re building security filters to prevent Server-Side Request Forgery (SSRF), remember that blocking just 127.0.0.1 is like locking the front door but leaving all the windows open. You must block the entire 127.0.0.0/8 range and ::1.

Your quick start eviction notice for port conflicts

Ready to put this into practice? Here’s a little starter kit you can paste today.

First, add some friendly names to your hosts file.

# Add these to your /etc/hosts file
127.0.10.1  api.dev.local
127.0.10.2  db.dev.local
127.0.10.3  cache.dev.local

Next, on Linux or macOS, you can formally add these as aliases to your loopback interface. This isn’t always necessary for binding, but it’s tidy.

# For Linux
sudo ip addr add 127.0.10.1/8 dev lo
sudo ip addr add 127.0.10.2/8 dev lo
sudo ip addr add 127.0.10.3/8 dev lo

# For macOS
sudo ifconfig lo0 alias 127.0.10.1
sudo ifconfig lo0 alias 127.0.10.2
sudo ifconfig lo0 alias 127.0.10.3

Now, you can bind three different services, all to their standard ports, without a single collision.

# Run your API on its default port
api-server --bind api.dev.local:3000

# Run Postgres on its default port
postgres -D /path/to/data -c listen_addresses=db.dev.local

# Run Redis on its default port
redis-server --bind cache.dev.local

Check that everyone is home and listening.

# Check the API
curl http://api.dev.local:3000/health

# Check the database (requires psql client)
psql -h db.dev.local -U myuser -d mydb -c "SELECT 1"

# Check the cache
redis-cli -h cache.dev.local ping
# Expected output: PONG

Welcome to the neighborhood

Your laptop isn’t a one-address town; it’s a small city with streets you haven’t named and doors you haven’t opened. For too long, you’ve been forcing all your applications to live in a single, crowded, noisy studio apartment at 127.0.0.1. The database is sleeping on the couch, the API server is hogging the bathroom, and the caching service is eating everyone else’s food from the fridge. It’s digital chaos.

Giving each service its own loopback address is like finally moving them into their own apartments in the same building. It’s basic digital hygiene. Suddenly, there’s peace. There’s order. You can visit each one without tripping over the others. You stop being a slumlord for your own processes and become a proper city planner.

So go ahead, break the monogamous, and frankly codependent, relationship you’ve had with 127.0.0.1. Explore the neighborhood. Hand out a few addresses. Let your development environment behave like a well-run, civilized society instead of a digital mosh pit. Your sanity and your services will thank you for it. After all, good fences make good neighbors, even when they’re all living inside your head.

August 25, 2025 by DevOps stuff SRE stuff

An irreverent tour of Linux disk space and RAM mysteries

Linux feels a lot like living in a loft apartment: the pipes are on display, every clank echoes, and when something leaks, you’re the first to squelch through the puddle. This guide hands you a mop, half a dozen snappy commands that expose where your disk space and memory have wandered off to, plus a couple of click‑friendly detours. Expect prose that winks, occasionally rolls its eyes, and never ever sounds like tax law.

Why checking disk and memory matters

Think of storage and RAM as the pantry and fridge in a shared flat. Ignore them for a week, and you end up with three half‑finished jars of salsa (log files) and leftovers from roommates long gone (orphaned kernels). A five‑minute audit every Friday spares you the frantic sprint for extra space, or worse, the freeze just before a production deploy.

Disk panic survival kit

Get the big picture fast

df is the bird’s‑eye drone shot of your mounted filesystems, everything lines up like contestants at a weigh‑in.

# Exclude temporary filesystems for clarity
$ df -hT -x tmpfs -x devtmpfs

-h prints friendly sizes, -T shows filesystem type, and the two -x flags hide the short‑lived stuff.

Zoom in on space hogs

du is your tape measure. Pair it with a little sort and head for instant gossip about the top offenders in any directory:

# Top 10 fattest directories under /var
$ sudo du -h --max-depth=1 /var 2>/dev/null | sort -hr | head -n 10

If /var/log looks like it skipped leg day and went straight for bulking season, you’ve found the culprit.

Bring in the interactive detective

When scrolling text gets dull, ncdu adds caffeine and colour:

# Install on most Debian‑based distros
$ sudo apt install ncdu

# Start at root (may take a minute)
$ sudo ncdu /

Navigate with the arrow keys, press d to delete, and feel the instant gratification of reclaiming gigabytes, the Marie Kondo of storage.

Visualise block devices

# Tree view of drives, partitions, and mount points
$ lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT --tree

Handy when that phantom 8 GB USB stick from last week still lurks in /media like an uninvited houseguest.

Memory and swap reality check

Check the ledger

The free command is a quick wallet peek, straightforward, and slightly judgemental:

$ free -h

Focus on the available column; that’s what you can still spend without the kernel reaching for its credit card (a.k.a. swap).

Real‑Time spy cam

# Refresh every two seconds, ordered by RAM gluttons
$ top -o %MEM

Prefer your monitoring colourful and charming? Try htop:

$ sudo apt install htop
$ htop

Use F6 to sort by RES (resident memory) and watch your browser tabs duke it out for supremacy.

Meet RAM’s couch‑surfing cousin

Swap steps in when RAM is full, think of it as sleeping on the living‑room sofa: doable, but slow and slightly undignified.

# Show active swap files or partitions
$ swapon --show

Seeing swap above 20 % during regular use? Either add RAM or conjure an emergency swap file:

$ sudo fallocate -l 2G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile

Remember to append it to /etc/fstab so it survives a reboot.

Prefer clicking to typing

Yes, there’s a GUI for that. GNOME Disks and KSysGuard both display live graphs and won’t judge your typos. On Ubuntu, you can run:

$ sudo apt install gnome-disk-utility

Launch it from the menu and watch I/O spikes climb like toddlers on a sugar rush.

Quick reference cheat sheet

  1. Show all mounts minus temp stuff
    Command: df -hT -x tmpfs -x devtmpfs
    Memory aid: df = disk fly‑over
  2. Top ten heaviest directories
    Command: du -h –max-depth=1 /path | sort -hr | head
    Memory aid: du = directory weight
  3. Interactive cleanup
    Command: ncdu /
    Memory aid: ncdu = du after espresso
  4. Live RAM counter
    Command: free -h
    Memory aid: free = funds left
  5. Spot memory‑hogging apps
    Command: top -o %MEM
    Memory aid: top = talent show
  6. Swap usage
    Command: swapon –show
    Memory aid: swap on stage

Stick this list on your clipboard; your future self will thank you.

Wrapping up without a bow

You now own the detective kit for disk and memory mysteries, no cosmic metaphors, just straight talk with a wink. Run df -hT right now; if the numbers give you heartburn, take three deep breaths and start paging through ncdu. Storage leaks and RAM gluttons are inevitable, but letting them linger is optional.

Found an even better one‑liner? Drop it in the comments and make the rest of us look lazy. Until then, happy sleuthing, and may your logs stay trim and your swap forever bored.

July 4, 2025 by DevOps stuff Linux Stuff SRE stuff

Free that stuck Linux port and get on with your day

A rogue process squatting on port 8080 is the tech-equivalent of leaving your front-door key in the lock: nothing else gets in or out, and the neighbours start gossiping. Ports are exclusive party venues; one process per port, no exceptions. When an app crashes, restarts awkwardly, or you simply forget it’s still running, it grips that port like a toddler with the last cookie, triggering the dreaded “address already in use” error and freezing your deployment plans.

Below is a brisk, slightly irreverent field guide to evicting those squatters, gracefully when possible, forcefully when they ignore polite knocks, and automatically so you can get on with more interesting problems.

When ports act like gate crashers

Ports are finite. Your Linux box has 65535 of them, but every service worth its salt wants one of the “good seats” (80, 443, 5432…). Let a single zombie process linger, and you’ll be running deployment whack-a-mole all afternoon. Keeping ports free is therefore less superstition and more basic hygiene, like throwing out last night’s takeaway before the office starts to smell.

Spot the culprit

Before brandishing a digital axe, find out who is hogging the socket.

lsof, the bouncer with the clipboard

sudo lsof -Pn -iTCP:8080 -sTCP:LISTEN

lsof prints the PID, the user, and even whether our offender is IPv4 or IPv6. It’s as chatty as the security guard who tells you exactly which cousin tried to crash the wedding.

ss, the Formula 1 mechanic

Modern kernels prefer ss, it’s faster and less creaky than netstat.

sudo ss -lptn sport = :8080

fuser, the debt collector

When subtlety fails, fuser spells out which processes own the file or socket:

sudo fuser -v 8080/tcp

It displays the PID and the user, handy for blaming Dave from QA by name.

Tip: Add the -k flag to fuser to terminate offenders in one swoop, great for scripts, dangerous for fingers-on-keyboard humans.

Gentle persuasion first

A well-behaved process will exit graciously if you offer it a polite SIGTERM (15):

kill -15 3245     # give the app a chance to clean up

Think of it as tapping someone’s shoulder at closing time: “Finish your drink, mate.”

If it doesn’t listen, escalate to SIGINT (2), the Ctrl-C of signals, or SIGHUP (1) to make daemons reload configs without dying.

Bring out the big stick

Sometimes you need the digital equivalent of cutting the mains power. SIGKILL (9) is that guillotine:

kill -9 3245      # immediate, unsentimental termination

No cleanup, no goodbye note, just a corpse on the floor. Databases hate this, log files dislike it, and system-wide supervisors may auto-restart the process, so use sparingly.

One-liners for the impatient

sudo kill -9 $(sudo ss -lptn sport = :8080 | awk 'NR==2{split($NF,a,"pid=");split(a[2],b,",");print b[1]}')

Single line, single breath, done. It’s the Fast & Furious of port freeing, but remember: copy-paste speed correlates strongly with “oops-I-just-killed-production”.

Automate the cleanup

A pocket Bash script

#!/usr/bin/env bash
port=${1:-3000}
pid=$(ss -lptn "sport = :$port" | awk 'NR==2 {split($NF,a,"pid="); split(a[2],b,","); print b[1]}')

if [[ -n $pid ]]; then
  echo "Port $port is busy (PID $pid). Sending SIGTERM."
  kill -15 "$pid"
  sleep 2
  kill -0 "$pid" 2>/dev/null && echo "Still alive; escalating..." && kill -9 "$pid"
else
  echo "Port $port is already free."
fi

Drop it in ~/bin/freeport, mark executable, and call freeport 8080 before every dev run. Fewer keystrokes, fewer swearwords.

systemd, your tireless janitor

Create a watchdog service so the OS restarts your app only when it exits cleanly, not when you manually murder it:

[Unit]
Description=Watchdog for MyApp on 8080

[Service]
ExecStart=/usr/local/bin/myapp
Restart=on-failure
RestartPreventExitStatus=64   # don’t restart if we SIGKILLed

Enable with systemctl enable myapp.service, grab coffee, forget ports ever mattered.

Ansible for the herd

- name: Free port 8080 across dev boxes
  hosts: dev
  become: true
  tasks:
    - name: Terminate offender on 8080
      shell: |
        pid=$(ss -lptn 'sport = :8080' | awk 'NR==2{split($NF,a,"pid=");split(a[2],b,",");print b[1]}')
        [ -n "$pid" ] && kill -15 "$pid" || echo "Nothing to kill"

Run it before each CI deploy; your colleagues will assume you possess sorcery.

A few cautionary tales

  • Containers restart themselves. Kill a process inside Docker, and the orchestrator may spin it right back up. Either stop the container or adjust restart policies.
  • Dependency dominoes. Shooting a backend API can topple every microservice that chats to it. Check systemctl status or your Kubernetes liveness probes before opening fire .
  • Sudo isn’t seasoning. Use it only when the victim process belongs to another user. Over-salting scripts with sudo causes security heartburn.

Wrap-up

Freeing a port isn’t arcane black magic; it’s janitorial work that keeps your development velocity brisk and your ops team sane. Identify the squatter, ask it nicely to leave, evict it if it refuses, and automate the routine so you rarely have to think about it again. Got a port-conflict horror story involving 3 a.m. pager alerts and too much caffeine? Tell me in the comments, schadenfreude is a powerful teacher.

Now shut that laptop lid and actually get on with your day. The ports are free, and so are you.

June 28, 2025 by DevOps stuff Linux Stuff SRE stuff

Linux commands for the pathologically curious

We all get comfortable. We settle into our favorite chair, our favorite IDE, and our little corner of the Linux command line. We master ls, grep, and cd, and we walk around with the quiet confidence of someone who knows their way around. But the terminal isn’t a neat, modern condo; it’s a sprawling, old mansion filled with secret passages, dusty attics, and bizarre little tools left behind by generations of developers.

Most people stick to the main hallways, completely unaware of the weird, wonderful, and handy commands hiding just behind the wallpaper. These aren’t your everyday tools. These are the secret agents, the oddballs, and the unsung heroes of your operating system. Let’s meet a few of them.

The textual anarchists

Some commands don’t just process text; they delight in mangling it in beautiful and chaotic ways.

First, meet rev, the command-line equivalent of a party trick that turns out to be surprisingly useful. It takes whatever you give it and spits it out backward.

echo "desserts" | rev

This, of course, returns stressed. Coincidence? The terminal thinks not. At first glance, you might dismiss it as a tool for a nerdy poetry slam. But the next time you’re faced with a bizarrely reversed data string from some ancient legacy system, you’ll be typing rev and looking like a wizard.

If rev is a neat trick, shuf is its chaotic cousin. This command takes the lines in your file and shuffles them into a completely random order.

# Create a file with a few choices
echo -e "Order Pizza\nDeploy to Production\nTake a Nap" > decisions.txt

# Let the terminal decide your fate
shuf -n 1 decisions.txt

Why would you want to do this? Maybe you need to randomize a playlist, test an algorithm, or run a lottery for who has to fix the next production bug. shuf is an agent of chaos, and sometimes, chaos is exactly what you need.

Then there’s tac, which is cat spelled backward for a very good reason. While the ever-reliable cat shows you a file from top to bottom, tac shows it to you from bottom to top. This might sound trivial, but anyone who has ever tried to read a massive log file will see the genius.

# Instantly see the last 5 errors in a huge log file
tac /var/log/syslog | grep -i "error" | head -n 5

This lets you get straight to the juicy, most recent details without an eternity of scrolling.

The obsessive organizers

After all that chaos, you might need a little order. The terminal has a few neat freaks ready to help.

The nl command is like cat’s older, more sophisticated cousin who insists on numbering everything. It adds formatted line numbers to a file, turning a simple text document into something that looks official.

# Add line numbers to a script
nl backup_script.sh

Now you can professionally refer to “the critical bug on line 73” during your next code review.

But for true organizational bliss, there’s column. This magnificent tool takes messy, delimited text and formats it into beautiful, perfectly aligned columns.

# Let's say you have a file 'users.csv' like this:
# Name,Role,Location
# Alice,Dev,Remote
# Bob,Sysadmin,Office

cat users.csv | column -t -s,

This command transforms your comma-vomit into a table fit for a king. It’s so satisfying it should be prescribed as a form of therapy.

The tireless workers

Next, we have the commands that just do their job, repeatedly and without complaint.

In the entire universe of Linux, there is no command more agreeable than yes. Its sole purpose in life is to output a string over and over until you tell it to stop.

# Automate the confirmation for a script that keeps asking
yes | sudo apt install my-awesome-package

This is the digital equivalent of nodding along until the installation is complete. It is the ultimate tool for the lazy, the efficient, and the slightly tyrannical system administrator.

If yes is the eternal optimist, watch is the eternal observer. This command executes another program periodically, showing its output in real time.

# Monitor the number of established network connections every 2 seconds
watch -n 2 "ss -t | grep ESTAB | wc -l"

It turns your terminal into a live dashboard. It’s the command-line equivalent of binge-watching your system’s health, and it’s just as addictive.

For an even nosier observer, try dstat. It’s the town gossip of your system, an all-in-one tool that reports on everything from CPU stats to disk I/O.

# Get a running commentary of your system's vitals
dstat -tcnmd

This gives you a timestamped report on cpu, network, disk, and memory usage. It’s like top and iostat had a baby and it came out with a Ph.D. in system performance.

The specialized professionals

Finally, we have the specialists, the commands built for one hyper-specific and crucial job.

The look command is a dictionary search on steroids. It performs a lightning-fast search on a sorted file and prints every line that starts with your string.

# Find all words in the dictionary starting with 'compu'
look compu /usr/share/dict/words

It’s the hyper-efficient librarian who finds “computer,” “computation,” and “compulsion” before you’ve even finished your thought.

For more complex relationships, comm acts as a file comparison counselor. It takes two sorted files and tells you which lines are unique to each and which they share.

# File 1: developers.txt (sorted)
# alice
# bob
# charlie

# File 2: admins.txt (sorted)
# alice
# david
# eve

# See who is just a dev, just an admin, or both
comm developers.txt admins.txt

Perfect for figuring out who has access to what, or who is on both teams and thus doing twice the work.

The desire to procrastinate productively is a noble one, and Linux is here to help. Meet at. This command lets you schedule a job to run once at a specific time.

# Schedule a server reboot for 3 AM tomorrow.
# After hitting enter, you type the command(s) and press Ctrl+D.
at 3:00am tomorrow
reboot
^D (Ctrl+D)

Now you can go to sleep and let your past self handle the dirty work. It’s time travel for the command line.

And for the true control freak, there’s chrt. This command manipulates the real-time scheduling priority of a process. In simple terms, you can tell the kernel that your program is a VIP.

# Run a high-priority data processing script
sudo chrt -f 99 ./process_critical_data.sh

This tells the kernel, “Out of the way, peasants! This script is more important than whatever else you were doing.” With great power comes great responsibility, so use it wisely.

Keep digging

So there you have it, a brief tour of the digital freak show lurking inside your Linux system. These commands are the strange souvenirs left behind by generations of programmers, each one a solution to a problem you probably never knew existed. Your terminal is a treasure chest, but it’s one where half the gold coins might just be cleverly painted bottle caps. Each of these tools walks the fine line between a stroke of genius and a cry for help. The fun part isn’t just memorizing them, but that sudden, glorious moment of realization when one of these oddballs becomes the only thing in the world that can save your day.

June 14, 2025 by DevOps stuff Linux Stuff

Podman the secure Daemonless Docker alternative

Podman has emerged as a prominent technology among DevOps professionals, system architects, and infrastructure teams, significantly influencing the way containers are managed and deployed. Podman, standing for “Pod Manager,” introduces a modern, secure, and efficient alternative to traditional container management approaches like Docker. It effectively addresses common challenges related to overhead, security, and scalability, making it a compelling choice for contemporary enterprises.

With the rapid adoption of cloud-native technologies and the widespread embrace of Kubernetes, Podman offers enhanced compatibility and seamless integration within these advanced ecosystems. Its intuitive, user-centric design simplifies workflows, enhances stability, and strengthens overall security, allowing organizations to confidently deploy and manage containers across various environments.

Core differences between Podman and Docker

Daemonless vs Daemon architecture

Docker relies on a centralized daemon, a persistent background service managing containers. The disadvantage here is clear: if this daemon encounters a failure, all containers could simultaneously go down, posing significant operational risks. Podman’s daemonless architecture addresses this problem effectively. Each container is treated as an independent, isolated process, significantly reducing potential points of failure and greatly improving the stability and resilience of containerized applications.

Additionally, Podman simplifies troubleshooting and debugging, as any issues are isolated within individual processes, not impacting an entire network of containers.

Rootless container execution

One notable advantage of Podman is its ability to execute containers without root privileges. Historically, Docker’s default required elevated permissions, increasing the potential risk of security breaches. Podman’s rootless capability enhances security, making it highly suitable for multi-user environments and regulated industries such as finance, healthcare, or government, where compliance with stringent security standards is critical.

This feature significantly simplifies audits, easing administrative efforts and substantially minimizing the potential for security breaches.

Performance and resource efficiency

Podman is designed to optimize resource efficiency. Unlike Docker’s continuously running daemon, Podman utilizes resources only during active container use. This targeted approach makes Podman particularly advantageous for edge computing scenarios, smaller servers, or continuous integration and delivery (CI/CD) pipelines, directly translating into cost savings and improved system performance.

Moreover, Podman supports organizations’ sustainability objectives by reducing unnecessary energy usage, contributing to environmentally conscious IT practices.

Flexible networking with CNI

Podman employs the Container Network Interface (CNI), a standard extensively used in Kubernetes deployments. While CNI might initially require more configuration effort than Docker’s built-in networking, its flexibility significantly eases the transition to Kubernetes-driven environments. This adaptability makes Podman highly valuable for organizations planning to migrate or expand their container orchestration strategies.

Compatibility and seamless transition from Docker

A key advantage of Podman is its robust compatibility with Docker images and command-line tools. Transitioning from Docker to Podman is typically straightforward, requiring minimal adjustments. This compatibility allows DevOps teams to retain familiar workflows and command structures, ensuring minimal disruption during migration.

Moreover, Podman fully supports Dockerfiles, providing a smooth transition path. Here’s a straightforward example demonstrating Dockerfile compatibility with Podman:

FROM alpine:latest

RUN apk update && apk add --no-cache curl

CMD ["curl", "--version"]

Building and running this container in Podman mirrors the Docker experience:

podman build -t myimage .
podman run myimage

This seamless compatibility underscores Podman’s commitment to a user-centric approach, prioritizing ease of transition and ongoing operational productivity.

Enhanced security capabilities

Podman offers additional built-in security enhancements beyond rootless execution. By integrating standard Linux security mechanisms such as SELinux, AppArmor, and seccomp profiles, Podman ensures robust container isolation, safeguarding against common vulnerabilities and exploits. This advanced security model simplifies compliance with rigorous security standards and significantly reduces the complexity of maintaining secure container environments.

These security capabilities also streamline security audits, enabling teams to identify and mitigate potential vulnerabilities proactively and efficiently.

Looking ahead with Podman

As container technology evolves rapidly, staying updated with innovative solutions like Podman is essential for DevOps and system architecture professionals. Podman addresses critical challenges associated with Docker, offering improved security, enhanced performance, and seamless Kubernetes compatibility.

Embracing Podman positions your organization strategically, equipping teams with superior tools for managing container workloads securely and efficiently. In the dynamic landscape of modern DevOps, adopting forward-thinking technologies such as Podman is key to sustained operational success and long-term growth.

Podman is more than an alternative—it’s the next logical step in the evolution of container technology, bringing greater reliability, security, and efficiency to your organization’s operations.

April 20, 2025 by DevOps stuff Kubernetes Linux Stuff SRE stuff

How to check if a folder is used by services on Linux

You know that feeling when you’re spring cleaning your Linux system and spot that mysterious folder lurking around forever? Your finger hovers over the delete key, but something makes you pause. Smart move! Before removing any folder, wouldn’t it be nice to know if any services are actively using it? It’s like checking if someone’s sitting in a chair before moving it. Today, I’ll show you how to do that, and I promise to keep it simple and fun.

Why should you care?

You see, in the world of DevOps and SysOps, understanding which services are using your folders is becoming increasingly important. It’s like being a detective in your own system – you need to know what’s happening behind the scenes to avoid accidentally breaking things. Think of it as checking if the room is empty before turning off the lights!

Meet your two best friends lsof and fuser

Let me introduce you to two powerful tools that will help you become this system detective: lsof and fuser. They’re like X-ray glasses for your Linux system, letting you see invisible connections between processes and files.

The lsof command as your first tool

lsof stands for “list open files” (pretty straightforward, right?). Here’s how you can use it:

lsof +D /path/to/your/folder

This command is like asking, “Hey, who’s using stuff in this folder?” The system will then show you a list of all processes that are accessing files in that directory. It’s that simple!

Let’s break down what you’ll see:

  • COMMAND: The name of the program using the folder
  • PID: A unique number identifying the process (like its ID card)
  • USER: Who’s running the process
  • FD: File descriptor (don’t worry too much about this one)
  • TYPE: Type of file
  • DEVICE: Device numbers
  • SIZE/OFF: Size of the file
  • NODE: Inode number (system’s way of tracking files)
  • NAME: Path to the file

The fuser command as your second tool

Now, let’s meet fuser. It’s like lsof’s cousin, but with a different approach:

fuser -v /path/to/your/folder

This command shows you which processes are using the folder but in a more concise way. It’s perfect when you want a quick overview without too many details.

Examples

Let’s say you have a folder called /var/www/html and you want to check if your web server is using it:

lsof +D /var/www/html

You might see something like:

COMMAND  PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
apache2  1234    www-data  3r  REG  252,0   12345 67890 /var/www/html/index.html

This tells you that Apache is reading files from that folder, good to know before making any changes!

Pro tips and best practices

  • Always check before deleting When in doubt, it’s better to check twice than to break something once. It’s like looking both ways before crossing the street!
  • Watch out for performance The lsof +D command checks all subfolders too, which can be slow for large directories. For quicker checks of just the folder itself, you can use:
lsof +d /path/to/folder
  • Combine commands for better insights You can pipe these commands with grep for more specific searches:
lsof +D /path/to/folder | grep service_name

Troubleshooting common scenarios

Sometimes you might run these commands and get no output. Don’t panic! This usually means no processes are currently using the folder. However, remember that:

  • Some processes might open and close files quickly
  • You might need sudo privileges to see everything
  • System processes might be using files in ways that aren’t immediately visible

Conclusion

Understanding which services are using your folders is crucial in modern DevOps and SysOps environments. With lsof and fuser, you have powerful tools at your disposal to make informed decisions about your system’s folders.

Remember, the key is to always check before making changes. It’s better to spend a minute checking than an hour fixing it! These tools are your friends in maintaining a healthy and stable Linux system.

Quick reference

# Check folder usage with lsof
lsof +D /path/to/folder

# Quick check with fuser
fuser -v /path/to/folder

# Check specific service
lsof +D /path/to/folder | grep service_name

# Check folder without recursion
lsof +d /path/to/folder

The commands we’ve explored today are just the beginning of your journey into better Linux system management. As you become more comfortable with these tools, you’ll find yourself naturally integrating them into your daily DevOps and SysOps routines. They’ll become an essential part of your system maintenance toolkit, helping you make informed decisions and prevent those dreaded “Oops, I shouldn’t have deleted that” moments.

Being cautious with system modifications isn’t about being afraid to make changes,  it’s about making changes confidently because you understand what you’re working with. Whether you’re managing a single server or orchestrating a complex cloud infrastructure, these simple yet powerful commands will help you maintain system stability and peace of mind.

Keep exploring, keep learning, and most importantly, keep your Linux systems running smoothly. The more you practice these techniques, the more natural they’ll become. And remember, in the world of system administration, a minute of checking can save hours of troubleshooting!

December 25, 2024 by DevOps stuff Linux Stuff SRE stuff

How to Change the Index HTML in Nginx: A Beginner’s Expedition

In this guide, we’ll delve into the process of changing the index HTML file in Nginx. The index HTML file is the default file served when a user visits a website. By altering this file, you can customize your website’s content and appearance. As we walk through the steps to modify the Nginx index HTML in Kubernetes with configmap, we’ll first gain an understanding of the Nginx configuration file and its location. Then, we’ll learn how to locate and modify the index HTML file. Let’s dive in!

Understanding the Nginx Configuration File.

The Nginx configuration file is where you can specify various settings and directives for your server. This file is crucial for the operation of your Nginx server. It’s typically located at /etc/nginx/nginx.conf, but the location can vary depending on your specific Nginx setup.

Locating the Index HTML File

The index HTML file is the default file that Nginx serves when a user accesses a website. It’s usually located in the root directory of the website. To find the location of the index HTML file, check the Nginx configuration file for the root directive. This directive specifies the root directory of the website. Once you’ve located the root directory, the index HTML file is typically named index.html or index.htm. It’s important to note that the location of the index HTML file may vary depending on the specific Nginx configuration.

server {
    listen 80;
    server_name example.com;
    root /var/www/html;
    
    location / {
        try_files $uri $uri/ =404;
    }
}

if the root directive is not immediately visible within the main nginx.conf file, it’s often because it resides in a separate configuration file. These files are typically found in the conf.d or sites-enabled directories. Such a structure allows for cleaner and more organized management of different websites or domains hosted on a single server. By separating them, Nginx can apply specific settings to each site, including the location of its index HTML file.

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {
    # Basic Settings
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # SSL Settings
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    # Logging Settings
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    # Gzip Settings
    gzip on;
    gzip_disable "msie6";

    # Virtual Host Configs
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Editing the Nginx Configuration File

To edit the Nginx configuration file, follow these steps:

  1. Open the terminal or command prompt.
  2. Navigate to the directory where the Nginx configuration file is located.
  3. Use a text editor to open the configuration file (e.g., sudo nano nginx.conf).
  4. Make the necessary changes to the file, such as modifying the server block or adding new location blocks.
  5. Save the changes and exit the text editor.
  6. Test the configuration file for syntax errors by running sudo nginx -t.
  7. If there are no errors, reload the Nginx service to apply the changes (e.g., sudo systemctl reload nginx).

Remember to back up the configuration file before making any changes, and double-check the syntax to avoid any errors. If you encounter any issues, refer to the Nginx documentation or seek assistance from the Nginx community.

Modifying the Index HTML File

To modify the index HTML file in Nginx, follow these steps:

  1. Locate the index HTML file in your Nginx configuration directory.
  2. Open the index HTML file in a text editor.
  3. Make the necessary changes to the HTML code.
  4. Save the file and exit the text editor

Common Questions:

  1. Where can I find the configuration file for Nginx?
    • Look for the Nginx configuration file at /etc/nginx/nginx.conf.
  2. Is it possible to relocate the index HTML file within Nginx?
    • Indeed, by altering the Nginx configuration file, you can shift the index HTML file’s location.
  3. What steps should I follow to modify the Nginx configuration file?
    • Utilize a text editor like nano or vim to make edits to the Nginx configuration file.
  4. Where does Nginx usually store the index HTML file by default?
    • Nginx generally keeps the index HTML file in the /usr/share/nginx/html directory.
  5. Am I able to edit the index HTML file directly?
    • Absolutely, you have the ability to update the index HTML file with a text editor.
  6. Should I restart Nginx to apply new configurations?
    • Restarting Nginx is required to activate any new configuration changes.

The Practicality of Mastery in Nginx Configuration

Understanding the nginx.conf file isn’t just academic—it’s a vital skill for real-world applications. Whether you’re deploying a simple blog or a complex microservices architecture with Kubernetes, the need to tweak nginx.conf surfaces frequently. For instance, when securing communications with SSL/TLS, you’ll dive into this file to point Nginx to your certificates. Or perhaps you’re optimizing performance; here too, nginx.conf holds the keys to tweaking file caching and client connection limits.

It’s in scenarios like setting up a reverse proxy or handling multiple domains where mastering nginx.conf moves from being useful to being essential. By mastering the location and editing of the index HTML file, you empower yourself to respond dynamically to the needs of your site and your audience. So, take the helm, customize confidently, and remember that each change is a step towards a more tailored and efficient web experience.

December 28, 2023 by DevOps stuff Kubernetes Linux Stuff SRE stuff

Essential Tools and Services Before Diving into Kubernetes

Embarking on the adventure of learning Kubernetes can be akin to preparing for a daring voyage across the vast and unpredictable seas. Just as ancient mariners needed to understand the fundamentals of celestial navigation, tide patterns, and ship handling before setting sail, modern digital explorers must equip themselves with a compass of knowledge to navigate the Kubernetes ecosystem.

As you stand at the shore, looking out over the Kubernetes horizon, it’s important to gather your charts and tools. You wouldn’t brave the waves without a map or a compass, and in the same vein, you shouldn’t dive into Kubernetes without a solid grasp of the principles and instruments that will guide you through its depths.

Equipping Yourself with the Mariner’s Tools

Before hoisting the anchor, let’s consider the mariner’s tools you’ll need for a Kubernetes expedition:

  • The Compass of Containerization: Understand the world of containers, as they are the vessels that carry your applications across the Kubernetes sea. Grasping how containers are created, managed, and orchestrated is akin to knowing how to read the sea and the stars.
  • The Sextant of Systems Knowledge: A good grasp of operating systems, particularly Linux, is your sextant. It helps you chart positions and navigate through the lower-level details that Kubernetes manages.
  • The Maps of Cloud Architecture: Familiarize yourself with the layout of the cloud—the ports, the docks, and the routes that services take. Knowledge of cloud environments where Kubernetes often operates is like having detailed maps of coastlines and harbors.
  • The Rigging of Networking: Knowing how data travels across the network is like understanding the rigging of your ship. It’s essential for ensuring your microservices communicate effectively within the Kubernetes cluster.
  • The Code of Command Line: Proficiency in the command line is your maritime code. It’s the language spoken between you and Kubernetes, allowing you to deploy applications, inspect the state of your cluster, and navigate through the ecosystem.

Setting Sail with Confidence

With these tools in hand, you’ll be better equipped to set sail on the Kubernetes seas. The journey may still hold challenges—after all, the sea is an ever-changing environment. But with preparation, understanding, and the right instruments, you can turn a treacherous trek into a manageable and rewarding expedition.

In the next section, we’ll delve into the specifics of each tool and concept, providing you with the knowledge to not just float but to sail confidently into the world of Kubernetes.

The Compass and the Map: Understanding Containerization

Kubernetes is all about containers, much like how a ship contains goods for transport. If you’re unfamiliar with containerization, think of it as a way to package your application and all the things it needs to run. It’s as if you have a sturdy ship, a reliable compass, and a detailed map: your application, its dependencies, and its environment, all bundled into a compact container that can be shipped anywhere, smoothly and without surprises. For those setting out to chart these waters, there’s a beacon of knowledge to guide you: IBM offers a clear and accessible introduction to containerization, complete with a friendly video. It’s an ideal port of call for beginners to dock at, providing the perfect compass and map to navigate the fundamental concepts of containerization before you hoist your sails with Kubernetes.

Hoisting the Sails: Cloud Fundamentals

Next, envision the cloud as the vast ocean through which your Kubernetes ships will voyage. The majority of Kubernetes journeys unfold upon this digital sea, where the winds of technology shift with swift and unpredictable currents. Before you unfurl the sails, it’s paramount to familiarize yourself with the fundamentals of the cloud—those concepts like virtual machines, load balancers, and storage services that form the very currents and trade winds powering our voyage.

This knowledge is the canvas of your sails and the wood of your rudder, essential for harnessing the cloud’s robust power, allowing you to navigate its expanse swiftly and effectively. Just as sailors of yore needed to understand the sea’s moods and movements, so must you grasp how cloud environments support and interact with containerized applications.

For mariners eager to chart these waters, there exists a lighthouse of learning to illuminate your path: Here you can find a concise and thorough exploration of cloud fundamentals, including an hour-long guided video voyage that steps through the essential cloud services that every modern sailor should know. Docking at this knowledge harbor will equip you with a robust set of navigational tools, ensuring that your journey into the world of Kubernetes is both educated and precise.

Charting the Course: Declarative Manifests and YAML

Just as a skilled cartographer lays out the oceans, continents, and pathways of the world with care and precision, so does YAML serve as the mapmaker for your Kubernetes journey. It’s in these YAML files where you’ll chart the course of your applications, declaring the ports of call and the paths you wish to traverse. Mastering YAML is akin to mastering the reading of nautical charts; it’s not just about plotting a course but understanding the depths and the tides that will shape your voyage.

The importance of these YAML manifests cannot be overstated—they are the very fabric of your Kubernetes sails. A misplaced indent, like a misread star, can lead you astray into the vastness, turning a straightforward journey into a daunting ordeal. Becoming adept in YAML’s syntax, its nuances, and its structure is like knowing your ship down to the very last bolt—essential for weathering the storms and capitalizing on the fair winds.

To aid in this endeavor, Geekflare sets a lantern on the dark shores with their introduction to YAML, a guide as practical and invaluable as a sailor’s compass. It breaks down the elements of a YAML file with simplicity and clarity, complete with examples that serve as your constellations in the night sky. With this guide, the once cryptic symbols of YAML become familiar landmarks, guiding you toward your destination with confidence and ease.

So hoist your sails with the knowledge that the language of Kubernetes is written in YAML. It’s the lingo of the seas you’re about to navigate, the script of the adventures you’re about to write, and the blueprint of the treasures you’re set to uncover in the world of orchestrated containers.

Understanding the Stars: Networking Basics

In the age of exploration, navigators used the stars to guide their vessels across the uncharted waters. Today, in the realm of Kubernetes, the principles of networking serve as your celestial guideposts. It’s not merely about the rudimentary know-how of connecting points A to B; it’s about understanding the language of the digital seas, the signals that pass like whispers among ships, and the lighthouses that guide them to safe harbor.

Just as a sailor must understand the roles of different stars in the night sky, a Kubernetes navigator must grasp the intricacies of network components. Forward and Reverse Proxies, akin to celestial twins, play a critical role in guiding the data flow. To delve into their mysteries and understand their distinct yet complementary paths, consider my explorations in these realms: Exploring the Differences Between Forward and Reverse Proxies and the vital role of the API Gateway, a beacon in the network universe, detailed in How API Gateways Connect Our Digital World.

The network is the lifeblood of the Kubernetes ecosystem, carrying vital information through the cluster like currents and tides. Knowing how to chart the flow of these currents—grasping the essence of IP addresses, appreciating the beacon-like role of DNS, and navigating the complex routes data travels—is akin to a sailor understanding the sea’s moods and whims. This knowledge isn’t just ‘useful’; it’s the cornerstone upon which the reliability, efficiency, and security of your applications rest.

For those who wish to delve deeper into the vastness of network fundamentals, IBM casts a beam of clarity across the waters with their guide to networking. This resource simplifies the complexities of networking, much like a skilled astronomer simplifying the constellations for those new to the celestial dance.

With a firm grasp of networking, you’ll be equipped to steer your Kubernetes cluster away from the treacherous reefs and into the calm waters of successful deployment. It’s a knowledge that will serve you not just in the tranquil bays but also in the stormiest conditions, ensuring that your applications communicate and collaborate, just as a fleet of ships work in unison to conquer the vast ocean.

The Crew: Command Line Proficiency

Just as a seasoned captain relies on a well-trained crew to navigate through the roiling waves and the capricious winds, anyone aspiring to master Kubernetes must rely on the sturdy foundation of the Linux command line. The terminal is your deck, and the commands are your crew, each with their own specialized role in ensuring your journey through the Kubernetes seas is a triumphant one.

In the world of Kubernetes, your interactions will largely be through the whispers of the command line, echoing commands across the vast expanse of your digital fleet. To be a proficient captain in this realm, you must be versed in the language of the Linux terminal. It’s the dialect of directories and files, the vernacular of processes and permissions, the lingo of networking and resource management.

The command line is your interface to the Kubernetes cluster, just as the wheel and compass are to the ship. Here, efficiency is king. Knowing the shortcuts and commands—the equivalent of the nautical knots and navigational tricks—can mean the difference between smooth sailing and being lost at sea. It’s about being able to maneuver through the turbulent waters of system administration and scriptwriting with the confidence of a navigator charting a course by the stars.

While ‘kubectl’ will become your trusty first mate once you’re adrift in Kubernetes waters, it’s the Linux command line that forms the backbone of your vessel. With each command, you’ll set your applications in motion, you’ll monitor their performance, and you’ll adjust their course as needed.

For the Kubernetes aspirant, familiarity with the Linux command line isn’t just recommended, it’s essential. It’s the skill that keeps you buoyant in the surging tides of container orchestration.

To help you in this endeavor, FreeCodeCamp offers an extensive guide on the Linux command line, taking you from novice sailor to experienced navigator. This tutorial is the wind in your sails, propelling you forward with the knowledge and skills necessary to command the Linux terminal with authority and precision. So, before you hoist the Kubernetes flag and set sail, ensure you have spent time on the command line decks, learning each rope and pulley. With this knowledge and the guide as your compass, you can confidently take the helm, command your crew, and embark on the Kubernetes odyssey that awaits.

New Horizons: Beyond the Basics

While it’s crucial to understand containerization, cloud fundamentals, YAML, networking, and the command line, the world of Kubernetes is ever-evolving. As you grow more comfortable with these basics, you’ll want to explore the archipelagos of advanced deployment strategies, stateful applications with persistent storage, and the security measures that will protect your fleet from pirates and storms.

The Captains of the Clouds: Choosing Your Kubernetes Platform

In the harbor of cloud services, three great galleons stand ready: Amazon EKS, Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). Each offers a seasoned crew and a vessel ready to brave the Kubernetes seas. While they share the same end goal, their tools, and amenities differ. Choose your ship wisely, captain, for it will be your home throughout your Kubernetes adventures.

The Journey Begins

Remember, Kubernetes is more than a technology; it’s a journey. As you prepare to embark on this adventure, know that the seas can be choppy, but with preparation, a clear map, and a skilled crew, you’ll find your way to the treasure of scalable, resilient, and efficient applications. So, weigh anchor and set sail; the world of Kubernetes awaits.

December 3, 2023 by Cloud stuff DevOps stuff Kubernetes Linux Stuff
NivelEpsilon
Exploring the Cloud: Insights into DevOps, Linux & Architectural Evolution