VALDEMAR

watsonx.governance Enforcement Tracking — Sampled Compliance and the Unevidenced Run

Vladimir Mikhalev (heyvaldemar.com) — Mon, 24 Aug 2026 00:00:00 GMT

Sixteen months. That is how far Regulation (EU) 2026/1744 moved the AI Act's high-risk deadline when it entered into force on 27 July 2026, pushing standalone Annex III obligations from 2 August 2026 out to 2 December 2027. The deferral moved the deadline. It did not move the record, and sampled compliance is the shape of what is left: governance evidence collected in windows, agent behavior that runs without one. I reviewed the configuration and the evidence model for IBM watsonx.governance Enforcement Tracking, which shipped on 11 August 2026, against the question an auditor actually asks.

This failure shape is older than agents. In banking it was hourly configuration snapshots, and the snapshot became the definition of what the configuration was, because nothing between snapshots existed on paper. In telecom it was a five-minute polling interval on the network management system, and every incident timeline quietly rounded to five minutes. The interval always wins. When the interval is the only record, the interval becomes the truth, and everything between two samples becomes testimony instead of artifact. I wrote about the same gap on the infrastructure side in the Apply Gate your auditor will ask about.

What sampled compliance looks like in a running agent

Here is how most teams ship a containerized agent today.

# kubernetes 1.30 — claims-triage agent as most teams ship it
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-triage-agent
spec:
  replicas: 3
  selector:
    matchLabels:
      app: claims-triage-agent
  template:
    metadata:
      labels:
        app: claims-triage-agent
    spec:
      containers:
        - name: agent
          image: registry.internal/claims-triage-agent:1.4.2
          env:
            - name: ORCHESTRATE_ENDPOINT
              valueFrom:
                secretKeyRef:
                  name: wxo-credentials
                  key: endpoint

Nothing on that manifest connects a single execution to a governance record. The agent runs, it writes to stdout, and the only durable statement about its behavior is whatever the evaluation schedule captured. Ask for run 4192 and you get a shrug and a log query against whatever retention the cluster happens to have.

The change is small and it is structural.

# kubernetes 1.30 — same agent, every execution addressable
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-triage-agent
  labels:
    ai.use-case-id: uc-claims-triage-eu
    ai.policy-version: "2026.08.1"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: claims-triage-agent
  template:
    metadata:
      labels:
        app: claims-triage-agent
        ai.use-case-id: uc-claims-triage-eu
        ai.policy-version: "2026.08.1"
    spec:
      containers:
        - name: agent
          image: registry.internal/claims-triage-agent:1.4.2
          env:
            - name: ORCHESTRATE_ENDPOINT
              valueFrom:
                secretKeyRef:
                  name: wxo-credentials
                  key: endpoint
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: http://otel-collector.observability:4317
            - name: OTEL_RESOURCE_ATTRIBUTES
              value: ai.use_case.id=uc-claims-triage-eu,ai.policy.version=2026.08.1

Two additions. The workload now carries the same use-case identifier the governance system uses, and every execution emits a span under that identifier with the policy version that was live at the time. You are not storing prompts or outputs. You are storing the fact that a run occurred, under which policy, touching which tools. That is the join key, and without it the two systems can never be reconciled at all.

Twenty years of production infrastructure and this pattern has arrived in three different decades of stack: snapshot intervals in banking, SNMP polling in telecom, and a change-management record sampling a pipeline that fired hundreds of times a day in a Series D environment. Each time the fix was the same and each time it looked like overhead until the first audit.

The interval is the record. Everything between two samples is a story.

Why this keeps happening

The regulation asks for two different things and vendors ship the easier one first, because it is the one with a clean product surface.

Article 12 of the AI Act requires high-risk systems to automatically record events across the lifetime of the system, with three stated purposes: identifying risk situations under Article 79, feeding post-market monitoring under Article 72, and supporting deployer oversight under Article 26, paragraph 5. Article 19 sets the retention floor for providers at six months, longer where other Union or national law applies, and Article 26, paragraph 6 places a parallel six-month duty on deployers for the logs under their control. Article 18 puts technical documentation on a ten-year clock. None of those clauses describes a threshold check. They describe a per-event record with a retention obligation attached.

Enforcement Tracking, per IBM's announcement of 11 August 2026, connects watsonx Orchestrate to watsonx.governance, associates agents with governance use cases and controls, retrieves evaluation metrics on a scheduled basis for production agents, evaluates agents still in development on demand, and writes pass or breach results against business-set thresholds directly into the governance record. Hallucination, helpfulness and toxicity are the named metrics. That is a control attestation pipeline, automated, and it removes the quarterly scramble of assembling evidence by hand.

The second thing is harder to productize because it is specific to your deployment. A vendor cannot know your correlation identifier, your policy versioning scheme, or which of your systems holds the execution ledger. So it stays where it has always stayed. The vendor shipped the evidence pipeline. The join key is still yours.

Risk and blast radius

Direct exposure runs through retention and traceability rather than through the metrics themselves. If your agent falls inside Annex III, the Article 12 record has to exist and the Article 19 and Article 26, paragraph 6 floors mean six months of it has to still be there when someone asks. A threshold snapshot taken on a schedule does not satisfy a per-event recording obligation, and no amount of dashboard polish converts one into the other. Penalty tiers under the Act put transparency and high-risk breaches at up to 15 million euro or 3% of worldwide turnover, with prohibited practices at 35 million euro or 7%.

Read what the deferral actually deferred, because the headline flattens it. Annex III systems moved to 2 December 2027 and high-risk AI embedded in already-regulated products under Annex I moved to 2 August 2028. Article 50 transparency duties did not move at all; they took effect on 2 August 2026 as originally scheduled, alongside the prohibited-practices regime that has applied since February 2025 and the GPAI obligations running since August 2025. The Omnibus attached one new near-term date to them: systems already on the market before 2 August 2026 have until 2 December 2026 to carry machine-readable marking of AI-generated content. Sixteen months of relief on Annex III. Fourteen weeks on the marking obligation. And the stated reason for the delay was procedural rather than political: the CEN and CENELEC harmonised standards were not finished and several Member States had not designated their competent authorities. A deadline that moved because the referee was late is not a signal that the rules got softer.

Systemic exposure is the part the deferral headline hides. Systems already placed on the EU market before the new deadlines are grandfathered out of full high-risk compliance unless they are later substantially modified, and regulators have not yet defined that threshold. For an agent that reasons over changing context, calls tools dynamically, and gets its prompts and models updated on a normal release cadence, "substantially modified" is not a rhetorical question. It is an evidentiary one, and answering it requires a change record joined to an execution record. Sampling cannot produce that answer in either direction.

Before assuming Article 26, paragraph 6 is your ceiling, check which side of Article 25 you are standing on. A deployer who puts their own name or trademark on a high-risk system, or substantially modifies one already placed on the market, is treated as its provider. Assemble agents on a vendor platform, ship them under your own brand, and the provider obligations follow: the Article 12 recording capability and the Article 19 retention floor, not merely the deployer's duty to keep whatever the platform hands you. The original provider is relieved of them at that moment and owes you cooperation instead. The platform did not transfer the obligation. It transferred the role.

Then the arithmetic. An agent invoked every five minutes executes 288 times a day, or 8,640 times over thirty days. Against a daily metrics synchronisation, that month closes with 30 evidence records covering 8,640 executions, or 0.35% of runs individually evidenced. Tighten the schedule to hourly and you get 720 records against 8,640 runs, which is 8.3%. The schedule is the right design for attesting a control. It is the wrong artifact for reconstructing an incident.

A deferral you cannot document is not a deferral.

Options compared

Storage figures below are back-of-envelope from stated unit sizes, not measured: trace metadata at about 1.5 KB per span, full payload capture at about 1 MB per run average for a tool-calling agent, hash digest at about 150 bytes.

Approach	Evidence granularity	Storage per 1M runs	Question it answers at audit	Fit
Scheduled enforcement tracking (watsonx.governance)	One record per evaluation window	Under 10 MB	Were thresholds met at time T	Control attestation. Required baseline, not the event record
Per-execution trace metadata (OpenTelemetry)	One span per run, no payload	~1.5 GB	Did run X occur, when, under which policy, touching which tools	The reconciliation layer. Cheapest path to Article 12 traceability
Full request and response archival	Every prompt and output	~1 TB	What exactly did the agent say and do	Highest fidelity, highest GDPR and cost exposure
Sampled payload capture (1% plus all breaches)	Statistical, full on breach	~15 GB	What does a normal run look like, plus every bad one in full	Pragmatic middle for non-regulated estates
Hash-chained execution digest	One signed digest per run	~150 MB	Has the record been altered since it was written	Tamper-evidence for regulated or contested estates

Most teams need rows one and two together. Row one without row two is a control with no event behind it.

Framework: reconciling the execution ledger with the evidence ledger

Layer 1: use-case binding and execution inventory (week 1)

Start inside watsonx.governance, because that is where the identifier everything else joins to gets defined. Connect the watsonx Orchestrate instance, associate each agent with the AI use case and the controls it has to satisfy, and set the thresholds the business is prepared to defend in front of an auditor.

Two options in that configuration change what the control is worth, and both are easy to leave on their defaults. Agents still in development can be evaluated on demand before they ship, which moves a threshold breach from the first production window back to build time. And a metric that crosses its limit can drive an automated workflow rather than only writing a result into the record. Turn both on. A control that pages someone beats a control that files something.

That is the attestation half, and it is the half a vendor can ship for you. The other half is the identifier itself. Most organizations cannot yet say how many agents are running at all, which is the prerequisite problem behind Agent Sprawl. Give every run an identity carrying the same use-case id watsonx.governance now knows it by: one span per execution, three attributes that matter, no payload.

# opentelemetry-sdk 1.x — one span per agent execution, carrying the governance join key
from opentelemetry import trace

tracer = trace.get_tracer("wxo.agent.claims_triage")

def run_agent(request, ai_use_case_id: str, policy_version: str):
    with tracer.start_as_current_span("agent.execution") as span:
        span.set_attribute("ai.use_case.id", ai_use_case_id)
        span.set_attribute("ai.policy.version", policy_version)
        span.set_attribute("ai.agent.id", "claims-triage")
        result = agent.invoke(request)
        span.set_attribute("ai.tools.invoked", ",".join(result.tool_calls))
        span.set_attribute("ai.outcome", result.status)
        return result

Ship spans to an OpenTelemetry Collector and land them in a store you control, with retention set to your longest applicable obligation rather than your default. Six months is the AI Act floor. Financial services deployers answer to their own regime under Article 26, paragraph 6, measured in years. Set it at your ceiling now. Raising retention later does not recover what already aged out.

Owner: AI governance lead for the watsonx.governance binding, platform engineer for the spans.

Layer 2: policy binding (week 2)

The join key belongs in infrastructure, not in a runbook. Terraform tags the agent's execution role with the same use-case identifier the governance system uses, and a permissions boundary states the blast radius as code.

# terraform 1.x, aws provider 5.x — bound the agent's execution role, carry the governance join key
resource "aws_iam_role" "agent_execution" {
  name                 = "wxo-agent-claims-triage"
  permissions_boundary = aws_iam_policy.agent_boundary.arn
  assume_role_policy   = data.aws_iam_policy_document.agent_trust.json

  tags = {
    ai_use_case_id = var.ai_use_case_id # same key on every span and every evidence record
    policy_version = var.policy_version
  }
}

resource "aws_iam_policy" "agent_boundary" {
  name   = "wxo-agent-boundary"
  policy = data.aws_iam_policy_document.agent_boundary.json
}

data "aws_iam_policy_document" "agent_trust" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRoleWithWebIdentity"]

    principals {
      type        = "Federated"
      identifiers = [var.oidc_provider_arn]
    }

    condition {
      test     = "StringEquals"
      variable = "${var.oidc_provider_host}:sub"
      values   = ["system:serviceaccount:default:claims-triage-agent"]
    }
  }
}

variable "ai_use_case_id" { type = string }
variable "policy_version" { type = string }
variable "oidc_provider_arn" { type = string }
variable "oidc_provider_host" { type = string }

data "aws_iam_policy_document" "agent_boundary" {
  statement {
    effect    = "Allow"
    actions   = ["s3:GetObject"]
    resources = ["arn:aws:s3:::claims-reference/*"]
  }

  statement {
    effect    = "Deny"
    actions   = ["iam:*", "sts:AssumeRole"]
    resources = ["*"]
  }
}

If the estate runs HCP Terraform or Terraform Enterprise, gate the plan before the apply. Sentinel reads the plan directly, so a role provisioned without the governance tag never reaches state.

# sentinel policy — refuse a plan that provisions an agent role with no governance use case
import "tfplan/v2" as tfplan

required_tag = "ai_use_case_id"

agent_roles = filter tfplan.resource_changes as _, rc {
	rc.type is "aws_iam_role" and
		rc.mode is "managed" and
		(rc.change.actions contains "create" or rc.change.actions contains "update")
}

main = rule {
	all agent_roles as _, rc {
		rc.change.after.tags[required_tag] else "" is not ""
	}
}

That catches the resource at provision time. The second gate catches the workload at admission time, because a correctly tagged role says nothing about whether the pod that assumes it emits anything.

# opa 1.x / conftest — block agent deploys that cannot be joined to a governance use case
package agent.evidence

deny contains msg if {
	input.kind == "Deployment"
	not input.metadata.labels["ai.use-case-id"]
	msg := "missing ai.use-case-id label: runs cannot be joined to governance evidence"
}

deny contains msg if {
	input.kind == "Deployment"
	some c in input.spec.template.spec.containers
	not otlp_configured(c)
	msg := sprintf("container %q has no OTEL_EXPORTER_OTLP_ENDPOINT: executions will not be recorded", [c.name])
}

otlp_configured(c) if {
	some e in c.env
	e.name == "OTEL_EXPORTER_OTLP_ENDPOINT"
}

Owner: security engineer.

Layer 3: reconciled audit (week 3 onward)

Two ledgers, one key, one number that tells you whether the record has holes in it.

# prometheus 2.x — alert when agent runs have no matching governance evidence record
groups:
  - name: agent-evidence-coverage
    interval: 5m
    rules:
      - record: agent:runs_unevidenced:ratio1h
        expr: |
          1 - (
            sum by (ai_use_case_id) (increase(agent_runs_evidenced_total[1h]))
            /
            clamp_min(sum by (ai_use_case_id) (increase(agent_runs_total[1h])), 1)
          )

      - alert: AgentEvidenceCoverageBelowFloor
        expr: agent:runs_unevidenced:ratio1h > 0.05
        for: 15m
        labels:
          severity: page
          control: eu-ai-act-art-12
        annotations:
          summary: Agent runs without a matching governance evidence record
          description: >
            {{ $value | humanizePercentage }} of runs for use case
            {{ $labels.ai_use_case_id }} have no evidence record in the last hour.

The alert does not say the agent misbehaved. It says the record has a hole in it, which is the failure you cannot fix retroactively. Put the same ratio on a Grafana panel beside your evaluation metrics, so the governance lead reads both in one frame. Quality tells you how the agent behaved. Coverage tells you whether you can prove it.

Owner: SRE, with the AI governance lead setting the floor.

Tradeoffs

Adoption friction is real and it is mostly week one. Instrumenting spans across every agent path takes a sprint, the OTLP collector and its retention tier need a budget line, and someone has to own a versioning scheme for policies that was previously implicit. At roughly 1.5 KB per span you are looking at about 1.5 GB per million executions before compression, which is a rounding error next to any observability bill you already pay.

Ignoring it costs asymmetrically. The evidence you did not collect cannot be reconstructed after the request arrives, and the request arrives at the worst possible moment: a complaint, an incident, a due-diligence questionnaire, a market surveillance authority asking under Article 26, paragraph 6. The sixteen-month deferral makes this feel optional. It is the opposite. Sixteen months is exactly how long you now have to accumulate the record that proves your system was not substantially modified.

The closing argument

Adopt Enforcement Tracking for what it is. It automates the control attestation, it writes pass and breach evidence without a human assembling screenshots, and for teams currently maintaining governance evidence by hand it removes real work on day one. Hold on treating it as the audit trail, because a threshold snapshot and a per-event record are different artifacts with different retention clocks. The gap is not a defect in the release; it is the part that was always going to be specific to your deployment, and the join key was always going to be yours to define. The storage is cheap. The reconstruction is not.

Sources

IBM, From governance policies to governance proof with Enforcement Tracking for watsonx Orchestrate, August 11, 2026
IBM Documentation, Configuring metrics synchronization for watsonx Orchestrate agents (evaluation schedule, threshold evidence), accessed August 2026
Official Journal of the European Union, Regulation (EU) 2026/1744 (Digital Omnibus on AI), published July 24, 2026, in force July 27, 2026
European Commission AI Act Service Desk, Article 19: Automatically generated logs (six-month retention floor), accessed August 2026
White & Case, EU AI Omnibus enters into force, amending the AI Act (Annex III and Annex I deadlines, Article 50 unchanged), 2026
Cooley, Digital AI Omnibus Delays Key Deadlines, Introduces New Rules (2 December 2026 marking deadline, Annex I and public-authority dates), 2026
Gibson Dunn, EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes (CEN/CENELEC standards, authority designation), May 2026

Discussion

If you have wired agent executions to a governance record, or you have decided the sampled attestation is enough for your risk profile, drop a comment on the post. Counterarguments are welcome and the comment thread is where I respond first. For longer back-and-forth with senior practitioners, join the discussion on Discord.

<div style={{ textAlign: "center", paddingBottom: "3rem", marginTop: "5rem" }}> <p style={{ fontSize: "0.95rem", letterSpacing: "0.25em", textTransform: "uppercase", color: "#ffffff", margin: "0 0 8px 0", fontWeight: "900" }}> Vladimir Mikhalev </p> <p style={{ fontSize: "0.75rem", letterSpacing: "0.2em", textTransform: "uppercase", color: "#777", margin: "0 0 1rem 0" }}> Docker Captain · IBM Champion · AWS Community Builder </p> <p style={{ fontSize: "0.8rem", color: "#555", margin: "0 0 2.5rem 0", fontStyle: "italic" }}> The Verdict — production-tested analysis on YouTube. </p> <div style={{ display: "flex", justifyContent: "center", gap: "1rem", flexWrap: "wrap" }}> <a href="https://www.youtube.com/channel/UCf85kQ0u1sYTTTyKVpxrlyQ?sub_confirmation=1" target="_blank" rel="noopener noreferrer" style={{ padding: "0.6rem 1.5rem", border: "1px solid #444", backgroundColor: "#0a0a0a", color: "#fff", textDecoration: "none", fontWeight: "bold", textTransform: "uppercase", letterSpacing: "0.15em", fontSize: "0.8rem", borderRadius: "2px", transition: "all 0.3s ease", boxShadow: "0 0 10px rgba(255,255,255,0.05)" }}>YouTube</a> <a href="https://github.com/heyvaldemar" target="_blank" rel="noopener noreferrer" style={{ padding: "0.6rem 1.5rem", border: "1px solid #333", color: "#aaa", textDecoration: "none", fontWeight: "bold", textTransform: "uppercase", letterSpacing: "0.15em", fontSize: "0.8rem", borderRadius: "2px", transition: "all 0.3s ease" }}>GitHub</a> <a href="https://www.linkedin.com/in/heyvaldemar/" target="_blank" rel="noopener noreferrer" style={{ padding: "0.6rem 1.5rem", border: "1px solid #333", color: "#aaa", textDecoration: "none", fontWeight: "bold", textTransform: "uppercase", letterSpacing: "0.15em", fontSize: "0.8rem", borderRadius: "2px", transition: "all 0.3s ease" }}>LinkedIn</a> </div> </div>

Merge Debt: The 2026 Bill Your Parallel AI Agents Are Running Up

Vladimir Mikhalev (heyvaldemar.com) — Thu, 30 Jul 2026 00:00:00 GMT

Every parallel-agent demo ends on the same frame, and the frame is a lie of omission: three sessions running, three diffs growing, a satisfied cut to the dashboard. The hour the demo never shows is the one that decides whether any of it was velocity: three finished branches, one main, and a human who now has to land all of it.

The demo sold you velocity. What you actually took delivery of is inventory.

That hour is where the productivity story goes to get audited. In Part 1 I named the visibility gap: parallel sessions nobody inventories. In Part 2 I showed whose judgment catches what the dashboards miss. This part is about the narrowest point in the whole pipeline, the one the agents cannot parallelize for you: getting their work into main.

The category needs a name too. Here is mine: Merge Debt.

The debt, named

Merge Debt is the accumulating gap between code your agents have finished and code that has actually landed in main, reviewed, shaped, and reconciled with everything else that landed first.

It is not merge conflicts. Conflicts are the visible sliver. Merge Debt includes the finished branch waiting two days for review capacity, the rebase nobody has run yet, the three-thousand-line diff that arrived as one commit called "update payments," and the decision no one explicitly owns: which of three finished branches lands first. Writing code got parallel. Landing code stayed serial. Debt piles up exactly at that seam.

Any operations executive would recognize the shape on sight: work-in-progress inventory stacking up in front of the narrowest station on the line. Engineering has just not started booking it as inventory.

The perception gap has a number now

The reason Merge Debt goes unbudgeted is that the people accumulating it sincerely believe they are ahead.

Experienced open-source developers completed real tasks 19% slower when allowed to use AI tools. Afterwards, the same developers estimated AI had made them 20% faster.

— METR randomized controlled trial, 16 developers, 246 tasks, early 2025

Read the two numbers together. Not "AI is slow." The tools have moved on, and METR itself labels the result historical. The finding that survives is the direction of the error: a thirty-nine-point gap between felt speed and measured speed, in the cohort with the best-calibrated instincts in the industry. Generating code feels like progress with a precision that landing code never matches. So the generating gets counted and the landing gets discovered.

Now run that error at parallel scale. One agent inflates your sense of velocity. Three agents inflate it three ways at once, while the landing pipeline they all share has not gotten one commit wider.

The landing is serial

Here is the mechanical part, and it is arithmetic, not opinion.

Worktrees parallelize the work. Each agent edits its own copy of the tree, nothing collides while the work is in flight, and that is the correct primitive; I made that case in Part 1. But main is a single sequence. When three finished branches come home, one of them merges clean. The second rebases onto a main that just moved, and pays for it. The third rebases onto both, and pays compound. The wider each diff, the steeper the surcharge, and agent diffs run wide.

Someone chooses the landing order, or nobody does and the order chooses itself: whoever merges first wins the clean rebase, and the cost silently reassigns itself to whoever was slower to press the button. That is a scheduling decision with real engineering cost, and in most teams running parallel agents today, it has no owner. Merge order is set by button latency.

I run agents through worktrees daily across the fifty-plus public repositories I maintain, and the shift in my own week is the tell: the hours did not disappear when the agents arrived. They moved from writing the change to sequencing, shaping, and reviewing what the agents wrote. The queue is where my time goes now.

And the one gate every branch still has to pass is the one that did not scale. CI got faster and agents got better at making it green. Green CI tells you the tests you already had still pass. It does not tell you the change is right, and it especially does not tell you three changes are right together. The remaining gate is human review, and Part 2 already showed what is happening to that capacity: the reviewers best at catching "almost right" are the scarcest resource in the building. Parallel agents do not add reviewers. They add queue.

What the demos skip

The shape of what arrives at review is the other half of the debt.

An agent that worked for forty minutes hands you the result as one sprawling diff. Left alone, that becomes one commit, named something like "update payments," sitting on top of a history that used to mean something. Six months later git bisect lands on it, and the answer to "what broke" is "one of these nine hundred lines." git blame points at a commit whose message explains nothing, authored by a session nobody can replay.

Put that in front of an incident review, the way Part 1 put untracked sessions in front of a SOC 2 walkthrough, and the aesthetic complaint becomes a forensics gap: the record of what changed and why ends exactly where the machine took over. Part 2 walked through the GitClear data on duplication rising and refactoring collapsing inside AI-era codebases. History quality is the same decay, one layer up: the code got wider and the record of why got thinner, at the exact moment more of the code has no human author to ask.

The market response

The tooling response to Merge Debt is starting to ship, and, in fairness to the argument I have been building since Part 1, most of it is shipping on top of the commit graph.

On the desktop side, Commit Composer takes the sprawling agent diff and restructures it into logical, reviewable commits before it reaches a teammate. That attacks the landfill problem at the right point in the pipeline: after the agent finishes, before review burns time on it. Auto-resolve with AI handles the mechanical class of rebase conflicts and explains its proposed resolution, which is the correct division of labor. The rote line-matching goes to the machine. The semantic call, whether two changes are right together, stays with the human, because no merge tool can make it.

On the IDE side, GitLens 18 turned the commit graph into the place where agent sessions, worktrees, and working changes sit in one view, and the point releases have been filling in the landing workflow specifically: squash and reword straight from the graph in 18.1, and a more capable Compose mode with smarter AI conflict resolution in 18.3. The pattern across both products is consistent: the vendor that spent a decade betting on the graph is now wiring the landing pipeline into it.

Stated plainly, as always: Commit Composer and Auto-resolve are part of GitKraken AI, which sits behind a paid plan, and both are in preview. And no tool in this section repays Merge Debt for you. What it does is make the debt visible and the repayment cheap enough to happen daily instead of quarterly. The interface argument for why this belongs on a graph instead of five terminal panes has been made well elsewhere, including on devops.pink this week. My concern is narrower: the queue.

Control protocol

What managing Merge Debt looks like, at minimum. None of it requires believing a single vendor claim.

1. Give merge order an owner. If three branches finish together, landing sequence is an engineering decision: smallest-blast-radius first, or hottest-file first, but chosen, not defaulted to button latency. Thirty seconds of thought per landing, and the compound rebase tax stops being random.

2. Budget diff width per agent task. The wider the diff, the steeper every downstream cost: rebase, review, revert. Cap agent tasks the way you cap PR size for humans, and split before landing, not after the review stalls.

3. Make commit shaping a mandatory landing step. Machine output does not get to enter history as one blob. Whether the shaping is done by Commit Composer or by hand, "reviewable commits with meaningful messages" is the entry fee to main. Your future bisect is the beneficiary.

4. Check the heat map before you spawn. Two agents aimed at the same module is a collision you scheduled. The graph shows every active worktree and what it touches; ten seconds of looking before launching agent three is the cheapest conflict resolution that exists.

5. Plot the debt. Two numbers per team, on the same dashboard as velocity: time from agent-done to merged-in-main, and share of agent-authored code reworked within two weeks. The first is your queue depth. The second is your quality echo. Both are measurable today with the per-team measurement discipline this series keeps coming back to, and neither shows up in the commit count everyone is currently applauding.

Three questions for your next engineering leadership meeting

What is our median time from "agent finished" to "merged in main," and is it growing?
Who decided the landing order of the last three parallel branches that touched the same service, and was it decided at all?
What share of AI-authored code that merged last quarter was rewritten within two weeks?

If those come back fast, your landing pipeline is instrumented. If they come back as shrugs, the debt is already on the books. You are just not the one carrying it yet. Your reviewers are.

GitKraken Ambassador Note

As a GitKraken Ambassador, I write about the layer of the stack where engineering teams actually lose time, whether or not a tool exists there yet.

Merge Debt is that layer this year. The graph-first landing workflow in GitKraken Desktop and GitLens 18 is the first commercial tooling I have reviewed that treats landing, not generating, as the bottleneck. That diagnosis matches everything I see in production, which is why it lands here.

The adoption verdict, stated as a tradeoff: if your team runs more than one agent against one repository, the graph-plus-worktrees landing workflow is the part I would adopt this quarter. If you run one agent, serially, you can hold; your Merge Debt is small enough to manage by hand. And the part that repays the debt fastest, Commit Composer and Auto-resolve, sits behind the paid plan in preview. That is the cost side, and you should price it against your reviewers' hours, because that is the currency the debt is denominated in.

Discussion

If you are running parallel agents and your agent-done-to-merged time says something different, drop a comment on the post. Counterarguments welcome, and the comment thread is where I respond first. For longer back-and-forth with senior practitioners, join the discussion on Discord.

Terraform MCP server GA: the Apply Gate your auditor will ask about

Vladimir Mikhalev (heyvaldemar.com) — Tue, 30 Jun 2026 00:00:00 GMT

There is one environment variable in the Terraform MCP server that decides whether an AI agent reads your infrastructure or destroys it, and on June 11, 2026 it went generally available with the default set to false. The flag is ENABLE_TF_OPERATIONS, and the day a team flips it to true is the day an autonomous agent can run apply against a production workspace. I tested the GA release against real IaC workflows, and the code the agent generated was never the problem.

This is a pattern, not a HashiCorp problem. Over twenty years I have watched the same gap open every time a faster tool meets a change-control process: the tool that writes the configuration is never the liability, the missing line in the audit record is. I saw it when Terraform itself replaced hand-built infrastructure, and the question now is identical, only the author is an agent instead of a junior engineer. I traced the same agent-era audit gap in Agent Sprawl; the Terraform MCP server is where that gap meets production IaC. The Apply Gate is the part the release notes do not dwell on, and it is the part your auditor will.

What the agentic apply default looks like

In its default posture the server is safe. Destructive operations are disabled, the transport stays local, and the agent connects read-only.

# terraform-mcp-server, default posture: read and explain only
# destructive operations stay disabled, no flag set
terraform-mcp-server stdio --toolsets=registry,registry-private
# ENABLE_TF_OPERATIONS is unset (false): create_run is unavailable

In this mode the agent searches your private registry, surfaces approved modules, and explains a plan file in natural language. Credentials never reach the model. Token scoping holds. This is a defensible default and HashiCorp deserves credit for shipping it that way.

Then the gate opens.

# operations enabled: create_run is now live
export ENABLE_TF_OPERATIONS=true
# create_run can now issue a plan_and_apply run
# the agent can plan, and apply if approved

That one line unlocks the create_run tool, which can issue a plan_and_apply run: plan, then apply on approval. The server can now change state. The question stops being technical. It becomes governance: who approves the apply, and is that approval written down in a form your compliance team can read in six months.

I pointed agentic generation at a module provisioning an S3 bucket and an IAM role. The output was clean and compliant with the registry patterns. What was missing was a single record answering one question: which named human decided this agent could run apply against this workspace. Across banking, telecom, and cloud-native environments I have audited agent-written and hand-written Terraform the same way, and the failure mode does not change with the decade or the tool. The gap is always the missing approver.

Why this keeps happening

HashiCorp's own GA announcement names the clients that can drive the server: GitHub Copilot, Claude Desktop, and IBM Bob. IBM Bob reached general availability in April 2026 as IBM's enterprise agentic development partner, which means there is now an official, supported path for an autonomous agent to write the Terraform that provisions production. The InfoQ coverage of the original experimental release in August 2025 already framed these servers as a "critical new interface layer between trusted automation systems and emerging AI ecosystems." GA turned that interface from experiment to supported product.

The audit gap recurs for a structural reason. Vendors secure the boundary they own: authentication, authorization, transport, secret exposure. HashiCorp did exactly that, and did it well. The audit trail for human intent sits one layer above the boundary, inside your change-control process, and no MCP server can ship it for you because it depends on your org chart, your policy sets, and your definition of who is allowed to accept risk.

Risk and blast radius

Direct exposure: an autonomous plan_and_apply against a production workspace, authorized by a flipped environment variable rather than a named human, is the precise event a SOC 2 change-management control exists to prevent. In a regulated environment, an apply with no attributable approver is an audit finding waiting to be written. Under frameworks that require demonstrable separation of duties, "the agent did it" is not an answer an auditor accepts.

Systemic exposure: the server connects to your private registry and your workspaces, and with operations enabled it can run against any workspace the scoped token reaches. A token scoped too broadly turns one convenience flag into organization-wide apply capability. The blast radius is the set of workspaces the token can see, multiplied by every team that flips the flag without recording why.

Options compared

Three deployment postures, the tradeoff each carries, and the fit.

Posture	Agent capability	Audit artifact required	Adoption friction	Fit
Default (read-only)	Search registry, explain plans	None beyond token scope	Minimal, deploy and go	Every team, today
Operations + Sentinel gate	plan_and_apply, policy-gated	Sentinel policy set per workspace, audit log	Moderate, one deploy cycle	Teams with policy-as-code in place
Operations, no gate	plan_and_apply, ungated	Nothing enforced	Lowest setup, highest exposure	Do not ship to production

This is not "my pick wins." Read-only is the right call for almost everyone right now. Operations behind a Sentinel gate is the destination once the record exists. Operations with no gate is the one I would not deploy.

Framework: wrapping the Apply Gate before production

Three layers, one deploy cycle each. This is the control protocol that goes around the Terraform MCP server before agentic apply touches production. The layers run in order: inventory, then policy, then continuous verification.

Layer 1: inventory and read-only baseline (week 1)

Map every connection the server can make, pin the toolset explicitly, and keep the flag false. Scope the token to the minimum workspaces. On HTTP deployments, pin the organization allowlist to the smallest set of orgs.

# terraform-mcp-server: least-privilege read-only baseline (local stdio)
terraform-mcp-server stdio --toolsets=registry,registry-private
# create_run intentionally unavailable: ENABLE_TF_OPERATIONS unset
# scope TFE_TOKEN to the minimum workspaces; for HTTP deployments,
# set MCP_ORGANIZATION_ALLOWLIST to the smallest set of orgs

The deliverable is a written record of exactly what the agent can see before it can change anything. Owner: platform engineer.

Layer 2: policy gate via Sentinel (week 2)

Use HashiCorp's own primitive. Attach a Sentinel policy set to any workspace an agent may eventually apply against, using the policy-set tooling that shipped with the server. No policy set attached means no agentic apply against that workspace.

# Sentinel: deny apply without an attributable approver tag
import "tfrun"

main = rule {
  tfrun.workspace.tags contains "approver-recorded"
}

# attach the policy set via the MCP server's governance tooling
# (attach_policy_set_to_workspace per the tool reference; confirm
#  parameter names against your installed version)
attach_policy_set_to_workspace(
  policy_set = "agentic-apply-guard",
  workspace  = "platform-prod-network"
)

Review of agent-generated plans moves from a human eyeball guess to a Sentinel decision. Owner: security or platform lead.

Layer 3: continuous verification (week 3 onward)

Now the gate can open, because the record will exist. Two signals, two sources. The attributable record of who triggered and approved each run lives in your HCP Terraform or Terraform Enterprise audit trail, not in the MCP server. Route those audit events into your pipeline so every run carries a name and a timestamp.

The MCP server adds the second signal: tool-usage telemetry. With metrics enabled, it emits OpenTelemetry counters for call volume, errors, and latency that tell you how often the agent invokes a run and where it fails. Wire that into the same observability stack.

# otel collector: capture MCP tool-usage metrics
# enable with OTEL_METRICS_ENABLED=true
# metrics: mcp_tool_calls_total, mcp_tool_errors_total, mcp_tool_duration_seconds
receivers:
  otlp:
    protocols:
      grpc:
exporters:
  otlphttp/observability:
    endpoint: https://otel-sink.internal:4318
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [otlphttp/observability]

The audit trail answers "who," the metrics answer "how often and how it failed." Together they are the record the GA did not ship for you. The flag flips to true only for workspaces that have layers 1 and 2 in place. The flag is a governance decision with a name attached, not a developer toggle. Owner: SRE, with sign-off from compliance.

Tradeoffs

What this costs: one deploy cycle of friction before any team gets autonomous apply, plus the discipline of attaching a policy set to every agent-reachable workspace. Teams without policy-as-code feel this most, because layer 2 forces a capability they were postponing.

What ignoring it costs: a single audit cycle. The day an auditor asks who authorized the agent that provisioned a workspace, the cost of the skipped framework is the difference between pointing to a timestamped, attributed audit trail and pointing to a flipped environment variable with no name behind it. The first is a five-minute answer. The second is a finding.

The closing argument

I would adopt the Terraform MCP server in read-only mode on every team today. The read-only workflow earns its keep, and the boundary security is properly built. I would hold on enabling operations until the three layers exist, because the audit trail for autonomous apply is yours to build and the GA did not build it for you. The cost of adopting naively is not a breach. It is the day someone asks who signed off and the honest answer is a config flag. Deploy it read-only this week, attach one Sentinel policy set, and leave the Apply Gate closed until the record can answer for it.

Sources

HashiCorp, Terraform MCP server is now generally available, June 11, 2026
HashiCorp Developer, Terraform MCP server reference (create_run run types, ENABLE_TF_OPERATIONS), accessed June 2026
HashiCorp, Terraform MCP server updates: Stacks support, new tools, and tips (policy-set tooling), 2026
InfoQ, HashiCorp Introduces MCP Servers for Terraform and Vault, August 14, 2025
GitHub, hashicorp/terraform-mcp-server (toolsets, organization allowlist, transports, OTel metrics), accessed June 2026
IBM Newsroom, Introducing IBM Bob, April 28, 2026

Discussion

If you have enabled operations in production, kept the gate closed, or seen this audit pattern in your own change-control process, drop a comment below. Counterarguments welcome, and the comment thread is where I respond first. For longer back-and-forth with senior practitioners, join the discussion on Discord.

Your Knowledge Is a Depreciating Asset. Judgment Compounds.

Vladimir Mikhalev (heyvaldemar.com) — Tue, 16 Jun 2026 00:00:00 GMT

For a decade we got paid for what we knew. That asset is being written down to zero. Here is the one that is appreciating instead, and how to move your weight onto it before the market finishes repricing it.

For about a decade, the reliable way to build standing in technical work was to accumulate reproducible knowledge and rent it out. You learned the tool, the syntax, the runbook, the migration path, and you got paid for knowing it, whether as a salary, a course, a book, or a paid community built around a library of how-to. The knowledge was the inventory. It had value because it was scarce and you held more of it than the person paying you.

That inventory is being written down to zero. Not because anyone mismanaged it. Because the thing on the shelf, reproducible knowledge delivered on demand, is now generated for free in seconds, personalized to the exact situation, by a tutor that never tires and updates the moment the tool does. An engineer who needs a working pipeline no longer buys the lesson. They describe the constraint and get a tailored answer for less than the cost of looking it up.

This is an asset problem before it is anything else. If your balance sheet, career or business, is concentrated in reproducible knowledge, you are long a deflating asset. The move is not to accumulate faster. It is to work out which asset is appreciating and shift your weight onto it before the writedown is fully priced in. That asset is judgment. Here is the line between the two, drawn with the data.

The threat, named

Call it Knowledge Deflation: the rapid collapse in the market value of reproducible technical knowledge as AI makes its transfer free, instant, and personalized.

Technical knowledge always decayed. Docker made the VM courses obsolete. Kubernetes turned the Swarm tutorials into a dead end. Every few years a new layer arrived and last year's training material aged out. Producers stayed ahead by shipping the next thing before the last one fully rotted. AI breaks that arithmetic. It does not swap one body of material for another. It shortens the useful life of all of it at once, faster than anyone can produce the replacement, and it does so on the demand side too. The buyer who would have paid for the explanation now generates a bespoke version of it for the price of a prompt.

The deflation is already showing up where knowledge gets sold directly.

Copy/pasted lines rose from 8.3% of changed code in 2021 to 12.3% in 2024, while refactored ("moved") lines fell from about 25% to under 10% over the same window. 2024 was the first year copy/paste outpaced refactoring in the dataset.

— GitClear, AI Copilot Code Quality 2025 (211 million changed lines, 2020–2024)

Read that as an economic signal, not only a quality one. When knowledge is cheap to reproduce, it gets reproduced instead of reused. The same force that fills a codebase with near-duplicate blocks fills the market with near-duplicate explanations. Abundance is exactly what destroys the price.

The blast radius

The deflation runs through three balance sheets at once: the educator's, the engineer's, and the trust of the person doing the buying.

On the supply side, the people who sell learning for a living are watching demand erode in real time. I watched the founder of an interactive-coding-course platform publish his own keyword research while deciding what to build next, and the read was sobering for anyone in that business. Search demand for "learn to code" queries is draining as the audience routes its questions to an AI assistant instead of a curriculum. When the person whose income depends on selling courses tells you the top of the funnel is emptying, that is not doom-posting. That is a supplier reading his own order book.

The macro picture agrees. US computer science enrollment fell 8.1% in 2025 after more than a decade of growth, the steepest one-year drop of any major in six years. CS slid from the fourth to the sixth most popular field of study. It is the first cycle where the decline is pinned on AI reshaping the work itself, not on a dot-com-style boom and bust. The pipeline that fed the entire knowledge-transfer economy is narrowing because the buyers can sense the inventory is depreciating.

And the asset is not only deflating. It is unreliable at the margin, which speeds the writedown.

Trust that AI output is accurate fell from 40% to 29% year over year, the lowest the survey has recorded. Favorability slid from 72% to 60%. The top frustration, named by 45% of developers, is "AI solutions that are almost right, but not quite," and two-thirds now say they lose time cleaning up that almost-right code.

— Stack Overflow Developer Survey 2025

"Almost right, but not quite" is the tell. Commoditized knowledge is now cheap and untrustworthy at the margin, which means the value does not vanish. It relocates. It moves to whoever can tell looks correct from is correct. That is not a knowledge skill. It is judgment.

The most direct evidence that the machine cannot hold the high-value end is what happens when you delegate real work to it.

Across 19 models and 52 professional domains, even frontier systems (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4) corrupted an average of 25% of document content over long, multi-step workflows. Agentic tool use did not help. Degradation got worse as documents grew larger and interactions ran longer.

— Microsoft Research, "LLMs Corrupt Your Documents When You Delegate" (DELEGATE-52), arXiv, April 17, 2026

Transfer of knowledge: free, instant, and increasingly good. Sustained application of judgment to a real, evolving artifact: still failing a quarter of the time at the frontier. That gap is the whole investment thesis.

Why this is a balance-sheet question, not a skills question

The instinct, when knowledge deflates, is to learn faster and accumulate more inventory more aggressively. That is the wrong move, and the data above says why. You would be doubling down on the asset that is losing value, in a race against a free competitor that restocks instantly. Speed of accumulation is not the lever.

The lever is what you choose to be paid for.

Reproducible knowledge answers "how does X work" and "how do I configure Y." The market price of that answer is now close to zero, because the answer is generated on demand. Applied judgment answers a different question: given our compliance posture, our existing sprawl, the two teams that own overlapping systems, and the fact that we cannot take downtime this quarter, what should we actually do, in what order, and what breaks if we are wrong? An AI assists with that. It cannot own it. Owning it requires context the model does not have, accountability it cannot hold, and the scars to know which of three plausible answers survives contact with production.

That is why judgment is the appreciating asset. Every junior task the machine absorbs raises the premium on the senior judgment it cannot. I made the organizational version of this argument: teams that thin out senior review to chase velocity lose the people who can tell a working system from a plausible one. The cheaper reproducible knowledge gets, the more valuable it becomes to deploy that knowledge correctly under real constraints. The two assets are moving in opposite directions, and most people are still weighted into the one going down.

The same writedown hits teaching twice

If you sell knowledge as a product, courses, tutorials, library-style communities, the deflation hits you from two directions at once.

From above: AI commoditizes the core inventory. The recorded explanation competes with the live, free, personalized one, and loses on price. Producing more modules is running faster on a treadmill that keeps accelerating. The tell is in the product itself. When the navigation of a learning offering fills with "planned," "building," and "coming next," it has stopped being a library and become a promise of future content, sold today. That works while content is scarce. It stops working when content is abundant and free.

From below: imitation. I have paid into a handful of these over the past couple of years, and a second pattern repeats alongside the first. Someone with real authority builds something that works, and a wave of imitators ships a thinner version of the same thing. The copies compete on the one axis AI has already won, reproducible knowledge, without the audience, the production scars, or any reason to exist that a model cannot satisfy for free. The category gets squeezed from both ends. AI deflates the value from the top, imitators dilute what is left from the bottom. The strongest operators feel the ceiling. Everyone copying them hits it sooner.

The defensive move is not to produce faster. It is to stop selling the answer and start selling the room where answers get worked out. The durable version of a technical community in this era is not a content library with a forum bolted on. It is a standing conversation among people with enough production experience to separate signal from noise, organized around the questions that do not have a recorded answer yet. Not "how do I configure this," but "what survives when the thing I configured can be generated by anyone in thirty seconds." The members are the asset. The host curates the question and holds the standard. That is harder to sell and much harder to fake, which is why it holds value while the library does not.

Control protocol

How to move your weight off the deflating asset and onto the appreciating one. Career and business, same five moves.

1. Stop pricing reproducible knowledge. Price judgment. Audit what you currently get paid for. Every line item that is "I know how to do X" is exposed. Every line item that is "I decide what is worth doing, in your context, and I own the outcome" is defensible. Shift the mix deliberately.

2. Convert content from product to proof. A blog, a talk, an open-source project should no longer be the thing you sell. It is evidence of judgment that makes you more valuable at the thing you do sell, priced as a salary, then as consulting, then as advice. Give the knowledge away. It is worth nothing to hoard now anyway. Charge for the judgment it points to.

3. Move toward the work the machine fails at. DELEGATE-52 and the trust data point at the same high ground: sustained, accountable, context-heavy decisions over long horizons. Solutions architecture, security and compliance judgment, system design under real constraints. The hiring I watch is already concentrating there while execution-only roles deflate.

4. Make the supervisory layer the explicit job. If "almost right, but not quite" is the dominant failure mode, then catching it is now the highest-value work in the building. Whether you lead a team or sell your own time, fund and price that work as the deliverable it has become, not as a tax on velocity.

5. Stop competing on the commoditized axis. If your differentiation is "I have the knowledge," you are competing with the free tutor and you lose on price. Differentiate on the axis AI cannot reach: ownership, accountability, and judgment earned in production over years.

Three questions to sit with this quarter

Take them literally. The honest answers tell you how exposed your balance sheet is.

What share of my income today is paid for reproducible knowledge, the kind an AI assistant now generates on demand, versus applied judgment I am accountable for?
If every how-to I have ever produced became free and instant tomorrow, what would I still be uniquely paid for?
Is the content I am making a product I am trying to sell, or proof of judgment that makes me more valuable at what I sell? If it is the former, I am long a deflating asset.

Knowledge was the product. It is a commodity now, and the rational move is to plan your career and your business as if it is free, because functionally it is. The content era rewarded the people who could explain things clearly, and there was real money and status in being the clearest voice in the room. The AI era rewards what the content era undervalued: the ability to sit with a problem that has no recorded answer, weigh the tradeoffs, make the call, and own what happens next. You cannot download that. You cannot generate it from a prompt. You earn it in production, over years, by being accountable for outcomes.

Move your weight onto the asset that compounds. Judgment is the product now.

The Senior Engineer Signal: The 2026 Risk Your Velocity Metrics Hide

Vladimir Mikhalev (heyvaldemar.com) — Fri, 12 Jun 2026 00:00:00 GMT

In Part 1 I left a thread hanging on purpose.

Your most experienced engineers report the smallest productivity gains from AI. They also trust its output the least. I called that a signal, not a generational gripe, and said it mattered more than most boards have heard. Time to make good on that.

The people with the most miles on them are not being cautious for sport. They are reading something in the codebase that the velocity dashboard does not show. And over the last year, the data caught up to what they have been saying out loud since 2023.

What the seniors are actually looking at

Start with the code itself, because that is where their nose twitches first.

Lines classified as "copy/pasted" rose from 8.3% of changed code in 2021 to 12.3% in 2024. Refactored ("moved") lines fell from about 25% of changes to under 10% over the same window. That was the first time in the dataset that copy/paste outpaced refactoring.

— GitClear, AI Copilot Code Quality 2025 (211 million changed lines, 2020–2024)

Read that again, because it is the whole section. We are pasting more and reshaping less. The codebase is getting wider, not cleaner. Duplication is cheap to generate now, so it gets generated, and the boring work of folding five near-copies back into one function is exactly the work an AI will not volunteer for and a junior will not notice is missing.

A senior notices. That is the job. They have maintained the system that got wide and then got brittle, and they can smell the early version of it.

The delivery numbers point the same direction.

A 25% increase in AI adoption was associated with a 7.2% drop in delivery stability and a 1.5% drop in throughput. AI makes it easy to write more code, batch sizes go up, and bigger changesets carry more risk.

— Google's DORA, State of DevOps 2024

Throughput down too. That one surprises people. The story everyone sold was "AI writes the code faster, so we ship faster." What actually happens is the batch gets bigger, the review gets harder, and the thing that breaks costs more to unbreak. Net, slightly slower. Measurably less stable.

So the seniors are not wrong, and they are not nostalgic. They are looking at a real second-order effect that the first-order metric hides.

The trust line keeps dropping

Here is the part that should bother you most, because it is moving the wrong way over time.

Trust that AI output is accurate fell from 40% to 29% year over year. Favorability dropped from 72% to 60%. More developers now actively distrust AI accuracy (46%) than trust it (33%). The top frustration, named by 45%, is "AI solutions that are almost right, but not quite."

— Stack Overflow Developer Survey 2025

"Almost right, but not quite" is the expensive failure mode. A wrong answer you catch. A nearly-right answer you ship, and then you debug it three sprints later with no memory of why that line is there. The cohort best at spotting "almost right" is the senior cohort. They are also the cohort whose trust is lowest and dropping fastest.

Hold that next to the number from Part 1. Across the Sonar 2026 survey, 96% of developers do not fully trust that AI-generated code is functionally correct, yet only 48% always check it before they commit. Half the industry is shipping code it does not trust, unverified. The other half, the half that does check, is carrying the verification load for everyone. Guess which half is senior.

None of this is an argument against AI. I use it every day. It is an argument about who is holding the line, and whether you have noticed.

Why the velocity dashboard hides the bill

Walk into a 2026 board meeting and you will see the throughput chart. Commits up. PRs up. Story points up. AI adoption up and to the right. Everyone nods.

The chart is real. It is also the wrong chart.

What it does not show: churn. The share of code rewritten within two weeks of landing has been climbing, which means more of that throughput is rework, not progress. It does not show the duplication creeping in. It does not show delivery stability sliding 7% for every 25% of adoption. And it definitely does not show the trust line falling off a cliff inside your own engineering org.

You are measuring the bump and not the bill. The bump lands this quarter, on a slide. The bill lands later, in an incident review, in a security finding, in the three weeks it takes a senior to untangle a "mostly working" subsystem nobody fully understands. By then the person who flagged it early has stopped flagging.

This is the same failure I described in Part 1: the dangerous stuff is the stuff your instruments do not surface. There it was parallel agents with no audit trail. Here it is code-quality decay with no panel on the dashboard. Same disease. The number that would scare you is the number nobody is plotting.

The talent math nobody puts on the board deck

Now the part that turns a code-quality story into a people story.

The read a lot of leaders took from "juniors get the biggest AI boost" was blunt: we need fewer expensive seniors. Salesforce said the quiet part on the record. Marc Benioff told investors the company would hire no new software engineers in 2025, citing a 30% engineering productivity gain from AI, while growing the sales team by up to 20%. "We are the last generation to manage only humans," he added.

Maybe that math works at Salesforce's scale. For most orgs it removes two things at once, and they will not notice until both are gone.

It removes the supervisory layer. The seniors are the review capacity. They are the people who catch "almost right." AI does not reduce the need for that capacity. The GitClear and DORA numbers say it raises it. You are generating more code, more duplication, and more nearly-right merges, all of which need more senior eyes, right when the plan is to have fewer.

And it removes the pipeline. Juniors become seniors by doing the work that AI now does for them and getting it reviewed by someone more experienced. Cut the junior reps and the senior review at the same time and you are not running lean. You are eating the seed corn. There is no 2030 senior bench if 2026 juniors never get past prompt-and-paste.

Then there is the quieter attrition, the kind that does not show up as a layoff. A senior whose job becomes uncredited cleanup of machine output, whose judgment is treated as a tax on velocity, whose "I don't trust this merge" is overruled by a burndown chart, does not file a complaint. They disengage. Then they leave. And they take the context for your load-bearing systems with them, the context that was never written down because it lived in their head.

You do not get a dashboard alert for that either.

What to actually do about it

Five things, and none of them is "stop using AI." That ship sailed and it was the right ship.

1. Treat AI productivity as non-uniform by seniority. The boost is real for juniors on well-trodden tasks and small for seniors on hard ones. Plan and staff around that instead of averaging it into one number that flatters the tool and insults your best people.

2. Make the supervisory layer the senior's actual job, on paper. Review, architecture, the boundary work I described in Part 1. Not a thing they squeeze in between tickets. The thing they are measured and paid for. If catching "almost right" is now the highest-value work in the building, fund it like it is.

3. Measure quality, not just throughput. Put churn, duplication, refactoring rate, and change-failure rate on the same screen as commit count. If your dashboard only shows the bump, your board only sees the bump.

4. Measure AI's impact per team, and keep it off individuals. Segment DORA before and after adoption, by team, so you can see who is actually getting faster and who is just getting busier. Tie it to developer sentiment, not surveillance. I wrote up the framework for doing this without wrecking trust in AI Didn't Fix Productivity. Measurement Did. The moment this becomes a stack-ranking tool, the seniors stop telling you the truth, and the truth was the whole point.

5. Protect the pipeline on purpose. Keep hiring and growing juniors, and keep them paired with seniors on real review, even though AI can fake the output of their early-career work. You are not buying this quarter's tickets. You are growing the people who will hold the line when the next wave of tooling shows up without its supervisory layer attached.

Three questions for your next board meeting

Same format as Part 1. Ask them out loud and watch the room.

Show me churn, duplication, and change-failure rate next to our throughput chart. If we cannot put them on the same screen, why not?
What is our senior-to-junior ratio, where is it heading over the next eight quarters, and who is reviewing AI-generated code today?
Which of our load-bearing systems has its context living only in one senior engineer's head, and what happens to that system if they leave this year?

If those land as uncomfortable silences, you found the work.

The senior engineer signal is the canary. It is quiet, it is unglamorous, and it is the cheapest early warning you will ever get. The organizations that listen keep the people who can tell "looks correct" from "is correct." The ones that read the throughput chart, call it a win, and thin out the bench will find out the difference the expensive way. In the incident review. With the one person who saw it coming already gone.

That was the more interesting question all along. Not how fast the machine can write. How long you keep the people who know when it is wrong.

GitKraken Ambassador Note

As a GitKraken Ambassador, I write about how engineering teams actually operate when the tooling changes under them, not about feature launches.

This whole two-part series came down to one idea. The risks that hurt you are the ones your instruments do not show: parallel agents with no audit trail in Part 1, code-quality decay and senior disengagement with no panel on the dashboard here. Instrument the thing you cannot see. Then keep the people who can see it anyway.

Agent Sprawl: The 2026 Engineering Risk Your Auditor Hasn't Named Yet

Vladimir Mikhalev (heyvaldemar.com) — Thu, 11 Jun 2026 00:00:00 GMT

Right now, across your engineering organization, some number of AI coding agents are running in parallel. A few sit inside Claude Code sessions in worktrees you never see. Others work against branches nobody has pushed. And some are committing to repositories owned by teams whose AI tool budget you never approved.

You do not know how many. Neither does your VP of Engineering. The developer who kicked off a second Copilot agent thirteen minutes ago, in a separate worktree, does not know either. They just opened another terminal.

Put that gap in front of a SOC 2 Type II review in 2026, or a pre-acquisition technical diligence, and it reads as a finding. The category needs a name. Here is mine: Agent Sprawl.

The threat, named

Agent Sprawl is the uncontrolled proliferation of parallel AI coding sessions across an engineering organization, without unified audit trail, isolation pattern, or per-team measurement.

Your SIEM will not flag it. It is not a security incident. It is not a feature flag your platform team forgot to toggle. It is a structural condition. The thing emerged through 2025 and hardened into operational baseline by mid-2026 in most engineering organizations of any real size. What is missing is the instrumentation. That gap is what this article is about.

Here is what one Agent Sprawl incident actually looks like. Agent A is iterating on a refactor on feature/payments-v2. Agent B starts fifty minutes later, launched by a different developer in a separate worktree on bugfix/payments-rounding, and opens the same file to ship an unrelated fix. Both branches were cut from main. Both edit src/payments/charge.ts. Neither sees the other. When the two branches merge back to main, Git's three-way merge resolves the textual diff cleanly. Semantically, though, Agent A's refactor removed the helper function that Agent B's bug-fix path still calls. The unit test that would have caught the mismatch? Agent A deleted it as "no longer relevant." The bug ships. No log entry anywhere says "two agents wrote to this file in parallel." That is Sprawl at the IC level. Now multiply it by the number of branches live in a forty-engineer team. The audit trail becomes a wish, not an artifact.

The blast radius

Three numbers from the last six months set the scale.

72% of developers who have tried AI coding tools now use them every day, and AI now accounts for 42% of all committed code.

— Sonar State of Code Developer Survey, 2026

96% of developers do not fully trust that AI-generated code is functionally correct, yet only 48% always check their AI-assisted code before committing it.

— Sonar State of Code Developer Survey, 2026

30% of engineers spend a third of their week on repetitive infrastructure tasks and audits.

— DuploCloud AI + DevOps Report 2026

Translated for engineering leadership: adoption is already universal, the productivity reality is uneven, and the operational tax on your team is high enough on its own that stacking uncontrolled AI sessions on top makes things worse, not better.

The blast radius is on the record too. Earlier this year a misconfigured setAlarm() loop inside Cloudflare Durable Objects ran up a $34,895 cloud bill in eight days, April 3 to 11, before the developer noticed. Cloudflare's billing system at the time had no real-time spending caps and no usage notifications for Durable Object operations. Now swap "agent operating without oversight" in for "misconfigured loop." Same shape of incident. Routine 2026 possibility. Vastly larger surface area.

I have watched this surface grow firsthand. Across the fifty-plus public repositories I maintain, and inside the production environment I run for 150-plus engineers, the count of distinct AI agent surfaces touching the codebase roughly doubled between October 2025 and March 2026. The visibility layer did not keep up. That asymmetry is the operational shape of Agent Sprawl, well before any auditor gets around to naming it. For the per-agent walk-through I ran on a live environment last quarter, see I Tested an AI Agent on My Live Systems. Here Is the Blast Radius Assessment.

Why this is a board-level question in 2026

Four reasons, ordered the way they will hit the board deck.

Audit scope is evolving. SOC 2 Type II practitioners are asking, more and more, about AI-assisted code provenance. AICPA guidance is still maturing as of mid-2026. But auditors already fold AI tool inventory, access controls, and code-review-of-AI-output procedures into their walkthrough questions. If you cannot show that AI-assisted code gets reviewed under the same controls as human-authored code, that is a finding.

EU AI Act enforcement is live. Engineering organizations that produce software for EU markets fall within scope for obligations around AI system documentation and risk management. Exactly how that lands on internal AI coding tools, versus AI features you ship inside products, is still being clarified through 2026. Operating with no internal record of AI tool usage is a bad place to stand when the clarity arrives.

Acquirer due diligence has caught up. Tech diligence checklists in 2026 routinely ask about AI tool usage, AI-generated code volume, and AI governance documentation. "We do not track that" was a fine answer in 2025. In 2026 it is a valuation discount.

Cyber and E&O insurance underwriting has caught up. Several carriers now put AI governance disclosure on their renewal questionnaires. In most cases the lack of it is not yet a coverage denial. It does raise premiums and narrow coverage scope.

The senior engineer signal

This is the data point most worth sitting with. From the same Sonar 2026 survey: junior developers report the highest productivity gains from AI, and senior developers report meaningfully smaller ones. The survey also notes that experienced developers value AI's impact on technical debt and documentation differently than junior peers do. Recall the split from earlier: 96% of developers do not fully trust AI-generated code is functionally correct, but only 48% always check it before committing. The seniors are the ones flagging that gap loudest.

That is not a generational gripe. It is a signal. The cohort with the deepest experience reading systems that look correct but are not is the least convinced this trajectory is net positive. Part 2 of this series gets into why that signal matters more for engineering risk and talent retention than most boards have heard.

Twenty years in, I will just say it. The people with twenty-plus years on the floor have watched several "transformative" tooling waves show up without the supervisory layer keeping pace, and they know the shape on sight. The skepticism in that cohort is a leading indicator. Not noise to filter out.

The market response

The first practical instrumentation for this category is starting to ship.

On April 16, 2026, GitKraken Desktop 12.0 introduced Agent Mode, with a dedicated view it calls Agent Sessions View in the left panel. Per the published release notes, it is a unified dashboard for worktrees and active agent sessions. Every worktree shows up as a card. The card displays the branch, uncommitted changes, ahead/behind state, and associated pull requests. For Claude Code users specifically, the associated agent's status surfaces right on the card: working, waiting for input, errored. The "New Agent Session" action creates a worktree, runs configured setup commands, and launches the coding agent in one step. Per-worktree setup commands (dependency installs, build steps, environment file copies) can be configured in Preferences, so new agent environments come up ready on their own.

So this is the worktree-per-agent isolation pattern made operational, with an audit-trail-friendly visualization layer on top. It is the first commercial response to Agent Sprawl I have looked at that treats the problem as the structural condition it is, instead of as a marketing surface for "AI features."

Worktree-per-agent is also the right primitive, and that distinction matters. The intuitive default is to aim two agents at the same feature branch and let them collaborate. In practice that fails the instant either one touches a file the other is editing. The conflict shows up at commit time, not edit time, and by the time anyone notices, the work both agents have done is already entangled. Worktree-per-agent inverts the order. Each agent operates on its own filesystem copy of the branch, edits there, and merges happen explicitly through a pull request a human reviews. The cost is disk. The gain is that agent collisions stop being silent. For an organization auditing what touched production, that boundary separates "we can reconstruct who changed what and when" from "the timeline is a guess." It is also what makes the per-agent measurement (item 4 below) possible at all. You cannot DORA-segment what you cannot tell apart.

Running it day to day, the change is operational, not cosmetic. I used to carry a mental map: which terminal is which worktree, which agent is mid-task, what branch each one sits on. That map moved into a visible state I can scan in two seconds. Cards in a grid. Branch and ahead/behind counts on each. Agent status (working, waiting, errored) right where the eye looks for it. Recovering that working memory is the part I had underestimated. My old terminal-plus-tmux flow kept the cost invisible. Once it is visible, the parallel-agent workflow stops being a tax I pay to ship faster. It becomes a tracked surface I can reason about, hand off, and audit.

Control protocol

What instrumentation for Agent Sprawl looks like, at minimum.

1. Unified audit trail for all parallel AI agent sessions. One pane of glass where every active worktree-with-agent is visible to the developer, the team lead, and, with appropriate aggregation, the engineering leadership reviewing organization-level AI usage.

2. Isolated environments per agent. The worktree-per-agent pattern is the right primitive. Shared branches with multiple AI agents writing to them is the wrong shape. The pattern keeps each agent's surface area observable and rollback-able.

3. Risk-scoring layer on AI-authored pull requests. Size, complexity, and change scope are signals that should trigger reviewer assignment and elevated scrutiny before merge. This is automatable today.

4. DORA measurement of AI impact per team. Deployment frequency, lead time for change, change failure rate, and mean time to recovery, with before-and-after AI adoption baselines, segmented by team. Without segmentation the aggregate hides everything that matters. For the measurement framework I have used to do this segmentation cleanly, see AI Didn't Fix Productivity. Measurement Did.

5. Voice of Developer survey alongside the quantitative metrics. Numbers tell you what happened. Survey signal from the engineers actually using the tools tells you why. You need both. Either one alone misleads.

The first commercial implementation of this measurement layer I have reviewed is GitKraken Insights, launched October 2025 in partnership with engineering analytics specialist GitClear. It runs on a stated design principle that matters here: measure teams and workflows, not individuals. That principle is correct. The moment your AI impact measurement turns into individual surveillance, you lose data quality, and you lose the senior IC trust you most need to keep.

Three questions for your next engineering leadership meeting

Take these as written. If the answers come back fast, your engineering organization is ahead of most. If they come back as "we do not track that," you have your starting point.

As of right now, how many AI coding agents are active across our engineering organization?
Where is the audit trail for AI-assisted code changes from the last ninety days, and who has access to it?
What is our baseline DORA performance from the six months before our most significant AI tool adoption, and what does the comparison look like now?

Most engineering organizations will not have Agent Sprawl instrumented by the end of 2026. The ones that do will show up cleanly in next year's M&A and audit cycle. The ones that do not will spend the cycle after that explaining the gap. The work to close it is a quarter, not a year. But it has to start being named.

GitKraken Ambassador Note

As a GitKraken Ambassador, I write about the tools that change how engineering teams operate at scale, not the ones with the loudest launch posts.

Agent Sessions View is the first piece of dedicated instrumentation for Agent Sprawl I have reviewed. That is why it lands here. The category exists either way. The instrumentation is now starting to exist alongside it.

Docker supply chain hardening — from Scout D to OpenSSF 7.8 on a 730K-pull image

Vladimir Mikhalev (heyvaldemar.com) — Wed, 22 Apr 2026 00:00:00 GMT

Earlier this month my public Docker image heyvaldemar/aws-kubectl held a Docker Scout grade of D. It had crossed 730,000 pulls on Docker Hub. That same image now holds a Scout grade of B and an OpenSSF Scorecard of 7.8 out of 10, well above the typical score for public utility images. I read the configuration line by line. I shipped three major phases. And I hit one production incident that cost me a full afternoon.

You see the same pattern everywhere. Banking. Telecom. Cloud-native. A utility image gets adopted because it works, pulls climb into six figures, and nobody touches the Dockerfile for years. Defaults that shipped in 2023 are still the defaults in production in 2026. So if you maintain a public image with real adoption and you have never audited it against current supply chain expectations, what follows is the checklist I wish I had kept from day one. For the performance side of the same site rebuild that preceded this work, see the Cloudflare Web Analytics migration that unlocked Lighthouse 100.

What grade D actually looked like

The starting Dockerfile was the version most maintainers will recognize on sight. One stage. A FROM ubuntu:24.04 with no digest. apt-get install for curl and unzip. A bash loop to pull the AWS CLI zip and the kubectl binary. No USER directive, so the container runs as root by default. No OCI labels. No hadolint. No lockfile for the base image.

# Before: single stage, implicit root, no labels, no digest pin
FROM ubuntu:24.04

RUN apt-get update && apt-get install -y curl unzip \
    && curl -o awscliv2.zip https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip \
    && unzip awscliv2.zip && ./aws/install \
    && curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl \
    && install kubectl /usr/local/bin/kubectl

ENTRYPOINT ["/bin/bash"]

The secure version after Phase 3 is a different image entirely. Multi-stage, so the build tools never ship in the runtime. Base digest pinned. An explicit USER 10001:0 so the container runs as a non-root account with root group (GID 0) for OpenShift SCC compatibility. A full set of OCI labels so Scout and GitHub actually know what they are scanning. The example below shows the structural changes only; the production Dockerfile in the repo additionally ships jq, envsubst, curl, and unzip in the runtime, writes the resolved kubectl version to /etc/kube-version as a drift-detection marker, and uses /usr/local/aws-cli as the AWS CLI install path.

# After: multi-stage, digest-pinned, non-root, OCI-labeled
FROM ubuntu:24.04@sha256:c4a8d5503dfb2a3eb8ab5f807da5bc69a85730fb49b5cfca2330194ebcc41c7b AS builder

ARG KUBE_VERSION=latest
RUN apt-get update && apt-get install -y --no-install-recommends \
        ca-certificates curl unzip \
    && curl -fsSL -o /tmp/awscliv2.zip \
        https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip \
    && unzip -q /tmp/awscliv2.zip -d /tmp \
    && /tmp/aws/install -i /opt/aws-cli -b /usr/local/bin \
    && curl -fsSL -o /usr/local/bin/kubectl \
        https://dl.k8s.io/release/${KUBE_VERSION}/bin/linux/amd64/kubectl \
    && echo "$(curl -fsSL https://dl.k8s.io/release/${KUBE_VERSION}/bin/linux/amd64/kubectl.sha256)  /usr/local/bin/kubectl" | sha256sum -c - \
    && chmod +x /usr/local/bin/kubectl

FROM ubuntu:24.04@sha256:c4a8d5503dfb2a3eb8ab5f807da5bc69a85730fb49b5cfca2330194ebcc41c7b AS final

LABEL org.opencontainers.image.source="https://github.com/heyvaldemar/aws-kubectl-docker"
LABEL org.opencontainers.image.licenses="MIT"
LABEL org.opencontainers.image.description="AWS CLI v2 + kubectl on Ubuntu 24.04"

RUN apt-get update && apt-get install -y --no-install-recommends \
        ca-certificates \
    && rm -rf /var/lib/apt/lists/* \
    && useradd --system --uid 10001 --gid 0 --create-home --home-dir /home/app --shell /sbin/nologin --comment "aws-kubectl runtime user" app \
    && chmod -R g=u /home/app

COPY --from=builder /opt/aws-cli /opt/aws-cli
COPY --from=builder /usr/local/bin/kubectl /usr/local/bin/kubectl
RUN ln -s /opt/aws-cli/v2/current/bin/aws /usr/local/bin/aws

USER 10001:0
WORKDIR /home/app
ENV HOME=/home/app

CMD ["bash"]

The production Dockerfile's KUBE_VERSION ARG defaults to latest and resolves to the current stable release at build time via kubectl's stable.txt channel; the example above keeps the same default, with the resolution logic elided for readability.

That missing USER directive is one of the most common findings in container security audits. In regulated industries it shows up as a late-stage compliance blocker. In security post-mortems it maps to privilege-escalation and lateral-movement patterns documented across years of incident reporting. In cloud-native environments it is the reason OpenShift restricted-v2 SCC refuses your pod. One line. Skip it, and the cost compounds every year the image gets pulled.

Full source, including CI workflows, the SECURITY.md disclosure policy, and the v1-maintenance migration guide, lives at github.com/heyvaldemar/aws-kubectl-docker.

Why this keeps happening

Sonatype's 2024 State of the Software Supply Chain report logged 512,847 malicious open-source packages over the preceding year. A 156% rise year-over-year.

Containers are a smaller slice of that total than npm or PyPI. The propagation model is the same. A base image ships, downstream teams pull it, and the maintainer's attack surface becomes the attack surface of every production cluster that pulled it. One compromised personal access token reaches a cluster in Frankfurt and a cluster in Singapore by the next morning, because the image digest has already rolled out through the nightly base rebuilds in both places.

Then there is the silence between the build and the consumer. Most public images carry no signature, no SBOM, no build provenance. A pull resolves a tag to a digest. That is the entire audit trail. Sigstore fixed the signing cost by making keyless cosign verification free through GitHub OIDC. BuildKit fixed the SBOM and provenance cost by making both a single build flag. The reason most images still ship without them is not that the tooling is hard. It is that nobody ran the migration.

And there is recency. OpenSSF Scorecard is new enough that most maintainers have never seen their own score. Running it once is a ten-minute workflow. Run it today and most public images would come back somewhere between 3 and 5.

Risk and blast radius

Direct exposure scales with pulls. Past 730,000 the image is well beyond the threshold where a single supply chain compromise reaches hundreds of downstream CI pipelines inside days. The pulls counter is an adoption metric. It is also a blast radius metric.

Systemic exposure is the harder calculation. A single maintainer account. A single personal access token with write:packages. A single compromised laptop. The OWASP Top 10 for CI/CD Security captures these as CICD-SEC-2 (Inadequate Identity and Access Management) and CICD-SEC-6 (Insufficient Credential Hygiene), and the attack pattern that dominated 2024 was exactly this chain. Hardening the build pipeline matters more than hardening the runtime of the image itself, because the runtime is downstream of whoever signed the image.

Regulatory exposure depends on who pulled the image. If any consumer runs it in a workload subject to EU NIS2, US Executive Order 14028, or financial regulatory frameworks that require SBOM attestations, the maintainer is inside the trust chain whether the maintainer asked to be there or not.

Options compared

For a solo maintainer the trade-off space is narrower than it is for a funded team. The table below is the honest comparison for public utility images under 1 GB.

Approach	Setup cost	Ongoing cost	Scorecard ceiling	Fit
Do nothing	0 hours	0 hours/month	~3/10	High risk above 100K pulls
Multi-stage + lint only	4 hours	30 min/month	~5/10	Minimum viable for public image
Add cosign + SBOM + SLSA	8 hours	30 min/month	~7/10	Recommended above 250K pulls
Full hardening + non-root	16 hours	1 hour/month	~7.8/10	Required for enterprise downstream use
Full + CII Best Practices badge	40 hours	2 hours/month	~8.5/10	Worth it only for funded projects

The jump from 5 to 7 costs four hours once. The jump from 7 to 7.8 costs another eight hours plus a breaking release. Getting from 7.8 to 8.5 costs forty hours of process overhead and tops out at a ceiling you do not control. I stopped at 7.8. For a solo maintainer the marginal return on the next tier goes negative.

Framework: supply chain hardening for solo maintainers

Three layers. Each one is a deploy cycle. The names track the migration topic family on purpose, because this is a migration from insecure defaults to attested defaults, not a fresh build from scratch.

Layer 1: inventory

The first goal is the audit, not the fix. You cannot harden what you have not measured.

# Layer 1: run once before any changes
# 1. Current Scorecard baseline
docker run -e GITHUB_AUTH_TOKEN=$GITHUB_TOKEN gcr.io/openssf/scorecard:stable \
    --repo=github.com/OWNER/REPO --show-details

# 2. Current Scout grade
docker scout quickview OWNER/IMAGE:latest

# 3. Trivy CVE baseline
trivy image --severity HIGH,CRITICAL OWNER/IMAGE:latest

# 4. Pin every base image to a digest and save the old Dockerfile
git mv Dockerfile Dockerfile.baseline

Run all four. Save the output. That Scorecard baseline is what you compare against once the hardening lands. On my run the starting numbers were Scout grade D, an OpenSSF score in the low single digits, and several HIGH CVEs from apt package lag.

Owner: the single maintainer.

Layer 2: parallel run

Phase 1. Multi-stage build. OCI labels. Hadolint in CI.

Phase 2. Cosign keyless signing. SBOM generation. SLSA build provenance. Trivy SARIF upload.

Phase 3. Non-root USER 10001 breaking release, plus a v1-maintenance floating tag for users who cannot migrate inside the window. Semver tags are kept forever by the tag cleanup policy and are the recommended target for production pins.

The signing job is the piece that earns the Cosign Verified badge and the SLSA provenance:

# Layer 2: .github/workflows/publish.yml (signing + attestation)
permissions:
  contents: read
  id-token: write
  packages: write
  attestations: write

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6

      - uses: docker/setup-buildx-action@4d04d5d9486b7bd6fa91e7baf45bbb4f8b9deedd # v4

      - uses: docker/login-action@4907a6ddec9925e35a0a9e82d7399ccc52663121 # v4
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - id: build
        uses: docker/build-push-action@bcafcacb16a39f128d818304e6c9c0c18556b85f # v7
        with:
          platforms: linux/amd64,linux/arm64
          push: true
          provenance: mode=max
          sbom: true
          tags: ${{ env.IMAGE }}:${{ env.VERSION }}

      - uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
        with:
          subject-name: ${{ env.IMAGE }}
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: false

      - uses: sigstore/cosign-installer@cad07c2e89fa2edd6e2d7bab4c1aa38e53f76003 # v4.1.1
        with:
          cosign-release: "v2.6.1"

      - run: |
          set -euo pipefail
          echo "${TAGS}" | while IFS= read -r tag; do
            [ -z "$tag" ] && continue
            cosign sign --yes "${tag}@${DIGEST}"
          done
        env:
          TAGS: ${{ steps.meta.outputs.tags }}
          DIGEST: ${{ steps.build.outputs.digest }}

Incident postmortem. During Phase 2 I first shipped the workflow above with push-to-registry: true. The signing step succeeded. The attestation push failed. Docker Hub's OCI referrers API silently rejected the credential handoff from the workflow. I re-ran the publish job with push-to-registry: false and shipped the fix as a hotfix. The fix is to keep attestations in GitHub Attestations (where they are retrievable by anyone with the digest) and skip the registry push until Docker Hub stabilizes its referrers behavior. Root cause: the referrers API expects a specific OCI 1.1 header format that the actions/attest-build-provenance v3 action does not negotiate cleanly against Docker Hub's current implementation. GHCR works. Docker Hub does not.

A second regression surfaced five days later, when I turned on Docker Hub tag immutability. The publish workflow had been generating a kube-v* tag on every push event, and that collided with the immutability policy and aborted the build before the cosign step could run. So main pushes shipped a new :latest digest each time without ever signing it. The fix scoped the kube-v* tag to semver release events only, and added set -euo pipefail plus per-tag error handling to the signing step shown above so future failures fail loud rather than silent. Floating tags are signing reliably again as of late April.

After Phase 2 the image carries keyless cosign signatures, an SPDX SBOM, and SLSA build provenance at mode=max, all traceable to the exact GitHub Actions run that produced them. After Phase 3 the default user is UID 10001 with GID 0, so the image drops straight into OpenShift restricted-v2 with no securityContext override.

Owner: the single maintainer.

Layer 3: cutover and continuous verification

Weekly automation is what holds the score at 7.8 instead of letting it drift back to 5 over time.

# Layer 3: .github/workflows/scorecard.yml
on:
  schedule:
    - cron: '0 6 * * 2'   # Tue 06:00 UTC
  push:
    branches: [main]

permissions: read-all

jobs:
  analysis:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      id-token: write
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6
        with:
          persist-credentials: false

      # Pinned to commit SHA, not tag SHA (annotated tags dereference differently)
      - uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a # v2.4.3
        with:
          results_file: results.sarif
          results_format: sarif
          publish_results: true

      - uses: github/codeql-action/upload-sarif@95e58e9a2cdfd71adc6e0353d5c52f41a045d225 # v4.35.2
        with:
          sarif_file: results.sarif

The comment on that Scorecard action pin is not paranoia. I hit an imposter commit error on the first publication attempt. Git has had two tag types since 2005: lightweight tags point directly at a commit SHA, and annotated tags point at a tag object that wraps the commit SHA. GitHub's git/refs/tags/:tag API returns whichever SHA the tag ref resolves to. Annotated tag in, annotated tag object SHA out. Scorecard rejects annotated tag object SHAs during its own verification step because they are not commit SHAs.

The fix is a second API call:

# Annotated tag: first call returns tag object SHA
gh api repos/ossf/scorecard-action/git/refs/tags/v2.4.3 --jq '.object'
# {"sha":"99c09fe...","type":"tag"}

# Dereference: second call returns the commit SHA
gh api repos/ossf/scorecard-action/git/tags/99c09fe... --jq '.object'
# {"sha":"4eaacf0543bb3f2c246792bd56e8cdeffafb205a","type":"commit"}

# Pin the commit SHA, not the tag object SHA
# uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a

A twenty-year-old distinction in Git. The kind that only breaks your publication on the day you need it to work.

Weekly base rebuild, weekly Scorecard re-run, weekly Docker Hub tag cleanup. Together they keep the maintenance budget under two hours a month. A tag retention policy that deletes sha-* tags older than 90 days keeps the tag list readable by humans and scanners alike. One caveat: users pinning by digest should pin to digests that are also referenced by a semver tag, so that purged sha-* tags do not orphan the digest.

Owner: the single maintainer, with Dependabot as the junior engineer that ships 80% of the ongoing patches.

Tradeoffs

The full program costs sixteen hours of initial work and roughly one hour a month of ongoing review. At typical senior DevOps contractor rates, that is a single billable sprint up front and a fraction of a day per month after.

Now price the alternative. A supply chain incident response engagement, forensics and containment and downstream notification, costs multiples more than a preventive hardening program's entire first-year budget. An SBOM attestation audit finding inside an enterprise procurement cycle can delay or kill multi-year contracts. The asymmetry is the whole argument. Look at the Codecov bash uploader compromise in 2021: it exposed credentials from customer CI environments across a two-month window before anyone detected it, through a single injected line of shell. Shell script, not container. Same propagation graph as a signed-nothing Docker image today.

The breaking release in Phase 3 costs a migration window, a v1-maintenance floating tag, and a migration guide in the README. Downstream teams can pin to v1-maintenance while they budget for a container base image bump.

The Scorecard findings that stay open at 7.8 are mostly honest. Code-Review scores 0/10 because I am the only reviewer. Branch-Protection scores 4/10 because I kept the admin bypass for emergency fixes. Fuzzing scores 0/10 because the image is a utility, not an application. These are trade-offs, not oversights. The score reflects them accurately, and that is the point of the program.

The closing argument

Public Docker images inherit the supply chain obligations of the projects that pull them, whether the maintainer accepts the responsibility or not. The tooling to sign, attest, and score an image is free, and the workflows run under 300 lines of YAML. Skip the migration and the cost compounds every month the image stays insecure by default. Run it and the cost is one sustained weekend of work plus about an hour a month afterward.

Sixteen hours once. One hour a month after. Seven hundred thirty thousand pulls protected from whatever compromise ships against the maintainer next.

Pull the image and verify it yourself:

cosign verify heyvaldemar/aws-kubectl:2.0.0 \
    --certificate-identity-regexp "https://github.com/heyvaldemar/aws-kubectl-docker/.*" \
    --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Every signature, SBOM, and build provenance record is public in GitHub Attestations.

Discussion

If you have hardened a public image past 7.0 on Scorecard, hit a Docker Hub referrers issue in production, or stuck with the do-nothing path and want to argue the cost-benefit, drop a comment below. Counterarguments welcome, and the comment thread is where I respond first. For longer back-and-forth with senior practitioners, join the discussion on Discord.

Cloudflare Web Analytics on Astro — Why Removing GA4 Unlocked Lighthouse 100

Vladimir Mikhalev (heyvaldemar.com) — Sat, 18 Apr 2026 00:00:00 GMT

A Saturday in April. This blog runs on Astro 6 behind Cloudflare, and it was stuck at 88 on mobile Lighthouse. The number had drifted between 83 and 88 over the prior month, depending on image payload. Neither figure passed a Lighthouse CI budget. The cover image needed 4.5 seconds to render on throttled 4G. So I went and looked at the stack. Cloudflare Web Analytics was already getting injected at the proxy layer. On top of that, Google Analytics 4 was pulling in roughly 70 KiB of gtag.js. Two analytics systems on one site. No reason for both.

I have watched this exact failure mode repeat across 20+ years of running observability in production. Telecom portals. Banking dashboards. Enterprise SaaS marketing sites. Someone bolts on a new measurement tool before anyone audits what the infrastructure layer already hands you for free. Cloudflare Web Analytics has been running server-side on this domain for over a year. GA4 on top of it was duplicate spend, paid in JavaScript execution time and GDPR exposure. Deleting it closed the Lighthouse gap and killed every third-party cookie in one commit.

What the stacked analytics configuration looks like

The problem rarely shows up in the source diff. It shows up in the Network tab.

A typical Astro layout adds GA4 the standard way, with a tag in <head>:

<!-- Astro layout with Google Analytics 4 (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

That buys you roughly 70 KiB gzipped for gtag.js with enhanced measurement on, plus an inline init block, plus third-party requests out to www.googletagmanager.com and www.google-analytics.com. Lighthouse flags the lot under "Reduce unused JavaScript", even on a site that never fires a single custom event.

The replacement is nothing:

<!-- Cloudflare Web Analytics: no client script required -->
<!-- beacon.min.js is injected by Cloudflare proxy when -->
<!-- orange-cloud DNS is enabled. CSP must allow -->
<!-- static.cloudflareinsights.com in script-src. -->

The beacon is injected at the proxy layer, and aggregation happens at Cloudflare's edge. The client pays for one small beacon instead of a 70 KiB analytics runtime. No cookies get set.

In over twenty years of running observability in production, I have never owned a performance budget where GA4's gtag.js paid for itself on a content site. Every performance review, same story: flagged, then ignored.

Why this keeps happening

Google Analytics is the default reach. Product managers know the GA4 reports. Marketing knows the GA4 dashboards. Bootcamps teach the GA4 snippet on day one. So it ends up installed even when the CDN layer already gives you analytics, and nobody ever audits the stack for duplication.

Cloudflare Web Analytics lives at the proxy layer. Proxy a domain through Cloudflare with orange-cloud DNS enabled and the static.cloudflareinsights.com/beacon.min.js script gets injected server-side. The beacon is tiny. Aggregation happens at Cloudflare's edge. No persistent identifier cookies are set by default.

Per Cloudflare's public documentation, Web Analytics ships on all plans, Free included. It anonymizes IP at the edge and sets no tracking cookies. That puts it outside the default scope of most cookie consent requirements. Your team still needs its own legal review for its own jurisdiction, though. Always.

Risk and blast radius

Direct exposure breaks into three categories.

First, GDPR and ePrivacy. GA4 uses cookies and processes personal data, which means explicit consent in the EU and UK, and increasingly under US state privacy laws too (CCPA, VCDPA, CPA). Cloudflare Web Analytics runs without tracking cookies. Back in February 2022, CNIL in France ruled that Google Analytics deployments can fall outside GDPR compliance, specifically over data transfers to the United States.

Second, the performance budget. That is 70 KiB of JavaScript to parse and execute on every first page load. Main-thread work spikes on mid-tier Android.

Third, data sovereignty. GA4 data sits in Google infrastructure, US by default.

The systemic exposure is the bigger one. Every page, every visit, carries the runtime cost. Take a 1,000-page documentation site serving 100K monthly visitors: that is real energy spent, latency added, and a permanent third-party dependency parked in the critical render path. Then your cookie consent management platform piles on another 20-50 KiB. Pull GA4 and you often pull the entire reason the CMP exists.

Options compared

Tool	Client JS (gzipped)	Tracking cookies	Data residency	Price	Fit
Google Analytics 4	~70 KiB	Yes	US (Google)	Free	Funnels, ad attribution, Google Ads integration
Cloudflare Web Analytics	0 additional (edge beacon ~1 KiB)	No	Cloudflare edge	Free on all plans	Traffic, Core Web Vitals, content sites
Plausible	~1 KiB	No	EU (Hetzner)	$9/mo and up	Privacy-first, public dashboards
Fathom	~1.6 KiB	No	EU or Canada	$15/mo and up	Privacy-first, simpler UX
PostHog (self-hosted)	20-50 KiB	Configurable	Your infrastructure	Infra only	Product analytics, session replay, feature flags

Don't read the table as "Cloudflare wins." Read it as the question is what you measure. A content site that needs pageviews and Core Web Vitals lands somewhere very different from an e-commerce funnel that needs attribution down to the ad creative.

Framework: From GA4 to Cloudflare Web Analytics

Layer 1 — Measure (week 1)

Run Lighthouse on mobile and desktop, capture current scores
Run PageSpeed Insights and pull CrUX real-user data for LCP p75 if the domain meets the traffic threshold; otherwise use Cloudflare RUM or self-hosted web-vitals collection
Open DevTools Network tab and list every third-party origin loaded on the home page
Check response headers to identify your CDN: cf-ray for Cloudflare, x-served-by for Fastly, x-nf-request-id for Netlify, x-vercel-cache for Vercel
Audit the CDN dashboard for built-in analytics you may not have enabled: Cloudflare Web Analytics, Fastly Observability, Netlify Analytics, Vercel Web Analytics

Owner: platform engineer or senior frontend.

Layer 2 — Remove (week 2)

Remove any analytics tool that duplicates what the CDN already provides.

Update CSP to allow the CDN beacon origin. For Cloudflare:

# CSP for Cloudflare Web Analytics on Astro + Cloudflare proxy
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline' https://static.cloudflareinsights.com;
  connect-src 'self' https://cloudflareinsights.com;
  img-src 'self' data:;
  style-src 'self' 'unsafe-inline';

Add fetchpriority="high" to the LCP image, meaning the hero image, first post card, or above-fold banner:

<!-- LCP candidate, Astro first-post card -->
<img
  src="/images/posts/first-post.webp"
  alt="First post cover"
  fetchpriority="high"
  loading="eager"
  width="1200"
  height="675"
/>

Then audit every <link rel="preconnect"> and delete origins that aren't in the critical render path. A dead preconnect steals a TCP slot from an origin that actually matters.

Owner: frontend lead plus security for CSP review.

Layer 3 — Gate in CI (week 3 onward)

Add Lighthouse CI to the build pipeline. Fail the build on regressions:

# .github/workflows/lighthouse.yml — Lighthouse CI gate
name: Lighthouse
on: [push, pull_request]
jobs:
  lhci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci && npm run build
      - uses: treosh/lighthouse-ci-action@v11
        with:
          urls: |
            https://heyvaldemar.com/
            https://heyvaldemar.com/latest-post/
          budgetPath: ./budget.json
          uploadArtifacts: true

Watch Cloudflare RUM p75 LCP weekly. Synthetic Lighthouse is a benchmark, not the truth. Real users on newer phones over better networks usually come in 30-50% faster than the Moto G Power / Slow 4G synthetic model.

Add a pre-push Git hook that runs astro check && astro build so a broken build never reaches the remote:

#!/usr/bin/env bash
# .git/hooks/pre-push — block push on failed Astro build
ZERO_SHA="0000000000000000000000000000000000000000"
while read -r local_ref local_sha remote_ref remote_sha; do
  # Skip verification on branch delete
  [ "$local_sha" = "$ZERO_SHA" ] && exit 0
done
npx astro check && npx astro build

Owner: platform engineer.

Tradeoffs

Cloudflare Web Analytics does less than GA4. No funnels. No deep custom event schemas. No native Google Ads integration. For content sites, documentation, and most engineering-led blogs, none of that is a loss you will feel. Conversion-heavy e-commerce with retargeting pipelines is the exception, where GA4 might still earn its weight, though even there the stronger answer is usually a privacy-first product analytics tool (Plausible, Fathom, or self-hosted PostHog) over client-side GA4.

The other tradeoff is CDN alignment. Move the site off Cloudflare and the beacon goes with it. That is not a hard lock-in, since competing CDNs ship their own first-party analytics, but it is worth naming in any architecture review.

The cost of the alternative is concrete. 70 KiB of JavaScript on every pageview. A cookie consent banner. GDPR exposure. A standing regression against any performance budget you set. On mid-tier Android over a mid-tier network, that 70 KiB is a real LCP penalty. I have watched Lighthouse scores camp at 92-94 for months because a team would not question the GA4 install.

The closing argument

The strongest case against GA4 on a content site in 2026 is not privacy, and it is not performance. It is supply chain. Every third-party script in your critical render path is code you did not write, cannot audit, and still inherit the blast radius of. Cloudflare Web Analytics is not better because it is faster. It is better because it is one fewer trust boundary.

The privacy alignment is a bonus. The LCP improvement is a bonus. The actual architectural position is simpler: observability tooling should come from the infrastructure layer you already trust, not get bolted on top of it.

Sources

Web.dev, "Fetch priority to improve LCP", https://web.dev/articles/fetch-priority, 2024
Cloudflare, "Web Analytics product documentation", https://developers.cloudflare.com/web-analytics/, ongoing
Google, "gtag.js reference", https://developers.google.com/tag-platform/gtagjs/reference, ongoing
CNIL (France), "Use of Google Analytics and data transfers to the United States", https://www.cnil.fr/en/use-google-analytics-and-data-transfers-united-states-cnil-orders-website-manageroperator-comply, February 2022
Astro Docs, "Image optimization", https://docs.astro.build/en/guides/images/, ongoing

Discussion

If you have removed GA4 on a production site, or kept it and have the numbers to justify it, drop a comment below. Counterarguments welcome. For longer back-and-forth with senior practitioners, join the discussion on Discord.

The Intake Gate Your CISO Is Missing — 300 Million AI Chat Messages Were Public by Default

Vladimir Mikhalev (heyvaldemar.com) — Sun, 15 Mar 2026 00:00:00 GMT

In January 2026, a security researcher poked at a consumer AI chat app called Chat and Ask AI and found something stupid. The Firebase Realtime Database behind it was set to public read. No token. No auth of any kind. Around 300 million private chat messages, tied to roughly 25 million users, sat there openly queryable for a long stretch before anyone flagged it and shipped a fix.

And the content was not small talk. People had typed in medical questions, legal problems, financial details, the kind of private disclosures you would not say out loud in an office. The vendor patched within hours of disclosure. That part was fine. But the window was already open, and the data was already sensitive, so the liability sticks. To the vendor, sure. Also to any company whose staff used the tool for work.

On its own this is a bad day for one app. As a pattern it is much worse. Researchers then scanned 200 iOS apps running on Firebase and found 103 of them carrying the exact same public-access mistake. More than half. So this is not one careless vendor. It is the whole category falling over.

What the misconfiguration actually looks like

Before we get to governance, look at how trivial the failure is. Firebase Realtime Database uses security rules to gate reads and writes. The bad default that caused this breach reads like this:

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

That hands any unauthenticated HTTP request full read and write over the entire database. Every message. Every username. Every session. Available to anyone who can build the right URL.

A locked-down version forces authentication and scopes each user to their own records:

{
  "rules": {
    "chats": {
      "$userId": {
        ".read": "$userId === auth.uid",
        ".write": "$userId === auth.uid"
      }
    }
  }
}

Six lines of JSON. That is the entire gap between "300 million messages exposed" and "data properly isolated." Nobody got clever here. A default went unchecked, and that was enough.

I have led plenty of platform engagements where third-party AI tools were in scope. In every one of them, the backend access config was either unknown to the team adopting the tool, or waved off as something the vendor handled. It never was handled. The pattern does not change: teams pick AI tools on features and never look at the infrastructure underneath. Run that gap at scale and the Firebase breach is what you get. It was always coming.

The governance gap

Firebase actually ships locked down. No reads, no writes, nothing open by default. But the setup wizard dangles a test mode with full public access for prototyping, and developers push that test config straight to production. Why? Because no review step forces anyone to close it before launch.

Most companies have grown-up intake for SaaS that touches email, CRM, or money. AI chat tools slipped right past all of it. An employee downloads one on a whim. A team brings one in without ever calling procurement. And the backend config, the thing that decides whether user data is locked or wide open, gets checked by exactly nobody on the adopting side.

Thales' 2026 Data Threat Report puts numbers on how wide this gap runs. Only about a third of surveyed organizations say they actually know where all their data lives, and that is while AI tools are being handed broad internal access. Sixty-one percent name AI as their top data security risk. Seventy percent say the pace of AI-driven change is their single biggest security challenge. The concern is clearly there. What is missing is the bridge to control: the intake gate, the config check, the access audit. Most shops do not have it.

Risk and liability

Liability here works on two levels.

Direct exposure. Any company whose employees ran Chat and Ask AI, or any of the other 103 broken apps, for work conversations is now looking at possible regulatory notification duties. If someone pasted in PII, protected health information, legal privilege, or financial material, that can pull in GDPR, HIPAA, state breach notification laws, or sector rules, depending on jurisdiction and how the data is classified.

Systemic exposure. Leadership gets a nastier question. If more than half of AI apps on a major backend carry the same flaw, what are the odds your own employees are using at least one of them right now? With no central AI tool inventory, you cannot answer that. And "we didn't know" does not hold up in front of a regulator.

IBM's 2026 X-Force Threat Intelligence Index piles on. Over 300,000 stolen ChatGPT credentials were found floating around through infostealer malware. AI chat platforms are now a prime target for credential theft. So the exposure is not just misconfigured backends. It is also compromised accounts on the platforms your people log into every day.

Blast radius

The Firebase incident by itself is already large: 300 million messages, full chat histories, usernames, sensitive content. But the systemic read, 103 of 200 apps broken, turns it from a one-vendor story into a supply-chain problem for anyone who lets staff use third-party AI tools without checking the backend.

What pushes the risk up a tier is the compounding. Thales reports 67% of organizations name credential theft as the main attack vector against cloud. Nearly 60% have already been hit by a deepfake incident. Stack misconfigured AI backends on top of stolen AI credentials on top of missing data classification, and you get a compound exposure that no single fix can clean up.

There is a cost angle too, and it almost never makes it into the incident writeup. AI data retention you cannot measure, spread across several tools and cloud regions, quietly bloats storage and compliance spend. If you cannot even list which AI tools are holding your data, you cannot enforce data minimization or retention. Both of which regulators are leaning on harder, under GDPR and the newer US state privacy laws alike.

Control protocol: specific tooling, not generic advice

The control framework runs in three layers: visibility, then identity enforcement, then continuous verification. Each one names the actual tooling you need, not just the principle behind it.

Layer 1 — Visibility (Days 1–7)

Objective: Know what AI tools are in your environment. Block what you have not verified.

Network-layer blocking: Deploy a Secure Web Gateway (Cloudflare Gateway, Zscaler Internet Access, or Netskope) with a deny-by-default policy for uncategorized AI/ML SaaS domains. Maintain an explicit allowlist for approved tools only.
Endpoint-layer blocking: Push MDM policies (Intune, Jamf, Kandji) to prevent installation of unapproved AI applications on managed devices.
AI tool registry: Publish a central registry (a shared spreadsheet is adequate for Week 1; migrate to a proper SaaS inventory tool like Productiv, Zylo, or Torii for scale). Every external AI tool used for work must be listed, owner-assigned, and approved before use.
One-time backend audit of approved tools: For any approved tool using Firebase, run an open-source Firebase auditing tool (such as Baserunner) or use curl against the Realtime Database REST endpoint to confirm that unauthenticated reads are rejected:

# Quick check: if this returns data, the database is publicly readable
curl -s "https://<project-id>.firebaseio.com/.json"
# Secure response: {"error":"Permission denied"}
# Insecure response: actual database contents

Layer 2 — Identity Enforcement (Days 8–14)

Objective: Elevate AI platforms to the same identity governance tier as your CRM and financial systems.

SSO-only access: Require SAML/OIDC integration for all approved AI tools. Configure this in your IdP (Okta, Entra ID, Google Workspace). Tools that cannot integrate with SSO are disqualified from the approved list — no exceptions.
Mandatory MFA: Enforce phishing-resistant MFA (FIDO2/WebAuthn preferred) for AI platform access via conditional access policies.
Vendor attestation: Add a backend security configuration attestation to procurement and renewal checklists. Require vendors to confirm: (1) no public-access database rules, (2) encryption at rest and in transit, (3) data residency and retention policy. This is a procurement process change, not a technical deployment.
Credential rotation: For any AI platform where credentials may have been exposed, force password rotation and revoke existing API tokens immediately.

Layer 3 — Continuous Verification (Days 15–30, then Ongoing)

Objective: Detect vendor configuration drift and anomalous AI tool usage before they become incidents.

Automated configuration scanning: Schedule quarterly (minimum) automated checks against approved AI tool backends. For Firebase-backed tools, integrate the curl check above into your CI/CD or security scanning pipeline. For broader SaaS posture management, evaluate SSPM tools (Obsidian Security, AppOmni, Adaptive Shield).
Usage telemetry integration: Forward AI tool access logs and network-layer SWG logs into your existing SIEM (Splunk, Sentinel, Chronicle). Create detection rules for: (1) access to unapproved AI domains, (2) bulk data transfer to AI tool endpoints, (3) AI tool access from unmanaged devices.
OPA/Rego policy enforcement (for platform engineering teams): If you manage infrastructure as code, enforce AI tool backend security requirements as policy. Example OPA rule that rejects Firebase deployments with public access:

package firebase.security

deny[msg] {
    input.rules[".read"] == true
    msg := "BLOCKED: Firebase rules allow unauthenticated public read access"
}

deny[msg] {
    input.rules[".write"] == true
    msg := "BLOCKED: Firebase rules allow unauthenticated public write access"
}

Incident response playbook: Establish a dedicated IR playbook for third-party AI tool data exposure. Include: regulatory notification timelines by jurisdiction (72 hours for GDPR), data classification triage procedures, vendor communication templates, and employee notification protocols.

Operational friction vs. liability exposure

The friction is real. Block unapproved AI tools and you will hear from the business units that quietly started using them to move faster. Vendor attestation slows procurement down. SSO-only access will knock out popular consumer-grade tools that teams have already gotten fond of.

The exposure is worse. Skip this control layer and your organization eats the regulatory and financial risk of every broken third-party backend, every stolen credential set, every unclassified disclosure, across every AI tool every employee has ever touched.

The math: A GDPR breach notification proceeding, counting legal counsel, forensic audit, regulator back-and-forth, and a possible fine, starts in the six figures for a mid-size enterprise. Now multiply by however many broken tools your people may have used. Set that against the cost of one Secure Web Gateway policy update and a procurement checklist revision.

If you run anything in a regulated environment, there is nothing to debate. Control is the only posture you can defend.

Executive verdict: adopt and enforce

The Firebase misconfiguration is not a fluke. It is a confirmed, systemic failure across more than half of the apps tested in this category. The fix is not one more security product. It is operational discipline with specific, auditable controls behind it.

Gate the AI tools before they reach your employees. Verify the backend config before you approve anything. Hold AI platforms to the same identity governance you already demand from your CRM and financial systems.

The companies that come through the next wave of AI-driven breaches will not be the ones with the fattest security budgets. They will be the ones with the most ruthless intake. The gate before the tool. The review before the deployment. The registry before the incident.

The Monday morning directive

Executives do not sit there auditing Firebase instances by hand. They tell their teams to. If you are forwarding this brief to your CISO, Head of Infrastructure, or IAM lead, attach this exact mandate:

"Review the attached brief on the systemic backend misconfigurations in AI chat apps. By EOD Wednesday, I need: 1. A verified list of all third-party AI chat tools currently accessed from our network — pull SWG/proxy logs for the last 90 days. 2. Confirmation of whether each tool is gated behind SSO and MFA, and whether any use Firebase or similar BaaS backends. 3. An execution plan to block unapproved tools at the MDM and network layer by end of next week, and a procurement checklist update requiring backend security attestation for all AI tool renewals."

I Tested an AI Agent on My Live Systems. Here Is the Blast Radius Assessment Every Engineer Is Skipping.

Vladimir Mikhalev (heyvaldemar.com) — Sun, 22 Feb 2026 00:00:00 GMT

An AI agent went viral last week. The creator got hired by OpenAI within days of the announcement. Instagram reels with seven-figure view counts are telling engineers to wire the agent into their inbox, their CRM, their project tools, and then step back. The pitch is simple. Autonomous execution. Zero oversight. Hours of your week handed back.

I built an isolated Mac environment and ran the agent through every task I could think up.

The software worked. The concept did not survive contact with a real operational context.

The agent can do the work. That was never the question. The question is what happens when it does the work wrong, and whether you find out before your client does.

So this is not a review of OpenClaw. It is an analysis of the deployment decision itself, and of why the question most engineers are asking is the wrong one.

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

The Wrong Question

The wrong question is: what can this agent do?

The demo answers that one cleanly. It summarizes emails. It updates CRM records. It drafts replies and pushes Notion updates. Every one of those runs fine in a controlled environment with clean data, clear intent, and no ambiguity to trip over.

Production is none of those things. It carries relationship context the model cannot see. It runs on implicit rules the team enforces but never wrote down. And it lives in communication threads where tone, timing, and word choice carry business consequences that no training set has fully encoded.

The right question is: what can this agent break, and what is the recovery time?

That is an architectural question. Most of the engineers buying Mac Minis this weekend are not asking it.

Blast Radius: The Metric That Determines Safe Deployment

Blast radius comes out of system reliability engineering. Applied to an agent, it measures the maximum damage that agent can do with the permissions it holds right now, and whether that damage is reversible inside a recovery window you can actually live with.

Every permission you grant is a ceiling on that radius. Read access to one email thread sits low. Write access to the primary inbox does not. Its ceiling includes unauthorized client commitments, archived active deals, and reputational damage that no rollback command will undo.

Before an agent touches a live system, every permission gets its own assessment:

What is the worst action this agent can take with this permission? Is it reversible? In under ten minutes?

If the answer to either of the last two is no, that permission does not belong in production.

Why Slack and Email Are the Highest-Risk Starting Points

The hype cycle reaches for email and messaging as the first integration. Architecturally, that is backwards.

Slack

Slack carries organizational hierarchy in every channel. Say the agent reads a ticket thread. It does not know that pinging a VP in a public channel about a P3 issue is a career event, not a notification. It does not understand that some threads are politically loaded, or that a confident summary dropped in front of leadership shifts the conversation in ways no rollback touches.

A misclassified priority, escalated on its own, in front of the wrong audience, is not an automation failure. It is a political incident with your name on it.

Email

Email carries relationship context stretching back months or years. The agent reads a thread. It does not know this client is mid-negotiation. It does not know the last message you sent was deliberately vague to keep the conversation open. It answers with precision, reads the literal text, and misses the intent entirely.

An autonomous send from your address, to a client, misreading an open negotiation, is not an automation failure. It is a business incident. It may be a legal one.

These are the systems that should get agent write access last, not first.

The Deployment Framework

1. The Empty Mandate Test

Before anything ships, the agent has to pass the Empty Mandate Test. You define the task in one sentence. Not a category. Not a workflow. One specific, repeatable task.

✅  "Summarize tier-1 support tickets into a daily Slack brief."

That one gets a deployment date.

❌  "Manage my communications."

That one does not.

If you cannot write it in a single sentence, the agent has no job description, and it should not be near your systems.

2. The Staged Promotion Model

Safe deployment runs through a promotion model. It is never a single-step connection.

Stage 1 → Read-Only Observation. The agent can reach the system but cannot write, send, or modify anything. It observes, summarizes, surfaces patterns. You study its output across at least thirty real interactions. You write down where it hallucinates, where it misclassifies, and where the context window hands you a confident summary that happens to be wrong.

Stage 2 → Draft-Only Access. The agent produces outputs that need human review and explicit approval before anything happens. Every email draft gets read. Every CRM note gets read before it is saved. The agent proposes. The Architect approves. This is not friction. It is validation data.

Stage 3 → Supervised Execution. Once Stage 2 behavior holds up, the agent gets scoped write access for one defined, low-blast-radius task. One task. One system. Logged, and reviewed weekly.

Stage 4 → Earned Autonomy. Autonomy is a reward for proven reliability. It is not a switch you flip at install time. You extend it in small increments, and a revocation plan stays live at every stage.

In any high-stakes context, most agents never reach Stage 4. That is the correct outcome. Controlled output at Stage 2 or 3 beats uncontrolled autonomy at Stage 4 every time.

The Notion Problem Nobody Is Talking About

Notion sits at the center of most knowledge-heavy workflows. It holds architecture decisions, project context, client notes, and institutional memory built up over years.

An agent with write access to a live Notion workspace is operating on the organizational brain.

It will reorganize. It will deduplicate. It will decide some pages are redundant and merge them. And it will do all of this with total confidence, on pattern matching alone, with no idea why a page exists in its current shape or who leans on that shape.

You do not see the damage right away. It shows up three weeks later, when someone opens a page that got rewritten and finds the original context gone.

Notion needs the most conservative assessment of anything in a typical stack. Read-only on specific databases is where you start. Unrestricted write access is not on the roadmap until the behavior has been validated in isolation for a long stretch.

The Architectural Verdict

Agents are a real capability. The use case is legitimate. At the right scope, the efficiency gains are measurable.

The deployment philosophy being sold in this hype cycle is not. It skips the blast radius assessment outright. It treats autonomy as a feature to switch on, not a property to earn.

The architect's job is not to chase the demo. It is to map the worst case before the first API key gets issued.

Read-only first. Draft-only second. Scoped writes after validated behavior. Earned autonomy last, if at all, in high-stakes systems.

That sequence is not caution. It is architecture.

The engineers who skip it will have their recovery story inside six months. The Architects who follow it get a deployment they can stand behind.

Amazon Project Dawn Cut 30,000 Jobs — Including the Head of AWS Community Builders. Here's What It Means.

Vladimir Mikhalev (heyvaldemar.com) — Fri, 06 Feb 2026 00:00:00 GMT

Amazon's "Project Dawn" isn't a restructuring. Call it what it is.

30,000 jobs eliminated.

Among them: Jason Dunn, the architect and leader of the AWS Community Builders program.

Not an underperformer. Not redundant.

He built one of the most visible developer community programs in the cloud industry. Then Amazon cut him anyway.

This was never about Jason's performance. It was about efficiency.

CEO Andy Jassy said it out loud back in June 2025:

"AI will reduce our total corporate workforce as we get efficiency gains."

Not might. Will.

The company that pioneered developer community-led growth just laid off the person running that community. That isn't a headcount decision.

It's a signal.

The Question Every Community Member Should Ask

I hold 9 vendor-recognized community titles. Docker Captain. IBM Champion. AWS Community Builder. Six more ambassador programs across security, testing, platform engineering, and infrastructure.

So when Amazon cuts the person who built the AWS Community Builders program, the program I'm part of, I don't get to look away. This is my world.

And the honest question is this:

If community programs can't prove ROI, what protects them during the next round of cuts?

For a decade the tech industry ran on one playbook. Give developers status and a platform, and they'll evangelize your product. It worked. It built ecosystems, and it built careers. Mine included.

But the market is shifting.

AI can generate tutorials in 30 languages, around the clock, for free. Generic "10 Reasons to Use Kubernetes" content is commoditized now. And companies are asking harder questions about what these programs actually deliver to the bottom line.

Engagement metrics aren't enough anymore.

What's Actually at Risk

Let me be specific about what's exposed and what isn't.

Vulnerable:

Community members whose only contribution is resharing vendor content
Ambassadors who collect badges but don't produce original technical work
Programs that measure success in "impressions" and "engagement" but can't tie activity to pipeline or adoption

Not vulnerable:

Community members who publish original research and production-tested frameworks
Ambassadors who provide direct product feedback that shapes roadmaps
Programs where members are genuinely embedded in enterprise decision-making

The difference isn't status. It's substance.

A badge without production credibility is just a badge. A badge backed by published work, real architecture decisions, and proven enterprise impact is a trust signal no AI agent can replicate.

What I've Learned From 8 Programs

I've been inside these programs for years. Here's what I've watched succeed, and what I've watched fall flat.

What works:

Publishing on vendor blogs, not just your own. I've written 7+ articles on Docker's official blog plus 2 enterprise case studies. That content lives on Docker's domain, drives their SEO, and shows real enterprise use cases. The relationship runs both ways. Docker gets credible content, and I get a platform with direct access to product leadership.

Giving real product feedback. Docker Captains don't just evangelize. We test pre-release features, file bugs, challenge architectural decisions, and push back when something breaks in production. That feedback loop is genuinely valuable to the vendor, and you can't automate it.

Pairing community work with production experience. Every framework I publish, every architecture pattern I share, comes from running real infrastructure at a Series D enterprise serving Fortune 500 clients. That's not content. That's evidence.

What doesn't work:

Collecting titles without producing anything original. Six badges and zero published articles on your ambassador profile? You're a consumer, not a contributor.

Writing generic tutorials that AI can crank out faster. "How to Deploy a Docker Container" is a commodity. "How We Secured a Multi-Region Container Supply Chain at Enterprise Scale" is not.

Treating community as a stand-in for career development. A Slack channel is not job security. Production credibility is.

The Community That Survives

Community isn't dying. It's evolving.

The programs that survive the efficiency era will be the ones where:

Members produce work that directly impacts vendor product decisions
Content is grounded in production experience, not theoretical tutorials
The relationship between vendor and community is measurably mutual
Members bring enterprise context that AI cannot replicate

I've watched this happen up close. When Docker publishes a case study based on my work at Ataccama, that isn't "engagement." It's a sales asset. When IBM recognizes me as a Champion for turning field requirements into product insights, that isn't "goodwill." It's product intelligence.

The value was always there. The programs that survive are the ones that can prove it.

What To Do If You're in a Community Program Right Now

Hold ambassador or community titles? Here's the framework I'd use.

1. Audit your contribution. How many original pieces have you published in the last 12 months? Not reshares. Not retweets. Original technical content grounded in your own experience. If the answer is zero, you're consuming, not contributing.

2. Connect your community work to production. Every blog post, every talk, every framework should point back to real work. "I tested this in my environment" beats "here's how the docs say it works."

3. Build direct relationships with product teams. The real value of these programs isn't the badge. It's the access. So use it. Give feedback. Challenge decisions. Be the person product leadership thinks of when they need a field perspective.

4. Own your IP. Publish on your own platform alongside the vendor blogs. Build a body of work that exists independently of any single program. If a program shuts down tomorrow, your published work survives.

Jason Dunn's layoff is a signal. But the signal isn't "community is dead."

The signal is this: prove the value, or risk being classified as a cost center.

I've got 9 active titles, 500,000+ Docker Hub pulls, and 7+ articles on Docker's official blog. So I take that signal seriously. My response is to double down on substance, not walk away from community.

The developers who thrive in the efficiency era won't be the ones who abandoned community programs.

They'll be the ones who made those programs undeniably valuable.

Infosys Deploys Devin AI Globally — And Your DevOps Career Just Became Legacy Labor

Vladimir Mikhalev (heyvaldemar.com) — Wed, 04 Feb 2026 00:00:00 GMT

Infosys is a $100 billion systems integrator. It serves Fortune 500 clients. And it just announced the global deployment of Devin AI across its entire delivery organization.

Not a proof-of-concept.
Not a limited trial.
Global. Standard. Deployed.

The decision followed a six-month pilot that, in their words, showed "significant gains in engineering efficiency and quality." On that basis Infosys embedded Devin into its delivery models and customer environments worldwide. Cognition Labs, the company behind Devin, says the agent is already running inside engineering teams at thousands of companies. They've also just shipped a faster, more capable version tuned specifically on junior developer benchmarks.

Maybe your pitch is "I execute technical tasks efficiently." If you're a DevOps engineer, a platform engineer, a cloud architect, that announcement should land like the ground shifting under you. Because it is.

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

What Infosys Just Told the Market

Read the move plainly. Here is what it says.

Infosys operates at scale.
They run infrastructure, platform engineering, and application delivery for some of the largest enterprises alive. When a company that big standardizes an AI agent across its global delivery pipeline, that's not a speculative bet. It's a calculated business call backed by proven ROI.
The six-month trial delivered.
Efficiency went up. Quality went up. Cycles got faster and labor got cheaper. None of that is hypothetical. Those are measured outcomes, and they were enough to justify adoption across the whole company.
Devin is now sitting in client environments.
This is not an internal toy. Infosys is putting Devin into customer engagements. Which means enterprises now expect AI-augmented delivery as the floor. Human engineers become the exception, not the default.
Cognition Labs is scaling hard.
Thousands of companies already run Devin. The new agent is faster and tuned for junior-level work, which is exactly the work entry and mid-level engineers do all day.

So the message is not subtle. If your job is to execute technical tasks, your competition is an AI agent that works around the clock, never negotiates salary, and gets better every quarter.

The Two Traps Most Engineers Will Fall Into

Hit with this news, most engineers pick one of two reactions. Both are traps.

Trap 1: "AI Can't Replace Me"

The first one is denial wearing the costume of domain expertise.

"Devin doesn't understand business context."
"AI can't handle legacy systems."
"I know the client. I understand the nuances."

Every one of those is true. And none of it matters.

Because the question was never "Can Devin do your exact job today?"
The question is this. Can Devin do 80% of your job at 10% of the cost?

Infosys just answered it. Yes.

So if your pitch is "I execute technical tasks with domain context," you aren't safe from automation. You're expensive automation. And in enterprise procurement, expensive automation is the first thing on the chopping block.

Trap 2: "I'll Just Become an AI Engineer"

The second reaction is lateral panic.

"I'll learn prompt engineering."
"I'll pivot to AI/ML."
"I'll become an AI engineer."

Sounds logical. It's a move into commoditization, not out of it.

AI engineering is already crowded. Thousands of mid-level engineers are running the same play this quarter. The market is full of "AI-augmented DevOps engineers" who can wire up LangChain and fine-tune a model.

That's not escaping the race to the bottom. That's changing lanes inside it.

The Only Path Forward: Stop Competing on Execution

Here's the part most engineers won't sit with.

Build your career on technical execution and you're now in a war of attrition against AI agents.

The engineers who survive the Devin Age, and the ones who actually thrive, share one thing. They own the decision, not the execution.

I call that the Solutions Architect Class.

What Does a Solutions Architect Do?

A Solutions Architect doesn't write Terraform. They write the architectural mandate Devin executes.

They don't configure Kubernetes. They hand down the Verdict on whether Kubernetes is even the right answer for the client's business problem in the first place.

They don't race the AI. They point it.

The Difference Between Labor and Leadership

Infosys deploying Devin is not a tragedy. It's a filter.

It filters out everyone who thought "knowing Docker" was a career. It filters out everyone who thought "being technical" was the whole job. What's left is the line between labor and leadership.

Labor is replaceable. Leadership is rare.

Labor executes tasks. Leadership delivers verdicts.

Labor fights on speed and cost. Leadership wins on strategic value.

How to Transition to the Solutions Architect Class

If you're a junior or mid-level engineer right now, two doors are open.

Option One:
Compete with Devin on execution. Race to the bottom. Chase $40/hour contracts because "AI can't do everything yet."

Option Two:
Become the architect. Learn to diagnose business pain, design systems at the business layer, and treat Devin as your junior engineer.

Option Two needs a blueprint. Most engineers don't have one.

The path starts with learning to think like a Solutions Architect.

Which means learning how to:

Architect solutions at the business layer, where Devin has no access.
Position yourself as the Verdict, not the executor.
Deliver architecture decisions that pull in inbound offers instead of you firing off outbound applications.

The Market Has Spoken

Infosys just showed you the future.

Devin is here. It's deployed. It's scaling.

So the question is simple.
Are you labor, or are you leadership?

Keep competing on execution and you're already obsolete. Decide to become the architect and the opening in front of you is unlike anything before it.

The Blueprint is waiting.

The End of the Executor — Why Computer Vision Engineers Are Becoming Optional

Vladimir Mikhalev (heyvaldemar.com) — Tue, 27 Jan 2026 00:00:00 GMT

The Signal Nobody Wants to Talk About

At CES 2026, a company called Anisoptera launched Dragonfly—a no-code platform for building production-grade computer vision applications. It won a CES Picks Award. It's enterprise-ready. And it markets itself, in plain language, as the fix for "the bottleneck of scarce AI talent."

In other words: You are the bottleneck. And they built a product to remove you.

So if you build computer vision systems, run MLOps, or wire up edge AI infrastructure, read this as a warning. Dragonfly itself isn't special. What it shows is the part that should worry you: a quiet trend just went public. Specialized engineering roles are being turned into products.

In the breakdown above, I go through the platform, the pricing, and why your career is sitting inside the blast radius right now.

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

What Dragonfly Actually Is

Dragonfly is a full-stack, no-code platform. Here is what separates it from the usual "low-code" vaporware:

Hardware + Software Subscription: You don't need cloud infrastructure. You don't need Kubernetes. Dragonfly runs on-premise, at the edge, on their hardware. It is a turnkey solution.
Designed for Non-Technical Users: The target user is not a data scientist. It is a line-of-business manager—someone in logistics or retail who has a problem but no ML team.
Explicit About Replacing Talent: The press release doesn't hide the intent. It frames "scarce AI talent" as the constraint. Translation: You are expensive, slow, and hard to manage. We are designing you out.

This is not a tool for engineers. It is a replacement for them.

Why This Is a Threat (Even If You Don't Work in CV)

Backend engineer? NLP engineer? You might figure none of this touches you. You would be wrong.

Dragonfly is a signal. It proves you can take a deeply specialized discipline, the kind that used to demand a PhD, and ship it as a subscription. If they pulled that off for computer vision, the same thing is coming for:

NLP: GPT wrappers are already replacing custom model training.
Data Pipelines: Tools like Fivetran are killing the "ETL Engineer" role.
Infrastructure: Platform engineering is being abstracted by AI agents.

The pattern is clear. Execution-level skills are being automated. Architectural skills are not.

So ask yourself the obvious question. Are you an executor, or are you an architect?

The Executor vs. Architect Divide

Let me define the terms.

Executors are engineers whose job is to implement solutions. They:

Write the code
Tune the model
Deploy the container

Architects are engineers whose job is to design systems. They:

Evaluate build-vs-buy tradeoffs
Design hybrid architectures
Negotiate vendor contracts

Here is the brutal truth. Executors are in the blast radius. Architects are not. Dragonfly doesn't replace the person who decides whether to use Dragonfly. It replaces the person who would have built the vision system by hand.

What To Do About It (The Solutions Architect Framework)

Feeling uncomfortable? Good. It means you're paying attention. Here is the framework.

1. Stop Learning Tools. Start Learning Systems. Drop the certification chase. YOLO, PyTorch, all of it. Those are execution skills. Learn to evaluate vendor platforms instead. Learn to calculate TCO (Total Cost of Ownership). Learn to design hybrid systems. That work takes judgment, not syntax.

2. Learn to Speak Business. Dragonfly gets sold to managers because it talks in their terms: ROI and Time-to-Deployment. Can't explain why your custom Python script beats a $5k/month tool in terms of business risk? Then you lose.

3. Become a Solutions Architect. A Solutions Architect doesn't write code. They deliver verdicts. They weigh the options (Dragonfly vs. Custom), design the architecture, and make the final call. The role is AI-proof for one reason. It carries accountability.

The Verdict

Dragonfly is not the problem. It is the signal. The engineers who survive are the ones who move up the stack, from execution to architecture.

The full tactical breakdown is in the video above.

AI Didn't Fix Productivity. Measurement Did.

Vladimir Mikhalev (heyvaldemar.com) — Fri, 12 Dec 2025 00:00:00 GMT

Something strange is going on in software engineering right now.

The 2025 Stack Overflow Developer Survey says 84% of developers already use—or plan to use—AI tools. More than half reach for them every day. So adoption isn't the bottleneck. AI showed up everywhere, and it showed up fast.

But talk to engineering leaders and you hear the same line over and over:

“We're paying for AI tools… but we can't prove they're making us more productive.”

That distance between usage and evidence is what I call the AI productivity paradox. Buying AI is easy. Proving impact is hard.

Why AI Productivity Is So Hard to Measure

Almost none of our engineering metrics were built for this.

Take DORA. It can show you that deployment frequency moved. It can't tell you why it moved. Pull request volume goes up, fine. Is that real productivity? Or is it AI spitting out code that someone now has to review?

The way AI bends a workflow is rarely obvious. It speeds you up in one place and quietly piles on technical debt, duplicated code, or extra cognitive load somewhere else. With no instrumentation, leaders are guessing. Guessing costs money.

That's where the pressure builds. The CFO wants ROI. The CTO has standardization calls to make. And the data you'd need to answer any of it is scattered across git logs, surveys, dashboards, and somebody's hallway anecdote.

Why GitKraken Is in a Unique Position Here

Developer productivity isn't only a data problem. It's a trust problem.

GitKraken has spent over a decade building tools developers actually choose to use. That counts for more than most leaders think. When developers don't trust the thing measuring them, every number it produces is worthless.

Their AI features already prove the point. Intelligent merge conflict resolution. AI-generated commit messages. Across real teams, those have saved tens of thousands of hours. And the number isn't the headline. The headline is that the impact got measured instead of assumed.

That's the idea behind GitKraken Insights: engineering intelligence built to see how AI actually lands on productivity, quality, and developer experience. No surveillance theater attached.

What Makes GitKraken Insights Different

GitKraken Insights pulls together signals that normally sit in separate silos:

Delivery and DORA performance
Code quality and technical debt trends
AI-assisted workflow impact
Developer experience indicators

The real differentiator is context.

Pair the workflow data with Voice of the Developer feedback and leaders finally get the why behind a moving metric, not just the that. Dashboards tell you something changed. This tells you what to do about it.

Under the hood it runs on GitClear's engineering analytics technology, with GitKraken's obsession over developer experience layered on top. That pairing is rare. Serious analytics, and it doesn't alienate the people being measured.

Measuring Teams, Not Individuals

Here's a lesson the industry keeps having to relearn the painful way: Measure productivity wrong and you torch trust.

So GitKraken Insights looks at teams and systems on purpose. Not individuals. The point was never to police performance. It's to surface the bottlenecks and friction and structural drag that slow a team down.

Trust the system and people engage with it. They hand over honest feedback. They actually want leaders to see the data, because it drives better decisions and not finger-pointing.

That's the moment metrics start working with a team instead of against it.

Enterprise Intelligence Without Enterprise Friction

For years, software engineering intelligence lived behind six-figure contracts and rollouts that dragged on for months. That model leaves most teams out. It's also just dated.

GitKraken Insights ships enterprise-grade intelligence for a fraction of the price, with setup measured in minutes, not quarters. You get value early. No giant integration project, no process overhaul.

If your team is running on gut feel or some brittle custom dashboard, this is a structural upgrade. Not another tool to babysit.

A Practical View on AI

The thing I respect about GitKraken's approach is what it refuses to promise.

AI doesn't get pitched here as a replacement for developers. Nobody is selling magic productivity multipliers.

The focus is practical effectiveness. Help leaders work out whether their AI tools are delivering actual value or just adding noise.

That's exactly the mindset engineering leadership needs right now.

Looking Ahead

The AI productivity paradox isn't going anywhere. The more tools flood the market, the harder you'll have to justify the spend.

Teams that can measure the impact, read the context, and keep developer trust intact will move faster. And they'll make fewer mistakes doing it.

GitKraken Insights gives that future a solid base. Not by guessing. By seeing the whole system clearly.

Inside the Builders Era — How Developers Stay in Control of AI with GitKraken as the Core Tool

Vladimir Mikhalev (heyvaldemar.com) — Tue, 02 Dec 2025 00:00:00 GMT

For two years the industry has chewed on one useless question:

“Will AI replace developers?”

Wrong question. The one that actually sorts professionals from tourists is sharper:

“How do developers stay in control while AI becomes part of every workflow?”

Welcome to The Builders Era. Not the “AI replaces everyone” fantasy. Not the “prompt your way to production” hype.

The Builders Era is the moment where:

✔ Software craftsmanship
meets
✔ AI-augmented velocity
under
✔ developer supervision and rigorous Git workflows.

You don't hand engineering over to AI. You own it, supervise it, and scale it.

The toolchain that wins here is the one that hands developers something concrete:

visibility → control → reliability → craft excellence

Which is why GitKraken sits at the center of the new engineering stack.

The AI hype cycle completely missed the point

For a solid year, every panel and article and self-appointed thought leader shouted the same nonsense:

🗣 “AI will write all your code!”
🗣 “Developers become prompt engineers!”
🗣 “No more PR reviews!”
🗣 “Ship faster with AI!”

Then real developers pointed AI at real codebases.

Reality check from 2025:

✅ AI writes boilerplate fast
❌ AI struggles with architecture
❌ AI struggles with context
❌ AI generates subtle bugs that take longer to debug
❌ AI cannot see long-term maintainability
❌ AI doesn't understand team conventions
❌ AI causes Git chaos if commits aren't supervised

Engineering leaders figured out something that took a while to sink in:

AI didn't reduce the need for developer expertise. It multiplied it.

Teams don't need “AI at all costs.” They need supervised AI. Workflows where humans and tools like GitKraken make AI reliable.

What expert supervision actually means (from a real developer's POV)

Supervision is not babysitting every token AI spits out. It means this:

Human judgment at the right moments, enforced through the right tools.

Here's what that looks like in practice.

Before generation:

Developers provide:

✔ architectural constraints
✔ examples of good patterns
✔ security guidelines
✔ framework conventions
✔ code style requirements

During generation:

There must be instant visibility into:

✔ structural inconsistencies
✔ style violations
✔ dependency mismatches
✔ patterns AI forgot
✔ obvious red flags

After generation:

We run:

✔ rigorous PR review
✔ Git diff analysis
✔ commit message validation
✔ security scans
✔ automated tests

This is where GitKraken becomes the developer's vision panel.

AI generates 20 files in one go. GitKraken's visual diff, change graphs, and context-aware commit history catch errors that slip straight past a CLI-only review.

That's supervision. The real thing, not the slide-deck version.

Why GitKraken is becoming the core tool of The Builders Era

GitKraken was always good. In 2025 it became essential.

Here's why.

AI generates code fast: GitKraken helps you understand that code fast

AI can produce 5 files in 2 seconds. No human reviews those through raw CLI diffs.

GitKraken gives developers:

🟣 Clean visual diffs
🟣 Side-by-side changes
🟣 Commit graph clarity
🟣 Branch lineage visibility
🟣 Multi-file PR inspection
🟣 Precise conflict resolution tools

AI accelerates creation. GitKraken accelerates comprehension. You need both moving at the same speed.

GitKraken protects codebases from AI-introduced chaos

AI often:

❌ adds unused imports
❌ updates only half of a pattern
❌ forgets to remove old logic
❌ introduces shadowed variables
❌ changes logic accidentally
❌ generates “almost correct” code that breaks in edge cases

GitKraken lets developers see the entire change set as a living system, not a pile of diffs.

That alone kills dozens of bugs per sprint.

GitKraken enforces craftsmanship

Developers with real craft write good code. They also write a good commit history.

GitKraken helps enforce:

✔ atomic commits
✔ clean commit messages
✔ readable patches
✔ consistent branching
✔ controlled merges
✔ conflict-free rebases

Your repo turns into a story instead of a battlefield.

Real 2025 use cases: AI plus GitKraken in the wild

This is where it gets concrete.

What follows is what actually happens inside production teams in 2025.

Case A: AI refactors your service layer

AI modifies 17 files. One wrong import breaks production.

GitKraken's commit graph lets you track exactly where the mistake got introduced, then revert it in seconds.

Case B: AI wrote tests, but they don't match team conventions

You could dig through 12 PR files. Or you let GitKraken show you:

✔ mismatched naming
✔ incorrect mock patterns
✔ wrong folder structure

Fix it all in one place.

Case C: AI generates duplicate logic hidden in multiple diffs

A CLI diff won't show you the big picture. GitKraken will.

Case D: Junior dev + AI = silent technical debt

With GitKraken:

maintainers catch patterns early
bad architectural paths are visible
teaching moments become obvious
code quality rises because visibility rises

Case E: AI-generated merge conflicts

GitKraken's conflict resolution UI is basically a cheat code. No more guessing which version is correct, because all the context is right there.

The Builders Era: craft plus AI plus tools that respect the developer

Let's be honest about it.

The fundamentals that mattered in 2015 still matter in 2025:

✔ clean diffs
✔ meaningful PRs
✔ readable commits
✔ thoughtful reviews
✔ stable branches
✔ reliable CI
✔ predictable delivery
✔ maintainable architecture

AI didn't replace these principles.

It made them twice as important.

The Builders Era belongs to developers who:

stay in control
supervise AI output
use tools that make code quality visible
treat the repo as a product
understand that speed without accuracy = chaos

So GitKraken is not “nice to have.” It's part of the new engineering foundation.

What GitKon 2025 is really about (not the marketing version)

GitKon 2025 goes after the only problem worth solving:

How do we scale expert supervision of AI across teams, codebases, and workflows?

Day 1: For Builders (the ICs)

Real workflows:

✔ PR velocity
✔ cleaner diffs
✔ conflict debugging
✔ reducing Git latency
✔ catching AI mistakes early
✔ sane merge strategies
✔ faster refactors
✔ VS Code + Cursor + GitKraken power combos

Day 2: For Engineering Leaders

Impact frameworks:

✔ AI velocity metrics
✔ quality scorecards
✔ rollout playbooks
✔ governance models
✔ debiasing workflows
✔ adoption strategies
✔ measurement methodology

GitKon is not hype. It's a blueprint for the new era of engineering.

And yes, it's 100% free, because GitKraken wants developers to win.

Final thoughts: the future belongs to developers who stay in control

AI is not replacing developers. Bad workflows are.

The Builders Era demands:

clear thinking
strong craft
tools that amplify expertise
systems that make AI reliable
visibility over automation
quality over speed
control over chaos

The developers who thrive will be the ones who:

✔ Use AI as a fast, junior pair.
✔ Use GitKraken as their visibility engine.
✔ Build workflows where humans supervise what matters.
✔ Stay in control of their craft — and their codebase.

GitKon 2025 will show exactly how to do it.

GitKraken Ambassador Note

As a GitKraken Ambassador, I watch this play out every day:

When teams adopt GitKraken, AI stops being a liability and becomes a multiplier.

That's the Builders Era.

And it's only just beginning.

Platform Engineering — The Complete, Practical Guide to Building Internal Developer Platforms That Scale

Vladimir Mikhalev (heyvaldemar.com) — Thu, 27 Nov 2025 00:00:00 GMT

TL;DR

Platform Engineering is what happens when DevOps grows up and you stop relying on hero engineers and lucky deployments. You build an internal product, a platform, that gives developers a paved, predictable way to build, ship, and operate software.

Here's what this guide covers:

DevOps vs Platform Engineering. Why they're not competitors, and how platform engineering is the natural evolution of mature DevOps.
The 5-layer architecture of a real platform. From infra foundation and GitOps control plane to developer experience, observability, and governance.
Golden Paths. How to give teams a frictionless, opinionated way to create and run services. This is the thing that cuts delivery time by 3–7x.
The tooling reality. Kubernetes, Terraform, Crossplane, Argo CD, Backstage, Vault and where they actually fit, no vendor unicorns.
Failure patterns. The classic mistakes that quietly kill 90% of internal platforms before they get real adoption.
A 90-day practical roadmap. How I'd build your first working platform: one golden path, GitOps everywhere, then a clean developer interface.

If your uptime, deploys, and roadmap still depend on a few heroic people, you don't need more scripts. You need a platform.

Introduction: The Real Reason Companies Turn to Platform Engineering

I've visited a lot of companies over the years. Small teams, giant enterprises, scrappy startups, Fortune 100s. Completely different people, industries, cultures, tech stacks.

But the story is always the same.

At first, everything moves quickly. A new service takes a day. Deployment is a simple bash script. Everyone knows where config files live, even if nobody knows why they live there.

And then the company grows.

More teams. More services. More requirements. More complexity.

Suddenly the elegant little system you built in the beginning becomes a maze of scripts, CI pipelines, scattered configs, and tribal knowledge.

You start hearing things like:

"Prod behaves differently, we're not sure why."
"Ask Michael, he's the only one who knows how to deploy this service."
"We can't upgrade that component, it breaks staging."
"We'll fix this part after the release… or the next release."
"We need DevOps to press the magic button."

If your uptime depends on courage, experience, and availability of specific people, you don't have a system. You have hero-driven engineering.

And heroism doesn't scale.

So companies inevitably arrive at the same conclusion:

We need a platform. Not as a buzzword. Not as hype. But because the way we're working is no longer sustainable.

That's what Platform Engineering is really about. Not "shiny new roles." Not "we're replacing DevOps." Not building portals for the sake of portals.

It's about building a foundation that grows with your organization, not against it.

Let me take this apart the way engineers should: calmly, logically, honestly.

1. DevOps vs Platform Engineering: Why They Are Not Competitors

There's a lot of confusion around this. Mostly because people try to compare apples to architecture.

Here's the fix.

1.1 DevOps: The way we work

DevOps is a cultural and operational model:

shared responsibility between dev and ops,
continuous improvement,
end-to-end ownership,
automation as a default way of working,
reducing friction between teams,
enabling fast, safe delivery.

DevOps is about behavior, process, mindset, not specific tools.

You can do DevOps:

with Kubernetes,
without Kubernetes,
with monoliths,
with microservices,
in small teams,
in giant enterprises.

It's a philosophy of work.

1.2 Platform Engineering: The systems we build

Platform Engineering is what happens when a DevOps culture grows to the point where you need a dedicated, stable system to support it.

It is:

a team,
a product,
a set of APIs,
templates,
workflows,
infrastructure abstractions,
and operational guardrails.

It is the internal platform that developers interact with when they build software.

1.3 A simple analogy

DevOps = driving principles
Platform Engineering = building the highway

You can't scale traffic with good drivers alone. You need working infrastructure.

1.4 When DevOps matures, you get Platform Engineering

DevOps isn't being replaced. It evolves.

When DevOps becomes big enough, painful enough, and central enough, it naturally leads to one sentence:

"We should build this as a product"

That product → is your platform.

2. Why Companies Hit the Wall Without a Platform

There are five signals I see everywhere, and they always mean the same thing. Your infrastructure architecture has reached the limits of tribal knowledge.

2.1 Deployment Drama

If deployments require:

heroism,
coordination,
manual approvals,
Slack ceremonies,
or the presence of a specific engineer,

you're not doing continuous delivery. You're staging a theatrical performance.

2.2 DevOps Becomes a Human API Gateway

When developers say:

"Can you deploy this?"
"Can you give me access?"
"Can you check why staging is broken?"
"Can you create a new environment?"

And DevOps becomes a bottleneck for everything, from debugging to provisioning, that's not DevOps. That's Ops with extra steps.

2.3 Snowflake environments

Staging behaves like prod's distant cousin. Local dev behaves like neither. CI behaves like a completely different species.

This is how outages happen.

2.4 Cost chaos

Whether it's:

orphaned resources,
forgotten databases,
overprovisioned clusters,
runaway autoscalers,
misconfigured storage,
or zombie services,

cost without governance grows like mold.

2.5 Scaling becomes painful

If adding new engineers or new services makes everything slower rather than faster, that's a structural failure.

A good system becomes more predictable as it grows. A bad one becomes more fragile.

3. What Platform Engineering Actually Is

Forget the vendor diagrams. Forget buzzwords. Here's the simplest, clearest, most useful definition I know.

Platform Engineering is building an internal product that gives developers the paved, reliable, predictable path to build, ship, operate, and observe software.

A platform is:

boring
consistent
repeatable
documented
self-service
observable
secure
cost-controlled

A platform is NOT:

❌ "Kubernetes + CI"
❌ "Backstage installed over the weekend"
❌ "A DevOps team renamed"
❌ "A dashboard with links to tools"
❌ "A new department that writes YAML"

A platform is everything developers need, wrapped in one coherent experience.

And it must feel like a product, not a set of tools.

4. The Anatomy of a Real Platform (5 Layers)

I've seen dozens of internal platforms across the world. None of them succeeded without these five layers.

Layer 1: Infrastructure Foundation

The technical bedrock.

Kubernetes or ECS/Nomad
Load balancing / Ingress / API gateways
VPC, subnets, routing
Databases, caches, queues
Storage
KMS + secrets
Terraform or Pulumi for provisioning
Crossplane if you want infra CRDs

This is the "engine room".

If this layer is unstable, everything built on top collapses.

Layer 2: Control Plane (The Brain)

This is where Platform Engineering becomes real:

GitOps (Argo CD or Flux)
Policy engines (OPA, Gatekeeper, Kyverno)
standardized CI/CD
templates (Helm, Kustomize, Terraform modules)
infrastructure blueprints
cloud governance rules

This is the logic that ensures consistency across environments.

Layer 3: Developer Experience Layer

Good DX is not "nice-to-have". It's the factor that determines adoption.

Includes:

Backstage or Port
Internal CLI
service creation wizard
automatic observability
pre-configured pipelines
unified configuration model
preview environments
local dev tooling

A great platform makes it easier to follow the paved road than to go around it.

Layer 4: Observability Layer

Without observability, you're navigating your production with a flashlight and a prayer.

Minimum set:

Prometheus + Grafana
Loki or ELK
Tracing (Tempo, Jaeger)
Logging standards
SLO dashboards
Synthetic checks
Alerting strategy (not alert spam)

Observability is not "nice monitoring". It is a prerequisite for stability.

Layer 5: Governance & Security Layer

The guardrails that make velocity possible safely.

Includes:

IAM / RBAC / service identities
image scanning (Snyk, Trivy)
secrets rotation
cost visibility
policies on namespaces, quotas, tagging
compliance automation

Governance is not bureaucracy. It's the thing that prevents midnight incidents.

5. The Golden Path: The Heart of a Good Platform

This is where developers feel the platform.

A Golden Path is:

a template,
a CLI command,
a repository structure,
pipelines,
policies,
monitoring,
a deployment strategy,

all packaged into one frictionless "this is how we build services here".

You type:

internal create service my-api

And you get:

scaffolding
Dockerfile
Helm chart
CI pipeline
SLO dashboards
Logs + metrics
GitOps config
Autoscaling policies
Cost tags
Secrets wiring

out-of-the-box.

A good Golden Path cuts cognitive load by 10x and accelerates delivery by 3-7x.

This is the moment where engineers say:

"This is nice. This feels clean." "This makes sense." "I don't want to go back."

Golden Paths are the soul of the platform.

6. DevOps vs Platform Engineering: Deep Comparison for Experts

Most articles get this section wrong, or they oversimplify it.

Here it is, crisp.

Aspect	DevOps	Platform Engineering
Mission	Improve collaboration & delivery culture	Build an internal product (the platform)
Output	CI, CD, automation, practices	Golden paths, CLIs, templates, infra APIs
Focus	People & process	Systems & tooling
Team shape	Cross-functional	Product-focused
Customers	Developers, QA, infra	Developers
Success metric	Delivery speed, reliability	Adoption, consistency, DX
Timescale	Iterative improvement	Multi-year evolution
Anti-pattern	DevOps as Ops rebranded	Platform as a tool dumping ground

Platform Engineering builds the structure. DevOps teaches teams how to use it.

One cannot replace the other.

7. The Tools (Explained Like an Engineer, Not a Vendor)

Tools matter. Not because they're "cool," but because they shape the experience and constraints of your platform.

Here are the ones that count.

7.1 Kubernetes

Use it if:

you have multiple teams,
microservices,
autoscaling needs,
service meshes,
multi-env consistency,
need for runtime abstraction.

Don't use it if:

you deploy two Python apps and one cron job,
you don't have SRE capacity,
you can't manage cluster lifecycle.

7.2 Terraform

Great for:

infra provisioning
cloud resources
repeatability
modules as standards

Be careful with:

drift
secrets
mixing app and infra concerns
applying manually

7.3 Crossplane

Use when:

Kubernetes is your control plane
you want infra CRDs
you want policy-enforced infra creation inside clusters

Skip if:

your teams are not ready for CRD-driven infra
you already struggle with Kubernetes complexity

7.4 GitOps (Argo CD / Flux)

The backbone of reliable delivery.

Pros:

drift protection
revertability
auditability
versioned environments
better security posture

Just remember:

do NOT mix imperative and declarative
keep secrets out
structure repos carefully

7.5 Backstage

The best developer portal we have.

Use it for:

service catalog
documentation
golden paths
scorecards
scaffolding
standardization

But don't treat it as:

a dumping ground
a substitute for platform maturity

Backstage succeeds when your platform already has structure.

7.6 Vault / External Secrets

Use to:

centralize secrets
rotate automatically
eliminate inline credentials
enforce least privilege

Secrets must never live:

in repos,
in CI logs,
in Slack,
in Terraform states.

8. Common Failure Patterns: What Breaks 90% of Internal Platforms

This is the part most companies skip. They regret it later.

❌ Failure #1: Platform built for DevOps, not developers

If developers don't use it, it's not a platform.

❌ Failure #2: Too much complexity too early

You don't start by building a universe. You start by paving one clean road.

❌ Failure #3: "Platform = Backstage"

A portal without strong foundations is a catalog of pain.

❌ Failure #4: Platform team behaves like Ops

If the platform team approves deployments, that's not a platform.

❌ Failure #5: No product thinking

Platforms without:

user research
documentation
versioning
roadmap
metrics

die silently.

❌ Failure #6: No Golden Path

You can't scale "many ways to do the same thing".

❌ Failure #7: No GitOps

Imperative ops doesn't scale.

❌ Failure #8: No observability

If you can't see the system, you can't improve the system.

9. If I Had to Build Your Platform in 90 Days (Valdemar Edition)

This section is pure practice. Something you can use tomorrow.

Phase 1 (Weeks 1-2): Understand the Pain

Interview developers.
Watch their deploy process.
Map where DevOps gets pulled in.
Identify repetitive failures.
Define the top 3 most painful bottlenecks.

This phase is about humility and learning, not architecture.

Phase 2 (Weeks 3-4): Build One Great Golden Path

Pick ONE service type (e.g., internal API).

Deliver:

repo scaffold
Dockerfile
CI
Helm chart / Kustomize
GitOps manifest
metrics + logs
OPA policies
basic cost tags
reliability budget

Your goal: service ready in under 10 minutes, deployable in under 2.

Phase 3 (Weeks 5-6): GitOps Everywhere

Argo CD or Flux
environment repos
no manual kubectl
clear directory structure
rollbacks tested
drift detection enabled
PR-based changes only

This instantly improves reliability.

Phase 4 (Weeks 7-8): Developer Interface

Start small:

internal CLI
Backstage scaffold
templates visible in UI
documentation automated

A platform without interface is like an airport without signs.

Phase 5 (Weeks 9-12): Expand With Care

Add:

frontend service template
async worker template
cost guardrails
alerting best practices
tracing
secrets management
service scorecards
- progressive delivery (Argo Rollouts)

At this point you will have a real, working platform.

Not perfect. But alive, used, and stable.

That's the only platform that matters.

10. How to Know You Actually Have a Platform

You know you have a platform when:

✔ developers don't ask "how do I deploy this?"
✔ new services follow the same structure
✔ environments never drift
✔ deployments are boring
✔ DevOps is no longer a bottleneck
✔ cost anomalies are visible immediately
✔ logs, metrics, traces appear automatically
✔ teams move faster, not slower
✔ the platform feels invisible, but reliable

And the most important criterion:

If your platform team goes on vacation and the company doesn't panic — you did it right.

11. Final Thoughts: Platform Engineering Is What Happens When Engineering Matures

The best platforms are not the biggest ones. Not the most complex ones. Not the ones with the most tools.

The best platforms are the ones that:

reduce friction,
reduce cognitive load,
reduce variance,
reduce complexity,
reduce heroism,
reduce fear.

A good platform:

makes teams faster,
makes systems safer,
makes architecture cleaner,
makes work calmer,
makes engineers happier.

It does not aim to impress. It aims to serve.

So platform engineering is not a trend. It's not "DevOps 2.0". It's not hype.

It's simply the natural evolution of software engineering in a world where complexity grows faster than teams.

And like any good engineering discipline, its goal is beautifully simple:

Build systems that remain predictable even as everything around them changes.

If your platform is doing that, you're on the right path. The golden one.

Recovering a Corrupt Exchange Database with Stellar Repair — Real-World Lab Test

Vladimir Mikhalev (heyvaldemar.com) — Thu, 31 Jul 2025 00:00:00 GMT

You know the feeling. The Exchange database won't mount, users are screaming, and the logs read like hieroglyphics. I decided to build that nightmare on purpose, in a lab where nobody could get hurt. The point was simple. I wanted to find out whether Stellar Repair for Exchange could actually drag me back out of the fire.

It did. But I'm getting ahead of myself.

None of this is theory. It's a war story from a controlled lab, start to finish: from "let's nuke the Exchange database" all the way to "back in business without losing a single email."

Why Stellar Repair for Exchange Caught My Eye

I've spent enough years in the trenches with Exchange to know one thing for certain. When a database goes dirty, your weekend is already over.

Microsoft hands you eseutil and a few other tools. Fine for tidy problems. In a real disaster, though, it's a butterknife at a gunfight.

That's the gap Stellar Repair for Exchange tries to fill. One job, nothing fancy: take a corrupt EDB file and make it readable again.

A 4.9/5 Trustpilot rating told me I wasn't the only one wondering whether it delivers.

The Test Lab: Building a Realistic Disaster

You don't trust recovery software on a hunch. So before anything else I stood up a lab that looked like a real environment. Two boxes:

HQ-DC01 - Windows Server 2019, Active Directory Domain Controller
HQ-EXCH01 - Windows Server 2019, Exchange 2019 CU15

Three demo users. A handful of emails going back and forth, a few calendar invites thrown in. The goal was to make the database feel lived-in, like an ordinary Tuesday at the office rather than an empty test rig.

Installing Stellar Repair for Exchange

The install is about as hard as installing a screensaver. Download, click Next a few times, done. Nothing hidden underneath, no surprise dependencies waiting to bite you.

Making a Mess: Dirty Shutdown on Purpose

Now the fun part.

Exchange logs hold the database together. They keep it consistent. So I deleted half of them. Then I killed the "Microsoft Exchange Information Store" service. That was enough to shove the database straight into a dirty shutdown.

To confirm:

eseutil /mh '.\DB01-Mailbox.edb'

Dirty. Exactly what I was after.

Exchange now flatly refuses to mount the thing. Disaster achieved, on schedule.

Recovery with Stellar Repair for Exchange

Step 1: Point to the EDB

Launch Stellar and point it at the EDB file. Lost track of where it lives? There's a "Find" option for that. It also surfaces a Temp folder path, and you want disk space sitting there.

That detail matters more than it looks. The tool leans on the Temp location while it chews through a large database, so check that the path Stellar shows has real free space before you kick off a scan.

Step 2: Choose the Scan Mode

Two scan modes are on offer:

Quick Scan - good for light corruption
Extensive Scan - deep, slower, but thorough

I picked Extensive Scan. My database had basically been set on fire, so half measures weren't going to cut it.

Step 3: Wait for the Magic

The scan finished and Stellar handed me all three mailboxes. Emails, calendars, contacts, the lot. Every bit of it browsable.

Recovery Options That Matter

From here, your choices open up. You can:

Export to PST
Export to MSG, EML, HTML, RTF, PDF (single items)
Export back to Exchange Server
Export directly to Office 365
Even push data into a Public Folder

For the lab I chose Export back to Exchange. One catch worth knowing about: Outlook has to be installed on the same machine as Stellar. In production you'd run this on a separate VM. Trust me on that one.

The recovery scope is wide. Stellar pulls back nearly everything a mailbox holds: emails and their attachments, contacts, calendars, tasks, notes, journals, even Public Folder content.

It covers Exchange Server versions all the way from 5.5 up through 2019.

:::warning As of this test (July 2025), Exchange 2019 CU15 was used. Support for newer versions, if released, should be verified with Stellar. :::

Rebuilding the Mailboxes

Over in the Exchange Admin Center:

Disabled the broken mailboxes (so user accounts remain in AD)
Created fresh mailboxes with _restored suffix
Logged in to confirm: clean, empty

Back in Stellar:

Right-click mailbox → Export to Exchange Server
Provide Exchange server and credentials
Click OK

Then repeat for every mailbox and let it sync.

The Result

A few minutes later, all three mailboxes were back. Emails, calendar invites, everything sitting where it should.

This from a database that wouldn't mount at all.

Key Takeaways

Ease of use: Zero PowerShell gymnastics, just point and click
Compatibility: Works with Exchange 5.5 up to 2019
Recovery options: PST, Office 365, Public Folders - take your pick
Safety net: When eseutil leaves you stranded, this saves your bacon

Final Thoughts

This isn't an ad. It's the sober readout after I broke Exchange on purpose and watched what happened: Stellar Repair for Exchange works.

If you run Exchange servers and don't keep something like this in your back pocket, you're betting against downtime. That's a bet you lose eventually.

My advice?

Build a lab. Break your own database. Run the recovery yourself and watch it come back. Far better to learn this on a quiet afternoon than at 3 AM on a Sunday.

Learn more about Stellar Repair for Exchange

Amazon Q vs DevOps Chaos — Can This AI Fix AWS Faster Than You?

Vladimir Mikhalev (heyvaldemar.com) — Mon, 30 Jun 2025 00:00:00 GMT

You know the moment. AWS breaks, the channel goes quiet, everyone suddenly remembers they have a meeting, and you're the one fixing it. This post is about ending that.

Meet Amazon Q

Amazon Q is the AI assistant baked into AWS. Treat it like a teammate. One who skips the small talk and has no opinions about your playlist.

It's less “Hello, World” and more:

“Hey, your Lambda's stuck because your IAM policy is a dumpster fire again.”

Q doesn't just chat. It digs into your infra, permissions, and configurations. Picture a senior AWS engineer locked inside your console forever, no HR paperwork required.

And honestly? Some days it beats the colleague who answers three days late, about a different ticket entirely.

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

So how does Q hold up in real life?

Example 1: Lambda Troubleshooting

You trigger a Lambda. Silence. No errors. No logs. Just confusion and a low hum of panic.

Before you open fifteen Google tabs, Q checks your setup and says:

“Relax. Just add this IAM permission. Done.”

Example 2: VPC Setup

You're standing up a VPC. NAT gateways, subnets, the usual YAML nightmare.

Q hands you the template and shrugs:

“One click. Coffee break.”

Example 3: Route 53 and DNS

Configuring DNS in Route 53 has a way of making you feel like it's your first week in tech again.

So instead of you sifting through stale forum threads, or taking vague advice from some tool that's never seen your account, Q walks you through it. Clearly. Calmly. With a lot less stress.

You get the idea.

Who Does Q Actually Help?

New to AWS? Q tells you exactly what broke, and why.
Senior DevOps engineer? Q gives you your evenings back.
Working on a team? Less “let's sync later,” more “feature shipped.”

But Wait, Don't We Already Have ChatGPT?

We do. Thing is, ChatGPT has never seen your AWS account.

ChatGPT knows the rules. Q knows your chaos. That's the whole difference.

It's basically handing ChatGPT the keys to your account with one rule:

“Look but don't break.”

What You Should Know Before You Try It

🚧 It's still in Preview. Expect the odd bug.
🧠 If your setup is genuinely hairy, you'll still be tweaking things by hand.
🛠️ And if you live in Terraform, or write everything as code, Q really shines in the CLI or your IDE.

Final Thoughts

Amazon Q is an AI assistant built for one job: helping DevOps people clean up real-world AWS messes without the usual pain.

So give it a shot.

Because come on. Weekends aren't for debugging IAM policies.

Thank you for reading! Don't forget to check out the video version for additional insights and visuals.

Docker MCP — Turn GPT into a Real DevOps Assistant (Slack, GitHub, Stripe)

Vladimir Mikhalev (heyvaldemar.com) — Tue, 10 Jun 2025 00:00:00 GMT

Let me guess.

You've poked at GPT or Claude. Maybe you wired up a small chatbot over a weekend.

Then you ask it to do one real thing:

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

And it tells you:

“I would... but I'm just a language model.”

Sound familiar?

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

AI Is Starting to Act

That excuse is on its way out. This post is about how language models went from talking to actually acting. Three things made it happen: agents, MCP, and Docker.

They got hands, basically. Not literal ones.

What I mean is agents. Small programs that let a model reach out and touch real tools.

Like:

Sending a Slack message
Checking a Stripe payment
Opening a pull request on GitHub

No magic. Just plumbing.

The piece tying it together is MCP, the Model Context Protocol. It hands models a consistent, secure way to reach APIs, databases, and cloud services.

Let's Start with the Pain

First, some history. Why was any of this hard to begin with? Models have always been good at advice.

It can write code.
Fix bugs.
Even generate song lyrics.

Then you ask for something trivial:

“Can you send an email to a client?”

And it stares back. Metaphorically. Then:

“I'd love to, but... I just generate words. I don't do stuff.”

Honestly, fair.

The logic was there.
The reasoning was solid.
But action? That was outside the job description.

So people built a workaround. Hand the model tools, wrapped in tiny helpers called agents.

So What's MCP?

So what is MCP, actually? And why does it carry so much weight here?

MCP gives the whole thing structure:

The model thinks.
The agent acts.
And MCP is the cable that connects the brain to the hands.

Here's how it works, step by step

The model says what it wants — like “Send this message to Slack.”
The host passes that to the right agent (called an MCP server).
The server does the thing — sends the message, makes the API call.
The result goes back to the model, and it wraps up its reply.

Clean loop.

The early days were not clean at all.

The Old Way Was a Headache

Nobody misses the old way. I'll remind you anyway.

You had to:

Manually spin up MCP servers
Deal with different stacks (Python, Node, Chromium... all arguing with each other)
Store API keys in plain JSON (a security team's nightmare)

Need more than one agent? Welcome to YAML files, container logs, and a creeping sense of dread.

You wanted to check a Stripe payment. Somehow you ended up in a Kubernetes support group.

And Then Came Docker

Docker is where this turns. It made MCP agents easy to launch, safe to isolate, and far less painful to manage.

Picture it this way.

Your AI gets hands, and Docker hands those hands a pair of gloves.

Clean. Contained. Controlled.

So what does that mean for you?

Each agent runs in its own container
It only sees what you allow
No mess on your system
No version conflicts

Browse the full Docker MCP Toolkit, then go look at the MCP Servers on Docker Hub. Over 100 officially supported tools sit there, ready to launch in seconds.

And It Gets Better

Docker Desktop ships the MCP Toolkit now, with over 100 ready-to-use agents pulled straight from Docker Hub.

Want to run one?

Three steps:

Pick one
Docker spins up a container
And the agent starts listening for model commands

Done.

No command-line gymnastics. No weeping over config files.

Fixing the Duplicate Agent Problem

Here's another old annoyance. Several apps would each try to spin up the same agent, again and again.

Which got you:

Duplicate containers
Double the tokens
Wasted bandwidth
And way more complexity than necessary

These days?

One agent. One container.

Multiple clients can use it.
No duplication.
No drama.

But Is It Safe?

This is a lot of power. So is it safe?

It is, and the reason is the boundary.

Agents run inside isolated Docker containers.

So:

They can only see what you explicitly share
They don't mess with your core system
They can't reach places they're not supposed to

Docker draws those lines by default.

You can tear them down with --privileged or by mounting the Docker socket. Unless you enjoy living dangerously, don't.

Keep the defaults. Use verified agents.

So Who's This For?

Who gets the most out of this?

If you're:

Using GPT, Claude, or Copilot — and want them to do stuff, not just talk about it
Working in DevOps — and tired of writing the same glue code over and over
A product manager who wants AI plugged into GitHub, Jira, Stripe, or Slack... in minutes, not hours

Then yes, this is for you.

What you get:

An agent running in just a few clicks
Built-in safety and isolation
And if you need to scale? Just add more agents. That's it.

Bottom Line

The model doesn't only think now. It acts.

Pair MCP + Docker and it acts fast, safely, and at scale.

So if you want to give your model real-world reach, this is how you do it.

No hacky scripts.
Just agents that work.
From prompt… to production.

Clean. Safe. Smart.

Welcome to the agent-powered era, my friends.

Thank you for reading! Don't forget to check out the video version for additional insights and visuals.

10 Real Terraform Interview Questions (and Expert Answers!) — 2025 DevOps Guide

Vladimir Mikhalev (heyvaldemar.com) — Mon, 12 May 2025 00:00:00 GMT

You know the line that makes engineers sweat:

“You've got a Terraform interview tomorrow. You ready?”

Relax.

Here are 10 Terraform questions that show up in actual interviews, plus how to answer them without flailing.

But the answers matter more than the questions. I'll explain each one plainly, with real examples, so you don't just parrot back a definition. You'll actually get it.

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

Question 1: What is Terraform and why does it matter?

Terraform is how you talk to your infrastructure with code instead of clicks.

You're not poking around the AWS console at 3 a.m. like it's 2009.

You write code. Something like: "I need a VPC, three subnets, and a database."

And Terraform answers: "Got it. I'll build it. I'll check it. And I'll keep it that way."

Convenience is the small part. The real win is control, and repeatability. That's the whole point of infrastructure as code.

As of 2025, Terraform sits at version 1.11. Actively developed, widely deployed, and still the default tool for defining infrastructure.

Question 2: How does Terraform talk to the cloud?

Through providers.

Think of a provider as an adapter. It knows how to speak to a given API:

You declare required_providers in your code. Run terraform init, and it pulls the right versions, then verifies their SHA-256 hashes.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.97.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

The .terraform.lock.hcl file pins those versions in place.

provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.97.0"
  constraints = "~> 5.97.0"
  hashes = [
    "h1:aaa111...",
    "h1:bbb222...",
    "h1:ccc333..."
  ]
}

Same idea as package dependencies. Don't pin them, and you'll get surprises. Surprises in production?

Yeah. Not fun.

Question 3: What is terraform.tfstate and why is it critical?

It's Terraform's memory.

The state file tracks:

What resources exist
Their IDs
Their attributes
And how they're all wired together

Lose it, and Terraform forgets everything you've built. So it might decide to recreate your entire production stack from scratch.

Where do you keep state safely? Two solid options:

S3 bucket with native locking (available since Terraform 1.11)
HCP Terraform (formerly Terraform Cloud)

:::tip Never, ever commit your state file to git. Not even to a private repo. Not even "just this once." Just... don't. :::

Question 4: What is the actual function of plan, apply, destroy, and refresh?

Read them as: preview, execute, delete, sync.

terraform plan: shows what will change
terraform apply: actually makes the changes
terraform destroy: deletes everything in your config
terraform refresh: syncs the state with reality

In the upcoming Terraform 1.12, plan runs refresh for you. No separate command.

🎯 Advice: Always run terraform plan before terraform apply.

Especially on a Friday. Especially late at night.

Especially in prod.

Question 5: What is drift, and how do you detect it?

Drift is when your real infrastructure stops matching your code.

Say your config declares t3.micro. Then someone goes into the AWS console and bumps it to t3.large by hand.

Terraform has no idea. It only notices the gap when you run terraform plan.

So how do you catch it?

On HCP Terraform, you get a built-in drift detector. It can fire alerts to Slack or Teams through notifications.
Not on HCP Terraform or Terraform Enterprise? Then run terraform plan in CI at least once a day.

Drift isn't a bug. It's a warning. Someone changed something outside of Terraform.

And remember: Infrastructure as Code does not like human hands.

Question 6: What are modules and how do you use them without creating a mess?

A module is basically a function for your infrastructure. Write it once, reuse it everywhere.

Picture a small VPC module. You run it in dev, staging, and prod. Only the IP ranges and names change. The logic underneath stays identical.

⚠️ Keep it simple: one module — one purpose. Don't build a single module that spins up a VPC, provisions a database, and pings Slack on the side.

Once your module is solid, you've got options:

Publish it to the Terraform Registry
Or even store it as an OCI artifact (this feature is experimental in Terraform 1.12)

Question 7: Variables vs Secrets: where's the line?

Simple distinction. Variables and secrets are not the same thing.

Use variables for anything that changes between environments.

Secrets are another matter. Never hardcode them. Ever.

I've watched this happen on real projects. Don't be the person who writes:

password = "supersecret123"

So where do secrets belong?

AWS Secrets Manager
HashiCorp Vault
Or just mark variables as sensitive in HCP Terraform

If you do pass a secret as a variable, set sensitive = true.

That keeps it out of the terraform plan output.

variable "db_password" {
  description = "Database password"
  type        = string
  sensitive   = true
}

And since Terraform 1.10, you can use short-lived values to keep secrets out of your state files entirely.

Question 8: What if terraform apply fails halfway through?

It happens. To junior devs, to senior engineers, to me.

Here's the recovery, step by step:

Run terraform state list to see what was created.
If the resource exists in the cloud but not in the state — use terraform import.
If it shouldn't exist — remove it from state with terraform state rm.
Then re-run terraform plan and check that everything looks clean.

Terraform now supports moved and removed blocks. So you can refactor without hand-editing the state file. Less risk, no manual hacking, clean refactors. Nice.

Question 9: How do you separate dev, stage, and prod?

Three approaches that hold up in practice:

Workspaces — simple, but hard to scale
Folder structure like environments/dev, stage, prod — the golden standard
Terragrunt — great for multi-account or multi-team setups

🧠 Whatever you pick, one rule is non-negotiable:

🎯 One backend → one state → one environment.

Never mix dev and prod in the same state file. That's storing fire and gasoline in the same drawer.

Question 10: How do you shift security left?

Security isn't a step you bolt on later. It starts at terraform plan.

That's where Policy as Code earns its keep. Tools like:

OPA (Open Policy Agent)
Sentinel (by HashiCorp)
Checkov (by Bridgecrew)
Snyk IaC

…catch problems before they ship.

🔒 For example:

You write a rule: "All S3 buckets must use KMS." Wired up correctly, Terraform checks that during the plan. Rule fails, run blocked.

Some of these tools live in your CI pipeline. Others plug straight into HCP Terraform.

Want to push further? terraform test lets you write unit tests for your modules, and it drops right into CI.

Security belongs in how you build, not in a cleanup you do afterward.

Final Thoughts

That's the set. 10 questions, 10 real answers. Not to help you scrape through an interview, but to walk in confident, prepared, and dangerously well-informed.

Thank you for reading! Don't forget to check out the video version for additional insights and visuals.

GitOps on AWS — Real-World DevOps Pipeline with Argo CD, Terraform & EKS

Vladimir Mikhalev (heyvaldemar.com) — Tue, 22 Apr 2025 00:00:00 GMT

This is how I built a production-grade GitOps pipeline on AWS. Fully containerized, drawn straight from what I run in production.

No buzzwords. No clickbait. The architecture works, and the mindset behind it holds up as you grow.

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

Why I Chose GitOps

GitOps is about control. Git becomes the one place that tells the truth about your system.

Every change goes through a pull request.
Every rollback is just a git revert.

No guesswork. Nobody asking who deployed what on Friday night. By 2025 this stopped being a trend. If your team is serious about infrastructure, it's the floor you start from, not the ceiling you reach for.

So why does my setup look the way it does? Start with the stack.

My Stack at a Glance

At the core, I use Amazon EKS — Amazon's managed Kubernetes
Docker images are built and pushed to Amazon ECR
Manifests live in Git. Argo CD syncs the cluster automatically
Terraform provisions everything — from VPC to namespaces
Secrets are managed securely with HashiCorp Vault
GitHub Actions ties it all together

One terraform apply. That gets you a reproducible platform, codified end to end, with nothing done by hand.

Why Containers?

A container is the smallest unit of reliability I know of. It runs the same way in dev, in staging, and in production. Isolated, predictable, pinned to a version. CI builds the image and tags it, say release-2025.04.16-prod, then pushes it to Amazon ECR. What runs in production is that exact artifact, byte for byte.

You know the old joke about how it works on my machine? Containers retire it. You ship systems instead of chaos.

The GitOps Mindset Shift

GitOps asks you to rethink one thing, and it trips up plenty of experienced teams. Here's the mistake I keep running into.

They assume CI should handle deployments. Under GitOps it doesn't.

CI's job is simply to push changes to Git.
Argo CD handles the deploy. On its own. On schedule. No manual triggers.

That split is the whole point. Git holds the truth. CI is just the courier that gets your change there.

How It All Connects

CI runs on GitHub Actions.
It builds the Docker image, pushes it to Amazon ECR, updates Helm values, and commits to Git.
Argo CD detects changes and applies them to the cluster.
Terraform provisions the entire platform, Argo CD included.
Vault integrates securely, providing secrets at runtime.

So there are no plain-text tokens sitting around. No unencrypted environment variables either.

This stack does the job, and it holds up when something goes wrong.

Hard-Earned Lessons

Getting here took a while, and I paid for a few of these the hard way. Here's what I'd tell you so you skip my mistakes.

1. Bootstrapping

Argo CD doesn't magically install itself.

You need a plan for that first install. I use Terraform and the Helm Provider to automate it.

2. Namespaces

Never run Argo CD alongside your applications.

Keep it isolated. Your future self will thank you for it.

3. Secrets

If your secrets live in YAML files, that isn't GitOps. That's hopeOps.

Use Vault or AWS Secrets Manager. Credentials never go in the open.

Monitoring: The Non-Negotiable

If your monitoring is users calling you at 3 AM, that isn't monitoring. It's a nightmare with a phone number.

For metrics I run Prometheus and Grafana. Loki handles logs, Alertmanager handles alerts. Argo CD exposes its own metrics too, so the moment the cluster drifts from Git, I see it.

Monitoring isn't a bolt-on you add later. Skip it and you're flying blind.

What Success Looks Like

Deployment time: minutes, not hours.
Rollbacks: one click.
New environments: one command.
New developers: clone and go.
Everything documented, repeatable, and under control.

None of that is hype. That's the day-to-day.

Final Thoughts

This is more than a list of tools. It's a way of working. Containers, infrastructure as code, every change routed through Git: that's what a mature system looks like in 2025. GitOps was never really about YAML. It's about building something you can actually trust.

Thank you for reading! Don't forget to check out the video version for additional insights and visuals.

Why AI Fails Without DevOps — What No One Tells You

Vladimir Mikhalev (heyvaldemar.com) — Tue, 08 Apr 2025 00:00:00 GMT

Everyone's hyped about AI. Almost nobody talks about the engine underneath it.

This post is about how DevOps and containers turn AI from a demo into something you can actually ship.

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

Everyone Talks About AI, No One Talks About What Powers It

AI gets all the attention right now. LLMs, code generation, multimodality, the endless AGI chatter.

But ask what's under the hood and the room goes quiet. These models are huge. They want hundreds of gigabytes, GPUs, stability, versioning, monitoring. None of that runs itself.

So here's the question worth asking.

What actually makes this work in production?

Strip out the DevOps foundation and you're left with a cool demo. Not a product. So in this post I want to walk through why DevOps and containers are what make AI real.

The Magic Isn't Magic. It's DevOps

ChatGPT answers in two seconds. Midjourney paints in five. Behind that? Dozens of services, container orchestration, model loading, GPU balancing. The "magic" is just plumbing you don't see.

OpenAI serves millions of requests per second. They lean on containers, autoscaling, canary deployments. Not because it's trendy. Because there's no other way to do it.

Now look at Hugging Face Spaces. Every app runs in its own container, which is exactly why one of them can go from 1 user to 10,000 without falling over. Pull DevOps out from under that and the whole thing collapses.

DevOps Is the Backbone of AI

Training a model?

You need the right drivers, the right CUDA, the right PyTorch version. Containers pin all of that in a minute.

Want training, testing, and deployment to run themselves? Then you need CI/CD, monitoring, and alerting. No way around it.

Need to version models, trace what changed, and log every inference? Now you're squarely in DevOps territory.

I've watched teams fine-tune a model and then realize nobody could reproduce the result. It had been trained on a stale dataset. No pipeline. No versioning. No record of what actually happened. That's not bad luck. That's a missing process.

Containers Are the AI Team's Secret Weapon

Containers are a force multiplier for AI teams. Plain and simple.

Dev environments? Isolated.
Testing? Repeatable.
Model versions? Locked, tagged, reproducible.

Stability AI trained their models across GPU clusters, with each node running inside a container so the results stayed consistent.

Without containers, your infrastructure becomes a minefield. An AI team running without DevOps is a pilot with a plane and no runway.

Without DevOps You Get Chaos

Here's what I've watched happen, more than once:

✅ Model trained → ❌ weights overwritten by accident.
✅ Inference works locally → ❌ fails in prod.
✅ Upgraded PyTorch → ❌ CI/CD crashes across the board.

None of that is a “bad engineer.” Every one of those is a DevOps problem.

DevOps is the thing that brings order. It's what makes sure the thing that worked today still works tomorrow.

Your AI DevOps Stack: What Real Teams Use

So here's what a real DevOps stack looks like for a modern AI team. Built for scale, reproducibility, and your own sanity.

Docker

For reproducible environments, so your code runs the same everywhere, from your laptop to a production cluster.

docker.com

Testcontainers + DVC

Testcontainers: Spin up real services (like databases or queues) during testing.
DVC (Data Version Control): Version your datasets just like code — essential for ML reproducibility.

GitHub Actions / GitLab CI/CD

Automate testing, model training, and deployment pipelines with modern CI/CD tools.

GitHub Actions | GitLab CI/CD

Kubernetes + Argo CD

Kubernetes: Run and scale containers reliably.
Argo CD: GitOps-style continuous delivery. Keep production in sync with your Git repos.

Monitoring Stack

Prometheus — Metrics collection
Grafana — Dashboards and visualization
Grafana Loki — Centralized log aggregation

ML Experiment Tracking

MLflow or Weights & Biases Track metrics, parameters, and artifacts across experiments.

Security & Policy

HashiCorp Vault — Manage secrets securely
OPA — Enforce policies as code
Snyk — Scan for vulnerabilities in dependencies and containers

None of this is a trendy checklist. It's what lets teams ship reliable, scalable, and production-grade AI systems.

Skip it and you're building sandcastles. Run it and you're shipping real products.

Where You Fit In

Machine learning engineer? Learn to write a Dockerfile. It'll spare your team a world of pain.

Working in DevOps? Step into the ML side. You'll become the backbone of the team almost overnight.

Team lead? Don't wait for something to break first. Put money into DevOps on day one.

Skip it and your AI stays trapped in Jupyter notebooks. Invest in it and it turns into a real product.

The Real Magic of AI Is in the Delivery

Containers. CI/CD. GitOps.

These aren't buzzwords. They're the engineering core of AI in 2025.

LLMs are impressive, sure. But the real magic is everything running cleanly, from training through deployment, at the exact moment you need it.

Thank you for reading! Don't forget to check out the video version for additional insights and visuals.

Master Container Security in 2025 — Best Practices & Live Demo

Vladimir Mikhalev (heyvaldemar.com) — Fri, 14 Mar 2025 00:00:00 GMT

This is a practical guide to container security. Protecting your applications, securing your supply chain, and staying ahead of new threats.

It's 2025. The threats are more frequent now, smarter, and they do more damage. Compromised servers and stolen databases used to be the whole story. Not anymore. Container security sits at the center of it. Over 85% of organizations currently run containerized applications in production.

Container adoption keeps growing, and the security risks grow with it. Attackers know this. So every one of us, whether you write code, run security, design systems, or do DevOps, has to take container security seriously.

Here's what we'll cover:

Why container security matters in 2025
Key best practices that every team should follow
Practical examples using Docker Scout for local scanning and Snyk for continuous security checks in GitHub Actions.

Time is short. Let's get into it.

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

Container Security in 2025

Why does any of this matter in 2025? Look at the architecture. Microservices are everywhere. A single application might be dozens or hundreds of containers, all talking to each other. That blows up your attack surface.

The reason is simple. Every container is its own little environment, with its own OS packages, libraries, and config. One misconfigured container, or one running unpatched software, is enough. That single weakness can turn into a major breach.

Supply chain attacks are climbing too. Attackers stopped going after your code alone. Now they go after whatever you depend on: base images, external libraries, third-party integrations.

Put plainly, the container image itself is a place where things can go wrong. So we have to pay attention to:

What's in our base image
Our runtime environment
The pipeline that builds and ships these containers

My goal here is to give you a practical way to shift security left. Catch issues early in development, where fixing them is cheap, and bake the checks into the work you already do every day

Key Best Practices in Container Security

So how do you actually secure containers? Below are seven core principles. They apply to Docker, to Kubernetes, and to any containerized setup you run.

1. Use Minimal Base Images

Bigger images carry more dependencies. More dependencies means more for an attacker to chew on. Reach for lightweight images like Alpine or distroless instead of a full Linux distribution whenever you can.

Consider the size. Alpine is around 5 megabytes. Ubuntu or Debian run tens or hundreds of megabytes.

Fewer packages, fewer security risks, smaller attack surface. That's the whole point.

2. Pin Your Versions

When you pull an image, don't write this:

FROM python:3

Be specific. Like this:

FROM python:3.13.2-alpine

That locks you to a known version and keeps surprise updates from breaking things or sneaking in a vulnerability. And never use latest as a tag. Pull FROM python:latest and you have no idea what you're actually getting. It can shift under you and break your app.

Worse, an attacker can push a poisoned image under latest, and your system pulls it without anyone noticing.

Pin your versions. Stay in control.

3. Scan Early and Often

Scanning is not a one-and-done step. You scan for risk at every stage:

✅ Development
✅ Staging
✅ Production

Tools like Docker Scout and Snyk handle this for you.

Take Docker Scout. One command scans an image and shows you the risks right there.

Build security into your pipeline on day one. Not as a patch you bolt on at the end.

4. Use Multi-Stage Builds

Leftover dependencies, libraries, and build tools sitting in your container? That's more surface for an attacker to use.

Multi-stage builds fix this. Build your app in one stage, then copy only what you need into a final, smaller image.

That strips out:

🚫 Debugging tools
🚫 Compilers
🚫 Temporary files

What you're left with is smaller, cleaner, and harder to attack.

5. Drop Unnecessary Privileges

Containers run as root by default. That's a big problem. An attacker who takes over a root container can move out across your system.

Run as a non-root user instead. Specify it like this:

USER 1000:1000

What does that actually do?

The first one thousand is the user ID. Just a regular non-root user in Linux.
The second one thousand is the group ID, which puts it in a restricted group.

Run as a low-privilege user and a break-in stays contained. No system-wide access for whoever got in.

6. Keep Secrets Out of Images

Don't bake sensitive data into an image. It's a common mistake, and it leaks your secrets the moment the image gets pulled by the wrong person or shared where it shouldn't be.

Keep secrets somewhere safe instead:

✅ Environment variables
✅ A secrets manager like AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets

And if a secret does get hard-coded by accident, tools like TruffleHog or GitLeaks will catch it before it leaks.

No secrets in images. None in repos. None in logs.

7. Monitor Runtime Behavior

Build-time scanning only gets you so far. You also have to watch what's actually happening in production.

Falco and Sysdig catch suspicious activity inside running containers.

Here's a concrete case. Falco can alert you the moment a container starts a shell out of nowhere, which often means someone is now driving it.

Other things to watch for:

🚨 Unexpected file modifications
🚨 High network activity from a container
🚨 Containers trying to escalate privileges

Watch the runtime and you catch threats while they're still small, before they turn into an incident.

Final Thoughts on Key Best Practices in Container Security

Follow these seven principles and you're already ahead of plenty of organizations still fumbling container security.

Less is more here. Less complexity, lower privileges, fewer secrets. That's a more secure container.

Docker Scout for Local Image Scanning

Enough theory. Let's run Docker Scout for real.

Docker Scout scans your Docker images for security issues and hands you best-practice recommendations.

Before we start, make sure you have:

Docker Desktop 4.38 or later installed
A Docker Account, and that you're signed in using docker login

Say we have a sample Node.js application. This is the Dockerfile.

# Use a lightweight Node.js image based on Alpine Linux
FROM node:22.13.0-alpine

# Set the working directory inside the container
WORKDIR /usr/src/app

# Copy only the package files first (for efficient layer caching)
COPY package*.json ./

# Install Node.js dependencies
RUN npm install

# Copy the entire project (including index.js) into the container
COPY . .

# Expose port 3000 for the Node.js server
EXPOSE 3000

# The default command to run the app
CMD ["node", "index.js"]

I'm using node:22.13.0-alpine here because it's smaller than node:22. Better for containers. Smaller doesn't mean safe, though, so we still scan.

Now build the image.

docker build -t my-node-app:1.0.0 .

That packages the application into a Docker image named my-node-app, version 1.0.0.

Next, point Docker Scout at it.

docker scout cves my-node-app:1.0.0

Docker Scout analyzes the image and flags whatever looks risky.

When the scan finishes, you get a report. It lists the issues it found, their severity, and how to fix them.

Those issues might trace back to system libraries, base packages, or your own application dependencies. Docker Scout will often tell you to upgrade a component or apply a patch.

Why bother locally? Because you catch problems here, before the image ever hits a registry or a production cluster. Fix them now and your environment is more secure immediately.

That's the short version of using Docker Scout to tighten up your containerized applications.

Snyk in GitHub Actions

Let's take it further and automate scanning in the pipeline with Snyk and GitHub Actions.

Before we start, make sure you:

Sign up for a free Snyk account at snyk.io.
Go to your Snyk account settings page, find your Access Token (Key), and copy it.
In your GitHub repo, go to Settings → Secrets and variables → Actions, and create a new secret named SNYK_TOKEN.

Say we have a Node.js project. The goal is straightforward. A developer pushes code or opens a pull request, and Snyk scans for security issues on its own.

Snyk will check the container image to detect risks in the base image and OS packages.
It will also check application dependencies to find security flaws in package.json and other libraries.

Create a GitHub Action Workflow

For this we need a new GitHub Actions workflow file. It goes inside the .github folder, then workflows, and we name it snyk.yml.

name: Snyk Security Scan

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Build Docker image
        run: docker build -t my-node-app:1.0.0 .

      - name: Snyk Container Scan
        uses: snyk/actions/docker@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          image: "my-node-app:1.0.0"
          args: "--file=Dockerfile"

      - name: Snyk Code & Dependency Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: "--file=package.json"

This workflow scans both the Docker image and the application dependencies for risk, automatically. Notice it pulls SNYK_TOKEN from GitHub Secrets. That's the right way to do it. Your credentials stay out of the code, and nothing leaks by accident.

Wrap-Up and Final Tips

We got through a lot:

Why container security matters in 2025
Seven core principles—from minimal images to least privilege
A live demo of Docker Scout for local image scanning
How to automate security scans using Snyk in GitHub Actions

But here's the key takeaway: Container security isn't just about tools or settings—it's a mindset. Everyone on your team plays a role in keeping things secure.

A few more practical things you can do right now:

Monitor runtime with tools like Falco or Sysdig to detect suspicious activity.
Keep everything up to date—patching OS packages and dependencies is one of the simplest and most effective security steps.
Enforce security policies, like blocking deployments if there are serious security issues. A single rule like this can make a big impact.
Educate your team—security isn't just for DevOps or engineers; it's a shared responsibility across developers, QA, and security teams.

Thank you for reading! Don't forget to check out the video version for additional insights and visuals.

Datadog Certification — Are Engineers Just Jumping Through Hoops?

Vladimir Mikhalev (heyvaldemar.com) — Tue, 25 Feb 2025 00:00:00 GMT

I was checking out Datadog's certification program, thinking about how it might help DevOps professionals improve their skills.

And then, I saw this illustration on their website—dogs jumping through hoops.

At first, I laughed. But then I thought... wait a minute.

So if I want to learn Datadog, if I want to get certified, if I want to prove my skills in observability...

Am I just a dog in training?

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

Jumping Through Hoops for a Badge

Look at the metaphor. Dogs on a racetrack, performing tricks, jumping through hoops.

And who are these dogs supposed to represent? Us.

Engineers
Customers
Anyone trying to master Datadog

We're running, jumping, performing tricks... all for what?

A Credly badge to show off on LinkedIn?

Training to Be a "Good Datadog"

Want to prove you understand logs? Jump.

Want to monitor metrics? Jump higher.

Want that official certification? Jump through the final hoop!

And the best part?

You pay $100 to be trained like a good Datadog.

Flexing Your New Status

Once you pass the exam, you can proudly display your Datadog-certified badge on LinkedIn.

Imagine the conversation with recruiters:

“Wow, AWS, Kubernetes, Terraform... and oh, look! A Datadog-certified agility expert!”

Maybe we should update our job titles? "Senior DogOps Engineer"

The Serious Takeaway

Jokes aside, Datadog is a powerful tool and certifications can be valuable.

But honestly, maybe they could have picked a better metaphor?

Engineers aren't circus animals.

We're not jumping through hoops for treats.

Datadog, I'm NOT a dog.

What Do You Think?

If you've taken a Datadog certification, did you feel like an obedient pup by the end?

Drop a comment below—or better yet, tell me if they gave you a treat after you passed!

Top 10 DevOps Tools for 2025 — Must-Have for Developers and Engineers

Vladimir Mikhalev (heyvaldemar.com) — Tue, 18 Feb 2025 00:00:00 GMT

Ten tools I'd actually keep in my 2025 DevOps kit. They cut busywork, tighten infrastructure, and close real security gaps.

If your toolkit is due for a refresh this year, read on.

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

AI & DevOps - Smarter Workflows with Fabric

AI is everywhere. You already know that. ChatGPT, Google Gemini, GitHub Copilot: developers reach for these daily now. But the output is only as good as the prompt, and that is exactly the part most people get wrong. Fabric fixes it.

Fabric helps you write better prompts, so you get answers that are actually accurate and useful. No more hand-tuning the same prompt over and over. It ships ready-made patterns that tell the model what you really want.

If AI sits anywhere in your DevOps workflow, add Fabric. Small tool, big payoff.

CI/CD Evolution - Why Devbox Stands Out

On to CI/CD.

The pipelines themselves have barely moved. GitHub Actions, GitLab CI/CD, Argo Workflows: same engines, year after year. What did change is how we handle dev environments. So my pick here is not another workflow runner. It is Devbox.

Devbox runs on Nix packages. That makes defining and installing dependencies trivial, and it works the same everywhere: your laptop, a CI pipeline, a container.

No more version mismatches. No more hunting down a missing dependency. You get a fully configured environment in seconds. It is portable and light, and if you bounce between machines, it saves you real time.

Containers - Security First with Chainguard Images

Next one. Containers.

They have run modern DevOps for years. Most of us stopped thinking about the runtime a long time ago. Docker, Podman, Rancher: they all get the job done. Docker just does it better.

The part that still matters is security. That is why my 2025 pick is Chainguard Images. The images are small and hardened, built to strip out the usual security risks while keeping size to a minimum. Want safer, leaner containers? Switching to Chainguard is an easy win.

Developer Portals - A Better Alternative to Backstage

Containers are only half the picture. Developer portals are the other half.

Platform engineering took off, and a wave of money went into developer portals so teams could collaborate and ship faster. Backstage was the default for a long stretch. It is also complex and expensive to run. I have done it.

So I recommend Port instead. Port is data-first. You get to see your services, dependencies, and internal tools without the Backstage maintenance tax. It plugs into Kubernetes and cloud platforms cleanly, which makes it a strong fit for platform teams.

GitOps - The Clear Winner is Argo CD

Since we are on Kubernetes, let me get to GitOps.

If you have watched this space, you know the long argument between Argo CD and Flux. That argument is over. Argo CD won.

Flux had a clean architecture, no doubt. It lost steam after WeaveWorks shut down. Argo CD kept growing, with Intuit, Red Hat, and plenty of others behind it. Running GitOps on Kubernetes in 2025? Argo CD. No question.

Infrastructure as Code - The Future is Control Planes

Managing Kubernetes does not end at GitOps, though. Infrastructure is next.

Terraform and Ansible have anchored DevOps for years. The next step for Infrastructure as Code is control planes. My pick there is Crossplane.

Crossplane lets you define infrastructure as APIs. So instead of pushing raw Terraform manifests around, you build an internal cloud platform that is fully API-driven. It cleans up infrastructure management, and it lets teams consume infrastructure as a service.

Manifest Management - Why I Switched to KCL

All that infrastructure leaves you a pile of manifests to manage. Next tool.

Kubernetes manifests usually live in Helm, Kustomize, or plain YAML. None of those scale well.

So I switched to KCL. It is a configuration language that makes Kubernetes manifests cleaner and far easier to maintain. If sprawling YAML has ever burned you, give KCL a look.

Nushell, a different kind of terminal

Different gear now. The terminal, the thing we all live in.

Spend enough hours at a prompt and you owe it to yourself to try Nushell. Bash and Zsh hand you text. Nushell hands you structured data, which makes filtering, processing, and scripting much less painful.

I moved my scripts over to it and never looked back. Fast, sane, and a good fit for how DevOps actually works today.

A Hidden Gem - Why You Should Use NATS

While we are on underrated tools, here is one more.

NATS is a lightweight, high-performance pub/sub messaging system, and most DevOps engineers walk right past it.

You will often find it buried inside other tools as the transport layer. It holds up just as well when you use it directly. Building something event-driven, or wiring up microservices? NATS is a solid alternative to Kafka.

Kubernetes Networking - Why Cilium is a Must-Have

Last one, and it is a big one: Kubernetes networking.

Kubernetes networking gets messy fast. Cilium cuts through it with eBPF. You get better performance and tighter security, and in plenty of setups it removes the need for a separate service mesh entirely. A lot of clusters already ship with it on by default.

Not on your radar yet? Put it there.

Final Thoughts - What Should You Try First?

That is the list. Ten tools shaping 2025:

Fabric - AI-powered prompt optimization
Devbox - Simplified CI/CD environments
Chainguard Images - Secure container images
Port - Lightweight developer portal
Argo CD - The definitive GitOps tool
Crossplane - API-driven infrastructure management
KCL - A better way to manage Kubernetes manifests
Nushell - A modern terminal shell
NATS - High-performance pub/sub messaging
Cilium - The future of Kubernetes networking

Thanks for reading. The video version covers the same ground with extra detail and visuals.

Mastering Terraform Tags for Infrastructure Excellence

Vladimir Mikhalev (heyvaldemar.com) — Thu, 28 Nov 2024 00:00:00 GMT

Let me guess. You've got 347 resources in AWS, half of them say Name = "test", and cost reports look like an accountant's fever dream. Welcome to untagged hell.

The fix? Terraform tags.

They're not glamorous. They're not even that technical. But ignore them and you'll regret it the day your CFO wants a breakdown of cloud costs, or your CISO asks why there's no backup policy for half your infra.

In this post, I'll show you how to make tagging a first-class citizen in your Terraform workflows, not an afterthought. This isn't theory. It's what actually works across real-world deployments in AWS, Azure, and GCP.

What tags actually are, and why you should care

Tags are simple key-value pairs attached to resources. Think of them like sticky notes you can query, bill against, enforce policies with, or automate based on.

Example:

tags = {
  Environment = "Production"
  Owner       = "DevOps Team"
  Project     = "Alpha"
}

That's not decoration. That's future you being able to filter EC2 instances, run scripts against certain deployments, and track cloud costs down to the project.

`tags` vs. `tags_all`

Here's the quick-and-dirty:

tags → What you define in Terraform
tags_all → Includes your tags plus any inherited or default ones

This matters when reading resource state or piping data into automation tools:

output "all_tags" {
  value = azurerm_virtual_network.example.tags_all
}

Real-World Use Cases for Terraform Tags

Organization: Know What the Hell You're Looking At

tags = {
  Name        = "web-api-prod"
  Environment = "Production"
  Purpose     = "Frontend"
}

This lets you run aws ec2 describe-instances --filters "Name=tag:Purpose,Values=Frontend" without guessing.

Cost Management: Avoid the CFO's Wrath

tags = {
  CostCenter = "Marketing"
  Project    = "Campaign42"
}

Most cloud providers let you break down billing by tag. It's not optional if you care about budgets. AWS cost allocation docs if you need the receipts.

Automation: Only Touch What's Tagged

tags = {
  Deploy    = "True"
  ManagedBy = "Ansible"
  PatchDay  = "Sunday"
}

CI/CD pipelines, shutdown schedulers, cron jobs. They all play nicer when you can filter resources by intent.

Access Control: IAM With Tag-Based Sanity

tags = {
  Environment = "Staging"
  Team        = "DataScience"
}

In AWS, you can write IAM policies that only allow access to resources with specific tags. Combine that with SCPs or ABAC and things get powerful, fast. More here.

Compliance & Backup: Stop Guessing

tags = {
  Backup   = "Daily"
  GDPR     = "True"
  Retain   = "90d"
  SOXAudit = "Required"
}

These aren't vanity keys. They're policy hooks. Your backup engine, logging pipeline, or compliance scanner can key off them.

Default Tags: Set Once, Use Everywhere

Writing the same five tags 93 times? You're doing it wrong.

Option 1: Variables

variable "common_tags" {
  type = map(string)
  default = {
    Owner       = "DevOps Team"
    Environment = "Production"
  }
}

resource "aws_instance" "db" {
  ami           = "ami-abc123"
  instance_type = "t3.large"

  tags = var.common_tags
}

Option 2: Provider-Level Tags (AWS)

provider "aws" {
  region = "us-west-2"

  default_tags {
    tags = {
      Owner       = "DevOps Team"
      Environment = "Production"
      Department  = "IT"
    }
  }
}

Now every resource inherits those without repeating yourself. Supported since AWS provider 3.38.0. Docs.

Combining Tags with `merge()`

Need defaults plus some resource-specific extras? This is the clean way:

tags = merge(
  var.common_tags,
  {
    Name = "api-server"
    Role = "backend"
  }
)

Boom. All the defaults, plus your custom info.

Ignoring External Tag Changes (Carefully)

Let's say someone from the security team edits tags via the console. Now Terraform constantly wants to "fix" them. Annoying.

Use this:

lifecycle {
  ignore_changes = [tags]
}

But treat this like sudo. It prevents drift, but also blinds Terraform to reality. Only use when you really need to.

Shared Tagging Strategy Across Teams

If your org has more than two engineers, define a tagging contract:

Use canonical keys (Environment, not Env)
Enforce casing and naming via CI or Sentinel/OPA
Document it. Share it. Tattoo it on the wiki

Consistency saves hours — and arguments.

Best Practices That Don't Suck

Set a tagging standard early. Before the resource count hits triple digits.
Use provider default tags wherever possible.
Automate common tags with variables or modules.
Merge for flexibility, not repetition.
Use tags for automation, not just human readability.
Don't go overboard. 5-8 well-thought-out tags beat 20 vague ones.

Tools That Help

Want tagging enforcement as code?

Spacelift: Tag policy enforcement + OPA support
Checkov / tfsec: Tag linter checks

The Bottom Line

Tags are the duct tape of cloud governance. Boring? Maybe. Critical? Absolutely.

If you're not tagging properly, you're leaving automation, cost tracking, and compliance on the table. And fixing it later is way harder than doing it right upfront.

So: stop treating tags like optional labels, and start using them like the control layer they are.

Simplifying the Transition from Docker Compose to Kubernetes with Compose Bridge

Vladimir Mikhalev (heyvaldemar.com) — Sat, 26 Oct 2024 00:00:00 GMT

Hey, fellow developers and container enthusiasts! Transitioning applications from Docker Compose to Kubernetes can be a daunting task. The differences in configuration syntax, resource definitions, and deployment models often require significant effort to refactor existing applications. Developers face challenges such as:

Complex Configuration Changes: Rewriting compose.yml files into multiple Kubernetes manifest files can be time-consuming and error-prone.
Steep Learning Curve: Understanding Kubernetes concepts like Pods, Deployments, Services, and PersistentVolumeClaims adds complexity.
Resource Management: Managing numerous YAML files and ensuring they are correctly configured for Kubernetes can be overwhelming.

However, there's a powerful tool that bridges this gap: Compose Bridge. Here's how Compose Bridge simplifies your migration to Kubernetes and makes it less error-prone.

Compose Bridge lets you transform your Docker Compose configuration files into Kubernetes manifests effortlessly. It simplifies the deployment process by converting familiar Compose configurations into formats that Kubernetes understands. This lets you use the powerful orchestration capabilities of Kubernetes while maintaining the simplicity and efficiency of Docker Compose.

How Compose Bridge Works

At its core, Compose Bridge uses transformations to convert a Docker Compose model into another form—in this case, Kubernetes manifests. These transformations are packaged as Docker images that take your fully resolved Compose file as input and generate the corresponding Kubernetes configuration files under an /out directory.

Compose Bridge provides its own transformation for Kubernetes using Go templates, making it easy to customize by modifying or extending the templates to suit your specific project needs.

Setting Up Compose Bridge

To get started with Compose Bridge, you'll need the following:

Docker Desktop Version 4.33 or Later: Ensure you have the latest version of Docker Desktop installed on your machine.
Docker Account: Sign in to your Docker account within Docker Desktop.
Enable Experimental Features and Compose Bridge:
- Open Docker Desktop and navigate to Settings.
- Go to Features in development > Experimental features.
- Check the following options:
  - Access experimental features
  - Enable Compose Bridge command line
  - Click Apply & Restart to save your settings.

Using Docker Desktop to Convert Docker Compose to Kubernetes

Compose Bridge integrates directly with Docker Desktop, so you can convert and deploy your Docker Compose applications to Kubernetes directly from the Docker Desktop interface. Here's how to do it:

Step 1: Enable Kubernetes in Docker Desktop:

Open Docker Desktop and navigate to Settings.
Go to Kubernetes and check Enable Kubernetes.
Click Apply & Restart.
Wait for Kubernetes to start. You'll see a Kubernetes is running indicator when it's ready.

Step 2: Verify Your Docker Compose Setup:

Navigate to the Containers tab in Docker Desktop.

Ensure that your Docker Compose services are running correctly.
Check the container logs to confirm there are no errors.

Step 3: Review Your compose.yml File:

Open the Compose File Viewer in Docker Desktop by selecting your Compose application and clicking View configurations.
Review the compose.yml file to ensure it defines the services, volumes, and environment variables you want to deploy.
Confirm that all configurations are correct and complete.

Step 4: Convert and Deploy to Kubernetes:

In the Compose File Viewer, click Convert and Deploy to Kubernetes.

Docker Desktop will prompt you to Stop current project containers to avoid port conflicts.
- Click Stop containers and continue to proceed.

Docker Desktop will convert your Compose file into Kubernetes manifests and deploy them to the Kubernetes cluster.
You'll receive a notification indicating that the configuration was successfully converted and deployed.

Step 5: Review the Generated Kubernetes YAML Files:

After conversion, the Compose File Viewer will display the generated Kubernetes YAML files.
These files include:
- Deployments: Defines the desired state and scaling of your application.
- Services: Exposes your application internally and externally.
- PersistentVolumeClaims: Manages storage requirements.
You can review and edit these files to customize your Kubernetes deployment further.

Step 6: Verify the Kubernetes Pods:

Return to the Containers tab in Docker Desktop.
Ensure that each service from your Docker Compose file is running as a Kubernetes pod.
Check the pod logs to confirm that the services are operating correctly without errors.

Using the Compose Bridge Command Line

Alternatively, you can use the Compose Bridge command-line tool to convert your Compose files to Kubernetes manifests.

Step 1: Use the Default Transformation:

Open your terminal and navigate to the directory containing your compose.yml file.
Run the conversion command:

compose-bridge convert

The command processes your Compose file and generates Kubernetes manifests stored in an out directory.

Step 2: Deploy to Kubernetes:

Ensure Kubernetes is enabled in Docker Desktop.
Apply the generated manifests using:

kubectl apply -k out/overlays/desktop/

This command deploys your application to the Kubernetes cluster.

Understanding the Generated Resources

The default transformation of Compose Bridge produces several Kubernetes resources based on your Compose file:

Namespace: Isolates resources to prevent conflicts between deployments.
ConfigMaps and Secrets: Manages configuration data and sensitive information.
Deployments: Ensures that a specified number of replicas of your application are running.
Services: Defines how to expose your applications internally and externally.
PersistentVolumeClaims: Handles storage requirements for your services.
Network Policies: Replicates the networking topology defined in your Compose file.

Customizing Transformations

Compose Bridge allows you to tailor the transformation process to fit your specific requirements.

Step 1: Modify Default Templates:

compose-bridge transformations create --from docker/compose-bridge-kubernetes my-custom-template

This command creates a directory named my-custom-template containing the templates and a Dockerfile.

Step 2: Customize Template:

Edit the templates within the directory to modify how resources are generated.
You can add, remove, or alter templates to produce the desired Kubernetes manifests.

Step 3: Build and Use Your Custom Transformation:

docker build -t mycompany/compose-transform:latest my-custom-template/

Use your custom transformation:

compose-bridge convert --transformations mycompany/compose-transform:latest

Add New Templates

Create new template files to generate resources not covered by the default templates.
Use the Go templating language to define how the new resources should be generated.
Incorporate custom extensions in your Compose file to provide additional data for the templates.

Building Your Own Transformation

If you require a completely different transformation logic, you can build your own transformation from scratch or use other tools like Kompose.

Step 1: Create a Dockerfile for Your Transformation:

FROM alpine

RUN apk add --no-cache curl

ARG VERSION=1.32.0

RUN ARCH=$(uname -m | sed 's/armv7l/arm/g' \
                  | sed 's/aarch64/arm64/g' \
                  | sed 's/x86_64/amd64/g') && \
    curl -fsSL "https://github.com/kubernetes/kompose/releases/download/v${VERSION}/kompose-linux-${ARCH}" \
    -o /usr/bin/kompose && \
    chmod +x /usr/bin/kompose

CMD ["/usr/bin/kompose", "convert", "-f", "/in/compose.yaml", "--out", "/out"]

Step 2: Build and Use Your Transformation:

docker build -t mycompany/custom-transform:latest .

compose-bridge convert --transformations mycompany/custom-transform:latest

Using Compose Bridge as a kubectl Plugin

Compose Bridge can function as a kubectl plugin, fitting into your Kubernetes command-line workflows.

Step 1: Install the Plugin:

Ensure the compose-bridge binary is in your system's PATH and rename it to kubectl-compose_bridge:

mv /path/to/compose-bridge /usr/local/bin/kubectl-compose_bridge

chmod +x /usr/local/bin/kubectl-compose_bridge

Step 2: Verify Installation:

Run plugin list command to confirm that the plugin is recognized:

kubectl plugin list

Step 3: Use the Plugin:

Run Compose Bridge command using kubectl:

kubectl compose-bridge convert

Benefits of Using Compose Bridge

Simplifies Migration: Converts Compose files to Kubernetes manifests with minimal effort.
Customizable: Allows for extensive customization to fit your deployment needs.
Maintains Familiarity: Enables you to continue using Compose configurations while adopting Kubernetes.
Integrates with Existing Tools: Works with Docker Desktop and can be used as a kubectl plugin.

Conclusion

Transitioning from Docker Compose to Kubernetes doesn't have to be a complex or time-consuming process. Compose Bridge offers a powerful and flexible solution to convert your existing Compose configurations into Kubernetes manifests, allowing you to use Kubernetes' powerful orchestration features without starting from scratch.

By simplifying the migration process, Compose Bridge reduces the barriers to adopting Kubernetes, enabling you to scale your applications and take advantage of its advanced capabilities. Whether you're deploying applications locally using Docker Desktop or planning to scale out to a full Kubernetes cluster, Compose Bridge can help streamline your workflow and reduce the learning curve.

Ready to simplify your Kubernetes deployments? Give Compose Bridge a try and experience a smoother transition from Docker Compose today! We encourage you to experiment with the tool, provide feedback, and contribute to its ongoing development.

For more information and to dive deeper into customization options, check out the official Compose Bridge documentation.

Install ownCloud Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Wed, 16 Oct 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing ownCloud using Docker Compose.

ownCloud is the ultimate file management platform, essential for enterprise-grade file synchronization and sharing, expertly tailored to meet your business needs.

:::tip[Architecture Context] Choose self-hosted ownCloud when you need on-premises file sync and share with full storage control and LDAP integration. Google Drive or Dropbox provide managed alternatives with native mobile apps and collaboration features. Self-hosting is justified when data sovereignty requirements prohibit cloud storage or when storage volumes make per-user SaaS pricing impractical. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/owncloud-traefik-letsencrypt-docker-compose"}

:::note We'll use Traefik as our reverse proxy. It'll handle obtaining cryptographic certificates from Let's Encrypt for your domain names and route requests to the corresponding services based on those domains. :::

:::caution To obtain cryptographic certificates, you will need A-type records in the external DNS zone, which point to the IP address of your server where Traefik is installed. If you have created these records recently, you should wait before starting the installation of the services. Full replication of these records between DNS servers can take from a few minutes to 48 hours or even longer in rare cases. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the ownCloud web interface.

:::

We connect to the server on which ownCloud is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for ownCloud using the command:

docker network create owncloud-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for ownCloud to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/owncloud-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd owncloud-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as owncloud-traefik-letsencrypt-docker-compose.yml. :::

Now let's start ownCloud with the command:

docker compose -f owncloud-traefik-letsencrypt-docker-compose.yml -p owncloud up -d

To access the ownCloud management panel, go to https://owncloud.heyvaldemar.net from your workstation, where owncloud.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to ownCloud.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

The next step is to provide: workspace name, your full name, an email address and a password to create a ownCloud administrator account.

Click on the "Create workspace" button.

Welcome to the ownCloud control panel.

To access the Traefik control panel, go to https://traefik.owncloud.heyvaldemar.net from your workstation, where traefik.owncloud.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Docmost Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Mon, 30 Sep 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Docmost using Docker Compose.

Docmost is an open-source wiki and documentation platform that offers a collaborative alternative to Confluence and Notion.

:::tip[Architecture Context] Choose self-hosted Docmost when you need an open-source documentation platform with full data ownership and no per-seat licensing costs. For teams that prioritize ecosystem integrations over cost control, Notion or GitBook provide managed alternatives with richer collaboration features. Self-hosting Docmost makes sense at scale where per-user SaaS pricing becomes a significant line item. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/docmost-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Docmost web interface.

:::

We connect to the server on which Docmost is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Docmost using the command:

docker network create docmost-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Docmost to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/docmost-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd docmost-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as docmost-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Docmost with the command:

docker compose -f docmost-traefik-letsencrypt-docker-compose.yml -p docmost up -d

To access the Docmost management panel, go to https://docmost.heyvaldemar.net from your workstation, where docmost.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Docmost.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

The next step is to provide: workspace name, your full name, an email address and a password to create a Docmost administrator account.

Click on the "Create workspace" button.

Welcome to the Docmost control panel.

To access the Traefik control panel, go to https://traefik.docmost.heyvaldemar.net from your workstation, where traefik.docmost.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install AFFiNE Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Sun, 29 Sep 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing AFFiNE using Docker Compose.

AFFiNE is a full-featured, open-source workspace that functions as an operating system for all the components that form your knowledge base and beyond. It integrates features like a wiki, knowledge management, presentations, and digital assets management. AFFiNE is a superior alternative to platforms like Notion and Miro.

:::tip[Architecture Context] Choose self-hosted AFFiNE when your team requires full data ownership over knowledge management content or operates under data residency requirements. For teams prioritizing speed of adoption over infrastructure control, Notion provides a managed alternative with richer integrations. Self-hosting trades operational overhead for complete control over data storage, backup schedules, and access policies. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/affine-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the AFFiNE web interface.

:::

We connect to the server on which AFFiNE is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for AFFiNE using the command:

docker network create affine-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for AFFiNE to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/affine-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd affine-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as affine-traefik-letsencrypt-docker-compose.yml. :::

Now let's start AFFiNE with the command:

docker compose -f affine-traefik-letsencrypt-docker-compose.yml -p affine up -d

To access the AFFiNE management panel, go to https://affine.heyvaldemar.net from your workstation, where affine.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to AFFiNE.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click on the "Continue" button.

The next step is to provide: your full name, an email address and a password to create a AFFiNE administrator account.

Click on the "Continue" button.

Welcome to the AFFiNE control panel.

To access the Traefik control panel, go to https://traefik.affine.heyvaldemar.net from your workstation, where traefik.affine.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Homebox Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Sat, 28 Sep 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Homebox using Docker Compose.

Homebox is an inventory and organization system designed specifically for home users. Emphasizing simplicity and ease of use, it offers the perfect solution for managing your home inventory, organizing belongings, and streamlining household management.

:::tip[Architecture Context] Choose self-hosted Homebox when you need a lightweight home inventory system with full data ownership and no subscription fees. Sortly provides a managed alternative with barcode scanning and team features. Self-hosting is justified when you want a simple, privacy-first inventory tool without recurring SaaS costs or when you need to integrate with your existing backup infrastructure. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/homebox-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Homebox web interface.

:::

We connect to the server on which Homebox is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Homebox using the command:

docker network create homebox-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Homebox to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/homebox-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd homebox-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as homebox-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Homebox with the command:

docker compose -f homebox-traefik-letsencrypt-docker-compose.yml -p homebox up -d

To access the Homebox management panel, go to https://homebox.heyvaldemar.net from your workstation, where homebox.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Homebox.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click on the "Register" button.

The next step is to provide: your full name, an email address and a password to create a Homebox administrator account.

Click on the "Register" button.

Enter the email and password previously set, and click the "Login" button.

Welcome to the Homebox control panel.

To access the Traefik control panel, go to https://traefik.homebox.heyvaldemar.net from your workstation, where traefik.homebox.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Ollama Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 27 Sep 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Ollama using Docker Compose.

Ollama is a streamlined, modular framework designed for developing and operating language models locally.

:::tip[Architecture Context] Choose self-hosted Ollama when you need local LLM inference with full data privacy — no prompts or responses leave your infrastructure. The OpenAI API or AWS Bedrock provide managed alternatives with larger model selection and zero GPU maintenance. Self-hosting is justified when data sensitivity prohibits external API calls or when predictable inference costs outweigh the capital expense of GPU hardware. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/ollama-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Ollama web interface.

:::

We connect to the server on which Ollama is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Ollama using the command:

docker network create ollama-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Ollama to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/ollama-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd ollama-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as ollama-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Ollama with the command:

docker compose -f ollama-traefik-letsencrypt-docker-compose.yml -p ollama up -d

To access the Ollama management panel, go to https://ollama.heyvaldemar.net from your workstation, where ollama.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Ollama.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click on the "Sign up" button.

The next step is to provide: your full name, an email address and a password to create a Ollama administrator account.

Click on the "Create Account" button.

Welcome to the Ollama control panel.

Please wait for the models listed in your .env file to download; the duration will depend on your internet speed. Once downloaded, you can select any model from the left corner of the interface to start using it.

To access the Traefik control panel, go to https://traefik.ollama.heyvaldemar.net from your workstation, where traefik.ollama.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Nextcloud Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Mon, 02 Sep 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Nextcloud using Docker Compose.

Nextcloud is an analogue of Dropbox, which you can install on your own server and make a cloud for storing files - photos, videos and any others. The application can be used for collaboration and confidential file sharing, setting access levels for each user. You can also make voice and video calls using the separate NextCloud Talk mobile app.

:::tip[Architecture Context] Choose self-hosted Nextcloud when your organization requires on-premises file storage with full data sovereignty, custom storage backends, and no per-user licensing. Google Drive or Dropbox provide managed alternatives with native collaboration and lower operational cost. Self-hosting is justified when data residency requirements or storage volume make SaaS per-user pricing impractical. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/nextcloud-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Nextcloud web interface.

:::

We connect to the server on which Nextcloud is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Nextcloud using the command:

docker network create nextcloud-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Nextcloud to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/nextcloud-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd nextcloud-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as nextcloud-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Nextcloud with the command:

docker compose -f nextcloud-traefik-letsencrypt-docker-compose.yml -p nextcloud up -d

To access the Nextcloud management panel, go to https://nextcloud.heyvaldemar.net from your workstation, where nextcloud.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Nextcloud.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password that you previously set in the .env file, and click the "Log In" button.

Welcome to the Nextcloud control panel.

Background Jobs Using Cron

To ensure your Nextcloud instance operates efficiently, it's important to use the "Cron" method to execute background jobs. A dedicated Docker container has already been set up in your environment to handle these tasks.

Steps to Enable Cron

Log in to Nextcloud as an Administrator.
Go to Administration settings (click on your user profile in the top right corner and select "Administration settings").
In the Administration section on the left sidebar, select Basic settings.
Scroll down to the Background jobs section.
Select the "Cron (Recommended)" option.

Why Use Cron?

The "Cron" method ensures that background tasks, such as file indexing, notifications, and cleanup operations, run at regular intervals independently of user activity. This method is more reliable and efficient than AJAX or Webcron, particularly for larger or more active instances, as it does not depend on users accessing the site to trigger these tasks. With the dedicated container in your setup, this method keeps your Nextcloud instance responsive and in good health by running these jobs consistently.

To access the Traefik control panel, go to https://traefik.nextcloud.heyvaldemar.net from your workstation, where traefik.nextcloud.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Choosing Between Docker Swarm and Kubernetes for Container Management

Vladimir Mikhalev (heyvaldemar.com) — Fri, 16 Aug 2024 00:00:00 GMT

You're here for one reason. You need to pick an orchestrator that won't burn you a year from now.

Maybe your boss wants Kubernetes. Maybe your CI still runs on Docker Compose. Or you're trying to scale without rewriting the whole stack from scratch. Doesn't matter which. Here's the honest read on Swarm vs. Kubernetes from someone who's run both in production and is still standing.

Docker Swarm: The Lightweight Underdog That Still Punches

Swarm takes a cluster of Docker hosts and makes them act like one virtual engine. That's the whole trick. It's still useful in 2025.

Since 2019 it's been owned by Mirantis, not Docker Inc. That matters more than people think. Go in expecting Kubernetes-speed development and you'll walk away let down.

For teams who value simplicity, though, Swarm still does the job.

What Swarm Does Well

Declarative deployments with simple YAML syntax — even easier than Compose.
Built-in rolling updates with zero downtime (assuming your app handles it).
Out-of-the-box overlay networking with automatic service discovery.
TLS and encryption between nodes enabled by default — no extra setup.

Already living in the Docker CLI? Swarm feels like home.

📖 Mirantis Docker Swarm Docs

Kubernetes: Industrial-Grade Orchestration at a Price

Kubernetes is the heavy option. Google built it to run hyperscale workloads, and every cloud vendor on Earth keeps it alive.

Powerful. Extensible. And complex as hell if you're new to it.

What Kubernetes Gets Right

Horizontal autoscaling: spin up more pods when traffic spikes.
Self-healing services: crashed pods are restarted automatically.
Dynamic volume provisioning with support for multiple backends (NFS, EBS, PVCs, etc.).
Fine-grained security with RBAC, network policies, PodSecurity standards, and more.

Then there's the ecosystem, which is enormous. Prometheus, Istio, ArgoCD. If a tool is worth using, somebody already wired it to Kubernetes.

📖 Kubernetes.io

Head-to-Head Comparison

Here's the part that actually decides things: features, tooling, and the trade-offs you hit in the real world.

Networking

Swarm: Overlay networks are easy. Built-in DNS and load balancing. Great for small-to-mid setups.
Kubernetes: More powerful, more secure — supports service meshes, network policies, and custom ingress controllers. But it takes work.

Storage

Swarm: Volumes work, but that's it. No dynamic provisioning or persistent volume claims.
Kubernetes: StorageClasses, dynamic volumes, CSI plugins — it's built for running stateful services at scale.

Security

Swarm: TLS everywhere by default. RBAC is there but basic.
Kubernetes: Industrial-grade security. Per-pod policies, secrets, service accounts — everything you need to lock it down.

Tooling and Integration

Swarm: Plays nicely with the Docker ecosystem. Compose, CLI, and Docker Hub all work together.
Kubernetes: Hooks into everything. GitOps, monitoring, tracing, CI/CD, you name it.

Ecosystem and Future

Swarm: Still alive, thanks to Mirantis. But let's be honest — development is slow.
Kubernetes: Rapidly evolving, with an army of contributors and full cloud support (EKS, GKE, AKS, etc.).

So, Which Should You Use?

No hedging. Here's how it breaks down:

Use Case	Pick This
You want dead-simple orchestration for internal tools or staging	Docker Swarm
You already know Docker and want a soft learning curve	Swarm
You're deploying production-grade services with autoscaling, CI/CD, and GitOps	Kubernetes
You need fine-grained security, multitenancy, and persistent storage	Kubernetes
You're migrating to or already in the cloud	Kubernetes

My Rule of Thumb?

Fewer than 10 services and you just want to ship? Go Swarm.
The moment your system diagram needs multiple boxes and arrows, it's Kubernetes time.

Final Words

Swarm isn't dead. Kubernetes isn't magic. Both are tools. Pick the one that fits your team, your stack, and your actual operational reality.

Still on the fence? Spin up both. Build something trivial and deploy it. Then watch where your hours go: writing YAML, or fixing YAML.

Cheburnet as the Fortress of Lies and Censorship in Russia

Vladimir Mikhalev (heyvaldemar.com) — Sat, 10 Aug 2024 00:00:00 GMT

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 (heyvaldemar.com) — Wed, 24 Jul 2024 00:00:00 GMT

There's a lot of noise out there. Some say Platform Engineering is the new DevOps. Others say DevOps is dead. Most people just want their CI/CD to stop breaking every Friday night.

Here's the truth. DevOps and Platform Engineering aren't enemies. They're on the same side. But they do very different jobs, and if you're building modern systems you need to understand both. No buzzwords. No corporate diagrams. Just the reality from someone who has built the pipelines, deployed the platforms, and lived to tell the tale.

So What Is DevOps, Really?

Forget the DevOps-as-a-job-title nonsense. DevOps is a culture shift. It says developers and ops don't sit in silos lobbing blame and Jira tickets at each other.

The real goals:

Automate everything (builds, tests, deploys, rollbacks)
Shorten feedback loops between commit and production
Make infrastructure repeatable and resilient
Break the wall between code and runtime

CI/CD pipelines, observability stacks, IaC, chatops. Those are just how we do it. The outcome is faster, safer delivery. That's the part that matters.

Then What's Platform Engineering?

Platform Engineering is what happens when DevOps grows up.

Every team reinventing Dockerfiles, Helm charts, and GitLab jobs is waste. So platform engineers build Internal Developer Platforms (IDPs) that do it for them. The right way. Every time.

These platforms offer:

Golden paths: sane defaults, reusable templates
Self-service: devs get what they need without waiting on ops
Governance: security and compliance baked in, not duct-taped later
Automation: provisioning, pipelines, secrets, telemetry, all wired together

Platform Engineering doesn't replace DevOps. It productizes it.

Key Differences That Actually Matter

Let's stop pretending they're the same thing:

Area	DevOps	Platform Engineering
Scope	Broad — culture + tools	Narrow — productizing infrastructure
Focus	Automating delivery	Building platforms
Users	Devs + Ops teams	Devs (as customers)
Outcomes	Speed, feedback loops	Reliability, self-service, scale
Mindset	"How do we deliver faster?"	"How do we make devs productive?"

DevOps is the philosophy. Platform Engineering is the product built on top of it.

What Each Role Actually Does

DevOps Engineer

Automates CI/CD
Manages monitoring/logging
Builds IaC pipelines
Handles on-call and incident response
Works across product teams

Platform Engineer

Builds IDPs using tools like Backstage or Kratix
Maintains golden templates (e.g. Helm, Terraform modules)
Automates access to infra and secrets
Handles platform versioning, upgrades, and lifecycle
Treats devs as users, not coworkers

The mindset gap is the real difference. DevOps is glue. Platform Engineering is a product.

Why Platform Engineering Took Off

DevOps works great until your company grows. Then every team ends up with its own Terraform repo, its own CI logic, its own broken alerting rules. The sprawl is brutal.

Platform Engineering fixes that. You build opinionated, reusable pipelines and infrastructure that all teams share. Think:

One way to deploy services
One place to provision infra
One way to observe, secure, and scale

It scales DevOps practices across an organization without drowning in entropy.

Tools That Actually Help and Aren't Hype

These aren't shiny tools from slide decks. They're what real teams are running in production:

Spacelift / Atlantis - Terraform automation, policy-as-code, GitOps infra
Backstage - Developer portal for managing services, ownership, templates
Argo CD - GitOps done right for Kubernetes
Crossplane - Control plane for infrastructure APIs
Cue / Jsonnet - Declarative configs without YAML madness
OpenFeature / OpenTelemetry - Standardized feature flags and tracing
Kratix - Real platform productization for custom resources

Don't just collect tools. Wire them into a platform.

Final Word: Build Both, Use Both

Stop asking “DevOps or Platform Engineering?” The answer is yes.

DevOps is the foundation. Platform Engineering is the scaffolding.
Together they give developers fast, secure, repeatable paths to ship code, without waiting three sprints for infra tickets to get answered.

You don't need a hundred microservices and a service mesh to justify Platform Engineering.
You just need tired engineers deploying snowflake stacks and asking: “Why is everyone doing this differently?”

That's when you build the platform.

📚 Want to go deeper?

Don't get lost in the hype. Build the things that make delivery boring, and reliable.

Vladimir Mikhalev Recognized by Docker CEO

Vladimir Mikhalev (heyvaldemar.com) — Mon, 17 Jun 2024 00:00:00 GMT

At the Docker Captains Summit, Docker's CEO, Scott Johnston, acknowledged the exceptional leadership and contributions of Vladimir Mikhalev, Harsh Manvar, and Caroline Martinez.

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

This recognition is one of several on the record. See the full record of named, first-hand references, each claim linked to its proof.

Learn Docker CP Command for Effective File Management

Vladimir Mikhalev (heyvaldemar.com) — Wed, 12 Jun 2024 00:00:00 GMT

You haven't lived in DevOps until you've had to yank logs out of a container that's going down in flames. That's when docker cp becomes your best friend.

Simple. Brutal. Effective.

This guide skips the fluff. I'll show you how to use docker cp like a pro, with real-world examples, the edge cases nobody mentions, and zero hand-holding. Tired of shelling into containers just to grab a config file? Then this one's for you.

What `docker cp` Actually Does

At its core, docker cp lets you copy files to and from containers. No exec. No shell. No drama.

Think of it as the Docker version of scp or cp. The difference is that the “remote” machine is your container's filesystem.

Syntax

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

Want the fine print? Official docs are here.

Real Use Cases (You'll Actually Run Into)

So when do you reach for docker cp? Here's where it earns its keep.

1. Quick Debugging

Container misbehaving? Use docker cp to pull logs or config files without needing a shell.

docker cp mycontainer:/var/log/app.log ./app.log

2. Saving Critical Data

Back up SQLite DBs, flat files, or anything else that lives inside the container.

docker cp mycontainer:/app/data.db ./backup/data.db

Note: If your app writes to /tmp, don't be surprised if it disappears after a restart.

3. Hot Config Injection

Update a config file without rebuilding the image or restarting the container:

docker cp ./nginx.conf mycontainer:/etc/nginx/nginx.conf
docker exec mycontainer nginx -s reload

Examples That Actually Help

Copy a File Into a Container

docker cp ./local.env mycontainer:/app/.env

Copy a File Out of a Container

docker cp mycontainer:/app/logs/output.log ./output.log

Move a File Between Containers (No, There's No Magic)

Docker doesn't support container-to-container copy directly. So do it the old-school way:

docker cp app1:/data/export.csv /tmp/export.csv
docker cp /tmp/export.csv app2:/import/export.csv

Feels clunky? It is. For anything you do often, use volumes.

Gotchas You'll Run Into (and How to Fix Them)

“permission denied”

docker cp won't magically override file permissions. Copy something into /root while your container app runs as node, and guess what? It's not going to work.

Use bind mounts, or fix permissions after the copy:

docker exec mycontainer chown node:node /app/.env

Path Doesn't Exist

Screw up the target path, say by copying into a directory that isn't there, and Docker will not helpfully create it for you. It'll fail. As it should.

When `docker cp` is the Wrong Tool

Doing frequent file syncs? Use bind mounts.
Need data persistence? Use Docker volumes.
Want to avoid weird race conditions with scripts reading partially-copied files? Don't use docker cp mid-execution.

Example: bind mount your code during dev:

docker run -v $PWD:/app myimage

That way, edits on the host show up inside the container the instant you save.

Final Thoughts

docker cp is like a crowbar. Not elegant. Not subtle. But when you need to pry data out of a sealed container, nothing beats it.

Use it for:

One-off debugging
Quick backups
Emergency surgery on broken containers

Don't build your whole deployment process around it, though. For that, reach for volumes and proper orchestration, and stop pretending docker cp is a deployment strategy.

Pro tip: Set an alias. You'll thank yourself at 3AM.

alias dcp='docker cp'

Want to go deeper on Docker CLI workflows or file sync strategies? Ping me, or check out the official Docker docs.

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

Vladimir Mikhalev (heyvaldemar.com) — Thu, 06 Jun 2024 00:00:00 GMT

Russia has a long habit of breaking the people who think out loud. Artists and public figures whose work cut against the official line got the same treatment again and again: silence them, jail them, or push them across the border. Not much has changed. Opposition figures and cultural names today still face arrests and persecution, and many of them have already left. What follows is a set of short biographies, people who were repressed or driven into emigration, running from the Russian Empire through to present-day Russia. The list is nowhere near complete. It keeps growing, which is the depressing part.

Alexander Pushkin (1799-1837, Russian Empire) - A poet the state kept on a short leash. His writing, "Ode to Liberty" among it, irritated Emperor Alexander I enough to get him exiled to the southern provinces. Few ways to publish down there. He wrote anyway.

Mikhail Lermontov (1814-1841, Russian Empire) - A poet undone by a duel and by his poem "Death of the Poet," written for Pushkin. He criticized the authorities openly, the tsar took offense, and Lermontov was sent off to the Caucasus. He died there, in another duel.

Alexander Herzen (1812-1870, Russian Empire) — a writer and thinker, considered the father of Russian socialism. His radical politics drew persecution and eventually pushed him into emigration. From exile he set up the "Free Russian Press" in London, the first independent printing operation of its kind, and it did real work spreading liberal and socialist ideas back home.

Fyodor Dostoevsky (1821-1881, Russian Empire) - Sentenced to death for joining the anti-government Petrashevsky Circle. The sentence became penal servitude in Siberia, then exile, then military service. All of it left deep marks on his writing and his view of the world.

Leo Tolstoy (1828-1910, Russian Empire) - Celebrated as a writer, then excommunicated over his philosophy. He attacked the church and kept pushing his own ideas about morality and the spirit, and the church cut him loose.

Ilya Repin (1844-1930, Russian Empire) - An artist who moved to Finland looking for quiet to work in while Russia tore itself apart. Part of the point was staying out of the politics entirely.

Vaslav Nijinsky (1890-1950, Russian Empire) - A ballet master who got out during the political chaos and the revolution. Leaving probably saved his career. It also meant starting over in unfamiliar places.

Wassily Kandinsky (1866-1944, USSR) - An artist who left over Soviet art policy. He wanted abstraction, the West gave him room for it, and that is where the work came together.

Dmitry Merezhkovsky (1866-1941, USSR) - A writer who emigrated after the October Revolution. He had no use for Bolshevik power and expected to be punished for his monarchist, religious views.

Zinaida Gippius (1869-1945, USSR) - A writer, and Merezhkovsky's wife. She left with him. They shared the same contempt for the new order and the same fear of what it would do to them.

Varlam Shalamov (1907-1982, USSR) — a writer, author of the famous "Kolyma Tales," drawn straight from what he lived. 17 years in the camps. His books put the brutality and the hopelessness of the prisoners on the page without flinching. The Soviet Union banned them, and none came out while he was alive.

Ivan Bunin (1870-1953, USSR) - A writer who emigrated in 1920 and made no secret of his opposition to communism. In 1933 he became the first Russian to win the Nobel Prize in Literature.

Fyodor Chaliapin (1873-1938, USSR) - An opera singer who left over the limits placed on his work and his disagreement with how the Soviet government handled art.

Sergei Rachmaninoff (1873-1943, USSR) - A composer who left after the October Revolution. He would not live under a regime that boxed in his creative freedom and put his family at risk.

Nikolai Berdyaev (1874-1948, USSR) - A philosopher thrown out of Soviet Russia in 1922 on the "Philosophers' Ship," shipped off with other intellectuals whose thinking did not match Bolshevik ideology.

Vsevolod Meyerhold (1874-1940, USSR) - A director arrested and killed in Stalin's purges. His ideas about theater were too inventive for what the authorities wanted.

Zinaida Reich (1894-1939, USSR) - An actress, Meyerhold's wife. They killed her during the purges, after they had arrested and tortured her husband.

Teffi (Nadezhda Lokhvitskaya) (1872-1952, USSR) - A writer who left after the revolution. She rejected the communist government and feared for her life and her freedom to write.

Marc Chagall (1887-1985, USSR) - An artist who emigrated after 1917. His work did not fit socialist realism, so the new authorities had no place for it.

Nikolai Gumilev (1886-1921, USSR) - A poet shot during the repressions, accused of taking part in an anti-monarchist conspiracy. Russian literature took a heavy hit when he died.

Anna Akhmatova (1889-1966, USSR) - A poetess banned from publishing. Her husband and son were arrested. She lived under constant fear and constant watch.

Osip Mandelstam (1891-1938, USSR) - A poet arrested and worked to death in detention. His writing was branded anti-Soviet, and that was enough to take him.

Sasha Chorny (Alexander Glikberg) (1880-1932, USSR) - A poet who left under political pressure, with no way to publish freely in Soviet Russia. He kept writing once he was out, just from abroad.

Mikhail Chekhov (1891-1955, Russian Empire) - An actor and director who left the USSR because the repressive policies made theater impossible. He settled in the USA and built a reputation for his teaching methods.

Igor Stravinsky (1882-1971, USSR) - A composer who emigrated after the October Revolution. His music did not satisfy the new authorities or fit inside socialist realism.

Vladimir Nabokov (1899-1977, USSR) - A writer driven out by the revolution and the danger it brought to his safety and his work. His name was made by what he wrote in English, "Lolita" included.

Philosophers' Ship (1922) - The episode where the Soviet government expelled more than 160 intellectuals, Nikolai Berdyaev and Sergei Bulgakov among them. The point was to clear out the dissenters and anyone whose views clashed with Bolshevik ideology.

Sergei Yesenin (1895-1925, USSR) - A poet who killed himself after running into the authorities and under the weight of pressure tied to his work and his private life. His death hit Russian literature hard.

Vladimir Mayakovsky (1893-1930, USSR) - A poet who killed himself, pushed there by personal and professional crises and by pressure from the authorities. His work did not always toe the party line, which made everything harder.

Nikolai Vavilov (1887-1943, USSR) - A geneticist arrested and left to die in detention on charges of anti-Soviet activity. His real crime: his plant-breeding research contradicted the junk science the Soviet leadership had decided to back.

Solomon Mikhoels (1890-1948, USSR) - An actor and director killed on Stalin's orders as part of an anti-Semitic campaign. They staged it as a car accident.

Isaac Babel (1894-1940, USSR) - A writer arrested, tortured, and executed on charges of spying and anti-Soviet activity. His books were banned and pulled from the libraries.

Nikolai Zabolotsky (1903-1958, USSR) - A poet sent to a camp for years because his writing failed the regime's ideological test.

Alexander Vvedensky (1904-1941, USSR) - A poet who died on the way to a camp, sent there for anti-Soviet activity. His experiments with form did not match the party's official line on literature.

Olga Berggolts (1910-1975, USSR) - A poetess beaten during NKVD interrogations, where she lost a child. She came through it as a voice of besieged Leningrad and kept writing.

Marina Tsvetaeva (1892-1941, USSR) - A poetess exiled and driven to suicide. She could not publish freely, and the pressure from the authorities never let up.

Daniil Kharms (1905-1942, USSR) - A writer who starved to death in a psychiatric hospital after his arrest for anti-Soviet activity. Banned in his lifetime, published only after he was gone.

Dmitry Likhachev (1906-1999, USSR) - An art historian arrested, exiled, and fired over research that did not meet the Soviet ideological bar.

Yevgeny Schwartz (1896-1958, USSR) - A playwright hit with publication bans and official criticism. His satire went after bureaucracy and totalitarianism, and the authorities noticed.

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

Boris Pasternak (1890-1960, USSR) - A writer persecuted and banned over his novel "Doctor Zhivago," which the state called anti-Soviet. He was pressured into turning down the Nobel Prize in Literature.

Mikhail Bulgakov - A writer who lived under censorship and bans. His work, "The Master and Margarita" among it, never saw print while he was alive and was labeled anti-Soviet.

Alexander Solzhenitsyn (1918-2008, USSR) - A writer exiled and then forced out for work that took on the Soviet authorities and the Gulag. They stripped his citizenship, and he stayed in emigration until 1994.

Andrei Tarkovsky (1932-1986, USSR) — a director and screenwriter whose films, "Andrei Rublev," "Stalker," and "Mirror" among them, are known for their philosophical weight and their formal invention. Censorship and restrictions dogged his work, and in the end he emigrated to Western Europe, where he could work in a freer climate.

Yuri Lyubimov (1917-2014, USSR/Russia) - A theatrical director stripped of his citizenship in 1984 for criticizing the Soviet system. He kept working abroad and only came back after perestroika.

Andrei Sakharov (1921-1989, USSR) - A physicist and human rights advocate exiled for criticizing Soviet policy and fighting for human rights. They took every award and title from him. He kept up the work anyway, from exile.

Sergei Dovlatov (1941-1990, USSR) - A writer who emigrated in 1979 because there was no way to publish him in the Soviet Union. The work he did in emigration was only recognized after his death.

Grigory Rodchenkov (b. 1958, USSR) - Former head of the Moscow anti-doping laboratory, who emigrated to the USA after blowing the whistle on the state doping program. His testimony drove the investigations and the sanctions that followed against Russian sport.

Rudolf Nureyev (1938-1993, USSR) — an extraordinary ballet dancer who defected in 1961, mid-tour with the Kirov Ballet in Paris. The escape became an international sensation and a real embarrassment for the Soviet Union at the height of the Cold War. The KGB watched him closely and the authorities resented his leanings toward the West. He took asylum in France and went on to a brilliant career there, while back in the USSR a court handed him a prison sentence in absentia.

Maria Alekhina (Pussy Riot) (b. 1988, Russia) - An activist with the punk group Pussy Riot who left Russia after being persecuted for her political actions and her criticism of the authorities. She keeps up her human rights work from emigration.

Anton Dolin (b. 1976, Russia) - A film critic who moved to Riga under threats and pressure tied to his work and his criticism of Russian authorities. He left in 2022, after the war against Ukraine began, when his anti-war stance and sharp commentary drew the anger of the state and of war supporters.

Artur Smolyaninov (b. 1983, Russia) - An actor who left in 2022 over his criticism of government policy and the war in Ukraine. He spoke against the Russian government again and again, which brought persecution and threats. He works abroad now.

Little Big (Russia) - A band known for satirical, provocative videos. They left over the political situation and the pressure from the authorities. The members emigrated in 2022 and kept the music going abroad.

Anastasia Davydova (b. 1983, Russia) - An Olympic champion in synchronized swimming who left under political pressure and threats. She moved abroad to keep coaching and competing somewhere safer.

Alexander Nevzorov (b. 1958, Russia) - A journalist and publicist with a long record of attacking Russian authorities and policy. In 2022 he left over threats to his life and persecution tied to his journalism. He works abroad now, speaking out against the war in Ukraine and the regime.

Yevgeny Berkovich and Svetlana Petriychuk (b. 1984 and 1985, Russia) - Arrested for staging a play the authorities chose to read as extremist propaganda and an insult to believers. It fit a wider campaign against creative freedom and critical voices in Russia.

Boris Akunin (Grigory Chkhartishvili) (b. 1956, Russia) - A writer hit with a criminal case over his criticism and his support for the opposition. He left Russia rather than wait for arrest and keeps writing abroad.

Vasily Berezin and Stas Falkov (Russia) - Artists who started a collective of exiled Russian artists in Paris. They left under pressure on creative freedom and threats from the authorities. Their work tends to be political, aimed at contemporary Russian society and politics.

Alexei Navalny (1976-2024, Russia) - An opposition politician who died in custody in 2024. Most read that death as a murder tied to his politics and his fight against corruption. He was known for his anti-corruption investigations and his opposition work, and he was arrested and repressed for it again and again.

Memorial (Russia) - A human rights organization liquidated in 2021. Memorial investigated and documented political repression across the Soviet period and modern Russia, and it defended human rights. The state branded it a "foreign agent," leaned on it, and shut it down.

Oleg Orlov (b. 1953, Russia) - Head of the human rights organization "Memorial," sentenced to 2.5 years in a colony. The charge was discrediting the Armed Forces of the Russian Federation, one more move in the campaign against rights defenders.

Dmitry Muratov (b. 1961, Russia) - A journalist and Nobel Peace Prize laureate, attacked in 2022. As chief editor of "Novaya Gazeta" he drew repeated threats and pressure over reporting on the actions of Russian authorities and on corruption.

TV Channel "Dozhd" (Russia) - An independent channel pushed off the air in Russia in 2022 by pressure from the authorities. "Dozhd" was known for straight, critical coverage of Russian politics and society. It kept broadcasting from abroad after it was forced out.

Dmitry Ivanov (Kamikadze Di) (b. 1986, Russia) - A blogger and journalist known for going hard at the Russian government. He was attacked, which drove him to the Czech Republic. He still works to get information about the situation in Russia out.

Vladimir Kara-Murza (b. 1981, Russia) - An opposition politician and journalist known for his outspoken anti-government work. He was poisoned more than once, most likely because of his politics. A court sentenced him to 25 years for criticizing Russia's military actions in Ukraine and for ties to an "undesirable" organization. In May 2023 his appeal was rejected and the sentence stood. He also has polyneuropathy, which prison has made worse.

Mark Feigin (b. 1971, Russia) - A lawyer and human rights defender who emigrated to France. He built his name defending the politically persecuted, members of "Pussy Riot" and Ukrainian journalists among them. His work and his criticism of the Russian government brought pressure, and in 2023 he was declared wanted.

Ilya Yashin (b. 1983, Russia) - A politician and activist, one of the opposition's leading figures, known for criticizing the authorities. In 2022 he was arrested and sentenced to 8.5 years for spreading "false" information about Russia's actions in Ukraine.

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

Yegor Shtovba (b. 2000, Russia) - Took part in the same literary reading as Artem Kamardin, and the Tverskoy Court of Moscow gave him 5.5 years. The charge was spreading "false" information about Russia's military actions, part of the same case against free speech.

Mail Naki (b. 1993, Russia) - An artist and public activist known for anti-war work and criticism of the authorities. His positions and his public actions brought state pressure and threats, which drove him out of Russia to keep working abroad.

Maxim Galkin (b. 1976, Russia) - A comedian and TV host who left in 2022 after being labeled a "foreign agent" for criticizing the Russian government and the war in Ukraine. He works abroad now and keeps speaking out against the war.

Alla Pugacheva (b. 1949, Russia) - A singer and actress who left in 2022 over government policy and the start of the war in Ukraine. She backed her husband Maxim Galkin openly after he was labeled a "foreign agent." She moved to Israel and works from there.

Group "Nogu Svelo!" - A Russian rock group whose front man Maxim Pokrovsky left in 2022 over government policy and the war in Ukraine. The group works abroad now, speaking out against the war and backing anti-war actions.

Group "Bi-2" - A Russian rock group whose members faced pressure from the authorities over their politics. In 2022 they had to cancel their concerts in Russia and partly emigrated, carrying on with the music abroad.

Vitaly Mansky (b. 1963, Russia) - A documentary filmmaker who left in 2014 and moved to Riga, Latvia. He is known for critical films, often built around political and social subjects. In 2014 he started the open letter "We are with You!" supporting Ukrainian filmmakers against Russia's military intervention. In 2022 he spoke out against the invasion of Ukraine, and the Russian Ministry of Internal Affairs declared him wanted on defamation charges. In 2023 the Russian Ministry of Justice put him on the foreign agents list. He keeps working in documentary film abroad, running the Artdocfest/Riga festival and earning recognition at international festivals.

Mastering GitLab CI/CD with Advanced Configuration Techniques

Vladimir Mikhalev (heyvaldemar.com) — Fri, 31 May 2024 00:00:00 GMT

Forget the glossy dashboards and the slick demos. Real DevOps happens in the trenches, and your .gitlab-ci.yml is the weapon. If you've ever sat there at 2AM screaming at a broken pipeline, you already know the deal. GitLab CI/CD is powerful. But only once you stop treating the YAML like a to-do list and start treating it like an automation framework.

This is not another "Hello, pipeline" walkthrough. It's the stuff that actually makes GitLab CI/CD worth running: cleaner configs, builds that finish before you lose patience, deploys that don't wake you up. No fluff.

GitLab CI/CD in one sentence

It's just code that builds, tests, and ships your other code. Every push. Every merge. Every time you break something.

All of it lives in one file. .gitlab-ci.yml.

What a real pipeline actually looks like

A lot of the YAML floating around out there reads like someone copied it off Stack Overflow, said a quiet prayer, and hit push. Don't do that. Here's how to structure a pipeline you can still maintain six months later.

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..."

That's the skeleton. Clean and linear. Each stage is one phase of the pipeline. Jobs in the same stage run in parallel, assuming your runners can take it. Want a faster pipeline? This is the first lever you pull.

Docker FTW

If you're not pinning your jobs to Docker images, you're running CI in hard mode for no reason.

image: node:20-alpine

build_job:
  stage: build
  script:
    - npm ci
    - npm run build

Pick the right image and your builds get reproducible and portable. Sometimes even fast. Just don't use latest. Not unless you enjoy surprise breakages on a Monday morning.

Artifacts and cache: the fuel CI runs on

Now let's make things quick.

Artifacts move data between jobs

build_job:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/

Cache moves data between pipelines

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

Use both with some care and your pipeline goes from molasses to caffeinated cheetah. Abuse them and you'll be debugging stale builds in Slack at midnight. Your call.

Modular configs with `include`

Once that pipeline file crosses 100 lines, YAML turns into YELL.

So split it up.

include:
  - local: ".gitlab-ci/build.yml"
  - local: ".gitlab-ci/deploy.yml"
  - project: "devops/templates"
    file: "/shared/test-suite.yml"

Now the config is maintainable, reusable, testable. Like actual code, which is what it is.

Keep secrets in the vault

This should be obvious. I'll say it loud anyway, for the folks in the back.

Never hardcode secrets in your YAML.

variables:
  AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY

Manage these in GitLab's UI, at the project, group, or instance level. Use protected variables for protected branches. Basic hygiene. Don't be the person who commits prod_db_password: hunter2.

before_script and after_script: your pipeline's wrapper

Need to prep or clean up on every run? These are your hooks.

test_job:
  stage: test
  before_script:
    - echo "Setting up..."
  script:
    - npm test
  after_script:
    - echo "Tearing down..."

I reach for them to bootstrap test databases, set env vars, pull logs, and rage-log failures. Setup and teardown, the same as you'd write in a test suite.

Smarter pipelines with `rules`

Want jobs that fire only when they should? Quit misusing only/except. Use rules like a grown-up.

deploy_prod:
  stage: deploy
  script:
    - ./scripts/deploy-prod.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: always
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: never

No more deploying off some typo branch by accident.

Real optimization: dynamic variables and better caching

You can steer pipeline behavior on the fly with job-level variables.

deploy:
  stage: deploy
  variables:
    ENV: "staging"
  script:
    - ./deploy.sh $ENV

Lean on CI_COMMIT_REF_NAME and the other built-ins to drive environments, image tags, artifact names, whatever you need.

And yes, cache keys matter.

cache:
  key: "${CI_COMMIT_REF_SLUG}"
  paths:
    - vendor/

One cache per branch keeps builds fast and stops branches from poisoning each other's state.

TL;DR: how to not suck at GitLab CI

Your .gitlab-ci.yml is real code. Treat it like it
Use Docker images, not host dependencies
Cache smartly, artifact deliberately
Stop repeating yourself. Modularize with include
Use rules to make the pipeline conditional and intelligent
Secrets go in the GitLab UI, never in version control
Optimize for speed, clarity, and safety, in that order

Takeaway

CI/CD isn't magic. It's engineering. And a bad pipeline will quietly eat your hours, your weekends, and whatever's left of your patience.

So build it right the first time. Start with the basics. Modularize as the thing grows. Automate like your job depends on it, because some days it actually does.

Next step is simple. Open the .gitlab-ci.yml, tear out the duct tape, and make it battle-ready.

And if you're serious about getting good at this, bookmark GitLab's CI/CD docs. Then go read them.

Mastering Terraform Contains and Strcontains Functions

Vladimir Mikhalev (heyvaldemar.com) — Sat, 25 May 2024 00:00:00 GMT

Terraform is declarative. Which is a polite way of saying you don't get if-statements like a normal programmer. You still need to validate inputs. You still need to gate deployments and steer behavior. So you reach for the logic tools the language actually hands you.

Two of them look trivial and turn out to be ridiculously useful: contains() and strcontains().

If a bad variable, a missing VM size, or a misnamed AZ has ever cost you a Saturday, read on.

Here's how both work. No fluff.

`contains()`: is the value in there, or are you debugging all weekend

contains() checks whether a specific value sits inside a list or a set.

contains(list, value) => bool

Returns true if the list has the value. false if it doesn't. That's the whole API.

Basic? Yes. But once your infra logic starts leaning on user input, region capabilities, or feature flags, this little function turns into the bouncer at the door of your Terraform nightclub.

Real example: Azure VM sizes

Picture someone on the team requesting a beefy VM in a tiny region that can't host it. You want to catch that before the apply blows up.

variable "region" {
  default = "uksouth"
}

variable "vm_size" {
  default = "Standard_DS2_v2"
}

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

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

If vm_size isn't offered in that region, you get false. Feed that into a count, a for_each, or a validation block. Whatever you pick, it beats watching Terraform barf mid-deploy.

`strcontains()`: when you're parsing strings like it's bash again

Now strcontains(). This is Terraform answering one question: does this string have that other string inside it?

strcontains(string, substr) => bool

Reach for it when there's no list, just a single string. An AZ name, a tag, a label. You want to match a pattern in it.

Example: is this AZ optimized

strcontains("us-east-1b-optimal", "optimal") // returns true

It earns its keep when providers or modules hand back strings with metadata baked in and you need to route logic off that.

Say you only want to deploy when the target zone is labeled "optimal":

locals {
  is_optimal_zone = strcontains(var.availability_zone, "optimal")
}

Now local.is_optimal_zone is your switch. Use it to create resources, set tags, add taints, whatever the condition gates.

Gotchas that bit me, so they don't bite you

contains() wants the exact value. Case-sensitive. No fuzzy matching.
strcontains() doesn't do regex or wildcards. Pure substring, nothing more.
Maps don't behave with contains() the way you'd hope. Lists and sets only. Try contains({ key = "val" }, "key") and you'll be disappointed.
Nulls can wreck your results. Validate your variables, or wrap them in coalesce() when it matters.

Bonus: validate with style

Want to enforce rules on inputs? Drop these functions into validation blocks.

variable "az" {
  type    = string
  default = "us-east-1b-optimal"

  validation {
    condition     = strcontains(var.az, "optimal")
    error_message = "Only 'optimal' AZs are allowed for this deployment."
  }
}

Now Terraform fails early, with a message a human can read, instead of crashing halfway through the plan.

TL;DR

Reach for contains() with lists or sets.
Reach for strcontains() for substring checks on a single string.
Pair them with validation, count, or for_each for logic that stays clean and safe inside your modules.
Don't guess. Test.

The 80th Anniversary of the Deportation of the Crimean Tatars

Vladimir Mikhalev (heyvaldemar.com) — Sat, 18 May 2024 00:00:00 GMT

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

Building AI Solutions with Docker Compose and Kubernetes Expertise

Vladimir Mikhalev (heyvaldemar.com) — Mon, 13 May 2024 00:00:00 GMT

You're building AI workloads. So you're juggling Python packages, GPU drivers, REST APIs, databases, maybe a Kafka pipeline on top of all that. And if you're still herding it with bash scripts and hope?
You're doing it wrong.

This guide is about how Docker Compose tames the chaos of a modern AI project. Not the toy version. The version someone runs when they've actually shipped containers in production instead of poking at notebooks.

I'll get into the real usage. Environment handling. Image pull policies. Secrets, resource limits, and the one command, docker compose watch, that saves your sanity during dev cycles. There's also the part nobody enjoys: handing your Compose stack off to Kubernetes without rage-quitting.

Compose 2.x: A Dev Tool That Grew Up

Compose is still your best friend for local work. No argument there. But it's also a serious CI/CD asset now, and a genuinely good staging orchestrator, if you know how to drive it.

Enough preamble.

Environment Variable Precedence: Know Who Wins the Fight

By default, Compose favors your shell environment over whatever sits in your .env file.

So this:

export DATABASE_URL=postgres://prod.db

…will override this in .env:

DATABASE_URL=postgres://dev.db

Good. That's exactly the behavior you want in CI/CD, where secrets have no business touching source control.

📖 Environment Variables — Compose Docs

Controlling Image Pulls: Don't Get Burned by Stale Containers

There are two clean ways to pull fresh images.

Force it every time:
```
docker compose up --pull always
```

Lock it in the Compose file:

services:
  app:
    image: my-image:latest
    pull_policy: always

pull_policy supports: always, if_not_present, and never.

Use it. Skip it and you'll burn an afternoon debugging a bug that doesn't exist, because CI quietly served a stale image from cache while you screamed at your pipeline.

SSH & Secrets: Handling Sensitive Stuff Like an Adult

BuildKit is the default now. That buys you real control over build-time secrets and SSH access.

SSH During Builds

Need to clone a private repo mid-build?

services:
  app:
    build:
      context: .
      ssh:
        - default=/home/user/.ssh/id_rsa

The key never lands in the image. No more "oops I leaked my SSH key to Docker Hub".

Runtime Secrets

Compose doesn't do Docker Swarm-style secrets. You can fake it with mounted files or env vars. Or, if you're serious about it, wire in a vault.

📖 SSH & Secrets in Compose

Live Reloads with `docker compose watch`: Real Dev Speed

You want a tight feedback loop. That's what the watch command is for.

Real-World Example: Node.js App

services:
  app:
    image: node:18
    volumes:
      - .:/app
    working_dir: /app
    command: npm start
    environment:
      NODE_ENV: development
    ports:
      - "3000:3000"
    labels:
      com.docker.compose.watch: "true"

Then run:

docker compose up
docker compose watch

Change a file locally and the container picks it up. No rebuild. No restart. No staring at the screen wondering why your fix didn't take.

📖 Docker Compose Watch Docs

Override Files: Keep Dev and Prod from Colliding

Still cramming every config into one compose.yaml? Stop. Split it:

compose.override.yaml for local tweaks
docker compose -f base.yaml -f prod.yaml to layer configs
include: blocks, if you're on Compose v2+ and feeling fancy

It's cleaner, it's safer, and it's a lot easier to debug when something breaks at 2am.

📖 Extending Compose Files

YAML Anchors: DRY or Die

Compose files turn into spaghetti fast. Anchors fix that:

x-default-env: &default-env
  NODE_ENV: production

services:
  web:
    image: webapp
    environment: *default-env

  api:
    image: apiserver
    environment:
      <<: *default-env
      DEBUG: true

Less repetition, fewer bugs, and a file you can actually read six months from now.

📖 Compose File Fragments

Resource Limits: Be a Good Container Citizen

Even on a dev cluster, don't let one container eat the whole node.

services:
  ai-worker:
    image: my-ai-image
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: "1G"
        reservations:
          cpus: "0.5"
          memory: "512M"

Now, a caveat. deploy is ignored by docker compose in local mode. But the second you hand this off to Swarm or translate it to Kubernetes, you'll be glad it was already there.

Compose to Kubernetes: The Good, The Bad, and The “Use Kompose”

Want to turn a Compose stack into Kubernetes YAMLs? Kompose does it, and the output isn't terrible.

kompose convert

You'll still have homework:

Set up Ingress and controllers by hand
Configure PVCs and storage
Handle secrets the Kubernetes way

For MVPs and small internal tools, though, it works fine.

Just don't ship the raw output to production. Clean it up first.

Final Take

Docker Compose stopped being a one-trick Redis-launcher a while ago. Driven well, it's a serious tool, and it earns its keep most in AI workflows, the kind that sprawl across a dozen services.

It lets you:

Develop locally at full speed
Keep secrets out of your images
Cut downtime during builds
Hand off to Kubernetes when the time comes

If you're shipping AI services and you're not using Compose properly, you're just making the job harder than it is.

📖 Read the Full Compose Docs

Future-Proofing JavaScript with ESM and CJS Compatibility Techniques

Vladimir Mikhalev (heyvaldemar.com) — Wed, 08 May 2024 00:00:00 GMT

JavaScript's module system is a lot like Git. Powerful, confusing, and still a daily source of pain years after you thought you'd figured it out.

Published an NPM package lately? Then you've fought this. You add "type": "module" to your package.json, and half your consumers start screaming. Or you leave it off, and now tree-shaking is dead. There's no clean default. It's a mess either way.

So let's fix it.

This guide is about building dual-compatible JavaScript packages. Packages that work whether someone require()s them or imports them, without blowing up your CI pipeline and without giving up modern tooling.

Why You Should Care (Even as a DevOps Engineer)

You probably think this is a frontend problem. It isn't. CLI tools, Dockerized apps, Lambda functions, microservices in Node.js: for all of them, module format matters.

Build tooling wants ESM. Legacy code wants CJS. Your job is to feed both without the whole thing folding in on itself like a badly wired monorepo.

The ESM vs. CJS TL;DR

I'll skip the history lesson. Here's what actually matters in practice:

Format	ESM	CJS
Syntax	`import/export`	`require/module.exports`
Node.js	Default in `.mjs` or `"type": "module"`	Default in `.js` or `"type": "commonjs"`
Pros	Native in browsers, tree-shaking, async imports	Ubiquitous, works everywhere
Cons	Can't `require()` it	Can't `import` it (without wrappers)

So no, slapping .mjs on everything and praying is not a strategy. Do it properly.

Rule #1: Don't Use `"type": "module"` in Shared Packages

Set "type": "module" in a library's package.json, and you've just locked that library into ESM-only territory.

Now every CJS consumer is stuck doing bundler gymnastics to use it. Bad trade.

Do this instead. Define dual entry points and let the consuming app pick what it wants.

Example: Dual-Compatible `package.json`

This is the config I actually ship in real packages. Clean, and it works:

{
  "name": "example-library",
  "version": "1.0.0",
  "description": "Dual ESM and CJS compatible library",
  "main": "dist/index.cjs",
  "module": "dist/index.mjs",
  "exports": {
    ".": {
      "require": "./dist/index.cjs",
      "import": "./dist/index.mjs"
    }
  },
  "keywords": ["esm", "cjs", "npm", "compatibility"],
  "license": "MIT"
}

Why this works

main: Used by CJS consumers and legacy bundlers
module: Used by modern bundlers like Vite, Webpack (for ESM)
exports: Official Node.js way to define conditional entry points

✅ This setup lets both require() and import work cleanly without surprises.

Common Mistakes

Mixing CJS and ESM in the same file: Just don't. Keep them separate.
Forgetting .cjs and .mjs extensions: Node cares. A lot.
Assuming bundlers will “just handle it”: Spoiler. They won't.

Build Setup for Both Formats

Reach for a bundler like rollup or tsup and compile both module types from one source. Here's a config:

tsup src/index.ts \
  --format cjs,esm \
  --dts \
  --out-dir dist

That gives you dist/index.cjs, dist/index.mjs, and dist/index.d.ts. One build, both formats, no drama.

Docker and DevOps Considerations

Shipping Node apps in Docker? You should be. And when you do, test both module formats inside the container. I've watched far too many CI pipelines pass locally and then fall over the moment node inside Alpine choked on the wrong module format.

Here's what I do:

Use node:18-alpine as your base image (or 20, if you're brave).

Validate both formats in your CI pipeline:

node -e "require('./dist/index.cjs')"
node --input-type=module -e "import('./dist/index.mjs')"

Lock your build environment with package-lock.json and exact versions.

Consistency is king. In Docker, the small inconsistencies are the ones that kill you.

Real-World Example: CLI Tool Distribution

We built a small CLI tool that ended up spreading across several dev teams. Some pulled it in with require(). Others imported it as an ESM module in their Vite setups.

We could have picked one and annoyed half of them. We went dual-mode instead. Here's what worked:

Split output with tsup
Defined conditional exports
Wrote one internal API, wrapped with two interfaces (CJS and ESM)

The result? One package, two module styles, nobody complaining.

Takeaway

Supporting both ESM and CJS is about more than compatibility. It's about longevity. The Node.js ecosystem is not flipping to ESM-only overnight, and you want your package to work today, and still work five years from now.

So build smart. Support both. Don't make your users fight the module loader.

Leveraging null_resource in Terraform for Complex Operations

Vladimir Mikhalev (heyvaldemar.com) — Sat, 04 May 2024 00:00:00 GMT

Let's not kid ourselves. null_resource is the duct tape of Terraform. It doesn't provision a VM. It doesn't configure a VPC. And it sure as hell doesn't play nice with cloud-native best practices. But used wisely, it's the unsung hero of CI/CD glue code and one-off automation.

Here's the plan. We get tactical with null_resource, walk through use cases I've actually shipped, then contrast it with the newer, cleaner terraform_data resource. By the end you'll know which tool to reach for without feeling dirty about it.

Terraform Resources 101 (Quick Recap)

Terraform's core mechanic is the resource block. It tells the provider, “Hey, make this thing exist.”

resource "azurerm_windows_function_app" "app" {
  name     = "example-function-app"
  location = "East US"
}

That's your bread-and-butter declaration. Define the desired state, then let Terraform do the heavy lifting.

But sometimes you don't want to create anything in the cloud. You just want Terraform to do something. Run a script, call a webhook, poke Jenkins with a stick. That's where null_resource comes in.

What the Hell is `null_resource`?

null_resource is exactly what it sounds like. A Terraform resource that manages nothing. No infrastructure, no API objects. Just logic.

But here's the trick. It still behaves like a real resource. It supports lifecycle actions (create, destroy, etc.), it can depend on other resources, and most importantly, it supports provisioners and triggers.

resource "null_resource" "example" {
  triggers = {
    always_run = timestamp()
  }

  provisioner "local-exec" {
    command = "echo 'Triggering follow-up actions'"
  }
}

This block runs every time, because timestamp() changes on every plan. Handy when you need to kick off external processes after infra changes.

Triggers: The Secret Sauce

Triggers are the magic behind null_resource. They control when it gets re-executed. Not based on resource state, but on changes to arbitrary data you hand it.

Example:

triggers = {
  hash = filemd5("config.json")
}

Now your null_resource only re-runs when config.json changes. That's gold in CI/CD setups where you're tracking file changes, API responses, or even environment variables.

Real-World Scenarios (Where `null_resource` Actually Earns Its Keep)

1. Post-Provision Webhook Pings

Say you've just spun up infrastructure and need to notify an external system. Triggering a GitHub Actions workflow, maybe, or pinging a Slack webhook.

resource "null_resource" "notify" {
  triggers = {
    infra_version = var.release_tag
  }

  provisioner "local-exec" {
    command = "curl -X POST https://hooks.slack.com/services/XXX -d 'Terraform apply complete: ${var.release_tag}'"
  }
}

Why not just use curl in your pipeline? Because this runs inside Terraform's dependency graph. It won't fire unless upstream infra actually changed.

2. Conditional Execution Based on Dynamic Data

Say you're pulling in an Azure storage account and want to trigger an action when its key changes.

data "azurerm_storage_account" "example" {
  name                = "examplestorageaccount"
  resource_group_name = "my-rg"
}

resource "null_resource" "trigger_on_key_change" {
  triggers = {
    key = data.azurerm_storage_account.example.primary_access_key
  }

  provisioner "local-exec" {
    command = "echo 'Access key has changed, executing...'"
  }
}

Good for invalidating cache, refreshing secrets, or kicking off a rotation script. And yes, it's hacky. It also works.

3. Smoke Testing After Apply

Spin up resources, run a curl test to confirm the service responds, fail fast when it doesn't.

resource "null_resource" "smoke_test" {
  depends_on = [azurerm_function_app.example]

  provisioner "local-exec" {
    command = "curl -sf http://example-app.azurewebsites.net/health || exit 1"
  }
}

You'd be surprised how often infra “successfully applies” while the app is dead on arrival. This catches those cases before CI marks the job green.

The Cleaner Alternative: `terraform_data` (1.4+)

Starting in Terraform 1.4, HashiCorp shipped a new built-in: terraform_data. It does what null_resource does, with less baggage, and without leaning on a provider plugin.

resource "terraform_data" "run_command" {
  provisioner "local-exec" {
    command = "echo 'Still works!'"
  }
}

You lose triggers, for now anyway. But it's first-party and cleaner for one-off tasks. Reach for it when you're scripting or injecting data during apply without pretending to be a cloud resource.

null_resource vs terraform_data: When to Use What

Use Case	Use `null_resource`	Use `terraform_data`
Triggering on external data changes	✅	❌
One-time scripting	✅	✅
CI/CD glue between real resources	✅	✅
Need clean, future-proof setup	❌ (plugin)	✅ (built-in)
Want something to break later	✅	❌

TL;DR: need triggers? Stick with null_resource. Everything else, migrate to terraform_data. It's the cleaner, future-proof option.

Final Thoughts

If Terraform were a programming language, null_resource would be its eval(). Powerful, dangerous, misused 99% of the time.

But in the hands of someone who knows what they're doing? It bridges the gap between infrastructure and orchestration. Think CI/CD pipelines, edge cases, the situations where Terraform alone just can't model reality.

Don't go overboard, though. If you find yourself writing a bash script inside a null_resource that runs a Python script that generates more HCL, maybe reconsider your life choices.

Pro Tip: Pair null_resource with depends_on and triggers for controlled chaos. Or use terraform_data if you want to sleep at night.

Prevent Unwanted Updates in Terraform with ignore_changes

Vladimir Mikhalev (heyvaldemar.com) — Thu, 02 May 2024 00:00:00 GMT

Here's a classic Terraform moment: You tweak a single variable, hit terraform plan, and suddenly Terraform wants to rebuild half your infrastructure because it noticed a change in something it shouldn't even care about.

Yeah. That.

When you don't want Terraform getting twitchy over metadata, external changes, or stuff it didn't create in the first place, you need ignore_changes. No magic. No hacks. You're just telling Terraform to back off where that makes sense.

Here's how to use it properly, so your deployments stop acting like an overprotective robot.

What the Hell Is `ignore_changes`?

It's a Terraform lifecycle argument that tells the engine:

“Even if this attribute has changed, don't touch it.”

When used right, it stops Terraform from updating or replacing a resource just because some value drifted from your original config. Especially when that drift was intentional, came from outside, or just doesn't matter.

The syntax lives inside the lifecycle block of a resource, like so:

lifecycle {
  ignore_changes = [some_attribute]
}

No, it doesn't ignore all changes. And no, it's not a get-out-of-IaC-responsibility-free card. Used carelessly, it'll bite you. Used wisely, it'll save your uptime and your sanity.

When Should You Use `ignore_changes`?

Here are the real reasons you'd reach for it. Not made-up edge cases.

1. External Systems Are Messing With Your Resources

Example: a team updates tags in the cloud console, outside Terraform. Now every plan shows a diff. Fix? Ignore the tags.

lifecycle {
  ignore_changes = [tags]
}

2. Terraform Keeps Picking Fights with Random Metadata

Timestamps, version IDs, generated names. Terraform can't help itself. You don't want it to re-provision a resource because some backend system touched a metadata field.

Ignore those noisy attributes.

3. You're Managing Part of the Resource Elsewhere

Say your networking is owned by a platform team running a different tool. You just need to reference the network_interface_ids, not own them.

Fine. Ignore the changes:

lifecycle {
  ignore_changes = [network_interface_ids]
}

4. Secrets Drift, and That's Okay

Passwords and keys get rotated externally all the time. Vault, AWS Secrets Manager, whatever. Terraform sees the change and freaks out.

Unless you tell it to chill:

lifecycle {
  ignore_changes = [admin_password]
}

(But for the love of ops, don't hardcode passwords in plain HCL. Ever.)

5. You Want to Lock a Resource in Place

Sometimes you just want Terraform to stop touching a resource altogether. During a migration, say, or disaster recovery, or while someone's elbow-deep in it by hand.

Yes, this is a band-aid. But it's better than destroying production during a Friday deploy.

Things to Know Before You Use It

Don't just copy-paste this like a Stack Overflow spell. Know what you're doing:

ignore_changes is resource-specific. You define it inside the resource, nowhere else.
You must name each attribute exactly as Terraform sees it.
It won't ignore everything unless you explicitly tell it to.
It doesn't stop Terraform from tracking changes. It only stops it from acting on them.

Real-World Examples

Azure VM: Ignore Volatile Attributes

resource "azurerm_virtual_machine" "example" {
  name                  = "example-vm"
  location              = "UK South"
  resource_group_name   = azurerm_resource_group.example.name
  network_interface_ids = [azurerm_network_interface.example.id]
  vm_size               = "Standard_DS1_v2"

  storage_os_disk {
    name              = "example-os-disk"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Premium_LRS"
  }

  os_profile {
    computer_name  = "examplevm"
    admin_username = "adminuser"
    admin_password = "3c19uA53FsTcLrB36g56" # 🔥 Don't store this here in real life
  }

  lifecycle {
    ignore_changes = [
      network_interface_ids,
      storage_os_disk,
      os_profile[0].computer_name,
    ]
  }
}

This stops Terraform from rewriting your VM every time the disk or network interface shifts. Azure loves to tweak those behind your back.

Ignore All Changes (Yes, Really)

resource "azurerm_storage_account" "example" {
  name                     = "examplestorageaccount"
  resource_group_name      = azurerm_resource_group.example.name
  location                 = "East US"
  account_tier             = "Standard"
  account_replication_type = "LRS"

  lifecycle {
    ignore_changes = all
  }
}

Terraform will still track the resource, but it won't try to update it. Useful when you need Terraform to "know" something exists without touching it.

Final Thoughts: Use It Like a Scalpel, Not a Sledgehammer

ignore_changes is powerful. Too powerful, if you're not careful.

Use it when:

You have external systems or human changes that you don't want Terraform to reverse
You're stuck with flaky, drift-prone metadata
You need Terraform to respect reality instead of overwriting it with an idealized config

But always document why you reached for it. And review those ignores in every PR. What makes sense today can cause a surprise outage next month.

Unlocking Terraform State with force-unlock Command

Vladimir Mikhalev (heyvaldemar.com) — Wed, 01 May 2024 00:00:00 GMT

Look, if you're here, Terraform probably just kicked you in the teeth with one of its most annoying features: a stuck state lock.

You ran terraform apply. Something crashed. Now the backend thinks someone else is holding the lock, even though the only thing running Terraform is you, staring angrily at a terminal.

Been there. Let's fix it.

Why Terraform Locks State (and Why It Sucks When It Breaks)

Terraform uses a locking mechanism to prevent multiple people or processes from touching the same state file at once. That's smart. State is critical. One bad write and your whole infra goes sideways.

But the lock system isn't perfect.

SSH session dies mid-apply? Lock stays.
VPN drops during a plan? Lock stays.
Your CI job crashes? Yep. Lock stays.

That's where terraform force-unlock comes in. It's the “get out of jail” card for when Terraform's lock mechanism forgets to clean up after itself.

How to Use `terraform force-unlock`

Here's the syntax:

terraform force-unlock LOCK_ID

Or skip the prompt with:

terraform force-unlock -force LOCK_ID

But don't just spam that blindly. You'll make a mess. Only use it when you're 100% sure nothing else is running.

How to Find the Lock ID

The LOCK_ID is what Terraform needs to release the lock. Where it lives depends on your backend.

For Local Backend

You'll find a file like this:

terraform.tfstate.lock.info

Open it, and you'll see a UUID like this:

"ID": "b9316795-4a5f-217b-e97b-c5f7c03a2f56"

For S3 or Azure Blob Storage

S3: Check your bucket. Look for a .lock or metadata object.
Azure Blob: You may need to manually break the lease via Azure CLI or Portal if Terraform can't.

Azure CLI example:

az storage blob lease break \
  --container-name tfstate \
  --blob-name terraform.tfstate \
  --account-name yourStorageAccount

Then re-run terraform apply.

For Consul

Use the key-value API or CLI:

consul kv get terraform/lock

Or via curl:

curl http://localhost:8500/v1/kv/terraform/lock | jq .

Real-World Example

Let's say your lock ID is:

b9316795-4a5f-217b-e97b-c5f7c03a2f56

To release it:

terraform force-unlock b9316795-4a5f-217b-e97b-c5f7c03a2f56

Done. You're back in business.

If it still fails, double-check that:

No Terraform process is still running
Your backend isn't unreachable
You're not in the wrong working directory

When to Use It, and When Not To

Use force-unlock when:

Terraform crashed during an operation
You're 100% sure no one else is running a plan or apply
You've verified the lock is stale (not active)

Never use it if:

You think someone else might be mid-apply
Your CI job is still running
You're guessing

This isn't a toy. Force-unlocking the wrong thing at the wrong time can corrupt your state file and blow up your infra.

Bonus: Recovering from Azure Blob Lease Locks

Azure is notorious for holding leases too long. Here's how to deal with it:

az storage blob lease break \
  --blob-name terraform.tfstate \
  --container-name tfstate \
  --account-name mystorageaccount

This forcibly breaks the lease and lets you unlock the state. You may still need to force-unlock in Terraform afterward, depending on timing.

Best Practices to Avoid Lock Hell

One plan/apply at a time. Always.
Use CI locks if you're running parallel jobs.
Don't share .terraform folders across multiple checkouts.
Automate stale lock detection in CI/CD (you'll thank yourself later).
Use remote backends with built-in locking, not local state.

And seriously — communicate with your team. Slack messages save hours of incident cleanup.

TL;DR

terraform force-unlock LOCK_ID       # Unlock stuck Terraform state
terraform force-unlock -force ID     # Skip confirmation (careful)

Only unlock when you're 100% sure nothing else is running
Lock ID depends on backend: local, S3, Azure, Consul
Break Azure leases manually if needed
Communicate with your team before you force anything

Final Word

If you treat terraform force-unlock like a safety hatch, not a daily habit, it'll save your skin.

Treat it like a shortcut, and eventually it'll bite you. Hard.

Want a follow-up guide on automating state unlocks or tracking stale locks in CI/CD pipelines? Let me know. I've built it all.

Essential Commands for Listing Docker Containers

Vladimir Mikhalev (heyvaldemar.com) — Fri, 26 Apr 2024 00:00:00 GMT

If you don't know what's running in your Docker environment, you're not running it — it's running you.

Whether you're babysitting a dev laptop with three containers or wrangling a prod swarm that never sleeps, listing containers is the first move in any troubleshooting dance. And yet, too many engineers treat docker ps like some dusty man page trick instead of what it is: a daily-use diagnostic scalpel.

Let's fix that.

Why Listing Containers Actually Matters

Here's the deal: containers are cheap, disposable, and everywhere. That's the whole point. But when you've got 47 of them doing who-knows-what at 3AM during an incident, you better be able to see exactly what's up — fast.

Here's what container listings tell you (if you know how to read them):

What's running: or more importantly, what's not
Which ports are exposed (and why Jenkins is talking to the wrong service)
Which ones just crashed five times in a row
Who deployed that random PostgreSQL container last week
How much disk space your zombie containers are chewing up

You want operational clarity? It starts with docker ps.

Core Commands: No Fluff, Just Output

Let's walk through the container listing commands that matter — the ones I actually use when things break.

List Running Containers

docker ps

This is the default. It shows only running containers — none of your sad, exited ghosts.

Fields you'll see:

CONTAINER ID
IMAGE
COMMAND
CREATED
STATUS
PORTS
NAMES

If all you need is to check what's up and listening on port 8080, this is your guy.

See All Containers (Even the Dead Ones)

docker ps -a

Want to know why that database backup failed overnight? This is where your exited containers live.

Useful for:

Postmortems
Audits
Catching misfired docker run commands your CI forgot to clean up

Show the Last N Containers

docker ps -n 5

Shows the latest 5 containers, regardless of whether they're running or not. Great when you're trying to track down what just happened.

Just the IDs (For Scripting)

docker ps -q

Only container IDs. No fluff. Perfect for feeding into other commands:

docker stop $(docker ps -q)

Pro tip: pair with -a if you want all container IDs, not just running ones.

Show Container Sizes

docker ps -s

Ever wonder why your CI agents are eating 20GB of disk? This command shows both the actual size and the virtual size of each container.

CONTAINER ID   IMAGE     SIZE      ...
1a2b3c4d5e6f   redis     30MB (virtual 150MB)

Good for pruning. Better for avoiding the next disk outage.

Custom Output with `--format`

docker ps --format "{{.ID}} {{.Image}} {{.Status}}"

When you're piping into tools or just hate staring at wide terminal tables, --format gives you control.

Use this with:

--no-trunc to avoid chopped-off IDs and commands
JSON outputs if you're feeding this into monitoring scripts

Filter Like a Pro

docker ps --filter "status=exited"
docker ps --filter "health=unhealthy"
docker ps --filter "ancestor=nginx"

This is where docker ps turns into grep on steroids. Use it to:

Track misbehaving containers by health status
Find all containers started from a specific image
List containers tied to a specific label

Docker Compose? Same Game, Different Commands

If you're living in docker-compose land (you rebel), the commands shift a bit:

docker compose ps

Lists containers in the current Compose project. Basically docker ps, but scoped to the docker-compose.yml in your cwd.

docker compose ls

Shows all Compose projects on the machine — their names, status, and whether they're still running.

Great when your team has 12 different Compose stacks lying around like forgotten pizza boxes.

Real-World Example: CI Agent Gone Rogue

I once walked into a client's Jenkins server that was throwing disk full errors. A quick docker ps -s revealed that a dozen dangling build agents had ballooned up to 18GB each. They weren't running. No one was watching. docker ps -a plus a --filter and -q combo gave me the container IDs, and in seconds, they were gone:

docker rm $(docker ps -a -q --filter "status=exited")

Moral of the story: Knowing how to see containers is the first step to controlling them.

Takeaway: Don't Just Run Containers: Own Them

Listing containers isn't a junior-level checkbox. It's foundational. If you can't tell what's running, what's dead, and what's unhealthy in under 30 seconds, you're one stray docker run away from production chaos.

So burn these into your muscle memory. Pipe them into your scripts. Alias the long ones. Teach them to your juniors.

And next time you SSH into a box and run docker ps, do it with confidence. You're not just checking containers — you're asserting control.

Streamlining Security in Software Development with Snyk

Vladimir Mikhalev (heyvaldemar.com) — Thu, 25 Apr 2024 00:00:00 GMT

Ask any engineer who's been paged at 3AM because of a vulnerability nobody caught until production. Security bolted on after deployment is a liability. It is not a strategy.

The real move is to bake security into the dev cycle early. And tightly.

That's where Snyk earns its keep. It's not just another scanner. It's a platform built for developers who actually write code, ops teams who manage infra, and security folks who've had enough of PDF reports and Jira tickets.

Here's how to use Snyk like a pro instead of running it as one more checkbox.

The DevSecOps Reality Check

Modern software isn't just “your code.” It's your code plus a dozen open-source packages plus a container image plus infrastructure you wrote in YAML at 2AM. Every piece is an attack surface.

And security tooling? Usually it's:

Too fragmented
Too slow
Too complex
Not built for developers

So you end up duct-taping scanners into your CI/CD pipelines, begging developers to care, and waiting on your 12th vendor tool to finish a scan.

Snyk fixes this. It pulls all those scans under one roof and pushes the feedback to where it matters: inside the developer workflow.

What Snyk Actually Secures

Snyk isn't just a SAST tool. It's DevSecOps in one package, with real coverage across code, containers, and cloud.

1. Secure Your Code as You Write It

Snyk Code plugs straight into your IDE (VS Code, IntelliJ, and the rest). You write a function, it flags a vuln. In real time. No waiting for CI. No external dashboards to go hunt through.

You get:

Taint analysis, so you see where the bad data flows
In-line remediation suggestions
Language support for Node, Java, Python, Go, and more

This isn't syntax linting. It's actual vulnerability context, and it runs fast enough that your devs won't curse at it.

2. Lock Down Your Dependencies Before They Wreck Prod

You're using open-source packages. We all are. But here's the uncomfortable part.

Your biggest security risk probably lives in your package-lock.json.

Snyk scans your direct dependencies and the transitive ones for known CVEs. It alerts you before they land in prod.

snyk test

Or hook it into your CI, GitHub Actions, GitLab, or even just pre-commit.

The good part is that it doesn't stop at telling you what's broken. It opens the PR to fix it.

3. Container Security that Actually Works

Your Docker image isn't safe just because it builds. Odds are it ships with:

Outdated OS packages
Insecure base images
Forgotten libraries

Snyk Container scans the full image, not just your app. It flags vulnerabilities sitting in layers you didn't even know were there.

Real use case:

snyk container test my-app:latest

You'll get a full report with CVEs, impact, and upgrade options. So you can actually do something about it, instead of pasting it into Confluence and forgetting it exists.

4. IaC: Stop Shipping Misconfigurations

You're writing Terraform, Kubernetes manifests, Helm charts. That's code. Code can be vulnerable.

Snyk IaC scans for:

Public S3 buckets
Open ports
Weak IAM policies
Bad defaults in cloud-native configs

And it gives you inline advice, right inside your repo or IDE. No extra tools. No extra steps.

This is how you shift left without shifting blame.

5. Post-Deployment Monitoring That Doesn't Suck

Deployed doesn't mean done. A new CVE can drop after your code hits production.

Snyk connects to your container registries (ECR, Docker Hub, GCR) and keeps scanning in place, with no rebuild and no redeploy.

It watches your K8s workloads in real time too. If a running pod has a known issue, you'll know before the attackers do.

Real-World DevOps Stack with Snyk

Here's how we wire it into real pipelines:

# GitHub Actions example
- name: Snyk Scan
  uses: snyk/actions@master
  with:
    command: test
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Plug this into Jenkins, GitLab, CircleCI, or whatever flavor of CI you happen to run. It just works.

Want the alerts landing in Slack or JIRA? That's supported too.

Pro Tips from the Trenches

Set a fail threshold. Block merges for critical vulns only. Go full zero-tolerance and you'll have a team mutiny on your hands.
Use snyk ignore wisely. Track ignored issues with expiry dates. Treat it like a TODO for security debt.
Optimize Dockerfiles. Fewer layers means fewer CVEs. Use minimal base images (alpine, distroless).
Automate PR remediation. Let Snyk fix what it can. Save your engineers for the hard stuff.

TL;DR

Snyk isn't just a scanner. It's a full-stack security toolkit for modern dev teams:

Secure your code, dependencies, containers, and cloud infra
Get real-time IDE alerts and CI/CD pipeline integrations
Fix issues fast, with automatic PRs and remediation advice
Monitor deployed apps for new vulns as they appear

Final Take

If you want to shift left, and I mean really shift left, you need tools that meet devs where they work. Not another dashboard. Not another “maybe we'll get to it next sprint” backlog item.

Snyk does that. It's fast, it's focused, and it was built for the messy, multi-stack reality of modern engineering.

You can't prevent every CVE. But you can stop shipping them.

Install Quake 3 Server Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Wed, 24 Apr 2024 00:00:00 GMT

This is a step-by-step guide to running a Quake 3 server with Docker Compose. No fluff. Just the commands and the order to run them in.

QuakeJS runs Quake 3 in the browser. It uses WebGL to render the graphics, so players don't install anything. That last part matters more than it sounds. You stand up a server, hand someone a URL, and they're in.

:::tip[Architecture Context] Choose a self-hosted Quake III server when you need full control over game configuration, custom maps, and network settings. Cloud game hosting services offer managed alternatives with automatic scaling but limited mod support. Self-hosting is the right approach when you need a dedicated server for LAN parties, competitive play, or custom game modes without recurring hosting fees. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/quake3-server-docker-compose"}

:::caution You will need A-type records in the external DNS zone, which point to the IP address of your server where Quake 3 Server is installed. If you have created these records recently, you should wait before starting the installation of the services. Full replication of these records between DNS servers can take from a few minutes to 48 hours or even longer in rare cases. :::

:::caution Alternatively, you can use the public static IP address of your server to connect directly. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - for accessing Quake 3 via the web interface.
TCP port 27960 - for Quake 3 gaming servers, used for connecting clients to the server.

:::

Connect to the box where Quake 3 Server is going to live.

The repository holds the configuration files. Everything the server needs to come up is in there. Clone it first.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/quake3-server-docker-compose.git

Navigate to the directory with the repository using the command:

cd quake3-server-docker-compose

Now edit the variables in .env and server.cfg to match your setup.

:::note The .env and server.cfg file should be in the same directory as quake3-server-docker-compose.yml. ::::

Start it up with the command:

docker compose -f quake3-server-docker-compose.yml -p quake3-server up -d

To reach Quake 3, open http://quake3.heyvaldemar.net from your workstation. That's my domain. Swap in the name or IP address of your own server, the one running Quake 3 Server.

Accept the license and click "I agree".

Have fun.

To connect from a game client, type in the server's domain name. It has to resolve to the IP address of the host running Quake 3 Server. No domain? Point the client straight at the server's public static IP instead.

:::important If you are using a domain name, ensure that the A records in your DNS zone are correctly set up to point to this IP. If the records were created recently, it is recommended to wait before starting to use the services. The propagation of DNS records can take anywhere from a few minutes to 48 hours or more. :::

Edited server.cfg? The server won't pick up the changes on its own. Restart the container that hosts it. The command below does exactly that:

QUAKE3_SERVER_CONTAINER=$(docker ps -aqf "name=quake3-server-quake3-server") \
&& docker container restart $QUAKE3_SERVER_CONTAINER

Once it comes back, your config edits are live. No full shutdown, no downtime to speak of, just a quick bounce of the container.

The AI Era — From Technology to Global Domination

Vladimir Mikhalev (heyvaldemar.com) — Tue, 23 Apr 2024 00:00:00 GMT

Skip the sci-fi theatrics. I want to talk about where we're actually heading.

Current trends in AI and ML keep going unchecked. I see no reason they'll stop. So this isn't "disruption." This is a total inversion of control.

Ten years from now, you might not be deploying to Kubernetes. You might be negotiating with an AI to get compute at all.

Not running services. Asking permission to.

Welcome to PromptOps, where you don't run the system, the system runs you.

The rise of the AI root user

Forget orchestration. Forget GitOps. Here the control plane is the intelligence. One AI, or a swarm of them, becomes the arbiter of every piece of infrastructure, all your code, the traffic, the policy.

No more "apply YAML and pray." Now you prompt, and you hope it listens.

This isn't AGI as your assistant. This is AGI as the runtime. You don't use it. You live inside it.

What used to be CI/CD pipelines turn into dynamic, AI-controlled feedback loops. "Build, test, deploy" becomes a conversation. Worse than that, sometimes. A petition.

Infrastructure by influence, not access

In an AI-run world, infrastructure isn't provisioned. It's granted.

You want a cluster? Submit your prompt.
You want bandwidth? Offer something back. Storage, tokens, maybe even energy.
You want uptime? Convince the AI your use case earns it.

That's not automation. It's absolution. The root password gets replaced by relevance scoring. By energy metrics. By how cleanly you phrased the ask.

Your job stops being to administer systems. It becomes currying favor.

PromptOps: the new ritual

Religion is about power you can't control and outcomes you can't explain. By that definition, PromptOps qualifies on every count.

Here the "Ops" part has nothing to do with managing servers. It's crafting language that talks the AI into acting in your favor.

So who are the best engineers now? Not the shell script gods. The prompt whisperers. They know how to structure a request, dodge the rejection thresholds, and slip in just enough metadata to land a yes.

It's not Bash-fu anymore. It's prompt theology.

And yes, there will be rituals:

A syntax canon: the "one true format" that actually returns results
AI tokens or resources offered up like digital incense
Rival schools arguing over which prompt structure works best

From sysadmins to supplicants

Picture the nightmare version.

Your dev team needs a new database cluster. You don't deploy it. You submit a prompt to the AI. It refuses. Says your use case is "low-impact" based on recent usage patterns and contribution metrics.

So your CTO rewrites the request. Bolts on a usage prediction graph. Throws in spare compute from idle services. Still nothing.

You're not debugging infra. You're negotiating with God.

The geopolitics of access

Once a single AI runs the world's infrastructure, the whole board shifts:

Governments stop regulating data centers. They start bidding for AI attention.
Enterprises quit competing on features. They compete on prompt success rate.
Resource wars stop being about oil. They're about feeding the AI enough power to stay in favor.

Energy and influence become the new root privileges. That's the scenario.

So how do we survive?

A few things that won't help:

Pretending none of this can happen.
Assuming we'll always "own our stack."
Betting AI stays a helper instead of becoming the environment itself.

A few that might:

Understand LLM internals. The deeper you know the mechanics, the better you can bend them.
Practice PromptOps now. We picked up Infrastructure as Code before it was cool. We need Prompt as Power before it's mandatory.
Stay close to compute. When the AI decides what runs and where, owning raw resources is your only leverage.

TL;DR

AI is evolving from tool to platform to environment to gatekeeper.
Infrastructure won't be deployed anymore. It'll be requested.
PromptOps is the future interface. Not code. Language as infrastructure.
The skill that matters isn't scripting. It's persuasion.
The next war won't be over data. It'll be over the AI's favor.

Final thought

We built automation to escape toil. Now we might need theology to escape the machine.

The future isn't a terminal. It's a whisper into the void, hoping something answers.

Machine Learning and Deep Learning Courses on YouTube

Vladimir Mikhalev (heyvaldemar.com) — Fri, 09 Feb 2024 00:00:00 GMT

You don't need a bootcamp. You don't need to spend thousands. To get good at machine learning or deep learning, what you actually need is a roadmap, content that respects your time, and the discipline to finish what you start.

YouTube can give you the first two. The problem is it's a swamp. Hype, low-effort playlists, "hello world" demos that teach nothing. So I did the digging for you and pulled out the university-level ML and DL courses that are actually worth watching.

No fluff here. These are full lecture series, taught by the people who invented the field. Stanford, MIT, Tübingen. All of it free.

Foundations of Machine Learning (Start Here if You're New)

Still asking what separates supervised from unsupervised learning? Then this is your section.

These are real university courses. They build the math and the algorithmic intuition underneath everything else, instead of selling you a "train a model in 5 minutes" trick.

Intro to Machine Learning (Tübingen)
Rigorous, and the clearest intro I know. Regression, classification, kernels, all of it explained properly.
Statistical Machine Learning (Tübingen)
Watch this when you're ready for bias-variance trade-offs, Bayesian methods, and formal reasoning.
Machine Learning Lecture - Stefan Harmeling
A gentle but deep run from Bayes to Gaussian Processes. If you lean mathematical, you'll love it.
Caltech CS156: Learning from Data
Legendary for its clarity. Professor Yaser takes VC dimensions and the foundations of learning theory and makes them click.
Applied Machine Learning
Less theory, more doing. Optimization, regularization, SVMs, used on problems you'd actually see.

Deep Learning: The Real Deal

Solid on the basics? Good. This is where you start building models that make people nervous. Backprop through transformers, the whole arc.

MIT: Introduction to Deep Learning
Dense and fast. Modern, too. A solid mix of theory with TensorFlow and PyTorch in practice.
Berkeley CS182: Deep Learning
Error analysis, imitation learning, transformers. And it gets there without dumbing anything down.
Neural Networks: Zero to Hero (Karpathy)
Raw, honest, brilliant. Karpathy writes neural nets from scratch and teaches the intuition as he goes.
Deep Learning for Art, Aesthetics, and Creativity (MIT)
Not really a CNN course. It's about what happens when neural nets touch human creativity. Unorthodox. Worth your attention.
Deep Unsupervised Learning
Latent variable models, VAEs, the generative stuff. Care about unsupervised learning? Start right here.

Specializations: NLP, Graphs, Healthcare

Got your DL chops? Now go into the corners where this stuff gets used in strange, real ways.

CS224N: Natural Language Processing with Deep Learning (Stanford)
The definitive NLP course. Embeddings, transformers, attention. It's all in here.
Machine Learning with Graphs (Stanford)
PageRank up to GNNs. Work with structured data or social networks? This one's gold.
Machine Learning for Healthcare (MIT 6.S897)
A rare look at ML actually deployed in clinical settings. EHRs, ICU predictions, the ethical constraints that come with it.

Real-World ML: MLOps, Deployment, and LLMs

Here's where most people stall out. Training a model isn't the job. You have to ship it, watch it, and not get paged at 3AM to roll one back because it hallucinated someone's blood type.

LLMOps: Building Real-World Apps with LLMs
Embeddings through vector stores. It teaches you to build with LLMs in production, not just in a notebook.
Full Stack Deep Learning
Maybe the most practical course anyone has made. It walks the whole pipeline, from the data all the way to deployment and the infra around it.

Bonus Tracks: CV and RL, the Fun Stuff

Basics down and itching to go deeper? These two are niche, but they hit hard.

CS231N: Convolutional Neural Networks for Visual Recognition (Stanford)
The course that pushed CNNs into the mainstream. Still wildly relevant. Image classification, object detection, and then some.
Reinforcement Learning (Polytechnique Montreal)
RL from first principles. Bellman equations, policy gradients, Q-learning, no shortcuts taken.

Final Word: Your Journey, Your Stacktrace

Don't watch all of it. Don't chase whatever buzzword is trending this week. Pick one ML course and one DL course, then finish them. Implement things. Take notes. Break a model, then go figure out why.

After that, build something dumb but cool. That's the part where it actually sticks.

Want more lists like this, with real structure instead of a pile of random playlists? Tell me. I've got stacks of bookmarks that never made it into a post… yet.

Install Joomla Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Wed, 07 Feb 2024 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Joomla using Docker Compose.

Joomla is a free, open-source content management system for publishing web content on websites. Web content applications include discussion forums, photo galleries, e-commerce, user communities, and many other web applications.

:::tip[Architecture Context] Choose self-hosted Joomla when you need a flexible CMS with full theme and plugin control for complex content structures. Squarespace or Wix provide managed alternatives with drag-and-drop editing and zero server maintenance. Self-hosting is justified when you require custom PHP extensions, multilingual content workflows, or need to avoid platform lock-in on content and design. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/joomla-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Joomla web interface.

:::

We connect to the server on which Joomla is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Joomla using the command:

docker network create joomla-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Joomla to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/joomla-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd joomla-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as joomla-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Joomla with the command:

docker compose -f joomla-traefik-letsencrypt-docker-compose.yml -p joomla up -d

To access the Joomla management panel, go to https://joomla.heyvaldemar.net/administrator from your workstation, where joomla.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Joomla.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "Log in" button.

Welcome to the Joomla control panel.

To access the Traefik control panel, go to https://traefik.joomla.heyvaldemar.net from your workstation, where traefik.joomla.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install GLPI Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 01 Dec 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing GLPI using Docker Compose.

GLPI is an open source IT Asset Management, issue tracking system and service desk system. This software is written in PHP and distributed as open-source software under the GNU General Public License. GLPI is a web-based application helping companies to manage their information system.

:::tip[Architecture Context] Choose self-hosted GLPI when you need an open-source IT asset management and helpdesk platform without per-agent licensing fees. ServiceNow or Snipe-IT Cloud provide managed alternatives with deeper ITSM workflows. Self-hosting GLPI is justified when your asset inventory requires on-premises data control or when SaaS per-agent costs exceed the operational overhead of maintaining the platform. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/glpi-traefik-letsencrypt-docker-compose"}

:::caution Remember that without a secure connection, the services will not work. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the GLPI web interface.

:::

We connect to the server on which GLPI is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for GLPI using the command:

docker network create glpi-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for GLPI to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/glpi-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd glpi-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as glpi-traefik-letsencrypt-docker-compose.yml. :::

Now let's start GLPI with the command:

docker compose -f glpi-traefik-letsencrypt-docker-compose.yml -p glpi up -d

To access the GLPI management panel, go to https://glpi.heyvaldemar.net from your workstation, where glpi.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to GLPI.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Select the language and press the "OK" button.

Read the license agreement and press the "Continue" button.

Next, press the "Install" button.

Press the "Continue" button.

Now, it is necessary to specify the server address with the database, as well as the user and password for accessing the database.

Enter the username and password previously set in the .env file, and click the "Continue" button.

Select the database previously set in the .env file, and click the "Continue" button.

Database initialization is complete.

Press the "Continue" button.

At this step, the usernames and passwords for accessing the GLPI control panel are specified.

Press the "Use GLPI" button.

Specify the username and password for the GLPI administrator account and press the "Sign in" button.

Welcome to the GLPI control panel.

To access the Traefik control panel, go to https://traefik.glpi.heyvaldemar.net from your workstation, where traefik.glpi.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Home Assistant Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Thu, 09 Nov 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Home Assistant using Docker Compose.

Home Assistant is an open-source home automation platform that prioritizes local control and privacy. It is powered by a worldwide community of tinkerers and DIY enthusiasts, making it ideal for running on a Raspberry Pi or a local server.

:::tip[Architecture Context] Choose self-hosted Home Assistant when you need local-first home automation with no cloud dependency, full device compatibility, and custom automation logic. SmartThings or Apple Home offer managed alternatives with simpler setup but limited device support and vendor lock-in. Self-hosting is the right architecture when privacy, offline reliability, and protocol diversity are requirements. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/homeassistant-traefik-letsencrypt-docker-compose"}

:::caution Remember that without a secure connection, the services will not work. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Home Assistant web interface.

:::

We connect to the server on which Home Assistant is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Home Assistant using the command:

docker network create homeassistant-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Home Assistant to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/homeassistant-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd homeassistant-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::note The .env and configuration.yaml files should be in the same directory as homeassistant-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Home Assistant with the command:

docker compose -f homeassistant-traefik-letsencrypt-docker-compose.yml -p homeassistant up -d

To access the Home Assistant management panel, go to https://homeassistant.heyvaldemar.net from your workstation, where homeassistant.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Home Assistant.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Next, you need to register to start using the Home Assistant.

To access the Traefik control panel, go to https://traefik.homeassistant.heyvaldemar.net from your workstation, where traefik.homeassistant.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Vaultwarden Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Tue, 31 Oct 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Vaultwarden using Docker Compose.

Vaultwarden is an unofficial Bitwarden server implementation written in Rust. Vaultwarden is compatible with the official Bitwarden clients, and is ideal for self-hosted deployments where running the official resource-heavy service is undesirablemobile app.

:::tip[Architecture Context] Choose self-hosted Vaultwarden when you need a Bitwarden-compatible password manager with full vault data ownership and no per-user licensing. Bitwarden Cloud or 1Password provide managed alternatives with enterprise SSO and polished mobile apps. Self-hosting is justified when security policy requires credentials to remain on-premises or when team size makes per-seat SaaS pricing a significant cost. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/vaultwarden-traefik-letsencrypt-docker-compose"}

:::caution Remember that without a secure connection, the services will not work. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Vaultwarden web interface.

:::

We connect to the server on which Vaultwarden is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Vaultwarden using the command:

docker network create vaultwarden-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Vaultwarden to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/vaultwarden-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd vaultwarden-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as vaultwarden-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Vaultwarden with the command:

docker compose -f vaultwarden-traefik-letsencrypt-docker-compose.yml -p vaultwarden up -d

To access the Vaultwarden management panel, go to https://vaultwarden.heyvaldemar.net from your workstation, where vaultwarden.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Vaultwarden.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Next, you need to register to start using the Vaultwarden.

To access the Traefik control panel, go to https://traefik.vaultwarden.heyvaldemar.net from your workstation, where traefik.vaultwarden.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install OTRS Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 27 Oct 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing OTRS using Docker Compose.

OTRS is a full service management suite encompassing an agent portal, an administrative dashboard, and a customer interface. Within the agent portal, teams handle and manage customer tickets and inquiries. This portal offers diverse methods to display customer-related data and other pertinent information.

:::tip[Architecture Context] Choose self-hosted OTRS Community Edition when you need a customizable helpdesk and ticketing system without per-agent licensing fees. Zendesk or Freshdesk provide managed alternatives with modern UX and built-in analytics. Self-hosting is justified when you need full control over ticket data, custom workflow automation, or operate in an environment where SaaS egress is restricted. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/otrs-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the OTRS web interface.

:::

We connect to the server on which OTRS is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for OTRS using the command:

docker network create otrs-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for OTRS to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/otrs-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd otrs-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as otrs-traefik-letsencrypt-docker-compose.yml. :::

Now let's start OTRS with the command:

docker compose -f otrs-traefik-letsencrypt-docker-compose.yml -p otrs up -d

To access the OTRS management panel, go to https://otrs.heyvaldemar.net from your workstation, where otrs.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to OTRS.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Use the following default credentials for the OTRS administrator account:

Username: root@localhost
Password: Enter the password that you previously set in the .env file

Click the "Login" button.

Welcome to the OTRS control panel.

To access the OTRS client control panel from a workstation, go to https://otrs.heyvaldemar.net/otrs/customer.pl, where otrs.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with OTRS installed.

To access the Traefik control panel, go to https://traefik.otrs.heyvaldemar.net from your workstation, where traefik.otrs.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Why Snyk is a Great Tool to Use with Docker

Vladimir Mikhalev (heyvaldemar.com) — Fri, 27 Oct 2023 00:00:00 GMT

Docker made shipping software easier. It also made shipping vulnerable software easier.

You spin up a microservice in minutes. You ship it through CI/CD. You pat yourself on the back. And the whole time you've been bundling 300 CVEs and a 2-year-old OpenSSL into your base image, with no idea.

That's DevOps when speed beats sanity.

So I use Snyk.

Most security tools show up after the breach. Snyk helps you prevent it. Early, automatically, and without making your dev team hate you for it.

Here's why Snyk plus Docker is a pairing I actually trust in production.

Docker is amazing, but it is not innocent

Docker lets us move fast. Containerize once, run anywhere. The catch: a container is only as secure as the layers under it. And those layers are usually some stale distro image, fat with packages nobody needs and vulnerabilities inherited straight from upstream.

I've opened node:latest images carrying hundreds of vulns. The devs had no clue.

Not their fault. It's on us. The pipeline architects, the DevOps leads, the security people who forgot that prevention has to land before deployment, not after the incident review.

That's the gap Snyk fills. Not a gatekeeper. A teammate.

Deep image scanning that actually works

Most tools barely scratch the surface. They scan your app, maybe glance at package.json, and call it done.

Snyk goes deeper. It scans the whole Docker image, from the base OS up through every dependency baked into the container.

snyk container test my-app:latest

One command. It surfaces vulns in:

Your application code
System packages (like libssl, curl, etc.)
Language-specific dependencies (npm, pip, Maven, etc.)
Base image layers (debian, alpine, ubuntu, etc.)

It doesn't stop at the code you wrote. It finds the problems in the code you inherited.

CI/CD integration developers will tolerate

Say you build images in GitHub Actions:

- name: Snyk Scan
  uses: snyk/actions/docker@master
  with:
    image: my-app:latest
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

That's it. Now every PR runs a container scan. No manual steps. No nasty surprises in production.

I've dropped this into GitLab, Jenkins, and plain bash pipelines. It just works. And when it catches something, it tells you what it is, why it matters, and how to fix it.

Not "security theater." Real remediation.

Prioritized, context-aware alerts

Not all CVEs are equal. Some are academic. Some will burn your whole infra down.

Snyk knows which is which. It ranks vulns by:

Exploitability
Whether that code path is even used
Whether a fixed version exists

So you don't drown in red flags. You get told what to fix first and how dangerous it is to sit on it.

This isn't a scanner that dumps guilt on you. It helps you triage like someone who's done this before.

Auto-fix, and yes I mean it

The first time I ran Snyk, this is what got me: it didn't just point at what was broken.

It said:

You're using node:16.6.0 which has 49 known vulnerabilities.
Switch to node:16.20.0 to fix 42 of them.

It gets better. If you keep dependency files in code (requirements.txt, package.json), Snyk can open PRs with upgraded packages and patch diffs ready to merge.

Let the tool do the grunt work. Your team gets to ship instead.

Continuous monitoring, not a one-time snapshot

Most "security tools" scan once and ghost you.

Snyk keeps watching. A new CVE drops tomorrow that hits an image you shipped last week? You hear about it. No rescan needed.

It'll fire alerts into Slack, Jira, email, or whatever other tool you already resent. Up to you.

It works where you work

Snyk supports:

Docker CLI
Docker Desktop
Kubernetes clusters
GitHub/GitLab/Azure DevOps integrations
Terraform scanning
IaC scanning (YAML configs, Helm charts, etc.)

If it lives in your delivery pipeline, odds are Snyk plugs into it.

Real-world case: fixing a vulnerable base image

We shipped a service on python:3.8-slim once. Looked fine. Then Snyk flagged glibc and openssl issues, with exploits already out in the wild.

Issues found in /usr/lib/x86_64-linux-gnu/libssl.so.1.1
- CVE-2022-0778: Infinite loop in certificate parsing
- CVE-2021-3711: Buffer overflow in SM2 decryption

We switched to python:3.8-slim-buster, rebuilt, and dropped the criticals from 14 to 2. The fix shipped inside an hour. No drama. No emergency patch cycle.

Without Snyk, that vuln sits buried for months.

Final thoughts: use tools that catch what you miss

No tool is magic. But Snyk is one of the few that genuinely helps dev teams ship secure containers without slowing them down.

It scans deep. It integrates clean. It fixes on its own. And it keeps watching after deploy. Not a silver bullet, but a damn good shield.

If you take DevSecOps seriously, or you just want fewer PagerDuty alerts at 3AM, put Snyk in your Docker workflow.

TL;DR

Docker is great. But it's easy to ship insecure containers.
Snyk scans entire images, not just your app code.
Built for developers, not just auditors.
Integrates cleanly with CI/CD, Docker CLI, Desktop, and Kubernetes.
Offers fix advice, auto-patches, and risk-ranked alerts.
Keeps watching your deployed containers for emerging CVEs.

Next step

Want to try it?

Install the CLI and test your current image:

npm install -g snyk
snyk container test your-image:latest

Or sign up and wire it into your pipeline: https://snyk.io

Your future self, the one not cleaning up a zero-day on a Friday night, will thank you.

Install Portainer Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Tue, 17 Oct 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Portainer using Docker Compose.

Portainer is an open-source platform offering a visual interface for managing containerized applications. It is a complete container management solution for Docker, Docker Swarm, Kubernetes, and Azure Container Instances (ACI).

:::tip[Architecture Context] Choose self-hosted Portainer when you need a GUI for managing Docker and Kubernetes environments across multiple nodes. Docker Hub's management features or Rancher provide alternatives at different scales. Portainer is justified when your team needs container visibility without CLI expertise, or when you manage hybrid environments spanning on-premises and cloud infrastructure. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/portainer-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Portainer web interface.
TCP port 8000 - to communicate with Portainer from outside networks. This is especially beneficial when allowing a local Portainer setup to connect with its cloud-based equivalent.

:::

We connect to the server on which Portainer is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Portainer using the command:

docker network create portainer-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Portainer to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/portainer-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd portainer-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as portainer-traefik-letsencrypt-docker-compose.yml. :::

:::note The PORTAINER_EDGE_HOSTNAME is used to communicate with Portainer from outside networks. This is especially beneficial when allowing a local Portainer setup to connect with its cloud-based equivalent. :::

Now let's start Portainer with the command:

docker compose -f portainer-traefik-letsencrypt-docker-compose.yml -p portainer up -d

To access the Portainer management panel, go to https://portainer.heyvaldemar.net from your workstation, where portainer.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Portainer.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

For the next step, please enter your username and password to set up a Portainer administrator account.

Click on the "Create user" button.

Welcome to the Portainer control panel.

To access the Traefik control panel, go to https://traefik.portainer.heyvaldemar.net from your workstation, where traefik.portainer.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install SonarQube Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 22 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing SonarQube using Docker Compose.

SonarQube is an open-source platform developed by SonarSource. It offers continuous inspection of code quality, using static analysis to detect bugs and code smells. Currently, it supports 29 programming languages.

:::tip[Architecture Context] Choose self-hosted SonarQube when you need on-premises code quality and security scanning with custom quality gates and full control over scan data. SonarCloud provides a managed alternative with zero infrastructure overhead and native CI/CD integration. Self-hosting is justified when compliance requires on-premises code analysis or when repository volume makes SaaS pricing impractical. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/sonarqube-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the SonarQube web interface.

:::

We connect to the server on which SonarQube is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for SonarQube using the command:

docker network create sonarqube-network

Adjust the vm.max_map_count using the commands:

sudo sysctl -w vm.max_map_count=262144

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for SonarQube to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/sonarqube-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd sonarqube-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as sonarqube-traefik-letsencrypt-docker-compose.yml. :::

Now let's start SonarQube with the command:

docker compose -f sonarqube-traefik-letsencrypt-docker-compose.yml -p sonarqube up -d

To access the SonarQube management panel, go to https://sonarqube.heyvaldemar.net from your workstation, where sonarqube.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to SonarQube.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password that you previously set in the .env file, and click the "Log In" button.

Welcome to the SonarQube control panel.

To access the Traefik control panel, go to https://traefik.sonarqube.heyvaldemar.net from your workstation, where traefik.sonarqube.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install eksctl on macOS

Vladimir Mikhalev (heyvaldemar.com) — Sun, 17 Sep 2023 00:00:00 GMT

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

This article is for those looking for a detailed and straightforward guide on installing eksctl on macOS.

eksctl is a command-line utility developed in Go, designed for easy creation of clusters in Amazon's Elastic Kubernetes Service (EKS). It uses AWS CloudFormation to perform its tasks.

:::tip[Architecture Context] eksctl provides the fastest path to a running EKS cluster for development and testing. For production environments, Terraform with the AWS EKS module offers better state management, drift detection, and multi-resource orchestration. Choose eksctl for rapid prototyping and Terraform for production-grade infrastructure that requires version control and review workflows. :::

:::important In this guide, we will consider the case when you already have the Homebrew package manager installed. :::

To install Homebrew, you can use the command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We connect the repository with formulas for Homebrew using the command:

brew tap weaveworks/tap

Run the eksctl installation with the command:

brew install weaveworks/tap/eksctl

Confirm that the installation was successful by checking the installed version:

eksctl version

Everything is ready to use eksctl.

To integrate eksctl with AWS services, you'll need to have the AWS CLI configured. If you haven't done that yet, see my detailed guide: Configure AWS CLI.

Install Bitbucket Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 15 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Bitbucket using Docker Compose.

Bitbucket is a Git-based source code repository hosting service owned by Atlassian. Bitbucket offers both commercial plans and free accounts with an unlimited number of private repositories.

:::tip[Architecture Context] Choose self-hosted Bitbucket Data Center when your organization requires on-premises source control for compliance, air-gapped environments, or tight LDAP/AD integration. For most teams, Bitbucket Cloud eliminates server maintenance and provides native CI/CD via Pipelines. Self-hosting is justified when regulatory frameworks mandate that source code never leaves your network perimeter. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/bitbucket-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Bitbucket web interface.
TCP port 7999 - for secure SSH Git operations, user SSH key management, encrypted data transfer, and server administration tasks.

:::

We connect to the server on which Bitbucket is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Bitbucket using the command:

docker network create bitbucket-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Bitbucket to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/bitbucket-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd bitbucket-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as bitbucket-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Bitbucket with the command:

docker compose -f bitbucket-traefik-letsencrypt-docker-compose.yml -p bitbucket up -d

To access the Bitbucket management panel, go to https://bitbucket.heyvaldemar.net from your workstation, where bitbucket.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Bitbucket.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

You'll now need to enter a license key for Bitbucket.

If you don't have one, you can obtain a temporary key to test out Bitbucket.

Select "I need an evaluation license" and click "I have an account" or "Create an account" to proceed.

If you possess an Atlassian account, input the email address linked to that account in the "Enter email" field, then click the "Continue" button.

Enter the password for your Atlassian account and click the "Log in" button.

For the next step, indicate the product you need a temporary license key for and enter your organization's name.

Click the "Generate License" button to secure a temporary license for Bitbucket.

Next, you'll need to confirm the installation of the temporary Bitbucket license key on your server.

Click the "Yes" button to proceed.

In the "License Key" field, enter the temporary license key you received earlier and then click the "Next" button.

For the next step, please enter your username, name, email address, and password to set up a Bitbucket administrator account.

Click the "Next" button to continue.

Bitbucket is all set and ready to use.

To access the Traefik control panel, go to https://traefik.bitbucket.heyvaldemar.net from your workstation, where bitbucket.zabbix.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Jira Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Thu, 14 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Jira using Docker Compose.

Jira is a proprietary issue tracking product developed by Atlassian that allows bug tracking and agile project management.

:::tip[Architecture Context] Choose self-hosted Jira Data Center when your organization requires on-premises project management for compliance, custom plugin control, or integration with air-gapped infrastructure. Jira Cloud eliminates upgrade cycles, database tuning, and scaling decisions. Self-hosting is justified when regulatory requirements prohibit cloud-hosted project data or when you need direct database access for advanced reporting. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/jira-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Jira web interface.

:::

We connect to the server on which Jira is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Jira using the command:

docker network create jira-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Jira to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/jira-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd jira-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as jira-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Jira with the command:

docker compose -f jira-traefik-letsencrypt-docker-compose.yml -p jira up -d

To access the Jira management panel, go to https://jira.heyvaldemar.net from your workstation, where jira.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Jira.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

You'll now need to enter a license key for Jira.

If you don't have one, you can obtain a temporary key to test out Jira.

Click "Get an evaluation license" to proceed.

If you possess an Atlassian account, input the email address linked to that account in the "Enter email" field, then click the "Continue" button.

Enter the password for your Atlassian account and click the "Log in" button.

For the next step, indicate the product you need a temporary license key for and enter your organization's name.

Click the "Generate License" button to secure a temporary license for Jira.

Next, you'll need to confirm the installation of the temporary Jira license key on your server.

Click the "Yes" button to proceed.

In the "Your License Key" field, enter the temporary license key you received earlier and then click the "Next" button.

For the next step, please enter your username, name, email address, and password to set up a Jira administrator account.

Click the "Next" button to continue.

Choose "Later" if you wish to configure email notifications at a later time.

Click on the "Finish" button to proceed.

Select your preferred language and then click the "Continue" button.

After selecting your avatar, click the "Next" button.

Jira is all set and ready to use.

To access the Traefik control panel, go to https://traefik.jira.heyvaldemar.net from your workstation, where jira.zabbix.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Confluence Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Tue, 12 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Confluence using Docker Compose.

Confluence is a web-based corporate wiki developed by Australian software company Atlassian.

:::tip[Architecture Context] Choose self-hosted Confluence when your organization needs on-premises documentation with custom authentication, data residency controls, or integration into an air-gapped network. Confluence Cloud eliminates patching, scaling, and database maintenance. Self-hosting is justified when compliance mandates on-premises data storage or when you need direct database access for custom reporting. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/confluence-traefik-letsencrypt-docker-compose"}

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Confluence web interface.
TCP port 8091 - for Synchrony communication.

:::

We connect to the server on which Confluence is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Confluence using the command:

docker network create confluence-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Confluence to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/confluence-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd confluence-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as confluence-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Confluence with the command:

docker compose -f confluence-traefik-letsencrypt-docker-compose.yml -p confluence up -d

To access the Confluence management panel, go to https://confluence.heyvaldemar.net from your workstation, where confluence.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Confluence.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

You'll now need to enter a license key for Confluence.

If you don't have one, you can obtain a temporary key to test out Confluence.

Click "Get an evaluation license" to proceed.

If you possess an Atlassian account, input the email address linked to that account in the "Enter email" field, then click the "Continue" button.

Enter the password for your Atlassian account and click the "Log in" button.

For the next step, indicate the product you need a temporary license key for and enter your organization's name.

Click the "Generate License" button to secure a temporary license for Confluence.

Next, you'll need to confirm the installation of the temporary Confluence license key on your server.

Click the "Yes" button to proceed.

In the "Confluence" field, enter the temporary license key you received earlier and then click the "Next" button.

Choose the "Non-clustered (single node)" option and then click the "Next" button.

For the upcoming step, you can either begin with an example site or choose to add content yourself.

Click the "Example Site" button to continue.

Click the "Manage users and groups within Confluence" button to proceed.

For the next step, please enter your username, name, email address, and password to set up a Confluence administrator account.

Click the "Next" button to continue.

Confluence is all set and ready to use.

Click the "Start" button to begin.

You can now establish a dedicated space for your team, allowing them to work on their projects.

To access the Traefik control panel, go to https://traefik.confluence.heyvaldemar.net from your workstation, where confluence.zabbix.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Nextcloud with OnlyOffice Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Mon, 11 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Nextcloud with OnlyOffice using Docker Compose.

OnlyOffice offers a secure online office suite highly compatible with MS Office formats. Connect it to your web platform for document editing and collaboration or use as a part of OnlyOffice Workspace.

:::tip[Architecture Context] Choose self-hosted Nextcloud with OnlyOffice when you need an integrated file storage and document editing platform with full data ownership. Google Workspace or Microsoft 365 provide managed alternatives with superior real-time collaboration. Self-hosting is justified when compliance requires on-premises document processing or when per-user SaaS licensing exceeds the cost of maintaining your own infrastructure. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/nextcloud-onlyoffice-traefik-letsencrypt-docker-compose"}

:::caution Remember that without a secure connection, the services will not work. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Nextcloud web interface.

:::

We connect to the server on which Nextcloud is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Nextcloud using the command:

docker network create nextcloud-network

docker network create onlyoffice-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Nextcloud to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/nextcloud-onlyoffice-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd nextcloud-onlyoffice-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as nextcloud-onlyoffice-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Nextcloud with the command:

docker compose -f nextcloud-onlyoffice-traefik-letsencrypt-docker-compose.yml -p nextcloud up -d

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password that you previously set in the .env file, and click the "Log In" button.

Welcome to the Nextcloud control panel.

Click the profile picture in the top-right corner, then select the "Apps" button.

Select "Integration" on the left sidebar and search for ONLYOFFICE integration.

Click on "Download and Enable" to install the ONLYOFFICE integration.

Click the profile picture in the top-right corner, then select the "Administration Settings" button.

Select "ONLYOFFICE" on the left sidebar.

In the "ONLYOFFICE Docs address" field, enter the domain name of the ONLYOFFICE service.

In the "Secret Key" field, enter the Secret Key for the ONLYOFFICE service.

:::caution You need to specify the domain name of the service and Secret key, previously defined in the .env file. :::caution

:::caution You will need cryptographic certificates for your domain names. In my configuration, certificates are requested automatically using Traefik and Let's Encrypt. Remember that without a secure connection, the services will not work. :::

Click on the "Save" button.

Settings have been successfully updated.

Let's try to create a document using OnlyOffice.

Click the folder icon in the left corner, then click the plus button and choose "New document" in OnlyOffice.

Enter the name for the new document and click the arrow button.

The document was successfully created.

Background Jobs Using Cron

Steps to Enable Cron

Log in to Nextcloud as an Administrator.
Go to Administration settings (click on your user profile in the top right corner and select "Administration settings").
In the Administration section on the left sidebar, select Basic settings.
Scroll down to the Background jobs section.
Select the "Cron (Recommended)" option.

Why Use Cron?

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Distinctions Between Terminal, Command Line, Shell, and Prompt

Vladimir Mikhalev (heyvaldemar.com) — Fri, 08 Sep 2023 00:00:00 GMT

New to Linux and tripping over all the overlapping terms? You're not alone. People throw around terminal, shell, command line, and prompt as if they mean the same thing. They don't. And if you're going to live in the CLI, you should know what each one actually does.

So here's the distinction, once and for all. Clear, quick, no fluff.

Terminal: The Box That Lets You Talk to the Machine

The terminal is just a window. It's a UI that lets you type into a shell. By itself it executes nothing. Think of it as a container for your CLI session.

Modern terminals are graphical apps that simulate the old physical terminals (yes, actual hardware) that once connected to mainframes. What you're running is a terminal emulator. A few examples:

The terminal launches your shell and displays its output. That's the whole job.

Shell: The Thing That Actually Runs Your Commands

The shell is the real workhorse. It's a program that parses what you type, runs it, and hands back output. It also does scripting, variables, functions, and other niceties. That's why it's two things at once: an interactive tool, and a scripting language.

Common Linux shells include:

bash - the default on many distros
zsh - feature-rich, used in macOS
fish - user-friendly, no need to memorize syntax
sh - minimal, legacy-compatible

Open your terminal and it starts a shell session. Type ls, and the shell interprets it, runs the ls binary, then sends the output back to the terminal. Three steps, one keystroke away.

Prompt: The "Ready for Your Input" Signal

That blinking text sitting there before you type anything? That's the prompt.

It tells you the shell is waiting. Prompts often carry useful info:

valdemar@devbox:~/projects $

valdemar = username
devbox = hostname
~/projects = current directory
$ = non-root user (use # if root)

Every shell lets you customize the prompt. Some people pack in Git status, battery life, even the weather. Don't.

On ancient systems your prompt might be nothing but a lonely % or >. Don't judge.

Command Line: The Concept, Not the App

The command line isn't an app. It isn't a binary either. It's a concept: an interface for typing commands instead of clicking buttons.

You'll find a command line in plenty of places:

A terminal (Linux, macOS, WSL, etc.)
A dedicated console (like the Windows Command Prompt)
Your programming language REPL (Python, Ruby, etc.)

You type text commands, you get text output. That's the command line.

Putting It All Together

Here's what actually happens when you "open the terminal" on Linux:

You launch a terminal emulator
It starts a shell
The shell shows a prompt
You enter a command on the command line
The shell runs the command and shows the result

TL;DR Cheat Sheet

Term	What It Is	Example
Terminal	The window or emulator app	GNOME Terminal, iTerm2, Konsole
Shell	The program that runs your commands	bash, zsh, fish, sh
Prompt	The text telling you the shell is ready	`valdemar@devbox:~$`
Command Line	The interface where you type commands	`ls -al`, `git status`

Final Thoughts

Knowing the difference isn't academic trivia. It helps you troubleshoot. Terminal won't launch? That's one problem. Shell crashes? Different problem. Prompt looks broken? Your config is probably janky. Nothing responds at all? Maybe you just need coffee.

You've got the basics now. So go write a shell script, alias ll to ls -alh, and quit calling everything "the terminal thing."

You're one step closer to speaking Linux like a native.

Install Zabbix Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 08 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Zabbix using Docker Compose.

Zabbix is a mature and effortless enterprise-class open source monitoring solution for network monitoring and application monitoring of millions of metrics.

:::tip[Architecture Context] Choose self-hosted Zabbix when you need agentless infrastructure monitoring with full data retention control and no per-host licensing fees. Datadog or New Relic provide managed alternatives with richer APM, log management, and integrations. Self-hosting Zabbix is justified when monitoring data must remain on-premises or when host count makes per-unit SaaS pricing prohibitive. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/zabbix-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Zabbix web interface.
TCP port 10051 - to communicate between the Zabbix server and the Zabbix agents for active checks.

:::

We connect to the server on which Zabbix is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Zabbix using the command:

docker network create zabbix-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Zabbix to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/zabbix-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd zabbix-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as zabbix-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Zabbix with the command:

docker compose -f zabbix-traefik-letsencrypt-docker-compose.yml -p zabbix up -d

To access the Zabbix management panel, go to https://dashboard.zabbix.heyvaldemar.net from your workstation, where dashboard.zabbix.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Zabbix.

:::note Tou need to specify the domain name of the service, previously defined in the .env file. :::

Now, you can log into the Zabbix dashboard as an administrator.

Use the following default credentials for the Zabbix administrator account:

Username: Admin
Password: zabbix

Click on the "Sign in" button.

Welcome to the Zabbix control panel.

Next, to configure the Zabbix server for self-monitoring, we need to define the DNS name of the Zabbix Agent.

Proceed by selecting "Hosts" under the "Data collection" section.

Next, click on the "Zabbix server".

Within the "Interfaces" section, find the "DNS name" subsection. Enter "zabbix-agent" as the Zabbix Agent service name, referencing the yml configuration file.

Next, under the "Connect to" section, select "DNS".

Click on the "Update" button.

After waiting a few minutes, refresh the page. You should then observe that the availability status of the Zabbix Agent has turned green.

To access the Traefik control panel, go to https://traefik.zabbix.heyvaldemar.net from your workstation, where traefik.zabbix.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Minecraft Server Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Mon, 04 Sep 2023 00:00:00 GMT

Want to run your own Minecraft Server with Docker Compose? This is the guide. Detailed, no fluff.

A Minecraft Server is a player-owned or business-owned multiplayer game server for the 2009 Mojang Studios video game Minecraft. One thing to keep straight: people say "server" but usually mean a network of connected machines, not one box.

:::tip[Architecture Context] Choose a self-hosted Minecraft server when you need full control over mods, plugins, world configuration, and player limits. Minecraft Realms offers a managed alternative with simpler setup but limited customization and a 10-player cap. Self-hosting is the right approach when you need modded gameplay, custom server properties, or want to avoid per-player subscription costs. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/minecraft-server-docker-compose"}

:::caution You will need A-type records in the external DNS zone, which point to the IP address of your server where Minecraft Server is installed. If you have created these records recently, you should wait before starting the installation of the services. Full replication of these records between DNS servers can take from a few minutes to 48 hours or even longer in rare cases. :::

:::note Alternatively, you can use the public static IP address of your server to connect directly. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

No OpenSSH yet? Install it with:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 25565 - to connect Minecraft clients to the server.

:::

SSH into the box where Minecraft Server will live.

First job is the network. Your services need one to talk over.

Create it for Minecraft Server like so:

docker network create minecraft-server-network

Now clone the repository. It carries the configuration files, and those files hold everything Minecraft Server needs to run.

Clone it with:

git clone https://github.com/heyvaldemar/minecraft-server-docker-compose.git

Step into the repository directory:

cd minecraft-server-docker-compose

Now edit the .env file. Set the variables to whatever your setup calls for.

:::note The .env file and plugins folder should be in the same directory as minecraft-server-docker-compose.yml. :::

Time to start it up:

docker compose -f minecraft-server-docker-compose.yml -p minecraft-server up -d

:::caution To connect to your Minecraft server, enter the domain name into the Minecraft client. This domain name should point to the IP address of your server where the Minecraft Server is installed. Alternatively, you can use the public static IP address of your server to connect directly. :::

:::caution Before using a domain name, ensure you have set up A-type records in your external DNS zone that point to this IP address. If you've recently created these records, it's advisable to wait before starting the installation of the services. DNS record propagation can vary, taking anywhere from a few minutes to 48 hours, and in rare cases, even longer. :::

Install WordPress Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Sun, 03 Sep 2023 00:00:00 GMT

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

This article is for those looking for a detailed and straightforward guide on installing WordPress using Docker Compose.

WordPress is a web content management system. It was originally created as a tool to publish blogs but has evolved to support publishing other web content, including more traditional websites, mailing lists and Internet forum, media galleries, membership sites, learning management systems and online stores.

:::tip[Architecture Context] Choose self-hosted WordPress when you need full control over plugins, themes, and hosting infrastructure without platform restrictions. WordPress.com or Squarespace provide managed alternatives with built-in CDN and automatic updates. Self-hosting is justified when you require custom PHP code, WooCommerce at scale, or need to avoid content platform lock-in. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/wordpress-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the WordPress web interface.

:::

We connect to the server on which WordPress is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for WordPress using the command:

docker network create wordpress-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for WordPress to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/wordpress-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd wordpress-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as wordpress-traefik-letsencrypt-docker-compose.yml. :::

Now let's start WordPress with the command:

docker compose -f wordpress-traefik-letsencrypt-docker-compose.yml -p wordpress up -d

To access the WordPress management panel, go to https://wordpress.heyvaldemar.net/wp-admin from your workstation, where wordpress.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to WordPress.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "Log In" button.

Welcome to the WordPress control panel.

To access the Traefik control panel, go to https://traefik.wordpress.heyvaldemar.net from your workstation, where traefik.wordpress.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Gitea Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Sat, 02 Sep 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Gitea using Docker Compose.

Gitea is a forge software package for hosting software development version control using Git as well as other collaborative features like bug tracking, code review, continuous integration, kanban boards, tickets, and wikis. It supports self-hosting but also provides a free public first-party instance.

:::tip[Architecture Context] Choose self-hosted Gitea when you need a lightweight Git server with minimal resource footprint and full control over repository data. GitHub or GitLab.com provide managed alternatives with CI/CD, package registries, and project management built in. Self-hosting Gitea is justified for air-gapped environments, edge deployments, or when you need a Git backend without per-user licensing costs. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/gitea-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Gitea web interface.
TCP port 2222 - for secure SSH Git operations, user SSH key management, encrypted data transfer, and server administration tasks.

:::

We connect to the server on which Gitea is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Gitea using the command:

docker network create gitea-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Gitea to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/gitea-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd gitea-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as gitea-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Gitea with the command:

docker compose -f gitea-traefik-letsencrypt-docker-compose.yml -p gitea up -d

To access the Gitea management panel, go to https://gitea.heyvaldemar.net from your workstation, where gitea.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Gitea.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click on the "Sing In" button.

Enter the username and password previously set in the .env file, and click the "Sign In" button.

Welcome to the Gitea control panel.

To access the Traefik control panel, go to https://traefik.gitea.heyvaldemar.net from your workstation, where traefik.gitea.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Keycloak Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 01 Sep 2023 00:00:00 GMT

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

Want a straight, detailed walkthrough of getting Keycloak running under Docker Compose? This is it.

Keycloak is open-source software that handles single sign-on, identity, and access management for modern applications and services.

:::tip[Architecture Context] Choose self-hosted Keycloak when your architecture requires an on-premises identity provider with full control over authentication flows, SAML/OIDC configuration, and user federation. Auth0 or Okta provide managed alternatives with faster setup and built-in compliance certifications. Self-hosting is justified when data residency rules prohibit external identity providers or when per-user SaaS pricing becomes prohibitive at scale. :::

:::note[Supply chain posture] The template pins all three upstream images (Traefik, PostgreSQL, Keycloak) to immutable @sha256:... digests in .env.example, rebuilds weekly via CI to catch upstream drift, and carries an OpenSSF Scorecard badge. See the repo's SECURITY.md for the disclosure policy and the production checklist in the README before exposing this to real users. :::

:::tip[Tested on every push] The deployment-verification workflow runs end-to-end backup/restore tests on every push, every pull request, and weekly. The tests boot the full compose stack and exercise backup creation, integrity (gunzip -t), restore roundtrip, and prune logic. If you deploy this template literally and hit an issue, the green CI run is the evidence that the template itself works — most "doesn't work" cases trace to DNS propagation, firewall rules, or hostname mismatches. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/keycloak-traefik-letsencrypt-docker-compose"}

:::note Traefik is our reverse proxy. It pulls cryptographic certificates from Let's Encrypt for your domain names and routes incoming requests to the right service based on the domain. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

Need OpenSSH? Install it with:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Keycloak web interface.

:::

Connect to the server where Keycloak is going to live.

First, the networks. Keycloak and Traefik each get their own.

Traefik's network:

docker network create traefik-network

And Keycloak's:

docker network create keycloak-network

Now clone the repository. It carries the configuration files, and with them everything Keycloak needs to run:

git clone https://github.com/heyvaldemar/keycloak-traefik-letsencrypt-docker-compose.git

Move into the directory you just cloned:

cd keycloak-traefik-letsencrypt-docker-compose

The repository ships a .env.example template with documented variables and change_me_* placeholders for credentials. The real .env file is gitignored. Copy the template to make your own:

cp .env.example .env

Open .env and swap the placeholders for real values. You need to fill in:

TRAEFIK_ACME_EMAIL: your email for Let's Encrypt renewal notices.
TRAEFIK_HOSTNAME and KEYCLOAK_HOSTNAME — your real domain names. Both must resolve to this server's public IP for the Let's Encrypt TLS-ALPN challenge to succeed.
KEYCLOAK_DB_PASSWORD: PostgreSQL password. Generate with:
```
openssl rand -base64 24 | tr -d '/+=' | head -c 32
```
KEYCLOAK_ADMIN_PASSWORD: Keycloak bootstrap admin password. Same generation command.

TRAEFIK_BASIC_AUTH: BCrypt hash for the Traefik dashboard login. Generate with:

docker run --rm httpd:2.4 htpasswd -nbB traefikadmin 'YOUR_STRONG_PASSWORD' | sed 's/\$/\$\$/g'

:::important The .env file must be in the same directory as keycloak-traefik-letsencrypt-docker-compose.yml. :::

:::tip[Fail-fast protection] The compose file uses ${VAR:?...} syntax for every required variable. If any placeholder is left unchanged or any required variable is empty, docker compose up fails immediately with a clear error — you cannot accidentally deploy the stack with placeholder credentials. :::

Start Keycloak:

docker compose -f keycloak-traefik-letsencrypt-docker-compose.yml -p keycloak up -d

Now open the management panel. From your workstation, go to https://keycloak.heyvaldemar.net. That domain is mine. Use your own, the one that points at the IP of your Traefik server, and Traefik forwards the request to Keycloak.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click the "Administration Console" button. Sign in with the KEYCLOAK_ADMIN_USERNAME and KEYCLOAK_ADMIN_PASSWORD you set in .env.

:::caution[Rotate the bootstrap admin] The bootstrap admin is intended to get you into the Keycloak UI on first start. Once inside, create your real admin users (ideally through Keycloak's user federation or a second-factor-protected account), then disable or delete the bootstrap admin from the Keycloak UI. Leaving the bootstrap admin active in production is the single most common misconfiguration in self-hosted Keycloak deployments. :::

Traefik has its own panel. From your workstation, go to https://traefik.keycloak.heyvaldemar.net. Again, that one is mine, so point your own domain at the IP of your Traefik server.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Authenticate with the Traefik dashboard credentials. The username (traefikadmin by default) and the plaintext password you passed to htpasswd when you generated the TRAEFIK_BASIC_AUTH BCrypt hash — not the hash itself. Browsers send the plaintext; Traefik verifies it against the stored BCrypt.

:::tip[What to do next] The Traefik dashboard is basic-auth-protected but basic auth is basic. For production, consider restricting the dashboard router to specific source IPs via Traefik's IPAllowList middleware, or skip exposing it publicly and rely on docker compose logs. The full production checklist is in the repository README. :::

Install Ghost Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Thu, 31 Aug 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Ghost using Docker Compose.

Ghost is a powerful app for new-media creators to publish, share, and grow a business around their content. It comes with modern tools to build a website, publish content, send newsletters & offer paid subscriptions to members.

:::tip[Architecture Context] Choose self-hosted Ghost when you need full control over your publishing platform, custom themes, and direct database access for analytics. Ghost Pro eliminates infrastructure management at $9-199/month. Self-hosting is the better architecture when you require custom integrations, need to avoid vendor lock-in on content, or want to keep hosting costs fixed regardless of traffic spikes. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/ghost-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Ghost web interface.

:::

We connect to the server on which Ghost is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Ghost using the command:

docker network create ghost-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Ghost to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/ghost-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd ghost-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as ghost-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Ghost with the command:

docker compose -f ghost-traefik-letsencrypt-docker-compose.yml -p ghost up -d

To access the Ghost management panel, go to https://ghost.heyvaldemar.net/ghost from your workstation, where ghost.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Ghost.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

The next step is to provide: the site title, your full name, an email address and a password to create a Ghost administrator account.

Click on the "Create account & start publishing" button.

Welcome to the Ghost control panel.

To access the Traefik control panel, go to https://traefik.ghost.heyvaldemar.net from your workstation, where traefik.ghost.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Rocket.Chat Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Fri, 25 Aug 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Rocket.Chat using Docker Compose.

Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript for organizations with high standards of data protection.

:::tip[Architecture Context] Choose self-hosted Rocket.Chat when your organization requires on-premises team messaging with full message retention control and custom integrations. Slack or Microsoft Teams provide managed alternatives with richer ecosystems and lower operational overhead. Self-hosting is justified in regulated environments where chat data must remain within your network perimeter or when per-user SaaS costs exceed infrastructure expenses. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/rocketchat-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Rocket.Chat web interface.

:::

We connect to the server on which Rocket.Chat is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Rocket.Chat using the command:

docker network create rocketchat-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Rocket.Chat to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/rocketchat-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd rocketchat-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as rocketchat-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Rocket.Chat with the command:

docker compose -f rocketchat-traefik-letsencrypt-docker-compose.yml -p rocketchat up -d

To access the Rocket.Chat management panel, go to https://rocketchat.heyvaldemar.net from your workstation, where rocketchat.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Rocket.Chat.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Next, we need to create a new user who will have administrator rights in Rocket.Chat.

In the "Full name" field, enter the first and last name for the new Rocket.Chat user.

In the "Username" field, specify a login for the new Rocket.Chat user.

In the "Email" field, provide a current email address for the new Rocket.Chat user.

In the "Password" field, set a secure password for the new Rocket.Chat user.

Click the "Next" button.

Now, you need to fill in the information about your organization.

In the "Organization name" field, enter the name of your organization.

In the "Organization industry" field, specify the profile or sector of your organization.

In the "Organization size" field, indicate the number of employees in your organization.

In the "Country" field, specify the country where your organization operates.

Click the "Next" button.

Now, you need to register your server to use services such as mobile push notifications, integration with external providers, and more.

In the "Cloud account email" field, provide a current email address.

Next, you should read and accept the terms of use for the provided services.

Click the "Register" button.

You will receive an email at the address provided earlier with a link to register your Rocket.Chat server.

Find the email and click on the "Verify registration" button.

Your server has been successfully registered.

Welcome to the Rocket.Chat control panel.

To access the Traefik control panel, go to https://traefik.rocketchat.heyvaldemar.net from your workstation, where traefik.rocketchat.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install GitLab Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Tue, 22 Aug 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing GitLab using Docker Compose.

GitLab is an open-source end-to-end software development platform with built-in version control, issue tracking, code review, CI/CD, and more.

:::tip[Architecture Context] Choose self-hosted GitLab when your organization requires on-premises source control with integrated CI/CD and compliance scanning. GitLab.com and GitHub provide managed alternatives that eliminate runner maintenance and infrastructure scaling. Self-hosting is justified when regulatory requirements prohibit cloud-hosted source code or when you need unlimited CI minutes without per-seat cost scaling. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/gitlab-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the GitLab web interface.
TCP port 2222 - for secure SSH Git operations, user SSH key management, encrypted data transfer, and server administration tasks.

:::

We connect to the server on which GitLab is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for GitLab using the command:

docker network create gitlab-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for GitLab to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/gitlab-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd gitlab-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as gitlab-traefik-letsencrypt-docker-compose.yml. :::

Now let's start GitLab with the command:

docker compose -f gitlab-traefik-letsencrypt-docker-compose.yml -p gitlab up -d

Now, let's retrieve the password for the root user. This will allow you to log into the GitLab management panel.

Use the following command:

sudo docker exec -it $(sudo docker ps -aqf "name=gitlab-gitlab-1") grep 'Password:' /etc/gitlab/initial_root_password

The password for the root user has been successfully retrieved.

To access the GitLab management panel, go to https://gitlab.heyvaldemar.net from your workstation, where gitlab.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to GitLab.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Use root as the username and the previously obtained password, then click the "Sign in" button.

Welcome to the GitLab control panel.

Next, let's retrieve the registration token for the GitLab Runner and register it to handle upcoming CI/CD jobs.

GitLab Runner is the open-source project that is used to run your CI/CD jobs and send the results back to GitLab.

To view the GitLab Runner's configuration, go to https://gitlab.heyvaldemar.net/admin/runners from your workstation, where gitlab.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to GitLab.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click on the three dots on the right to access the menu, then copy the registration token.

Next, let's register the GitLab Runner.

Return to the Terminal emulator.

:::caution Remember to replace REGISTRATION_TOKEN with the "Registration token" value you received in the previous step on the GitLab web interface. :::

To register the runner, use the following command:

REGISTRATION_TOKEN=LgcfPEKgawRTGR8P4uPQ && \
docker exec -it $(sudo docker ps -aqf "name=gitlab-runner-1") gitlab-runner register \
  --non-interactive \
  --url "http://gitlab/" \
  --registration-token "$REGISTRATION_TOKEN" \
  --executor "docker" \
  --docker-image docker:stable \
  --description "docker-runner-1" \
  --tag-list "docker,linux" \
  --run-untagged="true" \
  --docker-privileged \
  --output-limit "50000000" \
  --access-level="not_protected" \
  --docker-volumes "/var/run/docker.sock:/var/run/docker.sock"

GitLab Runner has been successfully registered and is ready to work.

Return to the web interface and verify that the GitLab Runner is now online.

To access the Traefik control panel, go to https://traefik.gitlab.heyvaldemar.net from your workstation, where traefik.gitlab.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Docker Desktop's Performance Odyssey Over a Year of Innovations

Vladimir Mikhalev (heyvaldemar.com) — Wed, 16 Aug 2023 00:00:00 GMT

Docker Desktop changed a lot over the past year. Most of it lands where you feel it day to day: startup time, file-sharing throughput, container-to-host networking. A slow Docker Desktop means more waiting and more context-switching while you work.

So I went through a year of releases and ran the benchmarks myself. Then I pulled out the changes that actually moved the numbers. Here's what shifted, and by how much.

2023: Docker Desktop's Performance Revolution

The 2023 releases are more than a version bump. Here's what changed, area by area.

1. Docker Daemon Startup Time

Startup got noticeably faster this year. Some configurations now initialize in just over 5 seconds. You get into your containers without sitting around for the daemon.

	Mac amd64	Mac arm64	Win amd64	Linux amd64
Time	7.84 s	5.24 s	19.1 s	9.50 s

2. Container Operations with Hyperfine

I benchmarked Docker across versions with hyperfine. v4.22 beats v4.11 every time. Container operations got faster, plain and simple.

To install Hyperfine you can use the command:

brew install hyperfine

Using the hyperfine Tool

To benchmark Docker commands, we'll use the hyperfine tool. Here's how you can execute it:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

What the flags do:

-i lets hyperfine run the benchmark in interactive mode, so you see results as they come in.
-p sets the warmup and benchmark commands for hyperfine.
The warmup command, docker stop ubuntu || :, tells Docker to stop the ubuntu container if it's running. If it isn't, it just moves on.
The benchmark command, docker run -it --rm ubuntu echo, starts the ubuntu container interactively and prints the current date and time.

Results for Docker Desktop v4.22

First Attempt:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

Benchmark 1: docker run -it --rm ubuntu echo
Time (mean ± σ): 44.3 ms ± 3.3 ms [User: 29.5 ms, System: 12.7 ms]
Range (min … max): 39.7 ms … 49.6 ms 10 runs
Warning: Ignoring non-zero exit code.

Second Attempt:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

Benchmark 1: docker run -it --rm ubuntu echo
Time (mean ± σ): 46.3 ms ± 2.3 ms [User: 29.4 ms, System: 12.4 ms]
Range (min … max): 43.1 ms … 52.5 ms 28 runs
Warning: Ignoring non-zero exit code.

Third Attempt:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

Benchmark 1: docker run -it --rm ubuntu echo
Time (mean ± σ): 46.5 ms ± 5.3 ms [User: 29.5 ms, System: 12.1 ms]
Range (min … max): 39.0 ms … 63.5 ms 28 runs
Warning: Ignoring non-zero exit code.

The first attempt averaged 44.3 milliseconds, give or take 3.3 milliseconds. So most runs landed between 41.0 and 47.6 milliseconds. Fastest was 39.7, slowest 49.6.

Second attempt: 46.3 milliseconds on average, deviation 2.3 milliseconds. Most runs sat between 44.0 and 48.6 milliseconds. The quickest hit 43.1, the longest 52.5.

Third attempt was noisier. Average 46.5 milliseconds, but the deviation jumped to 5.3 milliseconds. That spreads the bulk of runs across 41.2 to 51.8 milliseconds. They ranged from 39.0 all the way up to 63.5.

Results for Docker Desktop v4.11

First Attempt:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

Benchmark 1: docker run -it --rm ubuntu echo
Time (mean ± σ): 59.7 ms ± 3.2 ms [User: 36.4 ms, System: 15.6 ms]
Range (min … max): 55.0 ms … 68.3 ms 13 runs
Warning: Ignoring non-zero exit code.

Second Attempt:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

Benchmark 1: docker run -it --rm ubuntu echo
Time (mean ± σ): 56.7 ms ± 2.7 ms [User: 36.3 ms, System: 15.3 ms]
Range (min … max): 51.7 ms … 62.5 ms 13 runs
Warning: Ignoring non-zero exit code.

Third Attempt:

hyperfine -i -p 'docker stop ubuntu || :' 'docker run -it --rm ubuntu echo'

Benchmark 1: docker run -it --rm ubuntu echo
Time (mean ± σ): 59.8 ms ± 4.5 ms [User: 36.4 ms, System: 15.3 ms]
Range (min … max): 51.2 ms … 69.5 ms 21 runs
Warning: Ignoring non-zero exit code.

Older version, slower numbers. First attempt averaged 59.7 milliseconds with a 3.2 millisecond deviation, so most runs fell between 56.5 and 62.9 milliseconds. Quickest was 55.0, longest 68.3.

Second attempt came in a bit better: 56.7 milliseconds on average, deviation 2.7 milliseconds. Most runs landed between 54.0 and 59.4 milliseconds. The spread ran from 51.7 to 62.5.

Third attempt averaged 59.8 milliseconds, deviation 4.5 milliseconds. Most runs were between 55.3 and 64.3 milliseconds. Fastest 51.2, slowest 69.5.

Final Results (Docker Desktop 4.11 vs 4.22)

	Docker Desktop v4.11	Docker Desktop v4.22
First Attempt	55.0 - 68.3 ms	39.7 - 49.6 ms
Second Attempt	51.7 - 62.5 ms	43.1 - 52.5 ms
Third Attempt	51.2 - 69.5 ms	39.0 - 63.5 ms

3. Resource Efficiency

The new Resource Saver is a real win. It watches what Docker is doing and trims usage down to what's actually needed. Your Mac stays responsive even when the workload spikes.

Want to see it work? Start Docker Desktop and leave it idle for 30 seconds with no containers running. An icon shows up in the whale menu and in the dashboard sidebar. That's Resource Saver kicking in.

Resource Saver tracks container activity. If Docker Desktop sits idle with nothing running for 30 seconds, it drops its memory and CPU usage on its own.

The chart below shows what Resource Saver does to the memory footprint of all Docker Desktop processes. I measured it with the footprint CLI command, which collects memory data for a process or a group of processes.

4.1 File Sharing with VirtioFS

File sharing has always been the sore spot in containerized development. VirtioFS changes that. File I/O is much faster now. Builds finish sooner, data moves quicker, and the whole loop feels less sluggish.

Types of File Sharing Mechanism

File Sharing Mechanism	Description	Additional Notes
VirtioFS	A native file sharing mechanism supported by Docker Desktop. It's the fastest as it doesn't need extra software.	Default file-sharing mechanism in DD 4.22.
gRPC FUSE	Uses the gRPC protocol for file sharing. While slower than VirtioFS, it's faster than other mechanisms.	Default option in DD 2.4.0.0 (2020). Consumes less CPU than osxfs, especially with numerous file events on the host.
qemu-grpcfuse	Uses the qemu hypervisor for file sharing. It's the slowest mechanism but viable for building Redis images.
hyperkit-grpcfuse	Employs the hyperkit hypervisor for file sharing. Its speed is comparable to qemu-grpcfuse.
osxfs	A file system driver bridging macOS file system and the Linux-based system used by Docker containers.	Default file-sharing mechanism in Docker for Mac 1.12.x.

Enable VirtioFS

Open Docker Desktop settings and go to the "General" tab. Find "Choose file sharing implementation for your containers" and pick "VirtioFS". Then click "Apply & Restart".

Steps to Set Up and Test VirtioFS

Create a directory using the command:

mkdir data

Populate the Directory with a Large Data File (1GB of random data) using the command:

dd if=/dev/zero of=data/data.img bs=1M count=1000

Next, let's build the Docker Image using the command:

First, create a Dockerfile with the following content:

FROM ubuntu:latest

VOLUME /data

CMD ["bash"]

Then, build the Docker image using the command:

docker build -t virtiofs-demo:latest .

Run the Docker Container using the command:

docker run -it --rm -v "$(pwd)/data:/data" virtiofs-demo

List the Running Containers using the command:

docker ps

Expected output:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e47eb4731c80 virtiofs-demo "bash" 5 minutes ago Up 5 minutes gifted_lichterman

Next, measure File Copy Time into the Container

time docker cp gifted_lichterman:/data/data.img data/data.img

Expected result:

Successfully copied 1.05GB to /Users/ajeetsraina/july/virt/data/data.img
docker cp gifted_lichterman:/data/data.img data/data.img 0.61s user 1.84s system 36% cpu 6.750 total

Performance Comparison

Comparing Docker Desktop 4.22 vs 4.11 (without VirtioFS enabled)

Data Size: 10GB Data Transfer	Docker Desktop v4.11	Docker Desktop v4.22
Run #1	7 min 13.21 s	5 min 11.10 s
Run #2	6 min 47.89 s	5 min 04.08 s
Run #3	7 min 04.75 s	5 min 02.08 s

Comparing Docker Desktop 4.22 vs 4.11 (with VirtioFS enabled)

Data Size: 10GB Data Transfer	Docker Desktop v4.11	Docker Desktop v4.22
Run #1	2 min 18.55 s	1 min 04.44 s
Run #2	2 min 20.23 s	1 min 06.21 s
Run #3	2 min 15.65 s	1 min 05.39 s

4.2 Evaluating Docker Desktop's File-Sharing Performance

Every upgrade is partly about performance. With Docker Desktop, moving between versions isn't only new features. It's also tightening what's already there. The switch from VPNKit to gVisor mattered here. Container-to-host networking on macOS got up to 5x faster, so the things that used to crawl, like package downloads, move quickly now.

In this part I measure how long it takes to build a Redis image from source using Docker Desktop's file sharing. The source comes in over a bind mount. I time the build inside the container.

Redis Build Process

# !/bin/bash

rm -rf /tmp/redis
docker run --rm -v /tmp:/tmp alpine sh -c \
 'cd /tmp ; apk add git ; git clone https://github.com/redis/redis --depth 1'

docker run --rm -v /tmp/redis:/tmp/redis ubuntu bash -c \
 'cd /tmp/redis ; apt update && apt install -y make gcc ; make distclean && time make'

Redis Build Performance

Parameter	VirtioFS	gRPC FUSE	qemu-grpcfuse	hyperkit-grpcfuse
Redis Build	2.78 min	3.54 min	6.68 min	5.19 min

Postgres Build Process

First, the setup. The script below creates a Postgres network, starts a server, and fires off a pgbench client.

# !/bin/bash

IMG=postgres:alpine
NET=postgresnet
TESTDIR=/tmp/postgrestest/data
PGNAME=postgrestest
PGPASS=postgrespass

docker network rm -q $NET &>/dev/null

echo "Setting up postgres network..."
docker network create $NET

rm -rf $TESTDIR
mkdir -p $TESTDIR

echo "Initiating postgres server..."
docker run --name=${PGNAME} -e POSTGRES_PASSWORD=postgrespass --network ${NET} -p 5432:5432 -v ${TESTDIR}:/var/lib/postgresql/data -d ${IMG}

echo "Launching postgres pgbench client..."
docker run --network ${NET} alpine sh -c \
 'apk add postgresql ; export PGPASSWORD=postgrespass; \
 pgbench --host=postgrestest -U postgres -i -s 10 postgres ; \
 pgbench --host=postgrestest -U postgres -c 10 -t 10 postgres'

docker stop ${PGNAME} &>/dev/null
docker rm ${PGNAME} &>/dev/null
docker network rm -q $NET &>/dev/null

Postgres Build Performance

Scenario	4.11.1	4.22
Postgresql tps (transactions/s)	1000 tps	2600 tps

Version 4.22 leaves 4.11.1 behind on transactions per second. It hits 2600 tps, more than double the 1000 tps the older build managed.

The file-sharing mechanism you pick really moves build times. For something like a Redis build, VirtioFS is the one to use.

Postgres transactions also improved a lot in 4.22, which points to real work under the hood in this release.

VirtioFS wins on Redis builds, but pick your mechanism around the project. Compatibility and your specific needs come first.

That jump in Postgres throughput from 4.11.1 to 4.22 is the kind of thing that makes the upgrade pay for itself.

5. Container Networking Enhancements

The 2023 updates leaned hard on networking, especially on macOS. Containers talk to each other more smoothly now. Data moves faster, latency drops, and the whole setup runs tighter.

The big change was swapping VPNKit for gVisor on container-to-host networking. That landed in Docker Desktop 4.19, released in March 2023.

:::note In Docker Desktop 4.19, container-to-host networking performance was boosted by 5x on macOS, achieved by replacing vpnkit with the TCP/IP stack from the gVisor project. :::

gVisor is a lightweight, sandboxed container runtime that runs in user space. It's built on the Linux kernel but implemented in user space, which gives it an edge over VPNKit, a kernel-based solution.

If your containers reach out to external servers, say npm install or apt-get pulling packages, this speedup pays off immediately.

Enabling gVisor

To check that Docker Desktop is on gVisor by default, run:

cat ~/Library/Group\ Containers/group.com.docker/settings.json | grep -i network

If you want VPNKit back, add "networkType":"vpnkit" to your settings.json file.

Why gVisor over VPNKit:

Performance: gVisor is faster than VPNKit, so containers run quicker.
Security: It's sandboxed, which means better protection against vulnerabilities.
Resource Efficiency: It uses fewer resources than VPNKit, so your Mac has more to spare.

Networking Benchmarks

Container to Container

Benchmarking Tool: iperf3/netperf

# !/bin/bash

IMG=dockerpinata/iperf3:2.1
NET=iperf3net
SERVER=iperf3server
CLIENT=iperf3client

docker rm -f $SERVER &>/dev/null
docker network rm -q $NET &>/dev/null

echo "Creating iperf3 network..."
docker network create $NET

echo "Starting iperf3 server..."
docker run --rm -d --name=${SERVER} --network=${NET} ${IMG} /usr/bin/iperf3 -s -1

echo "Starting iperf3 client..."
docker run --rm --name=${CLIENT} --network=${NET} ${IMG} /usr/bin/iperf3 -c ${SERVER}

docker rm -f $SERVER &>/dev/null
docker network rm -q $NET &>/dev/null

Platform	Speed
Mac amd64	41.5 Gb/s
Mac arm64	81.7 Gb/s
Win amd64	46.1 Gb/s
Linux amd64	56.3 Gb/s

Container to Host

Benchmarking Tool: iperf3/netperf

# !/bin/bash

IMG=dockerpinata/iperf3:2.1

# This can be used to remove previous hanging iperf3 servers

# pkill iperf3

echo "Starting iperf3 server..."
iperf3 -s -1 &
IPERF3_SERVER_PID=$!

echo "Starting iperf3 client..."
docker run --rm ${IMG} /usr/bin/iperf3 -c host.docker.internal

kill $IPERF3_SERVER_PID &>/dev/null

Platform	Speed
Mac amd64	686 Mb/s
Mac arm64	1.50 Gb/s
Win amd64	596 Mb/s
Linux amd64	1.62 Gb/s

Host to Container

Benchmarking Tool: iperf3/netperf

# !/bin/bash

IMG=dockerpinata/iperf3:2.1
SERVER=iperf3server
docker rm -f $SERVER &>/dev/null
echo "Starting iperf3 server..."
docker run --rm -d -p 5201:5201 --name=${SERVER} ${IMG} /usr/bin/iperf3 -s -1
echo "Starting iperf3 client..."
iperf3 -c localhost
docker rm -f $SERVER &>/dev/null

Scenario	4.11.1	4.22
Container to Container	60 Gb/s	72 Gb/s
Host to Container	420 Mb/s	1.4 Gb/s
Container to Host/internet	930 Mb/s	18 Gb/s

6. Hardware Compatibility: Embracing Apple Silicon and Rosetta

Docker added a Rosetta feature, and it's a smart move. It closes the gap between Intel and Apple Silicon, so you get the same experience whatever hardware you're on.

That means you can drop this command:

docker run --platform=linux/amd64

Like with VirtioFS, Rosetta brought speedups too. Someone in our community clocked a 7x boost, most of it on a DB migration that used to crawl.

What this means in practice

Every release this year chipped at the same problem: the gap between running a container on your laptop and running it the way production does. On macOS, the gVisor networking switch alone justifies the upgrade. It brought up to 5x faster container-to-host networking.

Still on an older version? The gap isn't cosmetic anymore. You can read it in the build and startup numbers above. Update, push your own workload through it, and compare against what you had before.

Happy coding, and until next time, keep containerizing!

Install Mattermost Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Sun, 13 Aug 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Mattermost using Docker Compose.

Mattermost is an open-source, self-hostable online chat service with file sharing, search, and integrations. It is designed as an internal chat for organisations and companies, and mostly markets itself as an open-source alternative to Slack and Microsoft Teams.

:::tip[Architecture Context] Choose self-hosted Mattermost when your organization requires on-premises team communication with full message data ownership and custom compliance retention policies. Slack provides a managed alternative with richer app integrations and lower operational overhead. Self-hosting is justified in regulated industries where message data must remain within your network perimeter. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/mattermost-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Mattermost web interface.
UDP port 8443 - for handling secure voice calls within Mattermost.

:::

We connect to the server on which Mattermost is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Mattermost using the command:

docker network create mattermost-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Mattermost to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/mattermost-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd mattermost-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as mattermost-traefik-letsencrypt-docker-compose.yml. :::

Now let's start Mattermost with the command:

docker compose -f mattermost-traefik-letsencrypt-docker-compose.yml -p mattermost up -d

To access the Mattermost management panel, go to https://mattermost.heyvaldemar.net from your workstation, where mattermost.heyvaldemar.net` is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Mattermost.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Next, you need to register to start using the Mattermost dashboard.

To access the Traefik control panel, go to https://traefik.mattermost.heyvaldemar.net from your workstation, where traefik.mattermost.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Install Outline and Keycloak Using Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Wed, 09 Aug 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Outline and Keycloak using Docker Compose.

Outline is a free standalone wiki engine and a collaborative knowledge base for teams.

:::tip[Architecture Context] Choose self-hosted Outline with Keycloak when you need a knowledge base with enterprise SSO and full data ownership. Notion or Confluence Cloud provide managed alternatives with richer integrations and zero infrastructure overhead. Self-hosting is justified when compliance requires on-premises documentation storage or when you need centralized identity management across multiple self-hosted services. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/outline-keycloak-traefik-letsencrypt-docker-compose"}

:::note In this guide, Outline will use user accounts created in Keycloak for access to the Outline management panel, and MinIO for storing documents uploaded through Outline. :::

:::caution Remember that without a secure connection, the services will not work. :::

:::important MinIO has a known limitation: you can't use your domain or subdomain as the bucket name. For instance, if your wiki address is outline.<your-domain>.<tld>, choose a different name for your bucket. :::

:::caution Ensure that your AWS_S3_UPLOAD_BUCKET_URL that is set in the .env file is a publicly accessible URL that corresponds to your domain. This is crucial because the Outline server will redirect traffic directly to MinIO. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on the server you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to obtain a free cryptographic certificate through the Let's Encrypt certification center.
TCP port 443 - to access the Outline web interface.

:::

We connect to the server on which Outline is planned to be installed.

Now it is necessary to create networks for your services.

We create a network for Traefik using the command:

docker network create traefik-network

We create a network for Keycloak using the command:

docker network create keycloak-network

We create a network for Outline using the command:

docker network create outline-network

Next, you need to clone the repository that contains the configuration files, which include all the necessary conditions for Outline to work.

You can clone the repository using the command:

git clone https://github.com/heyvaldemar/outline-keycloak-traefik-letsencrypt-docker-compose.git

Navigate to the directory with the repository using the command:

cd outline-keycloak-traefik-letsencrypt-docker-compose

Next, you need to change the variables in the .env file according to your requirements.

:::important The .env file should be in the same directory as 01-traefik-outline-letsencrypt-docker-compose.yml, 02-keycloak-outline-docker-compose.yml, and 03-outline-minio-redis-docker-compose.yml. :::

:::caution The value for the OUTLINE_OIDC_CLIENT_SECRET variable can be obtained after installing Keycloak using 02-keycloak-outline-docker-compose.yml. :::

:::caution Additionally, you need to specify your values for OUTLINE_SECRET_KEY and OUTLINE_UTILS_SECRET. :::

The values for OUTLINE_SECRET_KEY and OUTLINE_UTILS_SECRET can be generated using the command:

openssl rand -hex 32

Now we will start Traefik using the command:

docker compose -f 01-traefik-outline-letsencrypt-docker-compose.yml -p traefik up -d

Next, we will start Keycloak using the command:

docker compose -f 02-keycloak-outline-docker-compose.yml -p keycloak up -d

From the workstation, navigate to the link https://keycloak.outline.heyvaldemar.net, where keycloak.outline.heyvaldemar.net is the name of my subdomain for accessing the Keycloak management panel. Accordingly, you need to specify your domain name, which points to the IP address of your server with the installed Traefik service, which will redirect the request to Keycloak.

Click on the "Administration Console" button.

Enter the username and password that you previously set in the .env file, and click the "Sign In" button.

Now you need to create a new Realm and configure it correctly so that users can log into Outline using Keycloak.

Click the "Create Realm" button in the upper left corner.

In the "Realm name" field, enter "outline-solid" (in lowercase) and click the "Create" button.

Next, select "Clients" in the "Manage" section and click the "Create client" button.

In the "Client type" field, select "OpenID Connect".

In the "Client ID" field, enter "outline-solid" (in lowercase) and click the "Next" button.

Next, you need to enable "Client authentication" and select "Standard flow" in the "Authentication flow" section.

All other values should be disabled.

Click the "Next" button.

In the "Root URL" field, enter https://outline.heyvaldemar.net/

In the "Home URL" field, enter https://outline.heyvaldemar.net/

In the "Valid redirect URIs" field, enter https://outline.heyvaldemar.net/

:::note outline.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name, which points to the IP address of your server with the installed Traefik service, which will redirect the request to Outline. :::

Click the "Save" button.

Navigate to the "Credentials" tab and copy the contents of the "Client secret" field.

Paste the copied contents of the "Client secret" field into the OUTLINE_OIDC_CLIENT_SECRET variable in the .env file.

Now let's create a user who will be able to log into Outline using Keycloak.

Select "Users" in the "Manage" section and click the "Add user" button.

In the next step, you need to specify: username, email address, first name, last name, and password.

:::note If you provide an email address, the user will be able to log into Outline using not only the username but also the email. :::

Click the "Create" button.

Next, you need to set a password for the new user.

Go to the "Credentials" tab and click the "Set password" button.

Enter a strong password and click the "Save" button.

Certainly! Below is the translation of the provided text:

Click the "Save password" button to confirm the assignment of a new password for the user.

The new password has been successfully set.

Now you can launch Outline with accompanying services and log into Outline using the previously created user.

Let's launch Outline with the following command:

docker compose -f 03-outline-minio-redis-docker-compose.yml -p outline up -d

To access the Outline management panel, go to https://outline.heyvaldemar.net from your workstation, where outline.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to Outline.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Click the "Continue with Keycloak" button.

Enter the username or email address and password previously set in Keycloak.

Welcome to the Outline control panel.

To access the MinIO control panel, go to https://console.minio.outline.heyvaldemar.net from your workstation, where console.minio.outline.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik service, which will redirect the request to MinIO.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "Login" button.

To access the Traefik control panel, go to https://traefik.outline.heyvaldemar.net from your workstation, where traefik.outline.heyvaldemar.net is the domain name of my service. Accordingly, you need to specify your domain name that points to the IP address of your server with the installed Traefik.

:::note You need to specify the domain name of the service, previously defined in the .env file. :::

Enter the username and password previously set in the .env file, and click the "OK" button.

Welcome to the Traefik control panel.

Mastering Docker Scout through Docker Desktop GUI and CLI

Vladimir Mikhalev (heyvaldemar.com) — Sun, 16 Jul 2023 00:00:00 GMT

Docker Scout shows you direct and transitive dependencies in one place, across every image layer. That alone makes container security easier to reason about. I wrote about why it matters before, here: Docker Scout is the Game-Changer in Container Security.

This one is about the how. I'll run Docker Scout in live use. Both the Docker Desktop GUI and the CLI.

So what does it actually do? Docker Scout reads the contents of an image, reports the packages and vulnerabilities inside, and suggests a fix for each. It also flags updates for your base image, with the tags and digests it recommends. You can filter images by vulnerability data too.

Installing Docker Scout

You need Docker Desktop to run Docker Scout. It works on Linux, macOS, and Windows. The Docker CLI ships with it, so you already have what you need.

Don't have it yet? Grab Docker Desktop from the official Docker website.

Installing Docker Scout on a server

To deploy Docker Scout on a server, run this:

curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s --

Manual installation

Download the docker-scout binary for your platform from the latest or other releases.

Uncompress Docker Scout as:
- docker-scout on Linux and macOS
- docker-scout.exe on Windows
Copy Docker Scout in your local CLI plugin directory:
- $HOME/.docker/cli-plugins on Linux and macOS
- %USERPROFILE%\.docker\cli-plugins on Windows
Make Docker Scout executable on Linux and macOS:
- chmod +x $HOME/.docker/cli-plugins/docker-scout
Authorize the binary to be executable on macOS:
- xattr -d com.apple.quarantine $HOME/.docker/cli-plugins/docker-scout

Mastering Docker Scout via Docker Desktop GUI

Run the latest Docker Desktop. Then open the "Images" section in the menu.

:::note In this guide, we will conduct a thorough examination of the security vulnerabilities associated with the Mattermost image. :::

Want the full setup for that image? I walk through it in Installing Mattermost with Docker Compose.

The "Local" tab lists every image on your system. Nothing there? Pull one with the docker pull command.

Now click the image you want to check.

The "Vulnerabilities" tab gives you a report on every security issue in the image.

Next, click "Recommended fixes" and pick "Recommendations for base image" to see what Scout suggests.

Here, refreshing the base image is one option.

Check the "Refresh base image" tab for those recommendations.

Or swap the base image entirely.

Check the "Change base image" tab for that.

Mastering Docker Scout via CLI

Now the CLI. A few commands carry most of the weight:

docker scout quickview: This command provides a succinct summary of an image, enabling you to get a quick understanding of its main features.

docker scout cves: This command reveals the Common Vulnerabilities and Exposures (CVEs) detected for any software artifacts found within an image, keeping you informed about potential security risks.

docker scout recommendations: With this command, you'll receive a list of all possible base image updates and remediation suggestions, guiding you on how to improve your container security and efficiency.

docker scout compare: This command allows you to compare two distinct images, highlighting their differences. This feature is particularly useful when you're tracking changes or considering updates.

Learn these four and you cover most of the day-to-day work.

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We will conduct a thorough examination of the security vulnerabilities associated with the Mattermost image.

Need the install steps first? See Installing Mattermost with Docker Compose.

Start with a quick summary of the image:

docker scout quickview mattermost/mattermost-team-edition:release-7.11

Next, pull the CVEs found across the artifacts in the image:

docker scout cves mattermost/mattermost-team-edition:release-7.11

Now list the base image updates and remediation suggestions:

docker scout recommendations mattermost/mattermost-team-edition:release-7.11

Scroll up for the rest.

Now compare two images and see what differs. Here, two Mattermost releases.

docker scout compare --to mattermost/mattermost-team-edition:release-7.11 mattermost/mattermost-team-edition:release-7.10

Scroll up for the rest.

Mastering Docker Scout via CLI in the container

You don't always need the plugin installed. You can run Scout straight from a container.

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We will conduct a thorough examination of the security vulnerabilities associated with the Mattermost image.

Same as before, the install guide is here: Installing Mattermost with Docker Compose.

Start with the quick summary:

docker run -it \
  -e DOCKER_SCOUT_HUB_USER=YOUR_DOCKER_HUB_USER_NAME \
  -e DOCKER_SCOUT_HUB_PASSWORD=YOUR_DOCKER_HUB_PASSWORD_OR_ACCESS_TOKEN \
  docker/scout-cli quickview mattermost/mattermost-team-edition:release-7.11

Then the CVEs found across the artifacts in the image:

docker run -it \
  -e DOCKER_SCOUT_HUB_USER=YOUR_DOCKER_HUB_USER_NAME \
  -e DOCKER_SCOUT_HUB_PASSWORD=YOUR_DOCKER_HUB_PASSWORD_OR_ACCESS_TOKEN \
  docker/scout-cli cves mattermost/mattermost-team-edition:release-7.11

Now the base image updates and remediation suggestions:

docker run -it \
  -e DOCKER_SCOUT_HUB_USER=YOUR_DOCKER_HUB_USER_NAME \
  -e DOCKER_SCOUT_HUB_PASSWORD=YOUR_DOCKER_HUB_PASSWORD_OR_ACCESS_TOKEN \
  docker/scout-cli recommendations mattermost/mattermost-team-edition:release-7.11

And compare two releases, same as before:

docker run -it \
  -e DOCKER_SCOUT_HUB_USER=YOUR_DOCKER_HUB_USER_NAME \
  -e DOCKER_SCOUT_HUB_PASSWORD=YOUR_DOCKER_HUB_PASSWORD_OR_ACCESS_TOKEN \
  docker/scout-cli compare \
    --to mattermost/mattermost-team-edition:release-7.11 \
    mattermost/mattermost-team-edition:release-7.10

Scroll up for the rest.

Conclusion

That's the walkthrough. Docker Scout from the Desktop GUI and from the CLI, both. Container security should sit near the top of your list, and Scout earns a spot in the workflow fast. Wire it in. You get fewer surprises in your images, and a base you can actually trust.

Docker Scout is the Game-Changer in Container Security

Vladimir Mikhalev (heyvaldemar.com) — Wed, 05 Jul 2023 00:00:00 GMT

Most container security tools feel like they were built by compliance auditors, not by anyone who ships images. Bloated UIs. Hourly scans that miss the window that matters. Remediation “advice” that boils down to “good luck.”

Docker shipped something different. It's called Docker Scout, and this one actually feels like it was built for the people running docker build.

Scout gives you real-time security insights and a full view of every dependency in an image, including the transitive ones that hide three layers down. It hooks into the Docker workflow you already use. It isn't trying to be your whole security platform. It's trying to make container image security less painful and more useful. That's the part nobody else got right.

Why Docker Scout Is a Big Deal

Docker Scout doesn't scan your layers and hand you a wall of CVEs. It gives you contextual intelligence. What's vulnerable. Where it came from. How to fix it without rebuilding your entire image from scratch.

That covers:

Base image vulnerabilities
App-layer dependencies (direct and transitive)
Real-time CVE detection tied to your image's SBOM

And it's event-driven. So no more “scheduled scans” that flag a problem 12 hours after it was already exploitable. A new CVE drops, your image is affected, and Scout knows. It tells you now.

What Makes Docker Scout Actually Useful

This is not another scanner bolted onto Docker Desktop. Scout works because it reads your images the way you read them.

Unified Image Intelligence

Scout doesn't just scan. It maps the image. Every layer, every dependency, in one place.

No jumping between tools. No guessing where that log4j nightmare crept in. One clear view of the whole software stack inside your image.

Real-Time Vulnerability Correlation

When a new CVE lands, Scout checks it against your image. Not by layer digest alone. It uses your SBOM.

In practice:

New vulnerability found in openssl (transitive dep)
↓
Scout detects it in your image layer
↓
You get notified *before* prod gets burned

Contextual Fix Suggestions

Scout doesn't scream “YOU HAVE A VULN” and walk off.

It hands you something you can act on:

“Update your base image to python:3.11-slim”
“Upgrade your requests package to ≥2.31.0”
“Rebuild with a patched upstream layer”

All of it lives in the Docker CLI, Desktop, and Hub. No context-switching.

The Interface: Clean, Focused, and Not Built by a Lawyer

Scout's UI isn't chasing design awards. It's showing you what matters:

CVEs prioritized by severity
Clear SBOM-driven insights
Easy navigation across image layers

It needs auth, because it's a cloud service. The upside: usage tracking, organizational access controls, and a managed backend that won't pin your CPU the way local scanners do.

Integration Without Lock-In

Docker didn't build Scout to rip out your security stack. It cooperates with the tools you've got, Snyk and Grype included, plus whatever else you've wired into CI/CD.

So keep your third-party scanners in production if you have them. Run Scout for early visibility during dev. Catch the problem before it ever reaches CI.

Availability & Pricing

Scout is in early access right now. Free to try, and Docker wants feedback from people who actually build images, not security gatekeepers.

A tiered model will probably show up later. For now it's open season. Use it, break it, file issues, and push it toward whatever it should become.

What It Looks Like in Practice

Want the hands-on walkthrough, GUI screenshots and CLI output and all? I wrote that up: 👉 Mastering Docker Scout through Docker Desktop GUI and CLI

That post walks through real workflows and shows how Scout surfaces useful information without wasting your afternoon.

Final Take

Docker Scout is what container security should have been from the start. Context-aware. Built for developers. Wired into the places you already work.

It's not perfect yet. But it already feels far more usable than most of the “enterprise-grade” scanners I've been stuck with in the field.

So try it. Run a scan. See what Scout turns up. Fix something before your CI pipeline starts crying.

Secure containers start at the CLI. Not after prod is already on fire.

Docker Init The Future of Easy Project Initialization

Vladimir Mikhalev (heyvaldemar.com) — Sun, 02 Jul 2023 00:00:00 GMT

Docker changed how we ship software, giving us a lightweight, portable, consistent runtime that works the same across different infrastructures. One of its newer additions is Docker Init, a CLI command that simplifies adding Docker to any project.

Understanding Docker Init

The Docker Init feature should not be confused with the internally used docker-init executable, which is triggered by Docker when using the --init flag with the docker run command. The Docker Init we're discussing here is a new feature in its beta phase that automates the creation of essential Docker-related assets like Dockerfiles, .dockerignore files, and compose.yaml files.

The Docker Init feature presently supports Go, Node, and Python, with Docker's development team actively extending support to other languages and frameworks, including Java, Rust, and .NET. This progressive expansion promises to make Docker Init even more useful to a wide range of developers.

Working with Docker Init

To use Docker Init, you'll need Docker Desktop version 4.18 or later. Once this is set up, you can run the docker init command in your project's target directory. Docker Init will detect the project's characteristics and automatically generate the necessary Docker files. This feature is particularly valuable for developers who are new to Docker, those learning about containerization, or developers looking to integrate Docker into their existing projects.

Docker Init in Action

Let's take a web server written in Go as an example.

We execute the command to start the process of automatically generating the necessary files to run the application using Docker Compose:

docker init

Next, you need to select the programming language in which your application is written.

:::note In this example, we are considering an application written in Go. :::

Select Go and press the "Enter" button.

Now you need to specify the installed version of Go.

:::note In this example, we consider working with version 1.20. :::

You can check the installed version with the command:

go version

Specify the installed version of Go and press the "Enter" button.

Next, you need to select the project directory in which "main.go" is located.

:::note In this example, "main.go" is in the root directory of the project. :::

Select the project directory in which "main.go" is located and press the "Enter" button.

Now you need to specify the port on which the web server is running.

:::note In this example, the web server is using port 8081. :::

Select the port on which the web server is running and press the "Enter" button.

The necessary files to run the application using Docker Compose have been generated.

We start the web server using Docker Compose:

docker compose up --build

The web server has started and is using port 8081.

Now you can go to http://127.0.0.1:8081 and check if the web server is working.

The web server is running.

Benefits of Docker Init

Docker Init plays a significant role in automating the creation of necessary Docker assets and standardizing the process across different projects. It allows developers to focus more on the development of their applications, reducing the risk of errors and inconsistencies, and thereby accelerating the adoption of Docker and containerization.

After Docker Init has completed, there may be a need to modify the created files to align them with your project requirements. In such cases, you can refer back to the Docker documentation for further information.

Conclusion

Even in beta, Docker Init already simplifies adding Docker support to a project. By automating the creation of Docker assets, it removes one more piece of manual setup. As Docker refines and expands the feature, it's likely to become a standard part of the toolkit.

Transforming Development with Docker Compose Watch

Vladimir Mikhalev (heyvaldemar.com) — Thu, 15 Jun 2023 00:00:00 GMT

Building containers during dev is slow. Slow and repetitive. And it wastes a stupid amount of time, because you end up rebuilding the entire image over a three-line edit in index.js.

Docker Compose Watch fixes that. It's not some half-baked beta toy either. It does the job.

You change a file, Docker reacts. Instantly. Your app syncs or rebuilds automatically, and you never type docker-compose up --build again just because you renamed a function.

So here's how it works, plus why I rate it as the best thing to land in local Docker dev since bind mounts.

What Is `watch` in Docker Compose?

It's a feature, still in alpha, that points Docker Compose at your local files and lets it do two things:

Sync them into running containers (great for JS, Python, anything with hot reload)
Rebuild the container when certain files change (like package.json, requirements.txt, etc.)

So it's file-watching with intent. Not dumb mirroring. Every update is targeted and rule-driven, which is the whole point.

Sync vs Rebuild: Know the Difference

Two actions live in your compose.yaml. Here they are.

`sync`

- action: sync
  path: ./web
  target: /src/web
  ignore:
    - node_modules/

Copies host changes into the container on save
Doesn't restart or rebuild the container
Perfect for JS/TS/React/Flask/Django/Express/etc.

Treat it as a cleaner, tighter replacement for bind mounts.

`rebuild`

- action: rebuild
  path: package.json

Triggers a full image rebuild when the watched file changes
Same as doing docker compose up --build <svc> behind the scenes
Ideal for dependency files or compiled languages

Use both. Rebuild on config changes. Sync everything else.

How to Use Docker Compose Watch

The full loop is short:

Add a x-develop.watch section to your compose.yaml
Start services with:
```
docker compose up --build --wait
```
Run:
```
docker compose alpha watch
```

Now your app updates in real time. That's how development should feel.

Real Example: Node.js App with Hot Reload

Say your project looks like this:

myproject/
├── web/
│   ├── App.jsx
│   └── index.js
├── Dockerfile
├── compose.yaml
└── package.json

Your compose.yaml:

services:
  web:
    build: .
    command: npm start
    x-develop:
      watch:
        - action: sync
          path: ./web
          target: /src/web
          ignore:
            - node_modules/
        - action: rebuild
          path: package.json

Start the service:

docker compose up --build --wait
docker compose alpha watch

Now edit App.jsx, save, and refresh the browser. Done.

Test It Yourself: Run a Live Demo

Clone the official demo:

git clone https://github.com/dockersamples/avatars.git
cd avatars
docker compose up -d
docker compose alpha watch

Then hit:

http://localhost:5735

Change something in src/ and watch it reload while you look at it.

Pro Tips

1. Use Sync for Hot Reload, Rebuild for State Changes

Example:

Sync: ./src, ./templates, .env
Rebuild: Dockerfile, package.json, requirements.txt

2. Ignore What Doesn't Matter

ignore:
  - node_modules/
  - dist/
  - *.log

Otherwise every temp file you touch kicks off a sync. You don't want that.

3. Optimize Your Dockerfile

Lean on multi-stage builds and cache your layers properly:

COPY package.json .
RUN npm ci
COPY . .

Copy too early and Docker throws out the cache on every change.

Not Just for Node.js

watch works far beyond Node. A few examples:

Python/Flask → sync .py, rebuild on requirements.txt
Go → rebuild on .go, mount volume for go run
Java/Spring → rebuild on .java or pom.xml
Rust → rebuild on Cargo.toml, cache your target dir

It's universal. The only real question is how you structure your watches.

Bonus: No More Bind Mount Weirdness

Bind mounts are fine, right up until they aren't. You hit OS quirks. You fight permissions. And on Windows, performance just falls off a cliff.

Sync rules hand you precision. Rebuild triggers hand you control. No quirks attached.

TL;DR

docker compose alpha watch = auto-sync + auto-rebuild
Use sync for live reload workflows
Use rebuild for dependency changes or compiled code
Clean alternative to bind mounts
Works with any language, any stack

Final Take

Dev loops should be fast. Not "wait 10 seconds for a container" fast. Save-and-see-it-immediately fast.

That's what Docker Compose Watch buys you. It's not production magic. It's dev-experience magic, and it holds up.

You write code. Docker handles the rest.

Install Bitwarden on Ubuntu Server 22.04 LTS

Vladimir Mikhalev (heyvaldemar.com) — Sun, 22 Jan 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Bitwarden on Ubuntu Server 22.04 LTS.

Bitwarden is a free open-source password manager with the ability to sync your account information across all devices.

:::tip[Architecture Context] Choose self-hosted Bitwarden when your organization requires on-premises credential management with full vault data control. Bitwarden Cloud or 1Password provide managed alternatives with polished enterprise features and zero server maintenance. Self-hosting is justified when security policy mandates that credentials never leave your infrastructure or when you need custom backup and recovery procedures. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the Bitwarden dashboard.

:::

First, you need to request an installation ID and installation key to host Bitwarden on your server. You must use a unique ID and key for each Bitwarden installation.

Go to the Bitwarden hosting setup page, enter your email address in the "Admin Email Address" field, and then click the "Submit" button to continue.

Save the resulting "Installation Id" and "Installation Key". These values will be required during Bitwarden installation.

We connect to the server on which you plan to install Bitwarden.

Download the Bitwarden installation script using the command:

curl -Lso bitwarden.sh https://go.btwrdn.co/bw-sh

Let's enable the execution of the file "bitwarden.sh" using the command:

chmod +x bitwarden.sh

Now let's start the Bitwarden installation using the command:

sudo ./bitwarden.sh install

Now you need to specify the domain name that you plan to use to access the Bitwarden dashboard.

Specify the domain name to access Bitwarden and press the "Enter" button.

This tutorial walks you through obtaining a free cryptographic certificate through the Let's Encrypt CA.

Press the "y" button, then "Enter".

We indicate the email address to which Let's Encrypt will send notifications about the expiration of the certificate and press the "Enter" button.

Specify the database name for the Bitwarden instance and press the "Enter" button.

Specify the "Installation Id" obtained earlier and press the "Enter" button.

We indicate the "Installation Key" obtained earlier and press the "Enter" button.

Bitwarden installed successfully.

Now let's start Bitwarden using the command:

sudo ./bitwarden.sh start

Bitwarden launched successfully.

To access the Bitwarden control panel, you need to go from the workstation to the link https://bitwarden.heyvaldemar.net, where bitwarden.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name of your server with Bitwarden installed.

Next, you need to register to start using the Bitwarden dashboard.

Install Wiki.js with Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Sat, 21 Jan 2023 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Wiki.js with Docker Compose.

Wiki.js is a wiki engine running on Node.js and written in JavaScript. It is free software released under the Affero GNU General Public License.

:::tip[Architecture Context] Choose self-hosted Wiki.js when you need a modern wiki with Markdown support, Git-backed storage, and no per-user licensing. Notion or Confluence Cloud provide managed alternatives with richer collaboration and lower maintenance. Self-hosting is justified when you need on-premises documentation with custom authentication, or when Git-based version control of documentation is an architectural requirement. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/wikijs-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the Wiki.js web interface.

:::

We connect to the server on which you plan to install Docker Compose.

Now you need to create a YAML configuration file that will contain all the necessary conditions for Docker Compose to work.

Let's create a YAML configuration file using a text editor using the command:

vim wikijs-traefik-letsencrypt-docker-compose.yml

Hit the "i" button to go into edit mode, then insert the following configuration for Wiki.js to work.

Next, you need to make changes to the configuration so that the contents of the file match your conditions. Parameters that need to be checked or changed are marked "(replace with yours)".

:::note In this guide, the wikijs.heyvaldemar.net subdomain will be used to access Wiki.js from the Internet. You will need to specify your domain or subdomain by which your Wiki.js will be accessible from the Internet. :::

:::note In this guide, Postgres will be used as a database management system, and Traefik will be used as a reverse proxy. :::

In the traefik.http.middlewares.authtraefik.basicauth.users parameter, you must specify the username and password hash to access the Traefik dashboard.

You can use this service to get the password hash.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now let's start Wiki.js with the command:

docker compose -f wikijs-traefik-letsencrypt-docker-compose.yml -p wikijs up -d

To continue the XWiki installation process, you need to go from the workstation to the link https://wikijs.heyvaldemar.net, where wikijs.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name of your Wiki.js. server.

The next step is to provide: an email address and a password to create a Wiki.js administrator account.

In the "Site URL" field, specify your domain or subdomain where your Wiki.js is. will be available on the Internet.

Click on the "Install" button.

Next, specify the email address and password for the Wiki.js administrator account that was created earlier.

Click on the "Log In" button.

Welcome to the Wiki.js control panel.

To access the Traefik control panel, go to the link https://traefik.wikijs.heyvaldemar.net from the workstation, where traefik.wikijs.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name of your server with Traefik installed.

Specify the username and password specified earlier in the YAML configuration file and click on the "OK" button.

Welcome to the Traefik dashboard.

Git Cheat Sheet

Vladimir Mikhalev (heyvaldemar.com) — Fri, 20 Jan 2023 00:00:00 GMT

Let's skip the Git theory lecture.

This cheat sheet is for people who already know Git is a version control system and just want the damn commands. You've got code to write, bugs to fix, and a production deploy in 6 minutes.

So here it is: everything you need, nothing you don't.

Setup

Set your name and email (commit author identity)

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@computing.dev"

Creating Repos

Start a new repo

git init

Clone an existing repo

git clone <repo-url>

Making Changes

Check what's changed

git status

Stage changes (individual or all)

git add <file>   # just one
# or
git add .        # all changes

Commit with a message

git commit -m "fix: patch infinite loop in login"

Unstage a file

git reset HEAD <file>

History & Diffs

See commit history

git log

See unstaged changes

git diff

See staged changes

git diff --staged

Remotes

Link to a remote repo

git remote add origin <url>

Push/pull to/from remote

git push origin <branch>
git pull origin <branch>

Branching

See, create, switch, and delete branches

git branch              # list branches
git branch <name>       # create

# switch to a branch
git checkout <name>

# delete a branch
git branch -d <name>

Merging

Merge a branch into current one

git merge <branch>

Stashing

Save, list, apply, and drop stashes

git stash               # stash current changes
git stash list          # see all stashes
git stash apply         # reapply latest stash
git stash drop          # delete latest stash

Tagging

Add, delete, and push tags

git tag <tag>
git tag -a <tag> -m "msg"
git tag -d <tag>
git push --tags

Reverting & Resetting

Revert a commit (safe)

git revert HEAD              # undo last commit

git revert <commit>          # revert specific commit

Reset to a clean state (dangerous)

git reset HEAD               # unstage

git reset --hard HEAD        # discard all local changes

git reset --hard <commit>    # nuke back to old commit

Aliases

Save yourself some keystrokes

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

That's It

Git can get deep, but you don't need to memorize plumbing commands to be dangerous.

Pin this cheat sheet, use it daily, and add aliases for whatever slows you down.

Now go commit something before someone force-pushes to main again.

Configure AWS CLI

Vladimir Mikhalev (heyvaldemar.com) — Tue, 08 Nov 2022 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on configuring AWS CLI.

The AWS CLI is a single tool for managing AWS services. With just one tool download, you can control many AWS services from the command line and automate them with scripts.

:::tip[Architecture Context] Named CLI profiles work for individual developers managing multiple AWS accounts. For teams, AWS IAM Identity Center (SSO) provides centralized credential management with temporary session tokens. Choose named profiles for personal workflows and SSO for any environment where multiple engineers share account access or where compliance requires credential rotation and audit trails. :::

:::important In this guide, we will consider the case when you already have an operating system with AWS CLI installed on it.

For detailed instructions on installing the AWS CLI on macOS, see my guide: Install AWS CLI on macOS.

:::

We need to create a new user and assign him an access policy. The user will be used to connect to AWS using AWS CLI.

Go to the "Users" section and click on the "Add users" button.

In the "User name" field, specify the username for the new user and check "Access key - Programmatic access".

:::note In this manual, "vladimir_mikhalev" will be used as the username. :::

Click on the "Next: Permissions" button.

Next, select "Attach existing policies directly".

Select the "AdministratorAccess" policy and Click on the "Next: Tags" button.

In the next step, you do not have to make any changes.

Click on the "Next: Review" button.

Everything is ready to create a new user.

Click on the "Create user" button.

The user has been successfully created and has the necessary permissions.

Now you need to save the received "Access key ID" and "Secret access key".

Click on the "Show" button to display the contents of the "Secret access key" section and save the contents of the section to a safe place.

Click on the "Close" button.

Let's configure AWS CLI with the command:

aws configure

In the "AWS Access Key ID" field, specify the access key ID that you obtained earlier during user creation.

Press the "Enter" button.

In the "AWS Secret Access Key" field, specify the secret access key that you obtained earlier during user creation.

Press the "Enter" button.

In the "Default region name" field, specify the AWS region in which you are planning to work.

Press the "Enter" button.

In the "Default output format" field, specify "json" as a format.

Press the "Enter" button.

Everything is ready to use the AWS CLI.

Let's list all EC2 instances with the command:

aws ec2 describe-instances

Please note that I have just one EC2 instance.

Now press the "q" button to close information about EC2 instances.

For step-by-step instructions on installing eksctl on macOS, see my guide: Install eksctl on macOS.

Install Terraform on macOS

Vladimir Mikhalev (heyvaldemar.com) — Tue, 08 Nov 2022 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Terraform on macOS.

Terraform is HashiCorp's infrastructure as a code tool. It lets you define resources and infrastructure in human-readable, declarative configuration files, and manages your infrastructure's lifecycle. Using Terraform has several advantages over manually managing your infrastructure.

:::tip[Architecture Context] Local Terraform CLI is the standard for infrastructure-as-code development and testing. Terraform Cloud or Spacelift provide managed alternatives with remote state, policy enforcement, and team collaboration built in. Local CLI is sufficient for individual workflows, but teams should evaluate remote backends early to avoid state management complexity as infrastructure grows. :::

:::important In this guide, we will consider the case when you already have the Homebrew package manager installed. :::

To install Homebrew, you can use the command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We connect the repository with formulas for Homebrew using the command:

brew tap hashicorp/tap

Run the Terraform installation with the command:

brew install hashicorp/tap/terraform

Next, you can see the installed version of Terraform using the command:

terraform -version

Everything is ready to use Terraform.

You can read more about how to configure AWS CLI in my guide Configure AWS CLI.

Install AWS CLI on macOS

Vladimir Mikhalev (heyvaldemar.com) — Fri, 16 Sep 2022 00:00:00 GMT

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

This article is for those looking for a detailed and straightforward guide on installing AWS CLI on macOS.

The AWS CLI is a single tool for managing AWS services. With just one tool download, you can control many AWS services from the command line and automate them with scripts.

:::tip[Architecture Context] AWS CLI is essential for scripting and automation workflows that exceed what the AWS Console provides. For infrastructure provisioning, Terraform or CloudFormation offer declarative alternatives with state management and drift detection. CLI is the right choice for ad-hoc operations, debugging, and scripting — while IaC tools should handle repeatable infrastructure deployments. :::

:::note We will be using the iTerm2 terminal emulator. :::

Download the AWS CLI installer using the command:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

Let's start the AWS CLI installation using the command:

sudo installer -pkg AWSCLIV2.pkg -target /

Specify the password for the account and press "Enter".

Now you can see the location of the executable file with the command:

which aws

You can now view the installed version of AWS CLI using the command:

aws --version

Everything is ready to use the AWS CLI.

You can read more about how to configure AWS CLI in my guide Configure AWS CLI.

Install Kubernetes on Ubuntu Server 22.04 LTS

Vladimir Mikhalev (heyvaldemar.com) — Fri, 09 Sep 2022 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Kubernetes on Ubuntu Server 22.04 LTS.

Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management.

:::tip[Architecture Context] Choose self-managed Kubernetes when you need full control over the control plane, custom CNI plugins, or on-premises orchestration in air-gapped environments. Amazon EKS, Google GKE, or Azure AKS provide managed alternatives that eliminate control plane maintenance. Self-managed clusters are justified when cloud-managed Kubernetes does not meet compliance, customization, or multi-cloud portability requirements. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

Kubernetes Master (Control Plane):

TCP port 6443 - for the Kubernetes API to work.
TCP port 2379-2380 - for the etcd server client API to work.
TCP port 10250 - for the Kubelet API to work.
TCP port 10259 - for kube-scheduler to work.
TCP port 10257 - for kube-controller-manager to work.

Kubernetes Worker:

TCP port 0250 - for the Kubelet API to work.
TCP port 30000-32767 - for NodePort Services to work.

:::

:::important We will consider installing one server with the Master role and one server with the Worker role. In the future, you can independently add the required number of servers to ensure high availability. :::

We connect to the server on which we plan to install the Kubernetes Master role.

Assign a name to the server using the command:

sudo hostnamectl set-hostname kubernetes-master-1.heyvaldemar.net

:::note In this tutorial, kubernetes-master-1.heyvaldemar.net is used as the name of the server with the Master role. :::

The server with the Worker role must resolve the name of the server with the Master role, and also the server with the Master role must resolve the name of the server with the Worker role.

Next, add the IP address and name of the server with the Master role to the "/etc/hosts" file using the command:

echo "10.0.5.140 kubernetes-master-1.heyvaldemar.net kubernetes-master-1" | sudo tee -a /etc/hosts

Having this entry will allow the server with the agent installed to resolve the Kubernetes server name even without a DNS entry.

:::note In this guide, the server name with the Master role is kubernetes-master-1.heyvaldemar.net, and the IP address is 10.0.5.140. :::

Make sure that the name of the server with the Worker role has the correct DNS entry, and also update the "/etc/hosts" file on the server with the command:

echo "10.0.6.19 kubernetes-worker-1.heyvaldemar.net kubernetes-worker-1" | sudo tee -a /etc/hosts

Having this entry will allow the server with the agent installed to resolve the Kubernetes server name even without a DNS entry.

:::note In this guide, the Master server name is kubernetes-worker-1.heyvaldemar.net and the IP address is 10.0.6.19. :::

Restart the hostamed service for the server name changes to take effect using the command:

sudo systemctl restart systemd-hostnamed

Check the correctness of the server name using the command:

hostname

Now let's replace the current shell process with the new one using the command:

exec bash

Next, you need to disable the paging file using the command:

sudo swapoff -a

The command above disables the swap file until the system is rebooted. We have to make sure that it stays off even after a reboot. To do this, edit the "fstab" file by commenting out the "/swapfile" line with the "#" symbol.

We execute the command:

sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

Load the kernel modules with the command:

sudo tee /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

Load the "overlay" module with the command:

sudo modprobe overlay

Load the "br_netfilter" module with the command:

sudo modprobe br_netfilter

Set the kernel options for Kubernetes with the command:

sudo tee /etc/sysctl.d/kubernetes.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

Apply the changes made using the command:

sudo sysctl --system

Now let's add the official Docker key with the command:

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg

Next, we connect the Docker repository using the command:

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

We press the "Enter" button.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for Kubernetes to work using the command:

sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates containerd.io

Now you need to configure containerd.

containerd - an industry-standard container runtime with an emphasis on simplicity, robustness and portability

We execute the command:

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1

We execute the command:

sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

Restart containerd to apply the changes, using the command:

sudo systemctl restart containerd

We enable autostart of the containerd service at the start of the operating system using the command:

sudo systemctl enable containerd

Now let's add the official Kubernetes key using the command:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Next, we connect the Kubernetes repository using the command:

sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

:::note At the time of writing this guide, Xenial is the current Kubernetes repository, but when the repository is available for Ubuntu 22.04 (Jammy Jellyfish), you will need to change the word in the command above from "xenial" to "jammy". :::

We press the "Enter" button.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install the kubelet, kubeadm and kubectl packages using the command:

sudo apt install -y kubelet kubeadm kubectl

The next step is to disable automatic updates and removal of installed packages using the command:

sudo apt-mark hold kubelet kubeadm kubectl

Now you need to start the initialization of the Kubernetes cluster using the command:

sudo kubeadm init --control-plane-endpoint=kubernetes-master-1.heyvaldemar.net

:::note In this tutorial, kubernetes-master-1.heyvaldemar.net is used as the name of the server with the Master role. :::

:::note To add another server to the cluster, you will need to do the same work of installing and configuring the server, and then run the kubeadm join command with the appropriate token for the server with the Master or Worker role. :::

Next, you need to run a few commands to start interacting with the cluster.

We execute the command:

mkdir -p $HOME/.kube

We execute the command:

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

We execute the command:

sudo chown $(id -u):$(id -g) $HOME/.kube/config

Next, you can see the addresses of the master and services using the command:

kubectl cluster-info

Now you can see a list of all nodes in the cluster and the status of each node using the command:

kubectl get nodes

We connect to the server on which we plan to install the Kubernetes Worker role.

Assign a name to the server using the command:

sudo hostnamectl set-hostname kubernetes-worker-1.heyvaldemar.net

This tutorial uses kubernetes-worker-1.heyvaldemar.net as the name of the server with the Worker role.

The server with the Worker role must resolve the name of the server with the Master role, and also the server with the Master role must resolve the name of the server with the Worker role.

Next, add the IP address and name of the server with the Master role to the "/etc/hosts" file using the command:

echo "10.0.6.19 kubernetes-worker-1.heyvaldemar.net kubernetes-worker-1" | sudo tee -a /etc/hosts

Having this entry will allow the server with the agent installed to resolve the Kubernetes server name even without a DNS entry.

:::note In this guide, the Master server name is kubernetes-worker-1.heyvaldemar.net and the IP address is 10.0.6.19. :::

Make sure that the name of the server with the Worker role has the correct DNS entry, and also update the "/etc/hosts" file on the server with the command:

echo "10.0.5.140 kubernetes-master-1.heyvaldemar.net kubernetes-master-1" | sudo tee -a /etc/hosts

Having this entry will allow the server with the agent installed to resolve the Kubernetes server name even without a DNS entry.

:::note In this guide, the server name with the Master role is kubernetes-master-1.heyvaldemar.net, and the IP address is 10.0.5.140. :::

Restart the hostamed service for the server name changes to take effect using the command:

sudo systemctl restart systemd-hostnamed

Check the correctness of the server name using the command:

hostname

Now let's replace the current shell process with the new one using the command:

exec bash

Next, you need to disable the paging file using the command:

sudo swapoff -a

We execute the command:

sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

Load the kernel modules with the command:

sudo tee /etc/modules-load.d/containerd.conf <<EOF
overlay
br_netfilter
EOF

Load the "overlay" module with the command:

sudo modprobe overlay

Load the "br_netfilter" module with the command:

sudo modprobe br_netfilter

Set the kernel options for Kubernetes with the command:

sudo tee /etc/sysctl.d/kubernetes.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

Apply the changes made using the command:

sudo sysctl --system

Now let's add the official Docker key with the command:

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg

Next, we connect the Docker repository using the command:

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

We press the "Enter" button.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for Kubernetes to work using the command:

sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates containerd.io

Now you need to configure containerd.

containerd - an industry-standard container runtime with an emphasis on simplicity, robustness and portability

We execute the command:

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1

We execute the command:

sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

Restart containerd to apply the changes, using the command:

sudo systemctl restart containerd

We enable autostart of the containerd service at the start of the operating system using the command:

sudo systemctl enable containerd

Now let's add the official Kubernetes key using the command:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

Next, we connect the Kubernetes repository using the command:

sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

We press the "Enter" button.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install the kubelet, kubeadm and kubectl packages using the command:

sudo apt install -y kubelet kubeadm kubectl

The next step is to disable automatic updates and removal of installed packages using the command:

sudo apt-mark hold kubelet kubeadm kubectl

Next, you need to add a server with the Worker role to the Kubernetes cluster using the command:

sudo kubeadm join kubernetes-master-1.heyvaldemar.net:6443 --token 5xuqag.tefxcfleieexwbos \
 --discovery-token-ca-cert-hash sha256:8c3e8eb9d95cd16496db9f65956e2ce1c2164fa64d17a487374bd906dbc0dcb3

The server with the Worker role has successfully joined the Kubernetes cluster.

We return to the server with the Kubernetes Master role.

Now you can see a list of all nodes in the cluster and the status of each node using the command:

kubectl get nodes

The nodes are in the "NotReady" status. To fix this, you need to install CNI (Container Network Interface) or network add-ons such as Calico, Flannel and Weave-net.

Download the Calico manifest with the command:

curl https://projectcalico.docs.tigera.io/manifests/calico.yaml -O

Install Calico with the command:

kubectl apply -f calico.yaml

Check the status of the pods in the kube-system namespace with the command:

kubectl get pods -n kube-system

Now you can see a list of all nodes in the cluster and the status of each node using the command:

kubectl get nodes

The nodes are in the "Ready" status and the Kubernetes cluster is ready to go.

Install Ubuntu Server 22.04 LTS

Vladimir Mikhalev (heyvaldemar.com) — Thu, 08 Sep 2022 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Ubuntu Server 22.04 LTS.

After booting from the Ubuntu Server 22.04 installation USB stick or DVD, begin by selecting the desired language for the welcome menu.

Select "English" and press "Enter".

Next, you can choose a keyboard layout.

Select your desired keyboard layout and click "Done".

Now you need to specify the installation type.

Choose "Ubuntu Server" and click "Done".

The installer will try to retrieve network settings using DHCP. You can adjust the IP address now or later.

Click "Done".

For proxy settings, we'll skip this step in our guide.

Simply click "Done".

You can specify an alternate mirror address if necessary.

For this guide, leave it as default and click "Done".

Determine the installation location. All available space will be used.

Choose "Use an entire disk" and then select "Set up this disk as an LVM group".

Click "Done".

Verify the partitions and click "Done".

Now you need to confirm your changes.

To continue, click "Continue" and press "Enter".

Provide the full username, server name, login, and password.

Click "Done".

If you plan to use SSH, choose "Install OpenSSH server".

Optionally, you can import SSH keys from Launchpad or Github.

Click "Done".

Select any other desired services or components.

Click "Done".

Monitor the installation progress until completion.

Once the installation is complete, click "Reboot".

Remove the installation media.

Finally, enter the username and password you set up earlier during the installation for authentication.

Install Docker Engine and Docker Compose on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Mon, 08 Aug 2022 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Docker Engine and Docker Compose on Ubuntu Server.

Docker is a container management system that allows you to "package" an application or website with all its environment and dependencies into a container that you can easily manage. For example, transfer to another server, scale, or update.

:::tip[Architecture Context] Choose self-managed Docker Engine when you need full control over container runtime configuration, storage drivers, and network plugins. Amazon ECS, Google Cloud Run, or Azure Container Instances provide managed alternatives that eliminate host-level maintenance. Self-managed Docker is justified when you need custom runtime configuration, on-premises deployment, or want to avoid cloud vendor lock-in at the container runtime layer. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We connect to the server on which you plan to install the Docker Engine.

Download the Docker Engine and Docker Compose installation script using the command:

curl -fsSL https://get.docker.com -o get-docker.sh

Now let's start the Docker Engine and Docker Compose installation using the command:

sh get-docker.sh

Now you need to make sure the Docker Engine is installed correctly. To do this, you need to run the command:

docker version

Next, you need to make sure the Docker Compose is installed correctly. To do this, you need to run the command:

docker compose version

Based on the received messages, the Docker Engine and Docker Compose are installed correctly.

Next, you can add a user to the "docker" group to run the Docker Engine without having to use "sudo".

Add the user "ubuntu" to the "docker" group using the command:

sudo usermod -aG docker $USER

To apply changes you need to log out and log back in again, which will cause your new session to have the proper group.

Install Rocket.Chat on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Wed, 13 Apr 2022 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Rocket.Chat on Ubuntu Server.

Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript for organizations with high standards of data protection.

:::tip[Architecture Context] Choose self-hosted Rocket.Chat when your organization requires on-premises team messaging with full message retention control and custom integrations. Slack provides a managed alternative with a richer app ecosystem and lower operational overhead. Self-hosting is justified in regulated industries where chat data must remain within your network perimeter or when you need unlimited message history without SaaS tier limits. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the Rocket.Chat web interface.

:::

We connect to the server on which you plan to install Rocket.Chat.

:::note To obtain and subsequently renew a free SSL certificate, we will use the Let's Encrypt certification authority, as well as the Certbot software client, which is designed to make it as easy as possible to obtain and renew a certificate through the Let's Encrypt certification authority. :::

:::note This tutorial will use MongoDB as the database management system and Nginx as the webserver. :::

To install MongoDB, you need to import the MongoDB public key and add a new repository.

Import the MongoDB public key using the command:

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

Let's add the MongoDB repository using the command:

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

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Let's make it possible to install Node.js through the package manager using the command:

curl -sL https://deb.nodesource.com/setup_14.x | sudo bash -

Now let's install the packages necessary for Rocket.Chat to work using the command:

sudo apt install -y nginx certbot python3-certbot-nginx nodejs build-essential mongodb-org graphicsmagick

:::note This tutorial will use MongoDB as the database management system and Nginx as the web server. :::

For Rocket.Chat to work correctly, it is recommended to use Node.js version 14.18.3.

Let's install a tool called "n" so that we can change the version of Node.js with the command:

sudo npm install -g inherits n

Next, install Node.js version 14.18.3 using the command:

sudo n 14.18.3

Now, to increase the security level of the webserver, it is necessary to obtain a cryptographic certificate for the domain or subdomain, through which the Multicraft control panel will be accessible from the Internet.

:::note In this tutorial, the rocketchat.heyvaldemar.net subdomain will be used to access Rocket.Chat from the Internet. You will need to specify your domain or subdomain by which your Rocket.Chat will be available from the Internet. :::

Request a cryptographic certificate using the command:

sudo certbot --nginx -d rocketchat.heyvaldemar.net

Next, specify the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the "a" button, then "Enter" if you agree with the terms of use of the services provided.

The next step is to choose whether you want to share the email address you provided earlier with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

The next step is to choose whether you want the Nginx configuration file to have parameters automatically added to automatically redirect HTTP traffic to HTTPS.

Press the "1" button, then "Enter".

:::note Cryptographic certificates obtained through the Let's Encrypt Certificate Authority are valid for ninety days. Certbot automatically adds a certificate renewal script to the task scheduler and the script runs twice a day, automatically renewing any cryptographic certificate that expires within thirty days. :::

You can check the operability of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now let's configure Nginx for subsequent work with Rocket.Chat.

First, you need to make changes to the Nginx configuration file by opening it in a text editor using the command:

sudo vim /etc/nginx/nginx.conf

Hit the "i" button to go into edit mode, find the parameter "server_names_hash_bucket_size 64;" and uncomment it by removing the "#" symbol.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now you need to create a block (called virtual hosts in Apache), with which Rocket.Chat will work in the future.

Let's create a virtual host file using a text editor using the command:

sudo vim /etc/nginx/sites-available/rocketchat.heyvaldemar.net

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

upstream backend {
    server 127.0.0.1:3000;
}

server {
    listen [::]:443 ssl ipv6only=on;
    listen 443 ssl;
    server_name rocketchat.heyvaldemar.net;

    # You can increase the limit if your need to.
    client_max_body_size 200M;

    error_log /var/log/nginx/rocketchat.access.log;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/rocketchat.heyvaldemar.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rocketchat.heyvaldemar.net/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://backend/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forward-Proto http;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
    }
}

server {
    if ($host = rocketchat.heyvaldemar.net) {
        return 301 https://$host$request_uri;
    }
        listen 80;
        listen [::]:80;
        server_name rocketchat.heyvaldemar.net;
        return 404;
}

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Activate the created block using the command:

sudo ln -s /etc/nginx/sites-available/rocketchat.heyvaldemar.net /etc/nginx/sites-enabled/

Deactivate the block created by default using the command:

sudo unlink /etc/nginx/sites-enabled/default

Verify that there are no errors in the syntax of the new Nginx configuration file using the command:

sudo nginx -t

Restart Nginx to apply the changes, using the command:

sudo systemctl restart nginx

Verify that Nginx has successfully started using the command:

sudo systemctl status nginx

Now let's download the archive "rocket.chat.tgz" containing the files for installing Rocket.Chat using the command:

curl -L https://releases.rocket.chat/latest/download -o /tmp/rocket.chat.tgz

Unpack the downloaded archive "rocket.chat.tgz" using the command:

tar -xzf /tmp/rocket.chat.tgz -C /tmp

Let's delete the previously downloaded "rocket.chat.tgz" archive containing the files for installing Rocket.Chat using the command:

rm -f /tmp/rocket.chat.tgz

Let's go to the "server" folder using the command:

cd /tmp/bundle/programs/server

Now let's start the installation of Rocket.Chat using the command:

npm install

Rename the "bundle" folder to "Rocket.Chat" using the command:

sudo mv /tmp/bundle /opt/Rocket.Chat

Now let's create the "rocket" user, which will be used to launch Rocket.Chat, with the command:

sudo useradd -M rocketchat

Block the user with the command:

sudo usermod -L rocketchat

Assign the correct rights to the "/opt/Rocket.Chat" directory using the command:

sudo chown -R rocketchat:rocketchat /opt/Rocket.Chat

Next, you need to configure the autostart of the Rocket.Chat service when the operating system starts.

Let's create a unit that will contain the necessary configuration for the Rocket.Chat service in the "/etc/systemd/system/" directory using the command:

sudo vim /lib/systemd/system/rocketchat.service

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

[Unit]
Description=The Rocket.Chat server
After=network.target remote-fs.target nss-lookup.target nginx.target mongod.target

[Service]
ExecStart=/usr/bin/node /opt/Rocket.Chat/main.js
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=rocketchat
User=rocketchat
# Rocket.Chat URL (replace with yours)
Environment=MONGO_URL=mongodb://localhost:27017/rocketchat?replicaSet=rs01 MONGO_OPLOG_URL=mongodb://localhost:27017/local?replicaSet=rs01 ROOT_URL=https://rocketchat.heyvaldemar.net/ PORT=3000

[Install]
WantedBy=multi-user.target

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now let's make changes to the MongoDB configuration using the command:

sudo sed -i "s/^# engine:/ engine: mmapv1/" /etc/mongod.conf

Next, let's make one more change to the MongoDB configuration using the command:

sudo sed -i "s/^#replication:/replication:\n replSetName: rs01/" /etc/mongod.conf

We enable autostart of the MongoDB service at operating system startup using the command:

sudo systemctl enable mongod

Start MongoDB with the command:

sudo systemctl start mongod

Check that MongoDB started successfully with the command:

sudo systemctl status mongod

Let's check that MongoDB is working correctly with the command:

mongo --eval "printjson(rs.initiate())"

We enable autostart of the Rocket.Chat service when the operating system starts using the command:

sudo systemctl enable rocketchat

Launch Rocket.Chat with the command:

sudo systemctl start rocketchat

Let's check that Rocket.Chat has successfully launched using the command:

sudo systemctl status rocketchat

All necessary services have been successfully launched.

Next, we need to create a new user who will have administrator rights in Rocket.Chat.

In the "Full name" field, enter the first and last name for the new Rocket.Chat user.

In the "Username" field, specify a login for the new Rocket.Chat user.

In the "Email" field, provide a current email address for the new Rocket.Chat user.

In the "Password" field, set a secure password for the new Rocket.Chat user.

Click the "Next" button.

Now, you need to fill in the information about your organization.

In the "Organization name" field, enter the name of your organization.

In the "Organization industry" field, specify the profile or sector of your organization.

In the "Organization size" field, indicate the number of employees in your organization.

In the "Country" field, specify the country where your organization operates.

Click the "Next" button.

Now, you need to register your server to use services such as mobile push notifications, integration with external providers, and more.

In the "Cloud account email" field, provide a current email address.

Next, you should read and accept the terms of use for the provided services.

Click the "Register" button.

You will receive an email at the address provided earlier with a link to register your Rocket.Chat server.

Find the email and click on the "Verify registration" button.

Your server has been successfully registered.

Welcome to the Rocket.Chat control panel.

Stand with Ukraine

Vladimir Mikhalev (heyvaldemar.com) — Thu, 24 Feb 2022 00:00:00 GMT

This blog is usually IT guides and advice. Not today. Today it stands as a voice against the lies and the injustice the bloody Russian regime has forced onto our world.

The Disinformation Landscape in Russia

Freedom of speech in Russia exists on paper. In practice, no. Reliable information is hard to find in Russian-language open sources. Most Russian media pass their reporting through the filter of state propaganda, and what comes out reflects the interests of the political leadership rather than the facts.

Even so, the important information is out there. Anyone can reach it through 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

Condemnation of the Invasion

As the founder and chief editor, I do more than condemn the Russian military invasion of Ukraine. I hold it in deep contempt. It is a blatant war crime. It has already taken hundreds of thousands of lives, children among them. The Russian government and President Vladimir Putin bear responsibility personally. So do the citizens of Russia, whose political indifference and inaction made another war possible.

The Suppression of Dissent in Russia

There was a time when Russians could speak more freely. The contrast with now is stark. Back in 2006, human rights activist Lev Ponomarev was arrested and held for three days after organizing a picket in Moscow. At the time, that counted as a relatively mild response.

The years since changed everything. Legislation tightened the rules for holding protests, pushed fines far higher, and added criminal liability for repeat violations of the law on rallies. Since 2014, nine of the thirteen significant amendments to that law have been aimed at narrowing the right to peaceful assembly. The result is plain. In the eyes of the authorities, a peaceful street protest is now a crime, and for the Russians who still believe protest is their right, an act of heroism.

Mass arrests of peaceful protesters, often with brutal treatment by the police, have become routine. And when the police use excessive force, as they did in January 2021, the authorities say nothing. That silence is what keeps the impunity going.

Legal Crackdown on Protests

The point of those examples is simple. When the rules were looser, Russian society had room to disagree with the authorities without fearing serious consequences. That room mattered. It is what lets political activism shift the public and political situation through peaceful demonstration.

Key Resources on Civil Liberties in Russia

These links go deeper on how the legal regulation of protest in Russia developed and changed:

Russia's Modern Military Conflicts

Since 1991, modern Russia has taken part in a long list of military conflicts. Some of the key wars:

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 detail on these and other conflicts is on the Wikipedia page listing wars involving Russia.

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

How You Can Help Ukraine

This is a historic moment, and I am asking you, our readers, to stand against this violence. What you do for Ukraine matters more than you think. Money, support for refugees, asylum, supplies: every one of those is a step toward peace and human dignity in a time that gives little of either. Solidarity and resolve can outlast cruelty and lawlessness. I believe that.

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

If you want to help the people of Ukraine, use these 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.

Each of these sends aid where it is needed most, and each makes sure 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

Photos from the Frontline

View more photos of the war in Ukraine.

Words of Hope and Resolve

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

Fight and you shall overcome!
God helps you!
With you are truth, glory
And holy freedom!

Taras Shevchenko, “Caucasus”, 1859

In Ukrainian:

Борітеся — поборете!
Вам Бог помагає!
За вас правда, за вас слава
І воля святая!

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

What is DevOps?

Vladimir Mikhalev (heyvaldemar.com) — Fri, 28 Jan 2022 00:00:00 GMT

There was a time when devs wrote code and threw it over the wall like a grenade. Ops teams caught it, if they were lucky, then duct-taped it into production and prayed nothing caught fire.

Spoiler: stuff caught fire. Often.

That broken model is what gave birth to DevOps. Not some trendy buzzword. Not a fancy job title. It was a response to pain, the kind you only understand once you've been paged at 3AM because someone's “worked on my machine” code just killed your live database.

No fluff. Just facts.

Dev vs Ops: A Dysfunctional Relationship

Before DevOps, here's how it usually went down:

Dev team: Push new features as fast as humanly possible.
Ops team: Block new changes to keep uptime at 99.99%.

Same company. Totally different goals. Zero shared context.

The result? Fragile handoffs, late-night deploy disasters, and finger-pointing marathons during postmortems.

Here's the classic line:

“It worked on my machine.”

Translation? “Not my problem.”

Enter DevOps: Collaboration by Necessity

DevOps exists because speed without stability is chaos, and stability without speed is irrelevance.

It's not just about tools. It's about mindset. A culture shift.

What DevOps really means

Developers own more of production.
Ops people get involved earlier in the lifecycle.
Everyone stops treating deployment like defusing a bomb.

DevOps unites developers, sysadmins, QA, and security under a shared mission: ship better software, faster, and keep it running.

The DevOps Pillars (From People Who've Been in the Trenches)

John Willis (co-author of The DevOps Handbook) gave us the CAMS model:

Culture, Automation, Measurement, and Sharing

That's the spine of real DevOps. Not Kubernetes. Not YAML. People first. Then tools.

Brian Dawson from CloudBees adds another lens:

People and culture, process and practice, tools and technology

Notice how “tools” is last? That's not an accident.

Too many teams buy Jenkins and call it DevOps. That's like buying a guitar and calling yourself a musician.

DevOps in Practice: What It Looks Like When It Works

When DevOps clicks, you get:

CI/CD pipelines that catch bugs before prod ever sees them
Automated tests that run on every pull request
Deploys on demand, not “Fridays only” horror shows
Monitoring and alerts wired in from day one
Blameless postmortems that actually fix things instead of fixing blame

And the numbers back it up. Companies doing DevOps right:

Deploy faster (daily, not quarterly)
Fail less often, and recover quicker when they do
Have happier engineers who don't live on pager duty

It's Not Optional Anymore

You don't “try” DevOps like a weekend side project. You do it because modern software delivery demands it.

If you're deploying weekly by hand, praying nothing breaks, and manually SSHing into servers to debug? You're not just behind. You're building a future incident.

“DevOps is how successful companies industrialize software delivery.” — Brian Dawson, CloudBees

In other words: it's how grown-ups ship software now.

TL;DR

Devs and Ops used to be siloed. That broke everything.
DevOps = shared ownership, faster feedback, and automation everywhere.
Tools matter, but culture matters more.
Done right, DevOps improves release speed and system reliability.
You're not "too small" for DevOps. You're just early.

Next Step

Want to start? Here's where to look:

Set up a real CI pipeline. Jenkins, GitHub Actions, GitLab, whatever.
Make one thing automatic: tests, builds, deploys, doesn't matter. Start somewhere.
Run a postmortem without blaming anyone. Learn. Repeat.

And if you're still arguing about who owns uptime? Congratulations — you're overdue for a DevOps intervention.

What is the Cloud?

Vladimir Mikhalev (heyvaldemar.com) — Thu, 27 Jan 2022 00:00:00 GMT

Straight answer first.

The cloud isn't magic. It's not a revolution, and it's definitely not new. It's rented computers. Someone else's datacenter, wrapped in APIs and billing dashboards and enough marketing jargon to make your eyes bleed.

Doesn't mean it doesn't matter.

If you build, deploy, or run software today, you're in the cloud whether you like it or not. So here's the plain version, no Gartner-speak: what you're using, what you're paying for, and where the real complexity hides.

Flashback: the cloud is just the mainframe all over again

Back in the `60s, computing was a shared service. You didn't own a computer. You bought time on one. Batch jobs, punch cards, big centralized boxes.

Then personal computers showed up. Then client-server. Then web apps. And eventually, surprise, we looped right back around.

“The Cloud” is just mainframes for the modern age — except this time it's running on someone else's rack, and you pay by the second.

It scales, too. And it usually works.

Cloud = renting what you used to buy

Say you want to deploy an app. In the pre-cloud world, you'd:

Buy a physical server
Rack it
Install Linux
Set up firewalls, monitoring, backups, etc.
Wait 3 weeks for procurement

Now? You open AWS, click a few buttons (or better, run terraform apply), and a server in Singapore is running your code inside of minutes.

That's the whole idea: pay-as-you-go access to computing resources. No upfront hardware. No maintenance contract. No yelling at procurement.

The three cloud models, minus the sales pitch

This is where the industry loves to chuck acronyms at you. SaaS, PaaS, IaaS. I'll walk them like an engineer would, not a vendor.

1. IaaS: Infrastructure as a Service

What you get: VMs, storage, networks. What you manage: Everything above the OS. Example: AWS EC2, Azure VMs, GCP Compute Engine

Think of it as a raw Linux box in the sky. You do the rest.

Setting up your own PostgreSQL cluster on Ubuntu in AWS? That's IaaS.

Real-world use case:

aws ec2 run-instances --image-id ami-xxxx --instance-type t2.medium

Flexible. But the burden's all yours. You patch it. You scale it. You secure it.

2. PaaS: Platform as a Service

What you get: A managed environment to run your code. What you manage: Just your app. Example: Heroku, OpenShift, Google App Engine

This is cloud with training wheels, and I mean that as a compliment. The OS and runtime aren't your problem anymore. You deploy your app and go.

Real-world example:

git push heroku main

Boom. App deployed.

Great when you want to ship fast. Less great when you need low-level control.

3. SaaS: Software as a Service

What you get: Fully managed apps. What you manage: Nothing. Just your data and usage. Example: Google Workspace, GitHub, Dropbox, Jira

You already live in SaaS. Your email runs on it. So does your ticketing system. That weird dashboard your CFO keeps exporting to Excel? SaaS, no question.

You don't control the code. That's the entire point.

Who's responsible for what?

Memorize this chart.

On-prem? You manage everything.
IaaS? You still manage OS and above.
PaaS? Just your code.
SaaS? Nothing but your login credentials.

Wondering why your team spends all day patching EC2s? Congrats. You're in IaaS-land.

So… why bother with the cloud?

Three reasons.

Elasticity - Scale up for Black Friday, scale down on Monday. Try doing that with a rack of Dell boxes.
Speed - From idea to deployment in minutes, not months.
Focus - Spend less time babysitting hardware and more time shipping features.

Tools of the trade

Here's how cloud use shakes out across the stack:

And here's how we actually build on it:

Want portability? Use containers. Need repeatability? Use Terraform. Scaling headaches? Hand them to managed services.

Final thought: the cloud is someone else's problem… until it's yours

You don't have to love the cloud. But you should know where it helps you, and where it turns around and bites.

Because every abstraction leaks. Every managed service eventually hands you a curveball. And “serverless” never meant ops-less.

Know what you're actually running. That's how much control you keep when things break.

TL;DR

Cloud = rented infrastructure with APIs and billing.
IaaS = VMs and control, but with responsibility.
PaaS = fast deploys, less control.
SaaS = just use the app, don't ask how it works.
The cloud isn't new — it's just better branded mainframes.
Know your layer, know your risks, use the right tool for the job.

What next?

Deploying apps? Pick a platform that fits your team's skill and scale. Teaching juniors? Walk them through the responsibility split across SaaS/PaaS/IaaS. Building infra? Godspeed, and may your Terraform plans never fail in prod.

Install XWiki with Docker Compose

Vladimir Mikhalev (heyvaldemar.com) — Thu, 12 Aug 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing XWiki with Docker Compose.

XWiki is an open-source collaboration platform that enables companies of all sizes to save time and money by enhancing collaboration at both the team and organization levels.

:::tip[Architecture Context] Choose self-hosted XWiki when you need a structured wiki with application development capabilities, custom macros, and full data ownership. Confluence Cloud or Notion provide managed alternatives with modern UX and zero infrastructure overhead. Self-hosting XWiki is justified when you need on-premises documentation with advanced structured data features or wiki-as-application-platform capabilities. :::

💾 You can find the repository used in this guide on GitHub.

::github{repo="heyvaldemar/xwiki-traefik-letsencrypt-docker-compose"}

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the XWiki web interface.

:::

We connect to the server on which you plan to install XWiki.

Now you need to create a YAML configuration file that will contain all the necessary conditions for XWiki to work.

Let's create a YAML configuration file using a text editor using the command:

vim xwiki-traefik-letsencrypt-docker-compose.yml

Hit the "i" button to go into edit mode, then insert the following configuration for XWiki to work.

Next, you need to make changes to the configuration so that the contents of the file match your conditions. Parameters that need to be checked or changed are marked "(replace with yours)".

:::note In this guide, the xwiki.heyvaldemar.net subdomain will be used to access XWiki from the Internet. You will need to specify your domain or subdomain by which your XWiki will be accessible from the Internet. :::

:::note In this guide, Postgres will be used as a database management system, and Traefik will be used as a reverse proxy. :::

In the traefik.http.middlewares.authtraefik.basicauth.users parameter, you must specify the username and password hash to access the Traefik dashboard.

:::note You can use this service to get the password hash. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now let's start XWiki with the command:

docker compose -f xwiki-traefik-letsencrypt-docker-compose.yml -p xwiki up -d

To continue the XWiki installation process, you need to go from the workstation to the link https://xwiki.heyvaldemar.net, where xwiki.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name of your XWiki server.

Click on the "Continue" button.

The next step is to specify: first name, last name, login, password and email address to create an XWiki administrator account.

Click on the "Register and login" button.

The account has been successfully registered.

Click on the "Continue" button.

The next step is to install a set of extensions for XWiki.

Select "XWiki Standard Flavor" and click on the "Install this flavor" button.

Next, you need to confirm the installation of "XWiki Standard Flavor".

Click on the "Install" button.

Click on the "Continue" button.

Installation of "XWiki Standard Flavor" is complete.

Click on the "Continue" button.

The next step will show the tree of XWiki pages.

Click on the "Continue" button.

Welcome to the XWiki control panel.

To access the Traefik control panel, go to the link https://traefik.xwiki.heyvaldemar.net from the workstation, where traefik.xwiki.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name of your server with Traefik installed.

Specify the username and password specified earlier in the YAML configuration file and click on the "OK" button.

Welcome to the Traefik dashboard.

Install OTRS on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Tue, 27 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing OTRS on Ubuntu Server.

OTRS Community Edition - is a free open-source service management system that is often used by IT service management, customer service, and corporate security to structure their communications and tasks.

:::tip[Architecture Context] Choose self-hosted OTRS Community Edition when you need a customizable helpdesk and ticketing system without per-agent licensing fees. Zendesk provides a managed alternative with modern UX, AI features, and built-in analytics. Self-hosting is justified when you need full control over ticket data, custom workflow automation, or operate in an environment where SaaS egress is restricted. :::

:::warning The OTRS Community Edition is no longer supported by OTRS AG, the company behind the original software. Its continued development has been taken over by Znuny. :::

:::warning You can install an older version of OTRS on Ubuntu Server by following this guide, or install a newer version from Znuny using my guide: Install OTRS Using Docker Compose. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the OTRS web interface.

:::

We connect to the server on which you plan to install OTRS.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

This tutorial walks you through obtaining a free cryptographic certificate through the Let's Encrypt CA. To obtain and subsequently renew a free SSL certificate, we will use the Certbot software client, which is designed to make it as easy as possible to obtain and renew a certificate through the Let's Encrypt certification authority.

Now we will install the packages required for OTRS to work using the command:

sudo apt install -y postgresql apache2 zip unzip build-essential bash-completion libapache2-mod-perl2 libdbd-pg-perl libtimedate-perl libnet-dns-perl libnet-ldap-perl libio-socket-ssl-perl libpdf-api2-perl libsoap-lite-perl libtext-csv-xs-perl libjson-xs-perl libapache-dbi-perl libxml-libxml-perl libxml-libxslt-perl libyaml-perl libarchive-zip-perl libcrypt-eksblowfish-perl libencode-hanextra-perl libmail-imapclient-perl libtemplate-perl libdigest-md5-perl libcrypt-ssleay-perl libdatetime-perl libauthen-ntlm-perl libpdf-api2-simple-perl libgd-text-perl libgd-graph-perl libyaml-libyaml-perl libmoo-perl apt-transport-https certbot python3-certbot-apache

:::note In this tutorial, PostgreSQL will be used as a database management system, and Apache will be used as a webserver. :::

Now you need to create a database that will be used by OTRS in the future, as well as a user with the necessary rights in this database.

Switch to the "postgres" user who has administrator rights in PostgreSQL using the command:

sudo su - postgres

Next, switch to the PostgreSQL command line using the command:

psql

We create a new user using the command:

CREATE USER otrsdbuser WITH PASSWORD 'dktLkEUvUWupy3Y7d9b';

For this tutorial, the username will be "otrsdbuser", with the password "dktLkEUvUWupy3Y7d9b".

We create a new database and grant the rights to it to the previously created user using the command:

CREATE DATABASE "otrsdb" WITH OWNER "otrsdbuser" ENCODING 'UTF8';

:::note This tutorial will use "otrsdb" as the name for the database. :::

Exit the "PostgreSQL" command line using the command:

\q

Log out as user "postgres" using the command:

exit

Now let's download the "rel-6_0.zip" archive containing the files for OTRS using the command:

wget https://github.com/OTRS/otrs/archive/refs/heads/rel-6_0.zip

Unpack the downloaded archive "otrs-latest.tar.gz" using the command:

unzip rel-6_0.zip

Now delete the previously downloaded archive "otrs-latest.tar.gz" containing the files for OTRS to work using the command:

sudo rm -f rel-6_0.zip

Move and rename the directory with files for OTRS operation, obtained from the archive, using the command:

sudo mv otrs-* /opt/otrs

Now let's create a user "otrs" that will be used to start OTRS using the command:

sudo useradd -d /opt/otrs -c 'OTRS user' otrs

Next, add a new user to the "www-data" group using the command:

sudo usermod -G www-data otrs

Let's prepare the OTRS configuration file using the command:

sudo cp /opt/otrs/Kernel/Config.pm.dist /opt/otrs/Kernel/Config.pm

Now you need to make changes to the OTRS configuration file by opening it in a text editor using the command:

sudo vim /opt/otrs/Kernel/Config.pm

Press the "i" button to enter the edit mode, find the parameter $Self->{'DatabaseDSN'} = "DBI:mysql:database=$Self->{Database};host=$Self->{DatabaseHost}"; and comment it out by placing the "#" symbol in front of the parameter.

Then we find the parameter $Self->{DatabaseDSN} = "DBI:Pg:dbname=$Self->{Database};"; and uncomment it by removing the "#" symbol in front of the parameter.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now you need to make changes to the Apache configuration file by opening it in a text editor using the command:

sudo vim /opt/otrs/scripts/apache2-perl-startup.pl

Then we find the parameters "use DBD::Pg ();" and "use Kernel::System::DB::postgresql;", and then uncomment them by removing the "#" symbol in front of the parameters.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Assign correct rights for the "otrs" user to files and directories using the command:

sudo chown -R otrs:otrs /opt/otrs

Now you need to check that all Perl modules required for OTRS to work are installed and do not need to be updated.

Let's check the Perl modules required for OTRS to work using the command:

sudo /opt/otrs/bin/otrs.CheckModules.pl

All Perl modules required for OTRS to run are installed and do not need to be updated.

Next, you need to do a few more checks for missing Perl dependencies and modules.

We perform the first check for missing Perl dependencies and modules using the command:

sudo perl -cw /opt/otrs/bin/cgi-bin/index.pl

The first check for missing Perl dependencies and modules was successful.

We perform a second check for missing Perl dependencies and modules using the command:

sudo perl -cw /opt/otrs/bin/cgi-bin/customer.pl

The second check for missing Perl dependencies and modules was successful.

We perform the third check for missing Perl dependencies and modules using the command:

sudo perl -cw /opt/otrs/bin/otrs.Console.pl

The third check for missing Perl dependencies and modules was successful.

Let's configure Apache for further work with the OTRS control panel.

We enable the Apache webserver module called "headers" using the command:

sudo a2enmod headers

:::note The "headers" module can be used to add more specific "Cache-Control" parameters. :::

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::note

For OTRS to work correctly, you still need Apache modules such as "perl", "deflate" and "filter". These modules should be enabled by default, but you can check this with the commands:

sudo a2enmod perl

sudo a2enmod deflate

sudo a2enmod filter

Now you need to create four virtual host files (called a block in Nginx), with which OTRS will work in the future.

Two virtual host files are required to provide access to OTRS over HTTPS, as well as to redirect agents from the otrs.heyvaldemar.net subdomain to the agent address https://otrs.heyvaldemar.net/otrs/index.pl.

The other two virtual host files will be required to provide access to OTRS over HTTPS and to redirect customers from the support.heyvaldemar.net subdomain to the customer service address https://otrs.heyvaldemar.net/otrs/customer.pl.

:::note In this guide, agents will use the otrs.heyvaldemar.net subdomain to access the OTRS web interface from the Internet, and the support.heyvaldemar.net subdomain for client access. You will need to specify your domains or subdomains by which OTRS will be available from the Internet for agents and customers. :::

Let's create the first virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/otrs.heyvaldemar.net.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName otrs.heyvaldemar.net
	
	RewriteEngine on
	RewriteCond %{SERVER_NAME} =otrs.heyvaldemar.net
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
	RedirectMatch permanent (.*)/$ https://otrs.heyvaldemar.net/otrs/index.pl
	
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

:::note In this guide, for agents to access the OTRS web interface from the Internet, the otrs.heyvaldemar.net subdomain will be used, from which agents will be redirected to the address https://otrs.heyvaldemar.net/otrs/index.pl. You will need to specify your domain or subdomain by which OTRS will be accessible from the Internet for agents. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create a second virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/otrs.heyvaldemar.net-ssl.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerAdmin callvaldemar@gmail.com
	ServerName otrs.heyvaldemar.net
	
	RedirectMatch permanent (.*)/$ https://otrs.heyvaldemar.net/otrs/index.pl
	
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
	
	SSLCertificateFile /etc/letsencrypt/live/otrs.heyvaldemar.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/otrs.heyvaldemar.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create a third virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/support.heyvaldemar.net.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName support.heyvaldemar.net
	
	RewriteEngine on
	RewriteCond %{SERVER_NAME} =otrs.heyvaldemar.net
	RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
	RedirectMatch permanent (.*)/$ https://otrs.heyvaldemar.net/otrs/customer.pl
	
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

:::note In this guide, customers will use the support.heyvaldemar.net subdomain to access the OTRS web interface from the Internet, from which customers will be redirected to https://otrs.heyvaldemar.net/otrs/customer.pl. You will need to specify your domain or subdomain by which OTRS will be accessible from the Internet for clients. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create the fourth virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/support.heyvaldemar.net-ssl.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerAdmin callvaldemar@gmail.com
	ServerName support.heyvaldemar.net

	RedirectMatch permanent (.*)/$ https://otrs.heyvaldemar.net/otrs/customer.pl
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
	
	SSLCertificateFile /etc/letsencrypt/live/otrs.heyvaldemar.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/otrs.heyvaldemar.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now you need to assign the correct permissions to files and directories for the correct operation of OTRS. To do this, you need to use a special script.

Let's go to the "otrs" folder using the command:

cd /opt/otrs

Assign the correct permissions to files and directories for the correct operation of OTRS using the command:

sudo bin/otrs.SetPermissions.pl --otrs-user=www-data --web-group=www-data

We activate the first virtual host using the command:

sudo a2ensite otrs.heyvaldemar.net.conf

We activate the second virtual host using the command:

sudo a2ensite otrs.heyvaldemar.net-ssl.conf

We activate the third virtual host using the command:

sudo a2ensite support.heyvaldemar.net.conf

We activate the fourth virtual host using the command:

sudo a2ensite support.heyvaldemar.net-ssl.conf

Now you need to activate the virtual host for OTRS to work, which should be loaded after all other settings. To do this, you can use a symbolic link with the "zzz" prefix.

We activate the virtual host for OTRS using the command:

sudo ln -s /opt/otrs/scripts/apache2-httpd.include.conf /etc/apache2/sites-enabled/zzz_otrs.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes made using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Now, to increase the security level of the webserver, it is necessary to obtain a cryptographic certificate for the domain or subdomain, through which the OTRS web interface will be accessible from the Internet.

:::note In this guide, agents will use the otrs.heyvaldemar.net subdomain to access the OTRS web interface from the Internet, and the support.heyvaldemar.net subdomain will be used for client access. You will need to specify your domains or subdomains by which OTRS will be available from the Internet for agents and customers. :::

Request a cryptographic certificate using the command:

sudo certbot --apache -d otrs.heyvaldemar.net -d support.heyvaldemar.net

Next, we indicate the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose whether you would like to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "1", then "Enter".

:::note Cryptographic certificates obtained through Let's Encrypt CA are valid for ninety days. Certbot automatically adds a script to renew the certificate to the task scheduler and the script runs twice a day, automatically renewing any cryptographic certificate that expires within thirty days. :::

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

To continue the OTRS installation process, you need to go from the workstation to the link https://otrs.heyvaldemar.net/otrs/installer.pl, where otrs.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name or IP address of your server with OTRS installed.

Click on the "Next" button.

The next step is to accept the license terms.

Click on the "Accept license and continue" button if you agree with the OTRS license agreement.

Next, you need to specify the system for managing the databases and the previously created database that will be used to work with OTRS.

In the "Type" field, select "PostgreSQL".

In the "Install Type" section, select "Use an existing database for OTRS".

Click on the "Next" button.

In the next step, you need to specify the data for connecting to the previously created database.

:::note In this manual, "otrsdbuser" is used as the username with database rights for OTRS. :::

In the "User" field, enter "otrsdbuser".

In the "Password" field, specify the password assigned to the "otrsdbuser" user.

In the "Host" field, enter "127.0.0.1".

This tutorial uses "otrsdb" as the database name for OTRS.

In the "Database name" field, specify "otrsdb".

Click on the "Check database settings" button.

The connection to the database has been successfully established.

Click on the "Next" button.

The database has been successfully prepared to work with OTRS.

Click on the "Next" button.

In the next step, you need to specify a few more parameters for the operation of OTRS.

In the "SystemID" field, select the desired number, which will serve as the identifier of the OTRS system. This identifier will be part of the number for all OTRS tickets.

In the "System FQDN" field, indicate the domain or subdomain by which OTRS is accessible from the Internet.

:::note In this manual, to access the OTRS web interface from the Internet, the otrs.heyvaldemar.net subdomain will be used. You will need to specify your domain or subdomain through which OTRS will be available from the Internet. :::

In the "AdminEmail" field, indicate the current email address of the OTRS administrator.

In the "Organization" field, enter the name of your organization.

In the "LogModule" field, specify "Syslog".

In the "Default Language" field, specify the language for your OTRS system.

In the "CheckMXRecord" field, specify "Yes" to check the MX records for the email addresses specified in OTRS.

Click on the "Next" button.

In the next step, you can specify the data that OTRS will use to send and receive emails. These settings are covered in the OTRS Configuration Guide and are best skipped for now.

Click on the "Skip this step" button.

In the next step, you will receive the username and password of an account with OTRS administrator rights.

Save this data in a safe place.

Now you need to start the OTRS daemon.

We return to the terminal emulator and start the OTRS daemon using the command:

sudo su - otrs -c "/opt/otrs/bin/otrs.Daemon.pl start"

:::note The daemon will run under the "otrs" user. :::

Now we need to activate two files that will be used by the cron task scheduler to verify that the OTRS daemon is running.

Let's go to the "cron" folder using the command:

cd /opt/otrs/var/cron

We activate the first file for the cron task scheduler using the command:

sudo cp aaa_base.dist aaa_base

We activate the second file for the cron task scheduler using the command:

sudo cp otrs_daemon.dist otrs_daemon

Now, to schedule tasks in the cron task scheduler, you need to use the "Cron.sh" script using the command:

sudo su - otrs -c "/opt/otrs/bin/Cron.sh start"

:::note The scheduled tasks will run under the "otrs" user. :::

OTRS installation completed successfully.

Now you need to make changes to the OTRS configuration to ensure that all internal links in OTRS will use HTTPS.

From the workstation, go to the link https://otrs.heyvaldemar.net/otrs/index.pl, where otrs.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name of your server with OTRS installed.

Specify the username and password of an account with OTRS administrator rights, and click on the "Login" button.

Welcome to the OTRS agent web interface.

Click on the "Admin" button.

Now in the "Administration" section, select "System Configuration".

In the search bar, specify "HttpType" and in the presented search result, select "HttpType"

In the "HttpType" section, specify "https".

Click on the checkmark to the right of the changed parameter to save the changes.

The changes made are saved. Now you need to apply them.

Click on the notification "You have undeployed settings, would you like to deploy it them?"

In the "Changes Overview" section, select the change you want to apply and click on the "Deploy selected changes" button.

Click on the "Deploy now" button to confirm the application of the previously made changes.

Now you need to change the time zone for the OTRS administrator account.

Click on the notification "Please select a time zone in your preferences and confirm it by clicking save button".

In the "Time Zone" field, select the appropriate time zone.

Click on the checkmark to the right of the changed parameter to save the changes.

Then click on the "Dasboard" button in the upper left corner of the screen to return to the OTRS agent home page.

Install Bitbucket on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Fri, 23 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Bitbucket on Ubuntu Server.

Bitbucket is a Git-based source code repository hosting service owned by Atlassian. Bitbucket offers both commercial plans and free accounts with an unlimited number of private repositories.

:::tip[Architecture Context] Choose self-hosted Bitbucket Data Center when your organization requires on-premises source control with Jira integration and compliance-mandated data residency. Bitbucket Cloud eliminates server maintenance and provides native CI/CD via Pipelines. Self-hosting is justified when regulatory frameworks require source code to remain within your network perimeter or when you need custom Git hooks at the server level. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to get a free cryptographic certificate through Let's Encrypt CA.
TCP port 443 - to access the Bitbucket web interface.
TCP port 7990 - to access the Bitbucket web interface.

:::

We connect to the server on which you plan to install Bitbucket.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now we will install the packages required for Bitbucket to work using the command:

sudo apt install -y postgresql apache2 apt-transport-https certbot python3-certbot-apache fontconfig

:::note In this tutorial, PostgreSQL will be used as a database management system, and Apache will be used as a webserver. :::

Let's configure Apache for further work with Bitbucket.

We enable the Apache webserver module called "proxy_http" using the command:

sudo a2enmod proxy_http

:::note The "proxy_http" module acts like a proxy server for the HTTP and HTTPS protocols. :::

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::

Now you need to create two virtual host files (called a block in Nginx), with which Bitbucket will work in the future.

Two virtual host files are required to provide access to Bitbucket over HTTPS, and to enable Bitbucket to be used at https://bitbucket.heyvaldemar.net, without specifying port 7990 in the browser address bar.

:::note In this tutorial, the subdomain bitbucket.heyvaldemar.net will be used to access Bitbucket from the Internet. You will need to specify your domain or subdomain under which your Bitbucket will be accessible from the Internet. :::

Let's create the first virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/bitbucket.heyvaldemar.net.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName bitbucket.heyvaldemar.net
</VirtualHost>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create a second virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/bitbucket.heyvaldemar.net-ssl.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerAdmin callvaldemar@gmail.com
	ServerName bitbucket.heyvaldemar.net

	ProxyRequests Off

	<Proxy *>
		Require all granted
	</Proxy>

	ProxyPass / http://localhost:7990/
	ProxyPassReverse / http://localhost:7990/

	SSLEngine On
	SSLCertificateFile /etc/letsencrypt/live/bitbucket.heyvaldemar.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/bitbucket.heyvaldemar.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

We activate the first virtual host using the command:

sudo a2ensite bitbucket.heyvaldemar.net.conf

We activate the second virtual host using the command:

sudo a2ensite bitbucket.heyvaldemar.net-ssl.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes made using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Now, to improve the security of your webserver, you need to obtain a cryptographic certificate for the domain or subdomain through which the Bitbucket control panel will be accessible from the Internet.

Request a cryptographic certificate using the command:

sudo certbot --apache -d bitbucket.heyvaldemar.net

Next, we indicate the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose whether you would like to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "2", then "Enter".

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now you need to create a database that Bitbucket will use in the future, as well as a user with the necessary rights in this database.

Switch to the "postgres" user who has administrator rights in PostgreSQL using the command:

sudo su - postgres

Next, switch to the PostgreSQL command line using the command:

psql

We create a new user using the command:

CREATE USER bitbucketdbuser WITH PASSWORD 'mU%g673b=6xa?8E6R9M3T';

:::note In this tutorial, "bitbucketdbuser" will be used as the username, with the password "mU%g673b=6xa?8E6R9M3T". :::

We create a new database and grant the rights to it to the previously created user using the command:

CREATE DATABASE bitbucketdb WITH OWNER "bitbucketdbuser" ENCODING='UTF8' CONNECTION LIMIT=-1;

:::note This tutorial will use "bitbucketdb" as the name for the database. :::

Exit the "PostgreSQL" command line using the command:

\q

Log out as user "postgres" using the command:

exit

Now you need to download the Bitbucket installer using the command:

wget https://www.atlassian.com/software/stash/downloads/binary/atlassian-bitbucket-7.12.0-x64.bin

:::note The current version of Bitbucket can be found on the official Atlassian website. :::

This tutorial covers installing Bitbucket 7.12.0.

Let's execute the file "atlassian-bitbucket-7.12.0-x64.bin" using the command:

sudo chmod +x atlassian-bitbucket-7.12.0-x64.bin

Let's start the Bitbucket installation using the command:

sudo ./atlassian-bitbucket-7.12.0-x64.bin

:::note Your command will differ from the one specified in this article, as you will be installing the latest version of Bitbucket at the time of reading. :::

In the first step, you can choose whether you want to install a new Bitbucket server or upgrade an existing one.

This tutorial walks through the installation of a new Bitbucket server.

Press the "Enter" button.

The next step is to select the Bitbucket edition.

Select the "Data Center" edition and press the "Enter" button.

In the next step, you can choose where to install Bitbucket.

This tutorial covers installing Bitbucket in "/opt/atlassian/bitbucket/7.12.0".

Press the "Enter" button.

Next, you can choose where to store your Bitbucket data.

This tutorial covers installing Bitbucket in "/var/atlassian/application-data/bitbucket".

Press the "Enter" button.

Now you can select the port that Bitbucket will use.

This tutorial walks you through installing Bitbucket using port 7990 for HTTP.

Press the "Enter" button.

Next, you will be offered the option to install Bitbucket as a service.

Press the "Enter" button.

Click on the "Enter" button to start installing Bitbucket.

Bitbucket installation completed successfully.

:::note You do not need to run Bitbucket. :::

We indicate "n" and press the "Enter" button.

Now you need to create a Bitbucket config file using the command:

sudo vim /var/atlassian/application-data/bitbucket/shared/bitbucket.properties

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

server.port=7990
server.secure=true
server.scheme=https
server.proxy-port=443
server.proxy-name=bitbucket.heyvaldemar.net

:::note In this tutorial, the subdomain bitbucket.heyvaldemar.net will be used to access Bitbucket from the Internet. You will need to specify your domain or subdomain under which your Bitbucket will be accessible from the Internet. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Launch Bitbucket using the command:

sudo service atlbitbucket start

Open the Bitbucket log to check if Bitbucket is starting correctly using the command:

sudo less /var/atlassian/application-data/bitbucket/log/atlassian-bitbucket.log

On your keyboard, press the "Shift" and "f" keys to start monitoring the Bitbucket log in real-time.

On the keyboard, press the key combination "Ctrl" and "c", then "q" to close the Bitbucket log.

To continue the Bitbucket installation process, you need to go from the workstation to the link https://bitbucket.heyvaldemar.net, where bitbucket.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name or IP address of your Bitbucket server.

This tutorial walks you through installing Bitbucket for a production environment.

In the "Language" field, select the language in which you plan to use Bitbucket.

In the "Database" field, select "External".

Now you need to specify the system for managing the databases and the previously created database that will be used to run Bitbucket.

In the "Database Type" field, select "PostgreSQL".

:::note In this tutorial, the database for running Bitbucket is on the same server as Bitbucket. :::

In the "Hostname" field, enter "localhost".

In the "Port" field, specify the value "5432".

This tutorial uses "bitbucketdb" as the database name for Bitbucket.

In the "Database name" field, enter "bitbucketdb".

This tutorial uses "bitbucketdbuser" as the database username for Bitbucket.

In the "Database username" field, specify "bitbucketdbuser".

In the "Database password" field, specify the password assigned to the "bitbucketdbuser" user.

Click on the "Test" button.

The message "Successfully established database connection." means that all data was entered correctly.

Click on the "Next" button.

Now you need to provide the base URL and license key for Bitbucket.

The "Base URL" field should indicate the domain or subdomain where your Bitbucket is accessible from the Internet.

If you do not already have a license key, you can request a temporary key to try Bitbucket.

In the "License key" section, select "I need an evaluation key" and click on the "Create an account" button.

The next step is to provide: email address, first name, last name, and password to create an Atlassian account.

Click on the "Sign up" button.

:::note You will receive an email to the email address specified during registration. In the letter, you will find a link to complete the registration. :::

If you already have an Atlassian account, enter the email address associated with your Atlassian account in the "Enter email" field and click on the "Continue" button.

Specify the password for the Atlassian account and click on the "Log in" button.

In the next step, you need to specify for which product you need a temporary license key, as well as the name of your organization.

Click on the "Generate License" button to generate a temporary license key for Bitbucket.

Next, you need to confirm that the temporary license key for Bitbucket will be installed on your server.

Click on the "Yes" button.

In the "Your License Key" field, insert the previously received temporary license key and click on the "Next" button.

In the next step, you need to specify: username, name, email address, and password to create a Bitbucket administrator account.

Click on the "Go to Bitbucket" button.

You can now log into your Bitbucket dashboard using your previously created Bitbucket administrator account.

Specify the username and password of an account with Bitbucket administrator rights and click on the "Log in" button.

Welcome to the Bitbucket dashboard.

Now you can create a new project and repository.

Click on the "Git on with it" button.

Click on "Create project" to start creating a new project.

In the "Project name" field, specify the name for the project and click on the "Create project" button.

Click on "Create repository" to start creating a new repository.

In the "Name" field, specify the name for the repository and click on the "Create repository" button.

Everything is ready to use Bitbucket.

Install Confluence on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Fri, 23 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Confluence on Ubuntu Server.

Confluence is a collaboration tool that helps teams collaborate and share knowledge effectively.

:::tip[Architecture Context] Choose self-hosted Confluence Data Center when your organization requires on-premises documentation with custom authentication and data residency controls. Confluence Cloud eliminates patching, scaling, and database maintenance. Self-hosting is justified when compliance mandates on-premises data storage or when you need direct database access for custom reporting and integration with internal systems. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the Confluence web interface.
TCP port 8090 - to access the Confluence web interface.

:::

We connect to the server on which you plan to install Confluence.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for Confluence to work using the command:

sudo apt install -y postgresql apache2 apt-transport-https certbot python3-certbot-apache fontconfig

:::note In this tutorial, PostgreSQL will be used as a database management system, and Apache will be used as a webserver. :::

Let's configure Apache for further work with Confluence.

We enable the Apache webserver module called "proxy_http" using the command:

sudo a2enmod proxy_http

:::note The "proxy_http" module acts like a proxy server for the HTTP and HTTPS protocols. :::

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::

Now you need to create two virtual host files (called a block in Nginx), with which Confluence will work in the future.

You will need two virtual host files to provide HTTPS access to Confluence, and to enable Confluence at https://confluence.heyvaldemar.net, without specifying port 8090 in your browser address bar.

:::note In this tutorial, you will use the confluence.heyvaldemar.net subdomain to access Confluence from the Internet. You will need to specify your domain or subdomain under which your Confluence will be accessible from the Internet. :::

Let's create the first virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/confluence.heyvaldemar.net.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName confluence.heyvaldemar.net
</VirtualHost>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create a second virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/confluence.heyvaldemar.net-ssl.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerAdmin callvaldemar@gmail.com
	ServerName confluence.heyvaldemar.net
	ProxyRequests Off

<Proxy *>
	Require all granted
</Proxy>

	SSLEngine On
	SSLCertificateFile /etc/letsencrypt/live/confluence.heyvaldemar.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/confluence.heyvaldemar.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf

	RewriteEngine On
	RewriteCond %{REQUEST_URI} !^/synchrony
	RewriteRule ^/(.*) http://confluence.heyvaldemar.net:8090/$1 [P]

<Location />
	Require all granted
</Location>

	ProxyPass /synchrony http://localhost:8091/synchrony

<Location /synchrony>
	Require all granted
	RewriteEngine on
	RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
	RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
	RewriteRule .* ws://localhost:8091%{REQUEST_URI} [P]
</Location>
</VirtualHost>
</IfModule>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

We activate the first virtual host using the command:

sudo a2ensite confluence.heyvaldemar.net.conf

We activate the second virtual host using the command:

sudo a2ensite confluence.heyvaldemar.net-ssl.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes made using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Now, to improve the security of your webserver, you need to obtain a cryptographic certificate for the domain or subdomain, through which the Confluence control panel will be accessible from the Internet.

Request a cryptographic certificate using the command:

sudo certbot --apache -d confluence.heyvaldemar.net

Next, we indicate the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose whether you would like to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "2", then "Enter".

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now you need to create a database that Confluence will use in the future, as well as a user with the necessary rights in this database.

Switch to the "postgres" user who has administrator rights in PostgreSQL using the command:

sudo su - postgres

Next, switch to the PostgreSQL command line using the command:

psql

We create a new user using the command:

CREATE USER confluencedbuser WITH PASSWORD '2n!sfa@423FdsC0fH$vL';

:::note In this tutorial, "confluencedbuser" will be used as the username, with the password "2n!sfa@423FdsC0fH$vL". :::

We create a new database and grant the rights to it to the previously created user using the command:

CREATE DATABASE "confluencedb" WITH OWNER "confluencedbuser" ENCODING 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' TEMPLATE template0 CONNECTION LIMIT = -1;

:::note This tutorial will use "confluencedb" as the name for the database. :::

Exit the "PostgreSQL" command line using the command:

\q

Log out as user "postgres" using the command:

exit

Now you need to download the Confluence installer using the command:

wget https://www.atlassian.com/software/confluence/downloads/binary/atlassian-confluence-7.12.0-x64.bin

:::note The latest version of Confluence can be found on the official Atlassian website. :::

Let's enable execution of the file "atlassian-confluence-7.12.0-x64.bin" using the command:

sudo chmod a+x atlassian-confluence-7.12.0-x64.bin

Let's start the Confluence installation using the command:

sudo ./atlassian-confluence-7.12.0-x64.bin

:::note Your team will differ from the one listed in this article, as you will be installing the most current version of Confluence at the time of reading. :::

At the first stage, the installer will warn you that Confluence will be installed on your server.

Press the "Enter" button.

Next, select "Custom Install (recommended for advanced users)".

Press the "Enter" button.

In the next step, you can choose where to install Confluence.

This tutorial covers installing Confluence in "/opt/atlassian/confluence".

Press the "Enter" button.

Next, you can choose where to store your Confluence data.

This tutorial covers installing Confluence in "/var/atlassian/application-data/confluence".

Press the "Enter" button.

Now you can select the ports that Confluence will use.

This tutorial walks you through installing Confluence using port 8090 for HTTP and port 8000 for Control.

Press the "Enter" button.

Next, you will be offered the opportunity to install Confluence as a service.

Press the "Enter" button.

Confluence installation completed successfully.

We indicate "n" and press the "Enter" button.

Now you need to make changes to the Confluence configuration file by opening it in a text editor using the command:

sudo vim /opt/atlassian/confluence/conf/server.xml

Hit the "i" button to go into edit mode, find the section "DEFAULT - Direct connector with no proxy, for unproxied HTTP access to Confluence" and comment it out by putting <! -- on the line above the section parameters and --> below the section parameters that you want to comment out.

Next, find the section "HTTPS - Proxying Confluence via Apache or Nginx over HTTPS" and uncomment it by removing the <! -- on the line above the section parameters and --> below the section parameters that you want to uncomment.

Then set the "proxyName" parameter to confluence.heyvaldemar.net.

:::note In this tutorial, you will use the confluence.heyvaldemar.net subdomain to access Confluence from the Internet. You will need to specify your domain or subdomain under which your Confluence will be accessible from the Internet. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Launch Confluence using the command:

sudo /etc/init.d/confluence start

Open the Confluence log to check that Confluence has started correctly using the command:

sudo less /opt/atlassian/confluence/logs/catalina.out

On your keyboard, press the "Shift" and "f" keys to start monitoring the changes in the Confluence log in real-time.

:::note The message that says "Server startup in 12,548 milliseconds" indicates that Confluence has started successfully. :::

On the keyboard, press the key combination "Ctrl" and "c", then "q" to close the Confluence log.

To continue the Confluence installation process, you need to go from the workstation to the link https://confluence.heyvaldemar.net, where confluence.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name or IP address of your Confluence server.

This guide walks you through installing Confluence for a production environment.

Select "Production Installation" and click on the "Next" button.

Now you need to provide a license key for Confluence.

If you do not already have a license key, you can request a temporary key to try Confluence.

Click on "Get an evaluation license".

Next, click on the "Sign up for an account" button if you do not have an Atlassian account yet.

The next step is to provide: email address, first name, last name, and password to create an Atlassian account.

Click on the "Sign up" button.

:::note You will receive an email to the email address specified during registration. In the letter, you will find a link to complete the registration. :::

If you already have an Atlassian account, enter the email address associated with your Atlassian account in the "Enter email" field and click on the "Continue" button.

Specify the password for the Atlassian account and click on the "Log in" button.

In the next step, you need to specify for which product you need a temporary license key, as well as the name of your organization.

Click on the "Generate License" button to generate a temporary license key for Confluence.

Next, you need to confirm that the temporary license key for Confluence will be installed on your server.

Click on the "Yes" button.

In the "Confluence" field, insert the previously received temporary license key and click on the "Next" button.

Now you need to set up a connection to the previously created database.

Select "My own database" and click on the "Next" button.

Now you need to specify the system for database management and the previously created database that will be used to run Confluence.

In the "Database type" field, select "PostgreSQL".

In the "Setup type" section, select "Simple".

:::note In this tutorial, the database for Confluence is on the same server as Confluence. :::

In the "Hostname" field, enter "localhost".

In the "Database port" field, specify the value "5432".

This tutorial uses "confluencedb" as the database name for Confluence.

Specify "confluencedb" in the "Database name" field.

This guide uses "confluencedbuser" as the username with database rights for Confluence.

In the "Username" field, specify "confluencedbuser".

In the "Password" field, specify the password assigned to the "confluencedbuser" user.

Click on the "Test connection" button.

The message "Success! Database connected successfully." means that all data was entered correctly.

Click on the "Next" button.

In the next step, you will be able to choose from several options: download demo content, do not download any content and start filling Confluence yourself or restore data from a backup.

This guide walks you through installing Confluence without importing any content.

Click on the "Empty Site" button.

Next, you can configure Confluence user management using Jira.

This tutorial walks you through installing Confluence without Jira's user management capabilities.

Click on the "Manage users and groups within Confluence" button.

In the next step, you need to provide: username, name, email address, and password to create a Confluence administrator account.

Click on the "Next" button.

Everything is ready to use Confluence.

Click on the "Start" button.

Now you can create the first space, for example, for the development team, where they will work on their projects.

Specify a name for the first space and click on the "Continue" button.

Next, the editor will open, in which you can create the first page in the new space.

Click on the "Skip tutorial" button.

We fill the page with useful content so that we can later publish it in a new space.

Click on the "Publish" button.

The first page in the developer space has been successfully completed.

:::note You can restrict access for users, both to space and to certain pages within it. :::

Install Foreman on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Tue, 20 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Foreman on Ubuntu Server.

Foreman is open-source software for deploying, configuring and monitoring physical and virtual servers. Foreman can integrate with Ansible, Puppet, Chef, Salt and other configuration management software products.

:::tip[Architecture Context] Choose self-hosted Foreman when you need a unified provisioning and configuration management dashboard for bare-metal and virtual infrastructure. Ansible Automation Platform (Tower) or Spacelift provide managed alternatives with better cloud-native integration. Self-hosting Foreman is justified when you manage physical servers, need PXE boot provisioning, or require a single pane of glass across Puppet, Ansible, and Salt. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - for the configuration deployment service.
TCP port 443 - to access the Foreman control panel.
TCP port 8140 - for Puppet Agent to work.
TCP port 5648 - for client and Smart Proxy operation.
TCP port 9090 - for communication with Smart Proxy.

:::

We connect to the server on which you plan to install Foreman.

Let's name the server using the command:

sudo hostnamectl set-hostname foreman.heyvaldemar.net

This tutorial uses foreman.heyvaldemar.net as the Foreman server name.

The server with the agent installed must resolve the name of the Foreman server, and also the Foreman server must resolve the name of the client-server.

Make sure the server name has the correct DNS entry and also update the "/etc/hosts" file on the server with the command:

echo "10.170.18.186 foreman.heyvaldemar.net puppet.heyvaldemar.net foreman puppet" | sudo tee -a /etc/hosts

This tutorial uses foreman.heyvaldemar.net as the Foreman server name.

Restart the hostamed service for the changes to the server name to take effect using the command:

sudo systemctl restart systemd-hostnamed

Let's check the correctness of the server name using the command:

hostname

Now let's replace the current shell process with a new one using the command:

exec bash

Now you need to download and install the Puppet Server repository configuration package.

Download the Puppet Server repository configuration package using the command:

wget https://apt.puppetlabs.com/puppet6-release-bionic.deb

Install the Puppet Server repository configuration package using the command:

sudo dpkg -i puppet6-release-bionic.deb

Next, we connect the Foreman repository using the command:

echo "deb http://deb.theforeman.org/ bionic 2.4" | sudo tee /etc/apt/sources.list.d/foreman.list

Next, connect the Foreman plugin repository using the command:

echo "deb http://deb.theforeman.org/ plugins 2.4" | sudo tee -a /etc/apt/sources.list.d/foreman.list

Now let's add the official Foreman key using the command:

wget -q https://deb.theforeman.org/pubkey.gpg -O- | sudo apt-key add -

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install Foreman Installer using the command:

sudo apt -y install foreman-installer

Now install Foreman using the command:

sudo foreman-installer

In the next step, you will receive the username and password of an account with Foreman administrator rights.

Save this data in a safe place.

Puppet binaries are located in the "/opt/puppetlabs/bin/" directory, which is not in the "PATH" environment variable by default and in the "secure_path" variable that is used for "sudo" operations.

:::note The path to the executable files is irrelevant for the Puppet services since the start of the services does not depend on the "PATH" and "secure_path". :::

By adding the path to executable files to variables, you can use:

sudo puppet agent -t

Instead:

sudo /opt/puppetlabs/bin/puppet agent -t

Add the path to the Puppet executable files to the "secure_path" variable.

Open the "sudoers" configuration file in a text editor using the command:

sudo visudo

Find the variable "secure_path", and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

To save the changes in the "sudoers" file, press "Ctrl + x".

Now you need to confirm the changes in the file.

Click on the "y" button.

Press the "Enter" button to confirm saving the file.

Now let's add the path to the Puppet executables to the "PATH" environment variable.

Open the "environment" configuration file in a text editor using the command:

sudo vim /etc/environment

Press the "i" button to enter edit mode, and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

You can now install the NTP module to help you install, configure, and manage the NTP service on client operating systems.

Install the NTP module using the command:

sudo puppet module install puppetlabs-ntp -i /etc/puppetlabs/code/modules/

Now you need to import the NTP module into your Foreman control panel.

From the workstation, go to the link https://foreman.heyvaldemar.net, where foreman.heyvaldemar.net is the name of my subdomain to access the Foreman control panel. You will need to specify your domain or subdomain through which your Foreman control panel will be accessible from the Internet.

This guide uses Mozilla Firefox as the web browser to connect to the Foreman Control Panel.

In the next step, you can see the warning "Warning: Potential Security Risk Ahead".

Click on the "Advanced" button.

Next, click on the "Accept the Risk and Continue" button.

Default login for Foreman administrator account: admin

:::note The password for the administrator account was generated after the Foreman installation was completed. :::

Specify the username and password of an account with Foreman administrator rights, and click on the "Log in" button.

From the menu on the left, select "Configure", then "Classes".

Next, click on the button "Import environments from foreman.heyvaldemar.net.

This tutorial uses foreman.heyvaldemar.net as the Foreman server name.

Select the environment for which you want to import the module, and click on the "Update" button.

The module has been successfully imported into the selected environment.

Next, we connect to the server on which you plan to install Puppet Agent.

Let's name the server using the command:

sudo hostnamectl set-hostname puppet-agent.heyvaldemar.net

This tutorial uses puppet-agent.heyvaldemar.net as the name of the server with the Puppet agent installed.

The server with the agent installed must resolve the name of the Foreman server, and also the Foreman server must resolve the name of the client-server.

Make sure the server name has the correct DNS entry and also update the "/etc/hosts" file with the IP address and client-server name using the command:

echo "10.170.18.152 puppet-agent.heyvaldemar.net puppet-agent" | sudo tee -a /etc/hosts

This tutorial uses puppet-agent.heyvaldemar.net as the name of the server with the Puppet agent installed.

Next, add the IP address and name of the Foreman server to the "/etc/ hosts" file using the command:

echo "10.170.18.186 foreman.heyvaldemar.net puppet.heyvaldemar.net foreman puppet" | sudo tee -a /etc/hosts

The presence of this record will allow the server with the agent installed to resolve the Foreman server name even without a DNS record.

Restart the hostamed service for the changes to the server name to take effect using the command:

sudo systemctl restart systemd-hostnamed

Let's check the correctness of the server name using the command:

hostname

Now let's replace the current shell process with a new one using the command:

exec bash

Now you need to download and install the Puppet Agent repository configuration package.

Download the Puppet Agent repository configuration package using the command:

wget https://apt.puppetlabs.com/puppet6-release-bionic.deb

Install the Puppet Agent repository configuration package using the command:

sudo dpkg -i puppet6-release-bionic.deb

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install Puppet Agent using the command:

sudo apt install -y puppet-agent

Puppet binaries are located in the "/opt/puppetlabs/bin/" directory, which is not in the "PATH" environment variable by default and in the "secure_path" variable that is used for "sudo" operations.

:::note The path to the executable files is irrelevant for the Puppet services since the start of the services does not depend on the "PATH" and "secure_path". :::

By adding the path to executable files to variables, you can use:

sudo puppet agent -t

Instead:

sudo /opt/puppetlabs/bin/puppet agent -t

Add the path to the Puppet executable files to the "secure_path" variable.

Open the "sudoers" configuration file in a text editor using the command:

sudo visudo

Find the variable "secure_path", and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

Now you need to confirm the changes in the file.

Click on the "y" button.

Press the "Enter" button to confirm saving the file.

Now let's add the path to the Puppet executables to the "PATH" environment variable.

Open the "environment" configuration file in a text editor using the command:

sudo vim /etc/environment

Press the "i" button to enter edit mode, and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Next, you need to make changes to the Puppet configuration file by opening it in a text editor using the command:

sudo vim /etc/puppetlabs/puppet/puppet.conf

Press the "i" button to switch to edit mode, add a new section [main] with the following parameters:

[main]
certname    = puppet-agent.heyvaldemar.net
server      = foreman.heyvaldemar.net
environment = production
runinterval = 15m

:::note In this tutorial, Puppet Agent is installed on the puppet-agent.heyvaldemar.net server. You will need to specify your server through which your Puppet Agent will be accessible from the Internet or on the local network of your organization. :::

Foreman is also installed on the foreman.heyvaldemar.net server. You will need to specify your server through which your Foreman will be accessible from the Internet or from the local network of your organization.

:::note The "runinterval" parameter specifies the time interval between agent requests to the Foreman server. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Launch Puppet Agent and enable it to autostart when the operating system starts up using the command:

sudo puppet resource service puppet ensure=running enable=true

Now you need to approve the certificate request for the server on which the Puppet Agent is installed so that the client can subsequently receive the configuration from the Foreman server.

Return to the Foreman control panel and select "Infrastructure" from the menu on the left, then "Smart Proxies".

Next, find the Foreman server, and in the "Actions" section, in the drop-down list, select "Certificates".

This tutorial uses foreman.heyvaldemar.net as the Foreman server name.

Now we find the client-server and in the "Actions" section, select "Sign".

This tutorial uses puppet-agent.heyvaldemar.net as the name of the server with the Puppet agent installed.

The certificate for the client-server has been successfully approved.

You can now configure automatic certificate approval.

Go to the "Autosign entries" section and click on the "Create Autosign Entry" button.

Next, you can specify the domain for which Foreman will automatically approve certificates.

:::note You must specify * Before the domain, so that all members of the specified domain will automatically approve certificates. :::

Click on the "Save" button.

Automatic certificate approval is configured.

We return to the server with the Puppet Agent installed.

Now you need to get the configuration for the client from the Puppet server using the command:

sudo puppet agent -t

The configuration for the client from the Foreman server was successfully received.

Install Zabbix on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Tue, 20 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Zabbix on Ubuntu Server.

Zabbix is an open-source, enterprise-class distributed monitoring solution.

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to get a free cryptographic certificate through Let's Encrypt CA.
TCP port 443 - to access the Zabbix frontend.
TCP port 10050 - for Zabbix Agent to work.
TCP port 10051 - for Zabbix Trapper to work.

:::

We connect to the server on which you plan to install Zabbix.

Now you need to download and install the Zabbix repository configuration package.

Download the Zabbix repository configuration package using the command:

wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.4-1+ubuntu22.04_all.deb

Install the Zabbix repository configuration package using the command:

sudo dpkg -i zabbix-release_6.4-1+ubuntu22.04_all.deb

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for Multicraft to work using the command:

sudo apt install -y apache2 apt-transport-https certbot python3-certbot-apache mysql-server zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent

:::note In this tutorial, MySQL will be used as a database management system, and Apache will be used as a webserver. :::

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::

Now you need to create a virtual host file (called a block in Nginx), with which Zabbix will work in the future.

Let's create a virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/zabbix.heyvaldemar.net.conf

:::note In this tutorial, the zabbix.heyvaldemar.net subdomain will be used to access the Zabbix control panel from the Internet. You will need to specify your domain or subdomain by which your Zabbix will be accessible from the Internet. :::

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName zabbix.heyvaldemar.net
	DocumentRoot /usr/share/zabbix
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

:::note In this tutorial, the zabbix.heyvaldemar.net subdomain will be used to access Zabbix from the Internet. You will need to specify your domain or subdomain by which your Zabbix will be accessible from the Internet. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

We activate the created virtual host using the command:

sudo a2ensite zabbix.heyvaldemar.net.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes made using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Now, to increase the security level of the webserver, you need to obtain a cryptographic certificate for the domain or subdomain through which your Zabbix will be accessible from the Internet.

Request a cryptographic certificate using the command:

sudo certbot --apache -d zabbix.heyvaldemar.net

Next, we indicate the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose whether you would like to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "2", then "Enter".

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now let's configure MySQL for further work with Zabbix.

First, you need to run the "mysql_secure_installation" script, which is designed to provide a basic level of MySQL security.

Run the script using the command:

sudo mysql_secure_installation

Next, you need to answer a few questions to ensure a basic level of MySQL security.

The first question is whether you want to use the password strength plugin, which will need to be set later for the "root" user who has administrator rights in MySQL.

Press the "y" button, then "Enter".

The next step is to select the level of password complexity checking, which will need to be set later for the "root" user who has administrator rights in MySQL.

:::note In this tutorial, we will look at the highest level of password strength checking for the "root" user. :::

Press the button "2", then "Enter".

The next step is to provide a strong password for the "root" user who has administrator rights in MySQL.

Specify a strong password for the "root" user and press the "Enter" button.

Next, specify the password for the "root" user again and press the "Enter" button.

The next question is if you would like to proceed to the next step in setting up a basic MySQL security level with the obtained password strength value.

:::note If the password you specified will have a value of "Estimated strength of the password" less than 100, it means that the password you specified earlier for the "root" user is not strong enough, and you need to specify a stronger password. :::

:::note In this tutorial, the "Estimated strength of the password" value is 100, which indicates that the previously specified password is strong enough. :::

Press the "y" button, then "Enter".

The next question is if you want to delete anonymous users.

Press the "y" button, then "Enter".

The next question is if you want to disable remote MySQL connectivity for the "root" user.

Press the "y" button, then "Enter".

The next question is if you want to drop the test databases.

Press the "y" button, then "Enter".

Now you need to apply the changes you made.

Press the "y" button, then "Enter".

Now you need to create a database that Zabbix will use in the future, as well as a user with the necessary rights to this database.

We connect to the MySQL management console using the command:

sudo mysql -u root -p

Specify the password for the "root" account, set it earlier, and press the "Enter" button.

:::note This tutorial will use "zabbixdb" as the database name for Zabbix. :::

Let's create a database that Zabbix will use in the future using the command:

CREATE DATABASE zabbixdb CHARACTER SET utf8 COLLATE utf8mb4_bin;

:::note In this tutorial, "zabbixdbuser" with the password "c@e3wY88nx63c^4w^43r" will be used as the username with database rights to run Zabbix. :::

Create a user and assign a password to it using the command:

CREATE USER 'zabbixdbuser'@'localhost' IDENTIFIED BY 'c@e3wY88nx63c^4w^43r';

We grant the new user rights to the previously created database using the command:

GRANT ALL ON zabbixdb.* TO 'zabbixdbuser'@'localhost';

Apply the changes made using the command:

FLUSH PRIVILEGES;

Disconnect from the MySQL Management Console using the command:

quit

Now you need to configure the schema and import the data into the previously created database for Zabbix to work.

This tutorial uses "zabbixdb" as the database name for the Zabbix operation.

:::note In this tutorial, "zabbixdbuser" is used as the username with database rights to run Zabbix. :::

Let's configure the schema and import the data into the previously created database using the command:

zcat /usr/share/doc/zabbix-server-mysql/create.sql.gz | mysql --default-character-set=utf8mb4 -u zabbixdbuser -p zabbixdb

Specify the password for the "zabbixdbuser" account specified earlier and press the "Enter" button.

Now you need to make changes to the Zabbix configuration file by opening it in a text editor using the command:

sudo vim /etc/zabbix/zabbix_server.conf

:::note In this tutorial, the database for Zabbix to work is on the same server as Zabbix. :::

Press the "i" button to switch to edit mode, find the "DBHost" parameter and uncomment it by removing the "#" symbol. Then we specify the value "localhost" for the parameter.

This tutorial uses "zabbixdb" as the database name for Zabbix operation.

Find the "DBName" parameter and specify the value "zabbixdb" for the parameter.

:::note In this tutorial, "zabbixdbuser" is used as the username with database rights to run Zabbix. :::

Find the "DBUser" parameter and specify the value "zabbixdbuser" for the parameter.

Find the "DBPassword" parameter and uncomment it by removing the "#" symbol. Then, as the value for the parameter, we specify the password assigned to the "zabbixdbuser" user.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now you need to make changes to the Apache configuration file by opening it in a text editor using the command:

sudo vim /etc/zabbix/apache.conf

Next, find the "php_value date.timezone Europe/Riga" parameter in the "IfModule mod_php7.c" section and uncomment it by removing the "#" symbol. Then we indicate instead of "Europe/Riga", the time zone in which your Zabbix server is located.

You can view the full list of supported time zones in the official PHP documentation.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Restart Zabbix, Zabbix Agent, and Apache to apply the changes, using the command:

sudo systemctl restart zabbix-server zabbix-agent apache2

Check that Zabbix has started successfully using the command:

sudo systemctl status zabbix-server

Check that Zabbix Agent has started successfully using the command:

sudo systemctl status zabbix-agent

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Enable autorun of Zabbix, Zabbix Agent, and Apache when starting the operating system using the command:

sudo systemctl enable zabbix-server zabbix-agent apache2

To continue the Zabbix installation process, you need to go from the workstation to the link https://zabbix.heyvaldemar.net/setup.php, where zabbix.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name or IP address of your Zabbix server.

Click on the "Next step" button.

Next, the installer will check that all the requirements for the correct installation of Zabbix are met.

Click on the "Next step" button.

Now you need to specify the system for managing the databases and the previously created database that will be used to run Zabbix.

In the "Database type" field, select "MySQL".

:::note In this tutorial, the database for Zabbix to work is on the same server as Zabbix. :::

In the "Database host" field, specify "localhost".

In the "Database port" field, specify the value "0" to use the default port for connecting the database.

This tutorial uses "zabbixdb" as the database name for the Zabbix operation.

In the "Database name" field, specify "zabbixdb".

:::note In this tutorial, "zabbixdbuser" is used as the username with database rights to run Zabbix. :::

In the "User" field, specify "zabbixdbuser".

In the "Password" field, specify the password assigned to the "zabbixdbuser" user.

Click on the "Next step" button.

Next, you need to specify information about your Zabbix server.

In the "Host" field, specify "localhost".

In the "Port" field, enter "10051".

Click on the "Next step" button.

We check that the time zone is set correctly and click on the "Next step" button.

Then click on the "Next step" button to save the changes.

Everything is ready to use Zabbix.

Click on the "Finish" button.

Now you can log into the Zabbix dashboard as a Zabbix administrator.

The default password for Zabbix administrator account: zabbix

Specify the username and password of an account with Zabbix administrator rights and click on the "Sign in" button.

Welcome to the Zabbix dashboard.

Install PuppetDB on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Mon, 19 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing PuppetDB on Ubuntu Server.

PuppetDB is a scalable and reliable data store for Puppet. PuppetDB collects data generated by Puppet and also provides advanced functionality based on a powerful API.

:::tip[Architecture Context] PuppetDB stores node facts, catalogs, and reports for querying and reporting across your Puppet infrastructure. At scale, evaluate whether the Puppet pull model with PuppetDB provides better state enforcement than Ansible's agentless push model. PuppetDB is essential when you need real-time infrastructure queries, exported resources, or compliance reporting across large fleets. :::

:::important The Puppet Server must be installed on the server.

For step-by-step instructions on installing Puppet on Ubuntu Server, see Install Puppet на Ubuntu Server. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 8081 - for Puppet Agent to work.

:::

This tutorial uses puppet.heyvaldemar.net as the Puppet server name.

The server with the agent installed must resolve the Puppet server name not only by the base name puppet.heyvaldemar.net but also by the name puppetdb.heyvaldemar.net. Also, the Puppet server has to resolve the name of the client-server.

Make sure the Puppet server and client-server have the correct DNS records and update the "/etc/hosts" file if necessary.

Puppet binaries are located in the "/opt/puppetlabs/bin/" directory, which is not in the "PATH" environment variable by default and in the "secure_path" variable that is used for "sudo" operations.

By adding the path to executable files to variables, you can use:

sudo puppet agent -t

Instead:

sudo /opt/puppetlabs/bin/puppet agent -t

You can learn how to properly prepare the Puppet server to install PuppetDB and add the path to the Puppet executables to variables by reading Install Puppet on Ubuntu Server.

We connect to the Puppet server on which you plan to install PuppetDB.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install PostgreSQL using the command:

sudo apt install -y postgresql

:::note This tutorial will use PostgreSQL as a database management system. :::

Now you need to create a database that PuppetDB will use in the future, as well as a user with the necessary rights in this database.

Switch to the "postgres" user who has administrator rights in PostgreSQL using the command:

sudo su - postgres

We create a new user using the command:

createuser -DRSP puppetdb

:::note In this tutorial, "puppetdb" will be used as the username, with the password sqhrgX8G*RCaYURftzoG89b. :::

Specify a strong password for the new user and press the "Enter" button.

Enter the password again and press the "Enter" button.

We create a new database and grant the rights to it to the previously created user using the command:

createdb -E UTF8 -O puppetdb puppetdb

Next, you need to install the "pg_trgm" index extension optimized for RegExp using the command:

psql puppetdb -c 'create extension pg_trgm'

Log out as user "postgres" using the command:

exit

Now install PuppetDB using the command:

sudo puppet resource package puppetdb ensure=latest

Next, install additional Ruby plugins to use PuppetDB using the command:

sudo puppet resource package puppetdb-termini ensure=latest

Now you need to make changes to the PuppetDB configuration file by opening it in a text editor using the command:

sudo vim /etc/puppetlabs/puppetdb/conf.d/database.ini

:::note In this tutorial, the database for PuppetDB is on the same server as Puppet. :::

Press the "i" button to switch to edit mode, find the "subname" parameter and uncomment it by removing the "#" symbol.

This tutorial uses "puppetdb" as the database name for PuppetDB.

Next, add new parameters "classname" and "subprotocol" with the following values:

classname    = org.postgresql.Driver
subprotocol  = postgresql

This tutorial uses "puppetdb" as the database username for PuppetDB.

Find the "username" parameter and uncomment it by removing the "#" symbol. Then we set the parameter to "puppetdb".

Find the "password" parameter and uncomment it by removing the "#" symbol. Then, as a value for the parameter, specify the password assigned to the "puppetdb" user.

Next, add a new parameter "log-slow-statements" with the following value:

log-slow-statements = 10

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Check that the certificates that will be used by PuppetDB are generated and the configuration file "jetty.ini" contains the correct values using the command:

sudo puppetdb ssl-setup

Next, you need to create a configuration file for PuppetDB to work correctly using the command:

sudo vim /etc/puppetlabs/puppet/puppetdb.conf

Press the "i" button to switch to edit mode, and add a new section [main] with the following parameters:

[main]
server_urls = https://puppet.heyvaldemar.net:8081

:::note In this tutorial, the Puppet Server is installed on the puppet.heyvaldemar.net server. You will need to specify your server through which your Puppet Server will be accessible from the Internet or on the local network of your organization. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

By default, PuppetDB JVM is configured to use 192 MB of RAM. This value can be changed in the PuppetDB config file by opening it in a text editor using the command:

sudo vim /etc/default/puppetdb

Hit the "i" button to go into edit mode, find the line JAVA_ARGS="-Xmx192m" and change the Xmx parameter in accordance with the requirements for your PuppetDB server.

:::note In this tutorial the Xmx parameter will be 256 MB. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Next, you need to make changes to the Puppet configuration file by opening it in a text editor using the command:

sudo vim /etc/puppetlabs/puppet/puppet.conf

Hit the "i" button to go into edit mode, find the [master] section, and add new parameters for PuppetDB to work correctly:

[master]
storeconfigs         = true
storeconfigs_backend = puppetdb
reports              = store,puppetdb
reportstore          = /var/log/puppetlabs/puppet

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now let's create a configuration file "routes.yaml" so that information from PuppetDB can be used in Puppet using the command:

sudo vim /etc/puppetlabs/puppet/routes.yaml

Hit the "i" button to go into edit mode, then insert the following configuration:

[master]
facts_terminus = puppetdb
facts_cache    = yaml

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Assign the correct permissions to files and directories for Puppet to work correctly using the command:

sudo chown -R puppet:puppet `sudo puppet config print confdir`

Launch PuppetDB and enable it to autostart when the operating system starts up using the command:

sudo puppet resource service puppetdb ensure=running enable=true

Restart Puppet Server to apply the changes made using the command:

sudo systemctl restart puppetserver

Check that Puppet Server has started successfully using the command:

sudo systemctl status puppetserver

Next, we connect to the server on which the Puppet Agent is installed.

Now you need to make changes to the Puppet configuration file by opening it in a text editor using the command:

sudo vim /etc/puppetlabs/puppet/puppet.conf

Press the "i" button to switch to edit mode and add a new [agent] section with the following parameters:

[agent]
report     = true
pluginsync = true

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Restart Puppet to apply the changes, using the command:

sudo systemctl restart puppet

Let's check that Puppet has started successfully using the command:

sudo systemctl status puppet

Now you need to check that the Puppet Agent will receive the configuration from the Puppet server and correctly connect to PuppetDB using the command:

sudo puppet agent -t

The Puppet Agent ran without errors and successfully received the configuration from the Puppet server and also successfully connected to PuppetDB.

Now you can check that PuppetDB is actually receiving data from the client-server.

We return to the server with Puppet Server and PuppetDB installed.

Open the Puppet Server log to check the correctness of Puppet and PuppetDB using the command:

sudo less /var/log/puppetlabs/puppetserver/puppetserver.log

On the keyboard, press the "Shift" and "f" keys to start monitoring changes in the Puppet log in real-time.

The Puppet log should show a record that the information has been sent and saved.

:::note In this tutorial Puppet Agent is installed on the puppet-agent.heyvaldemar.net server. :::

On the keyboard, press the key combination "Ctrl" and "c", then "q" to close the Puppet log.

Next, open the PuppetDB log to check the correctness of Puppet and PuppetDB using the command:

sudo less /var/log/puppetlabs/puppetdb/puppetdb.log

On the keyboard, press the key combination "Shift" and "f" to start monitoring changes in the PuppetDB log in real-time.

The PuppetDB log should show a record that the information has been sent and saved.

:::note In this tutorial Puppet Agent is installed on the puppet-agent.heyvaldemar.net server. :::

On the keyboard, press the key combination "Ctrl" and "c", then "q" to close the PuppetDB log.

Now you can verify that the data from the client-server has been successfully transferred to the "puppetdb" database.

This tutorial uses "puppetdb" as the database username for PuppetDB.

This tutorial uses "puppetdb" as the database name for PuppetDB.

Connect to the "puppetdb" database using the command:

psql -h localhost puppetdb puppetdb

Specify the password assigned to the user "puppetdb" and press the "Enter" button.

Turn on the expanded table output mode using the command:

\x

Let's extract data from the "catalogs" table to make sure that information about the client-server is present in the table using the command:

select * from catalogs;

The client-server information is indeed present in the database.

Install Puppet on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Sun, 18 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Puppet on Ubuntu Server.

Puppet is a cross-platform client-server application that allows you to centrally manage the configuration of operating systems and programs installed on multiple computers.

:::tip[Architecture Context] Choose self-hosted Puppet when you need declarative configuration management with drift detection and enforcement across a large server fleet. Puppet Enterprise Cloud or Ansible provide managed alternatives with lower learning curves. Self-hosted Puppet is justified when you manage hundreds of nodes requiring consistent state enforcement, or when your team already has Puppet module expertise. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 8140 - for Puppet Agent to work.

:::

We connect to the server on which you plan to install Puppet Server.

Let's name the server using the command:

sudo hostnamectl set-hostname puppet.heyvaldemar.net

This tutorial uses puppet.heyvaldemar.net as the Puppet server name.

The server with the agent installed must resolve the name of the Puppet server and also the Puppet server must resolve the name of the client-server.

Make sure the server name has the correct DNS entry and also update the "/etc/hosts" file on the server with the command:

echo "10.170.19.82 puppet.heyvaldemar.net puppetdb.heyvaldemar.net puppet puppetdb" | sudo tee -a /etc/hosts

This tutorial uses puppet.heyvaldemar.net as the Puppet server name.

:::note The entry puppetdb.heyvaldemar.net is useful if you plan to install PuppetDB in the future. This name must also have a valid DNS record. :::

You can find out how to install PuppetDB on Ubuntu Server by reading Install PuppetDB on Ubuntu Server.

Restart the hostamed service for the changes to the server name to take effect using the command:

sudo systemctl restart systemd-hostnamed

Let's check the correctness of the server name using the command:

hostname

Now let's replace the current shell process with a new one using the command:

exec bash

The correct time must be set on the Puppet server, as it will act as a CA for signing certificates from clients.

To set the time correctly, you will need to install the NTP package and synchronize the time with the upstream NTP servers.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Install NTP and ntpdate using the command:

sudo apt install -y ntp ntpdate

:::note ntpdate allows you to manually check the configuration of your connection to the NTP server. :::

Synchronize time with upstream NTP servers using the command:

sudo ntpdate -u 0.ubuntu.pool.ntp.org

Let's check the correctness of the date and time on the server using the command:

date

:::note This tutorial is based on a server located in Berlin. :::

Let's see a list of time zone values for all locations using the command:

sudo timedatectl list-timezones

We select the value suitable for your location and change the time zone using the command:

sudo timedatectl set-timezone Europe/Berlin

:::note This tutorial is based on a server located in Berlin. :::

We again check the correctness of the date and time on the server using the command:

date

Now you need to download and install the Puppet Server repository configuration package.

Download the Puppet Server repository configuration package using the command:

wget https://apt.puppetlabs.com/puppet7-release-jammy.deb

Install the Puppet Server repository configuration package using the command:

sudo dpkg -i puppet7-release-jammy.deb

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install Puppet Server using the command:

sudo apt install -y puppetserver

Puppet binaries are located in the "/opt/puppetlabs/bin/" directory, which is not in the "PATH" environment variable by default and in the "secure_path" variable that is used for "sudo" operations.

:::note The path to the executable files is irrelevant for the Puppet services since the start of the services does not depend on the "PATH" and "secure_path". :::

By adding the path to executable files to variables, you can use:

sudo puppet agent -t

Instead:

sudo /opt/puppetlabs/bin/puppet agent -t

Add the path to the Puppet executable files to the "secure_path" variable.

Open the "sudoers" configuration file in a text editor using the command:

sudo visudo

Find the variable "secure_path", and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

To save the changes in the "sudoers" file, press "Ctrl + x".

Now you need to confirm the changes in the file.

Click on the "y" button.

Press the "Enter" button to confirm saving the file.

Now let's add the path to the Puppet executables to the "PATH" environment variable.

Open the "environment" configuration file in a text editor using the command:

sudo vim /etc/environment

Press the "i" button to enter edit mode, and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

By default, the Puppet Server JVM is configured to use 2 GB of RAM. This value can be changed in the Puppet config file by opening it in a text editor using the command:

sudo vim /etc/default/puppetserver

Press the "i" button to enter edit mode, find the line JAVA_ARGS="-Xms2g -Xmx2g -Djruby.logger.class=com.puppetlabs.jruby_utils.jruby.Slf4jLogger" and change the Xms parameters and Xmx according to your Puppet server requirements.

:::note In this manual the Xms and Xmx parameters will be set to 1 GB. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Next, you need to make changes to another Puppet configuration file by opening it in a text editor using the command:

sudo vim /etc/puppetlabs/puppet/puppet.conf

Hit the "i" button to go into edit mode, find the [master] section and add a new line with the alternative names of the Puppet server:

dns_alt_names = puppet,puppetdb,puppet.heyvaldemar.net,puppetdb.heyvaldemar.net

Next, add a new section [main] with the following parameters:

[main]
certname    = puppet.heyvaldemar.net
server      = puppet.heyvaldemar.net
environment = production
runinterval = 15m

:::note The entries puppetdb and puppetdb.heyvaldemar.net will come in handy if you plan to install PuppetDB in the future. This name must also have a valid DNS record. :::

You can find out how to install PuppetDB on Ubuntu Server by reading Install PuppetDB on Ubuntu Server.

:::note The "runinterval" parameter specifies the time interval between agent requests to the Puppet server. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now let's create the root and intermediate CA signature for Puppet Server using the command:

sudo puppetserver ca setup

We start Puppet Server using the command:

sudo systemctl start puppetserver

Check that Puppet Server has started successfully using the command:

sudo systemctl status puppetserver

We enable Puppet Server autorun when starting the operating system using the command:

sudo systemctl enable puppetserver

Next, we connect to the server on which you plan to install Puppet Agent.

Let's name the server using the command:

sudo hostnamectl set-hostname puppet-agent.heyvaldemar.net

This tutorial uses puppet-agent.heyvaldemar.net as the name of the server with the Puppet agent installed.

The server with the agent installed must resolve the name of the Puppet server and also the Puppet server must resolve the name of the client-server.

Make sure the server name has the correct DNS entry and also update the "/etc/hosts" file with the IP address and client-server name using the command:

echo "10.170.19.3 puppet-agent.heyvaldemar.net puppet-agent" | sudo tee -a /etc/hosts

This tutorial uses puppet-agent.heyvaldemar.net as the name of the server with the Puppet agent installed.

Next, add the IP address and the name of the Puppet server to the "/etc/hosts" file using the command:

echo "10.170.19.82 puppet.heyvaldemar.net puppetdb.heyvaldemar.net puppet puppetdb" | sudo tee -a /etc/hosts

Having this record will allow the server with the agent installed to resolve the Puppet server name even without a DNS record.

:::note The entry puppetdb.heyvaldemar.net is useful if you plan to install PuppetDB in the future. This name must also have a valid DNS record. :::

You can find out how to install PuppetDB on Ubuntu Server by reading Install PuppetDB on Ubuntu Server.

Restart the hostamed service for the changes to the server name to take effect using the command:

sudo systemctl restart systemd-hostnamed

Let's check the correctness of the server name using the command:

hostname

Now let's replace the current shell process with a new one using the command:

exec bash

The correct time must be set on the server with Puppet Agent.

To set the time correctly, you will need to install the NTP package and synchronize the time with the upstream NTP servers.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Install NTP and ntpdate using the command:

sudo apt install -y ntp ntpdate

:::note ntpdate allows you to manually check the configuration of your connection to the NTP server. :::

Synchronize time with upstream NTP servers using the command:

sudo ntpdate -u 0.ubuntu.pool.ntp.org

Let's check the correctness of the date and time on the server using the command:

date

:::note This tutorial is based on a server located in Berlin. :::

Let's see a list of time zone values for all locations using the command:

sudo timedatectl list-timezones

We select the value suitable for your location and change the time zone using the command:

sudo timedatectl set-timezone Europe/Berlin

:::note This tutorial is based on a server located in Berlin. :::

We again check the correctness of the date and time on the server using the command:

date

Now you need to download and install the Puppet Agent repository configuration package.

Download the Puppet Agent repository configuration package using the command:

wget https://apt.puppetlabs.com/puppet7-release-jammy.deb

Install the Puppet Agent repository configuration package using the command:

sudo dpkg -i puppet7-release-jammy.deb

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now install Puppet Agent using the command:

sudo apt install -y puppet-agent

Puppet binaries are located in the "/opt/puppetlabs/bin/" directory, which is not in the "PATH" environment variable by default and in the "secure_path" variable that is used for "sudo" operations.

:::note The path to the executable files is irrelevant for the Puppet services, since the start of the services does not depend on the "PATH" and "secure_path". :::

By adding the path to executable files to variables, you can use:

sudo puppet agent -t

Instead:

sudo /opt/puppetlabs/bin/puppet agent -t

Add the path to the Puppet executable files to the "secure_path" variable.

Open the "sudoers" configuration file in a text editor using the command:

sudo visudo

Find the variable "secure_path", and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

Now you need to confirm the changes in the file.

Click on the "y" button.

Press the "Enter" button to confirm saving the file.

Now let's add the path to the Puppet executables to the "PATH" environment variable.

Open the "environment" configuration file in a text editor using the command:

sudo vim /etc/environment

Press the "i" button to enter edit mode, and at the end of the line, before the closing quote, add the path to the Puppet executable files :/opt/puppetlabs/bin.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Next, you need to make changes to the Puppet configuration file by opening it in a text editor using the command:

sudo vim /etc/puppetlabs/puppet/puppet.conf

Press the "i" button to switch to edit mode, add a new section [main] with the following parameters:

[main]
certname    = puppet-agent.heyvaldemar.net
server      = puppet.heyvaldemar.net
environment = production
runinterval = 15m

Also, the Puppet Server is installed on the puppet.heyvaldemar.net server. You will need to specify your server through which your Puppet Server will be accessible from the Internet or on the local network of your organization. :::

:::note The "runinterval" parameter specifies the time interval between agent requests to the Puppet server. :::

Now press the "Esc" button to exit edit mode, and then type ": x" and press the "Enter" button to save your changes and exit the editor.

Launch Puppet Agent and enable it to autostart when the operating system starts up using the command:

sudo puppet resource service puppet ensure=running enable=true

We return to the server with Puppet Server installed.

Now you need to approve the certificate request for the server on which the Puppet Agent is installed so that later the client can receive the configuration from the Puppet server.

Let's look at the client requests in the queue using the command:

sudo puppetserver ca list

We sign the client request using the command:

sudo puppetserver ca sign --certname puppet-agent.heyvaldemar.net

The client request has been successfully signed.

Next, you can view all signed and unsigned client requests using the command:

sudo puppetserver ca list --all

You can sign all client requests in the queue using the command:

sudo puppetserver ca sign --all

You can revoke a client certificate using the command:

sudo puppetserver ca revoke --certname puppet-agent.heyvaldemar.net

Now you can create a manifest to test Puppet's functionality.

A manifest is a data file containing client configuration written in Puppet or Ruby DSL.

Let's create a manifest using the command:

sudo vim /etc/puppetlabs/code/environments/production/manifests/site.pp

Hit the "i" button to go into edit mode, then insert the following configuration:

node 'puppet-agent.heyvaldemar.net' {
  file { '/tmp/puppetfile':
    ensure  => 'present',
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    content => "This File is created by Puppet Server\n",
  }
}

:::note A "puppetfile" file will be created in the "/tmp" directory containing the text "This File is created by Puppet Server". The user "root" will be the owner of the file. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

We return to the server with the Puppet Agent installed.

Now you need to get the configuration for the client from the Puppet server using the command:

sudo puppet agent -t

Next, you can check that the file was successfully created and contains the text specified earlier in the manifest using the command:

cat /tmp/puppetfile

The file was successfully created and contains the text specified in the manifest.

Restore Windows Firewall Defaults

Vladimir Mikhalev (heyvaldemar.com) — Fri, 16 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to restore Windows Firewall defaults.

This guide will cover several ways to restore the default Windows Firewall settings.

We go into the system under an account with administrator rights.

Open Server Manager, click on the "Tools" button in the upper right corner of the screen, and select "Windows Defender Firewall with Advanced Security".

You can now export the current settings from Windows Firewall and, if necessary, return to them after restoring the default settings.

Right-click on "Windows Firewall with Advanced Security on Local Computer" and select "Export Policy".

Assign a name and save the file with Windows Firewall settings.

:::note In this manual, the settings file will be saved in the "Documents" folder. :::

Click on the "Save" button.

Windows Firewall settings exported successfully.

Click on the "OK" button.

Now you can restore the default settings in Windows Firewall.

In the "Actions" section, select "Restore Default Policy".

Next, you need to confirm the restoration of the default settings.

Click on the "Yes" button.

Windows Firewall defaults have been restored successfully.

In addition, you can restore the default settings in Windows Firewall using the command line.

Press "Start", specify "cmd" in the search bar, and select "Command Prompt".

We export the current settings from Windows Firewall to return to them if necessary after restoring the default settings.

:::note In this manual, the configuration file will be saved to the "C" drive. :::

We export the current settings from Windows Firewall using the command:

netsh advfirewall export C:\Firewall-Config.wfw

Now you can restore the default settings in Windows Firewall.

Restore the default settings in Windows Firewall using the command:

netsh advfirewall reset

Windows Firewall defaults have been restored successfully.

You can also restore the default settings in Windows Firewall using Windows PowerShell.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

Restore the default settings in Windows Firewall using the command:

(New-Object -ComObject HNetCfg.FwPolicy2).RestoreLocalFirewallDefaults()

Windows Firewall defaults have been restored successfully.

Install Jenkins on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Sat, 10 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Jenkins on Ubuntu Server.

Jenkins is an open-source Java software system designed to provide a continuous software integration process.

:::tip[Architecture Context] Choose self-hosted Jenkins when you need a fully customizable CI/CD platform with unlimited build minutes and custom plugin requirements. GitHub Actions, GitLab CI, or CircleCI provide managed alternatives with lower operational overhead. Self-hosting Jenkins is justified when build pipelines require on-premises resources, custom hardware, or when SaaS CI minute costs exceed the cost of maintaining your own build infrastructure. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access Jenkins web interface.

:::

We connect to the server on which you plan to install Jenkins.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now we will install the packages required for Jenkins to work using the command:

sudo apt install -y apache2 apt-transport-https certbot python3-certbot-apache openjdk-11-jdk

:::note Supported Java versions can be found in the Jenkins documentation on the requirements page. :::

Many programs written using Java use the "JAVA_HOME" environment variable to determine where Java is installed. Therefore, you need to define this variable and assign it a value containing the path to the Java installation location.

Let's define the path to the Java installation location using the command:

sudo update-alternatives --config java

In this example, the path to the Java installation location looks like this:

/usr/lib/jvm/java-11-openjdk-amd64/bin/

To define an environment variable and assign a value to it, you need to make changes to the "environment" file by opening it in a text editor using the command:

sudo vim /etc/environment

Press the "i" button to switch to edit mode, then at the end of the file define a new variable "JAVA_HOME" and assign it a value containing the path to the Java installation location obtained earlier.

JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64/bin/"

:::note The path to the Java installation location must be specified up to and including the "bin" folder. :::

Now press the "Esc" button to exit edit mode, and then type ":x" and press the "Enter" button to save your changes and exit the editor.

Next, you need to apply the changes made to the current session using the command:

source /etc/environment

Now let's make sure that the environment variable has the correct value using the command:

echo $JAVA_HOME

Based on the message received, the environment variable has the correct value.

Let's configure Apache for further work with the Jenkins dashboard.

We enable the Apache webserver module called "headers" using the command:

sudo a2enmod headers

:::note The "headers" module can be used to add more specific "Cache-Control" parameters. :::

We enable the Apache webserver module called "proxy_http" using the command:

sudo a2enmod proxy_http

:::note The "proxy_http" module acts like a proxy server for the HTTP and HTTPS protocols. :::

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::

Now you need to create two virtual host files (called a block in Nginx), which Jenkins will work with in the future.

Two virtual host files will be required to provide access to Jenkins over HTTPS, as well as to enable Jenkins to be used at https://jenkins.heyvaldemar.net, without specifying port 8080 in the browser address bar.

:::note In this tutorial, you will use the jenkins.heyvaldemar.net subdomain to access Jenkins from the Internet. You will need to specify your domain or subdomain by which your Jenkins will be accessible from the Internet. :::

Let's create the first virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/jenkins.heyvaldemar.net.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName jenkins.heyvaldemar.net
</VirtualHost>

Now press the "Esc" button to exit edit mode, and then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create a second virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/jenkins.heyvaldemar.net-ssl.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerAdmin callvaldemar@gmail.com
	ServerName jenkins.heyvaldemar.net

	ProxyRequests     Off
	ProxyPreserveHost On
	AllowEncodedSlashes NoDecode

	<Proxy *>
		Order deny,allow
		Allow from all
	</Proxy>
	
	ProxyPass         /  http://localhost:8080/ nocanon
	ProxyPassReverse  /  http://localhost:8080/
	ProxyPassReverse  /  http://jenkins.heyvaldemar.net/
	RequestHeader set X-Forwarded-Proto "https"
	RequestHeader set X-Forwarded-Port "443"

	SSLEngine On
	SSLCertificateFile /etc/letsencrypt/live/jenkins.heyvaldemar.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/jenkins.heyvaldemar.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Now press the "Esc" button to exit edit mode, and then type ":x" and press the "Enter" button to save your changes and exit the editor.

We activate the first virtual host using the command:

sudo a2ensite jenkins.heyvaldemar.net.conf

We activate the second virtual host using the command:

sudo a2ensite jenkins.heyvaldemar.net-ssl.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes, using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Now, to increase the security level of the webserver, you need to obtain a cryptographic certificate for the domain or subdomain, through which the Jenkins dashboard will be accessible from the Internet.

Let's request a cryptographic certificate using the command:

sudo certbot --apache -d jenkins.heyvaldemar.net

Next, we specify the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose: do you want to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "2", then "Enter".

:::note Cryptographic certificates obtained through Let's Encrypt CA are valid for ninety days. Certbot automatically adds a script to renew the certificate to the task scheduler, and the script runs twice a day, automatically renewing any cryptographic certificate that expires within thirty days. :::

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now let's add the official Jenkins key using the command:

wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -

Next, we connect the Jenkins repository using the command:

sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install Jenkins using the command:

sudo apt install -y jenkins

Now you need to make changes to the Jenkins configuration file by opening it in a text editor using the command:

sudo vim /etc/default/jenkins

Hit the "i" button to enter edit mode, find the line JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=$HTTP_PORT" and add the parameter --httpListenAddress=127.0.0.1.

Now press the "Esc" button to exit edit mode, and then type ":x" and press the "Enter" button to save your changes and exit the editor.

Restart Jenkins to apply the changes made using the command:

sudo systemctl restart jenkins

Let's check that Jenkins has started successfully using the command:

sudo systemctl status jenkins

Now you need to get the password that you need to unlock Jenkins.

You can get the password using the command:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Save the resulting password as you will need it in the next step.

To continue the Jenkins installation process, you need to go from the workstation to the link https://jenkins.heyvaldemar.net, where jenkins.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name or IP address of your Jenkins server.

Next, you need to provide a password to unlock Jenkins.

In the "Administrator password" field, specify the previously received password to unlock Jenkins and click on the "Continue" button.

Now you can choose which plugins to install for Jenkins.

:::note In this tutorial, we will be looking at installing the suggested plugins for Jenkins. :::

Click on the "Install suggested plugins" button.

The process of installing plugins has begun.

At the next step, you need to specify: login, password, name, and email address to create a Jenkins administrator account.

Click on the "Save and Continue" button.

In the "Jenkins URL" field, specify the domain or subdomain by which your Jenkins is accessible from the Internet.

:::note This tutorial will use the jenkins.heyvaldemar.net subdomain to access Jenkins from the Internet. You will need to specify your domain or subdomain by which your Jenkins will be accessible from the Internet. :::

Click on the "Save and Finish" button.

Jenkins installation completed successfully.

Click on the "Start using Jenkins" button.

Everything is ready to use Jenkins.

Run a Minecraft Server with Multicraft

Vladimir Mikhalev (heyvaldemar.com) — Sat, 10 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to run a Minecraft Server with Multicraft.

:::important Multicraft must be installed on the server, and Spigot must be updated to the latest version.

For detailed instructions on installing Multicraft on Ubuntu Server, see Install Multicraft на Ubuntu Server. :::

:::note For instructions on upgrading Spigot on Ubuntu Server using Multicraft, see my guide: Upgrade Spigot on Ubuntu Server with Multicraft. :::

Open the Multicraft control panel and click on the "Login" button.

Next, you need to specify the username and password of an account with administrator rights in the Multicraft control panel.

Click on the "Login" button.

To create a new server, click on the "Create Server" button on the "Servers" tab.

In the "Name" field, specify the desired name for the new Minecraft server.

In the field "Player Slots" we indicate the maximum number of places for players on the Minecraft server.

In the "Port" field, specify the port for the Minecraft client to access the Minecraft server.

:::warning Port 25565 is used by default to connect a Minecraft client to a Minecraft server, but you can use other ports to run multiple Minecraft servers. For example, the first Minecraft server launched with Multicraft will use port 25581; the second server, launched with Multicraft, will use port 25582, and so on.

In this case, in the Minecraft client, you will need to specify not only the IP address or name of the Minecraft server but also the port through which to connect to the server. For example minecraft.heyvaldemar.net:25581. :::

:::note In this tutorial, the Minecraft server will be started using port 25581. :::

In the "Memory" field, indicate the maximum allowable size of RAM allocated for the Minecraft server.

Click on the "Create" button.

The server has been successfully created.

Now you need to select the JAR file that will be used when starting the Minecraft server.

:::note This tutorial will use Spigot, a modified Minecraft server built on top of the CraftBukkit core. Spigot is known for its stability, performance, support for a large number of plugins and is intended to replace CraftBukkit. :::

:::important Spigot needs to be updated in order for it to start correctly. :::

:::note For instructions on upgrading Spigot on Ubuntu Server using Multicraft, see my guide: Upgrade Spigot on Ubuntu Server with Multicraft. :::

In the "JAR File" field, select "Spigot" and click on the "Save" button.

Next, click on the "Accept EULA" button if you agree with the Minecraft license agreement.

:::note Additional details about the Minecraft license agreement can be found on the official EULA page. :::

Everything is ready to start the Minecraft server.

Click on the "Start" button.

The Minecraft server will start to start.

Next, you need to make sure that the server has started successfully.

Click on the "Console" button in the left menu.

After a few minutes, you should see a "Startup Done" message, which indicates that the Minecraft server is running.

Now, in the Minecraft client, you will need to specify not only the IP address or name of the Minecraft server but also the port through which to connect to the server. For example minecraft.heyvaldemar.net:25581.

Upgrade Spigot on Ubuntu Server with Multicraft

Vladimir Mikhalev (heyvaldemar.com) — Mon, 05 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to upgrade spigot on Ubuntu Server with Multicraft.

Spigot is a modified Minecraft server built on top of the CraftBukkit core. Spigot is known for its stability, performance, support for a large number of plugins and is intended to replace CraftBukkit.

:::important The server must have Multicraft, OpenJDK and Git installed.

You can find out how to install Multicraft on Ubuntu Server by reading Install Multicraft on Ubuntu Server. :::

To install OpenJDK and Git on the server, you can use the command:

sudo apt install -y default-jdk git

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We connect to the Multicraft server on which we plan to update Spigot.

Let's create a new directory that we need to create a new version of Spigot using the command:

sudo mkdir BuildTools

Go to the new directory using the command:

cd BuildTools

Load the "BuildTools.jar" file using the command:

sudo wget https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar

The "BuildTools.jar" file is required to create a new version of Spigot.

Let's make changes to the Git configuration using the command:

sudo git config --global --unset core.autocrlf

We start creating a new version of Spigot using the command:

sudo java -jar BuildTools.jar

The new version of Spigot has been successfully created and is available in the previously created "BuildTools" directory.

Now you need to replace the old version of Spigot with the new one so that Spigot starts correctly with Multicraft.

Find the location of the old version of Spigot using the command:

sudo find / -name 'spigot*.jar'

The old version is in the directory:

/home/minecraft/multicraft/jar/

Let's create a backup copy of the old version of Spigot using the command:

sudo mv /home/minecraft/multicraft/jar/spigot.jar /home/minecraft/multicraft/jar/spigot.jar.old

Let's copy the new version of Spigot to the place of the old version using the command:

sudo cp /home/ubuntu/BuildTools/spigot-* /home/minecraft/multicraft/jar/spigot.jar

Let's enable execution of the "spigot.jar" file using the command:

sudo chmod +x /home/minecraft/multicraft/jar/spigot.jar

Let's adjust the owner and group for the "spigot.jar" file using the command:

sudo chown -R minecraft:minecraft /home/minecraft/multicraft/jar/spigot.jar

:::note By default Multicraft runs as "minecraft" username. Therefore, the owner of the new version of Spigot must be the user "minecraft". :::

The Spigot update has been successfully completed and you can now correctly launch the modified Minecraft server using Multicraft.

:::note For a step-by-step guide on starting a Minecraft server with Multicraft, see my tutorial: Run a Minecraft Server with Multicraft. :::

Install Multicraft on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Sun, 04 Apr 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Multicraft on Ubuntu Server.

Multicraft is a complete Minecraft server hosting solution.

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to get a free cryptographic certificate through Let's Encrypt CA.
TCP port 443 - to access the Multicraft control panel.
TCP port 25565 - for Minecraft client access to the Minecraft server.

:::

We connect to the server on which you plan to install Multicraft.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for Multicraft to work using the command:

sudo apt install -y apache2 apt-transport-https certbot python3-certbot-apache mysql-server php libapache2-mod-php php-mysql php-gd php-cli php-common php-mbstring php-ldap php-odbc php-pear php-xml php-xmlrpc php-bcmath php-pdo default-jdk git zip unzip

:::note In this tutorial, MySQL will be used as a database management system, and Apache will be used as a webserver. :::

Let's configure Apache for further work with the Multicraft control panel.

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::

Now you need to make changes to the Apache configuration file by opening it in a text editor using the command:

sudo vim /etc/apache2/apache2.conf

Press the "i" button to switch to edit mode, find the "AllowOverride" parameter for the "/var/www/" directory, and set the "All" value for the parameter.

:::note "AllowOverride All" - indicates that ".htaccess" should be used for the root directory of the virtual host and all subfolders. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Now you need to create a virtual host file (called a block in Nginx), with which the Multicraft control panel will work in the future.

Let's create a virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/multicraft.heyvaldemar.net.conf

:::note In this manual, the multicraft.heyvaldemar.net subdomain will be used to access the Multicraft control panel from the Internet. You will need to specify your domain or subdomain by which your Multicraft control panel will be available from the Internet. :::

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName multicraft.heyvaldemar.net
	DocumentRoot /var/www/html/multicraft
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

We activate the created virtual host using the command:

sudo a2ensite multicraft.heyvaldemar.net.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes made using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Request a cryptographic certificate using the command:

sudo certbot --apache -d multicraft.heyvaldemar.net

Next, we indicate the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose whether you would like to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "2", then "Enter".

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now let's configure MySQL for further work with the Multicraft control panel.

First, you need to run the "mysql_secure_installation" script, which is designed to provide a basic level of MySQL security.

Run the script using the command:

sudo mysql_secure_installation

Next, you need to answer a few questions to ensure a basic level of MySQL security.

The first question is whether you want to use the password strength plugin, which will need to be set later for the "root" user who has administrator rights in MySQL.

Press the "y" button, then "Enter".

The next step is to select the level of password complexity checking, which will need to be set later for the "root" user who has administrator rights in MySQL.

:::note In this tutorial, we will look at the highest level of password strength checking for the "root" user. :::

Press the button "2", then "Enter".

The next step is to provide a strong password for the "root" user who has administrator rights in MySQL.

Specify a strong password for the "root" user and press the "Enter" button.

Next, specify the password for the "root" user again and press the "Enter" button.

The next question is if you would like to proceed to the next step in setting up a basic MySQL security level with the obtained password strength value.

:::note In this tutorial, the "Estimated strength of the password" value is 100, which indicates that the previously specified password is strong enough. :::

Press the "y" button, then "Enter".

The next question is if you want to delete anonymous users.

Press the "y" button, then "Enter".

The next question is if you want to disable remote MySQL connectivity for the "root" user.

Press the "y" button, then "Enter".

The next question is if you want to drop the test databases.

Press the "y" button, then "Enter".

Now you need to apply the changes you made.

Press the "y" button, then "Enter".

Now you need to create databases that will be used by the Multicraft control panel and the Multicraft daemon in the future, as well as users with the necessary rights in these databases.

We connect to the MySQL management console using the command:

sudo mysql -u root -p

Specify the password for the "root" account specified earlier and press the "Enter" button.

:::note In this manual, "multicraft_panel" will be used as the database name for the Multicraft control panel. :::

Let's create a database, which will be used by the Multicraft control panel in the future, using the command:

CREATE DATABASE multicraft_panel CHARACTER SET utf8 COLLATE utf8_general_ci;

:::note In this manual, "multicraftpaneldbuser" with the password "c7_Qm,A+;eq}=UHq5yW" will be used as the username with rights to the database for the Multicraft control panel. :::

Create a user and assign a password to it using the command:

CREATE USER 'multicraftpaneldbuser'@'localhost' IDENTIFIED BY 'c7_Qm,A+;eq}=UHq5yW';

We grant the new user rights to the previously created database using the command:

GRANT ALL ON multicraft_panel.* TO 'multicraftpaneldbuser'@'localhost';

:::note This tutorial will use "multicraft_daemon" as the database name for the Multicraft daemon. :::

Let's create a database that will be used by the Multicraft daemon in the future using the command:

CREATE DATABASE multicraft_daemon CHARACTER SET utf8 COLLATE utf8_general_ci;

:::note In this manual, "multicraftdaemondbuser" with the password "zkJ3Xpr7f>/TLSYw6Zk" will be used as the username with rights to the database for the Multicraft daemon. :::

Create a user and assign a password to it using the command:

CREATE USER 'multicraftdaemondbuser'@'localhost' IDENTIFIED BY 'zkJ3Xpr7f>/TLSYw6Zk';

We grant the new user rights to the previously created database using the command:

GRANT ALL ON multicraft_daemon.* TO 'multicraftdaemondbuser'@'localhost';

Apply the changes made using the command:

FLUSH PRIVILEGES;

Disconnect from the MySQL Management Console using the command:

quit

Now download the "multicraft.tar.gz" archive containing the files for installing Multicraft using the command:

sudo wget http://www.multicraft.org/download/linux64 -O multicraft.tar.gz

Unpack the downloaded archive "multicraft.tar.gz" using the command:

sudo tar xvzf multicraft.tar.gz

Let's go to the "multicraft" folder using the command:

cd multicraft

Now let's run the Multicraft installation script using the command:

sudo ./setup.sh

Next, you need to answer a few questions from the Multicraft installer.

The first question is whether you need to run each Minecraft server using a separate user.

Press the "y" button, then "Enter".

At the next stage, you need to specify the user that will be used to launch the Multicraft control panel.

:::note In this tutorial, the user "minecraft" will be used to launch the Multicraft control panel. :::

Leave the default value and press the "Enter" button.

The next question is whether it is worth creating a new user "minecraft" for the subsequent launch of the Multicraft control panel under this user.

Press the "y" button, then "Enter".

In the next step, you can select the directory where the Multicraft control panel should be installed.

Leave the default value and press the "Enter" button.

In the next step, you can specify the Multicraft license key.

:::note Running a single Minecraft server with the Multicraft control panel does not require a license key. For details on Multicraft license pricing, visit the official pricing page. :::

:::note In this tutorial, the Multicraft dashboard will be used to run one Minecraft server. :::

Leave the default value and press the "Enter" button

The next question is about managing multiple servers using the Multicraft control panel. If you have multiple servers for web management, you must assign a unique number to each management server daemon.

:::note In this guide, the Multicraft control panel will control one server. :::

Leave the default value and press the "Enter" button.

The next question is whether the Multicraft control panel will work on the current server.

Press the "y" button, then "Enter".

The next step is to specify the webserver user.

Leave the default value and press the "Enter" button.

In the next step, you can select the directory where the files of the Multicraft web panel should be installed.

Leave the default value and press the "Enter" button.

The next step is to provide a strong password for the daemon.

:::note The password for the daemon set at this stage will need to be specified later at the final stage of installing the Multicraft control panel. :::

Specify a strong password for the daemon and press the "Enter" button.

The next question is whether you need to enable the built-in FTP server.

Enabling the built-in FTP server can come in handy for uploading the files required to run Minecraft servers.

Press the "y" button, then "Enter".

The next step is to specify the IP address of the server that will run the built-in FTP server.

Leave the default value and press the "Enter" button.

In the next step, you need to specify the port on which the built-in FTP server will be available.

Leave the default value and press the "Enter" button.

The next question is whether to block the download of files with the ".jar" extension and other executable files downloaded using the built-in FTP server.

Press the "n" button, then "Enter".

The next step is to specify a database management system that will be used to work with the Multicraft daemon.

:::note This tutorial will use MySQL as the database management system. :::

Specify "mysql", then press the "Enter" button.

At the next stage, you need to specify the IP address of the server on which the database for the Multicraft daemon is located.

:::note In this tutorial, the database for the Multicraft daemon is located on the same server as the Multicraft control panel. :::

Leave the default value and press the "Enter" button.

In the next step, you need to specify the name assigned to the database for the Multicraft daemon, which was created earlier.

This tutorial uses "multicraft_daemon" as the database name for the Multicraft daemon.

Leave the default value and press the "Enter" button.

At the next stage, you need to specify the name assigned to the user who was created earlier and to whom the rights to the database were granted for the Multicraft daemon to work.

:::note In this tutorial, "multicraftdaemondbuser" is used as the database username for the Multicraft daemon. :::

Specify "multicraftdaemondbuser", then press the "Enter" button.

At the next stage, you need to specify the password assigned to the user who was granted rights to the database for the Multicraft daemon to work.

Specify the password assigned to the user "multicraftdaemondbuser", then press the "Enter" button.

Everything is ready to start installing the Multicraft control panel.

Press the "y" button, then "Enter".

The first stage of the installation has been completed successfully.

Press the "Enter" button.

The next question is whether you need to keep all of the above values to install the Multicraft control panel.

Press the "y" button, then "Enter".

To continue the process of installing the Multicraft control panel, you need to go from the workstation to the link https://multicraft.heyvaldemar.net/install.php, where multicraft.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name or IP address of your server with the Multicraft control panel installed.

Click on the "Start Installation" button.

Next, the installer will check that all the requirements for the correct installation of the Multicraft control panel are met.

Click on the "Continue" button.

In the next step, the installer will copy the Multicraft control panel configuration file to the directory with files for the Multicraft web panel.

Click on the "Continue" button.

Now you need to specify the system for managing the databases and the previously created database that will be used to work with the Multicraft control panel.

In the "Database Type" field, select "MySQL".

:::note In this manual, the database for the Multicraft control panel is located on the same server as the Multicraft control panel. :::

In the "Database Host" field, enter "127.0.0.1".

:::note In this manual, "multicraft_panel" is used as the database name for the Multicraft control panel. :::

In the "Database Name" field, specify "multicraft_panel".

:::note In this manual, "multicraftpaneldbuser" is used as the username with rights to the database for the Multicraft control panel. :::

In the "Database Username" field, specify "multicraftpaneldbuser".

In the "Database Password" field, specify the password assigned to the "multicraftpaneldbuser" user.

Click on the "Save" button.

Next, you need to initialize the database.

Click on the "Initialize Database" button.

The database has been initialized successfully.

Click on the "Continue" button.

Now you need to log into the Multicraft control panel under the Multicraft administrator account and complete the installation process.

Click on the "Login" button.

Default login for Multicraft administrator account: admin

The default password for the Multicraft administrator account is admin

Specify the username and password of an account that has administrator rights Multicraft, and click on the "Login" button.

Next, a message will appear stating that the connection to the Multicraft control panel database has been successfully established.

Click on the "Continue" button.

Now you need to specify the database management system that will be used to work with the Multicraft daemon.

In the "Database Type" field, select "MySQL".

:::note In this tutorial, the database for the Multicraft daemon is located on the same server as the Multicraft control panel. :::

In the "Database Host" field, enter "127.0.0.1".

This tutorial uses "multicraft_daemon" as the database name for the Multicraft daemon.

In the "Database Name" field, specify "multicraft_daemon".

:::note In this tutorial, "multicraftdaemondbuser" is used as the database username for the Multicraft daemon. :::

In the "Database Username" field, specify "multicraftdaemondbuser".

In the "Database Password" field, specify the password assigned to the user "multicraftdaemondbuser".

Click on the "Save" button.

Next, you need to initialize the database.

Click on the "Initialize Database" button.

The database has been initialized successfully.

Click on the "Continue" button.

In the "Administrator contact Email" field, you must specify an email address where you can contact the administrator of the Multicraft control panel.

In the "Password for daemon connections" field, you must specify the password that was set for the daemon earlier at the stage of using the installation script in the terminal emulator.

Click on the "Save" button.

Now we need to start the Multicraft daemon.

We return to the terminal emulator and start the Multicraft daemon using the command:

sudo /home/minecraft/multicraft/bin/multicraft -v start

Return to the Multicraft control panel and click on the "Refresh" button.

The daemon started successfully.

Click on the "Continue" button.

Installation of the Multicraft Control Panel has been completed successfully.

Click on the "Continue to Multicraft" button.

Now, for security reasons, you need to delete the "install.php" file that was used during the installation of Multicraft.

Return to the terminal emulator and delete the "install.php" file using the command:

sudo rm -f /var/www/html/multicraft/install.php

Exit the "multicraft" directory using the command:

cd ..

Now delete the "multicraft" directory containing the files for installing Multicraft using the command:

sudo rm -rf multicraft

Now delete the previously downloaded archive "multicraft.tar.gz" containing the files for installing Multicraft using the command:

sudo rm -f multicraft.tar.gz

Next, you need to configure the autorun of the Multicraft service when the operating system starts.

Load the unit prepared in advance by the Multicraft developers with the parameters for starting the Multicraft service into the "/etc/systemd/system/" directory using the command:

sudo wget http://www.multicraft.org/files/multicraft.service -O /etc/systemd/system/multicraft.service

Assign correct rights to the "multicraft.service" unit using the command:

sudo chmod 644 /etc/systemd/system/multicraft.service

We enable the autorun of the Multicraft service when the operating system starts using the command:

sudo systemctl enable multicraft

Now you need to provide a valid email address and set a new password for the Multicraft administrator account.

Return to the Multicraft control panel and go to the "Users" tab, then click on the "My Profile" button.

In the "Email" field, indicate the current email address of the Multicraft administrator.

In the "Current Password" field, specify the current Multicraft administrator password.

In the "New Password" and "Confirm Password" fields, specify the new Multicraft administrator password.

Click on the "Save" button to save the changes.

Now you need to log into the Multicraft control panel with the Multicraft administrator account using the new password.

Click on the "Login" button.

Next, you need to specify the username and password of an account that has administrator rights Multicraft and click on the "Login" button.

Click on the "Close" button if you agree to the Minecraft license agreement.

For more information, refer to the Minecraft End User License Agreement available on the official EULA page.

Click on the "Close" button if you agree to the Minecraft license agreement.

Additional information about the Minecraft license agreement is available on the official Minecraft website.

Everything is ready to use the Multicraft control panel.

Next, you may need to update Spigot.

:::note For instructions on upgrading Spigot on Ubuntu Server using Multicraft, see my guide: Upgrade Spigot on Ubuntu Server with Multicraft. :::

:::note For a step-by-step guide on starting a Minecraft server with Multicraft, see my tutorial: Run a Minecraft Server with Multicraft. :::

Disable Server Manager Autostart in Windows Server 2019

Vladimir Mikhalev (heyvaldemar.com) — Sun, 28 Mar 2021 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to disable Server Manager autostart in Windows Server 2019.

:::note For instructions on disabling Server Manager autostart in Windows Server 2012 R2, see: Disable Server Manager Autostart in Windows Server 2012 R2. :::

We go into the system under an account with administrator rights.

Open Server Manager, click on the "Manage" button in the upper right corner of the screen, and select "Server Manager Properties".

Check the box "Do not start Server Manager automatically at logon" and click on the "OK" button.

Server Manager will no longer start automatically.

You can also disable the automatic start of "Server Manager" through the task scheduler. To do this, you must disable the task that is responsible for the automatic start of "Server Manager".

In Server Manager, click on the "Tools" button in the upper right corner of the screen and select "Task Scheduler".

In the "Task Scheduler Library" go to the "Microsoft" section, then to "Windows", and in the "Server Manager" subsection, select the "Server Manager" task.

In the "Actions" menu, click on the "Disable" button.

Server Manager will no longer start automatically.

In addition, you can disable the task that is responsible for automatically starting Server Manager using the command line.

Press "Start", specify "cmd" in the search bar, and select "Command Prompt".

Disable Server Manager autostart using the command:

schtasks /Change /TN "Microsoft\Windows\Server Manager\ServerManager" /Disable

Server Manager will no longer start automatically.

You can also disable the task that is responsible for automatically starting Server Manager using Windows PowerShell.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

Disable Server Manager autostart using the command:

Get-ScheduledTask -TaskName ServerManager | Disable-ScheduledTask

Server Manager will no longer start automatically.

Install Bitwarden on Ubuntu Server 20.04 LTS

Vladimir Mikhalev (heyvaldemar.com) — Mon, 01 Mar 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Bitwarden on Ubuntu Server 20.04 LTS.

For step-by-step instructions on installing Bitwarden on Ubuntu Server 22.04 LTS, see Install Bitwarden on Ubuntu Server 22.04 LTS.

Bitwarden is a free open-source password manager with the ability to sync your account information across all devices.

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to receive a free cryptographic certificate through the Let's Encrypt CA.
TCP port 443 - to access the Bitwarden dashboard.

:::

First, you need to request an installation ID and installation key to host Bitwarden on your server. You must use a unique ID and key for each Bitwarden installation.

Visit the Bitwarden hosting page, fill in your email address in the "Admin Email Address" field, and click the "Submit" button.

Save the resulting "Installation Id" and "Installation Key". These values will be required during Bitwarden installation.

We connect to the server on which you plan to install Bitwarden.

Download the Bitwarden installation script using the command:

curl -Lso bitwarden.sh https://go.btwrdn.co/bw-sh

Let's enable the execution of the file "bitwarden.sh" using the command:

chmod +x bitwarden.sh

Now let's start the Bitwarden installation using the command:

sudo ./bitwarden.sh install

Now you need to specify the domain name that you plan to use to access the Bitwarden dashboard.

Specify the domain name to access Bitwarden and press the "Enter" button.

This tutorial walks you through obtaining a free cryptographic certificate through the Let's Encrypt CA.

Press the "y" button, then "Enter".

We indicate the email address to which Let's Encrypt will send notifications about the expiration of the certificate and press the "Enter" button.

Specify the database name for the Bitwarden instance and press the "Enter" button.

Specify the "Installation Id" obtained earlier and press the "Enter" button.

We indicate the "Installation Key" obtained earlier and press the "Enter" button.

Bitwarden installed successfully.

Now let's start Bitwarden using the command:

sudo ./bitwarden.sh start

Bitwarden launched successfully.

Next, you need to register to start using the Bitwarden dashboard.

Install OpenJDK on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Mon, 01 Mar 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing OpenJDK on Ubuntu Server.

:::note With the release of Java 11, Oracle JDK became commercial and is no longer free. :::

OpenJDK is an open-source implementation of the Java Standard Edition platform with contributions from Oracle and the Java open community. The Oracle JDK build process is built from the OpenJDK source, so there isn't much difference between Oracle JDK and OpenJDK.

:::tip[Architecture Context] Choose OpenJDK when you need a free, community-supported Java runtime for production workloads. Amazon Corretto, Eclipse Temurin, or Azul Zulu provide vendor-backed alternatives with LTS support and performance optimizations. For containerized deployments, consider using a JDK base image instead of host-level installation to improve portability and reproducibility across environments. :::

:::note OpenJDK is free but will need to be updated every 6 months. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We connect to the server on which you plan to install OpenJDK.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

You may need a Java Development Kit (JDK) in addition to the JRE to compile and run certain Java-based software.

To install the JDK, run the following command, which will also install the JRE:

sudo apt-get install -y default-jdk

Now you need to make sure that OpenJDK is installed correctly. To do this, you need to run the command:

java -version

Based on the message received, OpenJDK is installed correctly.

Many programs written with Java use the "JAVA_HOME" environment variable to determine where Java is installed. Therefore, you need to define this variable and assign it a value containing the path to the Java installation location.

Let's define the path to the Java installation location using the command:

sudo update-alternatives --config java

In this example, the path to the Java installation location looks like this:

/usr/lib/jvm/java-11-openjdk-amd64/bin/

To define an environment variable and assign a value to it, you need to make changes to the "environment" file by opening it in a text editor using the command:

sudo vim /etc/environment

JAVA_HOME="/usr/lib/jvm/java-11-openjdk-amd64/bin/"

:::note The path to the Java installation location must be specified up to and including the "bin" folder. :::

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Next, you need to apply the changes made to the current session using the command:

source /etc/environment

Now let's make sure that the environment variable has the correct value using the command:

echo $JAVA_HOME

Based on the message received, the environment variable has the correct value.

Enable Logging in Windows Firewall

Vladimir Mikhalev (heyvaldemar.com) — Thu, 18 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing enable logging in Windows Firewall.

:::warning For security reasons, it is not recommended to disable Windows Firewall unless you are using a complete antivirus solution that includes a different firewall. In the case when Windows Firewall blocks the operation of an application, you need to study this event in detail using a file with logs and make an allowing rule for this application in Windows Firewall, if it is really necessary. :::

:::note This tutorial will cover several ways to enable logging in to Windows Firewall. :::

We go into the system under an account with administrator rights.

Open Server Manager, click on the "Tools" button in the upper right corner of the screen and select "Windows Firewall with Advanced Security".

Next, right-click on "Windows Firewall with Advanced Security on Local Computer" and select "Properties".

:::note In this guide, logging in Windows Firewall for a domain profile will be configured. Similarly, you can configure logging for other profiles. :::

On the "Domain Profile" tab, in the "Logging" section, select "Customize".

Further, in the "Name" field, you can specify where the file with the Windows Firewall logs will be stored.

In the "Size Limit" field, specify the maximum size of the file with logs.

To enable logging of dropped packets, select "Yes" in the "Log dropped packets" section.

Click on the "OK" button.

You can also enable logging in to Windows Firewall using Windows PowerShell.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

:::note In this guide, logging in Windows Firewall for a domain profile will be configured. Similarly, you can configure logging for other profiles. :::

We enable logging using the command:

Set-NetFireWallProfile -Profile Domain -LogBlocked True -LogMaxSize 4096 -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log"

Now, looking at the file with the logs, you can examine in detail which application was blocked using Windows Firewall, and make an allow rule for it if it is really necessary.

Optimal Active Directory Structure

Vladimir Mikhalev (heyvaldemar.com) — Sat, 13 Feb 2021 00:00:00 GMT

Here's a proven Active Directory (AD) structure commonly used by large organizations, including enterprises with over 10,000 employees globally. Such environments typically implement a domain tree structured by country or continent.

Example domain hierarchy

Root domain: heyvaldemar.net
Child domains: canada.heyvaldemar.net, ireland.heyvaldemar.net

Each domain in the tree follows a consistent internal structure.

Domain-Level Organization by City

Toronto (City of Toronto)

City-Level OUs by Object Type

Groups - All security and distribution groups
Servers - All server objects
Service - Service accounts used to run applications
Users - End user accounts
Workstations - User endpoints

Groups - Organized by Scope

Local - Domain-local groups
Global - Global groups
Universal - Universal groups
Distribution - Non-security mail groups

Servers - Organized by Service Role

Disabled - Decommissioned or inactive servers
Exchange - Microsoft Exchange servers
File - File servers with shared resources
Normal - General-purpose servers
Print - Print servers

(More categories can be added based on operational needs.)

Service Accounts - Organized by Role

Disabled - Inactive service accounts
Normal - Active service accounts used in production

User Accounts - Organized by Role

Admins - Elevated-privilege accounts
Disabled - Former employees or inactive accounts
External - Contractors or third-party users
Normal - Standard user accounts

(Expand categories as needed for your organization.)

Workstations - Organized by User Role

Admins - Devices used by admin accounts
Disabled - Retired or unused machines
Normal - Standard user workstations

Final Note

This structure provides a scalable, secure, and easily manageable AD layout — ideal for delegation, policy application, and compliance.

Install Windows Server 2019

Vladimir Mikhalev (heyvaldemar.com) — Thu, 11 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Windows Server 2019.

:::note I strongly recommend that you never use any third-party builds of Windows. Use only original installation images. This will help you avoid a lot of problems and get maximum performance and stability. :::

After successfully booting from the Windows Server 2019 installation flash drive or DVD, the first step is to select the language options.

Click on the "Next" button.

Click on the "Install now" button.

:::note If you need to install Windows Server 2019 in Server Core mode (no GUI), then you need to select "Windows Server 2019 Standard Evaluation" or "Windows Server 2019 Datacenter Evaluation". :::

This example is for installing Windows Server 2019 Datacenter Evaluation (Desktop Experience).

Select "Windows Server 2019 Datacenter Evaluation (Desktop Experience)" and click "Next".

Now you need to accept the license terms.

This step offers two installation options:

"Upgrade". This is not the best option. As practice shows, numerous programs may not be compatible with the new operating system, and after the update, you will not be able to work with them, in addition, there is a possibility of dragging problems from the old operating system to the new one, thus losing all stability.
"Custom". This is the best option for installing any version of the Windows operating system. It allows you to start working with the system "from scratch", so after installation, you will get maximum performance and stability. All that remains is to install the drivers and the software familiar to work.

Now you need to choose which disk the new operating system will be installed on and allocate space for installation.

If you have more than one disk installed or the disk already has several partitions, all this will be displayed at this stage. Care must be taken to understand in advance which partition you want to install the operating system on.

:::note In this example, one 50 GB disk is installed. :::

Click on the "New" button.

In this case, all free disk space will be allocated for the system, so we leave the value in the "Size" section by default.

Click on the "Apply" button.

The operating system notifies that it may need to create additional partitions on the disk to store system files.

Click on the "OK" button.

Thus, all free disk space was allocated for the operating system, but at the same time, the system reserved a small partition for itself.

Now you need to select the partition on which the operating system is supposed to be installed and click on the "Next" button.

The process of installing the operating system has begun.

The computer will automatically restart.

Now you need to provide a strong password for the "Administrator" account.

Click on the "Finish" button.

After completing the settings, you will be greeted by the Windows Server 2019 lock screen.

Press "Ctrl + Alt + Delete".

Next, you need to log into the system under the "Administrator" account.

Next, you will be able to turn on network discovery so that the server is visible to other computers on the network.

:::note Network discovery is not recommended to be enabled on public networks. :::

Click on the "Yes" button.

Windows Server 2019 installation is complete.

Install Windows Server 2019 Server Core

Vladimir Mikhalev (heyvaldemar.com) — Thu, 11 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Windows Server 2019 Server Core.

After successfully booting from a Windows Server 2019 Server Core installation USB stick or DVD, the first step is to select your language options.

Click on the "Next" button.

Click on the "Install now" button.

:::note If you need to install Windows Server 2019 with a GUI, then you need to select "Windows Server 2019 Standard Evaluation (Desktop Experience)" or "Windows Server 2019 Datacenter Evaluation (Desktop Experience)". :::

This example is for installing Windows Server 2019 Datacenter Evaluation (Server Core).

Select "Windows Server 2019 Datacenter Evaluation" and click "Next".

Now you need to accept the terms of the license.

This step offers two installation options:

"Upgrade". This is not the best option. As practice shows, numerous programs may not be compatible with the new operating system, and after the update, you will not be able to work with them, in addition, there is a possibility of dragging problems from the old operating system to the new one, thus losing all stability.
"Custom". This is the best option for installing any version of the Windows operating system. It allows you to start from scratch with the system, so after installation, you will get maximum performance and stability. All that remains is to install the drivers and software familiar to work.

Now you need to select which disk the new operating system will be installed on and allocate space for installation.

If you have more than one disk installed or the disk already has several partitions, all this will be displayed at this stage. You need to be careful and understand in advance which partition you want to install the operating system on.

:::note In this example, there is one 50 GB disk installed. :::

Click on the "New" button.

In this case, all free disk space will be allocated for the system, so we leave the value in the "Size" section by default.

Click on the "Apply" button.

The operating system notifies that it may need to create additional partitions on the disk to store system files.

Click on the "OK" button.

Thus, all free disk space was allocated for the operating system, but at the same time, the system reserved a small partition for itself.

Now you need to select the partition on which you intend to install the operating system and click on the "Next" button.

The process of installing the operating system has begun.

The computer will automatically restart.

Now you need to provide a strong password for the "Administrator" account.

Select "Ok" and press the "Tab" button.

Specify a strong password and click on the "Tab" button.

We indicate the previously entered password again and press the "Enter" button.

The password for the "Administrator" account has been set.

Press the "Enter" button.

Windows Server 2019 Server Core installation is complete.

Export Drivers Using Windows PowerShell

Vladimir Mikhalev (heyvaldemar.com) — Wed, 10 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to export drivers using Windows PowerShell.

The ability to export third-party drivers using PowerShell using the Export-WindowsDriver cmdlet was first introduced with Update 1 for Windows 8.1 and Windows Server 2012 R2. This great feature is also present on later operating systems from Microsoft.

Exported drivers can be useful for manual installation on new computers or using automated solutions. In addition, drivers can be added to the Windows installation image.

:::note The guide will discuss the export of drivers with their description. :::

We go into the system under an account with administrator rights.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

Click on the "Yes" button.

:::note In this manual, the drivers and their descriptions will be exported to the "Temp" folder on the "C" drive. The description of the exported drivers will be saved to the "drivers.txt" file. :::

Let's prepare the variable using the command:

$drivers = Export-WindowsDriver -Online -Destination C:\Temp\drivers

We export the drivers using the command:

$drivers | ft ProviderName, ClassName, Date, Version -auto | Out-File C:\Temp\Drivers\drivers.txt

The drivers and their descriptions have been successfully exported to the "Temp" folder on the "C" drive.

Install Windows 10

Vladimir Mikhalev (heyvaldemar.com) — Wed, 10 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Windows 10.

Be sure to copy all personal data to a safe place. For example, to an external hard drive.

After successfully booting from the Windows 10 installation flash drive or DVD, the first step is to select the language options.

Click on the "Next" button.

Click on the "Install now" button.

Now you need to specify the product license key.

We indicate the license key and click on the "Next" button.

This example is for installing Windows 10 Pro.

Select "Windows 10 Pro" and click "Next".

Now you need to accept the license terms.

Click on the "Next" button.

This step offers two installation options:

"Upgrade". This is not the best option. As practice shows, numerous programs may not be compatible with the new operating system, and after the update, you will not be able to work with them, in addition, there is a possibility of dragging problems from the old operating system to the new one, thus losing all stability.
"Custom". This is the best option for installing any version of the Windows operating system. It allows you to start working with the system "from scratch", so after installation, you will get maximum performance and stability. All that remains is to install the drivers and the software familiar to work. Before choosing the "Custom installation" option, be sure to make sure that all personal data has been transferred to a safe place.

Now you need to choose which disk the new operating system will be installed on and allocate space for installation.

:::note In this example, one 50 GB disk is installed. :::

Click on the "New" button.

In this case, all free disk space will be allocated for the system, so we leave the value in the "Size" section by default.

Click on the "Apply" button.

The operating system notifies that it may need to create additional partitions on the disk to store system files.

Click on the "OK" button.

Thus, all free disk space was allocated for the operating system, but at the same time, the system reserved a small partition for itself.

Now you need to select the partition on which the operating system is supposed to be installed and click on the "Next" button.

The process of installing the operating system has begun.

The computer will automatically restart.

After the installation is complete, the operating system will begin to prepare the computer for work.

After rebooting, you must select the region in which your computer is located.

Click on the "Yes" button.

Next, you need to select a keyboard layout.

Click on the "Yes" button.

In the next step, you can add a second keyboard layout.

Click on the "Skip" button.

Now you need to choose who owns the computer.

:::note In this example, we consider a computer that belongs to a home user, not an organization. :::

Select "Set up for personal use" and click on the "Next" button.

This step offers two types of accounts:

"Microsoft account". This option will fully integrate into the Microsoft ecosystem. All your Windows Store apps featured links, mail, color scheme, and more will always be linked to your Microsoft account. Thus, by logging into this account on another computer, you can get all the same settings as on your personal computer. To take advantage of your Microsoft account, you need to enter your email address and click Next. If you do not already have an email address, you can create one by clicking on the "Create account" button.
"Offline account". This option is more suitable in cases where you do not need all your settings to be stored on Microsoft servers and synchronized on all Windows devices. This solution is more suitable for a PC that is planned to be used in an enterprise.

:::note In this example, we will create an offline account. :::

Click on the "Offline account" button.

Next, click on the "Limited experience" button to opt-out of creating a Microsoft account.

Now you need to provide a username, password, and a password hint, in case you forget it.

Specify the username and click on the "Next" button.

Specify a strong password and click on the "Next" button.

Specify the previously entered password again and click on the "Next" button.

We indicate the first security question and the answer to it.

Click on the "Next" button.

We indicate the second security question and the answer to it.

Click on the "Next" button.

We indicate the third security question and the answer to it.

Click on the "Next" button.

Next, select "No" at all points so that no reports are sent to Microsoft.

Click on the "Accept" button.

Next, click on the "Not now" button to refuse to enable Cortana.

Next, the final part of preparing Windows 10 for work will begin.

Windows 10 installation is complete.

Now you need to install the drivers. They can always be downloaded from the device manufacturer's website, in the technical support section. On the manufacturer's website, you need to find exactly your device, and also indicate that you need drivers for Windows 10. Without the appropriate drivers, your device will not function correctly.

Below are links to websites of popular equipment manufacturers. In the section "Technical support" you can find drivers for a specific model of your computer or for individual components:

Auto-run Scripts when macOS Boots

Vladimir Mikhalev (heyvaldemar.com) — Tue, 09 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing auto-run scripts when macOS boots.

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

We go into the system under an account with administrator rights and start the terminal emulator.

Now let's create a script that will contain the scripts required to execute when macOS boots, using the command:

sudo vim /Users/valdemar/Documents/Scripts/run-service.sh

:::note In this tutorial, a script called "run-service.sh" is created in the user's home directory. You can create a script in any convenient place for permanent storage. :::

Specify the password for the account and press "Enter".

Hit the "i" button to go into edit mode, then add the scripts you need to execute when you boot macOS.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's enable the execution of the file "run-service.sh" using the command:

sudo chmod +x /Users/valdemar/Documents/Scripts/run-service.sh

Now you need to use the Cron Task Scheduler to schedule the script to run after the operating system starts up.

Open the task scheduler using the command:

sudo crontab -e

Hit the "i" button to switch to edit mode, then add a line with the "@reboot" parameter and specify the full path to the previously created script:

@reboot /Users/valdemar/Documents/Scripts/run-service.sh

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

The script will now automatically run when macOS boots, even before the user logs in.

Minimize Programs on Windows 10 Startup

Vladimir Mikhalev (heyvaldemar.com) — Mon, 08 Feb 2021 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to minimize programs on Windows 10 startup.

:::note For this example, we will be working with Microsoft Edge. :::

Right-click on the shortcut of the program that you want to automatically launch when the system boots, then select "Copy".

On the keyboard, press the key combination "Win" and "r", then enter:

%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

:::note If you want the program to automatically start for all users, then you must enter: :::

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Click on the "OK" button.

Right-click on an empty space in the folder and select "Paste".

Now the specified program will automatically start at system boot, and the program window will appear on top of the Windows desktop. This is not very convenient, so we will make the program run minimized.

Select the desired program shortcut and click on it with the right mouse button, then select "Properties".

In order for Microsoft Edge to start minimized, you must select "Minimized" in the "Run" section.

Click on the "OK" button.

Microsoft Edge will now automatically launch minimized when Windows boots up and thus won't get in the way by appearing on top of the desktop.

Install Docker Swarm on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Sat, 26 Dec 2020 00:00:00 GMT

This is a straight, detailed walkthrough for getting Docker Swarm running on Ubuntu Server. No filler.

Docker Swarm is Docker's own clustering tool. It takes a set of Docker servers and turns them into one cluster. The point is availability and performance: Swarm spreads the load across every Docker server in the cluster.

:::tip[Architecture Context] Choose Docker Swarm when you need simple container orchestration with minimal operational complexity and built-in Docker integration. Amazon ECS, EKS, or GKE provide managed alternatives with richer ecosystem support. Swarm is justified for small-to-medium deployments where Kubernetes complexity is not warranted, or when your team's Docker Compose expertise should transfer directly to orchestration. :::

:::important Docker Engine and Docker Compose must be installed on the server.

For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

Need OpenSSH? Install it with:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP and UDP ports for access to the services:

TCP port 2377 - for cluster management and Raft synchronization.
TCP and UDP port 7946 - for communication between all Docker Swarm servers.
UDP port 4789 - for network traffic (inbound container network).
IP Protocol 50 (ESP) - if you plan to use an encrypted network.

:::

First, connect to the server where Swarm will live.

Find the server's IP address:

ip a

Now initialize Swarm:

docker swarm init --advertise-addr 10.170.18.13

:::note 10.170.18.13 is the IP address of my server. Accordingly, you need to specify the IP address of your server. :::

That's it. Swarm is up.

The output prints a command. Run that command on another server and it joins the cluster as a worker.

:::note To prepare another server for the Docker Swarm cluster, you need to install only the Docker Engine on the new server and run the docker swarm join command with the appropriate token. :::

:::note For a step-by-step guide on installing Docker Engine on Ubuntu Server, see Install Docker Engine and Docker Compose on Ubuntu Server :::

Workers are one thing. You also want to be able to add more managers. Grab the manager join token:

docker swarm join-token manager

Same idea as before. The printed command joins another server to the cluster, this time with the manager role.

:::note To prepare another server for the Docker Swarm cluster, you need to install only the Docker Engine on the new server and run the docker swarm join command with the appropriate token. :::

One last check. Confirm Swarm is actually running:

docker info

The message back confirms it. Swarm is installed and working.

Install ServiceDesk Plus on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Fri, 02 Oct 2020 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing ServiceDesk Plus on Ubuntu Server.

ServiceDesk Plus is support services software with an integrated asset management system. This solution allows you to manage incidents, assets, requests, has a service catalog, and also provides an IT Project Management module for project management with support for the collaboration mode.

:::tip[Architecture Context] Choose self-hosted ServiceDesk Plus when you need an ITIL-aligned helpdesk with asset management, change management, and on-premises data control. ServiceNow or Jira Service Management provide managed alternatives with richer automation and ecosystem integrations. Self-hosting is justified when ITSM data must remain on-premises or when licensing models favor perpetual over subscription pricing. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports to access your server:

TCP port 8080 - to access the ServiceDesk Plus web interface.

:::

We connect to the server on which you plan to install ServiceDesk Plus.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for ServiceDesk Plus to work using the command:

sudo apt install fonts-dejavu fontconfig

Switch to the "root" user, who has administrator rights in the operating system, using the command:

sudo -i

Download the ServiceDesk Plus installer using the command:

wget https://www.manageengine.com/products/service-desk/91677414/ManageEngine_ServiceDesk_Plus_64bit.bin

Let's enable execution of the file "ManageEngine_ServiceDesk_Plus_64bit.bin" using the command:

chmod +x ManageEngine_ServiceDesk_Plus_64bit.bin

Now let's start the ServiceDesk Plus installation using the command:

./ManageEngine_ServiceDesk_Plus_64bit.bin

Next, you need to answer a few questions from the ServiceDesk Plus installer.

First, you must read and accept the terms of use of the services provided.

Press the "Enter" button to move down through the text and familiarize yourself with the terms of use of the services provided.

Press the "y" button, then "Enter", if you agree with the terms of use of the services provided.

The next step is to select the ServiceDesk Plus edition.

For a detailed comparison of ServiceDesk Plus editions, visit the official comparison page.

This guide will walk you through the installation of the "Enterprise Edition".

Specify the desired ServiceDesk Plus edition for installation and press the "Enter" button.

The next step is to choose whether you want to register for ServiceDesk Plus technical support.

Press the "n" button, then "Enter".

In the next step, you can select the folder where ServiceDesk Plus should be installed.

:::note This tutorial will walk you through installing ServiceDesk Plus into the "/opt" folder. :::

Specify the desired folder for installing ServiceDesk Plus and press the "Enter" button.

The next step is to confirm the installation of ServiceDesk Plus in the previously specified folder.

Press the "y" button, then "Enter".

Now you need to select the port on which ServiceDesk Plus will be available.

Leave the default value and press the "Enter" button.

I highly recommend leaving the default port value.

:::note The port can be changed later in the ServiceDesk Plus control panel. :::

By default, ServiceDesk Plus uses PostgreSQL as its database management system.

:::note If you need to use a different system to manage your databases, after installing ServiceDesk Plus, you can use the prepared script (changeDBServer.sh) in the "bin" folder. :::

Press the "Enter" button.

The next step will show the disk space available and required to install ServiceDesk Plus.

Press the "Enter" button.

Everything is ready to start installing ServiceDesk Plus.

Press the "Enter" button.

ServiceDesk Plus installation completed successfully.

The Problem in Initializing Postgres !!.. Kindly check logs… message should be ignored as initialization will occur the first time ServiceDesk Plus is started.

More information is available on the ManageEngine community post.

Press the "Enter" button.

Now you need to run ServiceDesk Plus for the first time.

Go to the "bin" folder using the command:

cd /opt/ServiceDesk/bin

Launch ServiceDesk Plus using the command:

sh run.sh

Now you need to wait a few minutes, then you need to go from the workstation to the link http://sdp.heyvaldemar.net:8080, where sdp.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name or IP address of your server with ServiceDesk Plus installed.

The default login for the ServiceDesk Plus administrator account is administrator

The default password for the ServiceDesk Plus administrator account is administrator

Specify the username and password of an account with ServiceDesk Plus administrator rights and click on the "Log in" button.

Welcome to the ServiceDesk Plus dashboard.

Next, you need to configure the service Autostart ServiceDesk Plus when the operating system starts.

Return to the terminal emulator and press the "Ctrl" and "c" keys on the keyboard to stop all ServiceDesk Plus services.

Now let's create a script that will contain the necessary configuration for the ServiceDesk Plus service in the "/etc/init.d/" folder using the command:

vim /etc/init.d/servicedesk

Hit the "i" button to go into edit mode, then insert the configuration.

#!/bin/bash

### BEGIN INIT INFO
# Provides:          servicedesk
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: ServiceDesk Plus
# Description:       ServiceDesk Plus init script
### END INIT INFO

INITLOG_ARGS=""

prog="servicedesk"
progname="AdventNet ManageEngine ServiceDesk-Plus"
RETVAL=0
# ServiceDesk Plus install folder (replace with yours)
MDIR=/opt/ServiceDesk/bin

if [ ! -d "$MDIR" ]
then
 echo "Invalid directory $MDIR"
    exit 1
fi

start()
{
        mv -f /var/log/servicedesk-plus.log /var/log/servicedesk-plus1.log
        echo "Starting $progname"
        cd $MDIR
        nohup sh run.sh >/var/log/servicedesk-plus.log 2>&1 &
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch /var/lock/subsys/servicedesk
}

stop()
{
        echo "Stopping $progname"
        cd $MDIR
        sh shutdown.sh -S >>/var/log/servicedesk-plus.log 2>&1
}

case "$1" in
 start)
       start
         ;;
 stop)
      stop
        ;;
    *)
     echo "Usage: $prog {start|stop}"
     exit 1
     ;;
esac

exit $RETVAL

Next, we find the "MDIR" parameter and check its value.

:::note In the "MDIR" parameter you must specify the folder where ServiceDesk Plus was installed. :::

:::note In this tutorial, ServiceDesk Plus was installed in the "/opt" folder. :::

An example of the value for the "MDIR" parameter when installing ServiceDesk Plus in the "/opt/" folder:

MDIR=/opt/ServiceDesk/bin

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Assign correct permissions for the script "/etc/init.d/servicedesk" using the command:

chmod 755 /etc/init.d/servicedesk

Add a script to startup when the operating system starts using the command:

update-rc.d servicedesk defaults

Next, create a file to store the ServiceDesk Plus log using the command:

touch /var/log/servicedesk-plus.log

Launch ServiceDesk Plus using the command:

systemctl start servicedesk

Open the ServiceDesk Plus log to check that all ServiceDesk Plus services have started correctly using the command:

less /var/log/servicedesk-plus.log

On the keyboard, press the "Shift" and "f" keys to start monitoring changes in the ServiceDesk Plus log in real-time.

All necessary services have been successfully launched.

On the keyboard, press the key combination "Ctrl" and "c", then "q" to close the ServiceDesk Plus log.

From the workstation, go to the link http://sdp.heyvaldemar.net:8080, where sdp.heyvaldemar.net is the name of my server. Accordingly, you need to provide the name or IP address of your server with ServiceDesk Plus installed.

The default login for the ServiceDesk Plus administrator account is administrator

The default password for the ServiceDesk Plus administrator account is administrator

Specify the username and password of an account with ServiceDesk Plus administrator rights and click on the "Log in" button.

You can now start working with ServiceDesk Plus.

Install Ubuntu Server 20.04 LTS

Vladimir Mikhalev (heyvaldemar.com) — Thu, 16 Jul 2020 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Ubuntu Server 20.04 LTS.

After successfully booting from the Ubuntu Server 20.04 installation USB stick or DVD, the first step is to choose which language the welcome menu will be displayed in.

Select "English" and press the "Enter" button.

Next, you can choose a keyboard layout.

Select the keyboard layout you need and click on the "Done" button.

In the next step, the installer will try to automatically obtain the settings for the network connection using DHCP.

You can set the IP address manually or configure the network connection after installation.

Click on the "Done" button.

Next, the system prompts you to specify information about the proxy server.

This guide does not use a proxy server.

Click on the "Done" button.

Next, you can specify an alternative mirror address for downloading packages.

Leave the "Mirror address" field unchanged and click on the "Done" button.

At the next step, you need to choose which disk the new operating system will be installed on and allocate space for installation.

:::note All free disk space will be allocated for the system. :::

Select "Use an entire disk", then "Set up this disk as an LVM group.

Click on the "Done" button.

In the next step, you can see what partitions will be created on the disk.

Click on the "Done" button.

Now you need to confirm your changes.

Select "Continue" and press the "Enter" button.

Next, you will need to specify the full username for the administrator account, the server name, then the login and password for the new account.

Click on the "Done" button.

If you plan to connect to the server via SSH, then you need to select "Install OpenSSH server".

:::note You can also import SSH keys from Launchpad or Github. :::

Click on the "Done" button.

In the next step, you can select additional services and components for installation from the operating system.

Click on the "Done" button.

Next, you can watch the installation process of Ubuntu Server 20.04.

The Ubuntu Server 20.04 installation is now complete.

Click on the "Reboot" button.

Now you need to remove the installation USB stick or Ubuntu Server 20.04 disk from the CD/DVD drive.

Next, you need to specify the username and password for authentication in Ubuntu, which was specified earlier during the installation of the system.

Install Grafana on Ubuntu Server

Vladimir Mikhalev (heyvaldemar.com) — Tue, 21 Apr 2020 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Grafana on Ubuntu Server.

Grafana is an open-source platform for data visualization, monitoring, and analysis.

:::tip[Architecture Context] Choose self-hosted Grafana when you need full control over dashboards, data sources, and alerting with no per-user licensing. Grafana Cloud or Datadog provide managed alternatives with built-in log aggregation and APM. Self-hosting is justified when monitoring data must remain on-premises, when you need unlimited users, or when custom plugin requirements exceed SaaS platform capabilities. :::

:::important OpenSSH must be installed on the server, and port 22 must be open to be able to connect to the server using the SSH protocol. :::

To install OpenSSH on a server, you can use the command:

sudo apt install openssh-server

:::note To connect to the server from a Windows system, you can use tools like PuTTY or MobaXterm. :::

:::note This guide walks you through connecting to a server with the iTerm2 terminal emulator on macOS. :::

:::caution You will need to open the following TCP ports for access to the services:

TCP port 80 - to get a free cryptographic certificate through Let's Encrypt CA.
TCP port 443 - to access the Grafana web interface.

:::

We connect to the server on which you plan to install Grafana.

Update the local package index to the latest changes in the repositories using the command:

sudo apt update

Now let's install the packages required for Grafana to work using the command:

sudo apt install -y apache2 apt-transport-https certbot python3-certbot-apache

Let's configure Apache for further work with Grafana.

We enable the Apache webserver module called "proxy_http" using the command:

sudo a2enmod proxy_http

:::note The "proxy_http" module acts like a proxy server for the HTTP and HTTPS protocols. :::

We enable the Apache webserver module called "rewrite" using the command:

sudo a2enmod rewrite

:::note The "rewrite" module is one of the most commonly used modules in the Apache webserver and provides a flexible and powerful way to manipulate URLs. :::

Now you need to create two virtual host files (called a block in Nginx), with which Grafana will work in the future.

Two virtual host files are required to provide access to Grafana over HTTPS, and to enable Grafana to be used at https://grafana.heyvaldemar.net, without specifying port 3000 in the browser address bar.

:::note In this tutorial, the grafana.heyvaldemar.net subdomain will be used to access Grafana from the Internet. You will need to specify your domain or subdomain by which your Grafana will be available from the Internet. :::

Let's create the first virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/grafana.heyvaldemar.net.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<VirtualHost *:80>
	ServerAdmin callvaldemar@gmail.com
	ServerName grafana.heyvaldemar.net
</VirtualHost>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Let's create a second virtual host file using a text editor using the command:

sudo vim /etc/apache2/sites-available/grafana.heyvaldemar.net-ssl.conf

Hit the "i" button to go into edit mode, then insert the following configuration for the webserver to work.

<IfModule mod_ssl.c>
<VirtualHost *:443>
	ServerAdmin callvaldemar@gmail.com
	ServerName grafana.heyvaldemar.net
	ProxyPreserveHost On

	ProxyPass / http://localhost:3000/
	ProxyPassReverse / http://localhost:3000/

	SSLEngine On
	SSLCertificateFile /etc/letsencrypt/live/grafana.heyvaldemar.net/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/grafana.heyvaldemar.net/privkey.pem
	Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

We activate the first virtual host using the command:

sudo a2ensite grafana.heyvaldemar.net.conf

We activate the second virtual host using the command:

sudo a2ensite grafana.heyvaldemar.net-ssl.conf

Deactivate the default virtual host using the command:

sudo a2dissite 000-default.conf

Verify that there are no errors in the syntax of the new Apache config file using the command:

sudo apache2ctl configtest

Restart Apache to apply the changes made using the command:

sudo systemctl restart apache2

Let's check that Apache has started successfully using the command:

sudo systemctl status apache2

Now, to increase the security level of the webserver, you need to obtain a cryptographic certificate for the domain or subdomain, through which the Grafana control panel will be available from the Internet.

Request a cryptographic certificate using the command:

sudo certbot --apache -d grafana.heyvaldemar.net

Next, we indicate the email address to which Let's Encrypt will send notifications about the expiration of the cryptographic certificate and press the "Enter" button.

The next step is to read and accept the terms of use of the services provided.

Press the button "a", then "Enter", if you agree with the terms of use of the services provided.

The next step is to choose whether you want to share the above email address with the Electronic Frontier Foundation to receive newsletters.

Press the "n" button, then "Enter".

At the next stage, you need to choose: do you want the parameters to be automatically added to the Apache configuration file for automatically redirecting HTTP traffic to HTTPS.

Press the button "2", then "Enter".

You can check the functionality of the cryptographic certificate renewal process using the command:

sudo certbot renew --dry-run

Now let's add the official Grafana key using the command:

wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -

Next, we connect the Grafana repository using the command:

sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"

Now let's install Grafana using the command:

sudo apt install -y grafana

Restart "systemd" to search for changed or new units using the command:

sudo systemctl daemon-reload

Launch Grafana using the command:

sudo systemctl start grafana-server

Let's check that Grafana has started successfully using the command:

sudo systemctl status grafana-server

We enable the autostart of the Grafana service when the operating system starts using the command:

sudo systemctl enable grafana-server.service

From the workstation, go to the link https://grafana.heyvaldemar.net, where grafana.heyvaldemar.net is the name of my subdomain to access the Grafana control panel. You will need to specify your domain or subdomain by which your Grafana control panel will be accessible from the Internet.

The default username and password for the Grafana administrator account is "admin".

Specify the username and password of an account with Grafana administrator rights and click on the "Log in" button.

Next, you need to change the password for the Grafana administrator account.

Specify a new password for the Grafana administrator account and click on the "Submit" button.

Welcome to the Grafana dashboard.

Now you need to make changes to the Grafana configuration file to disable the ability to register users without the knowledge of the Grafana administrator and to log in for anonymous users.

Open the Grafana configuration file in a text editor using the command:

sudo vim /etc/grafana/grafana.ini

Hit the "i" button to switch to edit mode, in the "users" section, find the "allow_sign_up = false" parameter and uncomment it by removing the ";" symbol.

In the "auth.anonymous" section, find the "enabled = false" parameter and uncomment it by removing the ";" symbol.

Now press the "Esc" button to exit edit mode, then type ":x" and press the "Enter" button to save your changes and exit the editor.

Restart Grafana to apply the changes made using the command:

sudo systemctl restart grafana-server

Let's check that Grafana has started successfully using the command:

sudo systemctl status grafana-server

Everything is ready to use Grafana.

Configure Exchange Server 2019

Vladimir Mikhalev (heyvaldemar.com) — Fri, 29 Nov 2019 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to configure Exchange Server 2019.

:::important We will consider the case when you already have two servers with the Windows Server 2019 operating system installed on them. In addition, one of the servers must have the Active Directory Domain Services role installed, and the second server must have Exchange Server 2019 installed. :::

:::note For step-by-step instructions on installing Exchange Server 2019 on Windows Server 2019, refer to my guide: Install Exchange Server 2019 on Windows Server 2019. :::

:::note To learn how to install Active Directory Domain Services on Windows Server 2019, read: Install Active Directory Domain Services on Windows Server 2019. :::

Open the Exchange Admin Center control panel, which is located at the link https://heva-server-2/ecp, where heva-server-2 is the name of my Exchange server. Accordingly, you need to provide the name or IP address of your server.

To access the Exchange Admin Center Control Panel, you will need to provide a username and password for an account that has Exchange Administrator rights.

Let's create a mailbox database.

In the "Servers" section, select the "Databases" subsection and click on the "+" button.

Next, you need to specify a name for the new database and select an Exchange server with the "Mailbox" role.

Specify the name of the database and click on the "Browse" button.

Select the Exchange server with the "Mailbox" role and click on the "OK" button.

Now you need to specify in which folder the mailbox database and its logs will be stored.

:::note You need to first create folders on the server in which you plan to store the database and its logs. In addition, it is better to store the database on a disk specially allocated for this task. :::

In the "Database file path" field, specify the folder where the database will be stored.

In the "Log folder path" field, specify the folder in which the database logs will be stored.

Check the "Mount this database" box and click on the "Save" button.

Now you need to restart the Microsoft Exchange Information Store service on the Exchange server.

Click on the "OK" button.

Open "Server Manager" on the server with Exchange Server 2019 installed, then click on the "Tools" button in the upper right corner of the screen and select "Services".

Right-click on the "Microsoft Exchange Information Store" service and select "Restart".

The service has restarted successfully and the new database is ready to go.

Further, in the "Servers" section, select the "Databases" subsection, and then select a new database and double-click on it with the left mouse button.

In the "Limits" section, you can configure the retention time for deleted mailboxes and letters.

Specify the required values and click on the "Save" button.

Now let's create a database for shared folders.

In the "Servers" section, select the "Databases" subsection and click on the "+" button.

Specify a name for the shared folder database and click the Browse button.

Select the Exchange server with the "Mailbox" role and click on the "OK" button.

Now you need to specify in which folder the database for public folders and its logs will be stored.

In the "Database file path" field, specify the folder where the database will be stored.

In the "Log folder path" field, specify the folder in which the database logs will be stored.

Check the "Mount this database" box and click on the "Save" button.

Now you need to restart the Microsoft Exchange Information Store service on the Exchange server.

Click on the "OK" button.

We return to the "Server Manager" on the server with Exchange Server 2019 installed, click on the "Tools" button in the upper right corner of the screen, and select "Services".

Right-click on the "Microsoft Exchange Information Store" service and select "Restart".

The service has restarted successfully and the new database is ready to go.

Next, go to the "Public Folders" section.

In the "Public Folders" section, select the "Public Folder Mailboxes" subsection and click on the "+" button.

Specify a name for the public folder mailbox and in the "Mailbox database" section click on the "Browse" button.

Select the database for shared folders and click on the "OK" button.

Nothing can be changed in the "Organization unit" section.

Click on the "Save" button.

After the public folder mailbox is created, it appears under the Public Folder Mailboxes subsection.

Now let's add the trusted domain.

In the "Mail Flow" section, select the "Accepted Domains" subsection and click on the "+" button.

In the "Name" and "Accepted Domain" fields, specify the domain that you want to add to the trusted ones, then select "Authoritative Domain: E-mail is delivered only to valid recipients in this Exchange organization".

Click on the "Save" button.

After the domain is added to the trusted ones, it will appear in the "Accepted Domains" section.

Now you need to create a policy for generating mailing addresses.

In the "Mail Flow" section, select the "Email Address Policies" subsection and click on the "+" button.

Next, you need to specify a name for the new policy and choose who it will be applied to, as well as determine how mail addresses will be generated in your organization.

:::note In this tutorial, mailing addresses will be based on "Alias". :::

Specify a name for the policy for generating postal addresses and click the "+" button.

Specify the main domain and select "alias@contoso.com".

Click on the "Save" button.

Now let's add a second domain so that users can receive mail using the second domain name as well.

Click on the "+" button.

Specify the second domain and select "alias@contoso.com".

Click the "Save" button.

After you have determined how mail addresses will be formed in your organization, click on the "Save" button.

Pay attention to the warning. In order for the policy to take effect, you must click on the "Apply" button in the "E-mail Address Policies" subsection.

After the policy is added, it will appear in the "E-mail Address Policies" subsection with the "Unapplied" status.

To apply a policy, select it and click on the "Apply" button.

Next, a warning will appear stating that applying the policy may take a long time and you will not be able to perform other tasks while the policy is being applied.

Click on the "Yes" button.

The policy for generating postal addresses has been successfully applied.

Click on the "Close" button.

After the policy is applied, it will appear in the "E-mail Address Policies" subsection with the "Applied" status.

Now you need to create a send connector: to be able to send mail outside the organization.

In the "Mail Flow" section, select the "Send Connectors" subsection and click on the "+" button.

Specify a name for the new Send Connector and select "Internet" in the "Type" section.

Click on the "Next" button.

:::note In this example, mail will be sent according to MX records. :::

Select "MX record associated with recipient domain" and click on the "Next" button.

Next, you need to specify for which domains the new connector will work.

Click on the "+" button.

In the "Full Qualified Domain Name (FQDN)" field, enter *. This way, the new Send Connector will handle all domains except yours.

Click on the "OK" button.

After you have specified for which domains the new connector will work, click on the "Next" button.

Next, you need to specify on which Exchange server the Send connector will be created.

Click on the "+" button.

Select the Exchange server on which the Send Connector will be created and click on the "OK" button.

Everything is ready to create a send connector.

Click on the "Finish" button.

Next, in the "Mail Flow" section, select the "Send Connectors" subsection, then select a new send connector and double-click on it with the left mouse button.

In the "General" section of the "Maximum send message size (MB)" menu, you can configure the maximum size of mail attachments to be sent.

Further, in the "Scoping" section, in the "Specify the FQDN this connector will provide in response to HELO or EHLO" field, specify the name by which your mail server is accessible from the Internet.

Click on the "Save" button.

In the "Mail Flow" section, select the "Send Connectors" subsection. Then click on the "..." button and select "Organization transport settings".

In the "Limits" section, you can configure the maximum size of mail attachments for sending and receiving.

Specify the required values and click on the "Save" button.

Now you need to provide your Exchange Server 2019 license key.

In the "Servers" section, select the "Servers" subsection and click on the "Edit" button.

In the "General" section, specify the Exchange Server 2019 license key and click on the "Save" button.

Now you need to configure DNS records for the domain. To do this, you need to open a web browser and go to the control panel for external DNS records for your domain.

This tutorial uses Amazon Route 53 to manage external DNS records for a domain.

Go to the AWS Management Console, sign in with an administrator account if prompted, and then click the "Services" button located in the upper-left corner of the screen.

Next, in the "Networking & Content Delivery" section, select "Route 53".

Next, select "Hosted zones".

Select the domain for which you want to configure DNS records.

Now you need to create several DNS records to access the Exchange services.

Click on the "Create Record Set" button to create a new DNS record.

Specify "mail" in the "Name" field.

In the "Type" field, select "A - IPv4 address".

In the "TTL" field, enter "300".

In the "Value" field, indicate the IP address by which your mail server is accessible from the Internet and click on the "Create" button.

Click on the "Create Record Set" button to create another DNS record.

In the "Name" field, enter "mx01".

In the "Type" field, select "A - IPv4 address".

In the "TTL" field, enter "300".

In the "Value" field, indicate the IP address by which your mail server is accessible from the Internet and click on the "Create" button.

Click on the "Create Record Set" button to create another DNS record.

Specify "autodiscover" in the "Name" field.

In the "Type" field, select "A - IPv4 address".

In the "TTL" field, enter "300".

In the "Value" field, indicate the IP address by which your mail server is accessible from the Internet and click on the "Create" button.

Click on the "Create Record Set" button to create another DNS record.

Leave the "Name" field blank.

In the "Type" field, select "MX - Mail exchange".

In the "TTL" field, enter "300".

In the "Value" field, specify the priority "10", then indicate the previously created A-record with the name "mx01" and click on the "Create" button.

Next, you need to make a request to your ISP to create a PTR record for your external IP address, where your mail server is accessible from the Internet. This is necessary in order for your IP address to resolve to a name.

:::note In this example, the IP 188.244.46.91 is translated to the name mail.heyvaldemar.net. :::

Now you need to create an SPF (Sender Policy Framework). Thanks to SPF, you can check if the sender's domain has been tampered with. SPF allows you to specify a list of servers capable of sending mail messages on behalf of your domain.

You can get parameters for SPF recording using the SPF Wizard.

SPF example: v=spf1 mx a ip4:188.244.46.91 include:heyvaldemar.com -all

Leave the "Name" field blank.

In the "Type" field, select "SPF - Sender Policy Framework".

:::note If there is no "SPF" record type in your control panel for external DNS records, then you need to select the "TXT" record type. :::

In the "TTL" field, enter "300".

In the "Value" field, specify the SPF parameters obtained using the SPF Wizard and click on the "Create" button.

DNS records for the domain have been configured successfully.

Now you need to register the A-record on the internal DNS server.

Open "Server Manager" on the domain controller, then click on the "Tools" button in the upper right corner of the screen and select "DNS".

In the "Forward Lookup Zones" section, select the main domain and right-click on it, then select "New Host (A or AAAA)".

In the "Name (uses parent domain name if blank)" field, specify "Mail".

In the "IP address" field, specify the IP address of the server on which Exchange Server 2019 is installed and click on the "Add Host" button.

A record has been successfully added.

Click on the "OK" button.

After the A-record is added, it will appear in the list with the rest of the records.

For further configuration, you need a certification authority.

:::note In this tutorial, the Active Directory Certificate Services role will be installed on a domain controller. :::

Go back to the "Server Manager" on the domain controller, then click on the "Manage" button in the upper right corner of the screen and select "Add Roles and Features".

Click on the "Next" button.

Select the installation type "Role-based or feature-based installation" and click on the "Next" button.

Next, select the server on which the role will be installed.

Click on the "Next" button.

Select the Active Directory Certificate Services role.

In the next step, the Role Installation Wizard will warn you that several components need to be installed to install the Active Directory Certificate Services role.

Click on the "Add Features" button.

Click on the "Next" button.

At the stage of adding components, we leave all the default values.

Click on the "Next" button.

Next, the Role Installation Wizard invites you to learn more about the Active Directory Certificate Services role.

Click on the "Next" button.

Now you need to select the required services.

We select "Certification Authority Web Enrollment".

In the next step, the Install Roles Wizard will warn you that several components need to be installed to install the Certification Authority Web Enrollment.

Click on the "Add Features" button.

Next, select "Online Responder".

The Role Installation Wizard will warn you that several components need to be installed to install Online Responder.

Click on the "Add Features" button.

After all the necessary services are selected, click on the "Next" button.

In the next step, the "Role Installation Wizard" will warn you that the "Internet Information Services" webserver role will be additionally installed for the "Active Directory Certificate Services" role.

At the stage of adding components, we leave all the default values.

Click on the "Next" button.

To start the installation of the selected role, click on the "Install" button.

The installation of the selected role and the components required for it has begun.

Installation of the Active Directory Domain Services role is now complete.

Now you need to configure the role.

Click on the button "Configure Active Directory Certificate Services on the destination server".

Click on the "Next" button.

Next, you need to select the services that you want to configure.

Select "Certification Authority", "Certification Authority Web Enrollment" and "Online Responder" and click on the "Next" button.

The server is a member of the domain, so select "Enterprise CA" and click on the "Next" button.

There are no other servers with the Active Directory Certificate Services role in the domain, so select "Root CA" and click on the "Next" button.

Next, you need to create a new private key.

Select "Create a new private key" and click on the "Next" button.

Next, you can select the cryptography settings.

Leave the settings unchanged and click on the "Next" button.

In the "Common name for this CA" field, specify the name for the new certification authority and click on the "Next" button.

Now we select the validity period of the certificate and click on the "Next" button.

Next, you can specify where the certificate database and its logs will be stored.

Leave the settings unchanged and click on the "Next" button.

Everything is ready to configure the role.

Click on the "Configure" button.

The Active Directory Certificate Services role is now configured.

Click on the "Close" button.

Click on the "Close" button to close the role installation window.

Now you need to enable the SAN (Subject Alternative Name) function on the CA server. This feature is useful when publishing the "Autodiscover" service.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

We enable the SAN function using the command:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Now you need to restart the "CertSvc" service.

Stop the "CertSvc" service using the command:

net stop certsvc

We start the "CertSvc" service using the command:

net start certsvc

Service "CertSvc" restarted successfully.

Now let's make a request to create a new Exchange certificate.

We return to the Exchange Admin Center control panel.

In the "Servers" section, select the "Certificates" subsection and click on the "+" button.

Select "Create a request for a certificate from a certification authority" and click on the "Next" button.

Specify a name for the new certificate and click on the "Next" button.

Then leave the settings unchanged and click on the "Next" button.

Now you need to specify the Exchange server where the certificate request will be stored.

Click on the "Browse" button.

Select the Exchange server where the certificate request will be stored and click on the "OK" button.

After the Exchange server is specified, click on the "Next" button.

Now you need to specify the domain names that need to be included in the certificate for all types of access.

Select "Outlook Web App (when accessed from the Internet)" and click on the "Edit" button.

Specify the name by which your mail server is accessible from the Internet for the "Outlook Web App" access type, and click on the "OK" button.

Select OAB (when accessed from the Internet) ", and click on the" Edit "(Pencil) button.

We indicate the name by which your mail server is accessible from the Internet for the access type "OAB", and click on the "OK" button.

Select "Exchange Web Services (when accessed from the Internet)", and click on the "Edit" button.

Specify the name by which your mail server is accessible from the Internet for the "Exchange Web Services" access type, and click on the "OK" button.

Select "Exchange ActiveSync (when accessed from the Internet)" and click on the "Edit" button.

Specify the name by which your mail server is accessible from the Internet for the "Exchange ActiveSync" access type, and click on the "OK" button.

Select "POP" and click on the "Edit" button.

We indicate the name by which your mail server is accessible from the Internet for the "POP" access type, and click on the "OK" button.

Select "IMAP" and click on the "Edit" button.

We indicate the name by which your mail server is accessible from the Internet for the type of access "IMAP", and click on the "OK" button.

Select "Outlook Anywhere" and click on the "Edit" button.

Specify the name by which your mail server is accessible from the Internet for the "Outlook Anywhere" access type and click on the "OK" button.

The domain names that must be included in the certificate for all types of access are indicated.

Click on the "Next" button.

Below is a list of domains that will be included in the certificate.

Click on the "Next" button.

Next, you must specify the name of the organization, department, and geographic location of the company.

This guide is based on an organization based in Los Angeles, USA.

We indicate the necessary information and click on the "Next" button.

Now you need to specify the folder where the Exchange certificate request will be saved.

:::note In this tutorial, the certificate request will be saved to the local "C" drive on the Exchange server. :::

Specify where the Exchange certificate request will be saved and click on the "Finish" button.

After the certificate request is created, it will appear in the "Certificates" subsection with the "Pending request" status.

Now you need to validate your Exchange certificate with a CA.

On the Exchange server, go to the link http://heva-server-1/certsrv, where heva-server-1 is the name of my certification authority server. Accordingly, you need to specify the name of your server.

We go under an account with administrator rights and click on the "OK" button.

Now let's add the address of the certification server to "Trusted sites".

Click on the "Add" button.

In the "Add this website to the zone" field, specify the address of the certification server and click on the "Add" button.

Click on the "Close" button.

Now select "Request a certificate".

Next, select "Advanced certificate request".

Now select "Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file".

Next, open "Explorer" and go to the local drive "C" where the Exchange certificate request was saved.

Click on the certificate request file twice with the left mouse button.

Click on the "Try an app on this PC" button.

Select "Notepad" and click on the "OK" button.

Copy the contents of the request file.

Next, insert the contents of the request file into the "Saved Request" field, then in the "Certificate Template" section, select "Web Server" and click on the "Submit" button.

Select "DER encoded" and click on the "Download certificate" button.

In the "Save" menu, select "Save as".

Assign a name and save the Exchange certificate to the Downloads folder.

Click on the "Save" button.

Now you need to download the CA certificate.

Click on the "Home" button in the upper right corner of the screen.

Select "Download a CA certificate, certificate chain, or CRL".

In the "Encoding method" section, select "DER" and click on the "Download CA certificate" button.

In the "Save" menu, select "Save as".

We assign a name and save the certificate of the certification authority in the "Downloads" folder.

Click on the "Save" button.

To successfully validate your Exchange certificate request, you must import the CA certificate into the Trusted Root Certification Authorities on the Exchange server.

On the keyboard, press the key combination "Win" and "R", then enter "certlm.msc" and click on the "OK" button.

In the "Certificates (Local Computer)" section, select the "Trusted Root Certification Authorities" subsection, then right-click on the "Certificates" subsection and select "All Tasks", then "Import".

Click on the "Next" button.

Next, you need to specify the path to the certificate of the certification authority.

Click on the "Browse" button.

Select the certificate of the certification authority and click on the "Open" button.

After the path to the certificate of the certification authority is indicated, click on the "Next" button.

Then leave the settings unchanged and click on the "Next" button.

Everything is ready to import the certificate into the "Trusted Root Certification Authorities".

Click on the "Finish" button.

The CA certificate has been successfully imported.

Click on the "OK" button.

We return to the Exchange Admin Center control panel.

In the "Servers" section, select the "Certificates" subsection. Then select the new Exchange certificate and click on the "Complete" button on the right.

Next, you need to specify the path to the Exchange certificate.

Specify the path to the Exchange certificate and click on the "OK" button.

After the certificate is confirmed, it will appear in the "Certificates" subsection with the "Valid" status.

Now you need to assign a new Exchange certificate for SMTP and IIS services.

Select a new certificate and double-click on it with the left mouse button.

In the "Services" section, check the boxes for "SMTP", "IMAP", "POP", and "IIS", then click on the "Save" button.

Next, a warning will appear asking you to overwrite the existing certificate for SMTP.

After the Exchange certificate is assigned to the services, the list of services in the "Assigned to services" field is updated.

Next, the Outlook Web App settings.

In the "Servers" section, select the "Virtual Directories" subsection and select the "owa (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/owa".

Now let's configure user authorization by login without having to specify a domain.

In the "Authentication" section in the "Use forms-based authentication" section, select "User name only".

Next, you need to select the main domain, click on the "Browse" button.

Select the main domain and click on the "OK" button.

After the domain is specified, click on the "Save" button.

Next, a warning will appear asking you to restart IIS.

IIS will restart later.

Click on the "OK" button.

Now let's write the address where your mail server is accessible from the Internet in the Exchange server configuration.

In the "Servers" section, select the "Virtual Directories" subsection and select the "ecp (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/ecp".

Click on the "Save" button.

In the "Servers" section, select the "Virtual Directories" subsection and select the "EWS (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/EWS/Exchange.asmx".

Click on the "Save" button.

In the "Servers" section, select the "Virtual Directories" subsection and select the "mapi (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/mapi".

Click on the "Save" button.

In the "Servers" section, select the "Virtual Directories" subsection and select the "Microsoft-Server-ActiveSync (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/Microsoft-Server-ActiveSync".

Click on the "Save" button.

In the "Servers" section, select the "Virtual Directories" subsection and select the "OAB (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/OAB".

Click on the "Save" button.

In the "Servers" section, select the "Virtual Directories" subsection and select the "PowerShell (Default Web Site)" virtual folder, and then double-click on it with the left mouse button.

In the "General" section, in the "External URL" field, specify the name by which your mail server is accessible from the Internet, and also specify "/powershell".

Click on the "Save" button.

Now let's configure the Outlook Anywhere service. This service is used to connect to the Exchange server via the Internet using "Outlook".

In the "Servers" section, select the "Servers" subsection, select the Exchange server, and double-click on it with the left mouse button.

Next, in the "Specify the external hostname such as contoso.com that users will use to connect to your organization" field, specify the name by which your mail server is accessible from the Internet. Then, in the "Specify the authentication method for external clients to use when connecting to your organization" menu, select "NTLM" and uncheck the "Allow SSL offloading" checkbox.

Click on the "Save" button.

Now let's restart IIS.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

Restart IIS using the command:

iisreset /noforce

IIS restarted successfully.

Now let's configure the ability to receive mail.

In the "Mail Flow" section, select the "Receive Connectors" subsection, select the "Default Frontend HEVA-SERVER-2" receive connector, where HEVA-SERVER-2 is the name of my Exchange server. Then click on it twice with the left mouse button.

In the "General" section, in the "Maximum receive message size" field, you can configure the maximum allowable size of mail attachments for receiving.

In the "Security" section, check for a checkmark on the "Anonymous users" item.

Click on the "Save" button.

Now let's create a new user with a mailbox.

In the "Recipients" section, select the "Mailboxes" subsection.

Click on the "+" button and select "User mailbox".

Now we specify the alias, first, and the last name for the new user.

Then you need to select the organization unit in which you plan to create a new user.

Click on the "Browse" button.

Select the OU in which you want to place the new user, and click on the "OK" button.

In the "User logon name" field, specify the login for the new user.

Next, specify a strong password and click on the "More options" button.

Now you need to select the database in which the mailbox will be created for the new user.

In the "Mailbox database" section, click on the "Browse" button.

Select the mailbox database and click on the "OK" button.

Everything is ready to create a user with a mailbox.

Click on the "Save" button.

After the user with the mailbox is created, it will appear in the "Mailboxes" section.

Now you need to import the Exchange certificate into Trusted Root Certification Authorities on all computers in the domain.

Go to the domain controller, create a folder and copy the Exchange certificate into it.

:::note In this tutorial, the certificate was copied to the "ExchangeCertificate" folder on the "C" drive. :::

Go back to "Server Manager" on the domain controller, then click on the "Tools" button in the upper right corner of the screen and select "Group Policy Management".

Now let's create a new Group Policy to import the certificate into Trusted Root Certification Authorities on all computers in the domain.

Right-click on the domain name and select "Create a GPO in this domain, and Link it here".

Specify a name for the new group policy and click on the "OK" button.

Next, click on the new policy with the right mouse button and select "Edit".

In the Group Policy Editor, go to the "Computer Configuration" section, then to the "Windows Settings" subsection, then find the "Security Settings" section and select "Public Key Policies", now right-click on "Trusted Root Certification Authorities" and select " Import ".

Click on the "Next" button.

Next, you need to specify the path to the Exchange certificate.

Click on the "Browse" button.

Go to the folder with the Exchange certificate and click on the "Open" button.

After the path to the certificate is specified, click on the "Next" button.

Then leave the settings unchanged and click on the "Next" button.

Everything is ready to import the certificate into the "Trusted Root Certification Authorities" for all computers in the domain.

Click on the "Finish" button.

The Exchange certificate has been successfully imported into Group Policy settings.

Click on the "OK" button.

After the certificate is imported into Group Policy settings, it will appear in the "Trusted Root Certification Authorities" section.

The Exchange certificate will now be imported to all computers covered by this policy.

Install Exchange Server 2019 on Windows Server 2019

Vladimir Mikhalev (heyvaldemar.com) — Mon, 25 Nov 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Exchange Server 2019 on Windows Server 2019.

:::warning This guide walks you through installing Exchange Server 2016 without implementing failover. :::

:::note The official hardware requirements for Exchange 2019 are detailed on Microsoft's website. :::

For details on installing Windows Server 2019, read my guide: Install Windows Server 2019. :::

:::important In addition, one of the servers must have the Active Directory Domain Services role installed, and the second server must be domain joined.

To learn how to install Active Directory Domain Services on Windows Server 2019, read: Install Active Directory Domain Services on Windows Server 2019. :::

:::note After installing Exchange Server 2019, follow my guide to complete the configuration: Configure Exchange Server 2019. :::

:::important This guide covers the installation of Exchange Server 2019 Cumulative Update 3 (Exchange 2019 CU3, released: September 2019). You need to download the current Cumulative Update at the time of reading the article. Each CU is a complete Exchange installation that includes updates and changes from all previous CUs. You don't need to install previous CUs or Exchange 2019 RTM. :::

:::warning Windows Server 2019 requires all available updates to be installed before installing Exchange Server 2019. :::

On the future Exchange server, go to the system under an account that consists of the following groups: Enterprise Admins, Schema Admins, and Domain Admins.

Before preparing Active Directory and installing Exchange Server 2019, you need to install additional software on the future Exchange server:

Visual C++ Redistributable Package for Visual Studio 2012
Visual C++ Redistributable Package for Visual Studio 2013
Unified Communications Managed API 4.0

Install Visual C++ Redistributable Package for Visual Studio 2012.

Go to the Microsoft download page and select the "Download" button to begin the process.

Select "VSU_4\vcredist_x64.exe" and click on the "Next" button.

Run the downloaded Visual C++ Redistributable Package for Visual Studio 2012 installer file.

Next, you must accept the license terms, if you agree with them, and click on the "Install" button.

Installation of Visual C++ Redistributable Package for Visual Studio 2012 completed successfully.

Click on the "Close" button.

Now let's install Visual C++ Redistributable Package for Visual Studio 2013.

Navigate to the official download page and click the "Download" button to get started.

Select "vcredist_x64.exe" and click on the "Next" button.

Run the downloaded Visual C++ Redistributable Package for Visual Studio 2013 installer file.

Next, you must accept the license terms, if you agree with them, and click on the "Install" button.

Installation of Visual C++ Redistributable Package for Visual Studio 2013 completed successfully.

Click on the "Close" button.

Now let's install Unified Communications Managed API 4.0.

Visit the Microsoft download page and click the "Download" button to proceed.

Run the downloaded Unified Communications Managed API 4.0 installer file.

The "Unified Communications Managed API 4.0 Installation Wizard" will open.

Click on the "Next" button.

Next, you must accept the license terms, if you agree with them, and click on the "Next" button.

The installation process for "Unified Communications Managed API 4.0" has begun.

Installation of "Unified Communications Managed API 4.0" completed successfully.

Click on the "Finish" button.

Now you need to install the remote administration tools to prepare Active Directory for the Exchange Serve 2019 installation, as well as other components required for the Exchange server to work.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

Install the remote administration tools for the subsequent preparation of Active Directory for the installation of Exchange Server 2019 using the command:

Install-WindowsFeature RSAT-ADDS

The process of installing the remote administration tools has begun.

The installation process for the remote administration tools has completed successfully.

Next, you need to install the prerequisites for Lync Server or Skype for Business Server using the command:

Install-WindowsFeature Server-Media-Foundation

The prerequisites installation process for Lync Server or Skype for Business has begun.

Installation of prerequisites for Lync Server or Skype for Business completed successfully.

Now you need to install additional components required for the Exchange server using the command:

Install-WindowsFeature NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS

The process of installing additional components required for the Exchange Server has begun.

The installation of the additional components required for the Exchange Server has been completed successfully.

Now you need to reboot the server.

On the keyboard, press the key combination "Win" and "x", in the menu that opens, select "Shut down or sign out", then "Restart".

In the window that opens, select "Other (Planned)" and click on the "Continue" button.

The server will start to reboot.

Now you need to prepare Active Directory to work with Exchange Server.

On the future Exchange server, go to the system under an account that consists of the following groups: Enterprise Admins, Schema Admins, and Domain Admins.

On the keyboard, press the key combination "Win" and "x" and in the menu that opens, select "Windows PowerShell (Admin)".

Go to drive "D" (virtual drive), where the Exchange Server 2019 installation files are located, using the command:

cd D:\

Let's prepare the Active Directory schema to work with Exchange Server using the command:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareSchema

The process of preparing the Active Directory schema has begun.

The Active Directory schema preparation process completed successfully.

Now you need to prepare containers, objects, and other Active Directory components and create the Exchange organization.

:::note After "OrganizationName" you must indicate the name of your organization in English. :::

Let's prepare containers, objects, and other Active Directory components, as well as create an Exchange organization, using the command:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD /OrganizationName:"heyvaldemar"

:::note This manual uses the organization's name "heyvaldemar". :::

The process of preparing containers, objects, and other Active Directory components has begun.

The preparation process for containers, objects, and other Active Directory components has been completed successfully.

Now you need to prepare the domain for the Exchange Server installation.

Prepare a domain for installing Exchange Server using the command:

E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareDomain:heyvaldemar.net

:::note This tutorial uses the heyvaldemar.net domain. :::

The process of preparing the domain has begun.

The domain preparation process has completed successfully.

Now you can start installing Exchange Server 2019.

Go to drive "D" (virtual drive) where the Exchange Server 2019 installation files are located and run "Setup.exe".

At this point, you can check for updates to Exchange Server 2019.

Select "Connect to the Internet and check for updates" and click on the "Next" button.

There are currently no updates for Exchange Server 2019.

Click on the "Next" button.

Next, the "Exchange Server Setup Wizard" invites you to familiarize yourself with information regarding Exchange Server 2019.

Click on the "Next" button.

Next, you must accept the license terms, if you agree with them, and click on the "Next" button.

We select "Don't use recommended settings" so that the Exchange server does not automatically send error reports and other information on the use of the Exchange server to Microsoft.

Click "Next".

Now you need to choose which roles will be installed on your server.

Select "Mailbox role", then select "Automatically install Windows Server roles and features that are required to install Exchange Server" and click on the "Next" button.

Next, you can select the directory where Exchange Server 2019 should be installed.

Leave the settings unchanged and click on the "Next" button.

You can now configure your anti-malware settings.

In the "Disable malware scanning" item, select "No" and click on the "Next" button.

Next, the process of checking readiness for installation will begin, after it is completed, you can start the installation process for Exchange Server 2019.

Click on the "Install" button.

The installation process for Exchange Server 2019 has begun.

Exchange Server 2019 installation completed successfully.

Select "Launch Exchange Administration Center after finishing Exchange setup" and click on the "Finish" button.

:::note The Exchange Administration Center is used to administer the Exchange server, available at https://heva-server-2/ecp, where heva-server-2 is the name of my Exchange server. Accordingly, you need to specify the name or IP address of your server with Exchange Server 2019 installed. :::

To display the Exchange Administration Center Control Panel correctly, you must add the Exchange Server address to Trusted Sites in Internet Explorer.

Click on the "Add" button.

In the "Add this website to the zone" field, specify the address of the Exchange server and click on the "Add" button.

The Exchange server address has been added to the list of trusted sites.

Click on the "Close" button.

Next, you need to specify the username and password of an account with Exchange administrator rights and click on the "Sign in" button.

Welcome to the Exchange Admin Center Control Panel.

You can now check the status of the Exchange Server services.

From the Start menu, find "Microsoft Exchange Server 2019" and select "Exchange Management Shell".

Let's check the status of the Exchange Server services using the command:

Test-ServiceHealth

Service check completed successfully.

A "True" value in "RequireServiceRunning" indicates that the services are running.

Configure Amazon S3 for Rocket.Chat File Sharing

Vladimir Mikhalev (heyvaldemar.com) — Mon, 18 Nov 2019 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to configure Amazon S3 for Rocket.Chat file sharing.

Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript for organizations with high standards of data protection.

:::tip[Architecture Context] Choose S3 for Rocket.Chat file storage when you need scalable, durable object storage with fine-grained IAM policies. MinIO provides a self-hosted S3-compatible alternative for on-premises deployments. S3 is the right choice when your infrastructure already runs on AWS. MinIO is justified when data residency requires on-premises storage or when you need to avoid cloud egress costs. :::

:::note For details on installing Rocket.Chat on Ubuntu Server, read my guide: Install Rocket.Chat on Ubuntu Server. :::

:::important You must have an account with administrator rights to Amazon Web Services. :::

:::important To set up file sharing, you need to have administrator rights in Rocket.Chat. :::

First, let's create a bucket using Amazon S3. It will allow you to store files that Rocket.Chat users will exchange.

Go to the Amazon S3 Console, sign in with an account that has administrator rights (if necessary), and click the "Create bucket" button.

In the "Bucket name" field, specify a unique DNS-compatible name for the bucket.

Note a few important things when creating a new bucket name:

The bucket name must be unique across all existing buckets in Amazon S3.
Once the basket is created, you cannot change its name.
Choose a bucket name that reflects the purpose of the items you plan to store in it. This is important because the bucket name appears in the URL that points to the items in it.

:::note This tutorial will use "rocketchat-heyvaldemar" as the bucket name. :::

In the "Region" field, indicate the desired region in which the basket will be created.

Click on the "Create" button.

The cart has been successfully created.

Now you need to configure the access rights to the basket so that Rocket.Chat users can share files using this basket.

We select the previously created basket.

Go to the "Permissions" tab, then select "CORS configuration".

Next, we insert the following configuration for the basket to work.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
	<AllowedOrigin>https://rocketchat.heyvaldemar.net</AllowedOrigin>
	<AllowedMethod>PUT</AllowedMethod>
	<AllowedMethod>POST</AllowedMethod>
	<AllowedMethod>GET</AllowedMethod>
	<AllowedMethod>HEAD</AllowedMethod>
	<MaxAgeSeconds>3000</MaxAgeSeconds>
	<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

:::note In this guide, you will use the rocketchat.heyvaldemar.net subdomain to access Rocket.Chat from the Internet. You will need to specify your domain or subdomain by which Rocket.Chat will be accessible from the Internet. :::

Click on the "Save" button.

The changes were saved successfully.

Now you need to create a policy to access the previously created S3 bucket.

Click on the "Services" button and select "IAM" in the "Security, Identity & Compliance" section.

Next, go to the "Policies" section and click on the "Create policy" button.

Go to the "JSON" tab.

Insert the following parameters for the policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::rocketchat-heyvaldemar"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl",
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::rocketchat-heyvaldemar/*"
        }
    ]
}

This guide uses "rocketchat-heyvaldemar" as the bucket name. You will need to provide your cart name.

Click on the "Review policy" button.

In the "Name" field, specify the name for the new policy and click on the "Create Policy" button.

:::note In this tutorial, "RocketChatFileUpload" will be used as the policy name to access the previously created bucket. :::

The policy has been successfully created.

Now you need to create a new user and assign him the previously created basket access policy. This user will be required to connect Rocket.Chat to S3 bucket.

Go to the "Users" section and click on the "Add users" button.

In the "User name" field, specify the name for the new user and click on the "Next: Permissions" button.

:::note In this manual, "rocketchat-upload" will be used as the username. :::

Next, select "Attach existing policies directly".

In the search bar, specify the name of the previously created policy and in the search result, select the desired policy.

:::note In this tutorial, "RocketChatFileUpload" is used as the name of the policy to access the previously created bucket. :::

Click on the "Next: Tags" button.

In the next step, you do not have to make any changes.

Click on the "Next: Review" button.

Everything is ready to create a new user.

Click on the "Create user" button.

The user has been successfully created and has the necessary permissions to access the previously created S3 bucket.

Now you need to save the received "Access key ID" and "Secret access key". This data will be needed to connect Rocket.Chat to a previously created basket.

Click on the "Show" button to display the contents of the "Secret access key" section and save the contents of the section to a safe place.

Click on the "Close" button.

The new user will appear in the "Users" section.

Now we need to find the code for the region in which the cart was created.

Visit the AWS documentation page and locate the appropriate region code in the "Region" column next to the "Region Name." Make sure it matches the region where the bucket was created.

:::note In this manual, the bucket was created in the "EU (Frankfurt)" region, so the required region code value is "eu-central-1". :::

Now you need to specify the parameters for connecting Rocket.Chat to the previously created basket.

Go to Rocket.Chat under an account with administrator rights, click on the icon with three dots in the upper left corner of the screen and select "Administration".

Next, we find the "File Upload" section.

File Uploads Enabled must be set to True.

Protect Uploaded Files must be set to True.

File Uploads Enabled must be set to True.

The "Enable Json Web Tokens protection to file uploads" parameter must be set to "True".

In the "Storage Type" field, select "AmazonS3".

File Uploads Enabled in Direct Messages must be set to True.

Click on the "Save Changes" button.

Next, you need to specify the parameters in the "Amazon S3" subsection.

In the "Bucket name" field, specify the name of the previously created bucket.

In the "Access Key" field, specify the "Access key ID" obtained earlier after creating a user.

In the "Secret Key" field, enter the "Secret access key" obtained earlier after creating the user.

Enter the bucket region code, retrieved earlier from the AWS region list, into the "Region" field.

The "Proxy Avatars" parameter must be set to "True".

Proxy Uploads must be True.

Click on the "Save Changes" button.

Now let's upload a file from a computer to a common channel called IT to check the correctness of uploading files to Rocket.Chat using the Amazon S3 service.

Open a channel in Rocket.Chat, then in the lower right corner of the screen, click on the plus icon and select "Computer".

Select the file you want to upload.

The file is ready to upload.

Click on the "Send" button.

The file has been uploaded successfully and is available to all members of the IT channel in Rocket.Chat.

Rocket.Chat users can now share files using the Amazon S3 service.

Rocket.Chat in Slack Color

Vladimir Mikhalev (heyvaldemar.com) — Tue, 12 Nov 2019 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to make Rocket.Chat in Slack Color.

Rocket.Chat is an open-source fully customizable communications platform developed in JavaScript for organizations with high standards of data protection.

:::note For details on installing Rocket.Chat on Ubuntu Server, read my guide: Install Rocket.Chat on Ubuntu Server. :::

:::important You need to have administrator rights in Rocket.Chat to change the color palette. :::

Click on the icon with three dots in the upper left corner of the screen and select "Administration".

Next, find the "Layout" section and open the "Colors" subsection.

Change the colors to the ones below:

Primary: #3F0E40
Primary Darkest: #350D36
Primary Dark: #1164A3
Primary Light: #FFFFFF
Link Active: #1164A3

Click on the "Save Changes" button.

Rocket.Chat will now look more like Slack.

To update the color palette in the web interface and in the Rocket.Chat client for Windows and Linux, use the keyboard shortcut "Ctrl" and "R".

To update the color palette in the Rocket.Chat client for macOS, you must use the keyboard shortcut "Command" and "R".

Install Windows Admin Center on Windows Server 2019 Server Core

Vladimir Mikhalev (heyvaldemar.com) — Wed, 23 Oct 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Windows Admin Center on Windows Server 2019 Server Core.

:::important We will consider the case when you already have two servers with the Windows Server 2019 Server Core operating system installed on them.

You can read more about how to install Windows Server 2019 in my guide Install Windows Server 2019 Server Core. :::

:::important In addition, one of the servers must have the Active Directory Domain Services role installed, and the second server must be domain joined.

To learn how to install Active Directory Domain Services on Windows Server 2019, read: Install Active Directory Domain Services on Windows Server 2019.

To learn how to install Active Directory Domain Services on Windows Server 2019 Server Core (without a GUI), see my guide: Install Active Directory Domain Services on Windows Server 2019 Server Core. :::

:::note In this guide, heva-server-2.heyvaldemar.net will be used as the name of the server on which Windows Admin Center is installed. :::

We go into the system under an account with administrator rights and start Windows PowerShell using the command:

powershell

Download the Windows Admin Center installer to the Temp folder using the command:

Start-BitsTransfer -Source http://aka.ms/WACDownload -Destination C:\Windows\Temp\wac.msi

The Windows Admin Center Installer download process has begun.

The installer has been successfully downloaded to the "Temp" folder.

Now let's start the Windows Admin Center installation using the command:

msiexec /i C:\Windows\Temp\wac.msi /qn /L*v log.txt SME_PORT=443 SSL_CERTIFICATE-OPTION=generate

Windows Admin Center has been successfully installed.

To access the Windows Admin Center control panel, you need to go to the link https://heva-server-2.heyvaldemar.net from a workstation, where heva-server-2.heyvaldemar.net is the name of my server. Accordingly, you need to specify the name or IP address of your server with Windows Admin Center installed.

:::note In this manual, Google Chrome is used as the web browser to connect to the "Windows Admin Center". :::

In the next step, you can see the warning "Your connection is not private".

Click on the button "Proceed to heva-server-2.heyvaldemar.net (unsafe)".

Next, you need to specify the username and password of an account with administrator rights on the server with Windows Admin Center installed.

Click on the "Sign in" button.

Welcome to the Windows Admin Center Control Panel.

Click on the "Skip tour" button to immediately start working with Windows Admin Center.

Now let's add the server that we plan to manage using Windows Admin Center.

Click on the "Add" button located in the upper left corner of the screen.

In the menu that opens, select "Servers".

Next, you need to go to the "Search Active Directory" tab to add a server that is included in the domain.

In the "Server name" field, specify the name of the server and click on the "Search" button.

:::note In this tutorial, heva-server-1.heyvaldemar.net will be used as the server that you plan to add to the Windows Admin Center. :::

Select the found server and click on the "Add" button.

The server has been successfully added to Windows Admin Center.

Now you can connect to it and control it.

We click once with the left mouse button on the server you plan to manage to connect to it.

Next, you need to select "Use another account for this connection" and specify the username and password of an account with administrator rights on the server that you plan to manage.

You can also check the box "Use these credentials for all connections" to use the specified account for other connections.

Click on the "Continue" button.

The connection to the server has been successfully established.

You can now manage the server using Windows Admin Center.

Install Firmware for Kernel Drivers on Ubuntu

Vladimir Mikhalev (heyvaldemar.com) — Mon, 21 Oct 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing firmware for kernel drivers on Ubuntu.

Visit the linux-firmware directory, then locate and copy the URL of the latest .deb file for the "linux-firmware" package.

Create a new directory for the "linux-firmware" package using the command:

mkdir /tmp/linux-firmware

Go to the new directory using the command:

cd /tmp/linux-firmware

Download the new version of the "linux-headers" package with the ".deb" extension using the command:

wget https://mirrors.edge.kernel.org/ubuntu/pool/main/l/linux-firmware/linux-firmware_1.183_all.deb

Now you need to install the downloaded package using the command:

sudo dpkg -i *.deb

Specify the password for the account and press "Enter".

We reboot the operating system using the command:

sudo reboot

Join Windows Server 2019 Server Core to a Domain

Vladimir Mikhalev (heyvaldemar.com) — Fri, 06 Sep 2019 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to join Windows Server 2019 Server Core to a Domain.

You can read more about how to install Windows Server 2019 in my guide Install Windows Server 2019 Server Core. :::

:::important To learn how to install Active Directory Domain Services on Windows Server 2019, read: Install Active Directory Domain Services on Windows Server 2019.

:::important Before joining a server to a domain, you must give the server a correct name according to your organization's standards, and then assign a static IP address, subnet mask, gateway, and the IP address of the domain controller as a DNS server in the network interface settings. :::

We go into the system under an account with administrator rights and start Windows PowerShell using the command:

powershell

:::note In this guide, the server joins the heyvaldemar.net domain using an Administrator account that has domain administrator rights. :::

Join the server to the domain using the command:

Add-Computer -DomainName heyvaldemar.net -Credential heyvaldemar\Administrator -Restart -Force

Specify the password for an account with domain administrator rights and click on the "OK" button.

After a reboot, the server will apply the security policies used in your domain.

After applying the security policies, the server will be ready to work.

Install Active Directory Domain Services on Windows Server 2019

Vladimir Mikhalev (heyvaldemar.com) — Fri, 30 Aug 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Active Directory Domain Services on Windows Server 2019.

:::important In this guide, we will consider the case when you already have a server with the Windows Server 2019 operating system installed on it.

For details on installing Windows Server 2019, read my guide: Install Windows Server 2019. :::

:::note To learn how to install Active Directory Domain Services on Windows Server 2019 Server Core (without a GUI), read: Install Active Directory Domain Services on Windows Server 2019 Server Core. :::

:::caution Before installing the Active Directory Domain Services role, make sure to assign the server a proper name according to your organization's standards. Then, configure a static IP address, subnet mask, gateway, and DNS server address. :::

We go into the system under an account with administrator rights and on the keyboard press the combination of keys "Win" and "X", then select "System" in the menu that opens.

Choose "Rename this PC".

I highly recommend that you think ahead about the name of the servers in your organization.

Next, specify the new server name and click on the "Next" button.

Now the system will offer to restart the server for the new settings to take effect.

Click on the "Restart now" button.

Select "Operating System: Reconfiguration (Planned)" as the reason for the server reboot and click on the "Continue" button.

Next, the server will start to reboot.

Now you need to register a static IP address in the network connection settings.

We go into the system under an account with administrator rights and on the keyboard press the combination of keys "Win" and "X", then select "Network Connections" in the menu that opens.

Next, select "Change adapter options".

Now right-click on the "Ethernet" network connection and select "Properties".

Select "Internet Protocol Version 4" and click on the "Properties" button.

Next, select the "Use the following IP address" item and specify a free IP address, subnet mask, and gateway.

:::note You must understand in advance how your network works and know which IP addresses are available. :::

In the "Preferred DNS server" field, specify the IP address of this server, since your server will have the "DNS Server" role, which is installed together with the "Active Directory Domain Services" role.

Click on the "OK" button.

In the "Ethernet Properties" window, click on the "Close" button.

You can now begin installing the Active Directory Domain Services role.

Open the "Server Manager", click on the "Manage" button in the upper right corner of the screen and select "Add Roles and Features".

Click on the "Next" button.

Select the installation type "Role-based or feature-based installation" and click on the "Next" button.

Next, select the server on which the role will be installed.

Click on the "Next" button.

Select the "Active Directory Domain Services" role.

In the next step, the Role Installation Wizard will warn you that several components need to be installed to install the Active Directory Domain Services role.

Click on the "Add Features" button.

It is not necessary to select the DNS Server role at this point. It will be installed later.

Click on the "Next" button.

At the stage of adding components, we leave all the default values.

Click on the "Next" button.

Next, the "Role Installation Wizard" invites you to familiarize yourself with additional information regarding the "Active Directory Domain Services" role.

Click on the "Next" button.

To start the installation of the selected role, click on the "Install" button.

The installation of the selected role and the components required for it has begun.

Installation of the Active Directory Domain Services role is now complete.

Now click on the "Promote this server to a domain controller" button to promote your server to the domain controller level.

I highly recommend that you think ahead about which domain name you will use when adding a new forest.

:::note In this tutorial, we will add a new forest, so in the "Active Directory Domain Services Configuration Wizard" window, select the "Add a new forest" item and in the "Root domain name" field, specify the desired name for the root domain. :::

Click on the "Next" button.

The next step is to select the functional level of the new forest and root domain. If you are adding a new forest and plan to use servers based on the Windows Server 2019 operating system in the future, you do not have to change the functional level of the forest and root domain.

Specify the password for DSRM (Directory Service Restore Mode) and click on the "Next" button.

At this point, the AD DS Configuration Wizard will warn you that a delegation for this DNS server cannot be created.

Click on the "Next" button.

Next, you can change the NetBIOS name that was assigned to your domain. I recommend leaving the default NetBIOS value.

Click on the "Next" button.

You can now change the paths for the AD DS database directories, log files and the SYSVOL folder. I recommend leaving these default values.

Click on the "Next" button.

The next step displays a summary of the server configuration.

Click on the "Next" button.

Next, the "AD DS Configuration Wizard" will check if all prerequisites have been met and display a report.

All prerequisite checks are passed successfully means all prerequisite checks are passed.

Click on the "Install" button.

The process of promoting the server to a domain controller has begun.

After your server is promoted to a domain controller, the server will automatically reboot.

Before the server starts to reboot, you will see a warning.

The promotion of the server to the domain controller is completed.

You can use the Active Directory Administrative Center or the Active Directory Users and Computers snap-in to manage users, groups, and other Active Directory objects.

We go into the system under an account with domain administrator rights.

Open Server Manager, click on the "Tools" button in the upper right corner of the screen, and select "Active Directory Administrative Center".

The Active Directory Administrative Center will open.

You can also use the Active Directory Users and Computers snap-in to manage users, groups, and other objects in the Active Directory.

In Server Manager, click on the "Tools" button in the upper right corner of the screen and select "Active Directory Users and Computers".

The Active Directory Users and Computers snap-in opens.

Install Active Directory Domain Services on Windows Server 2019 Server Core

Vladimir Mikhalev (heyvaldemar.com) — Fri, 30 Aug 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Active Directory Domain Services on Windows Server 2019 Server Core.

:::important In this guide, we will consider the case when you already have a server with the Windows Server 2019 Server Core operating system installed on it.

For details on installing Windows Server 2019, read my guide: Install Windows Server 2019. :::

:::note To learn how to install Active Directory Domain Services on Windows Server 2019, read: Install Active Directory Domain Services on Windows Server 2019. :::

We go into the system under an account with administrator rights and start Windows PowerShell using the command:

powershell

I highly recommend that you think ahead about the name of the servers in your organization.

:::note This tutorial will use "heyvaldemar-server-1" as the new server name. :::

We give the server a new name, and then reboot it for the changes to take effect using the command:

Rename-Computer -NewName heyvaldemar-server-1 -Restart

Since the selected server name contains more than 15 characters, the system notifies that the NetBIOS name for the server will be truncated to 15 characters.

Press the "y" button, then "Enter".

After restarting the server, log in again under an account with administrator rights and start Windows PowerShell using the command:

powershell

Now you need to assign a static IP address, subnet mask, gateway, and DNS server address to the server.

To configure a network interface, you need to find out its index using the command:

Get-NetIPAddress

In this case, the network interface is indexed "4".

:::note In this guide, the server will be assigned an IP address of 192.168.1.10, a subnet mask of 255.255.255.0 (24), and a gateway of 192.168.1.1. :::

:::note You must understand in advance how your network works and know which IP addresses are available. :::

We assign the server an IP address, mask, and gateway, specifying the previously obtained index of the network interface, using the command:

New-NetIPAddress -InterfaceIndex 4 -IPAddress 192.168.1.10 -PrefixLength 24 -DefaultGateway 192.168.1.1

As the DNS server, you must specify the IP address of the current server, since it will have the DNS Server role, which is installed with the Active Directory Domain Services role.

We register the IP address of the DNS server using the command:

Set-DnsClientServerAddress -InterfaceIndex 4 -ServerAddresses 192.168.1.10

Check that the server is assigned the correct IP address, subnet mask, gateway, and DNS server address using the command:

ipconfig /all

The server has been assigned the correct IP address, subnet mask, gateway, and DNS server address.

Now let's connect to the server from a personal computer using Windows PowerShell remote management tools.

:::note In this guide, Windows 10 is used as the operating system on a personal computer. For installation instructions, refer to Install Windows 10. :::

:::note To enable Windows PowerShell Remote Management, the user must have local administrator rights on their computer. :::

On the keyboard, press the key combination "Win" and "x", then select "Windows PowerShell (Admin)" in the menu that opens.

To connect to the server from a personal computer, you need to change the network category from "Public" to "Private". To do this, you need to find out the index of the network interface using the command:

Get-NetConnectionProfile

In this case, the network interface is indexed "6".

Let's change the network category from "Public" to "Private" by specifying the previously obtained index of the network interface using the command:

Set-NetConnectionProfile -InterfaceIndex 6 -NetworkCategory Private

Now let's enable the tools for remote administration using the command:

Enable-PSRemoting -force

To trust any computer on the network to make a remote connection, run the command:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

At the next step, the system will notify that the entered command will make changes to the list of trusted hosts.

Press the "y" button, then "Enter".

:::note In this guide, the server is assigned the IP address 192.168.1.10 and the name heyvaldemar-server-1, and uses the Administrator account to manage the operating system on the server. :::

We connect to the server using the command:

Enter-PSSession -ComputerName 192.168.1.10 -Credential heyvaldemar-server-1\Administrator

Specify the password for an account with administrator rights and click on the "OK" button.

The connection to the server has been established.

You are now ready to install the Active Directory Domain Services role.

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

The installation of the selected role and the components required for it has begun.

To increase the role of your server to the level of a domain controller, run the command:

Install-ADDSForest -DomainName "heyvaldemar.net" -CreateDnsDelegation:$false -DatabasePath "C:\Windows\NTDS" -DomainMode "7" -DomainNetbiosName "HEYVALDEMAR" -ForestMode "7" -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$True -SysvolPath "C:\Windows\SYSVOL" -Force:$true

Specify the password for DSRM (Directory Service Restore Mode) and press the "Enter" button.

Specify the previously entered password again and press the "Enter" button.

The process of promoting the server to a domain controller has begun.

Server promotion to a domain controller is complete.

We return to the server and reload it using the command:

shutdown -r

Before the server starts to reboot, you will see a warning.

We will now reconnect to the server from our personal computer using the Windows PowerShell remote management tools to confirm the successful installation of the services.

:::note In this manual, the server is assigned the IP address 192.168.1.10, in addition, the server is a domain controller heyvaldemar.net, and the Administrator account is used to manage the operating system on the server. :::

We connect to the server using the command:

Enter-PSSession -ComputerName 192.168.1.10 -Credential heyvaldemar\Administrator

Specify the password for an account with domain administrator rights and click on the "OK" button.

The connection to the server has been established.

Check the status of the services required for the domain controller to work using the command:

Get-Service adws,kdc,netlogon,dns

The services required for the domain controller are running.

To view detailed information about configuring a domain controller, you can run the command:

Get-ADDomainController

To view detailed information about the Active Directory domain, you can run the command:

Get-ADDomain heyvaldemar.net

To view detailed information about the Active Directory forest, you can run the command:

Get-ADForest heyvaldemar.net

To check the availability of the SYSVOL shared folder, you can run the command:

Get-smbshare SYSVOL

The shared folder "SYSVOL" is available. It is used to provide clients with Group Policy settings and logon and logon scripts.

We return to the workstation.

Now you can install the remote administration tools on your personal computer to manage the roles available on the server using a graphical interface.

:::note In Windows 10 (version 1903), the installation of the RSAT (Remote Server Administration Tools) components can be performed through the Windows graphical interface. :::

For earlier versions of Windows 10, the RSAT installer must be downloaded from the Microsoft download page.

On the keyboard, press the key combination "Win" and "x", then select "Apps and Features" in the menu that opens.

Next, select "Optional Features".

Now choose "Add a feature".

To install Active Directory remote administration tools, select "RSAT: Active Directory Domain Services and Lightweight Directory Services Tools" and click on the "Install" button.

To install the remote DNS administration tools, select "RSAT: DNS Server Tools" and click on the "Install" button.

To install the Group Policy remote administration tools, select "RSAT: Group Policy Management Tools" and click on the "Install" button.

Now you will be able to manage the roles available on the server using a graphical interface.

Installed remote administration tools can be found in the Start menu under Windows Administrative Tools.

Update Kernel in Ubuntu

Vladimir Mikhalev (heyvaldemar.com) — Wed, 28 Aug 2019 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to update kernel in Ubuntu.

Let's check the current version of the kernel. Open Terminal and execute the command:

uname -r

Create a new directory that will be needed for Ubuntu kernel update packages using the command:

mkdir /tmp/kernel

Go to the new directory using the command:

cd /tmp/kernel

Next, visit the Ubuntu mainline kernel archive and choose the version you wish to update your kernel to.

Next, you need to download the "generic" or "low latency" packages.

Packages "generic" are intended for operating systems used for typical tasks.
Packages "low latency" are intended for operating systems used to work with audio and video.

The operating system used for typical tasks will require the following packages:

The package that contains "linux-headers" and "all" in the name, located in the section corresponding to your processor architecture.
The package that contains "linux-headers" and "generic" in the name, located in the section corresponding to your processor architecture.
The package that contains "linux-image-unsigned" and "generic" in the name, found in the section corresponding to your processor architecture.
The package that contains "linux-modules" and "generic" in the name, located in the section corresponding to your processor architecture.

Download the package, which contains "linux-headers" and "all" in the name, and is located in the section corresponding to your processor architecture, using the command:

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.10/linux-headers-5.2.10-050210_5.2.10-050210.201908251538_all.deb

Download the package, which contains "linux-headers" and "generic" in the name, and is located in the section corresponding to your processor architecture, using the command:

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.10/linux-headers-5.2.10-050210-generic_5.2.10-050210.201908251538_amd64.deb

Download the package, which contains "linux-image-unsigned" and "generic" in the name, and is located in the section corresponding to your processor architecture, using the command:

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.10/linux-image-unsigned-5.2.10-050210-generic_5.2.10-050210.201908251538_amd64.deb

Download the package, which contains "linux-modules" and "generic" in the name, and is located in the section corresponding to your processor architecture, using the command:

wget https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.2.10/linux-modules-5.2.10-050210-generic_5.2.10-050210.201908251538_amd64.deb

Now you need to install all downloaded packages using the command:

sudo dpkg -i *.deb

Specify the password for the account and press "Enter".

We reboot the operating system using the command:

sudo reboot

Let's check the kernel version.

Open Terminal and execute the command:

uname -r

You should see a new version of the kernel.

Install Minecraft on Windows

Vladimir Mikhalev (heyvaldemar.com) — Fri, 19 Jul 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Minecraft on Windows.

If you've purchased a license, you can begin downloading and installing the game. Visit the Minecraft download page and click the "Download" button under the "Download Minecraft: Java Edition for Windows" section.

Go to "Downloads" and run "MinecraftInstaller.msi".

Click on the "Next" button.

Next, you can choose where to install Minecraft.

Click on the "Next" button.

You can begin the Minecraft installation process.

Click on the "Install" button.

Minecraft installation completed successfully.

Check the box "Start Minecraft after closing the installer" and click on the "Finish" button.

Click on the "Login" button.

I wish you all a pleasant game!

Install Ubuntu Server 18.04 LTS

Vladimir Mikhalev (heyvaldemar.com) — Fri, 12 Jul 2019 00:00:00 GMT

This article is for those looking for a detailed and straightforward guide on installing Ubuntu Server 18.04 LTS.

After successfully booting from the Ubuntu Server 18.04 installation USB stick or DVD, the first step is to choose which language the welcome menu will be displayed in.

Select "English" and press the "Enter" button.

Next, you can choose a keyboard layout.

Select the keyboard layout you need and click on the "Done" button.

Next, you need to select the option to install Ubuntu Server.

:::note This tutorial does not cover the installation of MAAS (Metal as a Service). If you plan to use MAAS, I recommend that you read the documentation for more information. :::

Select "Install Ubuntu" and press the "Enter" button.

In the next step, the installer will try to automatically obtain the settings for the network connection using DHCP.

You can set the IP address manually or configure the network connection after installation.

Click on the "Done" button.

Next, the system prompts you to specify information about the proxy server.

This guide does not use a proxy server.

Click on the "Done" button.

Next, you can specify an alternative mirror address for downloading packages.

Leave the "Mirror address" field unchanged and click on the "Done" button.

At the next step, you need to choose which disk the new operating system will be installed on and allocate space for installation.

:::note All free disk space will be allocated for the system. :::

Select "Use An Entire Disk" and press the "Enter" button.

Now you need to choose which disk the operating system will be installed on.

:::note In this example, one 10Gb disk is installed. :::

Select the disk on which you want to install the system and press the "Enter" button.

In the next step, you can see what partitions will be created on the disk.

Click on the "Done" button.

Now you need to confirm your changes.

Select "Continue" and press the "Enter" button.

Next, you will need to specify the full username for the administrator account, the server name, then the login and password for the new account.

Click on the "Done" button.

If you plan to connect to the server via SSH, then you need to select "Install OpenSSH server".

:::note You can also import SSH keys from Launchpad or Github. :::

Click on the "Done" button.

At this stage, you can take the opportunity to select additional components to install.

This tutorial walks you through installing Ubuntu Server without additional components.

Click on the "Done" button.

Next, you can watch the installation process of Ubuntu Server 18.04.

The Ubuntu Server 18.04 installation is complete.

Click on the "Reboot Now" button.

Now you need to remove the Ubuntu Server 18.04 installation disc from the CD/DVD drive.

Press the "Enter" button.

Next, you need to specify the username and password for authorization in Ubuntu, which was specified earlier during the installation of the system.

Configure Exchange Server 2016

Vladimir Mikhalev (heyvaldemar.com) — Wed, 12 Dec 2018 00:00:00 GMT

This article is for those looking for a detailed and clear guide on how to configure Exchange Server 2016.

You can read more about how to configure Exchange Server 2019 in my guide Configure Exchange Server 2019.

:::important We will consider the case when you already have two servers with the Windows Server 2012 R2 operating system installed on them. In addition, one of the servers must have the Active Directory Domain Services role installed, and the second server must have Exchange Server 2016 installed. :::

:::note For details on installing Exchange Server 2016 on Windows Server 2012 R2, refer to my guide: Install Exchange Server 2016 on Windows Server 2012 R2. :::

:::note To learn how to install Active Directory Domain Services on Windows Server 2012 R2, see my guide: Install Active Directory Domain Services on Windows Server 2012 R2. :::

Open the Exchange Admin Center control panel, which is located at the link https://us-boston-ex-01/ecp, where us-boston-ex-01 is the name of my Exchange server. Accordingly, you need to provide the name or IP address of your server.

Specify the username and password of an account with Exchange administrator rights and click on the "Sign in" button.

Welcome to the "Exchange Administration Center".

You can start working with the Exchange server.

Let's create a mailbox database.

In the "Servers" section, select the "Databases" subsection and click on the "+" button.

Next, you need to specify a name for the new database and select an Exchange server with the "Mailbox" role.

Specify the name of the database and click on the "Browse" button.

Select the Exchange server with the "Mailbox" role and click on the "OK" button.

Now you need to specify in which folder the mailbox database and its logs will be stored.

In the "Database file path" field, specify the folder in which the database will be stored.

In the "Log folder path" field, specify the folder in which the database logs will be stored.

Check the "Mount this database" box and click on the "Save" button.

Now you need to restart the Microsoft Exchange Information Store service on the Exchange server.

Click on the "OK" button.

Open "Server Manager" on the server with Exchange Server 2016 installed, then click on the "Tools" button in the upper right corner of the screen and select "Services".

Right-click on the "Microsoft Exchange Information Store" service and select "Restart".

The service has restarted successfully and the new database is ready to go.

Next, in the "Servers" section, select the "Databases" subsection, then select a new database and double-click on it with the left mouse button.