​​Расскажу про необычный инструмент, который в первую очередь будет полезен тем, у кого рабочая машина на 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

​​Недавно посмотрел видео про Diun (Docker Image Update Notifier). Это маленькая консольная утилита, которая делает одно простое действие - проверяет наличие обновлений для образов запущенных контейнеров на хосте. Если обновление есть, уведомляет через email, telegram, gotify, slack и другие каналы. Больше ничего не делает, не качает обновление, не применяет, не перезапускает образ.

Diun состоит из одного бинарника. Запустить можно как на хосте, создав службу systemd, так и в контейнере, прокинув туда docker.sock. Процесс описан в документации:

# docker run -d --name diun \
 -e "TZ=Europe/Moscow" \
 -e "DIUN_WATCH_WORKERS=20" \
 -e "DIUN_WATCH_SCHEDULE=0 */6 * * *" \
 -e "DIUN_WATCH_JITTER=30s" \
 -e "DIUN_PROVIDERS_DOCKER=true" \
 -e "DIUN_NOTIF_TELEGRAM_TOKEN=1493678911:AAHtETAKqxUH8ZpyC28R-wxKfvH8WR6-vdNw" \
 -e "DIUN_NOTIF_TELEGRAM_CHATIDS=211805263" \
 -v "$PWD/data:/data" \
 -v "/var/run/docker.sock:/var/run/docker.sock" \
 -l "diun.enable=true" \
 crazymax/diun:latest

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

Diun умеет следить за актуальностью образов запущенных Docker контейнеров, образов подов в Kubernetes, Swarm, Nomad. Также можно настроить наблюдение за образами, используемыми в определённых Dockerfiles или конфигурационных файлах yaml, где указаны образы.

Простая, маленькая, удобная утилита. Описание установки, настройки, работы:
▶️ Diun - это вам не watchtower

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

#docker #devops

​​Вчера свершилось знаменательное событие - заблокировали доступ к hub.docker.com с IP адресов в России. Теперь без лишних телодвижений не скачать образы из этого репозитория. Не очень понятно, зачем это сделали, почему только сейчас и в чём тут смысл, если обойти эту блокировку, как и многие другие, не представляет каких-то проблем.

Расскажу несколько простых разных способов обхода этой блокировки.

1️⃣ Самый простой - переключиться на какое-то зеркало. Их сейчас много появится и встанет вопрос доверия к ним. Пока можно гугловское зеркало использовать, но его скорее всего тоже рано или поздно для нас заблокируют. Для этого достаточно создать конфиг /etc/docker/daemon.json, если у вас его нет, следующего содержания:

{ "registry-mirrors": ["https://mirror.gcr.io"] }

Перезапускаем службу и пользуемся, как раньше.

# systemctl restart docker

Больше ничего менять не надо.

2️⃣ Использовать локально подключение докера к своему реджистри через прокси. Недавно я об этом рассказывал и там многие написали, типа зачем всё это, доступ не заблокирован. Потому что не будет вашего итальянского сыра ХАХАХАХА. Сегодня этот реджистри, завтра все остальные. Прокси тоже относительно просто решает вопрос для единичного хоста.

3️⃣ Можно глобально на общем шлюзе настроить VPN подключение к серверу за пределами РФ, маркировать весь трафик, что блокируется и отправлять его через VPN соединение. Я так делаю дома для себя и своих тестовых стендов. Рассказывал про эту настройку на примере Mikrotik.

4️⃣ Поднять собственный прокси для докера, который будет иметь доступ к hub.docker.com. Не важно, как это будет сделано у него: через VPN он будет подключаться, или сразу поднят на VPS за пределами РФ. Вы со своей стороны будете подключаться к этому прокси, а он будет по вашим запросам загружать образы.

Проще всего подобный прокси поднять с помощью Nexus repository. Показываю, как это сделать. Я сразу взял VPS за пределами РФ и развернул там:

# docker volume create --name nexus-data
# docker run -d -p 8081:8081 -p 8082:8082 --name nexus \
-v nexus-data:/nexus-data sonatype/nexus3

В файле /var/lib/docker/volumes/nexus-data/_data/admin.password смотрим пароль от пользователя admin. Идём в веб интерфейс Nexus по IP адресу сервера на порт 8081.

Переходим в раздел управления и добавляем новый репозиторий. Тип выбираем docker (proxy). Если вы сами к прокси будете подключаться через VPN или проксировать к нему запросы через ещё какой-то прокси, типа Nginx или HAproxy, то можно в свойствах репозитория выбрать только HTTP и порт 8082. Это упростит настройку. Рекомендую идти именно по этому пути, чтобы ограничить тем или иным способом доступ к этому репозиторию. Вы же не будете его открывать в общий доступ для всех. В таком случае можно будет установить флаг Allow anonymous docker pull. Не нужно будет на всех хостах аутентификацию проходить.

В качестве Remote Storage можно указать https://registry-1.docker.io. Это докеровский репозиторий. Остальные настройки можно оставить по умолчанию, либо изменить в зависимости от ваших предпочтений.

Также зайдите в раздел Security ⇨ Realms и добавьте Docker Bearer Token Realm. Без него аутентификация в реджистри не будет работать.

После создания репозитория, можно его открыть. Там будет показан его url в зависимости от ваших настроек порта, http и адреса самого Nexus. Теперь его можно использовать в настройках /etc/docker/daemon.json:

{
    "insecure-registries": ["10.105.10.105:8082"],
    "registry-mirrors": ["http://10.105.10.105:8082"]
}

Перезапускайте службу Docker и пробуйте. Можно аутентифицироваться в своём реджистри и что-то загрузить:

# docker login 10.105.10.105:8082
# docker pull nginx

Идём в веб интерфейс Nexus, смотрим обзор репозитория и видим там скачанный образ Nginx.

Пока на практике каких-то реальный проблем с ограничением доступа нет. Если кто-то использует другие способы, поделитесь информацией. С помощью Nexus можно прокси для любых репозиториев делать, не только Docker.

#devops #docker

​​Я некоторое время назад сделал подборку основных команд, которые использую при работе с Docker. За последнее время в комментариях увидел несколько команд для Docker Compose, которые сам не знал, но они полезны. Решил сделать такую же подборку и для Docker Compose. Сам их все не помню и либо лезу в свою шпаргалку, либо начинаю гуглить. Я тут не привожу самые очевидные команды, типа start, stop, restart с разными ключами и т.д.

📌 Запустить часть контейнеров:

# docker compose up ct1 ct2

📌 Проверить файл конфигурации. Не знал об этой команде и всегда использовал внешние линтеры. Встроенный намного удобнее.

# docker compose config

📌 Запустить новый контейнер и выполнить в нём команду:

# docker compose run ct1 /scripts/start.js

📌 Запустить команду в работающем контейнере:

# docker compose exec ct1 bash

Поясню, в чём тут разница. На первый взгляд команды похожи. Run удобно использовать для выполнения какой-то команды из контейнера, который постоянно не запущен. Например, там какой-то один бинарник или скрипт, который запускается, отрабатывает и больше он не нужен. Удобно запустить его через run. Новый контейнер запустится, отработает и завершит работу. А exec удобно использовать, когда надо что-то запустить в работающем контейнере. Это аналог docker exec.

📌 Посмотреть все логи или логи контейнера:

# docker compose logs
# docker compose logs ct1

📌 Скопировать файлы из/в контейнер:

# docker compose cp prometheus:/etc/prometheus/prometheus.yml ~/
# docker compose cp ~/prometheus/prometheus.yml prometheus:/etc/prometheus/

Последняя команда скопирует файл только если он лежит в директории с docker-compose.yml, который запущен.

📌 Приостановить и запустить контейнеры:

# docker compose pause
# docker compose unpause

Для приостановки контейнеров используется механизм cgroups freezer. Процессам отправляется команда SIGSTOP для заморозки и SIGCONT для продолжения работы.

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

# docker compose top

📌 Посмотреть графическую схему всего docker-compose. Используется экспериментальная возможность экспорта содержимого композа в формат программы graphviz:

# docker compose alpha viz --networks --ports --image

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

📌Выполнить тестовую отработку команды без реальных действий:

# docker compose cp prometheus:/etc/prometheus/prometheus.yml ~/ --dry-run

Можно добавлять --dry-run к любой команде. Актуально для копирования файлов, так как там легко ошибиться с путём или файлом.

Полный набор всех команд и возможностей Docker Compose можно посмотреть в документации:

⇨ https://docs.docker.com/compose/reference

#docker

​​Я в своё время, когда познакомился с CIS — Center for Internet Security, изучил некоторые их документы по настройке софта, с которым работаю. Вот список заметок:

▪️ Nginx
▪️ MySQL 5.7
▪️ Apache 2.4
▪️ Debian 11
▪️ Docker
▪️ Ubuntu 22.04 LTS
▪️ PostgreSQL 16

На основе документа CIS Docker Benchmark v1.6.0 (доступ только через VPN) создан open source продукт, который проверяет Docker контейнеры и настройки самой службы - Docker Bench for Security. Покажу, как им пользоваться.

Можно просто запустить скрипт на хосте и посмотреть его замечания и рекомендации:

# git clone https://github.com/docker/docker-bench-security.git
# cd docker-bench-security
# sh docker-bench-security.sh

Вот несколько замечаний, которые я получил на тестовом сервере. Это не всё, что там было, показываю просто для примера:

[WARN] 1.1.1 - Ensure a separate partition for containers has been created
[WARN] 1.1.3 - Ensure auditing is configured for the Docker daemon
[WARN] 2.2 - Ensure network traffic is restricted between containers on the default bridge
[WARN] 2.13 - Ensure centralized and remote logging is configured
[WARN] 4.5 - Ensure Content trust for Docker is Enabled

Вспоминаю разбор документа по докеру, там реально об этом идёт речь, что указано в замечаниях.

Похожую проверку можно запустить через Docker. Это тот же скрипт, но упакованный в контейнер, который тут же будет собран:

# docker-compose run --rm docker-bench-security

Проверки можно разделить и не делать сразу все. К примеру, запускаем только проверки образов и runtime:

# sh docker-bench-security.sh -c container_images,container_runtime

Для проверки конкретного образа, достаточно его указать при запуске скрипта. Образ должен быть скачан. Будут выполнены все проверки, в том числе хоста. При проверке образа это скорее всего не нужно. Имеет смысл сразу указать, что нас интересует только 4-й раздел проверок, относящихся к образам:

# docker image pull nginx
# sh docker-bench-security.sh -i nginx -c container_images

Напомню, что есть похожий инструмент Dockle, писал про него. Он делает примерно то же самое, но только для образов. Саму систему и службу docker не проверяет. Конкретно для образов он удобнее и информативнее, чем Docker Bench for Security, потому что проверяет не только по CIS, но и некоторым другим рекомендациям. Увидеть разницу проверок можно на тестовом образе от Dockle:

# docker run --rm goodwithtech/dockle:latest goodwithtech/dockle-test:v2
# sh docker-bench-security.sh -i dockle-test -c container_images

У Dockle вывод более подробный с большим числом замечаний. Эти проверки имеет смысл использовать в тандеме. Docker Bench for Security для хоста и службы, Docker для образов.

#cis #docker #devops