标签：#devops

Sparrow is Raku automation framework comes with useful plugins people can use to automate infrastructure. Scc plugin allows to check Linux essential configuration files for security compliance. Here some examples: Sysctl $ sudo sysctl -a | s6 --plg-run scc@check = sysctl 12:24:07 :: [task] - run plg scc@check=sysctl 12:24:07 :: [task] - run [scc], thing: scc@check=sysctl [task run: task.bash - scc] [task stdout] 12:24:08 :: abi.cp15_barrier = 1 12:24:08 :: abi.setend = 1 12:24:08 :: abi.swp = 0 12:24:08 :: abi.tagged_addr_disabled = 0 12:24:08 :: debug.exception-trace = 0 12:24:08 :: dev.cdrom.autoclose = 1 12:24:08 :: dev.cdrom.autoeject = 0 12:24:08 :: dev.cdrom.check_media = 0 12:24:08 :: dev.cdrom.debug = 0 12:24:08 :: dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = drive name: 12:24:08 :: dev.cdrom.info = drive speed: 12:24:08 :: dev.cdrom.info = drive # of slots: 12:24:08 :: dev.cdrom.info = Can close tray: 12:24:08 :: dev.cdrom.info = Can open tray: 12:24:08 :: dev.cdrom.info = Can lock tray: 12:24:08 :: dev.cdrom.info = Can change speed: 12:24:08 :: dev.cdrom.info = Can select disk: 12:24:08 :: dev.cdrom.info = Can read multisession: 12:24:08 :: dev.cdrom.info = Can read MCN: 12:24:08 :: dev.cdrom.info = Reports media changed: 12:24:08 :: dev.cdrom.info = Can play audio: 12:24:08 :: dev.cdrom.info = Can write CD-R: 12:24:08 :: dev.cdrom.info = Can write CD-RW: 12:24:08 :: dev.cdrom.info = Can read DVD: 12:24:08 :: dev.cdrom.info = Can write DVD-R: 12:24:08 :: dev.cdrom.info = Can write DVD-RAM: 12:24:08 :: dev.cdrom.info = Can read MRW: 12:24:08 :: dev.cdrom.info = Can write MRW: 12:24:08 :: dev.cdrom.info = Can write RAM: 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.lock = 0 12:24:08 :: dev.raid.speed_limit_max = 200000 12:24:08 :: dev.raid.speed_limit_min = 1000 12:24:08 :: dev.scsi.logging_level = 68 12:24:08 :: dev.tty.ldisc_autoload = 1 12:24:08

AWS Builder Center now offers free 8-hour sandbox environments for workshops. Here's how it works, who it's for, and how it compares to Free Tier, Skill Builder, and Educate.

Quick note before we dive in — I know I've been off track from the iOS/Swift series lately. I just...

Static analysis isn't just for application source code. Terraform, Pulumi, OpenTofu, and CloudFormation files are code too — and they get misconfigured just as often as a backend service. A public S3 bucket, a security group open to 0.0.0.0/0 , or an unencrypted RDS instance are all bugs you can catch before apply ever runs. TFSec is the tool most people reach for first, but it's not the only option on the OWASP Source Code Analysis Tools list . In this article I'll use Checkov , a free, open-source policy-as-code scanner built by Bridgecrew (now part of Palo Alto Networks), to scan a Terraform project end to end — from a local scan to a GitHub Actions gate that blocks merges on critical misconfigurations. The same approach works with OpenTofu and Pulumi projects too, since Checkov understands HCL directly and also has native support for Pulumi's rendered plan output and CloudFormation/ARM/Kubernetes manifests. Why Checkov? 100% open source (Apache 2.0), actively maintained, thousands of built-in policies. Understands Terraform, OpenTofu, CloudFormation, Kubernetes, Helm, Dockerfile, ARM, Serverless Framework, and Pulumi (via cdktf /synthesized plans) — one tool across most of your IaC surface. No account or API key required to run locally or in CI. Supports custom policies written in Python or YAML if the built-in rule set doesn't cover something specific to your org. ## 1. The sample infrastructure A small AWS setup with a few intentionally introduced misconfigurations — the kind that get merged during a rushed sprint: # main.tf provider "aws" { region = "us-east-1" } resource "aws_s3_bucket" "data" { bucket = "company-app-data-bucket" } # Vulnerable: bucket has no encryption, no versioning, and is publicly readable resource "aws_s3_bucket_acl" "data_acl" { bucket = aws_s3_bucket . data . id acl = "public-read" } resource "aws_security_group" "web" { name = "web-sg" description = "Allow web traffic" # Vulnerable: SSH open to the entire internet ingress { from_port

Most "how to add SAST to your pipeline" articles gravitate toward the same four names: SonarQube, Snyk, Semgrep, Veracode. They're solid tools, but they're not the only options, and sometimes you can't use them — budget constraints, air-gapped environments, licensing restrictions, or simply wanting something lightweight that lives entirely in your repo. The OWASP Source Code Analysis Tools page lists dozens of alternatives across every language. In this article I'll walk through applying Bandit , a free, open-source SAST tool for Python, to a real sample application — from finding vulnerabilities locally to wiring it into a CI/CD pipeline with GitHub Actions. The same workflow (install → configure → scan → fail the build on high-severity findings → track results over time) applies almost identically if you swap Bandit for other OWASP-listed tools like Brakeman (Ruby), FindSecBugs (Java), Gosec (Go), or Horusec (multi-language). Why Bandit? 100% open source (Apache 2.0), maintained under the PyCQA org. No account, no server, no license key — it runs as a CLI or a library. Understands Python's AST, so it catches real logic patterns, not just regex matches. Easy to tune with a config file and inline # nosec suppressions. ## 1. The sample application Let's use a small Flask app with a few intentionally introduced vulnerabilities — the kind of thing that slips into real codebases under deadline pressure. # app.py import subprocess import sqlite3 import pickle import yaml from flask import Flask , request app = Flask ( __name__ ) DB_PATH = " users.db " @app.route ( " /ping " ) def ping (): host = request . args . get ( " host " ) # Vulnerable: command injection via shell=True result = subprocess . run ( f " ping -c 1 { host } " , shell = True , capture_output = True ) return result . stdout @app.route ( " /user " ) def get_user (): user_id = request . args . get ( " id " ) conn = sqlite3 . connect ( DB_PATH ) cursor = conn . cursor () # Vulnerable: SQL injection via strin

Most Dockerfiles work. That's the problem — "it builds and runs" hides a lot of quiet costs in security, speed, and size that don't announce themselves until an audit, an incident, or a cloud bill does it for them. Here are seven mistakes I see constantly, and what to do instead. 1. Running as root By default, the process in your container runs as root — and if someone breaks out, they're root on a surface they shouldn't be. Add a non-root user and switch to it: RUN useradd --system --uid 10001 appuser USER appuser Cheap, and it closes off a whole category of "well, at least it wasn't root" incidents. 2. FROM some-image:latest latest is not a version — it's "whatever was newest when this happened to build." Two builds a week apart can produce different images with no diff to explain it, and a surprise base upgrade is a fun way to spend a Friday. Pin a specific tag, ideally by digest: FROM node:20.11.1-slim 3. Baking secrets into layers COPY .env . or ARG API_KEY followed by using it — and now the secret lives in an image layer forever , recoverable by anyone who pulls the image, even if a later layer deletes the file. Layers are immutable and additive; you can't delete your way out of a leak. Use build secrets ( --mount=type=secret ) or inject at runtime, never at build. 4. No .dockerignore Without one, COPY . . sweeps your .git directory, local env files, node_modules , and test data into the build context — bloating the image and, worse, potentially baking credentials and history into a layer. A five-line .dockerignore is one of the highest-leverage files in the repo. 5. Layer order that destroys your cache COPY . . RUN npm ci # ← reinstalls on EVERY code change Docker invalidates every layer after the first change. Copy the lockfile and install dependencies before copying the rest of your source, so a one-line code change doesn't trigger a full reinstall. This is a build-speed bug hiding as a style choice. 6. Leaving package manager cruft in the image RUN apt-get

This post was originally published on MatrixTrak.com — the production reliability toolkit for trading bot operators and .NET engineers. When requests hang forever and recycling releases stuck work: why missing timeouts create backlog, how to add budgets safely, and the rollout plan that prevents new incidents.. Most production incidents do not start as "down." They start as waiting. At 09:12 a dependency slows down. Your ASP.NET instances look healthy. CPU is fine. Memory is fine. But requests stop finishing. In-flight count climbs. Connection pools stop turning over. You scale out and it does not help because the new instances just join the waiting. The cost is not subtle. Backlog grows, SLAs fail, and on-call starts recycling processes because it is the only thing that releases the stuck work. Then the incident repeats next week because nothing changed about the waiting. This post gives you a production playbook for .NET: how to set time budgets, wire cancellation, and roll it out without triggering a new outage. Rescuing an ASP.NET service in production? Start at the .NET Production Rescue hub . If you only do three things Write down a total budget per request/job (then enforce it). Set per-attempt timeouts for each dependency and log elapsedMs , timeoutMs , and the decision (retry/stop/fallback). Propagate cancellation end-to-end so work stops (no zombie work after timeouts). Why requests hang forever: infinite waits capture capacity Missing timeouts are not a performance problem. They are a capacity problem. When a call can wait forever, it will eventually wait longer than your system can afford. While it waits, it holds something your service needs to operate: a worker slot, a thread, a connection, a lock, or a request budget. Once enough requests or jobs are holding those resources, the system stops behaving like a service and starts behaving like a queue you did not design. From the outside it looks like "everything is slow." Underneath, you are accumulating

Day 9 of the 30 Days of AWS Terraform series focuses on Terraform Lifecycle Rules — powerful controls that decide how Terraform creates, updates, replaces, and destroys resources. What Terraform LifeCycle meta arguments are Lifecycle meta arguments allow us to control how Terraform behaves when it creates, updates, or destroys resources. They help us: Avoid downtime Protect important resources Handle changes made outside Terraform Validate configurations before and after deployment Enforcing compliance Controlling replacement behavior Lifecycle rules allow us to override default behavior safely. Lifecycle rules are Terraform-native controls applied inside a resource block: lifecycle { ... } Lifecycle Rules Covered 1️⃣ create_before_destroy — Zero Downtime Updates Problem: Terraform destroys the old resource before creating the new one → downtime. Solution: lifecycle { create_before_destroy = true } Behavior: New resource is created first Old resource is destroyed only after Ensures zero downtime 2️⃣ prevent_destroy — Protect Critical Resources This setting prevents Terraform from deleting a resource. Example If Terraform tries to destroy this resource, it will fail with an error. This is useful for: Production databases State storage buckets Important data resources 3️⃣ ignore_changes — Allow External Modifications Problem: Terraform overwrites manual or automated external changes. Solution: lifecycle { ignore_changes = [desired_capacity] } Demo: Auto Scaling Group desired capacity modified manually in AWS Console terraform apply did not revert the change Behavior: Terraform ignores changes for specified attributes. ✅ Use for: Auto Scaling Groups Resources modified by external systems Ops-driven configurations 4️⃣ replace_triggered_by — Replace When Dependency Changes Problem: Changing a dependency doesn’t always recreate dependent resources. Solution: lifecycle { replace_triggered_by = [aws_security_group.main] } Behavior: When security group changes EC2 instance i

If you've been monitoring Linux servers for any length of time, there's a good chance node_exporter was the first thing you installed. It's lightweight, reliable, and exposes a huge amount of machine metrics for Prometheus to scrape. For years, it has been the default answer. As your infrastructure grows, though, your monitoring stack usually grows with it. First comes log collection. Then traces. Before long you're running node_exporter , a log shipper, and maybe another telemetry agent. Each component has its own configuration, service unit, upgrade cycle, and failure modes. Grafana Alloy changes that by consolidating those responsibilities into a single telemetry agent. This post walks through migrating from node_exporter to Alloy on a real fleet, one server at a time, while maintaining continuous visibility throughout the process. These are the exact steps that survived contact with production on the Irin monitoring stack, not the idealized version that looks clean in a diagram. TL;DR If you're already running node_exporter , don't replace it overnight. Install Grafana Alloy alongside it, configure Alloy's built-in prometheus.exporter.unix component, verify that metrics are reaching your remote Prometheus instance, and only then retire node_exporter. Migrating one server at a time minimizes risk, preserves visibility, and positions your infrastructure for logs, traces, and future telemetry without deploying additional agents. The real difference is the direction of travel Before getting started, it's worth understanding what actually changes. This isn't simply replacing one monitoring agent with another. node_exporter is a server. It listens on a port, typically 9100,and waits for Prometheus to connect and scrape metrics. That means every monitored machine needs an open endpoint, network connectivity from Prometheus, firewall rules, and scrape configurations. Alloy flips that model around. Instead of waiting for Prometheus to connect, Alloy collects metrics loca

Git submodules have a reputation for being fiddly, but most of that pain comes down to a handful of missing commands and one config flag nobody mentions. Used well, they're a clean way to embed a shared library, a design-system repo, or a common docs folder inside another project - pinned to an exact commit so nothing shifts under your feet. This guide walks through the whole lifecycle, from adding a submodule to removing it, and calls out the gotchas that bite teams in real projects. Understanding What a Submodule Actually Is Before the commands, one mental model that clears up most confusion: a submodule embeds another git repo inside yours at a fixed path, pinned to a specific commit. Your repo doesn't track the submodule's files - it tracks which commit of the submodule to check out. That single idea explains almost every quirk that follows. Adding a Submodule Adding one is a single command: git submodule add git@github.com:org/shared-lib.git vendor/shared-lib This clones the repo into vendor/shared-lib , creates a .gitmodules file describing the mapping, and stages the pinned commit (git calls this a "gitlink"). Commit both pieces: git add .gitmodules vendor/shared-lib git commit -m "chore: add shared-lib submodule" The resulting .gitmodules entry is plain text and lives in version control: [submodule "vendor/shared-lib"] path = vendor/shared-lib url = git@github.com:org/shared-lib.git branch = main The branch line is optional: it's only used later when pulling the latest changes automatically. Cloning Without the Empty-Folder Surprise The most common submodule complaint is a teammate cloning the project and finding an empty folder where the submodule should be. The fix is knowing two commands: # Clone everything in one shot git clone --recurse-submodules <your-repo-url> # Already cloned? Initialize after the fact git submodule update --init --recursive Even better, run this once per machine so git pull and git checkout keep submodules in sync automatically - a

Installing Docker on Ubuntu should be simple, but in practice several Docker-shaped options compete for the same command name, each with different packaging, upgrade behavior, and security implications. This guide compares every major install path so you can pick the one that fits your machine. The options you will encounter include: docker.io from Ubuntu repositories docker-ce from Docker's official APT repository Docker from Snap Docker Desktop manually downloaded .deb packages the Docker convenience script rootless Docker Although they all provide container tooling, they are not interchangeable packages. The best choice depends on whether the machine is a developer workstation, a CI runner, a small server, a self-hosting box, or a production host. My default recommendation is calm but firm: for most technical users on normal Ubuntu machines, install Docker Engine from Docker's official APT repository. Use Ubuntu's docker.io only when distribution integration matters more than upstream Docker packaging. Avoid the Snap package unless you specifically want Snap behavior and understand its limits. Rootless Docker is worth knowing about, but it is not automatically the best default for every machine. This guide explains the tradeoffs, covers post-install security, and gives you clean installation paths for each method. Once Docker Engine is running, the Docker Cheatsheet is your daily command reference, and the Docker Compose Cheatsheet covers multi-container setups. Both sit alongside Git, VS Code, and CI/CD guides in Developer Tools: The Complete Guide to Modern Development Workflows . Quick Recommendation The table below summarizes which install path fits common scenarios. Use case Recommended install Developer workstation Docker official APT repo CI runner Docker official APT repo, version pinned if needed Small self-hosted server Docker official APT repo Production server Docker official APT repo, controlled upgrades Ubuntu-only conservative system Ubuntu docker.

TL;DR FFmpeg 8.x includes av1_vulkan , the first cross-vendor GPU AV1 encoder in mainline FFmpeg. We'll probe whether your GPU + driver actually expose AV1 encode, run a first working encode, benchmark it against SVT-AV1 on your own content, and talk about which jobs deserve it. 📦 Code: github.com/USER/repo (replace before publishing) Until FFmpeg 8.0 ("Huffman", released August 2025), GPU AV1 encoding meant picking a vendor: av1_nvenc for NVIDIA RTX 40+, av1_amf for AMD, av1_qsv for Intel Arc. Three code paths, three sets of flags, three driver stacks. The Vulkan Video encode work gives FFmpeg one encoder that reaches all three vendors through the standard VK_KHR_video_encode_av1 extension. The catch: driver support is a lottery. Plenty of capable hardware sits behind drivers that don't expose the encode extension yet. So before any pipeline decisions, we probe. 1. Check what you're running You want FFmpeg 8.x (8.1.2 is current as of late June 2026) built with Vulkan support, plus the vulkaninfo tool from the Vulkan SDK / vulkan-tools package. $ ffmpeg -version | head -1 ffmpeg version 8.1.2 Copyright ( c ) 2000-2026 the FFmpeg developers $ ffmpeg -hide_banner -encoders | grep vulkan V....D av1_vulkan AV1 ( Vulkan ) ( codec av1 ) If av1_vulkan doesn't appear, your build wasn't compiled with --enable-vulkan (distro packages vary; the BtbN static builds and most 8.x distro packages include it). 2. Probe the driver for AV1 encode 🔍 The encoder existing in FFmpeg means nothing if the driver doesn't expose the extension. This is the step that separates "should work" from "works": $ vulkaninfo | grep -iE "video_encode_(av1|queue)" VK_KHR_video_encode_av1 : extension revision 1 VK_KHR_video_encode_queue : extension revision 12 You see Meaning Both extensions listed You can encode AV1 via Vulkan 🎉 Only video_encode_queue Driver does Vulkan encode, but not AV1 (maybe H.264/H.265 only) Neither Driver too old, or GPU lacks an AV1-capable video engine Rough hardware floor: the

Bạn sẽ học gì Sau bài này, bạn sẽ tự tay đưa một app từ số 0 (một thư mục trống) đến chạy được bên trong một cluster Kubernetes chạy trên máy của bạn . Cụ thể: Viết một app Todo API nhỏ bằng Node.js + Express. Đóng gói (container hoá) nó thành một Docker image. Tạo một cluster Kubernetes local bằng kind . Deploy app bằng file YAML "thật" (không dùng lệnh tắt) để hiểu Kubernetes vận hành thế nào. Truy cập app đang chạy trong cluster từ máy của bạn. Đây là Part 1 trong series "DevOps 101 — Học K8s, Helm, ArgoCD từ số 0" . Cả series dùng chung một app tên todo-ops , các part sau sẽ xây tiếp lên nền này (thêm database, config, ingress, Helm, GitOps với ArgoCD). Điều kiện tiên quyết Docker (hoặc Docker Desktop / OrbStack) — đang chạy. kind — công cụ tạo cluster Kubernetes trong Docker. kubectl — CLI để nói chuyện với Kubernetes. Node.js 20+ và npm — để chạy thử app local. git — để quản lý mã nguồn. Cài đặt Chọn theo hệ điều hành của bạn. macOS (dùng Homebrew — nếu chưa có, cài trước): # Cài Homebrew (bỏ qua nếu đã có) /bin/bash -c " $( curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh ) " # Docker Desktop (hoặc OrbStack: brew install --cask orbstack) brew install --cask docker # Các CLI còn lại brew install kind kubectl node git Sau khi cài xong, mở Docker Desktop (hoặc OrbStack) và chờ nó báo Running trước khi chạy tiếp. Linux (Ubuntu/Debian): # Docker Engine curl -fsSL https://get.docker.com | sh sudo usermod -aG docker " $USER " # cho phép chạy docker không cần sudo (đăng xuất/đăng nhập lại để có hiệu lực) # kubectl curl -LO "https://dl.k8s.io/release/ $( curl -Ls https://dl.k8s.io/release/stable.txt ) /bin/linux/amd64/kubectl" sudo install -m 0755 kubectl /usr/local/bin/kubectl && rm kubectl # kind curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64 sudo install -m 0755 kind /usr/local/bin/kind && rm kind # Node.js 20 (qua NodeSource) + git curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get insta

Redpanda is a Kafka-API-compatible streaming platform written in C++ with no JVM and no ZooKeeper. This guide installs Redpanda on Ubuntu 24.04, secures it with a Let's Encrypt certificate and SASL/SCRAM authentication, tunes the kernel for production, verifies with a producer/consumer test, and exposes Redpanda Console behind Nginx basic auth. By the end, you'll have a secured, production-tuned single-node Redpanda cluster with a web console. Prerequisite: Ubuntu 24.04 server sized per Redpanda's CPU/memory requirements , non-root sudo user, and a domain A record (e.g. redpanda.example.com ). Install Redpanda $ sudo apt update $ curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | sudo -E bash Warning: Only run vendor setup scripts you trust — piped curl | sudo bash runs with root privileges. $ sudo apt install redpanda -y $ rpk --version Open the Firewall Port Service Purpose 9092 Kafka API Producer/consumer traffic 8082 Pandaproxy (HTTP) REST access for non-Kafka clients 8081 Schema Registry Avro/Protobuf schema versioning 9644 Admin API Monitoring, config, health checks 33145 Internal RPC Inter-node communication $ sudo ufw allow 9092,8082,8081,9644,33145/tcp $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp $ sudo ufw reload Issue a Let's Encrypt Certificate Redpanda ships with plaintext networking by default, fine for a lab, not for anything else. $ sudo apt install certbot -y $ DOMAIN = redpanda.example.com $ EMAIL = admin@example.com $ sudo certbot certonly --standalone -d $DOMAIN --non-interactive --email $EMAIL Certbot stores certs under /etc/letsencrypt/live , readable only by root. Redpanda runs as its own redpanda user, so copy the certs into a dedicated directory: $ sudo mkdir /etc/redpanda/certs $ sudo cp /etc/letsencrypt/live/ $DOMAIN /fullchain.pem /etc/redpanda/certs/node.crt $ sudo cp /etc/letsencrypt/live/ $DOMAIN /privkey.pem /etc/redpanda/certs/node.key $ sudo cp /etc/letsencrypt/live/ $DOMAIN /chain.pem /etc/re

Google Vertex AI is Google Cloud's managed ML platform with experiment tracking, training jobs, pipelines, a model registry, and endpoints, but it locks you into GCP-specific APIs and per-use billing. ClearML is an open-source MLOps platform that covers the same ground on any Docker host or Kubernetes cluster, capturing training metrics automatically with no code changes and keeping every byte of data on infrastructure you control. This guide deploys ClearML Server with Docker Compose and Traefik, registers an agent, runs an experiment, builds a pipeline, runs a hyperparameter sweep, and deploys a Triton-served model. By the end, you'll have a self-hosted Vertex AI replacement covering the full ML lifecycle. Vertex AI → ClearML Mapping GCP Vertex AI ClearML Equivalent Purpose Vertex AI Workbench ClearML Web UI Browser-based monitoring and configuration Vertex AI Experiments ClearML Experiment Manager Automatic hyperparameter/metric/artifact tracking Vertex AI Training Job ClearML Agent + Tasks Any machine becomes a remote worker via queues Vertex AI Pipelines ClearML Pipelines Python-native DAGs, no separate compile step Vertex AI Model Registry ClearML Model Repository Versioned models with full lineage Vertex AI Endpoints ClearML Serving (Triton) Self-hosted inference with canary/A-B support Cloud Monitoring/Logging ClearML Scalars/Plots Built-in metrics and hardware dashboards Prerequisite: Ubuntu host with Docker + Compose, DNS A records for app.clearml.example.com , api.clearml.example.com , files.clearml.example.com . NVIDIA Container Toolkit if you'll run GPU agents. Deploy the ClearML Server 1. Raise Elasticsearch's virtual memory limit and restart Docker: $ echo "vm.max_map_count=524288" | sudo tee /etc/sysctl.d/99-clearml.conf $ sudo sysctl --system $ sudo systemctl restart docker 2. Create persistent data directories with the correct ownership: $ sudo mkdir -p /opt/clearml/ { data/elastic_7,data/mongo_4/db,data/mongo_4/configdb,data/redis,data/fileserver,

Matomo is an open-source web analytics platform that keeps full ownership of visitor data on infrastructure you control, a privacy-first alternative to Google Analytics. This guide deploys Matomo using Docker Compose with a MariaDB backend, Nginx as the entry point, and Certbot issuing the TLS certificate before the stack goes live. By the end, you'll have Matomo tracking a website with a signed HTTPS certificate at your domain. Prepare Docker $ sudo usermod -aG docker $USER $ newgrp docker Set Up the Project 1. Create the project directory: $ mkdir matomo && cd matomo 2. Open the firewall: $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp 3. Create the environment file: $ nano .env MYSQL_ROOT_PASSWORD = your_strong_mysql_root_password MYSQL_PASSWORD = your_strong_mysql_matomo_password Use passwords of at least 16 characters. 4. Create the Nginx config: $ mkdir nginx $ nano nginx/matomo.conf server { listen 80 ; server_name matomo.example.com ; location /.well-known/acme-challenge/ { root /var/www/certbot ; } location / { return 301 https:// $host$request_uri ; } } server { listen 443 ssl http2 ; server_name matomo.example.com ; ssl_certificate /etc/letsencrypt/live/matomo.example.com/fullchain.pem ; ssl_certificate_key /etc/letsencrypt/live/matomo.example.com/privkey.pem ; location / { proxy_pass http://app:80 ; proxy_set_header Host $host ; proxy_set_header X-Real-IP $remote_addr ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header X-Forwarded-Proto $scheme ; } } Replace every matomo.example.com occurrence with your domain — it appears in both server blocks and the certificate paths. Deploy with Docker Compose $ nano docker-compose.yaml services : db : image : mariadb:11.4 command : --max-allowed-packet=64MB restart : always volumes : - matomo-db-data:/var/lib/mysql environment : - MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} - MYSQL_DATABASE=matomo - MYSQL_USER=matomo - MYSQL_PASSWORD=${MYSQL_PASSWORD} networks : - matomo-net app : image

Plausible Analytics is an open-source, self-hosted web analytics tool that tracks traffic without cookies or personal data collection, a privacy-first alternative to Google Analytics. This guide deploys Plausible Community Edition using Docker Compose, fronts it with Nginx, and secures it with a Let's Encrypt certificate. By the end, you'll have Plausible tracking a website's traffic securely at your domain. Configure the Environment 1. Clone the Community Edition repo: $ mkdir ~/plausible $ cd ~/plausible $ git clone https://github.com/plausible/community-edition.git $ cd community-edition 2. Generate a secret key: $ openssl rand -base64 64 | tr -d '\n' 3. Create the environment file: $ nano .env ADMIN_USER_EMAIL = admin@example.com ADMIN_USER_NAME = admin ADMIN_USER_PWD = ADMIN_PASSWORD BASE_URL = https://plausible.example.com SECRET_KEY_BASE = YOUR_SECRET_KEY_BASE DATABASE_URL = postgres://postgres:postgres@plausible_db:5432/plausible_db CLICKHOUSE_DATABASE_URL = http://plausible_events_db:8123/plausible_events_db Fill in your email, a strong admin password, your domain, and the secret key generated above. 4. Expose the app port via a Compose override (auto-merged with compose.yml ): $ nano compose.override.yaml services : plausible : ports : - 127.0.0.1:8000:8000 Deploy with Docker Compose $ docker compose up -d $ docker compose ps Confirm the app, Postgres, and ClickHouse (events DB) containers are all running. Front with Nginx and Let's Encrypt 1. Install Nginx: $ sudo apt update $ sudo apt install nginx -y 2. Create the virtual host: $ sudo nano /etc/nginx/sites-available/plausible.conf server { listen 80 ; listen [::]:80 ; server_name plausible.example.com ; access_log /var/log/nginx/plausible.access.log ; error_log /var/log/nginx/plausible.error.log ; location / { proxy_pass http://127.0.0.1:8000 ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_http_version 1.1 ; proxy_set_header Upgrade $http_upgrade ; proxy_set_header Connection "Upgr

Part 1: Solving GOP Structure and Compatibility Issues Operating a digital television network isn't just about keeping channels on air—it's about maintaining quality that viewers expect and troubleshooting issues before they escalate. When something goes wrong in live broadcasting, every second counts. But how do you quickly pinpoint whether the problem lies in encoder settings, transport stream structure, or temporal metadata? This is where specialized stream analysis tools become essential. In this series of articles, we'll walk through real-world scenarios that broadcast engineers face daily and show practical approaches to diagnosing and resolving them. When File Analysis Becomes Critical While live monitoring catches issues as they happen, file-based analysis is your diagnostic microscope. Here's the typical workflow: something breaks in production, engineers capture a few minutes of the problematic stream, and now they need to understand exactly what went wrong. File analyzers serve three primary purposes: Troubleshooting: Identifying the root cause of broadcast issues Encoder optimization: Fine-tuning compression settings Quality control: Validating compliance with standards and specifications Let's explore how this works in practice with actual tools and techniques. The GOP Structure Problem Here's a scenario every broadcast engineer has encountered: legacy set-top boxes or older TV models suddenly can't play your stream. The audio works, video starts and stops, or you see freezing. The culprit? Often, it's the GOP (Group of Pictures) structure. H.264 has been around since 2003—over 20 years. Almost everything supports it, yet you'll still find legacy equipment that struggles with certain configurations. Specifically, the number of B-frames can make or break compatibility. Why B-frames matter: They enable lower bitrates while maintaining quality by increasing encoding complexity through bidirectional prediction. But this comes at a cost—a more complex refere

Modern software development thrives on rapid iteration. Organizations deploy new features, bug fixes, and infrastructure updates multiple times each day to remain competitive and respond quickly to customer needs. Continuous Integration and Continuous Delivery (CI/CD) have transformed software delivery by automating repetitive tasks and accelerating release cycles. However, speed without security creates significant risk. A fast deployment pipeline that introduces vulnerable code into production can expose organizations to data breaches, service disruptions, and compliance violations. Conversely, excessive manual security reviews can slow innovation and delay valuable releases. The solution lies in integrating security directly into the CI/CD pipeline rather than treating it as a separate checkpoint. This philosophy, commonly known as DevSecOps, enables organizations to deliver software rapidly while maintaining a strong security posture. Understanding CI/CD Pipelines What Is Continuous Integration? Continuous Integration (CI) is the practice of frequently merging code changes into a shared repository. Every commit automatically triggers builds and tests, allowing development teams to identify integration issues early instead of waiting until the end of a project. Frequent integration encourages collaboration, reduces merge conflicts, and improves overall software quality. What Is Continuous Delivery? Continuous Delivery extends Continuous Integration by ensuring that validated code is always in a deployable state. Automated testing, packaging, and release preparation make it possible to deploy new versions with minimal manual effort whenever the business is ready. What Is Continuous Deployment? Continuous Deployment goes one step further by automatically releasing approved changes to production once they pass all quality and security checks. This approach significantly shortens release cycles while requiring a high level of confidence in pipeline automation. Benefi

How to Monitor Website Changes Automatically I run a few websites and need to know immediately when something breaks. A CSS regression, a broken layout, a missing section. Manual checking doesn't scale, and text-based monitoring misses visual issues. The {{screenshot-diff}} on Apify takes two screenshots and produces a pixel-level comparison with an overlay showing exactly what changed. How It Works Take a baseline screenshot of the correct state. Then take a current screenshot of the live page. The actor compares pixel by pixel and returns a diff image with changed pixels highlighted, plus a percentage telling you how much changed. import requests , time API_TOKEN = " YOUR_APIFY_TOKEN " def capture_screenshot ( url ): resp = requests . post ( " https://api.apify.com/v2/acts/weeknds~website-screenshot-api/runs " , headers = { " Authorization " : f " Bearer { API_TOKEN } " }, json = { " url " : url , " fullPage " : True } ) run_id = resp . json ()[ " data " ][ " id " ] time . sleep ( 15 ) items = requests . get ( f " https://api.apify.com/v2/acts/weeknds~website-screenshot-api/runs/ { run_id } /dataset/items " , headers = { " Authorization " : f " Bearer { API_TOKEN } " } ). json () return items [ 0 ][ " screenshotUrl " ] def compare_screenshots ( baseline_url , current_url ): resp = requests . post ( " https://api.apify.com/v2/acts/weeknds~screenshot-comparison-tool/runs " , headers = { " Authorization " : f " Bearer { API_TOKEN } " }, json = { " baselineImageUrl " : baseline_url , " currentImageUrl " : current_url , " threshold " : 0.01 } ) run_id = resp . json ()[ " data " ][ " id " ] time . sleep ( 10 ) items = requests . get ( f " https://api.apify.com/v2/acts/weeknds~screenshot-comparison-tool/runs/ { run_id } /dataset/items " , headers = { " Authorization " : f " Bearer { API_TOKEN } " } ). json () return items [ 0 ] baseline = capture_screenshot ( " https://mysite.com " ) current = capture_screenshot ( " https://mysite.com " ) result = compare_screenshots ( b