Книги по 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 без секретов
Автор: Сайбал Гош
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 #подборка
Telegram
Docker простыми словами
Docker без секретов
Автор: Сайбал Гош
Год издания: 2023
#docker #ru
Скачать книгу
Автор: Сайбал Гош
Год издания: 2023
#docker #ru
Скачать книгу
👍4❤1👌1
🐳 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
Идея простая: дать агентам вроде 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
👍12🤡2
Что на самом деле делает `docker run -it` 🐳
Когда контейнеру нужен интерактивный shell, REPL или текстовый редактор, обычно запускают:
Но
-
-
Вместе они дают полноценную интерактивную сессию:
Без
Без
Под капотом схема примерно такая:
То есть
Если вы годами пишете
https://labs.iximiuz.com/challenges/docker-101-container-run-tty
Когда контейнеру нужен интерактивный 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
👍13
Чат с вашими резюме.
Присылайте резюме, чтобы HR вас увидела и ей(ему) было удобно с вами связаться.
IT Резюме
P.S сейчас там можно бесплатно «прожарить» свое резюме на предмет ошибок и обхода ATS
Присылайте резюме, чтобы HR вас увидела и ей(ему) было удобно с вами связаться.
IT Резюме
P.S сейчас там можно бесплатно «прожарить» свое резюме на предмет ошибок и обхода ATS
Telegram
IT Резюме
Ваши IT резюме. Присылайте сюда, чтобы их заметили HRы
Можно постить, обсуждать и помогать.
Без флуда, провокаций, агрессии и мата.
@antonzvonar
Можно постить, обсуждать и помогать.
Без флуда, провокаций, агрессии и мата.
@antonzvonar
🤡4🔥3
🐳 Docker-образ с 3,17 ГБ до 354 МБ - почти в 9 раз меньше
Такая оптимизация обычно достигается не одной магией, а несколькими простыми приёмами:
- multi-stage build
-
- удаление build-зависимостей после сборки
- очистка
-
- установка только production-зависимостей
- объединение команд
Пример:
Что это даёт:
- быстрее pull/push
- быстрее CI/CD
- меньше места в registry
- быстрее запуск новых pod
- меньше потенциальная attack surface
Перед оптимизацией полезно посмотреть, что реально раздувает образ:
и отдельно проверить слои через
Большой Docker image почти всегда стоит сначала разобрать по слоям — часто там лежат гигабайты build-tools, cache и файлов, которые в runtime вообще не нужны.
Такая оптимизация обычно достигается не одной магией, а несколькими простыми приёмами:
- 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 вообще не нужны.
😁5👍2🤔2
Из вашего резюме вообще понятно, что вы умеете как DevOps-инженер?
Мы разбили работу DevOps-инженера на основные категории и сделали чекер, который показывает, какие из них в вашем резюме раскрыты хорошо, частично или почти не видны.
Опыт может быть - но по резюме этого не видно.
Проверь бесплатно и без регистрации:
https://updatecv.me/devops-resume-checker
А полный анализ резюме с правками доступен на: https://updatecv.me
Мы разбили работу DevOps-инженера на основные категории и сделали чекер, который показывает, какие из них в вашем резюме раскрыты хорошо, частично или почти не видны.
Опыт может быть - но по резюме этого не видно.
Проверь бесплатно и без регистрации:
https://updatecv.me/devops-resume-checker
А полный анализ резюме с правками доступен на: https://updatecv.me
💩6❤1
🐳 Как устроен Docker: что происходит «под капотом»
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (
– Docker CLI (
– REST API — взаимодействие 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 использует многослойную файловую систему. Каждый шаг
При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
Daemon вызывает
7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (
8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
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) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
-p, создать собственные сети, объединять контейнеры через docker network connect.В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
/proc виден). Для production стоит ограничивать права (например, --cap-drop).10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
runc для изоляции процесса7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍6
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
Классический 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
❤1💩1
Настраиваем простой 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-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.
Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного 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-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.
👍8❤4
Вопрос на собеседовании. Вопрос №6
Потеряете ли вы всю работу, если случайно покинете контейнер?
Нет, вы не потеряете никакой информации, данных и других параметров, если случайно покинете контейнер Docker.
Единственным способом потерять весь достигнутый прогресс будет выполнение соответствующей команды для удаления контейнера – выход из контейнера не причинит вреда информации.
#собеседование
Потеряете ли вы всю работу, если случайно покинете контейнер?
Единственным способом потерять весь достигнутый прогресс будет выполнение соответствующей команды для удаления контейнера – выход из контейнера не причинит вреда информации.
#собеседование
🤣6👍4
Kubernetes сам не запускает контейнеры.
Между кластером и контейнером работает отдельный слой — контейнерный runtime. От его выбора зависят особенности инфраструктуры, производительность и безопасность.
На открытом уроке разберём, как Kubernetes взаимодействует с runtime через CRI, сравним containerd, CRI-O и Kata Containers и обсудим сценарии их применения.
10 ноября в 20:00 МСК. Урок проходит в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes». Все участники получат скидку на обучение. Принять участие: https://vk.cc/d3AkT0
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Между кластером и контейнером работает отдельный слой — контейнерный runtime. От его выбора зависят особенности инфраструктуры, производительность и безопасность.
На открытом уроке разберём, как Kubernetes взаимодействует с runtime через CRI, сравним containerd, CRI-O и Kata Containers и обсудим сценарии их применения.
10 ноября в 20:00 МСК. Урок проходит в преддверии старта курса «Инфраструктурная платформа на основе Kubernetes». Все участники получат скидку на обучение. Принять участие: https://vk.cc/d3AkT0
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
❤1👍1🤡1