Podman: Запускаем контейнеры без Docker. Быстро, безопасно и без демонов.

Многие привыкли, что контейнеры = Docker. Но в мире Linux набирает популярность Podman — инструмент, который делает то же самое, но с несколькими ключевыми улучшениями, особенно важными для безопасности и системной интеграции.

▪️ Главные отличия от Docker:

Нет демона: Podman работает без постоянного фонового процесса (dockerd), который требует прав root. Каждый контейнер запускается как дочерний процесс пользователя. Это снижает поверхность атаки.

Rootless-режим: Вы можете запускать контейнеры от имени обычного пользователя, без sudo. Изоляция на уровне ядра не позволит такому контейнеру получить права администратора на хосте.

Интеграция с systemd: Podman умеет генерировать systemd-юниты для ваших контейнеров, позволяя управлять ими как обычными системными службами.

▪️ Quick Start: Попробуем прямо сейчас
Команды практически на 100% совпадают с Docker, поэтому переучиваться не придется.

Установка:

sudo apt install podman или sudo dnf install podman

Запуск первого контейнера (Nginx):

Bash

# Обратите внимание, никакого 'sudo'
podman run -d --name my_nginx -p 8080:80 docker.io/library/nginx

-d: запуск в фоновом режиме.
--name: имя контейнера.
-p: проброс порта.

Просмотр запущенных контейнеров:

Bash

podman ps
# CONTAINER ID  IMAGE                           COMMAND               CREATED         STATUS             PORTS                 NAMES
# a1b2c3d4e5f6  docker.io/library/nginx:latest  nginx -g 'daemon o...   2 minutes ago   Up 2 minutes ago   0.0.0.0:8080->80/tcp  my_nginx

Управление контейнером как systemd-сервисом:
Это киллер-фича. Создадим systemd-юнит для нашего Nginx.

Bash

# Генерируем .service файл
podman generate systemd --name my_nginx > ~/.config/systemd/user/nginx.service

# Перезагружаем демона systemd для user-сессии
systemctl --user daemon-reload

# Запускаем и включаем автозагрузку сервиса
systemctl --user start nginx.service
systemctl --user enable nginx.service

Теперь ваш контейнер будет стартовать вместе с вашей пользовательской сессией и управляться как обычная служба!

Вывод: Podman — это отличная, более безопасная и системно-интегрированная альтернатива Docker для запуска одиночных контейнеров на Linux-серверах.

#Podman #Containers #Linux #DevOps #Security #Systemd

Linux: Cgroups — Как контейнеры держат свои обещания (и как вы можете)

Вы когда-нибудь задумывались, как Docker или Kubernetes могут гарантировать, что один контейнер не "съест" все ресурсы сервера, оставив остальные голодать? Ответ — cgroups (Control Groups).

Что такое cgroups?
Это механизм ядра Linux, который позволяет организовывать процессы в иерархические группы и управлять их доступом к системным ресурсам:

CPU: Сколько процессорного времени может использовать группа.

Memory: Максимальный объем оперативной памяти.

Disk I/O: Приоритет и скорость чтения/записи на диск.

Network: Ограничения на сетевой трафик.

▪️ Почему это важно для админа?

Контейнеры (Docker, Podman, LXC): Они используют cgroups как основу для изоляции ресурсов. Когда вы задаете -m 512M для Docker-контейнера, это cgroups устанавливает лимит памяти.

Защита от "шумных соседей": Если у вас несколько сервисов на одном VDS/сервере, вы можете создать cgroup для каждого и гарантировать, что один прожорливый процесс не подвесит всю систему.

Обеспечение SLA: Для критически важных сервисов можно выделить гарантированный минимум ресурсов.

Тюнинг производительности: Можно приоритезировать ресурсы для одних процессов и ограничить для других.

▪️ Простой пример: Ограничиваем CPU для "прожорливого" процесса
Представьте, что у вас есть скрипт heavy_calc.sh, который грузит одно ядро на 100%.

Создаем cgroup (например, cpulimit):

Bash

sudo mkdir /sys/fs/cgroup/cpu/cpulimit

Путь может немного отличаться в зависимости от версии Linux и наличия systemd.

Устанавливаем лимит CPU (например, 50% одного ядра):

Bash

# Для systemd cgroups v2:
# cd /sys/fs/cgroup/user.slice/user-1000.slice/
# sudo echo "cpu.max 50000 100000" > cpu.max
# Или более универсально для cgroups v1:
sudo bash -c "echo 50000 > /sys/fs/cgroup/cpu/cpulimit/cpu.cfs_quota_us"
sudo bash -c "echo 100000 > /sys/fs/cgroup/cpu/cpulimit/cpu.cfs_period_us"

cpu.cfs_period_us - общий период (100мс = 100000мкс)
cpu.cfs_quota_us - сколько микросекунд можно использовать за период. 50% = 50000мкс

Добавляем процесс в cgroup:
Сначала запустите ваш "прожорливый" процесс в фоновом режиме, получите его PID.

Bash

./heavy_calc.sh &
PID=$! # Запоминаем PID
sudo bash -c "echo $PID > /sys/fs/cgroup/cpu/cpulimit/tasks"

Теперь этот процесс не сможет использовать более 50% одного ядра, даже если сервер свободен.

🧠 Взгляд архитектора:
Понимание cgroups — это фундамент для работы с контейнерными технологиями и тонкой настройки производительности Linux-систем. Это тот уровень контроля, который позволяет строить по-настоящему стабильную и предсказуемую инфраструктуру, где ресурсы распределяются не случайным образом, а согласно вашим четким правилам.

#Linux #Cgroups #Containers #Performance #Systemd #DevOps

🚀 DevOps: Podman 5.0 — запускаем контейнеры без Root и лишних демонов 🛡️

Если ты всё еще используешь Docker-демона, который крутится под рутом, у нас для тебя новости из 2026 года. Podman окончательно стал взрослым. Главная фишка пятой версии — полностью переписанный сетевой стек (pasta), который сделал Rootless-контейнеры (запуск от обычного юзера) такими же быстрыми, как и обычные.

Техническая суть:
Podman не требует запущенного демона (daemonless) и позволяет запускать контейнеры в изолированных User Namespaces. Если хакер «сломает» контейнер, он окажется внутри системы с правами обычного бесправного пользователя.

Команды для старта:

# Запуск контейнера от обычного пользователя (без sudo!)
podman run -d --name my-app -p 8080:80 nginx

# Генерируем systemd-юнит, чтобы контейнер сам стартовал после ребута
podman generate systemd --name my-app --files --new

Зачем это нужно: Это стандарт безопасности. В 2026 году запуск Docker под root в продакшене без веской причины считается дурным тоном.

#devops #containers #podman #docker #security #sysadmin #admin_future

🐧 Linux: живёшь под root в контейнере — живёшь опасно. Исправляем за 10 минут

Коллеги, воскресный пост про вещь, которую игнорируют даже опытные администраторы. Зайди в любой Docker-окружение на среднестатистическом сервере и запусти:

docker inspect $(docker ps -q) --format '{{.Name}}: User={{.Config.User}}'

Готов поспорить — большинство контейнеров покажут пустой User. Это означает root внутри. 79% Linux-атак в 2026 году используют легитимные системные инструменты — bash, cron, curl. Контейнер с root-процессом при любом побеге из namespace превращается в полноценный вектор атаки на хост.

Исправляется в три шага:

# В Dockerfile: создаём непривилегированного пользователя
FROM ubuntu:24.04

RUN groupadd -r appgroup && \
    useradd -r -g appgroup -s /sbin/nologin appuser

# Устанавливаем зависимости под root — пока ещё нужно
RUN apt-get update && apt-get install -y nginx && \
    chown -R appuser:appgroup /var/log/nginx /var/cache/nginx

# Переключаемся на непривилегированного
USER appuser

CMD ["nginx", "-g", "daemon off;"]

# Для уже запущенных контейнеров — аудит прямо сейчас:
# Кто реально запускает процессы внутри:
docker exec <container> ps aux | head -5

# В docker-compose.yml — добавляем user для каждого сервиса:
# services:
#   app:
#     image: myapp:latest
#     user: "1001:1001"  # uid:gid непривилегированного пользователя

# Запрещаем privilege escalation на уровне демона Docker:
# В /etc/docker/daemon.json:
# {
#   "userns-remap": "default",
#   "no-new-privileges": true
# }

# Проверяем что флаг no-new-privileges работает:
docker run --security-opt no-new-privileges:true \
    --user 1001 alpine whoami

Зачем это нужно:
Контейнер не является изолированной средой по умолчанию. Безопасность зависит от корректной настройки. Запуск под root — это не дефолт ради удобства, это дефолт ради лени. После вчерашней CVE-2026-31431 «Copy Fail» — любой непривилегированный пользователь на хосте мог стать root. Если контейнер уже запускается как root — второй шаг атаки не нужен.

Итог: один Dockerfile и десять минут — и твои контейнеры перестают быть тривиальным вектором атаки. Запусти аудит сегодня.

#linux #docker #containers #security #hardening #sysadmin #admin_future