DevOps Docker

Совет по Docker-бэкапам: не бэкапьте контейнер. Бэкапьте сценарий восстановления. Плохой вариант:

docker commit app backup

Это снимок хаоса: внутри могут быть временные файлы, старые логи, секреты и непонятное состояние процесса. Правильнее сохранять 4 вещи: • docker-compose.yml • .env.example без секретов • дампы данных: pg_dump, mysqldump, redis-cli save • версии образов через digest, а не просто latest Пример:

docker image inspect app:prod \
  --format='{{index .RepoDigests 0}}'

Главная мысль: бэкап ценен только тогда, когда ты можешь поднять проект с нуля на новой машине. Контейнеры одноразовые. Данные и инструкция восстановления — нет.

Модернизация дата-центров и Dev Cluster для ML На infra.conf’26 Яндекс рассказал о развитии инфраструктуры для ИИ. В компании: • внедряют кампусы дата-центров мощностью до 180 МВт; • используют жидкостное охлаждение для повышения эффективности охлаждения вычислительных мощностей; • развивают Dev Cluster — внутренний сервис для ускорения ML-экспериментов и разработки моделей. Изменения затрагивают как физическую инфраструктуру, так и платформенные инструменты для ML-разработки.

Редкий Docker-трюк для баз данных: не запускай приложение сразу после Postgres depends_on сам по себе ждёт только старт контейнера, а не готовность базы. Правильнее делать так:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 3s
      retries: 10

  migrate:
    image: myapp
    command: npm run migrate
    depends_on:
      db:
        condition: service_healthy

  app:
    image: myapp
    depends_on:
      migrate:
        condition: service_completed_successfully

Идея простая: 1. Сначала реально поднимается база 2. Потом отдельный контейнер накатывает миграции 3. Только после успешных миграций стартует приложение Так ты убираешь рандомные ошибки вида: connection refused relation does not exist database is starting up Особенно полезно для CI, staging и локальной разработки, где контейнеры часто стартуют с нуля. Маленькая деталь, которая делает Docker-сетап сильно взрослее.

АОТ — первая в России независимая некоммерческая ассоциация, которая занимается развитием cloud-native подходов и объединяет участников рынка облачных технологий. Сейчас организация формирует экспертный совет из девяти практиков, которые будут работать над развитием технологической повестки и отраслевых инициатив. 🔹Основные направления работы: — Kubernetes — Облачная инфраструктура — Платформенные решения — DevOps и DevSecOps — Безопасность облачных систем — Observability и устойчивость инфраструктуры — Применение AI в разработке Cloud-native сегодня — это уже не только контейнеризация, а комплексный подход к созданию масштабируемых, отказоустойчивых и управляемых систем, который становится стандартом для современной инфраструктуры. https://kod.ru/aot-experts/amp

🖥 Обито учит контейнеризации. Контейнер - это отдельное измерение для приложения. Запускаешь сервис через Docker — и он не ломает основную систему. Хочешь понять, что происходит внутри? Смотри логи и заходи в контейнер через shell. Если сервисов несколько, используй Docker Compose. Одна команда поднимает приложение, базу данных и кеш. А важные данные храни в volume. Контейнер можно удалить, но данные должны остаться. И не забывай чистить Docker. Лишние контейнеры и образы быстро превращают систему в хаос. Настоящий шиноби не запускает хаос. Он изолирует его.

Apple фактически сделала Docker Desktop необязательным на Mac. И полностью бесплатно. Речь про apple/container. У проекта уже 26,5 тысяч звёзд на GitHub. Теперь Linux-контейнеры можно запускать на Mac нативно: без Docker Desktop, без фонового демона, который съедает RAM, и без коммерческой лицензии за $21 в месяц на каждого разработчика. Что умеет apple/container: → запускает Linux-контейнеры как лёгкие VM прямо на Apple Silicon через виртуализацию macOS 26 → полностью совместим с OCI. Можно тянуть образы из Docker Hub, GitHub Container Registry и других реестров → написан на Swift и оптимизирован под Apple Silicon. Идея в том, чтобы быть быстрее и легче Docker Desktop на Mac → использует привычный container CLI. Если вы знаете Docker-команды, порог входа минимальный → позволяет пушить собранные образы в стандартные container registry и запускать их где угодно Docker Desktop для коммерческого использования стоит $21 в месяц за разработчика. Версия от Apple бесплатная, open source и распространяется под Apache-2.0. В прошлом месяце Microsoft сделала Docker Desktop необязательным на Windows через WSL Containers. Теперь Apple делает то же самое на Mac. Docker никуда не исчезает. Но эпоха, когда за GUI-обёртку вокруг контейнеров на своей машине приходилось платить, похоже, тихо заканчивается. Репозиторий: github.com/apple/container

🧠 Docker-совет: не копируй весь проект в image слишком рано Одна из частых ошибок в Dockerfile:

COPY . .
RUN npm install

или:

COPY . .
RUN go mod download

Проблема в том, что Docker cache ломается при любом изменении любого файла. Поменял README, тест, конфиг или один исходник — слой COPY . . изменился, значит зависимости снова скачиваются и билд становится медленным. Правильный подход: сначала копировать только dependency manifest, установить зависимости, а уже потом копировать остальной код. Для Node.js:

COPY package.json package-lock.json ./
RUN npm ci

COPY . .

Для Go:

COPY go.mod go.sum ./
RUN go mod download

COPY . .

Для Python:

COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

Так Docker будет переиспользовать слой с зависимостями, пока реально не изменились package-lock.json, go.sum или requirements.txt. Ещё сильнее помогает .dockerignore. Туда стоит добавить:

.git
node_modules
dist
build
coverage
.env
*.log

Итог: меньше контекста, меньше лишних invalidated layers, быстрее CI/CD, стабильнее кеши. Хороший Dockerfile - это не просто “собрать image”. Это управлять слоями так, чтобы сборка не начиналась с нуля при каждом чихе.

Как управлять расходами в облаке и не удивляться счетам ✨

Переход в облако дает бизнесу гибкость и скорость, но без продуманного подхода к управлению затратами может обернуться непредвиденными расходами. Когда инфраструктура растет, даже небольшие изменения в потреблении начинают заметно влиять на бюджет.

На вебинаре 25 июня эксперты Cloud.ru расскажут, как с помощью бизнес‑практик и встроенных инструментов сделать расходы на облако прозрачнее, грамотно распределять ресурсы между командами и выстроить эффективное управление затратами без ограничений для разработки. Вы узнаете:

▶️

почему важно назначать владельца каждому облачному ресурсу;

▶️

где скрываются неиспользуемые ресурсы и как автоматически находить их и устранять с помощью инструментов Cloud․ru;

▶️

какие сценарии чаще всего приводят к перерасходу бюджета и как держать их под контролем с помощью лимитов и квот;

▶️

как эффективно использовать FinOps инструменты Cloud․ru для мониторинга расходов, настройки алертов и автоматизации контроля затрат;

▶️

как сократить расходы на облако на 20–30 % за счет правильного выбора тарифов и оценки стоимости сервисов на этапе планирования и разработки.

👉 Зарегистрироваться 👈

4 MCP-сервера, о которых стоит знать каждому DevOps-инженеру 1. Kubernetes MCP - расследовать pod’ы в CrashLoopBackOff; - дебажить неудачные деплои; - анализировать состояние кластера. Repo: https://github.com/Flux159/mcp-server-kubernetes 2. AWS MCP - разбирать резкие скачки расходов в AWS; - находить неиспользуемые ресурсы; - troubleshooting облачной инфраструктуры. Repo: https://github.com/awslabs/mcp 3. Terraform MCP - проверять Terraform-планы; - находить drift в инфраструктуре; - объяснять изменения в инфраструктуре. Repo: https://github.com/hashicorp/terraform-mcp-server 4. Grafana + Prometheus MCP - расследовать скачки latency; - анализировать production-инциденты; - объяснять alert storms. Repos: https://github.com/grafana/mcp-grafana https://github.com/pab1it0/prometheus-mcp-server ИИ может получать доступ к вашей инфраструктуре, понимать, что реально происходит, и помогать разбирать проблемы на основе настоящих данных, а не догадок.

layerx Интерактивный инспектор слоёв Docker-образов с проверками эффективности, удобными для CI. Один бинарник. Демон Docker не нужен, если анализируете сохранённые архивы образов. #golang https://github.com/deveshctl/layerx

Быстро заканчивается место на диске, а где именно - непонятно? Есть простой способ найти самые тяжёлые директории в Linux:

du -sh /* 2>/dev/null | sort -rh | head -10

Что делает команда: du -sh /* считает размер всех директорий в корне 2>/dev/null убирает ошибки доступа из вывода sort -rh сортирует по размеру от большего к меньшему head -10 показывает 10 самых тяжёлых папок Дальше заходите в самую подозрительную директорию и повторяете команду уже внутри неё:

cd /var
du -sh * 2>/dev/null | sort -rh | head -10

Так можно быстро понять, что съело диск: логи, Docker, кэш, бэкапы или старые артефакты сборки.

Docker-совет для миграции Не переносите контейнер через docker save как единственный способ. Так вы сохраните image, но потеряете важное: - volumes - env-переменные - networks - ports - restart policy - bind mounts Лучше сначала восстановить docker-compose.yml из уже запущенного контейнера:

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/red5d/docker-autocompose \
  container_name

Потом на новом сервере запускаете уже нормально:

docker compose up -d

А данные из volume переносите отдельно через tar. Мигрировать нужно не контейнер, а всё состояние запуска. Image можно скачать заново, а вот volumes, env и настройки запуска - именно там обычно ломается прод.

🐍 Python Roadmap 2026: наконец-то полноценная актуальная карта изучения Python, а не список ссылок «разберись сам» На GitHub выложили большой русскоязычный роадмап по Python на 2026 год - от первых скриптов до уровня Middle+/Senior. Маршрут собран под современный Python: - Python 3.13+ - free-threaded mode без GIL - JIT - uv вместо боли с pip/venv/poetry - ruff, pyright, pytest, hypothesis - async-first подход - типизация - CPython внутри - web, базы, ML/AI, DevOps и архитектура В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура. Отдельный плюс - практический формат. На каждом этапе есть задачи, чеклисты, примеры кода и бесплатные ресурсы. То есть это не мотивационная простыня, а маршрут, по которому реально можно идти несколько месяцев и видеть прогресс. Для новичков - понятный путь без хаоса. Для джунов - способ закрыть дыры. Для тех, кто уже пишет на Python - хороший чеклист, чтобы понять, где ты всё ещё плаваешь. Python в 2026 году - это tooling, типы, async, инфраструктура, AI и продакшн-дисциплина. И этот роадмап как раз про такой Python. https://github.com/justxor/pythonroamap2026

Свой ML-завод: что дает собственная ML-платформа и как ее запустить ⤵️ На вебинаре 2 июня эксперт Cloud․ru расскажет, как выстроить эффективный ML-процесс — от загрузки данных до обучения моделей на GPU-кластере. В программе:

▶️почему ИИ-пилоты «не взлетают»: разрозненные инструменты, простой GPU и не только; ▶️во сколько обходится ML на самом деле: почему затраты GPU — это только вершина айсберга и куда ещё уходят деньги; ▶️облако, open source своими руками и готовое решение — чем отличаются три пути к ML-платформе и какие скрытые ловушки есть у каждого; ▶️on-premise vs. облако: когда локальное развёртывание дешевле и почему это не всегда так; ▶️в каких отраслях on-premise ML-платформа необходима и какие бизнес-сценарии можно реализовать с её помощью; ▶️из чего состоит и как устроена Evolution Stack.ML; ▶️зачем нужны воркспейсы.

Бонус: на вебинаре покажут, как создавать вокспейс на платформе, подключать внешние источники данных и запускать Jupyter Server на базе готового образа. Зарегистрироваться

🖥 Docker-трюк: используйте `docker buildx du`, чтобы найти, куда реально утекают гигабайты Если Docker начал жрать диск, большинство сразу делает: docker system prune -a И иногда случайно сносит половину полезного кеша. Более аккуратный способ - сначала посмотреть, что именно занимает место: docker buildx du Команда показывает размер build cache по builder'ам: какие слои занимают больше всего, что можно удалить, а что ещё используется. Особенно полезно на машинах, где часто собираются образы через BuildKit, CI, multi-stage Dockerfile и разные архитектуры. Мини-шпаргалка: docker buildx du показать размер кеша сборки docker buildx du --verbose увидеть подробности по записям кеша docker builder prune удалить неиспользуемый build cache docker builder prune --filter until=24h удалить кеш старше 24 часов docker builder prune --keep-storage 20GB очистить кеш, но оставить до 20 ГБ полезного хранилища docker system df посмотреть общий расход места: образы, контейнеры, volumes, build cache Главный нюанс: docker system prune чистит широко, а docker builder prune бьёт именно по кешу сборки. Для dev-машины и CI это часто безопаснее и предсказуемее. Если Docker внезапно занял 80 ГБ, не начинайте с ядерной кнопки. Сначала проверьте build cache.

Стартуем с Kubernetes без боли в Managed Kubernetes от MWS Cloud Platform. 27 мая в 16:00 Александр Курасов, технический владелец продукта в MWS Cloud Platform, покажет, как развернуть кластер за минуты, на вебинаре «Быстрый старт с Managed Kubernetes в облаке MWS». Разберём архитектуру сервиса, его интеграцию с IAM, сетями и балансировщиками. Увидите, как управляемый сервис берёт на себя администрирование master-узлов и упрощает жизнь. Будет интересно: ♦️DevOps-инженерам, которые хотят упростить работу с Kubernetes ♦️Backend-разработчикам, которым нужно быстро задеплоить сервис ♦️Platform-инженерам, строящим cloud-native инфраструктуру ♦️Техлидам и архитекторам, выбирающим Kubernetes в облаке ➡️ Зарегистрироваться

Docker-совет: используй COPY --link в Dockerfile, чтобы ускорять rebuild и не ломать cache chain. Обычно COPY создаёт слой, который зависит от предыдущих слоёв. Если выше что-то изменилось, Docker часто пересобирает цепочку дальше, даже когда сами файлы не поменялись. С COPY --link копируемые файлы попадают в отдельный независимый слой:

# syntax=docker/dockerfile:1.7

FROM golang:1.23 AS build
WORKDIR /app

COPY --link go.mod go.sum ./
RUN go mod download

COPY --link . .
RUN go build -o app ./cmd/app

Где реально помогает: большие монорепы; частые изменения базового образа; CI/CD с BuildKit cache; multi-stage сборки; ситуации, где COPY . . постоянно инвалидирует лишние слои. Плюс: BuildKit может переиспользовать слой с файлами даже при изменениях в предыдущих слоях. Минус: COPY --link не умеет следовать за symlink в destination path. Но для большинства production Dockerfile это не проблема.

🖥 На Stepik обновили курс «C# с нуля до профи» Представьте: через четыре месяца вы открываете чужой .NET-проект и читаете его как книгу. IServiceCollection не вызывает ступора. async Task<IActionResult> пишется на автомате. Вы точно знаете, почему EF Core сгенерировал именно такой SQL - и как переписать запрос, чтобы он летал. Это не фантазия. Это результат после 16 модулей, в которых каждая концепция объясняется через код и закрепляется практикой. ООП, SOLID, LINQ, async/await, DI, EF Core, ASP.NET Core, Docker, Kubernetes - всё, что казалось магией, станет рабочим инструментом. А бонусом - портфолио проектов: от CLI-утилит и REST API до собственного SaaS с multi-tenancy, JWT и деплоем в Kubernetes под TLS. Скидка - 58% доступна 48 часов: https://stepik.org/a/282984/

Linux умеет запускать программы в почти контейнерной изоляции вообще без Docker. За это отвечает `unshare`. Команда создает для процесса отдельные namespace: свой список процессов, свой mount-view, hostname, IPC, network и user namespace. В итоге программа видит не всю систему, а только ограниченный «кусок» окружения. Пример:

sudo unshare --pid --fork --mount --uts --ipc --net --user --map-root-user --mount-proc bash

Внутри новой shell можно выполнить:

ps aux

И вместо сотен процессов увидеть почти пустую систему: bash с PID 1 и сам ps. Это не Docker, не container runtime и не магия. Это базовый механизм ядра Linux, на котором контейнеры во многом и построены. Полезно знать, если хотите понимать контейнеры не как «черный ящик», а на уровне того, что реально делает kernel.

Pterodactyl — это современная, мощная панель управления игровыми серверами, написанная на PHP с использованием Laravel и Vue.js. Проект ориентирован на безопасность, производительность и расширяемость. Архитектура Pterodactyl построена на принципе контейнеризации: каждый сервер работает в собственном Docker-контейнере. Это обеспечивает изоляцию, гибкость управления и простую миграцию между хостами. Поддерживается широкий список игр и движков, включая Minecraft, CS:GO, Rust, ARK и многие другие. 🔹Основные возможности: — Веб-интерфейс с красивым и отзывчивым UI — Управление правами пользователей и доступом — Поддержка нескольких узлов (нодов) — API для автоматизации и интеграций — Мониторинг ресурсов: CPU, RAM, дисковое пространство — Поддержка SFTP через Daemon — Интеграция с Docker для запуска серверов в изолированной среде Проект с открытым исходным кодом, активно развивается и имеет сильное комьюнити. Отличное решение как для хостинг-провайдеров, так и для личного использования. https://github.com/pterodactyl/panel