DevOps.Pink

AI SRE Joined My On-Call — A Beginner-Friendly Walkthrough of Rootly

2026-05-12T00:00:00.000Z

You know the feeling. You finally sat down to eat, or just closed your laptop for the night, and your phone lights up. P1. Prod is down.

If you're new to on-call, that first incident is rough. Slack has twelve people typing. Your dashboards are a wall of red. You're flipping between logs, recent deploys, and that PR a coworker merged twenty minutes ago. Was it the deploy? The cache? CI/CD? Half the code in your stack was written by someone who left two years ago. The other half was written by an AI nobody fully audited. Welcome to modern on-call.

This is the gap a new category of tooling is trying to close — AI SRE. I walked through one of them, Rootly, and here's the honest beginner's take.

import VideoPlayer from "@components/VideoPlayer.astro";

Why "AI SRE" became a thing in 2026

Three forces converged. First, microservice sprawl means no single human can hold the whole architecture in their head anymore. Second, the people who wrote half the code have moved on, taking their context with them. Third, LLMs got good enough at code reasoning that they can plausibly assemble that lost context from logs, runbooks, and past postmortems.

So "AI SRE" is not a buzzword for "we put a chatbot in our incident channel." It's tooling that ingests your full incident surface area — runbooks, past postmortems, Slack incident channels, IaC, application code — and helps you reason about a failure faster than you could alone.

The AI part is doing two specific jobs:

Indexing your tribal knowledge. Every postmortem you've ever written, every Slack thread where someone said "oh, this is just X again" — that's training material your AI SRE keeps loaded and searchable.
Correlating live signals when an alert fires. Logs, metrics, recent commits, recent deploys. It pulls those together and produces a hypothesis with citations: "This looks similar to incident #438 from last March, and a deploy went out 12 minutes ago that touched the same code path."

You still decide what to do. You just skip the thirty minutes of frantic tab-switching that usually precedes any real thinking.

How Rootly handles trust: the four-level model

This is the part I cared about most. AI in production sounds great in a demo and terrifying when it's actually firing on a real incident. Nobody wants an autonomous agent rolling back deploys because it pattern-matched on the wrong thing.

Rootly publishes an AI SRE Maturity Model with four explicit levels, and you adopt them progressively. The names in the docs are formal; here's the practical version:

Level 1 — Observe. (Officially: "Read-Only Copilot.") The AI watches and produces context packets with verifiable hypotheses linked to evidence. It does not execute anything. This is the trust-building stage — you can challenge every conclusion, and the AI shows its work.

Level 2 — Advise. Still part of Level 1 in the formal model, but worth calling out: the AI now suggests specific next steps with a reasoning trail. "Consider rolling back deploy abc123. Here's why." You still drive.

Level 3 — Approve. (Officially: "Assisted Actions With Approvals.") The AI can initiate actions — rollbacks, config changes, scale-ups — but only through a workflow engine that enforces RBAC, audit logs, and verification gates. Nothing executes without a human approval click. This is where the time savings start to compound.

Level 4 — Autonomous. (Officially: "Guardrailed Autonomy for Narrow, Reversible Failure Modes.") As Rootly puts it: "This is not 'AI resolves incidents.' It is 'AI resolves a small number of repeatable incidents safely.'" Autonomous execution applies only to allow-listed, reversible runbooks with clear preconditions and stop conditions. Most teams reach this level only for a handful of specific failure modes after months of safe operation at Level 3.

The philosophy underneath is what Rootly calls "human-on-the-loop" — an engineer always has the final say on critical actions, accountability stays human. That's the right framing. It's also what separates serious AI SRE products from the demoware.

What stood out beyond the trust model

The post-incident timeline writes itself. After an incident closes, Rootly assembles the full sequence — when the alert fired, who joined the war room, what commands were run, what was tried, what fixed it. Postmortems usually take me an hour minimum. This drops it to "review and edit."

Citations on every recommendation. When the AI suggests a fix, it links to the past incident, runbook, or code line that informed the decision. You can challenge it. AI tools that refuse to show their work make me nervous; this one doesn't.

Bring your own AI API key. You plug in your own LLM credentials — OpenAI, Anthropic, or a self-hosted model. Your incident data is scoped to your account. Rootly's docs are explicit: "PII is automatically scrubbed and never used for training. Opt out anytime." For anyone in a regulated industry, that's the difference between "evaluate" and "can't even start the conversation."

The Rootly MCP server. This is the 2026-flavored part I didn't expect. Rootly ships an MCP (Model Context Protocol) server that plugs your incident context directly into IDEs like Cursor, Windsurf, and Claude Desktop. Mid-incident, you can ask your editor "what was the last change to the auth service?" and the answer comes from Rootly's correlation engine — without copy-pasting between five windows. If you've been following the MCP wave, this is the kind of practical integration the protocol was designed for.

The customer list is heavy on companies you'd recognize — NVIDIA, Canva, Webflow, Figma, LinkedIn, Replit, Grammarly, Mistral AI, Brex, DoorDash, SoFi. That's not a side-project tool; it's running production at scale.

Will it replace me?

The honest answer: no, but it changes the job.

Junior on-call shifts today are mostly "navigate to the right dashboard, identify the obvious thing, page a senior if it's not obvious." Levels 1 and 3 of the trust model handle the navigation and the obvious things. What's left for the human is the actual judgment — "is this the right rollback target," "do we communicate to customers now," "is this incident a symptom of a deeper architectural problem."

That's a better job. Less tab-juggling, more thinking. The path from junior to senior gets shorter because you spend rotation time on real decisions instead of pattern-matching against dashboards.

Who this is for

If you're a solo SRE drowning in alerts, this is for you. If you're a team lead and your engineers are burning out on rotation, this is for you. If you're early in your career and want to see what production on-call actually looks like, walking through Rootly's setup is a decent way to learn what the work involves before your first real pager.

The promise isn't "AI replaces your on-call." It's "AI handles the busywork so the thinking part is faster." Which, after a year of false-positive alerts and broken pager rotations, is what most of us actually need.

If on-call is starting to hurt, Rootly is worth a real evaluation. Start at Level 1 — observe-only — and see what it catches that you'd miss. You don't promote to Level 3 until you trust the Level 1 output. That's the right shape for adopting any AI tool in production.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Stop Lying About Your Backups — Zero-Trust Recovery with Plakar

2026-02-10T00:00:00.000Z

Hey my DevOps queens (and kings, too)!

Let's talk. We need to have a serious heart-to-heart. Put down your coffee, close your tickets, and let's be real. We need to discuss something uncomfortable. Because I know your secret.

You're lying.

Every morning, you look at those green backup checkmarks and tell the business:

"We are protected."

But deep down... you're praying you never have to test that theory. Because you know: if prod goes down, those checkmarks won't save you.

That's not a strategy — it's chronic fear.

Relax. ✨ Today, we are not fixing your services. Today, we are treating your fears. We're going to get rid of what keeps you up at night. We'll go through your traumas — point by point — and shut them down.

And for this, we'll use Plakar. ️

It's Open Source. I know that matters to you. No black boxes.

import VideoPlayer from "@components/VideoPlayer.astro";

1. The Fear of Recovery

Your first trauma is the fear of recovery.

We all know the nightmare: you restore the files... but the system doesn't work. Why? Because standard backups save the data, but they lose the context.

Permissions are broken
Timestamps are reset
Dependencies are gone

It's pure chaos. You have the pieces, but you lost the picture. Your system has amnesia.

Plakar is Digital Memory

It preserves the exact state: ownership, modes, and extended attributes. The relationships between files remain intact. You simply open Plakar and restore the snapshot — fast, granular, and reliable.

2. The Trap of Dependence

Let's move on. You feel dependent.

You keep everything in the cloud, and you know: if they hike prices tomorrow or lock your account, you can't get your data out fast. You're trapped.

Plakar treats this with total portability. It packs data into a Kloset — a self-contained repository.

You can keep it on S3 today, and tomorrow replicate snapshots to another Kloset store:

Local disk
Another cloud provider
Wherever you want

No format conversion. No complex migrations. The data belongs to you, not the infrastructure. You are free to choose where to live.

3. Paranoia

The third point is Paranoia.

You send data to the cloud — and often, control over where and how encryption happens isn't fully yours. You're forced to take their word for it.

But what if they get hacked? Or a rogue insider decides to peek at your files? You are handing your secrets to strangers.

Client-Side Encryption

Plakar does it differently. Data is encrypted on your end, at the source, before it leaves for storage. Nothing readable goes to the cloud.

To the outside world, it's just encrypted chunks — meaningless without your keys. You can delegate storage without delegating access. The risk of a cloud breach drops sharply.

You are protected.

4. Budget

And finally — budget.

You look at cloud bills and realize: you're paying for air. You're storing 50 copies of the same operating system. You're paying for the same thing 50 times. Your infrastructure is bloated.

Smart Deduplication

Plakar cuts out the fat. It breaks files into chunks. If you have a hundred similar servers, repeated chunks aren't duplicated.

The result:

Drastically smaller storage footprint
Significantly lower storage bills
No wasted company money

And your CFO will finally be happy.

The Prescription

Your fears aren't just "part of the job." They are symptoms of outdated architecture.

You don't need to learn to live with the pain. You need to change the tool.

Plakar gives you:
✅ Predictable recovery
✅ Independence from clouds
✅ Real privacy
✅ Smart savings

Our session is over for today. Try Plakar and finally start sleeping peacefully.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Escaping the Command Line Cartel: Why I Mandate Visual Git in Enterprise DX

2026-01-15T00:00:00.000Z

Today, I want to talk about the elephant in the server room: the romanticization of the CLI.

For years, relying purely on the terminal has been worn as a badge of honor in engineering. But if we evaluate it strictly as a Developer Experience (DX) framework, the terminal often behaves like a toxic dependency. We suffer through endless flags, fear pressing Enter on a force push, and accept the massive cognitive drain simply because “that's how real engineers do it.” This is gatekeeping, not architecture. True engineering prioritizes safety, speed, and absolute clarity. That's why I completely overhauled my version control workflow and integrated GitKraken as my primary Git interface.

Here is the architectural breakdown of why visual DX is fundamentally superior to the terminal.

import VideoPlayer from "@components/VideoPlayer.astro";

1. High-Signal Telemetry (Total Honesty)

The terminal obscures the narrative. To understand the history of a complex repository, you have to interrogate it with git log and attempt to visualize the multi-branch commit tree entirely in your head.

GitKraken provides immediate, high-signal telemetry. The commit graph is visually absolute—every branch, every merge, and every pivot is mapped out in front of you. It's not just a GUI; it is an auditable, honest map of your engineering truth. You see exactly who did what, and why, without typing a single query.

2. Tactile Architecture & Frictionless Workflows

In the CLI, you are typing abstract spells into a black box. There is a profound disconnect between the command and the architecture.

GitKraken transforms version control into a tactile experience. If I need to merge or rebase, I don't rely on rote memorization of syntax. I grab the branch and visually pull it onto another. Drag. And. Drop. It removes the friction between intention and execution, allowing me to interact with the codebase with zero latency.

3. Adult Conflict Resolution

In a standard CLI workflow, resolving a complex merge conflict is an exercise in stress management. The terminal presents a wall of text, and one wrong keystroke can break the build.

GitKraken reframes this into an analytical, structured conversation with the code. The visual merge conflict editor is a masterclass in DX:

I see my version.
I see the incoming version.
I see the output.

A few clicks to select what stays and what goes. No panic. No broken syntax. Just a calm, resolved deployment.

4. Psychological Safety (The Magic Button)

Enterprise infrastructure requires strict guardrails. We all make mistakes, and in the terminal, a bad commit feels catastrophic.

GitKraken introduces the ultimate layer of psychological safety: the Undo button. If I drop a stash, mess up a rebase, or commit to the wrong branch, I click one button, and the state is perfectly restored. Knowing that I have an immediate rollback mechanism fundamentally shifts how aggressively and confidently I can code.

5. Ecosystem Interoperability

A tool's value is defined by its ecosystem. GitKraken doesn't exist in a vacuum; it acts as an interoperability hub.

It natively integrates with Jira, GitHub, and GitLab, centralizing the context so I don't have to jump between ten different browser tabs. More importantly, through GitLens in VS Code, the visual context follows me directly into my IDE. It provides inline telemetry—showing exactly who authored a line and when—quietly providing context right when I need it.

The Executive Verdict

Beautiful, intuitive, and relentlessly efficient. It handles merge conflicts visually, integrates seamlessly across the enterprise stack, and actively mitigates human error.

Does your terminal do that?

If you are ready to stop fighting your tools and upgrade your Developer Experience, use my strategic alliance link below to deploy GitKraken.

Deploy GitKraken Pro (50% Executive Subsidy) ->

Join the conversation in the Discord Syndicate: are you staying loyal to the terminal, or are you ready to upgrade your architecture?

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Kubernetes Is No Longer Number One — The REAL 2025 Cloud Native Report (CNCF x SlashData)

2025-11-30T00:00:00.000Z

Hey my cloud-native queens, kings, and everyone shipping to production in between.

In this article, we're going to walk through the key facts from the 2025 “State of Cloud Native” report by CNCF and SlashData.

Here's the main spoiler: Kubernetes is NO LONGER the most interesting number.

While everyone's chasing K8s, the real action is somewhere else.

This data is based on over 12,000 developers from 128 countries, collected between June and July 2025, with a breakdown by role: backend, DevOps, ML/AI, IoT, and games.

Let's get straight to the facts.

import VideoPlayer from "@components/VideoPlayer.astro";

Finding Number One: Backend won

56% of backend developers are now cloud native.

In absolute numbers, that's 15.6 million cloud-native developers, and 9.3 million of them are backend.

Why does this matter? Because backend teams carry the weight for APIs, observability, microservices, CI/CD, and service ownership.

If you're building a platform, build it for backend and DevOps — not for “everyone in general”.

Backend + DevOps is the new core of the cloud-native community.

Finding Number Two: AI is not that cloud native

You might expect AI/ML to be all-in on the cloud and GPUs — but only 41% of ML/AI professionals are cloud native.

One big reason, according to the report, is the heavy use of MLaaS — managed services that abstract away the underlying infrastructure.

AI models keep scaling, but the classic DevOps discipline — logs, versioning, deployments — often lags behind.

For DevOps, SREs, and Platform Engineers, that's a huge window of opportunity: bring proper engineering hygiene into MLOps — real pipelines, versioned environments, logs, and managed clusters.

Finding Number Three: What's really being used

The most widely used cloud-native technologies are not exotic at all. They're very down-to-earth:

API gateways — 50%
Microservices — 46%
Kubernetes — 28%
Observability — 28%

Observability (28%) has now caught up to Kubernetes (28%). “Just running it” is no longer enough — everyone understands you have to see what's going on, too.

And then there's service mesh: 8%. Eight percent. The hype made it sound like 80.

So the world isn't living in “service mesh everywhere”. It's living in:

just give me a solid gateway, logs, and orchestration.

If you're building a product for DevOps, aim for this reality — not for super-exotic architectures almost nobody runs.

What to do with this data

If you're an architect, a DevOps team lead, or building a platform, here's what this report is really telling you:

Go backend- and DevOps-first. These two groups are the most cloud-native in the report. This is where you bring IDPs, artifact repositories, and policy-as-code.
Support hybrid. 30% of all developers are on hybrid cloud, 23% are multi-cloud. Your networking, secrets, and observability need to span everything, not just a single provider.
Bring ML teams up to code. If you have ML folks in-house, give them the same level of engineering hygiene as your production teams: versioned environments, pipelines, logs, clusters, and proper deployments.
Don't over-engineer. The mainstream stack is this combo: API gateways, microservices, Kubernetes, plus observability — not some universal service mesh everywhere. This is a mature, understandable stack where you can actually ship and make money.

Final verdict

Cloud native is now mainstream for backend and DevOps — and AI is just playing catch-up.

How does this look in your company or team? Do these numbers match your reality, or is your stack going in a different direction?

Share your experience in the comments — I'm genuinely curious to see how this data maps to real life.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Amazon Q - The AI DevOps Tool That Fixes AWS Headaches

2025-11-10T00:00:00.000Z

You know that feeling when something breaks in AWS and no one knows why?

Yeah - today's post is about fixing that.

import VideoPlayer from "@components/VideoPlayer.astro";

Meet Amazon Q

An AI assistant, built right into AWS. Marketed as your new cloud teammate.

But it's not just here to chat. It's here to help.

Not “Hello, World,” but more like:

“Why does your IAM keep blocking Lambda again?”

It looks at your setup. Your permissions. Your infrastructure.

It's like having a senior AWS engineer trapped inside your console - and you get to say:

“Please explain why nothing works. Again.”

And honestly? Sometimes it's more helpful than that coworker who answers three days later… and still not on topic.

How It Works in Real Life

Sounds great, right? But how does it look in real life?

Here are a few examples everyone who's touched AWS will recognize.

Example 1: The Silent Lambda

You try to run a Lambda - nothing happens.

No errors. No logs. Just… silence.

You start guessing: wrong trigger? Bad permissions?

Q checks your config, IAM, event sources - and says:

“Missing permission here. Add this - and you're good to go.”

Example 2: Building a VPC

You want to spin up a VPC with NAT and two subnets.

Normally: 30 minutes of Googling and a hundred lines of YAML-induced headache.

Q just says:

“Here's the template. One click - done.”

Example 3: Route 53 DNS Setup

Need to configure DNS in Route 53.

You open the console and feel like it's day one in AWS.

Q doesn't throw 10 outdated forum links at you - it explains what to do, why it matters, and helps you understand the steps - though you'll still need to describe your setup.

Who Amazon Q Helps

Q helps not only those drowning in IAM configs or forgetting how to YAML.

New to AWS? Q will explain where you got stuck - and why.
Experienced? It'll save you a couple of hours a day.
Working in a team? Fewer sync calls. More releases. Less pain.

Q's always got your back.

ChatGPT vs Amazon Q

But what about ChatGPT? It knows everything too, right?

Well… not your account. ChatGPT gives you theory. Q gives you context.

It's like giving ChatGPT access to your AWS console - and saying:

“Just don't break anything.”

A Few Things to Keep in Mind

Still, there are a few things to keep in mind:

Some features are still in Preview
It's not available in every region yet - but works in us-east-1, us-west-2, and eu-central-1
Complex setup? You'll still need to get hands-on
Working with Terraform or other IaC? Q works best in your editor or CLI, not just clicking around in the console

Final Thoughts

But here's the deal:

This is the first AI tool that actually helps DevOps engineers - not with theory, but with real, practical answers.

And not just for those who read AWS docs like bedtime stories. Q gets things done.

So now there's only one question:

“Will you try it - or keep debugging IAM on Saturdays?”

Join the Conversation

If you found this article helpful - give it a share

Subscribe if you want more DevOps, cloud, and automation content - and join our Discord (link's in the description).

And tell me in the comments:
What's the one AWS thing that always trips you up?

Maybe Q already knows how to fix it

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Inside Helm - How Charts, Releases, and State Work in Kubernetes

2025-11-09T00:00:00.000Z

Hey my DevOps queens (and kings, too)!

If you've ever deployed an app to Kubernetes and thought, “Wait… what actually happens after I type helm install?” — this one's for you.

Helm makes Kubernetes deployments look easy. But behind the scenes, it's doing a lot more than just rendering YAML files. It's a stateful release manager that tracks every change, stores versioned state inside your cluster, and handles upgrades intelligently — no external database required.

Today, let's pull back the curtain and see how Helm actually works: how charts are structured, where your release data lives, and how Helm keeps everything consistent and versioned like a pro.

What's Inside a Helm Chart

A Helm chart is a package that describes how your app should be deployed to Kubernetes. It's structured, predictable, and — if you do it right — beautifully reusable.

my-chart/
  Chart.yaml              # metadata (name, version, dependencies, etc.)
  values.yaml             # default configuration values
  templates/              # Go templates for Kubernetes manifests
    _helpers.tpl          # reusable named templates and functions
  charts/                 # subcharts (dependencies)
  files/                  # arbitrary files used in templates
  crds/                   # CustomResourceDefinitions (installed first)
  .helmignore             # like .gitignore for packaging

Think of it as your app blueprint — flexible through values.yaml and easily overridden at deploy time.

Pro tip: CRDs in the crds/ directory are:

installed first,
not templated,
and never upgraded or deleted — this protects existing Custom Resources and data.

What Actually Happens When You Run helm install

Let's break it down. When you run helm install, Helm doesn't just “apply some YAML.” It follows a clear sequence:

Loads the chart (local or remote).
Merges values from multiple sources:
- base values.yaml;
- any additional files: -f base.yaml -f prod.yaml (left-to-right; later overrides earlier);
- inline flags: --set, --set-string, --set-file, --set-json (these always take precedence).
Renders Go templates into complete Kubernetes manifests.
Applies them to the cluster.

On a clean install, Helm creates the resources.

If resources already exist and contain the correct Helm annotations (meta.helm.sh/*, app.kubernetes.io/managed-by=Helm), Helm will adopt them. Otherwise, you'll see:

Error: invalid ownership metadata

During upgrades or rollbacks, Helm performs a three-way strategic merge — comparing the previous manifest, the new manifest, and the current cluster state — handled client-side through client-go.

Where Helm Stores Release State

Every Helm release is stored inside your cluster. No external DBs, no magic.

By default, Helm saves release info in a Kubernetes Secret, though you can switch to a ConfigMap or SQL driver (PostgreSQL).

Default object structure:

kind: Secret
type: helm.sh/release.v1
metadata:
  name: sh.helm.release.v1..v
  namespace:

The .data.release field contains a base64-encoded, gzip-compressed blob with:

the chart archive,
rendered manifests,
merged values,
hooks,
and release metadata (revision, timestamps, status).

Because Secret data is base64-encoded by Kubernetes — and the release payload also includes encoded sections — the result is effectively nested encoding.

Heads up: etcd enforces a ~1 MiB limit for Secret data. If you hit:

Too long: must have at most 1048576 characters

switch to SQL storage:

export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://user:pass@host/db

Labels and Annotations

Helm labels everything it manages to track ownership precisely.

Added automatically:

app.kubernetes.io/managed-by=Helm
meta.helm.sh/release-name=
meta.helm.sh/release-namespace=

Best-practice labels (usually added by chart templates):

app.kubernetes.io/instance=
helm.sh/chart=-

If these don't match during an upgrade, Helm will refuse ownership — hence the classic invalid ownership metadata error.

What Is a Helm Release?

A release is one installed instance of a chart with a specific set of values (in a namespace).

Each change — install, upgrade, rollback — becomes a new revision stored right in your cluster. No external database. No API extension. Just Kubernetes objects doing their job.

The Three-Way Merge Explained

When you upgrade, Helm compares:

the previous rendered manifest,
the new manifest (after your changes),
the current live resources.

Then it calculates a three-way strategic merge patch and applies only what changed — reducing disruption and preserving manual tweaks where possible.

:::note This logic runs client-side, not via Server-Side Apply. For CRDs or unstructured resources, Kubernetes uses JSON merge-patch, which can behave slightly differently. :::

Namespaces: Release vs Target

Helm separates namespaces into two categories:

Release namespace — where Helm stores its Secret or ConfigMap.
Target namespaces — where chart resources are deployed (can be multiple).
--create-namespace only creates the release namespace (the one you pass with --namespace).

If your chart deploys across namespaces, create them manually or template them inside your chart.

Tip: Avoid hardcoding metadata.namespace unless you really need to — otherwise helm template | kubectl apply might push resources to default.

Storage Drivers

Helm supports multiple backends for storing release state:

export HELM_DRIVER=secret      # default (encoded, secure)
export HELM_DRIVER=configmap   # readable, not encrypted
export HELM_DRIVER=sql         # PostgreSQL – best for large releases
export HELM_DRIVER=memory      # ephemeral, for tests only

Managing Release History

Helm keeps all revisions unless you limit it. You can cap history like this:

helm upgrade --history-max 10 ...
export HELM_MAX_HISTORY=10

Explore release history anytime:

helm history 
helm get values 
helm get manifest

TL;DR

Helm isn't magic — it's clean engineering. Behind every helm install, it:

loads, merges, and renders templates,
stores state inside your cluster,
tags resources for ownership tracking,
applies three-way strategic merges on upgrade,
manages revisions — all with zero external dependencies.

Once you understand how Helm really works, it stops feeling mysterious and starts feeling like your favorite DevOps assistant.

Quick Debug Tip

helm ls -A
kubectl get secrets -A -l "owner=helm" -l "status=deployed"

Perfect for quick audits or just checking what Helm has been managing lately.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Git Merge Conflicts for Beginners - What to Do When Your Branches Have Beef

2025-07-14T00:00:00.000Z

Hey queens! ✨

Okay, so picture this: you've been hustling for days on a sick new feature in your own cozy little branch. The code is flawless, everything works perfectly, and you're ready to share your masterpiece with the world (or, you know, the main branch). You proudly type out that magic git merge command and… oops!

Git literally screams at you: "CONFLICT! I have no idea what to keep!" Sound familiar? The first instinct is full-on panic mode. You just want to slam your laptop shut and pretend it never happened. But wait! Don't freak out. We're gonna walk through this together, and I'll spill all the tea.

Wait, What Even Is `git merge`?

Let's break it down. When you're working on a project, you create branches, which are basically parallel universes for your code. You can do whatever you want in your own branch without messing up the main project. It's your personal creative space.

And git merge is the command that brings your universe back into the main timeline.

For example:

git checkout main
git merge feature/new-login

This is literally you telling Git, "Hey, take all the awesome stuff I built in feature/new-login and add it to the main branch, please!"

When It's a Buttery-Smooth Ride

(The Fast-Forward Merge)

If you and your teammates were working on totally different files, Git is a total genius. It will seamlessly combine everything on its own, and you won't even notice. Pure magic! ✨

Technically, this is called a Fast-Forward Merge. It happens when the main branch hasn't had any new commits since you created your branch. Git just "fast-forwards" the main pointer to include all your new commits.

Sometimes, to keep a clear history, developers force Git to create a merge "knot" even when it could fast-forward. This is done with:

git merge --no-ff feature/new-login

…and it leaves a nice little note in the project history saying, "This feature was merged right here."

When Git Has a Meltdown (aka a Conflict)

A conflict happens when you and someone else (or even you in a different branch) changed the exact same line of code in different ways. Git gets totally overwhelmed. It looks at the two versions and can't decide which one is right. It's basically looking at you like, "OMG, girl, I can't decide. You have to choose!"

What This Hot Mess Looks Like in Your Code

You open the file, and boom — Git greets you with something like this:

<<<<<<< HEAD
The version of the code from the main branch
=======
The version of the code from your new feature/new-login branch
>>>>>>> feature/new-login

Don 't panic!

This isn 't an error — it 's Git 's way of saying:

"Hey, I found two different versions of this code and I don 't know which one to keep. Can you help me out?"

Here 's what those weird lines mean:

<<<<<<< HEAD - This is what 's currently in your main branch.
======= - This line separates the two versions.
>>>>>>> feature/new-login - And this is the version coming from your branch.

Okay, So How Do I Fix This? A Step-by-Step Guide!

Breathe! You've got this.
Analyze the code. Take a look at both versions. Which one do you need? Maybe you need a little bit of both? The final decision is all yours.
Edit the file. Just delete the code you don't want and leave only the code that should be there.
Delete the markers. You have to get rid of the <<<<<<<, =======, and >>>>>>> lines. They've served their purpose.
Save the file.

And that's it! The conflict in the code is officially resolved.

The Final Steps: Letting Git Know You're a Genius

Now you just have to tell Git that you've handled it and everything is okay:

Tell Git you've resolved the conflict in this file

git add

Finalize the merge with a commit

git commit

Git will usually pop up a pre-written commit message for you. You can totally just use that.

And you're done! The merge is complete, and your amazing new feature is safe and sound in the main branch!

SOS! What If I Messed Everything Up?

If you started fixing a conflict and suddenly realized you're in way over your head, don't worry! There's an escape button:

git merge --abort

This command will completely cancel the merge, like it never even happened. Your project will go right back to how it was before you started. You can take a breath and try again when you're ready.

How to Vibe with merge and Avoid Conflicts

Always stay updated! Before you start working on a new feature, always update your main branch. The safest way is a two-step: run git fetch (which just downloads the latest changes without touching your code) and then git merge origin/main (to apply those changes). This seriously lowers the chances of a conflict.
Stay in your own lane. If you can, try to work on different files than your teammates.
Communicate! This is the biggest one. Actually talk to your team about who's working on what. A good convo is the key to a conflict-free life.

The Takeaway

Git conflicts are not the end of the world. They're totally normal. It doesn't mean you're a bad developer. It's just Git's way of saying, "Hey! I've got two different things here—can you help me choose?"

And now you know exactly how to help. Honestly? You're already one step closer to feeling like a total pro in Git.

**Keep coding, girl! You're killing it! **

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Git Branches - How to Not Break Prod and Stay Alive

2025-06-16T00:00:00.000Z

Hey queens. You're building stuff. Pushing code. Shipping features.

And then someone says:

“Just create a branch for that.”

Wait — a what?

Let's be real. Git can feel like sorcery at first. Branches? Rebases? Merge commits? Upstream what?

But here's the truth:

Branches are not scary. They're your safety net. Your creative zone. Your undo button.

They let you try bold things without risking production.

They help teams build fast — and stay sane.

This guide breaks it down, step by step.

No buzzwords. No hand-waving. Just real Git, the way developers actually use it in 2025.

Let's start from the core idea — what even is a branch?

What's a Branch, Really?

A branch is a pointer (a variable) that references a commit.

In practice, it's a parallel version of your codebase where you can work safely — nothing affects main until you decide it's ready.

Branches give you:

freedom to experiment,
a clean commit history,
protection from disaster,
and a solid setup for teamwork.

How to Work with Branches - Step by Step

1. Create a New Branch and Switch to It

Modern way (Git ≥ 2.23):

git switch -c feature/signup

switch is a modern, more readable alternative to checkout.
-c means “create a new branch.”

Classic way (still valid):

git checkout -b feature/signup

Tip: Use meaningful, kebab-case names with prefixes like: feature/signup, bugfix/fix-login, hotfix/crash-on-submit, release/v1.3.0

2. Do Some Work: Commit & Push

Example:

echo "Sign-up logic" > signup.js
git add signup.js
git commit -m "Add sign-up logic"
git push -u origin feature/signup

-u sets the upstream branch so future git push and git pull work without arguments.

After this, you can simply use git push and git pull without specifying branch names.

3. See What Branch You're In

git branch

The current branch is marked with a *.

To create a branch without switching:

git branch feature/experiment

Quick jump back to the previous branch:

git switch -

Super handy when jumping between main and a feature branch.

4. Switch Back to main and Update It

git switch main
git pull --ff-only origin main

Important:

Run this from the main branch.
If you have local commits, Git will stop politely — preventing accidental overwrites.

5. Merge Your Branch into main

Standard merge:

git merge feature/signup

If main hasn't changed since you branched off, Git performs a fast-forward — just moves the pointer.

Want to preserve a visible merge commit?

git merge --no-ff feature/signup

Great for tracking feature branches in project history or pull requests.

6. Handling Merge Conflicts

If Git reports a conflict:

Open the file and look for:

<<<<<<< HEAD
code from main
=======
code from your branch
>>>>>>> feature/signup

Manually fix the file.
Stage the resolved file:
```
git add filename
```
If a real merge happened (not fast-forward), finish with:
```
git commit
```

If it was fast-forward, Git already did everything — no commit needed.

7. Delete the Branch

Locally:

git branch -d feature/signup

If the branch hasn't been merged yet, use:

git branch -D feature/signup

Remotely:

git push origin --delete feature/signup

An alternative is:

git push origin :feature/signup

—but it's less readable.

8. View Branch History Visually

git log --oneline --graph --decorate --all

This shows your full commit tree, across all branches — clean and visual.

Merge vs Rebase: When and Why

merge preserves full history and creates a merge commit.
rebase rewrites your branch history to make it look like you started from the latest main.

To rebase:

git fetch origin
git rebase origin/main

Only rebase private branches.

If someone else has pulled your branch — do not rebase unless the team agrees.

If you must force-push after a rebase, never use --force directly. Use:

git push --force-with-lease

✅ This makes Git check that nobody has pushed since your last pull — safer for teams.

Suggested Team Workflow

Start a feature branch from main:
```
git switch -c feature/add-login
```
Work, commit, push:
```
git push -u origin feature/add-login
```
Open a pull request on GitHub/GitLab for review and CI checks.
Once approved, merge it — ideally with --no-ff.
Delete the branch locally and on the remote.
Keep main clean and always production-ready.

Working with Remotes

Task	Command
Push and set upstream	`git push -u origin feature/branch`
Pull updates with rebase	`git pull --rebase origin main`
Delete branch on remote	`git push origin --delete feature/branch`
Clean up remote branch refs	`git fetch --prune` or `git remote prune origin`
Safe force-push after rebase	`git push --force-with-lease`

Make pruning automatic:

git config --global fetch.prune true

Make rebase your default pull strategy:

git config --global pull.rebase true

Or do it manually per pull:

git pull --rebase

Keeps your history linear and avoids noisy merge commits.

Command Cheat Sheet

Action	Command
Create + switch to new branch	`git switch -c feature/branch`
Switch branches	`git switch branch-name`
Create branch without switching	`git branch branch-name`
See all branches	`git branch`
Jump to previous branch	`git switch -`
Update main before merge	`git switch main && git pull --ff-only origin main`
Merge branch	`git merge feature/branch`
Merge with visible history	`git merge --no-ff feature/branch`
Rebase feature onto latest main	`git rebase origin/main`
Delete local branch	`git branch -d branch-name` or `-D`
Delete remote branch	`git push origin --delete branch-name`
Visualize all history	`git log --oneline --graph --decorate --all`
Safe force-push after rebase	`git push --force-with-lease`
Clean deleted remotes automatically	`git config --global fetch.prune true`
Use rebase by default on pull	`git config --global pull.rebase true`

Best Practices (And Why They Matter)

One branch per task
Keeps changes isolated, focused, and easy to review.
Use clear, consistent naming
Prefixes like feature/, fix/, release/ help.
Use lowercase + hyphens: feature/add-login.
Use pull requests
Code reviews, CI checks, and visibility improve code quality.
Avoid --force — use --force-with-lease
Don't overwrite others' work by mistake.
Clean up your branches
Remove them when they're done — both locally and on remote.
Only rebase private branches
Never rewrite history others rely on.

Final Thoughts

Git branches aren't just a tool — they're a mindset.

They give you a safe space to build, break, and experiment — without breaking production.

With branches, you can:

isolate ideas,
collaborate without chaos,
and build with confidence.

Branch = creativity
Main = stability
You = the developer who keeps both in harmony.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Docker MCP - How GPT Agents Now Use Slack, GitHub, Stripe & More

2025-06-09T00:00:00.000Z

Today, I want to tell you how models like GPT and Claude went from just talking — to actually acting.

You can think of it as them getting hands. And by “hands,” I mean agents — helper programs that let the model trigger real-world tools.

For example:

send a message in Slack,
check a payment in Stripe,
or open a pull request on GitHub.

No magic needed — just MCP, an open standard called the Model Context Protocol.

It gives language models a consistent, secure way to interact with external tools — from APIs to databases to cloud services.

import VideoPlayer from "@components/VideoPlayer.astro";

The Challenge: Why This Was Hard

But getting to this point wasn't easy.

So let's talk about what made this hard in the first place, how it works today — and how Docker helps keep the whole setup clean, isolated, and easy to deploy.

You see, AI has always been a great advisor. It can write code, help find bugs, or even craft a poem if you're feeling down.

But the moment you asked it something simple, like:

“Hey, can you post in Slack that the task is done?”

It would just look at you and say:

“Uh… I'd love to, but I'm just a language model. I can talk — but I can't do.”

And yeah — it makes sense. It's smart. It just couldn't act on its own.

The brain was there — logic, knowledge, and clear reasoning.

But actually taking action? That wasn't part of the job description.

Enter Agents (a.k.a. Hands for Models)

To close that gap, developers started giving models a way to act — by connecting them to small helper services called agents.

In the world of MCP, these are known as MCP servers. And the app that connects the model to those servers? That's called the host.

How It Works — Step by Step

The model says what it wants to do — like “Send this message to Slack.”
The host takes that request and passes it to the right MCP server.
The MCP server performs the action — sends the message, makes the API call, whatever.
The host takes the result and gives it back to the model, so it can finish its reply.

Simple: The brain thinks, the hands act — and MCP is a cable that connects them.

The Catch: Why It Was a Headache

For a long time, setting this up was… painful.

I mean, it sounded great on paper. But in real life? Total hacker quest.

You had to spin up MCP servers manually.
Each agent had its own messy stack — Python, Node, Chromium — conflict city.
API keys? Sitting in raw JSON. Easy to use, terrifying to manage.
And if you wanted two or three agents? Brace yourself.

You just wanted to check a Stripe payment — and suddenly, you're deep in DIY DevOps.

And That's Where Docker Comes In

It made launching MCP agents simple, consistent, and reliable.

So imagine this: your AI finally gets hands — but you don't want those hands poking around your system.

It's like Docker gives those hands gloves — clean, contained, and safe.

The model gets the freedom to act, but the boundaries stay in place.

Each agent runs in its own container
It only sees what you allow
No mess in your system
No library conflicts
And no “whoops, I just deleted my desktop”

So What's Changed?

Now, Docker comes with the MCP Toolkit — and with it, an official catalog of over 100 ready-to-go agents.

You open Docker Desktop, go to the MCP Toolkit tab — and they're right there, ready for action.

You can browse the full Docker MCP Toolkit and explore MCP Servers on Docker Hub — over 100 officially supported tools ready to launch in seconds.

What Happens When You Use an Agent?

You pick an agent image — let's say GitHub
Docker spins up a container
The agent starts listening for commands from the model

That's it. No console gymnastics required.

Solving the Duplicated Agent Problem

Back in the day, if you ran multiple apps — like Claude, VS Code, whatever — none of them knew the agent was already running. So each one spun up its own copy.

That meant things got...messy:

Two containers doing the same job
Two access tokens
Two network connections
And a whole bunch of wasted resources

It was clunky. Risky. And just unnecessary.

Now? One agent. One container.

Multiple clients can connect to it — no duplication, no conflicts, no extra overhead.

But Is It Safe?

Yes — and here's why.

Agents run inside isolated Docker containers. Each container gives you a clean, controlled environment.

The agent only sees what you explicitly share — folders, environment variables, network access. Docker handles the isolation by default. It puts a strong boundary around your agent, keeping your system safe from mistakes, bugs, or even compromised tools.

Still, as with any software, it's smart to check what it's doing under the hood.

Stick to well-maintained agents, follow best practices, and you're in good shape.

And sure — like with any powerful tool, you can override that.

If you add --privileged, or mount the Docker socket, you're disabling that boundary. But stick with the defaults — and Docker takes care of the hard parts for you.

Who Is This For?

If you're already using GPT, Claude, or Copilot — and want them to actually do stuff, not just write about it
If you're in DevOps — and tired of scripting the same tools over and over
If you're a product person — and want AI wired into Jira, GitHub, Stripe, or whatever — in 10 minutes flat

What You Actually Get

An agent up and running in just a couple of minutes
Built-in isolation and safety
And if you want to scale up? Just add more agents.

It's that simple.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Kubernetes on Your Laptop — No Cloud, No Boring Docs, Just Magic

2025-05-29T00:00:00.000Z

Hey there, tech goddess (or just someone who's allergic to boring docs )

You've probably heard of Kubernetes, but every tutorial starts with “cluster,” “orchestration,” and “in the cloud”?

No thanks.

But what if I told you that you could launch your own website in Kubernetes, right on your laptop, set up environment variables, pass in secrets — step by step, no AWS, no tears, no PhD required?

Docker, Minikube, kubectl, Pod, Deployment, ConfigMap, Secret — all of it. I'll walk you through everything.

You just open VS Code, copy a few commands — and boom: a real cluster,spinning, working, and doing your bidding like a true DevOps enchantress. Enough theory — let's do some hands-on magic.

No AWS, no signups, no credit cards — just you, your laptop, and your curiosity.

Step 1 — Installing Docker (and figuring out why you even need it)

Scene 1: "What even is Docker?"

Imagine you're trying to run an app. It works perfectly for your friend on Windows, but not for you on a Mac. She's on Windows, you're on a Mac. It needs a bunch of libraries you don't have.

The fix? A container — a self-contained package that already includes everything the app needs.

A container = a suitcase with code, tools, and everything else bundled in.

Docker is the program that runs those suitcases — right on your machine.

Scene 2: "Download and install Docker"

Do this:

Go to https://www.docker.com/products/docker-desktop
Choose Docker Desktop for macOS (or your OS).
Download the installer.
Install like any other app: drag the Docker icon into your Applications folder.

Once it's installed — launch Docker Desktop (via Spotlight or Launchpad).

Quick check: is Docker working?

Open Terminal (Cmd + Space, type “Terminal”).

Run this command:

bash docker --version

You should see something like:

Docker version 24.0.2, build abc123

That means Docker is installed!

Next, run:

docker ps

If Docker is running, you'll see an empty table, like:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

That's totally fine — it just means no containers are running yet.

If Docker doesn't start or docker ps throws an error:

What's happening	Try this
`docker ps` doesn't work	Make sure Docker Desktop is running — look for the icon in your top menu bar
Command not found	Restart your Terminal or reboot your machine
Docker launched, but nothing's happening	The first launch can take a couple of minutes — be patient
It's asking for permissions	Check if macOS is waiting for you to approve something — a pop-up might be hiding behind other windows

Why does this matter?

We'll be launching our Kubernetes cluster using Minikube, and Minikube runs containers under the hood.

No Docker = no cluster = no “Hello, Pod.”

✅ TL;DR — You're ready to move on if:

You installed Docker Desktop
docker --version works
docker ps shows an empty table (and no errors)

If all that's good — let's install Kubernetes (via Minikube)!

Step 2 — Installing Minikube & kubectl (and launching your first cluster!)

Scene 1: “What are Minikube and kubectl?”

Minikube is like a mini version of Kubernetes you can run right on your laptop.

That means: no server, no cloud, no AWS, no mystical cluster setup — Minikube spins it all up locally.

kubectl (say “cube control” or “kube cuddle”) is your remote control for that cluster.

You'll use kubectl to create pods, check logs, update apps — basically, run the show.

Scene 2: Install kubectl and Minikube

If you're on a Mac:

Open Terminal and run these one by one:

brew install kubectl

Then:

brew install minikube

‍♀️ Take a moment, let Homebrew do its magic.

Scene 3: Start the cluster

Once it's installed, fire up your mini-cluster:

minikube start --driver=docker

What's happening here:

Kubernetes is starting inside Docker (which you set up in Step 1).
Minikube creates a “virtual machine” running your cluster.

⏱ This may take 1-2 minutes, so... deep breath.

Check if everything's working

Run this command:

kubectl get nodes

You should see something like:

NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.29.0

If you see STATUS: Ready - congrats!

Your first cluster is up. You literally just spun up your own infrastructure.

:::note Minikube runs a single-node cluster - perfect for learning and testing, but not meant for production. And that's totally fine — we're here to get hands-on, not deploy Netflix. :::

If something goes wrong - don't panic!

Problem	What to check	Example
`kubectl` not recognized	Did the install finish cleanly? Try restarting your terminal.	—
`minikube` won't start	Is Docker Desktop running? Look for the icon.	—
`minikube start` just hangs	Try restarting Docker, rebooting, and make sure you've got at least 4 GB of free RAM	—
`kubectl get nodes` shows nothing	Check if the cluster is running	`minikube status`
Cluster not started	Just run it again	`minikube start`

Why did we do this?

Kubernetes is how you run and manage container-based apps.
Minikube lets you explore it without needing cloud servers.
kubectl is your command center.

Now you're ready to create pods, deployments, services - everything a true DevOps witch needs.

Step 3 — My First Pod: Running an App in Kubernetes

Scene 1: “What even is a Pod?”

In Kubernetes, everything revolves around Pods.

Think of a Pod as a little room with one (or more) containers inside that:

share network and storage
start together
live and die together

A Pod usually runs just one container (like our nginx example) - but it can have multiple, like sidecars.

Scene 2: Create a YAML file for your Pod

Open VS Code or your favorite code editor. Create a new file and name it:

pod.yaml

✍️ Paste this inside:

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      ports:
        - containerPort: 80

✨ What's going on here:

apiVersion, kind, metadata — just Kubernetes boilerplate: "this is a Pod, name it like this".
Inside containers: you're saying: “Run a container using nginx:alpine and open port 80.”

Scene 3: Apply the file and launch the Pod

In your terminal, while inside the folder with the file:

kubectl apply -f pod.yaml

This tells Kubernetes: "Here's the definition — go make it real!"

Then check:

kubectl get pods

You should see something like:

NAME READY STATUS RESTARTS AGE
my-first-pod 1/1 Running 0 10s

✅ STATUS: Running means your Pod is alive and well!

Scene 4: Open your app in the browser

Now let's actually see nginx in action. Time to forward that port:

kubectl port-forward pod/my-first-pod 8080:80

What's this doing?

It tunnels port 80 from inside the container to your localhost:8080.
Meaning: whatever nginx serves, you can see in your browser.

Scene 5: Check if it's working

Pop open your browser and go to:

http://localhost:8080

If you see the default nginx page — boom, success!

If it didn't work — deep breath, let's fix it

Problem	What to try	Command
Browser says “site can't be reached”	Make sure the terminal with `port-forward` is still open	—
`kubectl port-forward` hangs or fails	Cancel it (`Ctrl + C`) and try again	`kubectl port-forward pod/my-first-pod 8080:80`
Port 8080 is already in use	Try a different port	`kubectl port-forward pod/my-first-pod 8081:80` and go to `localhost:8081`
nginx didn't start in the Pod	Check the logs	`kubectl logs my-first-pod`

So far, you've:

✅ Started your cluster
✅ Created your very first Pod
✅ Launched nginx
✅ Accessed it through the browser

This was your first real app running in Kubernetes — and that's a huge milestone

Step 4 — Deployment: So Your Pods Don't Break (And If They Do — They Auto-Heal)

Scene 1: “What is a Deployment, anyway?”

In the last step, you manually created a Pod. But here's the problem:

If it crashes — nobody restarts it
You want two Pods for reliability
You want Kubernetes to watch over them automatically

Enter the Deployment. It:

✅ creates Pods
✅ scales them (1, 2, 10, 100 — whatever)
✅ restarts them if they crash
✅ makes it easy to update images

Basically — a Pod manager that keeps your app alive and thriving.

Scene 2: Create the Deployment YAML

Create a new file called:

deployment.yaml

✍️ Paste this in:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80

What's happening here:

replicas: 2 — we're saying “Give me 2 identical Pods”
selector.matchLabels + template.metadata.labels — this connects the Deployment to the Pods via app: nginx
containers — same as before: launch nginx

Scene 3: Apply the Deployment

Open your terminal and run this:

kubectl apply -f deployment.yaml

You're telling Kubernetes: "Here's the blueprint — build it."

Now check that it worked:

kubectl get deployments

You should see something like:

NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 2/2 2 2 10s

✅ Which means: 2 Pods are up and running.

Now check the actual Pods:

kubectl get pods

You should see two Pods with similar names, like:

nginx-deployment-xxx-yyy 1/1 Running
nginx-deployment-aaa-bbb 1/1 Running

Scene 4: Let's test the auto-recovery

** Tiny experiment: delete one of the Pods**

kubectl delete pod

A few seconds later:

kubectl get pods

You'll see 2 Pods again.

Because the Deployment noticed one was gone — and created a new one automatically!

If the Deployment doesn't launch or Pods don't appear

Problem	What to check	Example Command
`kubectl apply -f deployment.yaml` does nothing	Make sure the file is named correctly and you're in the right folder	`ls`
`kubectl get deployments` shows nothing	Could be a YAML error (indentation, missing keys)	Run `kubectl apply -f deployment.yaml` again to see the error
Pods crash (`STATUS: CrashLoopBackOff`)	Something is breaking inside the container — check the logs	`kubectl logs`
Don't know the Pod name	Just list all Pods	`kubectl get pods`
`error: unable to recognize`	Your YAML might be broken — check the format	Use YAML Linter

Pro tip: You can always list Pods with:

kubectl get pods

Why this matters

Now you've got:

Two Pods = more reliability
Self-healing containers
Easy updates in the future

You just leveled up from “one test container” to a real Kubernetes-managed application.

Step 5 — Service: How to Open a Pod in the Browser (Without Magic)

Scene 1: “What is a Service?”

You already launched 2 nginx Pods — but right now, they're hiding behind a wall.

‍♀️ Without a Service, you can't just open them in the browser. Because:

Pods have internal IPs
They're not accessible from “outside”
If a Pod restarts, its IP might change

A Service is like a stable front door to your app.

It knows where your Pods are and routes traffic to them.

Even if a Pod dies, restarts, or moves — the Service still leads to the right place.

Scene 2: Create `service.yaml`

Create a new file and name it:

service.yaml

✍️ Paste this in:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

What this does:

type: NodePort — tells Kubernetes: “Expose this to the outside world via a port”
selector: app: nginx — the Service will forward traffic to Pods with that label
port — the port the Service listens on (inside the cluster)
targetPort — where to send traffic inside the Pod (nginx listens on port 80)
nodePort — the external port you'll use in your browser

Scene 3: Apply the Service

In your terminal:

kubectl apply -f service.yaml

Boom — your Service is live!

Now run this:

minikube service nginx-service

That command will automatically open your site in the browser — no need to worry about ports, IPs, or voodoo.

Didn't open? You can do it manually:

minikube ip

You'll get an IP, like 192.168.49.2

Now go to:

http://192.168.49.2:30080

✅ You should see the nginx welcome page!

What did we just do?

You created a Service to route traffic to your Pods
Used NodePort to make it accessible from outside
Opened a real website running inside Kubernetes — without port-forward

You're now officially at the “my app runs in K8s and opens in a browser” level —

aka your very first Kubernetes web app prototype!

Step 6 — ConfigMap: Passing Variables Into a Container (No Rebuilding Needed)

Scene 1: “Why do we even need ConfigMap?”

Let's say you've got a website. And now you want to:

show a different welcome message
tweak the behavior without rebuilding the image
keep settings separate from your code

ConfigMap is how you pass variables into your Pods.

Think of it like: “Here's a YAML with your config — grab it when you start up.”

Scene 2: Create the ConfigMap

Create a file called:

configmap.yaml

✍️ Paste this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  WELCOME_MSG: "Hello from ConfigMap!"

✨ What's going on here:

data: is just a key-value map
WELCOME_MSG is an example string (but it could be a URL, a mode, a path — anything)

Scene 3: Update your deployment.yaml

Open your deployment.yaml and inside the container block, add this under spec.containers[0]:

env:
  - name: WELCOME_MSG
    valueFrom:
      configMapKeyRef:
        name: nginx-config
        key: WELCOME_MSG

This tells Kubernetes: “When launching the container, pass it this environment variable from the ConfigMap.”

Scene 4: Apply it all

In your terminal, run:

kubectl apply -f configmap.yaml
kubectl apply -f deployment.yaml

This updates both the ConfigMap and the Deployment so everything is hooked up.

Scene 5: Check if the variable is inside the container

First, get the name of one of the Pods:

kubectl get pods

Copy a name (like nginx-deployment-xxx-yyy) and jump inside:

kubectl exec -it nginx-deployment-xxx-yyy -- /bin/sh

Now run:

echo $WELCOME_MSG

✅ You should see:

Hello from ConfigMap!

It worked! The variable made it all the way into your container from Kubernetes.

If the variable didn't show up

Problem	Check this	Example command
`echo $WELCOME_MSG` shows nothing	Make sure you saved changes and re-applied `deployment.yaml`	`kubectl apply -f deployment.yaml`
It looks right but still no variable	The Pod may not have restarted — delete it manually and let Deployment recreate it	`kubectl delete pod`
Can't get into the Pod	Double-check the Pod name	`kubectl get pods`
`kubectl exec` doesn't work	Pod may have crashed — check status or logs	`kubectl get pods`, `kubectl logs`

Pro tip: For the new config to appear, the Pod usually has to be recreated.

kubectl apply updates the Deployment, but won't restart running Pods.

What did you just do?

Created a config variable in Kubernetes
Passed it into a Pod via Deployment
Saw the variable live inside your container

This is key when your app needs to be flexible — change config without rebuilding the Docker image.

Step 7 — Secret: Safely Passing Passwords and Tokens into a Pod

Scene 1: “ConfigMap vs Secret — what's the difference?”

ConfigMap — for regular settings: modes, messages, URLs.

Secret — for anything you don't want exposed to the world:

passwords
access tokens
API keys

❗ Heads up: Secret values are automatically base64-encoded.

That's not encryption — just a way to hide them from curious eyes.

Scene 2: Create a secret file

Create a new file:

secret.yaml

✍️ Paste this:

apiVersion: v1
kind: Secret
metadata:
  name: nginx-secret
type: Opaque
data:
  SECRET_MSG: SGVsbG8sIGZyb20gU2VjcmV0IQ==

✨ What's going on:

type: Opaque — standard type of Secret
data: — key-value pairs (in base64)

Example:

echo -n "Hello, from Secret!" | base64

Which gives you: SGVsbG8sIGZyb20gU2VjcmV0IQ==

Scene 3: Link the Secret to your container

Open your deployment.yaml.

Inside containers > env, add:

- name: SECRET_MSG
  valueFrom:
    secretKeyRef:
      name: nginx-secret
      key: SECRET_MSG

Works exactly like ConfigMap — just a different data source: a Secret.

Scene 4: Apply the changes

In your terminal:

kubectl apply -f secret.yaml
kubectl apply -f deployment.yaml

Kubernetes will update the Secret and roll out the changes.

Scene 5: Check the container

First, get your Pod's name:

kubectl get pods

Then hop inside one:

kubectl exec -it  -- /bin/sh

Now check the variable:

echo $SECRET_MSG

✅ You should see:

Hello, from Secret!

That means your Secret was passed into the container successfully!

If the Secret variable didn't show up

Problem	Check this	Example command
`echo $SECRET_MSG` shows nothing	Make sure you saved and re-applied `deployment.yaml`	`kubectl apply -f deployment.yaml`
Secret wasn't created	Verify it's actually there	`kubectl get secrets`
Pod didn't restart	Delete it manually — Deployment will recreate it	`kubectl delete pod`
base64 was wrong	Make sure you encoded without newline	`echo -n "Hello"
Can't enter the Pod	Double-check the Pod name	`kubectl get pods`

Pro tip: If the variable doesn't show up after apply, manually deleting the Pod usually helps.

Why does this matter?

Secret is the standard way to safely pass sensitive data into your app — no hardcoding, no YAML leaks.

You just:

created a Kubernetes Secret
passed it into a container
verified it from the inside

Magic. Secure magic.

⏸️ Now pause for a second.

Do you realize what you've just done?

You installed a cluster. Deployed an app. Passed it configs and secrets — the full DevOps starter pack.

No clouds. No five tabs of Stack Overflow. No fear of hitting Enter.

Let's wrap it all up in a beautiful summary:

Final Recap — What You Did and Why It Matters

Step	What You Did	Why It Matters
1	Installed Docker	Runs containers — the foundation for Kubernetes
2	Installed Minikube and kubectl	Local cluster and control tool
3	Created a Pod	Ran your first app in Kubernetes
4	Set up a Deployment	Manages and scales Pods automatically
5	Added a Service	Made your app accessible from the browser
6	Connected a ConfigMap	Passed env vars without rebuilding the image
7	Connected a Secret	Securely passed passwords and sensitive data

✨ You just built a mini-infrastructure on your own laptop.

This isn't just “hello world” — it's hello Kubernetes.

So, what's next? Two paths:

Want to take a break and return later?

Stop the cluster:

minikube stop

Optionally quit Docker Desktop:

Click the icon in the top bar → Quit Docker Desktop

That's like hitting "pause."

Nothing will be deleted — everything stays just as it is.

When you want to come back:

Start Docker Desktop
Then run:

minikube start

And boom — your Pods, Services, Configs, Secrets... all back in action.

Not planning to return?

If you want to fully clean up everything we built:

minikube delete

This removes the cluster, all Pods, configs, and secrets — clean slate.

You can leave Docker installed — you'll probably use it again (a lot).

Even if you never touch Kubernetes again — know this:

You started it. You understood it. You owned it. That's already a huge step into the DevOps world.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

10 Docker Interview Questions & Answers for DevOps & Cloud Engineers

2025-05-26T00:00:00.000Z

If you're preparing for a Cloud Engineer or DevOps Engineer interview in 2025, Docker is non-negotiable — it comes up every single time.

Today, we're going through 10 Docker questions you're very likely to face — and how to answer them clearly and confidently.

import VideoPlayer from "@components/VideoPlayer.astro";

Before We Dive In: What Is Docker?

Docker is a platform that lets you run applications in isolated environments called containers.

These containers can run consistently across different environments — your laptop, a test server, production — without running into problems that only appear outside your local setup.

In real-world projects and DevOps roles, Docker is almost everywhere — for app development, testing, CI/CD pipelines, and cloud deployments.

Question 1: What's the difference between an image and a container? And what happens if you delete the image?

A Docker image is like a frozen recipe for your application — it includes everything needed to run it: code, libraries, environment settings.

A container is what you get when Docker takes that image and actually runs it — like turning the recipe into a real, running dish.

The image is read-only and reusable; the container has its own writable layer and lives as an isolated process. If you delete the image but the container is already running, it keeps working — because the image is already loaded into memory.

But if you stop that container and try to restart it, Docker won't find the image — and the restart will fail.

Pro Tip:

Tag your images properly (my-app:latest, my-app:v1.2) and regularly prune unused ones — but avoid deleting images used by running containers.

Question 2: What actually happens when you run docker run?

When I run docker run, Docker first checks if the image exists locally.

If not — it pulls it from a registry like Docker Hub. Then it creates a container — which is basically an isolated process with its own filesystem, networking, and resources.

Docker sets up isolation using Linux namespaces and cgroups.

Finally, it executes the default command defined in the image.

Example:

Running docker run nginx pulls the nginx image (if it's not local), creates a container, and starts the Nginx server inside that isolated environment.

Pro Tip:

Use --rm with docker run to automatically clean up the container after it exits — so your system doesn't get cluttered with stopped containers.

Question 3: COPY vs ADD — what's the difference, and when would you use each?

Both COPY and ADD move files into a Docker image.

COPY simply copies files and folders — no surprises.
ADD does more: it can unpack compressed files like .tar.gz and download files from URLs.

Because ADD has extra behavior that's not always obvious, I prefer COPY for clarity and only use ADD when I specifically need those extra features.

Example:

# Preferred
COPY ./app /app

# Only if needed (auto-extracts)
ADD archive.tar.gz /app/

Pro Tip:

Simplicity is security — prefer COPY unless you have a very good reason.

Question 4: What's a multi-stage build, and when would you use it?

A multi-stage build is when you use multiple FROM statements in your Dockerfile.

The first stage does heavy work — installing dependencies, building code.
The final stage copies only the necessary artifacts into a clean, minimal base image.

This reduces image size and eliminates unnecessary files and tools from production images.

Example:

# Stage 1 — build
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2 — production
FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./
CMD ["node", "dist/index.js"]

Pro Tip:

Smaller images = faster deployments + fewer vulnerabilities.

Question 5: CMD vs ENTRYPOINT — how do they work together?

ENTRYPOINT defines what runs — the main executable.

CMD gives it default arguments.

When you use docker run, the arguments you pass override CMD — but not ENTRYPOINT.

Together, they give you a flexible default setup that you can still tweak at runtime.

Example:

FROM nginx:1.28.0-alpine-slim

ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]

Pro Tip:

Want full control at runtime? Use only CMD — and leave out ENTRYPOINT.

Question 6: Volumes vs Bind Mounts — which would you use in production, and why?

In production, I prefer Docker-managed volumes. Volumes are isolated from the host OS, easier to back up, and more stable over time.

Bind mounts depend on host paths — which makes them fragile and environment-specific. Bind mounts are great for local development, not for production.

Example:

services:
  db:
    image: postgres
    volumes:
      - pg-data:/var/lib/postgresql/data

volumes:
  pg-data:

Pro Tip:

Volumes are portable, reliable, and more future-proof across hosts and clusters.

Question 7: How does networking between containers work?

By default, Docker connects containers to a bridge network, where they get private IP addresses.

However, they can only reach each other by IP unless you create a user-defined bridge network.

In a user-defined bridge network, containers can communicate by name, which simplifies service discovery.

Example:

services:
  app:
    image: my-app
    environment:
      DB_HOST: db
      DB_USER: appuser
      DB_PASSWORD: secret
    networks:
      - app-net

  db:
    image: postgres
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: secret
    networks:
      - app-net

networks:
  app-net:

Pro Tip:

Always use user-defined networks — the default bridge network doesn't support automatic name-based discovery and can lead to frustrating connection issues.

Question 8: How do you reduce Docker image size, and why should you care?

Reducing image size speeds up builds, deployments, and improves security.

I start with a minimal base image — like alpine:3.21.3, python:3.12-slim-bookworm, or node:20.13.1-alpine.
I combine RUN instructions to reduce layers, and clean up any temp files or caches.
I always use a .dockerignore file to exclude things like .git, node_modules, and test data.

And for complex builds, I use multi-stage builds to separate build tools from the final runtime.

Example:

A Node.js app image can shrink from 1.2 GB to under 200 MB by switching to node:20.13.1-alpine and cleaning up properly.

Pro Tip:

Smaller images = faster pipelines, quicker deploys, and fewer security issues.

Question 9: What is BuildKit, and why use it?

BuildKit is Docker's modern build engine that significantly improves performance, security, and flexibility.

It enables parallel execution of independent build steps, advanced caching mechanisms, and secure handling of secrets during builds. BuildKit also supports features like multi-platform builds and efficient storage management.

In modern Docker versions, BuildKit is enabled by default — so you don't need to configure anything. But if you're on an older setup, you can still enable it by setting DOCKER_BUILDKIT=1 or updating the Docker daemon config.

Example:

With BuildKit, multi-stage builds can run steps in parallel, reducing build times significantly.

Pro Tip:

Always leverage BuildKit for faster, more secure, and efficient Docker builds.

Question 10: How do you handle sensitive data (like secrets) in Docker?

I never hardcode secrets into Dockerfiles or images.

For local runs, I pass secrets as environment variables — either inline or via a .env file. If I use a .env file, I make sure to add it to .dockerignore — so it doesn't accidentally get copied into the image.

In production, I use secret management tools — like HashiCorp Vault, AWS Secrets Manager, or Kubernetes Secrets — to inject secrets at runtime.

Secrets should always come from outside the image, not baked inside

Example:

Pass database passwords using environment variables in staging, and HashiCorp Vault in production.

Pro Tip:

Good secret management = safer deployments and easier key rotations.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Helm in Kubernetes - What It Is and Why You Need It

2025-05-20T00:00:00.000Z

Hey, tech queens!

Today we're talking about Helm — my go-to tool for working with Kubernetes. If you've ever suffered through manually crafting YAML files for every single service, you're about to breathe a huge sigh of relief.

I used to drown in those manifests and think, “Is it always going to be this painful?” Nope. Because Helm exists.

Helm in Plain English

Imagine you buy a dresser from IKEA. Instead of guessing where each screw goes, you grab the instructions and have it assembled in 20 minutes - latte in hand.

Helm is that same kind of instruction manual - for Kubernetes.

Normally, deploying an app means creating a bunch of objects: Pods, Services, Ingresses, ConfigMaps — each with its own YAML file. It's tedious.

Helm saves you:

Bundles everything into one structure: a chart
Spins up apps with a single command
Simplifies upgrades, customization, and rollbacks
Makes deployments predictable and repeatable

What's a Helm Chart (and Why It's Not Scary)

The word “chart” might sound intimidating, but it's really just a folder with organized files. No magic, just structure.

Think of it as your deployment organizer:

Chart.yaml — the chart's business card: name, version, description
values.yaml — default settings (ports, replicas, DB names, etc.)
templates/ — YAML blueprints Helm renders into actual Kubernetes objects
_helpers.tpl — reusable functions to keep templates DRY
charts/ — dependencies like databases or message queues

Why It's Handy

A chart is like a capsule — it holds everything: instructions, configs, and dependencies.

Same chart, different environments:

Dev: myblog-dev, 1 replica, test DB
Prod: myblog, 3 replicas, production DB

Just tweak values.yaml — no need to touch anything else.

It's like one dress styled with different accessories.

Why Helm Is My Must-Have

Reasons I love Helm:

Scalability: no more 30+ YAML files
Flexibility: same chart, different setups
Transparency: preview what's actually going to be installed (helm template)
Security: Helm 3 removed Tiller (and that's a good thing)
Control: rollbacks are built-in (helm rollback is magic)

Helm 2 vs Helm 3 — Short & Sweet

Helm 2 relied on a separate component called Tiller, which had elevated cluster privileges — a big security headache.

Helm 3 fixed it:

No Tiller
Uses your existing kubectl credentials
Easier to install and great for CI/CD

What's Next? Helm v4 Is in the Works

Helm v4 is currently in planning (see HIP-0012) — with focus on a new API and architectural improvements.

No official release date yet — the devs meet weekly and are actively shaping the roadmap.

Installing Helm — Fast & Painless

You'll Need:

A Kubernetes cluster (Minikube, GKE, etc.)
kubectl installed

Most Universal Way

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Always use the official script from GitHub. Trust but verify.

Alternatives

macOS:

brew install helm

Homebrew now provides the latest release — v3.18.0

Linux (Snap):

sudo snap install helm --classic

Snap can sometimes lag behind — prefer the install script for CI.

Debian / Ubuntu (APT):

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | \
sudo tee /usr/share/keyrings/helm.gpg > /dev/null

echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | \
sudo tee /etc/apt/sources.list.d/helm-stable-debian.list

sudo apt-get update
sudo apt-get install helm

Verify the Install

helm version

Sample output:

version.BuildInfo{Version:"v3.18.0", GitCommit:"...", GoVersion:"go1.22.2", ...}

As of May 20, 2025, this is the latest stable release.

v3.18.1 is expected on June 11, and v3.19.0 is coming in September.

First Helm Run — Let's Go!

Install something fun — like Nginx:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install nginx bitnami/nginx

Customize settings:

helm install my-app ./my-chart \
 --set image.tag=2.0.1 --set replicaCount=3

Or use a YAML config:

helm install my-app ./my-chart -f values-prod.yaml

Something went wrong?

helm rollback my-app 1

Uninstall it:

helm uninstall my-app

Security & Best Practices

Always Inspect a Chart Before Installing

Think of it like trying on a dress before the party - just because it looks cute doesn't mean it fits.

helm lint — checks the structure and versioning of the chart
helm template — renders the final YAML (preview before install)
helm test — runs built-in tests (if defined)
helm diff — compares installed vs new version

Install the diff plugin:

helm plugin install https://github.com/databus23/helm-diff

Sign and Verify Your Charts

Use helm package --sign to digitally sign your charts
Run helm verify to confirm integrity
For advanced signing, try Cosign + the helm-sigstore plugin

Store Charts Like Images (OCI FTW)

Helm now supports pushing/pulling from OCI registries:

helm push mychart.tgz oci://registry.example.com/charts
helm pull oci://registry.example.com/charts/mychart --version 1.2.3

If you're using older tools like ChartMuseum, clarify that separately.

Mind Your Versions

Watch for version skew between Helm and Kubernetes
Don't upgrade Helm right before a production deploy — stability first!

Takeaway

Helm is my DevOps bestie. It brings:

Organization
Repeatable configuration
And a lot less Kubernetes chaos

If you're working with Kubernetes, get familiar with Helm.

It 100% deserves a spot in your toolkit.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Your First Git Commit - A Beginner-Friendly Guide to Version Control

2025-05-12T00:00:00.000Z

Hey, tech queens! ‍✨

If you've ever seen the word Git and thought:

“Okay, this sounds important… but also kind of intimidating?”

You're not alone.

But here's the good news: Git isn't scary — it's an essential tool that'll make your coding life much easier.

Let's walk through your first Git setup and commit, step by step — no jargon, no stress.

What Is Git, Really?

Think of your code like a project notebook. You want to:

save versions as you go,
undo mistakes,
and maybe work on it with other people — without chaos.

Git is the version control system that makes all of that possible.

It helps you:

snapshot your work at any time,
roll back if something breaks,
and collaborate smoothly with others.

Installing Git (No Stress, Just Steps)

On macOS

Open Terminal and run:

brew install git

:::note Homebrew must be installed beforehand. :::

If your Mac prompts you to install Xcode Command Line Tools, accept it — that's normal.

On Windows

Simplest method: download Git from git-scm.com. It includes Git Bash, which gives you a helpful command-line interface.

Prefer using the terminal?

winget install --id Git.Git

(Works on Windows 10 1809+ and Windows 11.)

On Linux

For Debian/Ubuntu:

sudo apt-get install git

For Fedora:

sudo dnf install git

For Arch-based systems:

sudo pacman -S git

Check the Installation

Make sure Git is installed with:

git --version

If you see a version number, you're all set.

Configure Git (Just Once)

Git tags your work with your name and email so you can track who made which changes — even if it's just you.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Set main as the default branch name (instead of the older master):

git config --global init.defaultBranch main

Optional: avoid using Vim by default (it can be confusing for beginners). Use something simpler like nano:

git config --global core.editor "nano"

Prefer VS Code? Use:

git config --global core.editor "code --wait"

Creating Your First Repository

Create a new folder for your project and initialize Git inside it:

mkdir my-first-repo && cd my-first-repo
git init

You now have a Git repository — a versioned folder ready to track changes.

Add a File and Make Your First Commit

Let's create a basic file:

echo "Hello, Git!" > README.md

:::note File names like README.md and readme.md are treated the same on macOS and Windows, but they're different on Linux — case matters. :::

Check Git's status:

git status

It will show the new file but mark it as untracked.

Tell Git to track it:

git add README.md

Now make your first commit:

git commit -m "Add README"

Done — your first snapshot is saved in Git history!

Bonus: Use `.gitignore` to Keep Things Clean

You might have folders or files you don't want to track — like node_modules, log files, or build output.

Create a .gitignore file:

echo "node_modules/" > .gitignore

Want help generating one for your tech stack? Check out gitignore.io.

Optional (But Handy) - Windows Line Ending Fix

If you're on Windows and see warnings like “LF will be replaced by CRLF,” run:

git config --global core.autocrlf true

This helps avoid annoying line ending issues between systems.

Make Things Faster with Aliases

Tired of typing full commands? Set up aliases:

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch

Now you can use git st instead of git status. Shortcuts = efficiency.

Prefer GUIs Over Command Line?

If the terminal isn't your thing (yet), try a visual interface:

GitHub Desktop — beginner-friendly and intuitive
Sourcetree — more advanced but still beginner-usable

You can always switch to the terminal when you feel ready.

Quick Cheat Sheet

Command	Description
`git init`	Creates a Git repo
`git status`	Shows changes and file states
`git add`	Stages files for commit
`git commit -m ""`	Saves a snapshot with a message
`git config`	Sets global Git settings (name, editor, etc.)

You Did It

You installed Git, configured it, created a repo, and made your first commit.

That's a big step in your dev journey — version control is a core skill for any developer.

Now you've got the tools and confidence to take control of your projects.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Best CI/CD Tool in 2025? GitHub Actions vs GitLab CI vs Argo Workflows

2025-05-11T00:00:00.000Z

If you're working with CI/CD, cloud platforms, or just trying to make your pipelines less messy, you're in the right place. Because today we're talking about a question many teams face:

Which CI/CD tool actually makes sense in 2025?

Not in theory — in real life.

They're all good. But which one fits your team?

Let's break it down together.

import VideoPlayer from "@components/VideoPlayer.astro";

First, let's set the stage

CI/CD isn't just “run tests and deploy” anymore.

Now it's about:

security,
rollbacks,
environments,
infrastructure as code,
and observability.

Pipelines aren't just scripts anymore — they're part of your system's core.

And the tool you choose shapes how your team builds, ships, and fixes things every day.

GitHub Actions

It's built right into GitHub.

Add a .yml file, grab a few Marketplace actions, and you've got a working pipeline.

For small projects? It works great:

frontend apps
Docker builds
deployments to S3, ECS, or Lambda

It's fast, simple, and easy to get started with.

It's great… until things start to grow and get a bit more complicated.

As the project grows:

you add more steps
jobs trigger other jobs
secrets start piling up
and debugging turns into trial and error

Suddenly, things feel fragile — like one small change might break everything.

That's usually the moment teams start looking for something more stable — like GitLab CI.

GitLab CI

GitLab CI isn't flashy, but it's solid.

Everything lives in one file — .gitlab-ci.yml. You define jobs, stages, environments, approvals — all in one place.

It gives you:

consistency
built-in security checks
preview environments
full visibility from commit to production

Once it's set up, it stays out of your way and just works.

It's great for teams that ship often and need predictability more than bells and whistles.

Argo Workflows

But what if you need more than predictability?

What if your pipeline isn't just for deployments but part of the product itself?

That's where Argo Workflows comes in.

Argo isn't just a CI/CD tool — it's a full-on pipeline engine for Kubernetes.

You define workflows as DAGs — Directed Acyclic Graphs. Each step runs as its own pod. Dependencies are clear. Everything is observable.

It's great for:

ML training
ETL pipelines
staged microservice deploys
or anything that reacts to events

Argo gives you full control and visibility — right inside the cluster.

But let's be honest: it's not beginner-friendly.

You'll need:

Helm
RBAC
persistent storage
ingress setup
and a team that can manage the whole thing

Argo isn't something you “just try.”

It's for teams that treat pipelines as real infrastructure — because that's what they are.

They All Have Their Place

And that's true for all of them — GitHub Actions, GitLab CI, Argo. They all have their place.

So — how do all these tools actually hold up when it's not just a side project, but real production work?

Let's compare real-world usage — the good and the painful.

GitHub Actions:

Great for small, fast-moving projects
If you've got fewer than 10 jobs, it's smooth
But beyond that? It can get messy fast
Debugging turns into guesswork

GitLab CI:

Works well for teams with structure
Supports approvals, environments, and solid release flows
It's quiet, reliable, and gets out of your way
Which is exactly what you want at scale

Argo Workflows:

This is for when delivery is the product
When pipelines aren't just support tools, but essential parts of your platform
It's complex, but if your team's ready — it's incredibly powerful

The Real Test: When Something Breaks

Not in a demo. Not on a sunny-day deploy.

When it's Friday at 4 PM, someone just merged to main…

You've closed your laptop, grabbed your bag — And then Slack pings: “deployment failed.”

That's when your CI/CD setup shows its true colors.

Choose What Fits Your Team

So yeah, the tools you pick do matter.

We've looked at the trade-offs, the patterns, and the pain points.

Now it's your turn to decide what fits your team — and your reality.

What's going to keep your pipelines healthy and your Fridays peaceful?

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

What Actually Runs the Internet? A No-Stress Guide to Containers & Kubernetes

2025-05-05T00:00:00.000Z

Hey, brilliant tech minds (and future ones too)! ‍✨

You've probably heard words like Docker, Kubernetes, or ContainerD flying around in tech convos (or LinkedIn posts you scroll past ). But what actually are they? And do you really need to know?

Short answer: YES — especially if you want to sound like that girl in tech and truly understand what makes apps like Netflix, Zoom, and Spotify tick. Let's break it down — no jargon, just good vibes and relatable examples. ‍♀️✨

Imagine You're Baking Cookies

Stay with me — this actually makes sense.

You've got the perfect cookie recipe. It's so good that you want people all over the world to bake the exact same cookies. But what if someone forgets sugar? Or uses the wrong oven temp?

So, genius you packs everything into a cute little cookie kit: ingredients, step-by-step instructions, even the timer. Now, anyone, anywhere, can make the same perfect batch.

That's what containers are in the tech world. They're like little kits that package everything an app needs — the code, the tools, the settings — so it runs exactly the same no matter where it is: on your laptop, in the cloud, wherever.

Meet Docker — the Container Queen

Docker is the tool that makes those little cookie kits (a.k.a. containers). It helps devs bundle up apps so they can run anywhere, easily.

Think of Docker as your fave meal-prep delivery service. It makes the packing and shipping of apps smooth and fast. One command — boom — your app is packaged, ready to ship.

But wait — what happens when you have a lot of containers to manage? Like, dozens of them? That's where it gets spicy…

Kubernetes: Your App's Event Planner

Kubernetes is like the logistics queen who makes sure everything runs perfectly — containers launching at the right time, recovering when they crash, scaling when there's more demand.

Here's what Kubernetes does:

Keeps your app running if something breaks
Spins up more containers when things get busy
Updates stuff behind the scenes without breaking the app
Basically? It's the ultimate control freak — in a good way

Think: a super-organized girlboss project manager who never misses a beat. ‍

And Then There's ContainerD — the Quiet One

ContainerD might sound like the awkward cousin at the tech party — but don't underestimate it.

Back in the day, Docker did everything — packaging, running, managing. But that got messy. So smart tech folks decided to split things up.

ContainerD is now the lightweight tool that handles just one job: running containers. No drama, no distractions.

And here's the tea: Kubernetes now uses ContainerD directly instead of Docker.
(Because Docker isn't just a runtime — it's a full suite of tools. Kubernetes only needs the “engine” part to do its job.)

Psst — if you ever hear the word CRI floating around, here's the scoop:
CRI (Container Runtime Interface) is just how Kubernetes talks to runtimes like ContainerD. That's it. Nothing scary.

TL;DR? Docker's still fab for development, but in the big leagues (like production apps), Kubernetes + ContainerD = power duo.

So Why Should You Even Care?

Even if you're not writing code, understanding how modern apps run is like knowing how your iPhone or Wi-Fi works. It's just part of being tech-savvy in 2025.

Let's recap:

Containers = app-in-a-box
Docker = the packer/delivery girl
Kubernetes = the event planner/project manager
ContainerD = the lowkey engine that runs the whole show

This is the invisible magic behind your fave platforms. And now? You're officially smarter than 90% of the internet. ✨

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

How Generative AI Actually Understands You

2025-04-28T00:00:00.000Z

Hey, lovely tech queens! ‍✨

You've probably seen AI writing blog posts, drawing epic art, narrating stories, and even making short films.

But how does it actually know what you're asking for?

Spoiler: it's not magic — just smart logic, broken into pieces. Like digital LEGO bricks.

Let me break it down for you — simple, fun, and drama-free.

1. What Are Tokens?

Words, but chopped into snackable bites

AI doesn't “read” like you and me. It breaks everything you type into little pieces called tokens. That could be:

a full word (“coffee”)
part of a word (“pro” + “duct”)
or even a symbol (“!”)

Example:

You type: “Make me a text about cats”

The AI sees: [“Make”, “me”, “a”, “text”, “about”, “cat”, “s”]

Why? Because tokens are easy to turn into numbers. And numbers = AI's love language.

2. What's Chunking?

Think: "Don't overwhelm the poor bot"

Even the biggest models have a token limit.

So when your input is long — AI breaks it into chunks.

Like slicing a pizza: same flavor, easier to handle.

3. What Are Embeddings?

Turning words into vibes (aka numbers)

AI doesn't “know” that pizza is tasty. But it turns every token into a set of numbers — called an embedding — that shows what the word means and how it connects to others.

Example:

“pizza”, “cheese” and “pepperoni” will have similar embeddings.
“pizza” and “printer”? Not so much.

It's like every word has a location on a map — and similar vibes live near each other.

But wait — what about images and videos?!

Oh girl, this is where it gets spicy. Let me show you:

4. How AI Creates Images

Tools like DALL·E, Midjourney and Stable Diffusion can turn words into gorgeous visuals.

You type:

“A cat wearing a hoodie drinking latte on a Tokyo rooftop”

Here's what happens:

The prompt turns into tokens
Tokens → embeddings
AI pulls what it knows about cats, hoodies, lattes & Tokyo
Then it generates a whole new image — pixel by pixel

It's not copying. It's imagining.

Like a creative bestie who's trained on billions of Pinterest boards.

5. How AI Makes Videos

Now it gets cinematic.

Models like Runway Gen-2 and Pika Labs are making full videos from just text prompts.

You type:

“A goldfish flying through space”

Boom — short movie.

Here's the magic:

It creates the first frame like a still image
Then builds more, one by one
Adds smooth transitions, motion, and vibe
Glues it all together as a video

Basically: AI = your personal animation studio.

6. How AI Understands Sound

With tools like ElevenLabs, Suno, or MusicLM, AI can:

Read your text out loud (like, perfectly)
Create music from a vibe
Analyze your voice for emotion or tone

Example:

You write: “Say it like you're a TED speaker hyping the crowd”

AI delivers with energy and sparkle.

Why Should You Even Care?

Because when you get how AI thinks, you:

Write 10x better prompts
Stop being scared of words like “token” and “embedding”
Use AI like a pro, not a guessing game
Can explain it to your boss, your bestie, or your future investor

Let's Wrap This Up:

AI doesn't read minds. But it does:

Break your words into tokens
Turn them into numbers (embeddings)
Use patterns it learned to predict what you want

And then — boom.

Text, image, video, sound — whatever your imagination served, it delivers.

AI isn't magic. But it is insanely good at pattern recognition.

And now that you speak its language, you're basically unstoppable.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

How AI Models Are Really Trained - From Idea to Reality

2025-04-20T00:00:00.000Z

Hey girls! And you, smart tech kings, too!

AI is everywhere — in your phone, your feed, your shopping cart. But how does it actually work behind the scenes?

Let's break it down:

How do AI models get built, trained, and sent out into the world?

It's not magic. It's not sci-fi. It's a step-by-step process — and I'm going to walk you through all of it, beginner-style.

1. Start With a Real Problem — Not “Let's Just Do AI”

Before any coding or fancy model building, there has to be a reason.

Companies don't build AI “just because.” They ask:

Can we reduce product returns?
Spot fake reviews faster?
Recommend better stuff to users?
Predict when a machine will break?

First step: Know exactly what you're solving.

If you skip this, the model might be cool — but totally useless.

2. Collect and Clean the Data (aka Your Model's Food)

Let's say you want to predict which customers might leave your app.

You'll need data like:

When they joined
How often they log in
What they clicked
If they stayed or left

But data doesn't come cute and clean. Ever.

So first, you clean it:

Remove typos, duplicates, and empty cells
Format everything consistently
Spot any weirdness (like someone logging in 300 times a day — um, bot?)

Think of this as skincare for your model:

If you skip the cleansing, nothing else will work right.

3. Split the Data: Train, Validate, Test

Now that your data's clean, don't toss it all into the model at once.

Split it into:

Training set: Where your model learns
Validation set: To check progress while it learns
Test set: To see if it actually works in real life

Imagine baking cookies:

Training = practicing the recipe
Validation = taste-testing as you go
Testing = sharing with friends to see if they love them (or not)

A common split is 80/10/10 — but it depends on your project.

4. Train the Model (Finally!)

Now the real fun begins — your model starts to “learn.”

But how?

Let's say you give it emails labeled “spam” or “not spam.”

The model:

Makes a guess
Checks the answer
Adjusts if it's wrong
Tries again

It repeats this thousands of times until it gets better at spotting patterns.

It's not memorizing — it's learning how to generalize.

Like, “If the subject line says FREE MONEY!!!... hmm, might be spam.”

5. Tune the Model — Like Tweaking a Recipe

Even after training, your model might need fine-tuning.

This is called hyperparameter tuning — sounds intimidating, but it's not.

Think of it like adjusting a cookie recipe:

Add more vanilla?
Bake longer?
Lower the oven temp?

In model terms:

Learning rate
Number of layers
Batch size

And guess what? Tools like Amazon SageMaker can tune this stuff automatically.

6. Evaluate the Model — Is It Actually Good?

Before launch, you have to test the model on data it hasn't seen before.

We use metrics like:

Accuracy: How often is it right?
Precision: When it says “yes,” is it correct?
Recall: Did it find all the real “yeses”?
F1 Score: A balance of precision and recall

Example:

If your model says “this customer will leave” —
Precision = how often it's right.
Recall = how many of the leaving customers it actually found.

7. Deploy the Model — Send It Into the World

Once your model is trained and tested, it's time to let it do its job!

There are two common ways to use it:

Real-time — for instant decisions (like chatbots or spam filters)
Batch — for scheduled jobs (like weekly reports or daily analysis)

You'll often use cloud tools to make this happen (like some from Amazon — SageMaker, for example).

Don't worry if these sound unfamiliar — you don't need to be an engineer to understand the process. Think of them as the behind-the-scenes crew helping your model go live.

8. Monitor and Update — Your Model Still Needs You

Just because it's deployed doesn't mean you're done.

The world changes. People change. So the model needs to adapt.

You (or your tools) will:

Track weird predictions
Notice when performance drops
Retrain the model with new data if needed

Think of it like skincare touch-ups — even the best routine needs updates.

Quick Recap — 8 Steps to Train a Model:

Step	What's Happening
1	Define a real business problem
2	Collect and clean the data
3	Split data into train / val / test
4	Train the model
5	Tune it (aka adjust the settings)
6	Test it with unseen data
7	Deploy it to do real work
8	Monitor and retrain when needed

Final Thoughts (From a Girl Who Gets It)

If you thought training a model meant pressing a button… now you know it's way more than that.

But also? It's totally doable.

When you break it into simple steps, everything starts to click.

Whether you want to build models, manage AI teams, or just sound confident when someone says “pipeline” — you've got this.

Stay curious. Keep learning.

And remember: great models run on clean data and smart decisions — just like you.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Is Kubernetes Overkill? Why You Probably Don't Need It

2025-04-19T00:00:00.000Z

Today, we're diving into a question that more and more teams are starting to ask:

Is Kubernetes overkill? And maybe more importantly, why do we keep spinning up clusters for things that don't actually need them?

Let's start with this:

Kubernetes is powerful. Many of us use it daily, and it solves real problems. But let's not pretend it's always the right solution.

Because sometimes? It adds more complexity than it removes.

So, let's talk honestly about when Kubernetes fits — and when it absolutely doesn't.

import VideoPlayer from "@components/VideoPlayer.astro";

When Kubernetes Is the Wrong Tool

We've all seen it:

Teams reaching for Kubernetes when it's the wrong tool for the job. That's like lighting a birthday candle with a flamethrower.

Here are a few real-world examples:

Example One: The Static Site

A simple marketing page — no backend, no database. Just HTML and maybe a bit of JavaScript. And yet… it's deployed in Kubernetes. With Ingress, autoscaling, Prometheus — the works. That's like renting a crane to hang a poster.

You don't need Kubernetes. Just throw it on Netlify or S3 — done. No cluster, no crying. They're fast, cheap, reliable — and require zero YAML therapy.

Example Two: The Monthly Monolith

One app. Updated once a month. No scaling, no rollout drama — it just runs. But somehow, there's a Helm chart, a cluster, and half a dozen manifests.

Why?

A basic VPC and docker run would've done the job. Fewer moving parts. No cluster to babysit.

Example Three: The Small Team with a Big Cluster

Two or three devs. No dedicated platform engineer. No one watching metrics. But there's a cluster anyway.

Pods crash, Argo's out of sync, PVCs break — and no one's watching. Nobody's sure if this is platform engineering or just chaos with better branding.

When Kubernetes Does Make Sense

To be fair, Kubernetes has its place.

When it fits, it's amazing. Let's look at a few scenarios where Kubernetes actually makes sense:

1. Complex Service Architectures

You're running multiple services — each with configs, secrets, health checks, and deploy flows.
You need orchestration, service discovery, and scheduling.

Kubernetes was built for this.

2. Dynamic Scaling and Resilience

You're dealing with traffic spikes.
You want self-healing.
You want the system to recover before you even notice something's wrong.

That's Kubernetes at its best.

3. Platform Engineering

You're not just deploying apps — you're building an internal platform.

With GitOps, Argo, Helm, policy-as-code — and a team that actually understands it all.

Here, Kubernetes gives you standardization, control, governance, and scale.

The Real Catch: Kubernetes Doesn't Fix Your Problems

It distributes them.

If you had no observability before, now your blind spots stretch across nodes.
If your CI/CD pipeline was fragile, now it's fragile and containerized.
If no one could debug a crash before, now it's hidden behind layers of abstraction.

Kubernetes is powerful. But it amplifies whatever's already in your system — good or bad.

Ask Yourself — Honestly:

Do you have a DevOps or platform team to maintain the cluster?
Are you running 5+ services that truly need orchestration?
Do you require auto-scaling, self-healing, and complex rollout strategies?
Are you confidently using tools like Helm, Argo CD, Prometheus — and using them well?
Can your team debug pod crashes, PVC issues, and weird networking glitches?

If the answer to most of those is “not really,” then maybe Kubernetes isn't your next step.

And that's totally okay.

There's No Shame in Choosing Simpler Tools

Especially when they work better.

We've got great alternatives:

Docker Compose + systemd
ECS Fargate
Cloud Run
Render
Heroku
A good old VPC instance and some solid CI/CD

Sometimes, the best tool isn't the most sophisticated — it's the one your team actually understands and can support long-term.

Let Me Be Real With You

Kubernetes is not a badge of honor. It's not a maturity checklist. It's just a complex, powerful tool, and it only makes sense when the problem truly calls for it.

If it helps, great. If it doesn't? Skip the cluster. Skip the chaos. Move forward with something that fits. Don't build a space shuttle when all you really need is… a bicycle.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

What Kind of Data Does AI Use

2025-04-14T00:00:00.000Z

Hey, you brilliant tech babes (and kings — I see you too )!

You already know how AI learns and where it shows up in real life. But there's one more thing you absolutely need to know to truly get AI:

It's all about the data, darling.
Like, literally. No data = no AI.

Let's break it down, step by step — from the types of data to why they matter, and what can go wrong if your data's a mess (spoiler: everything).

So grab your iced latte and let's talk dirty — data dirty.

Structured vs. Unstructured — What's the Tea?

Structured Data = Neat girl energy

Think spreadsheets, columns, drop-down menus. Basically, info that fits in tidy rows and is super easy to organize.

Real-life example:
Your online store tracks shoppers by name, age, and how much they spent last month.

Name: Emma
Age: 28
Purchase: $89.99
VIP status: Yes

Perfect for AI to eat up and analyze.
This kind of data is the go-to for supervised learning. It's simple, predictable, and super model-friendly.

Unstructured Data = Total chaos... but gold

This is all the messy stuff AI needs to decode:

Tweets
DMs
Selfies
Voice notes
TikToks
Review texts
Screenshots of what your friend sent you at 2am

This data is harder to process — but it's also where the juicy, human stuff lives.
With the right tools (like NLP or computer vision), AI can feel what people are saying, seeing, and reacting to.

The Data Types AI Actually Works With

Here's what shows up in real-world projects — broken down like a cute cheat sheet:

Data Type	Looks Like…	Example	What AI Does With It
Numerical	Numbers, prices, scores	5, 29.99, 90%	Normalize, scale, compare
Categorical	Labels, options, categories	"Beginner", "NY", "Tote bag"	Convert to machine-friendly codes
Text	Reviews, messages, bios	“Ugh, I loved it so much!”	Understand mood, topic, emotion
Image	Selfies, product pics, screenshots	Photo of a red dress	Detect shapes, colors, objects
Audio	Voice memos, customer calls	Voice note: “Sooo... mad or just tired?”	Turn into text or audio features
Video	Insta Reels, tutorials, dashcams	Makeup GRWM TikTok	Analyze image + sound together

⚙️ What Makes Data “Model-Ready”?

You don't just throw your raw data into an AI model and hope for the best — that's like showing up to a glam shoot with bed hair and mismatched socks.

Your data needs a serious prep routine:

Cleaning — remove duplicates, typos, missing stuff
Formatting — make sure prices are numbers, dates are dates, and text is readable
Labeling — if your model needs answers, you have to tell it what's what (e.g. “This is a cat. That's a croissant.”)
Balancing — avoid over-representing one side (like 90% apples and 10% oranges — we're not doing fruit bias today)

Why Bad Data = Bad AI

Let's be real: even the smartest AI won't save your butt if your data's a mess.
Here's what happens if you skip the prep:

Your model makes wrong predictions
It becomes biased (like recommending only men's products if it's seen mostly male data)
It just... breaks. And blames you silently.

Example:

Imagine you want your AI to recognize whether a voice note is angry or chill.
But most of your training data is people being excited.
Now when someone calmly says “I'm fine,” the model might think they're thrilled — or worse, lying.

That's not AI's fault. That's ✨data drama✨.

So... What Should You Know as a Beginner?

Even if you're not building models (yet), just knowing this gives you a major edge:

Data is the fuel AI runs on
Clean, balanced data = accurate, smart AI
Unstructured data is harder, but so much more real and emotional
You can totally start working with it — one TikTok caption or product review at a time

Final Thoughts from a Data-Loving IT Girl

People think AI is all about code and algorithms. But girl, no.
AI is 80% data, 20% logic — and 100% what you feed it.

So if you're learning AI, working in tech, or just curious about how Netflix knows you want to watch K-dramas at 2am... it all comes down to the data.

Clean it. Understand it. Respect it.

Because even your future AI model needs a solid skincare routine before it glows.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

DevSecOps Explained - Security for DevOps in 2025

2025-04-11T00:00:00.000Z

Today we're diving into something that sounds a bit technical at first, but is actually super practical: DevSecOps.

If you're in DevOps — or planning to get into it — security is not something you can afford to ignore anymore. And don't worry, this isn't going to be full of code or complex theory.

It's a straightforward explanation to help you think like a secure DevOps engineer in 2025. Let's get into it.

import VideoPlayer from "@components/VideoPlayer.astro";

What exactly is DevSecOps?

Well, DevSecOps simply means: security isn't something that comes in at the end — it's something that's part of the process from day one.

In the past, developers would write code, DevOps would deploy it, and only then would the security team show up and say, “Wait a second — is this safe?”

DevSecOps flips that around. It means we're thinking about security from the beginning. It's like buckling your seatbelt before the car starts moving — not after an accident happens.

And no, it doesn't mean you need to become a cybersecurity expert. But if you're touching infrastructure, automation, or CI/CD — then yes, security is part of your job.

Why is this especially important right now?

Because things are fast. Everything is automated. You're deploying through pipelines, spinning up cloud infrastructure in seconds, managing services across environments.

And attackers are adapting to that.

They're not just targeting websites anymore — they're going after your pipelines, your cloud configs, your secrets, your state files.

All it takes is one exposed API key, one public S3 bucket, or one bad permission — and your whole system is at risk.

Plus, with growing compliance demands, customer expectations, and the pressure to move quickly — we simply can't treat security like an afterthought anymore.

How do you actually start thinking like a DevSecOps engineer?

Let me walk you through a few simple — but powerful — things you can start doing right now.

No need to boil the ocean. Just start here:

1. Don't hardcode secrets.

I know it's tempting, but passwords, tokens, keys — they don't belong in your code. Ever.

Store them safely. Use something like Vault, AWS Secrets Manager, or even your CI/CD platform's built-in secrets.

Think about it like this — would you tape your house key to your front door? No? Then don't leave credentials in your Git repo either.

2. Treat your infrastructure as code like it's real code — because it is.

Terraform files, Kubernetes configs, Ansible playbooks — they can all introduce risks.

Use tools like tfsec, Checkov, or Snyk to scan for misconfigurations. They'll catch things you might miss.

3. Lock down your pipelines.

Your CI/CD has a ton of power. It can deploy apps, spin up servers, change production.

That's not something just anyone should have access to.

Keep it controlled.
Use approvals.
Don't give out admin access freely.

4. Be intentional with permissions.

Use the principle of least privilege.

Give people — and systems — only the access they actually need. Nothing more.

5. Don't forget observability.

Turn on logging.
Monitor who's doing what.
Set up alerts for strange behavior.

You can't respond to what you can't see.

Now let me be honest...

Some of the biggest security issues I've seen didn't come from complex hacks.
They came from simple, overlooked mistakes:

Leaving an S3 bucket open “just for testing” and forgetting to close it
Accidentally pushing secrets to a public Git repo
Letting the whole team share a single admin account
Storing sensitive Terraform state files locally, unencrypted
Skipping proper environments and pushing straight to production because staging was down

Each of these might seem small in the moment — but they can open the door to serious problems later.

If you're new to all this — where do you begin without feeling overwhelmed?

Here's a simple place to start:

✅ Move your secrets out of your codebase
✅ Store your Terraform state in a secure, remote backend with locking
✅ Add one security scanner to your workflow — just one is already progress
✅ Review infrastructure changes like you review application code
✅ Enable basic logging and alerting
✅ And start asking the question: “What could go wrong if this fails or leaks?”

That mindset shift is huge.

Security isn't about being paranoid — it's about being prepared.

To wrap this up:

DevSecOps isn't just a new tool or framework. It's a way of working. You're not just building systems that work — you're building systems that are resilient, secure, and ready to scale.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

How AI Learns — and Where It's Actually Used

2025-04-07T00:00:00.000Z

Hey, tech queens! And kings — don't act shy, I know you're here. ✨

If you've ever wondered how AI models “learn,” but everything you found online felt like it was written by a robot for robots — don't worry, I got you. Today, I'm breaking it down in the easiest, most human way possible.

We're talking how AI learns — and spoiler: it's not magic, just logic + data + the right type of training. There are three main ways machines learn, and honestly? They're kinda relatable.

So grab a matcha (or espresso, I don't judge) — let's go! ☕‍

1. Supervised Learning — Like AI School With a Teacher

This is the classic classroom situation.

Imagine you're showing someone photos of fruit and saying:

“This one's an apple. This one's an orange. Got it?”
Over time, they start recognizing apples and oranges on their own.

That's exactly how supervised learning works.
You give the AI a bunch of examples — with correct labels — and it learns the patterns.

** Example:**

You're building an app to recognize different types of bags (because, yes, I need AI to help me sort my closet).
You feed it photos labeled: tote, backpack, clutch.
Eventually, the model sees a new photo and goes, “Oh, that's a clutch.” Boom.

It learns from: examples with answers
Use cases: spam filters, price predictions, mood detection in texts
Vibe: “Tell me what's what, and I'll learn it.”

2. Unsupervised Learning — The “I'll Figure It Out Myself” Energy

This one's more like throwing someone into a room full of fruit and saying:

“Here's a bunch of stuff. Sort it however makes sense.”
No labels. No clues. Just vibes.

And somehow… they do it.

They group things by color, shape, size — whatever patterns they notice. AI does the same.

** Example:**

You've got hundreds of customers and zero info on who's who.
Your AI analyzes behavior — how often they buy, what they buy, when they shop — and groups them into categories. Now you know who's your VIP and who's just here for the flash sales.

It learns from: raw, unlabeled data
Use cases: customer segmentation, finding weird behavior (hello, fraud), organizing messy info
Vibe: “I'm independent and intuitive, thanks.”

3. Reinforcement Learning — Learn by Doing (and Failing)

Okay, so now imagine you're training your cat to stay off your laptop (been there).

If she stays on the floor — treat.

If she walks across your keyboard mid-Zoom call — no treat.

She figures it out eventually.

That's how reinforcement learning works: the AI tries, gets feedback, adjusts, and improves.

It's learning through experience — kind of like how we learn to not trust hotel Wi-Fi again.

** Example:**

Your robot vacuum bumps into your desk chair.
Ouch.
It backs up and tries another route. Over time, it learns the best paths for your space, and it becomes your little clean freak buddy.

It learns from: trial + error + rewards
Use cases: robots, game AI, delivery route optimization
Vibe: “Let me try, fail fabulously, and come back stronger.”

Quick Recap — Because We Love a Cute Table

Type of Learning	Learns From	Main Goal	Vibe
Supervised	Examples + right answers	Make accurate predictions	“Teach me & I'll deliver.”
Unsupervised	Just data	Find patterns or clusters	“Let me figure it out.”
Reinforcement	Actions + feedback	Learn best strategy	“Trial, error, glow-up.”

Final Thoughts From Your Favorite Tech Girl

AI doesn't have to be confusing. Once you understand the way it learns — girl, it clicks.

Honestly? It's not that different from how we learn:

Supervised: like school.
Unsupervised: like figuring out a new city without a map.
Reinforcement: like finally learning not to text your ex — the hard way.

So next time you hear someone mention machine learning, you'll be like: “Oh, supervised? Cute. Classic.”

And now that you've got the learning part down… let's see where AI is slaying in real life.

Where is AI actually used?

And I don't mean some future-sci-fi-robot-world. I mean right here, right now — in things you already use, buy, click on, and even wear.

Let's take this out of the textbook and into the real world, shall we?

1. Healthcare — Dr. AI Is In

AI doesn't replace doctors, but it does help them. Think of it like a super-focused assistant who never blinks.

It can analyze medical images, compare test results across thousands of cases, and spot signs of issues faster than the human eye.

No, it's not diagnosing your cold — but it might help flag early signs of something serious before you even feel it.

Girl-coded example:

You get a chest scan. The AI says, “Hey, this tiny area right here? That's worth a closer look.”
The doctor reviews it, confirms it, and you just got a life-saving second opinion. Yas.

2. Retail — AI Is Your (Low-Key) Shopping BFF

Ever wonder how your fave online store knows you're obsessed with oversized hoodies and anything beige?

Yeah, that's AI.

It tracks what you click, what you buy, what you almost buy, and builds a vibe profile. Then it recommends stuff you're actually into — not just random glitter crop tops (unless that's your thing).

Bonus:

AI helps brands manage stock too. So if data shows it's iced coffee season and everyone's about to panic-buy reusable cups — AI tells them to order extra before shelves go empty.

3. Manufacturing — AI as Quality Control Queen

Forget waiting for something to break. AI now predicts when machines will break — before they do. It catches tiny signs of wear, monitors equipment in real time, and keeps things smooth and efficient.

In other words:

Instead of “Oops, the machine died,” it's “Heads up, this part might fail in 3 days — wanna fix it now?”
We love a proactive moment.

4. Transportation — Not Just Self-Driving Cars

Self-driving cars get the spotlight, but AI is everywhere in transportation now.

From traffic light systems that reduce wait times, to delivery apps that find the fastest route even when your street's under construction (again), AI's behind the wheel.

Also:

AI can help plan bus routes, prevent train delays, and basically stop your “I'll be there in 10” from turning into 30.

5. Farming — Yes, Farming Got Smart Too

Think AI is only for techy city things? Nope.

Farmers are using AI to figure out the best time to plant crops, how much water each field needs, and when to harvest for the best yield.

With drones, sensors, and data analysis, AI can literally say:
“Hey, that row of strawberries looks a little off — might be a pest problem.”

It's like your skincare routine, but for plants.

6. Warehousing & Logistics — Organized Girl Energy

Ever wonder how your next-day delivery actually happens? AI.

It helps warehouses know where every item is, routes packages in real time, and adjusts on the fly if anything goes wrong.

(And yes, it probably helped choose your delivery slot too.)

Fun fact:
Some warehouses are almost entirely AI-driven. Like, your leggings got packed by a robot. Wild.

7. Customer Service — Not Your Basic Chatbot

Gone are the days of boring bots that reply with “I didn't get that.”

Today's AI-powered assistants can actually understand your messy, typo-filled question and offer legit solutions. At 3am. Without attitude.

Real example:

You message a beauty brand: “Hey my order is late and I think I put the wrong zip code??”
The AI checks your order, fixes your address, and updates delivery — without making you wait 47 minutes on hold. Iconic.

So… Should You Use AI?

Let's break it down:

Ask yourself…	If yes, AI might help
Do you have data?	✅
Do patterns repeat in that data?	✅
Would you love to automate tasks?	✅

If you nodded three times, guess what?
AI is not too much for you. You're ready.

Final Final Thoughts — Now You Really Get It

You don't need to code a neural network from scratch to understand AI. You just need to know:

How it learns
Where it works
What it needs to succeed

And now? You do.

From fashion to farming, playlists to packages — AI is behind so many things we use every day.

It's not science fiction. It's the quiet genius in the background. And you, babe, are officially in the know.

Let's keep learning, building, and leading the smart-girl revolution.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

10 Terraform Interview Questions You Must Know in 2025

2025-04-01T00:00:00.000Z

If you're preparing for a Cloud Engineer or DevOps Engineer interview in 2025, you must know Terraform—it's one of the most in-demand tools for managing cloud infrastructure.

Today, we're covering 10 must-know Terraform interview questions to help you land your next DevOps job! Stay tuned for expert tips and real-world examples. Let's jump in!

import VideoPlayer from "@components/VideoPlayer.astro";

Question 1: What is Terraform and why should you care?

So, Terraform is a free tool made by HashiCorp. It lets you manage your cloud infrastructure — like servers, databases, networks — using code instead of clicking around in a user interface like the AWS console.

Basically, you write some config files, and Terraform builds all your resources for you.

Why it's useful:

First, you don't have to do things manually anymore.
Second, your environments — dev, test, prod — stay consistent.
And finally, it works with multiple cloud providers like AWS, Azure, and Google Cloud Platform.

Example: Need 5 EC2 instances in AWS? Instead of setting them up one by one, you write a script in Terraform — and it will set everything up for you in one go.

Pro Tip: If someone asks how Terraform is different from tools like Ansible or CloudFormation, here's a simple way to explain it: Terraform describes the end goal — what you want things to look like — while Ansible is more about the step-by-step process to get there.

Question 2: What are the main parts of Terraform?

Let's break it down. There are three main pieces you should know:

First, Providers — they connect Terraform to cloud platforms like AWS, Azure, GCP, and so on.
Then we have Modules — these are chunks of reusable code that help you avoid repeating yourself.
And lastly, there's State — this is a file that keeps track of what Terraform has already created.

Example: If you're creating a server on AWS, the provider tells Terraform, "Hey, we're using AWS," and then you can use a module to automatically handle networking, storage, and so on.

Question 3: What is Terraform State and why is it important?

Terraform State is just a file that remembers everything Terraform has built.

Here's why it matters:

First, it helps by keeping track of what already exists in your infrastructure.
Second, it figures out the relationships — or dependencies — between different resources.
And third, it allows your whole team to collaborate effectively — particularly when the state file is stored remotely, which is key for team-based setups.

But here's something a lot of people get wrong: saving state on your laptop. If something happens to your computer, you could lose all your Terraform tracking.

Pro Tip: Store state in S3 and use DynamoDB for locking, or just go with Terraform Cloud to make life easier. And if someone mentions “state locking,” it's basically just a way to stop multiple people from making changes at the same time.

Question 4: What's the difference between Terraform Plan and Apply?

It's simple:

terraform plan shows you what changes Terraform is going to make.
terraform apply actually makes those changes.

Example: Let's say you change an EC2 instance type from t2.micro to t3.micro. terraform plan will say, “Hey, this is the difference,” and terraform apply will go ahead and make it happen.

Pro Tip: Before you apply any changes, it's a good idea to run terraform plan and save the output to a file. This way, you can double-check what's about to happen and avoid surprises.

Question 5: How does Terraform handle dependencies?

Terraform usually understands dependencies on its own, just by looking at how your resources are connected.

But if you really need to, you can use depends_on to say, “Hey, make sure this thing is done first.”

Example: You're creating an EC2 instance that needs a VPC. Terraform will automatically know to create the VPC first.

Pro Tip: Try not to rely too much on depends_on. Terraform is smart and can usually handle this without extra help.

Question 6: What is Terraform Drift and how do you find it?

Drift is when something in your cloud setup changes outside of Terraform — like if someone makes a manual change in the AWS Console — and now your code doesn't line up with what's actually running.

To spot that kind of difference, you can run terraform plan. It'll show you if anything has changed that Terraform didn't expect.

Pro Tip: If you want to keep everything organized and up to date, you can set up automatic drift checks in Terraform Cloud, or add a simple step to your automation setup to check for changes from time to time.

Question 7: How do you handle sensitive data in Terraform?

Here's how to deal with secrets safely:

First, use variables and set sensitive = true.
Then, store secrets in something secure like AWS Secrets Manager or Vault.
And finally, make sure your remote state is encrypted.

And seriously — never put passwords directly in your code or state files.

Question 8: What are Terraform Workspaces?

Workspaces let you use the same Terraform config for different environments — like dev, staging, and prod.

You can run commands like:

terraform workspace new dev
terraform workspace select dev

Pro Tip: Workspaces are fine for small projects, but for bigger systems, using separate state files is usually better.

Question 9: What are Terraform Modules and why use them?

Modules are just reusable bits of code that make your Terraform setup easier to manage.

Here's why they're helpful:

First of all, they help you avoid repeating the same code in every project.
They also keep your files nice and organized.
And finally, they help make sure your infrastructure stays consistent everywhere.

Example: You can create a module for a VPC and use it in multiple places instead of writing that code over and over.

Pro Tip: Before writing your own module, check out the Terraform Registry. Someone else may have already built what you need.

Question 10: How do you use Terraform in an automated deployment process?

You can plug Terraform into your CI/CD setup using tools like:

GitHub Actions
GitLab CI
Terraform Cloud

Here's a basic workflow:

First, run terraform fmt and terraform validate to check formatting and syntax.
Then, use terraform plan to preview the changes.
And finally, use terraform apply only after someone gives the green light (especially in production).

Pro Tip: Some teams also use Open Policy Agent to apply security rules before changes are applied.

Alright, that's it for today! These 10 Terraform questions should give you a solid foundation for your next DevOps interview.

Thanks for reading! Be sure to watch the video version for extra insights and helpful visuals.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

AI for Beginners - How It Works, Learns, and Makes Decisions

2025-03-31T00:00:00.000Z

Hey, lovely tech queens! ‍✨

Let's be real: tech terms like AI, machine learning, and deep learning get thrown around constantly — and unless you've spent your nights reading research papers (I haven't either), they can sound like a black box.

But they're not.
Let me break them down for you — clearly, simply, and with real-life examples (yes, including oranges and smart thermostats).

Part 1: What is AI — and why does everyone talk about it?

AI stands for Artificial Intelligence, and no, it's not about robots with feelings. It's about teaching machines to do things that usually require human intelligence:
like understanding language, recognizing images, predicting outcomes, or making decisions.

AI helps us in everyday life more than you might think:

Your phone suggests the next word before you finish typing.
Your bank detects suspicious activity before you even notice.
Your email knows how to separate spam from real messages.

It's not magic. It's just data, models, and logic — working together.

Part 2: How AI learns — and what ML and Deep Learning have to do with it.

To make a machine smart, you don't give it instructions line by line. You let it learn from examples — and that's what Machine Learning (ML) is.

Then there's Deep Learning, a more advanced method that helps machines handle complex tasks — like recognizing speech, analyzing images, or understanding natural language.

Want a clear example?

Let's say you live in a smart home with a smart thermostat.

The thermostat uses AI to decide whether to heat the room.
It uses ML to learn that you usually come home around 7 p.m., so it starts warming up at 6:30.
It uses Deep Learning to go even further: it checks your location, your calendar, even the way you message friends — and figures out that today you'll be home early. So it heats the room in advance, without you doing a thing.

That's how it works. Step by step, smarter and smarter.

Part 3: What happens after learning — the role of inference.

Once the model is trained, the learning phase is over. Now it's time to use that knowledge.

This process is called inference — when the AI makes a decision based on what it already knows.

Here's a simple one:

You trained a model to tell the difference between oranges and apples.
Now you show it a new fruit photo.
It looks at it and says: “That's an orange.”
That's inference. It's the model in action — making predictions or classifications based on what it learned earlier.

Part 4: Two types of inference — real-time vs batch.

Not all AI decisions are made the same way. Sometimes you need answers instantly. Sometimes you need to process a lot of data quietly in the background.

Let's break it down:

1. Real-time inference

This is when the AI reacts immediately to new input.

Examples:

A smart fridge notifies you that milk is low the second you open the door.
A navigation app recalculates your route as soon as you take the wrong turn.
An e-commerce site recommends similar items the moment you click on a product.

Speed matters here. The response has to be fast and seamless.

2. Batch inference

This happens when the system processes large amounts of data at once, usually on a schedule.

Examples:

Your sales data is analyzed overnight to generate a report by morning.
A bank reviews all transactions at the end of the day to assess risk levels.
A job platform scans thousands of resumes every weekend to find top matches.

This type of inference doesn't need to be instant — it's more about depth and scale.

When to use what? Here's the cheat sheet:

You need	Use this type
Instant feedback or decision-making	Real-time inference
Large-scale analysis without time pressure	Batch inference

A note from one IT girl to another

AI isn't some futuristic fantasy — it's already here, quietly making things smoother, smarter, and faster.
You don't need to know everything about algorithms to understand how it works.

If you get this:

AI = the system that acts smart,
ML = how the system learns from data,
Deep Learning = how it handles complex patterns,
Inference = how it applies what it learned to make decisions,

Then congrats — you're already ahead of most people.

Keep learning, stay curious, and don't be afraid of the tech terms.
You're more than smart enough to master this.

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Docker Run, Swarm & Kubernetes - Scaling Made Simple

2025-03-25T00:00:00.000Z

Hey, tech queens! ‍✨

Let's Talk About Scaling — Docker Run, Swarm & Kubernetes Explained Simply

Okay girls — you've nailed docker run, spun up your first container, and you're feeling like a total tech queen.

But then… your app gets popular (yas!), you need more power, and suddenly it's like:

“Wait… how do I run multiple containers? On multiple servers? Without chaos?”

Don't worry — you're about to level up your container game. Let's talk Docker Swarm vs Kubernetes, what they do, and how they help you scale with style.

Docker Run: Your First Crush

You type:

docker run my-app

Boom — your container is alive, running, and you feel unstoppable.

But here's the thing:

It only launches one container
If it crashes, you have to fix it yourself
Scaling? Load balancing? Not happening

It's great for learning and testing. But when you want to go big? Time to bring in reinforcements.

Docker Swarm: Your First Automation Sidekick

Swarm is Docker's built-in orchestration tool — your first step into scaling smart.

With one command, you can launch multiple containers across different servers, and Swarm handles the rest.

docker service create --name my-app --replicas 3 my-image

Swarm will:

Distribute containers across machines
Restart them if they crash
Balance traffic between them

Basically: You focus on building, Swarm keeps it all running.

Why I love it:

Easy to use
No extra tools needed
Perfect for small projects or learning orchestration

Kubernetes: The Boss of Container Management

If Swarm is your sidekick, Kubernetes (K8s) is the full-blown operations manager. She's powerful, reliable, and trusted by companies like Google, Netflix, and Spotify.

Kubernetes can:

Auto-scale your apps based on resource usage
Roll out updates with zero downtime
Heal itself when something breaks
Run across clouds and data centers

With just:

kubectl create deployment my-app --image=my-image

You've deployed an app that can scale to the moon — and heal itself along the way.

Kubernetes doesn't just run containers — it runs your platform.

Swarm vs Kubernetes — What's the Difference?

Feature	Docker Swarm	Kubernetes
Setup	Simple & fast	Advanced, more setup
Scaling	Basic replicas	Full auto-scaling
Healing	Restarts containers	Smart health checks + recovery
Best For	Learning & light apps	Serious production systems
Vibes	Chill side project	Cloud-native powerhouse

DevOps Pink Girl Tips

Start with Docker + Swarm to get the basics down
Move to Kubernetes when you're ready for pro-level control
Use Minikube to run Kubernetes locally
Learn kubectl commands like get pods, describe, and apply — they're gold
Don't panic — it all makes sense with practice!

Final Thoughts: You've Got This

Whether you're running a simple app or managing cloud infrastructure like a queen, orchestration is your next big step.

Docker Run is where we all start.

Swarm helps us grow.

Kubernetes? That's where the real magic happens.

You're not just launching containers — you're building systems, scaling apps, and creating serious DevOps vibes.

So go flex those tech muscles if you're stepping into Swarm or K8s life. I'm always here for your container wins!

Got a favorite kubectl command or Swarm tip? Share it in the comments — let's geek out together!

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

How Docker Works Under the Hood - A Girly Tech Deep Dive

2025-03-21T00:00:00.000Z

Hey, tech queens (and kings, if you're here too)! ‍✨

Today, we're diving under the hood of Docker to see what actually happens when we run those magical docker run commands. If you're anything like me—curious, IT-obsessed, and always wanting to know how stuff actually works—then you're in for a treat!

So, What Even Is Docker?

Let's be real—Docker makes life so much easier. Instead of installing a million dependencies, worrying about “it works on my machine” drama (ugh, been there!), we just throw everything into a container and let Docker do its thing.

But what's actually happening behind the scenes? Let's break it down!

Docker Is Not a Virtual Machine (And That's Important!)

Okay, first thing's first. If you think Docker is like VirtualBox or VMWare, girl, we need to talk! ‍♀️

Virtual Machines (VMs) create a whole new OS inside another OS. That means they're slow, require tons of resources, and basically act like a separate computer.

Docker, on the other hand, doesn't do that. Instead, it runs containers using the same OS kernel as your host machine. Think of it like running multiple apps on your phone—each one is separate, but they all share the same iOS or Android system.

Result: Docker containers start in seconds, use less memory, and are super lightweight compared to VMs.

What Happens When You Run `docker run`?

You type docker run nginx and boom—your container is up and running. But what actually happens behind the command? Here's the tea ☕:

1️⃣ Docker CLI talks to Docker Daemon

The CLI (Command-Line Interface) sends a request to the Docker Daemon (a background process that does all the hard work). Think of the daemon as Docker's fairy godmother ‍♀️—it grants your wish to run containers!

2️⃣ Docker Daemon checks for the image

If you don't have the Nginx image locally, Docker pulls it from Docker Hub (kind of like an app store for containers).

3️⃣ Docker creates a container

It sets up namespaces (more on that below!), allocates resources, and makes sure the container is isolated from your main system.

4️⃣ Docker starts the container's main process

Containers are just Linux processes running in an isolated environment. Unlike VMs, they don't boot a full OS—just the app you asked for.

5️⃣ You now have an active container!

Run docker ps and you'll see it in action!

How Docker Keeps Containers Separate

If containers share the same OS kernel, how do they stay isolated from each other? Here's where Linux namespaces and cgroups come in.

Namespaces = "You do you, I do me!"

Namespaces make sure each container has its own private world—its own file system, network, process tree, and more.
This is why when you run ls inside a container, you don't see your host system's files!

Cgroups = "You get this much CPU, you get this much RAM!"

Containers share resources, but cgroups ensure that one greedy container doesn't hog all the CPU or memory.
It's like a Netflix account with multiple users—everyone gets their fair share!

Why This Matters (And Why You Should Care)

So now you know that Docker isn't magic (though it sure feels like it sometimes ✨). Understanding how Docker really works helps you debug issues, optimize performance, and use it like a pro.

‍ Next Steps:

Try running docker stats to see how much CPU/memory your containers use.
Experiment with docker inspect to peek inside a container's metadata.
Play with docker network ls to check out how containers communicate!

Final Thoughts

Docker is a total game-changer, but knowing how it actually works makes you unstoppable. Now go flex your new knowledge, container queen!

Tag me if you try any of these tips.

I'd love to hear about your Docker adventures!

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Docker Compose Explained - Imagine Running Your Own Cafe

2025-03-18T00:00:00.000Z

Hey, tech queens! ‍✨

If you've ever felt overwhelmed by all this Docker and containers talk, don't worry—I got you! Today, we're diving into Docker in a way that actually makes sense. No boring textbook definitions, just real-life vibes and practical IT girl wisdom.

So, picture this: you're the head chef of your dream restaurant. You've got different stations—baking, coffee-making, smoothie-blending. Your goal? Run a smooth, flawless kitchen where every dish comes out chef's kiss perfect. Now imagine opening the exact same restaurant in a different city—how do you make sure everything works the same way?

That's where Docker comes in. Let's break it down!

What Even is Docker?

Okay, so think of Docker as a way to pack up your kitchen stations into perfectly organized "to-go" boxes. Inside each box, there's everything needed to set up a working station—ingredients, tools, instructions, the whole vibe. When you send this box to another restaurant (aka another server), all they have to do is unbox it and BOOM—instant setup.

In IT terms:

Instead of manually installing software, databases, and dependencies on different servers, Docker packs them into containers that can run anywhere.
No more “It worked on my machine but not yours” drama—it runs the same way, every time.

Running a Single Container = Turning On One Kitchen Appliance

Let's say you just need to make coffee. Easy, right? You press a button, the coffee machine turns on, and magic happens.

In Docker, the equivalent is:

docker run coffee-maker

Translation? “Turn on my coffee machine container and start brewing.”

But here's the thing—no one orders JUST coffee. Customers want a full experience: pastries, fresh juice, and a cozy vibe. Running a single Docker container is fine for one task, but what about when you need a whole team of containers working together?

Docker Compose = Running Your Entire Kitchen Like a Boss

Imagine if your kitchen had zero coordination:

The barista starts making coffee but there's no milk.
The baker finishes a croissant, but there's nowhere to put it because the plates haven't arrived yet.
The smoothie blender starts running... but no one put fruit in it.

Total chaos, right? That's exactly what happens when you have multiple containers that don't know how to work together.

Enter Docker Compose, aka the kitchen manager of your IT dreams. Instead of manually turning on each appliance one by one, you write a simple file (compose.yml) that tells all the stations when and how to start working. Then, with one command, your entire system boots up, perfectly in sync:

docker compose up

Translation? "Wake up, kitchen! Let's do this!"

How Does Docker Compose Keep Your Kitchen in Order?

Imagine your restaurant serves a signature breakfast set:

A fresh croissant (baked in the oven )
A cappuccino (made in the espresso machine ☕)
A smoothie (blended to perfection )

Here's how Docker Compose makes sure everything runs smoothly:

1 It Starts the Right Appliances First

You can't make a cappuccino before heating the milk, right? Same in tech. Your databases must start before your app, otherwise, it crashes trying to find missing data.

In Docker Compose, we define dependencies, so containers know who needs to start first.

2 It Connects Everything Automatically

Your barista needs to talk to the baker to coordinate orders. Same with services in IT—your app needs to communicate with the database, payment system, and notification service.

Docker Compose links all containers together, so they can "chat" without extra setup.

3 It Scales Up When Needed

If your cafe gets super popular (hello, influencer magic ✨), you hire more baristas to handle orders. In Docker, if your website gets more traffic, you easily add more containers without breaking a sweat.

docker compose scale coffee=3

Boom. Three baristas, no waiting in line.

Why Should an IT Girl Care About Docker?

Let's be real: if you're serious about tech, Docker is a game-changer. Whether you're a developer, DevOps babe, or cloud queen, Docker saves time, reduces errors, and lets you focus on actual coding instead of fixing messy setups.

With Docker, you can:

✔ Run the same setup on ANY computer - no more “but it works on my laptop” drama. ✔ Test new features in seconds - spin up a new environment with one command. ✔ Easily switch between projects - each app gets its own contained world. ✔ Deploy apps like a pro - your code runs the same on any server, anywhere.

Final Thoughts: Own Your Tech Kitchen!

Docker might seem complicated at first, but trust me—it's just Tupperware for your code. Once you start thinking in containers, managing apps becomes as easy as running your favorite cafe.

IT Girl Tip: Want to practice? Start by containerizing something simple—like a personal website or a tiny database. Once you get the hang of it, scaling up will be a breeze!

So, next time someone talks about Docker, just imagine your dream cafe running smoothly with a single command—and know that you, my tech queen, are running the kitchen. ✨

Let's go build something amazing!

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

DNS for IT Girls - How the Internet Works Like Magic

2025-03-15T00:00:00.000Z

Hey, tech queens! ‍

Today, we're diving into DNS—the secret behind why you can just type google.com instead of some long, impossible-to-remember number. DNS makes the internet easy and user-friendly, and once you understand it, you'll feel like a total networking goddess!

What is DNS?

DNS (Domain Name System) is like the translator of the internet. It turns human-friendly domain names (web.yourcompany.net) into machine-readable IP addresses.

Think of it like your phone contacts: instead of memorizing phone numbers, you just tap on a name. DNS does the same, but for websites.

Without DNS, you'd have to type 10.0.0.25 instead of facebook.com. Not cute, right?

The Hosts File: The Old-School Hack

Before DNS, people manually assigned names to IPs using the /etc/hosts file (yeah, ancient times! ). But guess what? You can still use this trick today to override DNS settings on your machine!

Pro Tip: Manually Map Names to IPs

Let's say you have a database server with IP 10.0.0.5, and you want to access it using the name database. Just add this line to your /etc/hosts file:

10.0.0.5 database

Now, whenever you type ping database, your system will automatically connect to 10.0.0.5, no matter what DNS says! #HackTheNetwork

Enter the DNS Server!

Managing hostnames manually gets messy real quick, so that's where DNS servers come in! They centralize everything, so instead of keeping a giant hosts file, your system just asks a DNS server for the right IP.

For example, if your company's internal DNS server is at 10.10.10.1, your laptop will query it whenever it needs to resolve a hostname. If the server doesn't know the answer, it forwards the request up the chain until it finds the right IP.

Pro Tip: Set a Custom DNS Server

To manually tell your system where to look for DNS resolutions, update the /etc/resolv.conf file like this:

nameserver 10.10.10.1

Now, all DNS requests will go to 10.10.10.1 first.

Subdomains: The DNS Name Tree

Ever wondered why we have maps.yourcompany.net, mail.yourcompany.net, and drive.yourcompany.net? These are subdomains, and they help organize different services inside a company or website. ✨

Example DNS setup for a company:

web.yourcompany.net → Main website
db.yourcompany.net → Database server
mail.yourcompany.net → Email services

DNS ensures that when users type these names, they are sent to the correct servers. It's basically the road sign system of the internet!

DNS Caching: How the Internet Gets Faster

Every time you visit a website, your system caches (stores) the DNS result so it doesn't have to ask again. This speeds things up but can sometimes cause problems when IPs change.

How to Clear Your DNS Cache

If a website stops loading properly, refreshing the DNS cache might help:

️ On Windows:

ipconfig /flushdns

On Mac/Linux:

sudo systemd-resolve --flush-caches

Now your system will request fresh DNS info instead of using old data.

Public vs Private DNS: Who Controls the Internet?

If your DNS server doesn't know an answer, it forwards the request to public DNS servers like:

✅ Google DNS → 8.8.8.8
✅ Cloudflare DNS → 1.1.1.1
✅ OpenDNS → 208.67.222.222

But for internal company networks, private DNS servers keep things secure. For example, if you work at yourcompany.net, you don't want random strangers resolving your internal servers!

Recap: DNS is the GPS of the Internet!

Now you know that DNS is the backbone of the web—it translates names into IPs, manages subdomains, caches results for speed, and allows you to override settings when needed.

Quick Cheat Sheet:

✅ /etc/hosts → Manually map names to IPs
✅ /etc/resolv.conf → Set your preferred DNS server
✅ ping, nslookup, dig → DNS troubleshooting tools
✅ ipconfig /flushdns → Clear DNS cache (Windows)
✅ systemd-resolve --flush-caches → Clear DNS cache (Linux/Mac)

You're officially a DNS queen now! Have you ever played around with your DNS settings? Let's chat in the comments! ✨

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Linux for Beginners - Essential Commands Every IT Girl Must Know

2025-03-10T00:00:00.000Z

Hey, lovely tech queens! ‍✨

If you're stepping into the world of Linux, welcome to the coolest club ever! I know, the command line can look super intimidating at first (been there, freaked out ), but trust me—once you get the hang of it, you'll feel like a total hacker goddess.

Today, I'm sharing my ultimate Linux cheat sheet—the basic commands every IT girl needs to master. These will help you navigate, manage files, and work like a pro. Let's dive in!

First Things First: Why Even Bother with Linux?

So, why are we talking about Linux when macOS and Windows exist? Because real IT girls know that:

✔️ Most servers run on Linux, so if you dream of a tech career, you NEED this.
✔️ Developers and cybersecurity pros swear by it—like, ethical hacking? Linux is your BFF.
✔️ It's free, open-source, and powerful—total boss babe energy.

And let's be real—nothing screams I know my sht* like typing commands in a black terminal.

Getting Started: Open That Terminal!

Before we slay the Linux game, let's open the terminal:

On Linux: Ctrl + Alt + T
On Mac: Use "Terminal" from Spotlight (Cmd + Space, then type “Terminal”).
On Windows: Install WSL (Windows Subsystem for Linux) or use Git Bash.

Alright, let's get into the commands that will make you feel like a total IT girl!

Navigating Like a Pro: Moving Around Folders

The first thing you need to learn is how to navigate your system. Forget clicking around—let's move like a boss in the terminal.

1 Where Am I? (Check Current Directory)

pwd

This tells you which folder you're in. Super useful if you ever feel lost.

2 What's Inside This Folder? (List Files)

ls

This shows all files and folders in the current directory.

Pro tip:

Use ls -l for more details (file size, date, owner).
Use ls -a to see hidden files (yes, Linux hides stuff from you).

3 Moving Between Folders (Change Directory)

cd foldername

Moves you into a folder.

Want to go back?

cd ..

Moves up one level.

Or just type:

cd ~

Takes you straight to your home directory.

✨ Think of these commands as teleporting through your files. No more aimless clicking!

File & Folder Magic: Creating, Moving & Deleting

Alright, now that we can move around, let's start making things happen!

4 Create a New Folder (mkdir)

mkdir myfolder

Boom! A new folder is born.

Pro tip:

Want to create multiple nested folders? Use mkdir -p parent/child/grandchild.

5 Create a New File (touch)

touch myfile.txt

Creates an empty file. Perfect for testing.

6 Move or Rename a File (mv)

mv oldname.txt newname.txt

Works for renaming files AND moving them.

Example: Move a file into a folder:

mv myfile.txt myfolder/

Now it's inside myfolder. So neat!

7 Copy a File (cp)

cp myfile.txt copyfile.txt

Now you have a duplicate!

Want to copy a whole folder?

cp -r myfolder newfolder

The -r flag copies everything inside too!

8 Delete a File (rm)

rm myfile.txt

Bye-bye, file!

Be super careful! If you use:

rm -r myfolder

It deletes the entire folder + its contents. No undo!

Reading & Editing Files

Alright, let's check what's inside our files.

9 Read a File (cat)

cat myfile.txt

Shows the contents of a file instantly.

Pro tip:

If the file is too long, use:
```
less myfile.txt
```
This lets you scroll through it. Press q to exit.

10 Edit a File (nano)

nano myfile.txt

Opens a simple text editor inside the terminal.

Running Programs & Managing Processes

Check Running Processes

ps aux

Shows all running programs.

Kill a Stuck Program

kill PID

Or use:

pkill -f process_name

This kills the process by name (super handy!).

Bonus IT Girl Tricks!

Redirecting Output: > vs >>

echo "Hello" > file.txt overwrites the file.
echo "Hello" >> file.txt adds text to the file without deleting old content.

View Command History

history

Lists all commands you've used—no more "What was that command again?" moments!

Find Any File

find / -name "filename"

Searches for a file anywhere on your system.

Want something faster?

locate filename

But first, run:

sudo updatedb

This updates the file database for locate.

Final Thoughts: Own That Terminal, Queen!

So, my fellow IT girl, this is your Linux survival kit. These commands will help you navigate like a pro, manage files, and even kill frozen programs like a boss.

Your next steps:

✅ Practice these commands daily.
✅ Start using Linux as your main OS (if possible).
✅ Experiment & break things—just don't delete your whole system!

And remember, every tech queen starts somewhere—the key is to keep learning.

Got questions? Comment below, and let's geek out together!

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Docker for Girls - Understanding docker ps Once and For All

2025-03-07T00:00:00.000Z

Hey girls!

If you're as passionate about IT and Docker as I am but sometimes find it a bit complicated, don't worry! Today, I'll explain the super-important docker ps command in a way that anyone can understand!

What is `docker ps`?

This command shows all the containers on your computer. It tells you which ones are running, which ones are stopped, and what their settings are. Think of docker ps as your list of all containers—just like a list of open tabs in your browser. ️

When Should You Use `docker ps`?

You use docker ps when you want to:

See which containers are currently running.
Find out which containers have stopped.
Get the ID or name of a container.
Check which ports are open.
View the size of a container.
Check if a container is healthy (yes, containers can have bad days too!).

How to Use `docker ps` (Examples)

The Simplest Command:

docker ps

Shows only running containers.

Want to See All Containers, Even Stopped Ones?

docker ps -a

Now you can see both running and stopped containers. The STATUS column will show why a container stopped (e.g., due to an error or just being turned off).

How to View the Last Created Container?

docker ps --latest

Great for checking if the most recently created container is working properly.

How to Check How Much Space a Container is Using?

docker ps -s

This helps when your disk space is running low.

How to See Only Container IDs?

docker ps -q

Useful when you need container IDs without extra details.

Filtering `docker ps`

To quickly find the container you need, use filters:

Find a container with a specific label:

docker ps --filter label=app=my-app

Show containers created before a specific one:

docker ps --filter before=my-app-container

Find containers using a specific volume:

docker ps --filter volume=my-volume

See containers in a specific network:

docker ps --filter network=my-network

How to Change `docker ps` Output?

By default, docker ps outputs a table, but you can customize what is displayed:

docker ps --format 'table {{.ID}}\t{{.Image}}\t{{.Status}}'

This will show only the container ID, image, and status.

Want JSON format? Easy:

docker ps --format json

Pro Tips!

✨ Don't forget about -a: If a container stops, docker ps won't show it by default, so use docker ps -a.
✨ Set up your favorite commands: For convenience, create aliases for frequently used commands.
✨ Monitor container sizes: Keep only the necessary containers to avoid wasting disk space.

Conclusion

The docker ps command is your go-to tool for managing containers. Now you know how to check which containers are running, which have stopped, and how to filter them. Easy, right?

I hope this guide helped! If you have any questions, feel free to ask—I'm always happy to chat about Docker.

See you soon, IT girl!

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Mastering Terraform Tags Like a True IT Queen

2025-03-04T00:00:00.000Z

Hey girls!

If you're as obsessed with Infrastructure as Code (IaC) as I am, then you know that Terraform is THE tool to have in your IT arsenal. And if you're working with cloud resources, you've probably heard about tags - those little key-value labels that help you organize, track expenses, and automate processes.

But let's be honest: tags can sometimes feel like a necessary evil, especially when you're managing multiple cloud environments.

Don't worry, darling! In this post, we'll break down Terraform tags: why you need them, how to use them, and the best practices to follow. So grab your favorite coffee ☕ and let's dive in!

What Are Terraform Tags?

Think of Terraform tags as little stickers you can attach to cloud resources to keep things organized and manageable. They are key-value pairs that allow you to classify resources by purpose, environment, or owner.

Example:

tags = {
  Environment = "Production"
  Owner       = "IT Girl Dev Team"
  Project     = "CoolNewApp"
}

Why do you need this? Because proper tagging makes resource management easier, helps automate processes, and controls access. Plus, it keeps your infrastructure structured and aesthetic - and we don't want a messy cloud, do we? ❌

Tags vs. tags_all: What's the Difference?

Terraform has two types of tags: tags and tags_all. They sound similar but serve different purposes:

tags - The tags you define in your Terraform code.
tags_all - A read-only attribute that Terraform pulls from the resource itself.

Example (referencing tags in Azure):

azurerm_virtual_network.example.tags_all

Why Should You Use Tags?

Tags aren't just for aesthetics (although we love that too ). Here are some key reasons why tagging is essential:

Organization

Imagine having thousands of resources in your AWS account without tags. Total chaos, right? Tags help group resources by environment, project, or team.

Example:

tags = {
  env     = "staging"
  owner   = "DevOps Team"
  purpose = "testing"
}

Cost Management

Cloud bills can be terrifying , but Terraform tags help you track where your money is going.

Example:

tags = {
  cost_center = "Marketing Analytics"
}

Automation

You know how much I love automation! Tags allow you to manage deployments, shut down unnecessary resources, and set up backups.

Example:

tags = {
  auto_shutdown = "true"
  deploy        = "true"
}

Access Control

You can configure tags to restrict access to resources using AWS IAM policies.

Example:

tags = {
  Environment = "Development"
}

How to Add Tags to Terraform Resources

It's super simple! Just use the tags attribute inside the resource block.

Example:

resource "aws_instance" "my_instance" {
  tags = {
    Environment = "Production"
  }
}

Want to Add Multiple Tags? Easy!

tags = {
  Environment = "Development"
  Owner       = "Leia Organa"
  Department  = "Rebel Alliance"
}

What Are Terraform Default Tags?

Default Tags are automatic tags applied to ALL resources without having to duplicate them in every block.

Example:

variable "common_tags" {
  type = map(string)
  default = {
    Environment = "Development"
  }
}

Then, just use them like this:

tags = var.common_tags

How to Override Default Tags?

Use the merge() function to combine default and custom tags.

Example:

resource "aws_instance" "my_instance" {
  tags = merge(
    var.common_tags,
    {
      Name = "MyAwesomeServer"
    }
  )
}

How to Ignore Tag Changes in Terraform?

If external systems modify your tags (_Azure Databricks, I see you _), tell Terraform to ignore them!

Example:

resource "aws_instance" "my_instance" {
  lifecycle {
    ignore_changes = [tags]
  }
}

Or ignore them at the provider level:

provider "aws" {
  ignore_tags = ["CostCenter"]
}

Best Practices for Terraform Tags

Tips to keep your cloud tagging strategy clean and effective:

✔ Be consistent - Use the same key names across resources.
✔ Document your tags - Define what each tag means.
✔ Automate tagging ⚙️ - Use Terraform modules.
✔ Use Default Tags ✅ - Follow the DRY (Don't Repeat Yourself) principle.

Level Up Your Terraform with Spacelift

Want a flawless GitOps process? Try Spacelift! It makes Terraform even better with:

✨ Security policies (OPA)
✨ Multi-IaC support (Terraform + Kubernetes + Ansible)
✨ Self-service infrastructure ‍♀️

Conclusion

Terraform tags may seem small, but they make a huge difference in cloud resource management. Start using them correctly, and your future IT-self will thank you!

Share your favorite Terraform hacks in the comments or on Twitter!

Until next time, keep slaying the IT world!

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

AWS AI/ML - The Ultimate Guide for IT Girls

2025-02-28T00:00:00.000Z

Hey, my tech-savvy girls!

‍ If you're like me and obsessed with IT and machine learning, let's break down AWS AI/ML services, which help companies (and even individuals) use artificial intelligence without all the hassle!

⚡ AWS is like Netflix for IT, but instead of movies, it's a massive ecosystem of tools that let businesses automate processes, analyze data, create chatbots, and even turn text into lifelike speech!

Today, I'll break down everything in the most detailed and easy-to-understand way, so that by the end of this article, you'll feel like an expert!

AWS: The Magical Toolbox for IT Girls

AWS is Amazon's global cloud platform, which allows businesses and developers to use a wide range of technologies on a subscription basis, without needing to build their own data centers.

How does it work?

1️⃣ You log into AWS, pick the service you need, and start using it.
2️⃣ Everything runs in the cloud, so you don't need to worry about managing servers.
3️⃣ AWS automates all processes and gives you ready-made AI/ML solutions.

AWS offers a TON of services, and now I'll break down the most interesting and useful ones!

AWS AI/ML is Like an Amusement Park: Let's Ride!

1. Amazon SageMaker - The Queen of Machine Learning

What is it?

Amazon SageMaker is the most powerful AWS tool for machine learning. It lets you build, train, and deploy ML models without needing deep programming knowledge.

How does it work?

✔️ You choose an ML model (or use a prebuilt one).
✔️ Upload data (e.g., last year's sales for an online store).
✔️ SageMaker trains the model and makes predictions.

Where is it used in real life?

✅ Finance - predicts stock price movements.
✅ Weather forecasting - analyzes temperature trends.
✅ E-commerce - recommends products to customers.
✅ Fraud detection - identifies suspicious bank transactions.

IT Girl Tip:

If you're new to ML, SageMaker automates everything—just upload data, and it does the magic for you! ✨

2. Amazon Lex - Smart Chatbots & Virtual Assistants

What is it?

Amazon Lex is an AI service for creating smart chatbots and virtual assistants like Alexa or Siri.

How does it work?

✔️ Uses Natural Language Processing (NLP) to understand what users are saying.
✔️ Processes both text and voice commands.
✔️ Works based on intents—you set up sample phrases, and the bot learns to respond.

Where is it used in real life?

✅ Customer service chatbots - answer FAQs without human agents.
✅ Virtual assistants - Alexa-style bots for businesses.
✅ Data search bots - find information quickly based on user queries.

IT Girl Tip:

Want to create your own chatbot? Lex helps you do it without complex coding!

3. Amazon Polly - The AI Voice Generator (Talking Robot)

What is it?

Amazon Polly is an AI tool that turns text into lifelike speech!

How does it work?

✔️ You type in a text.
✔️ Polly reads it in a natural-sounding voice (male, female, child, and even with accents!).
✔️ You can adjust tone, speed, and emotions.

Where is it used in real life?

✅ Audiobooks & articles
✅ Voiceovers for videos & ads
✅ Accessibility for visually impaired users
✅ Smart voice assistants ‍♀️

IT Girl Tip:

If you have a YouTube channel or TikTok, Polly can automatically voiceover your scripts!

4. Amazon Rekognition - AI for Facial & Object Detection

What is it?

Amazon Rekognition is an AI system that analyzes images and videos to detect people, objects, and even emotions!

How does it work?

✔️ Recognizes faces and objects.
✔️ Detects human emotions.
✔️ Can analyze live video streams.

Where is it used in real life?

✅ Security - surveillance cameras automatically recognize faces.
✅ Content moderation - filters out inappropriate images.
✅ Marketing analytics - studies customer reactions to ads.

IT Girl Tip:

If you work in cybersecurity or UX design, Rekognition can automate visual content analysis!

5. Amazon Textract - AI-Powered Document Scanning

What is it?

Amazon Textract extracts text, tables, and forms from scanned documents and images.

Where is it used in real life?

✅ Finance - analyzing invoices & receipts.
✅ Healthcare - digitizing medical records.
✅ Legal - automating document review.

IT Girl Tip:

If you have a pile of paperwork, Textract can turn it into searchable digital data!

6. Amazon Translate - AI-Powered Language Translator

What is it?

Amazon Translate is AWS's AI-powered translation tool that translates text in real time.

Where is it used in real life?

✅ Website & app localization.
✅ Business document translation.
✅ Social media & comment analysis.

IT Girl Tip:

Need to quickly translate a large amount of text? Amazon Translate does it in seconds!

7. Amazon Transcribe - Automatic Speech-to-Text

What is it?

Amazon Transcribe turns spoken words into text automatically!

Where is it used in real life?

✅ Subtitles for videos
✅ Lecture & interview transcriptions

IT Girl Tip:

A must-have tool for bloggers, journalists, and students!

8. Amazon Kendra - The AI-Powered Search Engine

What is it?

Amazon Kendra is like Google for your company's internal files—it helps businesses quickly find documents, reports, and emails.

Where is it used in real life?

✅ Corporate search - fast retrieval of policies, reports, and knowledge base articles.
✅ Customer support - quickly pulls up relevant FAQs.

IT Girl Tip:

If you work with a lot of PDFs & reports, Kendra automates searching & organizing!

9. Amazon Comprehend - AI-Powered Text Analysis

What is it?

Amazon Comprehend reads and understands text like a human, detecting emotions, key topics, and relationships between words.

Where is it used in real life?

✅ Customer sentiment analysis - understand what users feel about a product.
✅ Social media monitoring - track trends & user reactions.

IT Girl Tip:

Perfect if you work with customer reviews, social media comments, or support tickets!

That's it! Now you know everything about AWS AI/ML!

Which service are you most excited to try?

Tatiana Mikhaleva

Docker Captain · IBM Champion · AWS Community Builder

DevOps.Pink — cloud-native education for the agentic-AI era.

YouTube Discord LinkedIn

Mastering archive_file in Terraform Like a Pro

2025-02-27T00:00:00.000Z

Hey friends! If you're as obsessed with Terraform as I am (because who doesn't love automating infrastructure the chic way?!), then you NEED to know about the archive_file data source. It's basically your bestie for packaging files into ZIP or TAR formats, making deployments effortless. No more manual zipping—Terraform does it for you.

Today, I'm breaking down everything you need to know about archive_file, how to create archives from single or multiple files, and troubleshooting tips because we all know tech can be a little moody sometimes.

What is `archive_file` in Terraform?

Think of archive_file as the glam squad for your code—it takes your files and bundles them into neat little ZIP or TAR packages. Super useful for:

✨ Deploying AWS Lambda functions (which require zipped code!) ✨ Packaging Kubernetes manifests or Helm charts ✨ Bundling files before uploading to S3, Azure Storage, or Google Cloud Storage

Here's how you set it up:

data "archive_file" "example" {
  type        = "zip"              # Options: zip, tar, tgz
  source_dir  = "path/to/source"   # Directory to compress
  output_path = "path/to/output.zip" # Destination of the archive
}

Or, if you're working with just one file:

data "archive_file" "example_file" {
  type        = "zip"
  source_file = "path/to/file.txt"
  output_path = "path/to/output.zip"
}

Pro Tip: Use source_dir for entire folders and source_file for single files—but NOT both in the same block. Terraform's picky like that.

Creating an Archive from a Single File

Let's say you need to ZIP up a single file (hello, AWS Lambda deployments!). It's super simple:

data "archive_file" "example" {
  type        = "zip"
  source_file = "example.txt"
  output_path = "example.zip"
}

output "archive_checksum" {
  value = data.archive_file.example.output_base64sha256
}

This output_base64sha256 is a SHA-256 checksum to make sure your file stays intact. You don't need it, but it's a nice way to keep things in check. ✅

Example: Zipping a Python Script for AWS Lambda

Say you have lambda_function.py and need to deploy it to AWS Lambda:

data "archive_file" "lambda_zip" {
  type        = "zip"
  source_file = "lambda_function.py"
  output_path = "lambda_function.zip"
}

Then use it in your Lambda function:

resource "aws_lambda_function" "my_lambda" {
  function_name    = "my_lambda_function"
  role             = aws_iam_role.lambda_role.arn
  runtime          = "python3.8"
  handler          = "lambda_function.lambda_handler"

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
}

✨ Heads up! If your function has dependencies, you need to zip the whole folder, not just the script.

Creating Archives from Multiple Files

Ugh, I wish Terraform let us specify multiple files directly, but no, it's a diva. The workaround? Gather files in a temp folder first:

resource "terraform_data" "prepare_files" {
  provisioner "local-exec" {
    command = <


If you just want to archive an entire directory:
data "archive_file" "example" {
  type        = "zip"
  source_dir  = "${path.module}/my_folder"
  output_path = "${path.module}/example.zip"
}


Uploading an Archive to Azure Storage
For my Azure girls , here's how to compress a folder and upload it to an Azure Storage Blob:
data "archive_file" "app_package" {
  type        = "zip"
  source_dir  = "${path.module}/my_app_folder"
  output_path = "${path.module}/app_package.zip"
}

Now, create a storage account and upload it:
resource "azurerm_storage_blob" "example" {
  name                   = "app_package.zip"
  storage_account_name   = azurerm_storage_account.example.name
  storage_container_name = azurerm_storage_container.example.name
  type                   = "Block"
  source                 = data.archive_file.app_package.output_path

  depends_on = [data.archive_file.app_package]
}


Troubleshooting archive_file Issues
Terraform acting up? Here's how to fix common archive_file headaches:
1️⃣ Incorrect Source Path → Check your file paths! Use ${path.module} to avoid mistakes.

2️⃣ Missing zip Utility → Terraform needs zip installed. Fix it with:

Linux: sudo apt install zip
macOS: brew install zip
Windows: Ensure zip.exe is in your PATH.

3️⃣ Files Not Updating? → Terraform won't detect changes inside source_dir. Use filemd5() like this:
output "archive_hash" {
  value = filemd5(data.archive_file.example.output_path)
}

4️⃣ Permission Issues → If AWS Lambda or Docker throws permission errors, chmod your files before zipping:
chmod +x my_script.sh

5️⃣ Wrong Paths in Modules → Always use ${path.module}, not ${path.root}!

Key Takeaways
archive_file is a Terraform essential for packaging files before deployment.

Use source_file for one file and source_dir for entire folders.

Troubleshoot common issues with paths, permissions, and missing utilities.
Terraform is fun (and powerful), so go forth and automate like the IT queen you are! ‍✨



Tatiana Mikhaleva


Docker Captain  ·  IBM Champion  ·  AWS Community Builder


DevOps.Pink — cloud-native education for the agentic-AI era.


YouTube
Discord
LinkedIn



DevOps for IT Girls - Deploying Like a Queen
2025-01-09T00:00:00.000Z
Hey, tech beauties!
If DevOps sounds like a complicated, dry topic, then you've never had it explained the right way! Think of it as the ultimate self-care routine for your code—from writing it, to deploying it, to making sure it always runs smoothly.
Today, we're going through the entire DevOps cycle in a way that's easy, fun, and totally girl-coded—with an example we all understand: skincare & beauty!

Step 1: You Have an Idea—Now What?
Let's say you want to create a smart skincare recommendation app. You enter your skin type, age, and season, and boom—it suggests the perfect skincare routine. Genius, right?
You open VS Code, spend a few hours coding (we don't sleep, we debug ️), and it works!
But wait… only you can see it. How do we make it available to the world?

Step 2: Packaging It Up (Docker)
Here's the first DevOps rule: Just because it works on your laptop doesn't mean it'll work anywhere else.
Think of your code like skincare products. If you're traveling, you wouldn't just throw your creams, serums, and SPF loose into your suitcase, right? You'd pack them neatly in a travel bag to keep everything organized and secure.
That's exactly what Docker does for your app:
✅ Packs your code and all dependencies together

✅ Ensures it runs the same way anywhere—your laptop, a server, or the cloud

✅ Eliminates the “but it works on my machine!” excuse
Now, wherever your app goes, it's ready to glow ✨.

Step 3: Setting Up the Right Space (Terraform)
Okay, now your app is inside its cute little Docker container—but where do you run it? You need a server.
This is where Terraform comes in. If Docker is your travel bag, Terraform is your perfectly organized vanity shelf, making sure everything is set up just the way you like it.
Terraform helps by:
✨ Creating servers automatically (no manual clicking in cloud dashboards)

✨ Ensuring they always have the right settings (memory, CPU, storage)

✨ Making it easy to scale when traffic grows
Instead of setting up a new server manually every time, Terraform does it for you—perfectly, every time.

Step 4: Organizing Everything (Ansible)
Great, you've got a server—but it's completely empty. No software, no setup, nothing. It's like getting a brand-new vanity table with no products on it.
This is where Ansible comes in.
Imagine you have a list of must-have skincare products (cleanser, moisturizer, SPF, serum). You always arrange them in the same order on your vanity so everything is easy to find.
That's what Ansible does for your server:
✅ Installs all the software it needs (Docker, libraries, tools)

✅ Configures everything automatically

✅ Makes sure every new server is set up exactly the same way

Step 5: Automating Updates (CI/CD)
You decide to add a new feature: your app now suggests skincare based on the weather (because let's be real—your routine is different for winter vs. summer!).
But updating your app manually every time you make a change? Girl, no.
That's why we use CI/CD (Continuous Integration / Continuous Deployment):
✅ You push your new code to GitHub

✅ CI/CD tools (GitHub Actions, GitLab CI/CD, Jenkins) automatically test, build, and deploy it

✅ Your app updates without you lifting a finger
It's like a beauty subscription box—new products show up at your door every month, without you having to reorder them.

Step 6: Monitoring Performance (Prometheus & Grafana)
Your app is live, but how do you know if it's running smoothly?
Meet Prometheus & Grafana, your app's skincare tracker.
Prometheus collects data (server health, errors, traffic, performance)

Grafana turns it into beautiful dashboards & alerts
Just like tracking your skincare routine helps you know when to hydrate more or change products, monitoring tools help prevent app crashes before users even notice.

The Full DevOps Cycle—Beauty Edition
So, let's put it all together:
1️⃣ Write the code ️ (find your perfect skincare routine)

2️⃣ Package it in Docker  (store products in a beauty bag for easy travel)

3️⃣ Deploy infrastructure with Terraform  (set up a perfectly organized vanity shelf)

4️⃣ Set up servers with Ansible  (arrange your skincare in the right order)

5️⃣ Automate updates with CI/CD  (subscribe to beauty boxes so you always get the latest products)

6️⃣ Monitor everything with Prometheus & Grafana  (track your skincare results and adjust as needed)
Now, your app deploys automatically, scales seamlessly, and never crashes unexpectedly. That's what I call effortless beauty… and DevOps magic! ✨

Final DevOps Girl Tips
Learn step by step: Start with Docker, then move to CI/CD, then Kubernetes. No need to learn everything in one day!
⚡ Automate everything: The less manual work, the more time for innovation (or coffee & skincare ).
Stay updated: DevOps is always evolving—follow IT girl bloggers, Twitter devs, and tech conferences to stay ahead.
And most importantly, don't be afraid! DevOps isn't scary—it's just a well-organized self-care routine for your apps.
So go out there and deploy like a queen! ✨



Tatiana Mikhaleva


Docker Captain  ·  IBM Champion  ·  AWS Community Builder


DevOps.Pink — cloud-native education for the agentic-AI era.


YouTube
Discord
LinkedIn





Top Machine Learning YouTube Courses to Fuel Your Tech Passion
2024-05-05T00:00:00.000Z
Hey there, code cuties!  Today, I'm totally thrilled to share with you all something that's super close to my heart—your ultimate guide to slaying the tech world with the best Machine Learning and Deep Learning courses you can find on YouTube!  Whether you're a total newbie or a seasoned pro looking to spice up your skill set, I've curated just the right playlists to keep your tech game on point. Let's dive into this digital adventure together! ✨

Foundational Machine Learning Courses

Starting Strong: Kick off your journey with the Introduction to Machine Learning (Tübingen). It's like the beginner's bible—think regression, classification, and sparking those aha! moments.
Deep Dive into Data: Get cozy with data in Statistical Machine Learning (Tübingen). It's all about unlocking the secrets of algorithms and learning paradigms.
Master the Basics: With Machine Learning Lecture (Stefan Harmeling), you'll grasp the essentials from Bayes' rule to Gaussian Processes. Total game-changer!
Full Spectrum Learning: The Caltech CS156: Learning from Data course is a gem, covering everything from the basics to support vector machines. Prepare to be amazed!
Hands-On Hero: For those who love getting their hands dirty, Applied Machine Learning teaches the nitty-gritty of optimization and regularization. It's practical magic! ✨


Deep Learning Exploration

Beginner's Luck: Start your deep learning quest with Introduction to Deep Learning (MIT). It's perfect for babes stepping into the tech scene.
Technique Treasure Trove: The Deep Learning: CS 182 course will have you mastering everything from error analysis to imitation learning. Unlock your potential!
Nerd Out with Neural: Dive deep with Neural Networks: Zero to Hero by Andrej Karpathy. It's your backstage pass to the neural network show!
Creativity Meets AI: Explore how AI transforms art in MIT: Deep Learning for Art, Aesthetics, and Creativity. Perfect for when your inner artist meets your inner coder!
Unsupervised Learning Adventures: Get intrigued by the mysteries of AI with Deep Unsupervised Learning. Discover what lurks behind the data! ️‍♀️


Specialized Courses in Machine Learning

Healing with AI: The MIT 6.S897: Machine Learning for Healthcare (2019) melds ML with medicine. It's where tech meets tender loving care!
Graph Gurus: For a graph-tastic experience, check out Machine Learning with Graphs (Stanford). From PageRank to graph neural networks, it's a must for data divas!
Talk the AI Talk: Dive into CS224N: Natural Language Processing with Deep Learning and learn how to teach machines to understand us. Finally, a tech that gets you!


Practical and Real-World Applications

Language Model Love: Learn to build with LLMOps: Building Real-World Applications With Large Language Models. Bring your code to life!
From Lab to Fab: Full Stack Deep Learning guides you through everything from model training to real-world deployment. Let's get those models runway-ready!


Exploring Computer Vision and Reinforcement Learning

See the Vision: Stanford's CS231N: Convolutional Neural Networks for Visual Recognition is perfect for spotting trends and techs in visual data. ️
Decision Day: Unravel the secrets of AI decision-making with Reinforcement Learning (Polytechnique Montreal, Fall 2021). It's all about making smart choices!

This lineup is literally your dream guide to becoming a tech queen! Whether you're just getting started or looking to level up, these courses are your golden tickets to the tech scene. Let's own this journey together, one algorithm at a time!



Tatiana Mikhaleva


Docker Captain  ·  IBM Champion  ·  AWS Community Builder


DevOps.Pink — cloud-native education for the agentic-AI era.


YouTube
Discord
LinkedIn

DevOps.Pink

AI SRE Joined My On-Call — A Beginner-Friendly Walkthrough of Rootly

Why "AI SRE" became a thing in 2026

How Rootly handles trust: the four-level model

What stood out beyond the trust model

Will it replace me?

Who this is for

Stop Lying About Your Backups — Zero-Trust Recovery with Plakar

1. The Fear of Recovery

Plakar is Digital Memory

2. The Trap of Dependence

3. Paranoia

Client-Side Encryption

4. Budget

Smart Deduplication

The Prescription

Escaping the Command Line Cartel: Why I Mandate Visual Git in Enterprise DX

1. High-Signal Telemetry (Total Honesty)

2. Tactile Architecture & Frictionless Workflows

3. Adult Conflict Resolution

4. Psychological Safety (The Magic Button)

5. Ecosystem Interoperability

The Executive Verdict

Kubernetes Is No Longer Number One — The REAL 2025 Cloud Native Report (CNCF x SlashData)

Finding Number One: Backend won

Finding Number Two: AI is not that cloud native

Finding Number Three: What's really being used

What to do with this data

Final verdict

Amazon Q - The AI DevOps Tool That Fixes AWS Headaches

Meet Amazon Q

How It Works in Real Life

Example 1: The Silent Lambda

Example 2: Building a VPC

Example 3: Route 53 DNS Setup

Who Amazon Q Helps

ChatGPT vs Amazon Q

A Few Things to Keep in Mind

Final Thoughts

Join the Conversation

Inside Helm - How Charts, Releases, and State Work in Kubernetes

What's Inside a Helm Chart

What Actually Happens When You Run helm install

Where Helm Stores Release State

Labels and Annotations

What Is a Helm Release?

The Three-Way Merge Explained

Namespaces: Release vs Target

Storage Drivers

Managing Release History

TL;DR

Quick Debug Tip

Git Merge Conflicts for Beginners - What to Do When Your Branches Have Beef

Wait, What Even Is git merge?

When It's a Buttery-Smooth Ride

(The Fast-Forward Merge)

When Git Has a Meltdown (aka a Conflict)

What This Hot Mess Looks Like in Your Code

Okay, So How Do I Fix This? A Step-by-Step Guide!

The Final Steps: Letting Git Know You're a Genius

SOS! What If I Messed Everything Up?

How to Vibe with merge and Avoid Conflicts

The Takeaway

Git Branches - How to Not Break Prod and Stay Alive

What's a Branch, Really?

How to Work with Branches - Step by Step

1. Create a New Branch and Switch to It

2. Do Some Work: Commit & Push

3. See What Branch You're In

4. Switch Back to main and Update It

5. Merge Your Branch into main

6. Handling Merge Conflicts

7. Delete the Branch

8. View Branch History Visually

Merge vs Rebase: When and Why

Suggested Team Workflow

Working with Remotes

Command Cheat Sheet

Best Practices (And Why They Matter)

Final Thoughts

Wait, What Even Is `git merge`?

Scene 2: Create `service.yaml`