​​Короткая заметка для тех, кто использует Docker. Вы знаете, как посмотреть параметры, с которыми запускался контейнер? Я лично не знаю и не изучал этот вопрос.

У меня выработалась привычка посла запуска контейнера с кучей параметров записывать команду для запуска либо к себе в заметки, если предполагаю, что она мне ещё пригодится, либо локально на сервере в домашней директории, где он запущен.

То есть запустив что типа этого:

# docker run \
--name insentry_watch \
--detach \
--restart unless-stopped \
--network host \
--volume insentry-data:/var/lib \
--volume /etc/timezone:/etc/timezone:ro \
--volume /etc/localtime:/etc/localtime:ro \
--stop-timeout 60 \
cr.yandex/crp5a5q503oamalo3iou/insentry-watch/linux/amd64:23.1.0.27

Я сохраню эту команду. А как узнать, с какими параметрами был запущен контейнер, если вы это забыли и не сохранили? Тут поможет runlike. Простое приложение, которое показывает полную команду, с которой был запущен контейнер. Runlike написан на python, так что можно установить через pip:

# pip install runlike

Либо просто запустить через Docker. Для этого он собран в отдельный контейнер:

# docker run --rm -v /var/run/docker.sock:/var/run/docker.sock assaflavie/runlike YOUR-CONTAINER

Жаль, что вывод сразу не форматируется. На выходе получается однострочная портянка.

Подозреваю, что всю эту информацию можно вытащить из docker inspect, но там слишком много всего. Не знаю, как оттуда вычленить только параметры запуска.

⇨ Исходники

#docker

​​Расскажу про необычный инструмент, который в первую очередь будет полезен тем, у кого рабочая машина на Linux. Он для этого был создан. Возможно где-то и на сервере пригодится, но в основном для тестов. Речь пойдёт про Distrobox. Это надстройка над контейнерами, которая позволяет их прозрачно интегрировать в систему.

Допустим, вам надо запустить какой-то софт, возможно с графическим интерфейсом, но его нет под ваш дистрибутив. У вас вариант либо запустить его в виртуальной машине, либо как-то самому наколхозить нужный контейнер и примапить его к хосту. Distrobox решает эту задачу за вас. Вы просто выбираете нужную систему, запускаете её через Distrobox и работаете там с нужным вам приложением. Оно запускается и ведёт себя так, как будто установлено локально. Пробрасываются каталог пользователя, иксы или wayland, звук, d-bus и udev. Приложение ведёт себя как локальное.

Distrobox для популярных дистрибутивов есть в базовых репозиториях. В свежих Debian и Ubuntu присутствует, так что установка стандартна:

# apt install distrobox

Например, запустим в Debian какую-нибудь программу, которая есть в Fedora. Для этого создаём контейнер с последней Федорой. Делать это нужно под обычным пользователем, не под root. Пользователь должен быть в группе docker. В самой свежей версии, установленной вручную, это уже поправлено и можно под root запускать.

# distrobox-create --name fedora --image fedora:latest

Заходим в контейнер:

# distrobox-enter fedora

При первом входе будет выполнена преднастройка. После её окончания окажетесь в оболочке контейнера. Теперь можно установить какую-нибудь программу:

# sudo dnf install appname

После установки выполняем экспорт этой программы из консоли контейнера:

# distrobox-export --app appname

Теперь с этой программой можно работать, как будто она установлена на хосте. По умолчанию distrobox захочет положить ярлык на рабочий стол. Если у вас машина без графического окружения, то получите ошибку. Вместо этого можно выгрузить через ключ --bin, указав явно путь к бинарнику в контейнере:

# distrobox-export --bin /usr/sbin/appname

Бинарник (а точнее скрипт запуска) запуска программы из контейнера будет положен на хост в директорию ~/.local/bin. Она должна существовать. Там же можно посмотреть, как всё это работает:

#!/bin/sh
# distrobox_binary
# name: fedora
if [ -z "${CONTAINER_ID}" ]; then
exec "/usr/local/bin/distrobox-enter" -n fedora -- /bin/sh -l -c '/usr/sbin/appname$@' -- "$@"
elif [ -n "${CONTAINER_ID}" ] && [ "${CONTAINER_ID}" != "fedora" ]; then
exec distrobox-host-exec /home/zerox/.local/bin/appname"$@"
else
exec /usr/sbin/appname"$@"
fi

То есть всё это решение просто SHELL обёртка вокруг докера для удобного применения. Используются заранее подготовленные образы. В принципе, Distrobox удобен и для простого и быстрого запуска контейнеров с различными базовыми системами с примапленными ресурсами к хосту. Ими удобно управлять или работать. Смотрим список контейнеров:

# distrobox list

Устанавливаем, удаляем:

# distrobox stop fedora
# istrobox rm fedora

Можно сделать себе тестовую виртуалку со всеми базовыми системами и заходить в нужную. Все ресурсы у всех систем примаплены к хосту.

⇨ Сайт / Исходники / Как это работает

#linux #docker

​​В Linux есть инструмент для сохранения состояния работающих процессов, в том числе PID, системные права, открытые файлы, используемую память, сокеты, tcp соединения и т.д. То есть полное состояние процесса сохраняется на диск. Делается это с помощью CRIU (Checkpoint Restore In Userspace). Причём работает она в пространстве пользователя, а не ядра ОС.

В свежих версиях Debian и Ubuntu CRIU есть в базовых репозиториях:

# apt install criu

Покажу сразу на наглядном примере, как это работает. Создаём скрипт test.sh, который выводит в консоль текущую дату:

#!/bin/sh
while :; do
sleep 1
date
done

Запускаем его и наблюдаем работу. Открываем соседнюю консоль. Создадим там директорию, куда сохраним состояние процесса:

# mkdir ~/criu && cd ~/criu

Смотрим pid нашего скрипта:

# ps -C test.sh
  PID TTY     TIME CMD
  748 pts/1  00:00:00 test.sh

Сохраняем состояние процесса. Это пример для процесса, запущенного в консоли, следовательно с привязкой к shell:

# criu dump -vvvv -o dump.log -t 748 --shell-job

Работающий процесс будет остановлен, а его состояние сохранено в локальную директорию. Можете посмотреть содержимое. Там будет много различных файлов с расширением .img.

Восстанавливаем работу процесса, находясь в директории с состоянием:

# criu restore -vvvv -o restore.log --shell-job

Он продолжит работу в открытой консоли. Можно выключить или перезагрузить систему. И после этого восстановить процесс. Он так же продолжит свою работу с момента заморозки.

Я пробовал переносить процесс в другую систему (Debian -> Ubuntu), но там восстановить не получается. Должно быть такое же окружение и системные файлы. У меня он сразу ругался на разные размеры бинарников dash и sleep. Для реальной миграции между системами нужно соблюсти ряд условий, описанных в документации.

Изначально проект был открыт для создания инструмента по заморозке и переноса контейнеров OpenVZ, но сейчас расширил свою работу на LXC/LXD, Docker. Вот пример, как сохранить состояние Docker контейнера и запустить вновь: ⇨ https://criu.org/Docker_External.

Посмотрел немного записей на youtube по этой теме. Люди сохраняют открытые VNC сессии со всем софтом и открытыми TCP соединениями. Пример с открытым видео в браузере. После восстановления, продолжается воспроизведение практически на том же месте. Также инструмент применим для сохранения и восстановления контейнеров в Kubernetes.

⇨ Сайт / Исходники

#linux #docker

​​Для автоматической проверки Docker образов на уязвимости (CVE) есть хороший open source инструмент Trivy. Год назад я делал по нему пару заметок с обзором и автоматическим исправлением уязвимостей. Потом всё это в небольшую статью оформил.

Этот продукт хорошо дополняет open source утилита Dockle. Она тоже проверяет контейнеры на уязвимости, но помимо этого проверяет образ на соответствие best-practice Dockerfile и рекомендации CIS Docker Benchmarks (#cis).

Использовать очень просто, так как это по сути одиночный бинарник. В репозитории есть пакеты для установки под все популярные системы. Можно запустить и в Docker без установки:

# docker run --rm goodwithtech/dockle:v0.4.14 [YOUR_IMAGE_NAME]

Пример отчёта можно посмотреть на тестовом образе, для которого есть замечания:

# docker run --rm goodwithtech/dockle:v0.4.14 goodwithtech/dockle-test:v2

С помощью ключа -f json вывод можно сохранить в json файле. Dockle легко интегрировать в пайплайн. В репозитории есть примеры (gitlab).

⇨ Исходники

#docker #devops #cicd #security

​​Если вам нужно продебажить какой-то контейнер, в котором нет никаких инструментов для диагностики (а это почти всегда так), то для этого можно воспользоваться специально собранным для этих целей контейнером - Network-Multitool. Его ещё любят в кубернетисе запускать для отладки. Известная штука.

Работает он примерно так. Запускаем контейнер, внутри которого ничего нет, кроме nginx:

# docker run --name nginx -d -p 8080:80 nginx
# docker exec -it nginx bash
# ps axf
bash: ps: command not found

Подключаем к нему network-multitool:

# docker run --rm -it \
--network=container:nginx \
--pid container:nginx \
wbitt/network-multitool:alpine-extra bash

# ps axf
  PID TTY   STAT  TIME COMMAND
   47 pts/0  Ss   0:00 bash
   60 pts/0  R+   0:00 \_ ps axf
   1 ?    Ss   0:00 nginx: master process nginx -g daemon off;
   29 ?    S   0:00 nginx: worker process
   31 ?    S   0:00 nginx: worker process
   30 ?    S   0:00 nginx: worker process
   32 ?    S   0:00 nginx: worker process

Дальше всё остальное можно запускать: ping, dig, tcpdump и т.д.

Я тут выбрал самую жирную сборку alpine-extra, где максимальный набор инструментов, в том числе tshark, ApacheBench, mysql & postgresql client, git и т.д. Если всё это не надо, то используйте alpine-minimal. Описание сборок в репозитории.

Похожую функциональность имеет cdebug. У него принцип работы такой же, только он для удобства собран в бинарник. А подключается он к контейнерам точно так же.

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

# docker run --rm -it --network=host wbitt/network-multitool:alpine-extra bash
# tcpdump

На хост ничего ставить не надо. Полезная штука, берите на вооружение.

#docker #devops

​​К обоим заметкам на тему дебага Docker контейнеров, когда мы к ним цепляемся и запускаем различные утилиты, были комментарии на тему того, что можно просто подключиться к пространству имён (namespace) контейнера с хоста и запустить всё, что нужно. Вот мои прошлые заметки по этой теме:

- Network-Multitool
- Cdebug

Мне лично идея со специальными контейнерами кажется более удобной, потому что там все инструменты уже собраны и на сам хост ничего ставить не надо. Но для полноты картины расскажу и про способ с namespaces. Там всё очень просто.

Узнаём PID процесса в контейнере nginx:

# docker inspect -f '{{ .State.Pid }}' nginx
1009

Запускаем нужную нам утилиту в пространстве контейнера:

# nsenter -n -t 1009 netstat -tulnp

Соответственно, видим процесс nginx, слушающий 80-й порт. Так можно любую утилиту с хоста запустить. Вот вариант в одну строку:

# nsenter -n -t $(docker inspect -f '{{ .State.Pid }}' nginx) ip a

Сразу увидели ip адрес контейнера. Это то же самое, что:

# docker inspect -f '{{ .NetworkSettings.Networks.bridge.IPAddress }}' nginx

Какую команду проще и быстрее запомнить, судить не берусь. Правда, конкретно с IP я смотрю вот так:

# docker inspect nginx | grep IP

Сразу видно адрес. Думаю, идею поняли. Вот ещё пример. Надо посмотреть, как и через какой dns контейнер резолвит домены:

# nsenter -n -t $(docker inspect -f '{{ .State.Pid }}' nginx) dig ya.ru MX

Вообще, про nsenter и в целом про namespaces имеет смысл отдельную заметку написать. Думаю, сделаю это в ближайшее время.

#docker

​​В пятницу рассказывал про ролик, где показан запуск системы Windows через Docker контейнер. Меня заинтересовала эта штука, так что решил сразу попробовать, как это работает. А работает неплохо, мне понравилось.

Есть репозиторий, где всё подробно описано:

⇨ https://github.com/dockur/windows

Я решил попробовать работу этого проекта на обычной виртуальной машине Proxmox, где включена вложенная виртуализация. Для виртуалки тип процессора установил host. Больше никаких особенных настроек не делал.

Скопировал себе репозиторий и запустил дефолтный docker compose:

# git clone https://github.com/dockur/windows
# cd windows
# docker compose up

Был создан и запущен контейнер с Windows 11. Ничего не заработало, так как контейнер не смог загрузить образ системы, о чём сообщил в консоли. Там же была информация о том, что с моего IP нельзя выполнить загрузку. Судя по всему это работает блокировка Microsoft. Можно скачать образ вручную и подсунуть его контейнеру. Мне не захотелось заморачиваться.

Я просто изменил систему на Windows 10, добавив в окружение переменную, как показано в репозитории.

version: "3"
services:
 windows:
.................................
  environment:
   VERSION: "win10"
.................................

И запустил ещё раз. На удивление, всё прошло успешно. Стартовал контейнер, загрузил образ системы, развернул его, выполнив стандартную установку. За процессом можно наблюдать через веб интерфейс, зайдя по ip адресу сервера, указав порт 8006. Участие не требуется, всё выполняется автоматически. Никаких ключей вводить не надо. На выходе будет неактивированная, полностью легальная система.

Длилось всё это минут 30. На хосте должно быть достаточно свободного места и ресурсов системы. По умолчанию контейнеру выделяется 2 CPU, 4 GB памяти и 64 GB диска. Эти настройки можно изменить через environment.

У меня первый раз не хватило места на диске, второй раз память закончилась. Тогда я всё же сходил в репозиторий и уточнил информацию по ресурсам, которые требуются.

После запуска системы, с ней можно работать через браузер, либо по RDP. Специально ничего настраивать не надо. По RDP можно подключиться, указать пользователя docker, пароль пустой.

Мне очень понравилось, как тут всё организовано. Для тестовых стендов отличный инструмент. Весь ручной труд сделан за нас. Достаточно просто запустить контейнер и на выходе получить готовую систему. Можно на одной виртуалке держать полный набор различных тестовых систем Windows и запускать по мере надобности.

Работает всё это на базе KVM. От Docker тут только автоматизация запуска и управления.

#windows #docker

​​Западные блокировки в интернете добавляют лишнюю суету в повседневную работу. Я вам покажу очень простой и быстрый способ, как их обходить на примере загрузки и запуска продуктов elastic. Как известно, с территории РФ их скачать невозможно, как и воспользоваться репозиторием docker образов.

Для этого нам понадобится любая VPS и доступ к ней по SSH. Главное, чтобы с неё ничего не блокировалось. Ставим туда локальную прокси privoxy:

# apt install privoxy

Больше можно ничего не настраивать. Нам подойдут настройки по умолчанию. Прокси сама запустится на локальном интерфейсе 127.0.0.1:8118. Можно тут её оставить на постоянную работу.

Теперь идём на сервер, куда мы хотим установить elasticsearch. Если мы просто попытаемся скачать пакет, у нас ничего не выйдет:

# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.2-amd64.deb
HTTP request sent, awaiting response... 403 Forbidden

Доступ заблокирован. Подключимся по SSH к серверу с privoxy и пробросим её порт 8118 локально на машину на порт 3128:

# ssh -L 3128:localhost:8118 root@1.2.3.4

Проверяем, что порт проброшен:

# ss -tulnp | grep 3128
tcp  LISTEN 0   128    127.0.0.1:3128    0.0.0.0:*  users:(("ssh",pid=1350,fd=5))

Теперь сделаем так, чтобы wget работал через прокси. Для этого рисуем конфиг ~/.wgetrc:

use_proxy=yes
http_proxy=127.0.0.1:3128
https_proxy=127.0.0.1:3128

И снова скачиваем пакет. Теперь он успешно загрузится, можно устанавливать.

Если хочется запустить elasticsearch в докере из официального образа, то подключаем прокси докеру. Для этого передаём ему переменные через systemd. Все возможные варианты настройки прокси в докере описаны в документации.

# mkdir -p /etc/systemd/system/docker.service.d
# mcedit /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:3128"
Environment="HTTPS_PROXY=http://127.0.0.1:3128"

 # systemctl daemon-reload
 # systemctl restart docker

Обращаю внимание, что в качестве HTTPS_PROXY я передаю http подключение. Это важно. Privoxy не настроен на работу по https, а Docker хочет именно по https забирать образы. Проверим, что переменные объявлены:

# systemctl show --property=Environment docker
Environment=HTTP_PROXY=http://127.0.0.1:3128 HTTPS_PROXY=http://127.0.0.1:3128

Теперь можно забрать образ последней версии и запустить его:

# docker pull docker.elastic.co/elasticsearch/elasticsearch:8.13.2
# docker run -d -e "discovery.type=single-node" \
  -p 9200:9200 \
  -p 9300:9300 \
   docker.elastic.co/elasticsearch/elasticsearch:8.13.2

После того, как всё скачано и запущено, настройки прокси можно отключить.

Такой простой и быстрый метод с использованием своего прокси. Не надо искать сторонние репозитории или настраивать свои. Не надо подключать VPN и что-то ставить дополнительно на исходный сервер. Забрали всё с репозитория разработчиков, сделав минимум движений на сервере, куда всё устанавливали.

#elk #ssh #docker

​​Подбиваю старые полезные публикации, которых накопилось очень много за несколько лет. В этот раз решил сделать подборку на тему Docker. Сначала список наиболее часто используемых команд на основе личного опыта. А в конце ссылки на другие публикации по этой теме.

🟡 Установка Docker:

curl -o - https://get.docker.com | bash -

🟡 Запуск контейнера в режиме службы на конкретном порту с автоматическим запуском при загрузке сервера:

docker run -d -p 80:80 --restart always --name nginx-proxy nginx

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

docker ps
docker ps -a

🟡 Удаление остановленного или работающего контейнера:

docker rm nginx-proxy
docker rm -f nginx-proxy

🟡 Остановить и удалить все контейнеры:

docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)

🟡 Просмотр образов, удаление одного или сразу всех:

docker images
docker rmi nginx
docker rmi $(docker images -a -q)

🟡 Вход в консоль контейнера:

docker exec -it nginx-proxy bash

🟡 Просмотр всех логов контейнера, 100 последних строк или следить за ними:

docker logs nginx-proxy
docker logs -n 100 nginx-proxy
docker logs -f nginx-proxy

🟡 Статистика потребляемых ресурсов контейнера или группы контейнеров:

docker stats nginx-proxy
docker stats prometheus exporter
docker stats prometheus --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

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

docker top nginx-proxy

🟡 Информация о контейнере и пример выборки из неё разными способами:

docker inspect nginx-proxy
docker inspect -f '{{ .NetworkSettings.Networks.bridge.IPAddress }}' nginx-proxy
docker inspect --format '{{json .Mounts}}' grafana | jq .

🟡 Проверить занимаемое место докером:

docker system df

🟡 Очистить неиспользуемые данные:

docker system prune

🟡 Скопировать файл с контейнера на хост и наоборот:

docker cp nginx-proxy:/etc/nginx/nginx.conf ~/nginx
docker cp ~/nginx/nginx.conf nginx-proxy:/etc/nginx

🟡 Экспорт файловой системы контейнера:

docker export nginx-proxy -o ~/nginx-proxy.tar.gz

📌 Заметки по теме:

🔥 Portainer - веб панель для Docker
▪️ Локальный репозиторий docker образов - Nexus
▪️ Работа Docker daemon через http proxy
▪️ Дебаг контейнеров с помощью Network-Multitool
▪️ Диагностика работы контейнеров с помощью cdebug
▪️ Доступ к Docker daemon socket извне
▪️ Посмотреть, с какими параметрами был запущен контейнер
▪️ Линтер для Dockerfile - Hadolint
▪️ Sinker - синхронизации образов Docker из одного репозитория в другой
▪️ Дамп mysql базы из докер контейнера

📊 Мониторинг одиночного хоста с Docker
📊 Сtop - top для контейнеров
📊 Мониторинг Docker с помощью Zabbix

🛡 Рекомендации CIS по настройке Docker
🛡 Автоматическое исправление уязвимостей с помощью Copacetic
🛡 Проверка образов на уязвимости с помощью Trivy
🛡 Проверка образов с помощью Dockle
🛡 Заблокировать на файрволе доступ к контейнерам извне

🎓 Основы Docker. Большой практический выпуск для новичков
🎓 Бесплатный тренажёр для изучения Docker
🎓 Отличия Docker от LXC

🗃️ Бэкап вольюмов с помощью Docker-volume-backup
🤔 Docker Desktop for Windows

#docker #подборка

​​Если вдруг вам хочется чего-нибудь странного, то могу вам кое-что предложить. Например, запустить контейнеры Docker в LXC контейнере Proxmox. Я изначально думал, что это так просто не сработает. Всегда запускаю контейнеры в виртуалках. Тут решил попробовать в LXC, сразу заработало.

Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:

# apt install curl
# curl https://get.docker.com | bash -
# docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.

#proxmox #docker