DEV Community: Vladimir Mikhalev

Cypress in the Age of AI Agents: Orchestration, Trust, and the Tests That Run Themselves

Vladimir Mikhalev — Thu, 26 Feb 2026 11:33:21 +0000

Last year, I wrote about Docker and Cypress for this blog. It covered containers, layer caching, and parallel runners. Good stuff. Useful stuff.

But I'm not writing that article again.

Here's why.

I could write a perfect container config in my sleep. So could Claude. So could GPT. So could any intern with a prompt. Syntax has become a commodity. The Dockerfile isn't the hard part anymore.

The hard part?

Orchestration and trust when AI agents run the tests.

Let me explain.

The Shift Nobody Talks About

In 2025, Cypress shipped cy.prompt(). Write tests in plain English. The AI figures out the selectors. It even self-heals when your UI changes.

That's powerful. And that's dangerous.

Not because the tool is bad. It's genuinely impressive. But because it changes who is making decisions in your pipeline. And most teams haven't thought about that.

Before cy.prompt(), the chain of trust was simple:

A human wrote the test
A human reviewed it
CI ran it
If it failed, a human fixed it

Every link in that chain had a name attached.

Now?

An AI writes the test
An AI picks the selectors
An AI heals the test when it breaks
The human sees green checkmarks
Everybody ships

Until something goes wrong. And nobody knows why.

Autonomy vs. Augmentation: The Framework That Matters

The industry keeps confusing two very different things.

Autonomy means the agent acts for you. You find out later what happened.
Think: self-driving car. You're the passenger. The AI makes every turn.

Augmentation means the agent helps you decide. You still make the call.
Think: GPS navigation. It suggests the route. You drive.

Most AI testing tools sell autonomy:

"Never write a test again!"
"Self-healing pipelines!"
"Zero maintenance!"

That sounds great in a demo.

It falls apart in production.

Google's testing team found that 1.5% of all test runs were flaky (2016 study). Nearly 16% of tests showed some flakiness over time. Microsoft reported 49,000 flaky tests across 100+ product teams (2022). These numbers haven't gotten better. Now imagine those tests were written by AI.

You don't have a testing problem.

You have a trust problem.

What Actually Happens When AI Writes Your Cypress Tests

I've watched AI code assistants generate test suites. Here's the pattern I see every time:

Day one: Beautiful. High coverage numbers. Clean syntax. The PR merges fast. Everyone celebrates.

Week two: A UI change breaks three tests. The self-healing kicks in. Tests pass again. Nobody checks what changed.

Month two: The self-healed selectors are now targeting the wrong elements. The tests pass. But they're testing the wrong things. Your coverage number says 90%. Your real coverage is closer to 40%.

Quarter end: A production bug ships. The test suite was green. The post-mortem reveals the AI "healed" a critical login test. It now clicks a decorative button instead of the submit button. Both are blue. Both say "Continue."

The AI didn't fail.

The architecture failed.

Nobody designed a system where AI decisions get verified.

The Architecture Cypress Teams Actually Need

Here's the playbook I'd build for any team using Cypress with AI in 2026.

Layer 1: AI Generates, Humans Gate

Use cy.prompt() (or any AI tool) to draft tests. That's the accelerator.

But treat AI-generated tests like pull requests from a junior developer.

// cy.prompt() generates the test
cy.prompt([
  'Visit the login page',
  'Type admin@company.com into the email field',
  'Type the password into the password field',
  'Click the sign in button',
  'Verify the dashboard loads'
])

Then eject that code. Review the selectors. Commit the explicit version.

// The reviewed, committed version
cy.visit('/login')
cy.get('[data-cy=email]').type('admin@company.com')
cy.get('[data-cy=password]').type(Cypress.env('TEST_PASSWORD'))
cy.get('[data-cy=submit-login]').click()
cy.url().should('include', '/dashboard')
cy.get('[data-cy=welcome-banner]').should('be.visible')

The AI got you there faster. A human verified the result.

That's augmentation.

Layer 2: The Trust Boundary in CI

Your pipeline needs a clear line:

On one side: things AI can do alone
On the other: things that need human eyes

# GitHub Actions - Trust Architecture
jobs:
  ai-generated-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Run AI-assisted test suite
        run: |
          docker compose -f docker-compose.cypress.yml up \
            --abort-on-container-exit \
            --exit-code-from cypress

      - name: Validate no self-healed selectors
        run: |
          # Flag any tests that healed since last commit
          # Note: Requires a custom script to parse
          # Cypress Cloud API or stdout logs
          node ./scripts/check-healed-tests.js
          # If selectors changed, block the merge
          # Force a human review

      - name: Screenshot diff on healed tests
        if: failure()
        run: |
          # Capture what the AI "fixed"
          # Attach to PR for human review
          npx cypress run --spec "healed-tests/**" \
            --config screenshotOnRunFailure=true

The key:

Self-healed tests don't auto-merge. They create a review request. A human looks at what changed. Then decides.

Layer 3: The Accountability Layer

Every AI decision in your pipeline needs a log.

Not just "test passed."

But: "test healed selector from .btn-primary to .btn-action on Feb 15."

// cypress.config.js
module.exports = {
  e2e: {
    experimentalPromptCommand: true,
    setupNodeEvents(on, config) {
      on('after:spec', (spec, results) => {
        // Parse Cypress stdout or Cloud API for healing events.
        // Self-healing data appears in the Command Log
        // but isn't yet exposed in results.stats.
        //
        // Option A: Parse terminal output for "Self-Healed" tags
        // Option B: Query Cypress Cloud API for spec run details
        // Option C: Build a custom Cypress plugin that listens
        //           to command events during the run

        const healingEvents = parseHealingFromLogs(spec.name)

        if (healingEvents.length > 0) {
          logToAuditTrail({
            spec: spec.name,
            healed: healingEvents.length,
            timestamp: new Date().toISOString(),
            details: healingEvents
          })
        }
      })
    }
  }
}

When something breaks in production, you can trace it back:

"The AI changed this selector on this date. Nobody reviewed it. That's the gap."

Without this layer, your pipeline is a black box.

Green doesn't mean correct. It means unchallenged.

Layer 4: Docker as the Trust Container

Docker isn't just for consistency anymore.

It's your isolation boundary for AI-generated tests.

# docker-compose.cypress.yml
services:
  cypress-human-authored:
    build:
      context: .
      dockerfile: Dockerfile.cypress
    command: >
      npx cypress run
      --spec "cypress/e2e/human-authored/**"
    volumes:
      - ./results/human:/results

  cypress-ai-generated:
    build:
      context: .
      dockerfile: Dockerfile.cypress
    command: >
      npx cypress run
      --spec "cypress/e2e/ai-generated/**"
    volumes:
      - ./results/ai:/results
    # AI tests run in a separate container
    # Different reporting, different trust level

Separate the results. Report them differently.

Human-authored tests are your source of truth
AI-generated tests are your early warning system

When both agree: high confidence.
When they disagree: investigate.
When only AI tests pass: be suspicious.

The Uncomfortable Question

Here's where I need to be honest.

I've been in tech for 20 years, and spent the last 15 building delivery pipelines. I can debug a failing Docker container at 2 AM with my eyes half closed. I've configured CI/CD systems that run thousands of tests across dozens of services.

And I'm watching AI tools do parts of that job faster than I can.

That's not a threat.

That's a signal.

The value isn't in writing the cy.get() selector anymore.

The value is in designing the system where:

AI-generated selectors get verified
Self-healing gets audited
Trust has a paper trail

The Executor writes the test.

The Architect designs the trust system.

Most teams are building AI-powered testing without building AI-accountable testing. They're adding speed without adding trust.

That's technical debt with a new name.

What I'd Do This Week

If I ran a Cypress team today, here's my Monday morning plan:

Separate your test suites. Human-authored in one folder. AI-generated in another. Track them separately.
Add an audit log for self-healing. Every time cy.prompt() (or any AI tool) changes a selector, log it. Make it visible.
Block auto-merge on healed tests. Self-healed tests go into a review queue. A human approves. Every time.
Run AI tests in a separate Docker container. Different reporting pipeline. Compare results against human-authored tests.
Measure real coverage. Not line coverage. Not selector coverage. "Does this test actually verify the behavior we care about?" AI can inflate coverage numbers without testing anything meaningful.

None of this is anti-AI.

All of this is pro-trust.

The Bottom Line

Cypress + AI is the future. I believe that. cy.prompt() is a genuine leap forward.

The ability to write tests in plain English, the self-healing, the lower barrier to entry — all of it matters.

But the teams that win won't be the ones who automate the most.

They'll be the ones who trust the right things and verify everything else.

The bot that ships the wrong build doesn't get fired. You do.

Design accordingly.

Resources:

Valdemar is a Docker Captain and Cypress Ambassador based in Canada. He builds CI/CD pipelines that don't lie to you. Find him at valdemar.ai.

Cypress Test Replay in 2025: The Ultimate Guide to Time-Travel Debugging

Vladimir Mikhalev — Fri, 25 Apr 2025 15:30:39 +0000

In 2022, I was knee-deep in debugging hell. Picture this: It's Friday evening, your tests fail only in CI, and your teammates casually toss around the dreaded phrase: "It works on my machine!" 😱

Enter Cypress Test Replay—a feature that felt straight out of the future. Fast-forward to 2025, and this tool has evolved into something truly game-changing. Test Replay now turns every test run into an interactive time-travel debugging session, capturing complete DOM snapshots, network requests, and console logs, all seamlessly accessible through Cypress Cloud.

Note: Test Replay is available only for recorded runs in Cypress Cloud (not local CLI runs).

Let me show you how this magic works—and how it'll change your QA game for good.

Why Test Replay Is a Must-Have in 2025

Web apps are getting crazy complex:

Micro-frontends and WebAssembly have introduced quirky asynchronous behavior.
AI-driven UIs mean unpredictable, dynamic states.
Shift-left QA means teams need to debug super-fast, even at the PR stage.

Good luck troubleshooting all that with old-school videos or screenshots. Test Replay saves the day by making every CI test run a permanent, detailed artifact that's as easy to navigate as your favorite Netflix series.

Goodbye, Grainy Videos. Hello, Deterministic Debugging!

Remember trying to spot bugs from blurry CI videos? Yeah, me neither—because now, I just replay tests exactly as they happened.

What Gets Captured	What You See	Why It's Awesome
DOM & Shadow DOM	Element states, attributes, hierarchy	Spot precise UI glitches
CSS & Layout	Computed styles, box model	Debug those weird layout shifts
Network	API calls, payloads, timing	Quickly identify backend bugs
Console & JS Errors	Logs, full stack traces	No more manual error hunting
Browser Metadata	Viewport, browser, OS info	No more environment guessing

Currently, Test Replay is fully supported on Chromium-based browsers (Chrome, Edge, Electron). Support for Firefox and Safari is not yet available.

Quick Tech Breakdown

Instrumentation: Cypress snaps the DOM state efficiently.
Optimized Streaming: Tiny snapshot diffs stream securely (usually <300 kB each!).
Playback: Cypress Cloud reconstructs your tests pixel-perfectly.

Tip: Disable old-school video recording—Test Replay is lighter, faster, and just better.

⚠️ Limitation: Test Replay captures browser network activity (like fetch/XHR), but not cy.request() traffic. For those, use manual logging or test stubs as needed.

🧠 Want more? Check out Cypress Test Replay Docs for latest updates and full details.

Setting Up Cypress Test Replay Like a Pro

What You Need

Cypress v13+ (but seriously, go for v14.3.2).
Cypress Cloud integration is built into the Cypress app by default (since late 2023).
You still need to manually create a project in Cypress Cloud and retrieve your CYPRESS_RECORD_KEY to enable Test Replay for CI runs.
Chromium browser (Chrome ≥118, Edge ≥118, or Electron). Test Replay is not supported on Firefox or Safari.

Recommended Setup

// cypress.config.ts
import { defineConfig } from 'cypress';

export default defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      // Your custom tasks
    },
    video: false, // Save those precious CI minutes
    testIsolation: 'on', // Keeps states squeaky clean
    experimentalRunAllSpecs: true, // Run all specs in a suite cleanly
  },
  reporter: 'cypress-cloud/reporter',
  projectId: 'your-cypress-project-id',
});

Quick CI Integration

npx cypress run \
  --browser chrome \
  --record \
  --key $CYPRESS_RECORD_KEY \
  --parallel --group "e2e-chrome"

Once your run completes, open Cypress Cloud → Runs → select your spec → click Test Replay, and debug like you're watching a live recording.

💡 Pro Tip: For larger teams, consider managing Cypress Cloud settings in a .cypress.cloud.config.yaml file to keep project configs consistent and clean.

Real-Life Debugging Workflow

Here's how I tackle tricky bugs:

Spot the Bug: Click straight to the failing test step.
Inspect the DOM: Confirm UI visibility and correctness.
Network Deep-Dive: Scan API responses for errors.
Console Magic: Copy-paste errors right into my IDE.
Teamwork Time: Send teammates a direct link to the exact bug scenario.

Advanced Moves to Impress Your Team

1. Crush Flaky Tests

Use Attempt Selector to instantly compare retries—say goodbye to race conditions. Share network waterfalls to quickly spot backend slowness.

2. Level Up Your Performance Game

Overlay key metrics like Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) directly onto replay timelines.

3. Ace Your Security Audits

While Cypress Replay doesn't capture localStorage directly, you can verify that no sensitive tokens leak into visible DOM, URLs, or console output—crucial for SOC 2 and ISO compliance.

4. Custom Business Events

Emit custom events during tests:

cy.window().then(win => {
  win.dispatchEvent(new CustomEvent('cart:add', { detail: { sku: 'SKU123', qty: 2 } }))
});

Visualize these directly in Cypress Cloud.

💡 Pro Tip: Pair this with custom Cypress log messages (cy.log('cart:add')) to tag key steps in the replay timeline.

Performance & Storage Wins

Factor	Video Capture	Test Replay
Artifact Size	8–20 MB	0.2–1 MB
CI Impact	CPU-heavy	Lightweight
Data Richness	Limited	Super detailed

Canvas capture is supported in v13.5+, but disabled by default. Contact Cypress support to enable it if needed.

Security Essentials (Cypress Cloud)

TLS 1.3 transit encryption, AES-256 at rest.
Regional data storage (EU/US).
Easy project-level access control.
Enterprise-grade features (SAML 2.0, SCIM provisioning).

Comparing Competitors (Quickly!)

Feature	Cypress Replay	Playwright	Replay.io
CI Integrated	✅	✅	❌
DOM Inspection	✅	✅	✅
Cloud-ready	✅	❌	✅
Licensing	MIT	Apache-2.0	MPL-2.0

The big win? Cypress Test Replay plugs straight into your existing workflow—no extra steps.

Final Thoughts

By adopting Cypress Test Replay, you're not just debugging faster—you're stepping into the future of QA.

Trust me, your team will thank you (and your Fridays will become much calmer).

Now, go impress everyone. 🚀

Docker + Cypress in 2025: How I’ve Perfected My E2E Testing Setup

Vladimir Mikhalev — Thu, 20 Mar 2025 16:11:39 +0000

Hey there! A few years back, I was juggling multiple test frameworks, environment conflicts, and the dreaded “it works on my machine” fiasco. My team was shipping code daily, and every time a build passed on one environment but failed on another, it felt like I was stuck in a never-ending game of whack-a-mole. Enter Docker—my personal hero for environment consistency. Then along came Cypress, with its friendly syntax, real-time reloading, and powerful debug tools. It was a match made in DevOps heaven.

Fast forward to 2025, and containerization plus reliable E2E testing has become practically mandatory if you want to keep up with lightning-fast release cycles. Below are the best practices, gleaned from official docs and my own experiences, that’ll ensure your Docker+Cypress pipeline stands out.

Why This Combo Still Rocks

Consistency: By shipping Cypress in the same Docker image across dev, staging, and prod, I avoid environment-specific breakages.
Scalability: Need to parallelize tests? Docker’s lightweight, immutable containers spin up (and shut down) fast, which is perfect for large test suites.
Security: Containers isolate your testing environment, and with a few extra steps (detailed below), you can harden them significantly.

If you’re skeptical, just think of the alternative: manual installs, mismatched dependencies, and “quick fixes” that come back to haunt you months later. No thanks!

1. Upgrading the Cypress Docker Base Image (Node Version)

One of the coolest updates in 2025 is that Node 22.x (or newer) has become the standard. The Cypress team keeps releasing updated Docker images with the latest browsers—so be sure to use them!

FROM cypress/browsers:node-22.14.0-chrome-133.0.6943.126-1-ff-135.0.1-edge-133.0.3065.82-1

Why? Staying on the latest LTS means fewer security patches to worry about and better performance under the hood.

Where to find it? Check the Cypress Docker Images documentation for the most up-to-date tags.

2. Supercharging Your Docker Workflow

Optimized Dockerfile

I’ve learned the hard way that Docker builds can become slow if you’re not careful. Here’s a reference Dockerfile I’ve fine-tuned to avoid re-installing dependencies on every build:

# Use the latest Node LTS and Cypress browsers
FROM cypress/browsers:node-22.14.0-chrome-133.0.6943.126-1-ff-135.0.1-edge-133.0.3065.82-1

# Create a non-root user for better security
RUN addgroup --system cypress && adduser --system --ingroup cypress cypress
USER cypress

# Set a working directory
WORKDIR /e2e

# 1. Copy package files first for better caching
COPY package.json package-lock.json ./

# 2. Install dependencies + Cypress
RUN npm ci && npx cypress install

# 3. Copy in only the files you need for tests
COPY cypress/ ./cypress/
COPY cypress.config.js ./

# 4. Verify Cypress is installed properly (catches environment issues ASAP)
RUN npx cypress verify

# 5. Default command to run tests
CMD ["npx", "cypress", "run"]

Why this order?

Docker layers cache each step. By copying package files first and installing, you only rebuild dependencies when package.json changes.
Non-root user is a key security measure.
npm ci is faster and more predictable than npm install (no surprise updates).

Bonus: For advanced setups, consider a multi-stage build to separate your test dependencies from your final runtime image. But this Dockerfile alone should keep your build times snappy.

3. Making Parallelization More Powerful

Parallelizing with Cypress Cloud

If you use the Cypress Cloud, just tag your tests for parallel runs. This is excellent for automatically balancing specs across machines. But what if you don’t have a paid plan?

Parallelizing with Docker-Compose

You can still get your parallel game on using Docker. Here’s a snippet:

docker-compose up --scale cypress=3 --abort-on-container-exit

This spawns three containers, each running Cypress tests in parallel. If any container fails, the entire process fails (which is usually what you want in CI).

Why it’s cool: You can reduce total test time drastically, and it works even if you’re not on the paid Cypress plan. Big test suite? No problem—just spin up more containers and watch your total test time plummet.

4. Security Flex: Harden Your Docker Image

By 2025, DevSecOps isn’t just a buzzword—it’s a necessity. Container security is non-negotiable. Here’s how I lock things down:

Non-Root User: As shown in the Dockerfile above, run processes as a dedicated user (in this case, cypress).
Read-Only Filesystem: For extra lock-down, run your container with --read-only if your tests don’t need to write to the filesystem.
Security Scans: Integrate Docker Scout, Snyk or Trivy in your CI pipeline to catch vulnerabilities in your base image or dependencies.

Example (in compose.yml):

services:
  cypress:
    build: .
    read_only: true
    security_opt:
      - no-new-privileges

Why it’s cool: Show off your DevSecOps chops—everyone loves a stable pipeline that’s also secure.

5. Adding a Cypress Healthcheck for CI Stability

Ever had a test container time out because Cypress wasn’t ready yet? A healthcheck can save you a ton of headaches:

services:
  cypress:
    build: .
    healthcheck:
      test: ["CMD-SHELL", "npx cypress verify || exit 1"]
      interval: 30s
      retries: 3
      start_period: 10s

How it works: Docker checks if Cypress is verified and ready. If not, it retries before marking the container unhealthy.

CI benefits: Your pipeline won’t proceed until tests are actually ready to run, reducing flaky failures.

Putting It All Together in Your CI/CD Pipeline

Define Your Dockerfile: Start from the latest Cypress browsers image, add security measures, and keep the build minimal.
Docker Compose (Optional): If you have multiple services (like web, db, and cypress), keep them in one compose.yml for easy orchestration.
Parallel Strategy: Either use the Cypress Dashboard or Docker’s own --scale feature to run multiple containers simultaneously.
Security Scans: Add a step in your CI (Jenkins, GitHub Actions, GitLab CI, etc.) to run a container vulnerability scan.
Healthchecks: Make sure your containers are up and ready before the rest of the pipeline tries to run tests.

Pro Tip: Embrace ephemeral environments—spin up containers for every pipeline run so you always start from a clean slate.

Final Thoughts: Becoming the Docker + Cypress Superstar

When folks see you’ve got:

A fast, stable Docker-based pipeline,
Parallelized tests that finish in half the time,
A security-hardened container approach, and
Healthchecks to keep things reliable,

they’re going to know you’re the real deal. In 2025, a robust Docker + Cypress setup isn’t just “nice to have”—it’s how modern DevOps teams thrive.

Now that you’ve seen these best practices in action, it’s your turn! Try setting up your own Docker + Cypress pipeline, tweak it for your CI/CD workflow, and experience the boost in speed, stability, and security firsthand. Need a starting point? Check out the official Cypress Docker guide and start containerizing like a pro!

Official Resources to Keep You Sharp

Docker Documentation: For container best practices, security tips, and new features.
Cypress Documentation: For test strategies, debugging tips, and the latest parallelization tricks.
Docker Compose Docs: Essential for orchestrating multi-container environments and scaling test runners.

TL;DR (But Actually, Read the Whole Thing)

Upgrade to Node 22.x (or newer) in your Docker base image for security and performance.
Optimize your Dockerfile (order of COPY, RUN, etc.) to leverage layer caching.
Parallelize using Docker Compose scaling or the Cypress Dashboard.
Harden your containers with non-root users, read-only filesystems, and security scans.
Implement a Healthcheck to avoid flaky container starts.

Follow these tips, and you’ll impress not just your current team but any future colleagues or employers too. And let’s be real—there’s nothing like the look of awe on your teammates’ faces when your pipeline runs quickly, securely, and never breaks for environment-related reasons.

Now go forth and containerize! May your tests be green, your builds be fast, and your Docker images be as secure as Fort Knox.

Choosing Between Docker Swarm and Kubernetes for Container Management

Vladimir Mikhalev — Fri, 16 Aug 2024 20:35:11 +0000

As a Senior DevOps Engineer and Docker Captain, I've accumulated extensive experience with Docker Swarm and Kubernetes. These tools are pillars in the world of container orchestration, crucial for achieving scalability, high availability, and operational efficiency in distributed environments. This article provides a deep dive into their features, differences, and synergies, empowering you to choose the right tool for your infrastructure.

Understanding Docker Swarm

Docker Swarm, originally integrated directly into Docker, transforms a cluster of Docker hosts into a single, virtual host. As of 2019, Docker Swarm has been acquired by Mirantis, which now maintains and supports the tool. This transition is crucial for users to consider, especially those within the Docker ecosystem contemplating Swarm for their orchestration needs.

Key Features of Docker Swarm:

Declarative Configuration and Scaling: Swarm allows you to declare your desired state and scales services accordingly, simplifying application deployment and management.
Rolling Updates: Supports progressive updates with zero downtime, enhancing service continuity.
Networking: Offers simplified networking models that enable easy inter-container communication and built-in load balancing.

For more on Docker Swarm under its new management, visit the Mirantis official documentation on Docker Swarm.

Exploring Kubernetes

Developed by Google, Kubernetes is a robust tool designed to manage complex containerized applications across a variety of environments, perfect for dynamic and large-scale deployments.

Key Features of Kubernetes:

Auto-scaling: Dynamically adjusts container numbers based on demand, optimizing resource use.
Self-healing: Automatically handles the failure of containers or nodes, ensuring minimal service disruption.
Storage Orchestration: Automates storage attachment based on application requirements, supporting a wide array of storage backends.

Explore Kubernetes further on its official site.

Detailed Comparison: Docker Swarm vs. Kubernetes

Networking Capabilities

Docker Swarm: Utilizes a simple overlay network that is easy to configure and manage, supporting basic load balancing.
Kubernetes: Offers a robust networking model, supporting complex networking strategies like network policies for security, and service mesh integration for microservices architectures.

Storage Solutions

Docker Swarm: Provides straightforward volume management, but lacks some of the more advanced features like automatic provisioning.
Kubernetes: Supports dynamic volume provisioning through Persistent Volumes and StorageClasses, catering to a broader range of storage needs and environments.

Security Implementations

Docker Swarm: Offers basic security features such as TLS-based encryption and role-based access control.
Kubernetes: Provides comprehensive security configurations, including robust role-based access control, pod security policies, network policies, and Secrets management.

Integration with Other Tools

Docker Swarm: Integrates well within the Docker ecosystem, making it easier for those already using Docker tools.
Kubernetes: Boasts extensive integration capabilities with major CI/CD tools, monitoring systems like Prometheus, and logging tools like Fluentd, enhancing its adaptability in complex environments.

Future Roadmap and Community Support

Docker Swarm: While still supported, Docker Swarm sees more limited development activity compared to Kubernetes.
Kubernetes: Continues to evolve at a rapid pace, supported by a vast and active community contributing a plethora of plugins and tools.

Selecting the Right Tool

The choice between Docker Swarm and Kubernetes often boils down to your project's complexity and scale:

Docker Swarm is suited for simpler, smaller-scale operations or for those deeply integrated into the Docker ecosystem.
Kubernetes is ideal for complex, large-scale applications requiring advanced resiliency, scalability, and dynamic orchestration.

By understanding each platform's strengths, you can better align your choice with your operational requirements and strategic goals, ensuring your infrastructure not only supports but also enhances your applications.

My Courses

🎓 Dive into my comprehensive IT courses designed for enthusiasts and professionals alike. Whether you're looking to master Docker, conquer Kubernetes, or advance your DevOps skills, my courses provide a structured pathway to enhancing your technical prowess.

My Services

💼 Take a look at my service catalog and find out how we can make your technological life better. Whether it's increasing the efficiency of your IT infrastructure, advancing your career, or expanding your technological horizons — I'm here to help you achieve your goals. From DevOps transformations to building gaming computers — let's make your technology unparalleled!

Refill My Coffee Supplies

💖 PayPal
🏆 Patreon
💎 GitHub
🥤 BuyMeaCoffee
🍪 Ko-fi

Follow Me

🎬 YouTube
🐦 Twitter
🎨 Instagram
🐘 Mastodon
🧵 Threads
🎸 Facebook
🧊 Bluesky
🎥 TikTok
🐈 GitHub

Is this content AI-generated?

Nope! Each article is crafted by me, fueled by a deep passion for Docker and decades of IT expertise. While I employ AI to refine the grammar—ensuring the technical details are conveyed clearly—the insights, strategies, and guidance are purely my own. This approach may occasionally activate AI detectors, but you can be certain that the underlying knowledge and experiences are authentically mine.

Cheburnet as the Fortress of Lies and Censorship in Russia

Vladimir Mikhalev — Mon, 12 Aug 2024 13:31:46 +0000

In 2022, Russia opened a new dark chapter in its history. With the support of a submissive population, authorities not only perpetrated a genocide against the Ukrainian people but also began heroically suffocating the remaining vestiges of free speech within the country.

Each new restriction, whether it was X (formerly known as Twitter), Facebook, Instagram, YouTube, or VPN services, was met with approval by Russians. They not only passively accepted the loss of their rights but also vehemently rejected Western services, condemning them for mythical "sin and depravity". For the Russian orcs, Cheburnet became not just a shield from the world but a fortress of lies, protecting them from the truth.

Each date listed below is not just a mark on the calendar but a brick in the wall of Cheburnet, separating the regime-submissive Russians from the rest of the world.

March 4, 2022 — Russia blocked access to X (formerly known as Twitter) and Facebook, starting a large-scale campaign against platforms that could host critical opinions or information about the invasion of Ukraine.

March 14, 2022 — Instagram was blocked, further reducing Russians' access to global social networks.

August 7, 2022 — The blockage of Patreon limited content creators dependent on international donations.

September 22, 2022 — SoundCloud was blocked, affecting musicians and podcasters.

October 19, 2022 — Metacritic was blocked, limiting access to entertainment content reviews and ratings.

March 1, 2024 — A ban on promoting VPN services, crucial for bypassing internet censorship, was introduced.

April 23, 2024 — The government blocked 150 of the most popular VPN services, significantly hindering the ability to circumvent local internet restrictions.

July 12, 2024 — Ficbook, a popular resource for Russian-language fanfiction, was blocked.

July 16, 2024 — Envato, a major resource for stock photography, video, and music, was blocked.

August 5, 2024 — YouTube was slowed down to a non-functional state, virtually depriving users of access to video content.

August 8, 2024 — Bloggers with more than 10,000 subscribers are required to register with Roskomnadzor and provide personal information.

August 9, 2024 — The messaging app Signal was blocked on charges of violating Russian law, necessary to prevent its use in terrorist and extremist activities.

And yet another chord in the symphony of horror is the new authority of Roskomnadzor. The agency now has the power to control the networks of all internet providers in the country. This means that if a provider fails to comply with content removal demands, Roskomnadzor can take over the network management. Moreover, they can do this without any notification, giving the state agency nearly unlimited possibilities for control and censorship.

DevOps and Platform Engineering Dynamics

Vladimir Mikhalev — Thu, 25 Jul 2024 17:49:37 +0000

As a Senior DevOps Engineer and Docker Captain{:target="_blank"}, my journey through the ever-evolving landscape of software development has afforded me a comprehensive perspective on pivotal trends and methodologies that shape our industry. This article delves into the distinctions and synergies between Platform Engineering and DevOps, exploring their roles, differences, and potential trajectories as we forge ahead into 2024.

DevOps, known for bridging the once sizeable gap between development and operations, emphasizes a collaborative culture and automation to enhance software delivery speed and quality. This methodology facilitates a seamless flow between developing, testing, and deploying software, which accelerates delivery cycles and bolsters system reliability and security through continuous integration and deployment (CI/CD) pipelines and automated monitoring.

Conversely, Platform Engineering emerges as a focused endeavor within the DevOps ecosystem. It involves crafting robust Internal Developer Platforms (IDPs) that provide essential tools and workflows. These platforms enable developers to efficiently initiate, execute, and manage software projects by simplifying access to infrastructure, automating setups, and enforcing security standards through centralized governance.

While both disciplines aim to streamline software development and operations, their approaches and focuses vary significantly:

DevOps is broader, encompassing cultural shifts, process improvements, and tool integration across the entire software lifecycle.
Platform Engineering zeroes in on creating and maintaining scalable and reusable internal platforms that serve as the backbone for developers, enhancing their productivity and focusing on the technical and infrastructural aspects.

In the realm of DevOps, professionals are tasked with developing and refining processes that enhance collaboration and integration between teams, which often involves a mixture of operational and developmental duties. Platform engineers, however, dedicate their expertise to building and optimizing IDPs that directly address developers' needs, reducing the complexity they face and allowing them more freedom to focus on creating innovative software solutions.

Platform Engineering is not merely an extension of DevOps but a strategic evolution that addresses specific challenges within DevOps frameworks by providing structured, service-oriented solutions. It enhances the developer experience through streamlined workflows and self-service capabilities, effectively embodying the concept of "DevOps-as-a-Service."

Adopting the right tools is crucial for fostering an effective DevOps culture and building efficient IDPs. Tools like Spacelift, Backstage, and Argo facilitate the creation and management of infrastructure as code (IaC), supporting both platform engineering and DevOps practices by simplifying the orchestration of software delivery and operations.

The distinction between DevOps and Platform Engineering lies in their respective scopes and objectives. As we continue to navigate these paradigms, it's essential to recognize that both disciplines are not mutually exclusive but are complementary, with each playing a critical role in the broader context of organizational success in software development. By embracing both, organizations can ensure a more holistic approach to continuous improvement and innovation in their software delivery processes.

My Courses

My Services

Refill My Coffee Supplies

💖 PayPal
🏆 Patreon
💎 GitHub
🥤 BuyMeaCoffee
🍪 Ko-fi

Follow Me

🎬 YouTube
🐦 Twitter
🎨 Instagram
🐘 Mastodon
🧵 Threads
🎸 Facebook
🧊 Bluesky
🎥 TikTok
🐈 GitHub

Is this content AI-generated?

Learn Docker CP Command for Effective File Management

Vladimir Mikhalev — Wed, 12 Jun 2024 15:44:57 +0000

Docker remains at the forefront of container technology, offering developers and operations teams alike a robust platform for managing containerized applications. Among the plethora of tools Docker provides, the docker cp command is particularly invaluable for file operations between the host and containers. This detailed guide elucidates the docker cp command, enriching it with practical examples and links to official documentation to aid in your DevOps practices.

Understanding Docker cp

The docker cp command facilitates the transfer of files and directories to and from Docker containers. It mirrors the functionality of the Unix cp command but is tailored for the unique environment of containers. Whether you're handling configurations, logs, or data backups, docker cp ensures that you can efficiently manage files without direct interaction within the container's shell.

Syntax

docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH
docker cp [OPTIONS] SRC_PATH CONTAINER:DEST_PATH

For detailed syntax and options, refer to the Docker documentation here.

When to Use Docker cp

docker cp is essential in several scenarios:

Debugging: Quickly extract logs or configuration files to troubleshoot issues within a container.
Data persistence: Transfer data in/out of containers to ensure that important files are backed up or updated without downtime.
Configuration updates: Modify configuration files on-the-fly by copying new configuration settings into a running container.

However, it is generally advised to use Docker volumes for persistent data storage as modifications through docker cp can be lost when containers are restarted. More on managing Docker volumes can be found here.

Practical Examples

Copying Files into a Container

To copy a local file into a container, you might use:

docker cp /path/to/local/file.txt mycontainer:/path/in/container/file.txt

Extracting Files from a Container

To copy a file from a container to the host:

docker cp mycontainer:/path/in/container/file.txt /path/to/local/file.txt

Inter-Container File Transfer

While docker cp does not support direct file transfers between containers, you can achieve this by copying the file to the host first, then to the destination container:

docker cp sourcecontainer:/file.txt /tmp/file.txt
docker cp /tmp/file.txt destcontainer:/file.txt

Common Pitfalls and Solutions

Permission Issues: Ensure the user has appropriate permissions to access the files.
Path Errors: Verify paths are correct and accessible. Nonexistent paths will halt operations with errors.

Alternatives to docker cp

For continuous file synchronization or when working with dynamic data, consider using bind mounts or Docker volumes. These methods link host directories to container directories, allowing for real-time data continuity and less overhead than repetitive docker cp operations.

docker run -v /host/data:/container/data myimage

This binds the host directory /host/data to /container/data inside the container.

Conclusion

The docker cp command is a powerful tool for file management in Docker environments, critical for tasks ranging from simple backups to complex DevOps workflows. By integrating this tool effectively, you can enhance your container management and operational efficiency.

For more insights into Docker commands and best practices, explore the Docker official documentation here.

My Courses

My Services

Refill My Coffee Supplies

💖 PayPal
🏆 Patreon
💎 GitHub
🥤 BuyMeaCoffee
🍪 Ko-fi

Follow Me

🎬 YouTube
🐦 Twitter
🎨 Instagram
🐘 Mastodon
🧵 Threads
🎸 Facebook
🧊 Bluesky
🎥 TikTok
🐈 GitHub

Is this content AI-generated?

The Fates of Famous Figures Under the Pressure of Power from the Russian Empire to Our Days

Vladimir Mikhalev — Fri, 07 Jun 2024 20:36:45 +0000

In the history of Russia, many outstanding artists and public figures have faced repression and were forced to emigrate because of their views and creativity, which contradicted the official line of power. In our time, the situation has changed little, and many modern oppositionists and cultural figures continue to face persecution, arrests, and are forced to leave the country. In this article, I have compiled brief biographies of famous personalities who have faced repression and emigration, starting from the times of the Russian Empire and ending with modern Russia. This list is far from complete and, unfortunately, continues to be supplemented with new names.

Alexander Pushkin (1799-1837, Russian Empire) – A poet who faced censorship and governmental pressure. His works, including "Ode to Liberty," displeased Emperor Alexander I, leading to his exile in the southern provinces. Although publication opportunities were limited there, he continued his creative work.

Mikhail Lermontov (1814-1841, Russian Empire) – A poet whose fate was tragically sealed after a duel and his poem "Death of the Poet," dedicated to Pushkin’s death. His open criticism of authority displeased the tsar, resulting in his exile to the Caucasus, where he eventually died in another duel.

Fyodor Dostoevsky (1821-1881, Russian Empire) – A writer sentenced to death for participating in the anti-government Petrashevsky Circle. His sentence was commuted to penal servitude in Siberia, followed by exile and military service, profoundly influencing his work and worldview.

Leo Tolstoy (1828-1910, Russian Empire) – A writer celebrated for his literary works and philosophical views, which led to his excommunication from the church. Tolstoy criticized the church and advocated for his ideas on morality and spirituality, resulting in his exclusion from the religious community.

Ilya Repin (1844-1930, Russian Empire) – An artist who moved to Finland seeking solitude and tranquility for his art amidst the revolutionary turmoil in Russia. His relocation was also motivated by a desire to avoid direct involvement in the political upheavals of the time.

Vaslav Nijinsky (1890-1950, Russian Empire) – A ballet master who left Russia during a time of political instability and revolutionary changes. Emigration proved to be a salvation for his career, though it came with challenges of adapting to new conditions abroad.

Wassily Kandinsky (1866-1944, USSR) – An artist who left Russia due to disagreements with Soviet policies on art. His pursuit of abstractionism was recognized and celebrated in the West, where he was able to fully realize his creative potential.

Dmitry Merezhkovsky (1866-1941, USSR) – A writer who emigrated after the October Revolution, rejecting Bolshevik power and fearing repression for his monarchist and religious views.

Zinaida Gippius (1869-1945, USSR) – A writer and wife of Dmitry Merezhkovsky, she emigrated with him due to their shared disdain for the new Soviet power and fear of repression.

Ivan Bunin (1870-1953, USSR) – A writer who emigrated in 1920, openly opposing communism. He became the first Russian to win the Nobel Prize in Literature in 1933.

Fyodor Chaliapin (1873-1938, USSR) – An opera singer who emigrated due to restrictions in artistic activity and disagreement with the Soviet government's policies on art.

Sergei Rachmaninoff (1873-1943, USSR) – A composer who emigrated after the October Revolution, unwilling to live under the new regime that limited creative freedom and threatened his family.

Nikolai Berdyaev (1874-1948, USSR) – A philosopher exiled from Soviet Russia in 1922 aboard the "Philosophers' Ship" along with other intellectuals whose views did not align with Bolshevik ideology.

Vsevolod Meyerhold (1874-1940, USSR) – A director who was arrested and killed during Stalin's purges. His innovative approach to theater did not meet the ideological requirements of the authorities.

Zinaida Reich (1894-1939, USSR) – An actress and wife of Meyerhold, she was killed during Stalin's purges following the arrest and torture of her husband.

Teffi (Nadezhda Lokhvitskaya) (1872-1952, USSR) – A writer who emigrated after the revolution due to her disagreement with the communist government and fears for her life and creative freedom.

Marc Chagall (1887-1985, USSR) – An artist who emigrated after 1917 because his artwork did not fit within the confines of socialist realism and was not recognized by the new authority.

Nikolai Gumilev (1886-1921, USSR) – A poet executed in the context of political repressions for alleged involvement in an anti-monarchist conspiracy. His death was a significant blow to Russian literature.

Anna Akhmatova (1889-1966, USSR) – A poetess who faced repression and a ban on publications. Her husband and son were arrested, and she was forced to live under constant fear and surveillance.

Osip Mandelstam (1891-1938, USSR) – A poet who was arrested and died in detention under harsh conditions and abuses. His work was deemed anti-Soviet, leading to his arrest.

Sasha Chorny (Alexander Glikberg) (1880-1932, USSR) – A poet who emigrated due to political pressure and the impossibility of freely publishing his works in Soviet Russia. After emigration, he continued his literary activity, but now abroad.

Mikhail Chekhov (1891-1955, Russian Empire) – An actor and director who left the USSR unable to continue his theatrical activity under repressive policies. He moved to the USA, where he became known for his teaching methodologies.

Igor Stravinsky (1882-1971, USSR) – A composer who emigrated after the October Revolution, as his music did not meet the requirements of the new authority and did not fit within the bounds of socialist realism.

Vladimir Nabokov (1899-1977, USSR) – A writer who emigrated due to revolutionary changes that threatened his safety and creative freedom. Nabokov became known for his works written in English, including "Lolita".

Philosophers' Ship (1922) – An event during which the Soviet government expelled more than 160 intellectuals, including Nikolai Berdyaev and Sergei Bulgakov, to rid themselves of dissenters and those whose views did not align with Bolshevik ideology.

Sergei Yesenin (1895-1925, USSR) – A poet who took his own life after conflicts with the authorities and due to pressure related to his literary activities and personal life. His death was a tragedy for Russian literature.

Vladimir Mayakovsky (1893-1930, USSR) – A poet who took his own life influenced by personal and professional crises, as well as pressure from the authorities. His work did not always align with the official party line, complicating his life and work.

Nikolai Vavilov (1887-1943, USSR) – A geneticist-scientist who was arrested and died in detention due to accusations of anti-Soviet activity. His work on plant breeding did not align with the pseudoscientific theories supported by the Soviet leadership.

Solomon Mikhoels (1890-1948, USSR) – An actor and director who was killed as part of an anti-Semitic campaign on Stalin's orders. His murder was disguised as a car accident.

Isaac Babel (1894-1940, USSR) – A writer who was arrested, tortured, and executed on suspicions of espionage and anti-Soviet activity. His works were banned and removed from libraries.

Nikolai Zabolotsky (1903-1958, USSR) – A poet who was sent to a camp for several years for his literary works, which did not meet the ideological standards of Soviet authority.

Alexander Vvedensky (1904-1941, USSR) – A poet who died en route to a camp where he was sent for anti-Soviet activity. His innovative poetic experiments did not align with the official literary line of the party.

Olga Berggolts (1910-1975, USSR) – A poetess who was beaten and lost a child during interrogations by the NKVD. Despite the repression, she became a symbol of the besieged Leningrad and continued her literary activity.

Marina Tsvetaeva (1892-1941, USSR) – A poetess who was exiled and driven to suicide due to the inability to freely publish her works and pressure from the authorities.

Daniil Kharms (1905-1942, USSR) – A writer who died of starvation in a psychiatric hospital after being arrested for anti-Soviet activity. His works were banned during his lifetime and published only posthumously.

Dmitry Likhachev (1906-1999, USSR) – An art historian who was arrested, exiled, and fired from his job for his scientific and literary research, which did not meet the ideological requirements of the Soviet authority.

Yevgeny Schwartz (1896-1958, USSR) – A playwright who faced bans on publications and criticism from the authorities for his satirical works that lampooned bureaucracy and totalitarianism.

Anti-Fascist Committee (1940s, USSR) – A committee whose members were executed during Stalin's purges on charges of anti-Soviet activity and espionage.

Boris Pasternak (1890-1960, USSR) – A writer who faced persecution and bans on publications for his novel "Doctor Zhivago," which was deemed anti-Soviet. Pasternak was forced to decline the Nobel Prize in Literature under pressure from the authorities.

Mikhail Bulgakov – A writer who faced censorship and bans. His works, including "The Master and Margarita," were not published during his lifetime and were recognized as anti-Soviet.

Alexander Solzhenitsyn (1918-2008, USSR) – A writer who was exiled and later forced to emigrate for his works criticizing the Soviet authority and the Gulag. He was stripped of his Soviet citizenship and lived in emigration until 1994.

Yuri Lyubimov (1917-2014, USSR/Russia) – A theatrical director who was stripped of citizenship in 1984 for criticizing the Soviet system. Lyubimov continued his career abroad and returned to Russia only after perestroika.

Andrei Sakharov (1921-1989, USSR) – A physicist and human rights advocate who was exiled for his criticism of Soviet policies and his fight for human rights. He was stripped of all awards and titles but continued his human rights work from exile.

Sergei Dovlatov (1941-1990, USSR) – A writer who emigrated in 1979 due to the impossibility of publishing his works in the Soviet Union. His works, written in emigration, were recognized only after his death.

Grigory Rodchenkov (b. 1958, USSR) – The former head of the Moscow anti-doping laboratory, who emigrated to the USA after exposing the state doping program. His testimony became the basis for investigations and sanctions against Russian sports.

Maria Alekhina (Pussy Riot) (b. 1988, Russia) – An activist and member of the punk group Pussy Riot, who left Russia after persecution for her political actions and criticism of the authorities. She continues her human rights activities in emigration.

Anton Dolin (b. 1976, Russia) – A film critic who moved to Riga due to threats and pressure related to his professional activity and criticism of Russian authorities. Dolin left Russia in 2022 after the start of the war against Ukraine, as his anti-war stance and critical statements elicited negative reactions from the authorities and war supporters.

Artur Smolyaninov (b. 1983, Russia) – An actor who left Russia in 2022 due to his criticism of government policies and the war in Ukraine. Smolyaninov repeatedly spoke out against the Russian government, leading to persecution and threats against him. He continues his professional activity abroad.

Little Big (Russia) – A musical group known for their satirical and provocative videos, left Russia due to disagreement with the political situation in the country and pressure from the authorities. In 2022, the group members emigrated, continuing their music career abroad.

Anastasia Davydova (b. 1983, Russia) – An Olympic champion in synchronized swimming, who left Russia due to political pressure and threats. She moved to another country to continue her sports and coaching career in safer conditions.

Alexander Nevzorov (b. 1958, Russia) – A journalist and publicist, known for his critical statements against Russian authorities and politics. In 2022, Nevzorov left Russia due to threats to his life and persecution for his journalistic activity. He continues his work abroad, actively speaking out against the war in Ukraine and the political regime in Russia.

Yevgeny Berkovich and Svetlana Petriychuk (b. 1984 and 1985, Russia) – Arrested for staging a theatrical play, which was perceived by the authorities as propaganda of extremism and an insult to the feelings of believers. This was part of a broader campaign to suppress freedom of creativity and critical statements in Russia.

Boris Akunin (Grigory Chkhartishvili) (b. 1956, Russia) – A writer against whom a criminal case was initiated for his critical statements and support for opposition movements. Akunin left Russia, fearing arrest and persecution, and continues his literary activity abroad.

Vasily Berezin and Stas Falkov (Russia) – Artists who founded a collective of exiled Russian artists in Paris. They left Russia due to pressure on freedom of creativity and threats from the authorities. Their works often had a political character and criticized contemporary Russian society and politics.

Alexei Navalny (1976-2024, Russia) – An opposition politician who died in custody in 2024. His death is widely regarded as murder linked to his political activity and fight against corruption in Russia. Navalny was known for his anti-corruption investigations and active opposition activity, for which he was repeatedly arrested and repressed.

Memorial (Russia) – A human rights organization that was liquidated in 2021. Memorial was engaged in investigating and documenting political repressions in the Soviet Union and modern Russia, as well as protecting human rights. The organization was recognized as a "foreign agent" and subjected to pressure from the authorities, leading to its closure.

Oleg Orlov (b. 1953, Russia) – The head of the human rights organization "Memorial," sentenced to 2.5 years in a colony. Orlov was accused of discrediting the Armed Forces of the Russian Federation, in the context of the ongoing campaign against human rights defenders and their activities.

Dmitry Muratov (b. 1961, Russia) – A journalist, Nobel Peace Prize laureate, who was attacked in 2022. Muratov, the chief editor of "Novaya Gazeta," repeatedly received threats and faced pressure due to publications criticizing the actions of Russian authorities and corruption.

TV Channel "Dozhd" (Russia) – An independent TV channel forced to cease broadcasting in Russia in 2022 due to pressure from the authorities. "Dozhd" is known for its objective and critical reports on political and social issues in Russia. After ceasing broadcasting in Russia, the channel continued its work abroad.

Dmitry Ivanov (Kamikadze Di) (b. 1986, Russia) – A blogger and journalist, known for his sharp and critical performances against the Russian government. Ivanov was attacked, which forced him to move to the Czech Republic. He continues to actively spread information about the political situation in Russia.

Vladimir Kara-Murza (b. 1981, Russia) – An opposition politician and journalist, known for his active anti-government performances. Kara-Murza was repeatedly poisoned, presumably due to his political activity. He was sentenced to 25 years in prison for criticizing Russia's military actions in Ukraine and ties with an "undesirable" organization. In May 2023, the court rejected his appeal, leaving the sentence unchanged. Kara-Murza also suffers from polyneuropathy, a condition that has worsened in prison conditions.

Mark Feigin (b. 1971, Russia) – A lawyer and human rights defender who emigrated to France. He gained wide recognition for defending politically persecuted individuals, including members of the group "Pussy Riot" and Ukrainian journalists. Due to his professional activity and criticism of the Russian government, Feigin was subjected to pressure and was declared wanted in 2023.

Ilya Yashin (b. 1983, Russia) – A politician and activist, one of the leaders of the Russian opposition, known for his criticism of the authorities. In 2022, Yashin was arrested and sentenced to 8.5 years for disseminating "false" data about Russia's actions in Ukraine.

Artem Kamardin (b. 1990, Russia) – A poet sentenced by the Tverskoy Court of Moscow to 7 years of imprisonment for reading poems against military actions of Russia in Ukraine.

Yegor Shtovba (b. 2000, Russia) – An accomplice in the literary reading of Artem Kamardin, sentenced by the Tverskoy Court of Moscow to 5.5 years of imprisonment. He was accused of disseminating "false" data about military actions of Russia in Ukraine, as part of the same judicial campaign against freedom of speech.

Mail Naki (b. 1993, Russia) – An artist and public activist, known for his anti-war performances and criticism of the authorities. Due to his position and public actions, he was subjected to pressure and threats from the state, which forced him to leave Russia and continue his activities abroad.

Maxim Galkin (b. 1976, Russia) – A humorist and TV presenter, who left Russia in 2022 after being recognized as a "foreign agent" for criticizing the Russian government and the war in Ukraine. Galkin continues his professional activity abroad, actively speaking out against the war.

Alla Pugacheva (b. 1949, Russia) – A singer and actress, who left Russia in 2022 due to disagreement with government policies and the start of military actions in Ukraine. Pugacheva openly supported her husband Maxim Galkin, who was recognized as a "foreign agent". She moved to Israel and continues her activity abroad.

Group "Nogu Svelo!" – A Russian rock group, whose leader Maxim Pokrovsky left Russia in 2022 due to disagreement with government policies and the war in Ukraine. The group continues its activity abroad, actively speaking out against the war and supporting anti-war actions.

Group "Bi-2" – A Russian rock group, whose members were subjected to pressure from the authorities for their political views. In 2022, the group was forced to cancel its concerts in Russia and partially emigrated, continuing their musical activity abroad.

Vitaly Mansky (b. 1963, Russia) – A documentary filmmaker who left Russia in 2014 and moved to Riga, Latvia. Mansky is known for his critical films, often focusing on political and social issues. In 2014, he initiated the signing of the open letter "We are with You!" in support of Ukrainian filmmakers against the Russian military intervention in Ukraine. In 2022, he spoke out against Russia's invasion of Ukraine and was declared wanted by the Russian Ministry of Internal Affairs on charges of defamation. In 2023, the Russian Ministry of Justice included him in the list of foreign agents. Mansky continues to actively work in the field of documentary cinema abroad, organizing the Artdocfest/Riga festival and receiving recognition for his films at international film festivals.

Mastering GitLab CI/CD with Advanced Configuration Techniques

Vladimir Mikhalev — Fri, 07 Jun 2024 20:33:29 +0000

As a Senior DevOps Engineer and a recognized Docker Captain, I understand the pivotal role that continuous integration and delivery (CI/CD) systems play in modern software development. GitLab's CI/CD platform is a robust tool that automates the steps in software delivery processes, ensuring that you can deploy applications swiftly and reliably.

Understanding ".gitlab-ci.yml"

The .gitlab-ci.yml file is the backbone of GitLab’s CI/CD service. Located in the root directory of your repository, this YAML file defines the pipeline's configuration. Each push and merge request automatically triggers these pipelines, executed by GitLab Runner. Here’s how to leverage this powerful feature to its full potential.

Key Configuration Elements

The .gitlab-ci.yml file orchestrates your CI/CD pipeline's workflow. Understanding its structure is key to harnessing GitLab’s automation capabilities:

Stages and Jobs: Stages define the sequence of actions in your pipeline and are executed in the order they appear. Jobs within each stage run concurrently, boosting efficiency.
Scripts: The actual commands your pipeline executes. These can range from build commands to test scripts.
Docker Integration: As a Docker Captain, I frequently use Docker images to standardize environments across the CI/CD pipeline. Specifying an image ensures all jobs run in a consistent environment.

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script: echo "Building the project..."

test_job:
  stage: test
  script: echo "Running tests..."

deploy_job:
  stage: deploy
  script: echo "Deploying the project..."

Advanced Features

Artifacts and Caching: Artifacts are files generated by jobs and retained after they complete, such as logs or compiled applications. Caching speeds up building processes by reusing unchanged parts of your environment.

cache:
  paths:
    - node_modules/

build_job:
  stage: build
  script: npm install && npm run build
  artifacts:
    paths:
      - build/

Best Practices and Tips

Modular Configuration: For complex systems, break down your configuration into multiple files using the include keyword. This makes managing large projects easier and your configurations clearer.

include:
  - local: 'path/to/another-file.yml'
  - project: 'group/project-name'
    file: '/templates/.gitlab-ci-template.yml'

Using include, you can maintain a cleaner and more organized configuration by referencing other files, whether they are in the same repository, a different project, or even a remote URL.

Security Practices: Keep sensitive data like passwords or API keys in GitLab's environment variables, not in your .gitlab-ci.yml file.

variables:
  PROD_DB_PASSWORD: $PROD_DB_PASSWORD

Manage these variables securely through GitLab's UI at the project, group, or instance level. This approach ensures that sensitive information is not exposed in your version control.

Integrating Advanced GitLab CI/CD Techniques

Enhance your CI/CD pipelines by incorporating more advanced GitLab functionalities:

before_script and after_script: Prepare the environment before your main script runs and clean up afterwards.

test_job:
  stage: test
  before_script:
    - echo "Setting up test environment"
  script:
    - npm test
  after_script:
    - echo "Cleaning up after tests"

Dynamic Environment Management: Dynamically set and modify environment conditions based on the job context, enhancing flexibility across multiple environments.

deploy_job:
  stage: deploy
  variables:
    DEPLOY_ENV: "production"
  script:
    - if [ "$DEPLOY_ENV" == "production" ]; then deploy_to_production; else deploy_to_staging; fi

Using "rules" for Conditional Job Execution: Customize job execution based on complex conditions, such as changes to specific files or the status of previous tasks.

cleanup_job:
  stage: cleanup
  script: cleanup_resources
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: always
    - if: '$CI_PIPELINE_SOURCE == "push"'
      when: never

Efficient Management of Artifacts and Caches: Fine-tune your pipeline performance by effectively managing build artifacts and leveraging caching mechanisms.

build_job:
  stage: build
  script: build_application
  artifacts:
    paths:
      - output/
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/

Continuous Learning

The landscape of DevOps tools and practices is constantly evolving. As a Docker Captain, I keep abreast of these changes through continuous learning and experimentation. Embracing new tools like GitLab’s CI/CD allows us to refine our deployment strategies and improve automation. For more detailed instructions and advanced configurations, refer to the official GitLab CI/CD documentation.

My Courses

My Services

Refill My Coffee Supplies

💖 PayPal
🏆 Patreon
💎 GitHub
🥤 BuyMeaCoffee
🍪 Ko-fi

Follow Me

🎬 YouTube
🐦 Twitter
🎨 Instagram
🐘 Mastodon
🧵 Threads
🎸 Facebook
🧊 Bluesky
🎥 TikTok
🐈 GitHub

Is this content AI-generated?

The 80th Anniversary of the Deportation of the Crimean Tatars

Vladimir Mikhalev — Fri, 31 May 2024 14:16:54 +0000

May 18 marks the remembrance day of one of Stalin’s and the Soviet regime's most brutal crimes — the deportation of the Crimean Tatars.

The deportation operation began early on the morning of May 18, 1944, and concluded on the evening of May 20. It was the beginning of a cruel and inhumane operation carried out by the NKVD, which left an indelible scar in the history of the Crimean Tatar people. Residents were given just a few minutes to gather their belongings before being loaded into overcrowded cattle cars.

Those who refused to leave, resisted, or simply could not move were shot on the spot. Witnesses tell of bodies lying in the streets and courtyards, of screams and pleas for mercy that went unanswered. The conditions in the wagons were unbearable with overcrowding and lack of sanitation. People suffocated, died of dehydration, and lacked medical assistance, suffering from heat and suffocation. Mothers gave birth and lost their babies right before the eyes of other prisoners, and the dead were thrown directly onto the railway tracks.

About 200,000 people were sent to forced labor in Asian republics and Siberia. Upon arrival at their destinations, they faced not life, but a slow demise. Half of those who survived the hellish journey died in the first year of resettlement from hunger, cold, and unbearable working conditions. Many died from infections spread in overcrowded barracks. People were forced to work to exhaustion, often without clothing or footwear in the bitter cold.

This tragedy serves as a reminder that behind the facade of the "happy" life of the Soviet Union, which many now perceive as a time of stability and prosperity, lies the suffering and death of thousands of innocent people. Stalin's totalitarian regime turned the lives of millions into an endless nightmare filled with horror and bloody crimes.

Contemporary Impact and Ongoing History

As highlighted in the statement by the Canadian Minister of Foreign Affairs, Mélanie Joly, the tragedy of the Crimean Tatars finds parallels in Russia's actions in Crimea following its illegal annexation in 2014. Russian authorities continue policies of infringing upon the rights of the Crimean Tatars, destroying their cultural heritage, replacing historical names, and persecuting those who oppose the annexation. Canada and the international community recognize these actions as a continuation of the policy of repression and support Ukraine's sovereignty and territorial integrity in response to ongoing aggression.

Additional Resources for Study

📕 Article on the deportation of the Crimean Tatars on English Wikipedia
📕 Statement by the Minister of Foreign Affairs of Canada on the 80th anniversary of the deportation of the Crimean Tatars
📕 Official statement by the Government of Norway on the 80th anniversary of the deportation of the Crimean Tatars

Stand with Ukraine

Vladimir Mikhalev — Thu, 30 May 2024 20:12:27 +0000

My blog has gone beyond just providing IT guides and advice. Today, we stand as a voice against the lies and injustices that have engulfed our world due to the merciless actions of the bloody Russian regime.

Freedom of speech in Russia exists mostly in theory, not in practice. The reality is that finding reliable information in Russian-language open sources is quite difficult. Most media in Russia provide information that often passes through the filter of state propaganda and reflects the interests of the political leadership.

Nevertheless, everyone has access to important information from verified sources.

The State Emergency Service continues to deal with the aftermath of Russia’s massive missile attack on Ukraine on January 2, 2024. Photo from State Emergency Service of Ukraine

As the founder and chief editor, I not only condemn but also express deep contempt for the Russian military invasion of Ukraine. This act is a blatant war crime that has already claimed hundreds of thousands of lives, including children. Responsibility lies not only with the Russian government and President Vladimir Putin personally but also with the citizens of Russia, whose political indifference and inaction ultimately led to another war.

Examples from the past, when Russians could more freely express their opinions, highlight the contrast with the current situation. For example, in 2006, human rights activist Lev Ponomarev was arrested and detained for three days after organizing a picket in Moscow, but such actions were then considered relatively mild.

In subsequent years, the situation has changed drastically. Legislation has tightened the requirements for conducting protests, significantly increased fines, and introduced criminal liability for repeated violations of the law on rallies. Since 2014, nine of the thirteen significant amendments to the law have been introduced, aimed at limiting the right to peaceful assemblies. These legislative changes have led to the fact that peaceful street protests in the eyes of the authorities have come to be seen as a crime, and an act of heroism for those Russians who still believe it is their right to exercise it.

Cases such as mass arrests of participants in peaceful protests, often accompanied by brutal treatment by the police, have become commonplace. The lack of response from the authorities to cases of excessive use of force by the police, such as in January 2021, only reinforces the atmosphere of impunity.

These examples emphasize how in the past, when the conditions for protests were less strict, Russian society had greater opportunities to express their disagreement with the actions of the authorities without fear of serious consequences. This highlights the importance of political activism and the ability to change public and political situations through peaceful demonstrations and protests.

These links provide more detailed information on the development and change in the legal regulation of protest activities in Russia:

Since 1991, modern Russia has participated in several military conflicts. Some of the key wars include:

First Chechen War (1994–1996)
Second Chechen War (1999–2009)
Russo-Georgian War (2008)
Annexation of Crimea and intervention in Ukraine (since 2014)
Military intervention in Syria (since 2015)
Invasion of Ukraine (since 2022)

More detailed information about these and other military conflicts can be found here.

Two Ukrainian soldiers walk along the frontline city of Avdiivka in the Donetsk region. It is one of the hotspots nowadays after Russia launched a major offensive in mid-October 2023. Photo by Kostiantyn Liberov & Vlada Liberova / Getty Images

We stand at a historic moment, and I urge you, our readers, to join the ranks of those who oppose this violence. Your actions in support of Ukraine are of immense importance. Whether it’s financial assistance, supporting refugees, providing asylum, or resources, every step you take contributes to thefight for peace and humanity in these tragic times. I believe that our solidarity and determination can overcome cruelty and lawlessness.

A man with a bicycle goes through the city during a break between Russian shellings in the frontline Avdiivka, the Donetsk region. October 17, 2023. Photo by Ozge Elif Kizil / Anadolu Agency / Getty Images

To assist the people of Ukraine, you can use the following official and verified resources:

UNITED24: This is the official platform for collecting charitable donations to support Ukraine, launched by the President of Ukraine, Volodymyr Zelenskyy. Here you can direct funds to defense, humanitarian demining, medical assistance, reconstruction of Ukraine, as well as education and science.
EU Solidarity with Ukraine: This European Union initiative provides information on how to help Ukrainians who have fled the war or stayed in Ukraine. The website lists various organizations, including major international agencies and charitable organizations, providing assistance on the ground.
UNICEF assistance to Ukraine: This international organization urgently needs funds to assist children and their families in Ukraine. UNICEF provides assistance in safe water supply, healthcare, education, and protection.

These resources will help you direct aid where it is most needed, and ensure that your contribution is used effectively and transparently.

Artem, a serviceman of the infantry battalion of the 61st Mechanised Brigade, pets a dog in a trench at a position near the frontline in the Kharkiv region. Photo by Sofia Gatilova / Reuters

View more photos of the war in Ukraine.

Fight and you shall overcome!

God helps you!

With you are truth, glory

And holy freedom!

Taras Shevchenko, “Caucasus”, 1859

In Ukrainian:

Борітеся — поборете!

Вам Бог помагає!

За вас правда, за вас слава

І воля святая!

Тарас Шевченко, "Кавказ", 1859

Mastering Terraform Contains and Strcontains Functions

Vladimir Mikhalev — Thu, 30 May 2024 15:39:56 +0000

As a Senior DevOps Engineer and Docker Captain, I'd like to delve into the functionalities of Terraform's contains and strcontains functions. These tools are indispensable for crafting dynamic infrastructures and offer a fine-tuned approach to managing your resources efficiently.

Understanding the Terraform "contains" Function

The contains function in Terraform is a collection-based utility designed to ascertain whether a specific value exists within a given list or set. The function is straightforward; it returns true if the specified value is found, and false if it is not.

Here’s the syntax for the contains function:

contains(list, value)

list: This parameter represents the list, map, or set that you are searching within.
value: This is the value you are looking for in the specified list or set.

For a comprehensive understanding, refer to the official Terraform documentation on functions.

Practical Examples of "contains"

Consider a scenario where you need to verify the presence of a virtual machine size in a specific Azure region before deployment:

variable "region" {
  description = "Azure region"
  type        = string
  default     = "uksouth"
}

variable "vm_size" {
  description = "VM size"
  type        = string
  default     = "Standard_DS2_v2"
}

data "azurarm_virtual_machine_sizes" "example" {
  location = var.region
}

output "vm_size_supported" {
  value = contains(data.azurerm_virtual_machine_sizes.example.sizes, var.vm_size)
}

This example demonstrates how contains can be effectively used to prevent deployment errors by ensuring the necessary resources are available in the specified region.

Exploring the Terrafront "strcontains" Function

Moving on to string operations, the strcontains function checks for the presence of a substring within a given string, proving especially useful in parsing and conditional logic based on textual data.

Here’s how you define it:

strcontains(string, substr)

string: The main string in which to search for the substring.
substr: The substring you're trying to find within the main string.

Example Usage of "strcontains"

Suppose you want to check if a particular configuration tag is part of a server's setup:

strcontains("us-east-1b-optimal", "optimal")

This would return true, indicating that the "optimal" configuration is indeed a part of the server's setup description.

Conclusion

Both contains and strcontains are vital in a Terraform practitioner’s toolkit, facilitating precise control and checks within infrastructure code. They empower you to implement complex logic based on the data structure and string content dynamically.

Moreover, as the landscape of Terraform evolves, it's crucial to stay updated with the latest practices and community-driven alternatives like OpenTofu, which continue to push the boundaries of what's possible with open-source infrastructure as code tools. Visit OpenTofu’s website for more details on their offerings.

My Courses

My Services

Refill My Coffee Supplies

💖 PayPal
🏆 Patreon
💎 GitHub
🥤 BuyMeaCoffee
🍪 Ko-fi

Follow Me

🎬 YouTube
🐦 Twitter
🎨 Instagram
🐘 Mastodon
🧵 Threads
🎸 Facebook
🧊 Bluesky
🎥 TikTok
🐈 GitHub