Короткий, но реально полезный приём для работы с Docker 👇
docker run --rm -it -v $(pwd):/app -w /app python:3.11 bash
💡 Что делает:
--rm — контейнер удаляется сразу после выхода (чисто, без мусора)
-v $(pwd):/app — монтирует текущую папку внутрь контейнера
-w /app — задаёт рабочую директорию
python:3.11 — базовый образ
bash — запускает интерактивную оболочку
📦 Зачем нужно:
Позволяет моментально войти в окружение Python (или любого другого образа) без Dockerfile, просто чтобы протестировать код, команду или библиотеку.
Рабочие файлы остаются на хосте, мусора — ноль.
🔥 Трюк работает с любыми образами:
docker run --rm -it -v $(pwd):/src -w /src golang:1.22 bash
docker run --rm -it -v $(pwd):/app node:20 bash
Полезный Docker-трюк для .NET: кэшируйте NuGet-пакеты через BuildKit, а не скачивайте их заново при каждой сборке.
# syntax=docker/dockerfile:1.7
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src
COPY *.csproj .
RUN --mount=type=cache,target=/root/.nuget/packages \
dotnet restore
COPY . .
RUN --mount=type=cache,target=/root/.nuget/packages \
dotnet publish -c Release -o /app
NuGet-кэш не попадает в финальный image, но между сборками сохраняется. В итоге restore работает быстрее, особенно в CI, где зависимости обычно весят больше, чем сам код.
🧠 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”.
Это управлять слоями так, чтобы сборка не начиналась с нуля при каждом чихе.
Оффер редко приходит сам. Обычно между «без работы» и «оффер получен» стоят десятки откликов, доработок резюме и часов поиска.
Talanto.work помогает пройти этот путь быстрее:
🟠 50 000+ IT-вакансий с разных сайтов
🟠 Telegram-бот с уведомлениями по вашим фильтрам
🟠 Проверка резюме и рекомендации по улучшению
🟠 Проверка соответствия резюме конкретной вакансии
🟠 Генератор персональных сопроводительных писем
Ищите работу не дольше. Ищите эффективнее.
🎥 Вебинар по Kubernetes: K8S + Vault — как получать секреты?
Как безопасно управлять чувствительными данными в Kubernetes-кластере? На этом открытом уроке вы узнаете, как организовать надёжное и масштабируемое взаимодействие между Kubernetes и HashiCorp Vault — популярным инструментом для управления секретами.
Мы разберёмся, почему стандартные Kubernetes-секреты не всегда комфортны для использования, какие риски существуют и как их можно минимизировать с помощью подхода dynamic secrets. Основное внимание будет уделено External Secrets Operator — инструменту, который позволяет безопасно забирать секреты из Vault (и других хранилищ) и интегрировать их в кластер.
📌 На уроке вы узнаете:
- Как Kubernetes работает с секретами по умолчанию, и в чём его ограничения;
- Какие существуют способы интеграции Kubernetes и Vault;
- Что такое External Secrets Operator и почему его всё чаще выбирают для production-сред;
- Пошаговая схема подключения Vault к K8s;
- Практические примеры и best practices для безопасной и автоматизированной работы с секретами.
🎯 После вебинара вы:
- Поймёте, какие уязвимости есть в стандартном механизме Kubernetes-секретов;
- Сможете настроить интеграцию Vault с Kubernetes;
- Узнаете, как использовать External Secrets Operator для безопасного управления секретами;
- Получите шаблоны и примеры манифестов, которые можно адаптировать под свои проекты.
⚠ Открытый урок проходит в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes».
👉 Для участия зарегистрируйтесь: https://clck.su/eAiJI
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
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-grafanahttps://github.com/pab1it0/prometheus-mcp-server
ИИ может получать доступ к вашей инфраструктуре, понимать, что реально происходит, и помогать разбирать проблемы на основе настоящих данных, а не догадок.
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 и настройки запуска - именно там обычно ломается прод.
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.
Как настроить Docker для автоматизированного тестирования
#читать #docker
Docker позволяет эффективно автоматизировать тестирование программного обеспечения, создавая виртуализированные среды с помощью контейнеров и интегрируя их с Selenium для параллельного выполнения тестов в разных браузерах.
Читать далее
3 сайта, которые помогают создать, проверить или улучшить резюме и пройти ATS фильтр.
1. UpdateCV.me
Сервис для создания и улучшения IT-резюме, анализа его структуры и ATS-совместимости, сравнения с конкретной вакансией и адаптации под требования работодателя.
Можно загрузить готовое резюме или создать новое с помощью ИИ. Рекомендации только по делу в формате было-стало, пользователь сам решает, какие изменения принять.
2. NETWRK
Позволяет создать резюме с нуля, провести автоматический анализ, улучшить формулировки, адаптировать резюме под вакансию и подготовить сопроводительное письмо.
3. Сопровод
Помогает сравнить резюме с вакансией, найти недостающие навыки, адаптировать содержание и создать сопроводительное письмо для конкретного отклика.
Также есть трекер отправленных откликов.
#резюме #поискработы #карьера #hr
🐳 Docker полностью переписала слой виртуализации Docker Desktop
Новый Docker VMM вышел в public beta для macOS и Windows начиная с Docker Desktop 4.86. Раньше Desktop полагался на сторонний VMM, теперь Docker контролирует весь стек и может оптимизировать его именно под контейнерные нагрузки.
Что обещают на практике: более быстрый запуск контейнеров, заметно ускоренный file I/O между host и контейнером, возврат неиспользуемой RAM системе и более стабильную работу на Windows.
На Windows Docker отдельно заявляет сочетание изоляции уровня Hyper-V со скоростью, близкой к WSL2. Тот же движок уже используется в Docker Sandboxes, а дальше компания хочет построить единый runtime для ноутбуков, облака, on-prem и AI-агентов.
GA планируется на конец октября 2026 года, после чего Docker VMM должен стать движком по умолчанию для новых установок Docker Desktop на Mac, Windows и Linux.
https://www.docker.com/blog/docker-vmm-public-beta/
Книги по Docker и DevOps
Скачивайте и читайте.
Docker без секретов
Автор: Сайбал Гош
Learn Docker in a Month of Lunches, 2nd Edition
Автор: Elton Stoneman
50 Kubernetes Concepts Every DevOps Engineer Should Know
Автор: Michael Levan
Docker. Вводный курс
Автор: Шон П. Кейн
Docker Deep Dive
Автор: Nigel Poulton
GitOps Cookbook. Kubernetes Automation in Practice
Автор: Natale Vinto
Безопасность контейнеров
Автор: Лиз Райс
Kubernetes для DevOps
Автор: Джон Арундел
Docker for Developers
Автор: Richard Bullington-McGuire
#docker #devops #подборка
🐳 Docker выпустила Sandboxes - изолированные среды специально для AI coding agents.
Идея простая: дать агентам вроде Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode и Kiro больше свободы, но не давать им свободно ломать хост-систему.
Каждый агент запускается в отдельной microVM и получает только рабочую директорию проекта. Внутри он может:
- устанавливать пакеты;
- менять конфиги;
- запускать сервисы;
- поднимать собственные Docker-контейнеры;
- выполнять долгие задачи без постоянного подтверждения действий.
При этом Docker позволяет отдельно контролировать filesystem, network и credentials, а сам sandbox после работы можно просто удалить.
Это инфраструктурный слой для эпохи автономных coding agents: агенту дают почти полный контроль внутри песочницы, но хост остаётся изолированным.
https://www.docker.com/products/docker-sandboxes/
#Docker #AI #AIAgents #DevOps #Programming
🤯 Ошибка уже произошла. В логах — сотни строк, причин может быть несколько, а исправление ещё нужно проверить. Расследование инцидента легко превращается в часы ручной работы.
8 сентября в 20:00 МСК на открытом уроке «ИИ против бага: как разобрать инцидент в Python-проекте от логов до исправления» покажем, где в этом процессе действительно может помочь искусственный интеллект.
На практическом примере пройдём весь путь: проанализируем логи, сформулируем и проверим гипотезы, найдём проблемный участок кода, подготовим исправление и тесты. Вы увидите, как ускорять расследование с помощью ИИ, сохраняя контроль над результатом.
Урок будет полезен Python-разработчикам, знакомым с отладкой и анализом логов, и проходит в преддверии старта курса «ИИ для Python-разработчиков».
🤖Зарегистрируйтесь и разберите рабочий сценарий применения ИИ: https://vk.cc/d0TUT1
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Что на самом деле делает `docker run -it` 🐳
Когда контейнеру нужен интерактивный shell, REPL или текстовый редактор, обычно запускают:
docker run -it ...
Но -i и -t делают разные вещи.
- -i (--interactive) — оставляет STDIN открытым, чтобы процесс внутри контейнера мог получать ввод с клавиатуры.
- -t (--tty) — создаёт pseudo-TTY, поэтому приложение ведёт себя как в обычном терминале.
Вместе они дают полноценную интерактивную сессию:
docker run -it ubuntu bash
Без -i не будет нормального интерактивного ввода.
Без -t приложение может работать, но без привычного терминального поведения: prompt, цветов, управления курсором и нормальной работы vim, top, less и других TTY-программ.
Под капотом схема примерно такая:
Terminal
↓
Docker CLI
↓
pseudo-TTY
↓
bash внутри контейнера
То есть -i отвечает за ввод, а -t — за сам терминал.
Если вы годами пишете docker run -it, но никогда не разбирались, зачем нужны оба флага, у iximiuz есть отличный практический challenge:
https://labs.iximiuz.com/challenges/docker-101-container-run-tty
Чат с вашими резюме.
Присылайте резюме, чтобы HR вас увидела и ей(ему) было удобно с вами связаться.
IT Резюме
P.S сейчас там можно бесплатно «прожарить» свое резюме на предмет ошибок и обхода ATS
eBPF: рентгеновское зрение для production
Сервис замедлился, соединения обрываются, а привычные показатели указывают только на симптом. Чтобы найти настоящую причину, иногда нужно увидеть, что происходит глубже — на уровне ядра Linux.
23 сентября в 20:00 на открытом уроке курса «DevOps практики и инструменты» познакомитесь с eBPF — технологией, которая помогает исследовать сетевые события, производительность и безопасность работающей системы.
На демонстрации вы увидите, как Cilium Hubble показывает сетевые взаимодействия и помогает находить проблемы с трафиком. С помощью Tetragon разберёте обнаружение подозрительной активности на уровне ядра. Также рассмотрите диагностику узких мест без остановки сервисов.
Преподаватель объяснит архитектуру eBPF простыми словами — как программы безопасно запускаются в ядре, какие данные можно получать и почему этот подход расширяет возможности традиционного мониторинга.
Вы поймёте, для каких задач eBPF действительно полезен, где он дополняет существующие средства наблюдаемости и когда его внедрение будет избыточным.
👉 Зарегистрируйтесь: https://vk.cc/d1LA8H
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🐳 Docker-образ с 3,17 ГБ до 354 МБ - почти в 9 раз меньше
Такая оптимизация обычно достигается не одной магией, а несколькими простыми приёмами:
- multi-stage build
- python:slim / distroless вместо тяжёлого base image
- удаление build-зависимостей после сборки
- очистка apt / pip cache
- .dockerignore для лишних файлов
- установка только production-зависимостей
- объединение команд RUN, чтобы не тащить мусор в слои
Пример:
3.17 GB → 354 MB
Что это даёт:
- быстрее pull/push
- быстрее CI/CD
- меньше места в registry
- быстрее запуск новых pod
- меньше потенциальная attack surface
Перед оптимизацией полезно посмотреть, что реально раздувает образ:
docker history <image>
и отдельно проверить слои через dive.
Большой Docker image почти всегда стоит сначала разобрать по слоям — часто там лежат гигабайты build-tools, cache и файлов, которые в runtime вообще не нужны.
Из вашего резюме вообще понятно, что вы умеете как DevOps-инженер?
Мы разбили работу DevOps-инженера на основные категории и сделали чекер, который показывает, какие из них в вашем резюме раскрыты хорошо, частично или почти не видны.
Опыт может быть - но по резюме этого не видно.
Проверь бесплатно и без регистрации:
https://updatecv.me/devops-resume-checker
А полный анализ резюме с правками доступен на: https://updatecv.me
Kagent + Ollama: ИИ-агент для работы с Kubernetes
Как использовать локальную языковую модель для работы с Kubernetes? На вебинаре разберём связку Kagent + Ollama и посмотрим, как ИИ-агент помогает анализировать состояние кластера и взаимодействовать с его ресурсами.
1 октября в 20:00 МСК на открытом вебинаре OTUS покажем, как запустить ИИ-агента с локальной LLM и применить его в DevOps-задачах.
На практике рассмотрим:
— какую роль выполняют Kagent и Ollama;
— как подключить локальную LLM к агенту;
— как агент анализирует состояние кластера и работает с Kubernetes-ресурсами;
— в каких повседневных задачах DevOps-инженера он может помочь;
— какие возможности и ограничения есть у агентного подхода.
После вебинара вы поймёте, как устроена связка Kagent + Ollama, увидите её применение в Kubernetes и сможете оценить, для каких задач в вашей инфраструктуре подходит ИИ-агент.
Урок проходит в преддверии старта курса «ИИ в работе DevOps-инженера».
👉 Регистрируйтесь: https://vk.cc/d23O7U
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🐳 Как устроен Docker: что происходит «под капотом»
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (dockerd) управляет контейнерами, образами, сетями
– Docker CLI (docker) — интерфейс пользователя
– REST API — взаимодействие CLI и Daemon
👉 Пример: docker run nginx → CLI отправляет запрос, Daemon находит образ, создаёт контейнер, запускает процесс.
3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг Dockerfile создаёт новый слой.
При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует runc для запуска контейнера (соответствует OCI Runtime Spec).
Daemon вызывает runc, который через clone(), setns(), chroot() изолирует процесс.
7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (/var/lib/docker) или в реестре (Docker Hub, GitLab Container Registry).
8)
GitOps-практики: развёртываем сервис через ArgoCD
Классический CI/CD запускает деплой. Но как сделать так, чтобы состояние Kubernetes после него соответствовало конфигурации в Git? На вебинаре разберём принципы GitOps и посмотрим, как ArgoCD помогает управлять изменениями в кластере.
7 октября в 20:00 МСК на открытом вебинаре OTUS развернём сервис в Kubernetes с помощью ArgoCD и покажет работу подхода на практике.
На практике рассмотрим:
— чем GitOps отличается от классического CI/CD и когда его применять;
— как устроен ArgoCD и какие есть варианты реализации GitOps;
— как развернуть сервис в Kubernetes через ArgoCD;
— что произойдёт при изменении конфигурации напрямую в кластере;
— какие подходы к работе с ArgoCD полезны в проектах.
После вебинара вы поймёте принципы GitOps, познакомитесь с возможностями ArgoCD и увидите полный процесс развёртывания сервиса. Полученные подходы сможете применить при работе со своими Kubernetes-кластерами.
Урок проходит в преддверии старта курса «DevOps. Экспертный уровень».
👉 Регистрируйтесь: https://vk.cc/d2t4v4
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Настраиваем простой healthcheck для Docker-контейнера!
Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного docker ps часто недостаточно: нужен healthcheck, который будет регулярно проверять состояние сервиса.
Представим простой HTTP-сервис, который отвечает на /health:
curl -f http://localhost:8080/health
Если команда возвращает код 0, контейнер считается здоровым. Если команда падает несколько раз подряд, Docker помечает контейнер как unhealthy.
В Dockerfile можно добавить HEALTHCHECK:
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1
Параметры задают частоту проверки, максимальное время ожидания и число неудачных попыток.
Соберём образ:
docker build -t app-with-health .
Запустим контейнер:
docker run -d --name app app-with-health
Теперь статус будет виден прямо в списке контейнеров:
docker ps
В выводе можно увидеть состояние:
Up 2 minutes (healthy)
Если нужно посмотреть healthcheck подробнее, используем inspect:
docker inspect --format '{{json .State.Health}}' app
А чтобы вывести только текущий статус:
docker inspect --format '{{.State.Health.Status}}' app
Ожидаемый результат:
healthy
Healthcheck особенно полезен в связке с оркестраторами и deploy-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.