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

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

Решение такое. Образ надо скачать, создать контейнер, но не запускать его.

# docker pull nginx:latest
# docker create --name nginx nginx:latest

Теперь можно забрать нужный файл:

# docker cp nginx:/docker-entrypoint.d/30-tune-worker-processes.sh ~/

Либо выгрузить всё содержимое образа:

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

Заодно расскажу про один полезный инструмент, который рекомендую сохранить тем, кто работает с Docker. Dive - небольшая утилита на Go, которая позволяет просматривать слои образов и видеть, в каком слое что добавилось. У утилиты простой и наглядный tui интерфейс.

Можно скачать бинарник dive из репозитория или запустить сразу в докере и посмотреть нужный тебе образ:

# docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive nginx:latest

Увидите структуру файловой системы с подсветкой цветом разных слоёв. Если постоянно работаете на своей машине с образами, сделайте alias:

alias dive="docker run -ti --rm -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive"

Теперь можно просматривать образы так:

# dive nginx:latest

Удобная штука. Помимо отображения слоёв, она умеет проверять, не раздут ли размер образа из-за неправильных инструкций для сборки. Для этого можно собрать образ с помощью dive и сразу же получить результат анализа. То есть вместо docker build делаем dive build и получаем оценку. Подобную проверку можно встроить в CI систему и выполнять автоматически. В репозитории приведены примеры.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops

Тестировал вчера open source панель для управления сервером и установки на него софта - Cosmos. Сам автор позиционирует её как Secure and Easy Selfhosted Home Server. Панель и сама работает в Docker, и софт запускает тоже в контейнерах. Это уже не первая подобная панель на канале. Сразу скажу, что ничего особенного в ней не увидел. Она не лучше и не проще всех остальных похожих.

В целом, пользоваться можно. Даже русский язык есть, но переведено кривовато. Я переключился на английский. У всех подобных панелей на базе Docker есть один существенный минус. Они хоть и позиционируют себя как простые и быстрые в настройке, на деле это не так. Запуск приложений в Docker, особенно когда их много на одном сервере, требует от пользователя понимания, как всё это между собой связано и работает. Постоянно возникают небольшие нюансы в работе, которые не решить без этих знаний. А если вы знаете Docker, то и панель вам особо не нужна. Ставишь Portainer и запускаешь всё там.

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

▪️Интерфейс адаптивен, работает и на мобильных устройствах.
▪️Можно создавать пользователей веб панели. Бесплатная версия позволяет создать 5 штук.
▪️Панель нативно поддерживает работу MergerFS и SnapRAID.
▪️Из коробки HTTPS от Let's Encrypt.
▪️Поддержка OAuth 2.0 и OpenID, 2FA через Google аутентификатор или аналоги.
▪️Есть встроенные средства безопасности, на основании которых можно ограничивать доступ к публикуемым ресурсам. Можно ограничивать доступ на основе групп. Блокировать ботов, тех, кто превышает лимиты по запросам или трафику.

Запустить и посмотреть на Cosmos можно так:

# docker run -d --network host --privileged --name cosmos-server -h cosmos-server --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket -v /:/mnt/host -v /var/lib/cosmos:/config azukaar/cosmos-server:latest

Если настроено доменное имя, то можно сразу получить сертификат от Let's Encrypt, а все устанавливаемые службы будут запускаться на поддоменах. Если же сделать установку без HTTPS по IP адресу сервера, то сервисы будут подниматься на отдельных TCP портах. Я и так, и так попробовал.

Аналоги Cosmos:

◽️CasaOS
◽️Runtipi

Мне лично CasaOS больше всего понравилась. Она более целостно смотрится, магазин приложений больше, как и в целом сообщество. Но Cosmos более функциональна в базе.

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

#docker #linux

Когда разбирался с контейнером openvpn-monitor, про который вчера писал, пришлось немного его подебажить, так как он никак не хотел подключаться к консоли OpenVPN сервера. Писал стандартную ошибку в веб интерфейсе - connection timeout и адрес с портом сервера. Я и так, и сяк адреса и доменные имена пробовал, ни в какую.

Как это обычно бывает, контейнер внутри пустой. Там нет ничего, что помогло бы проверить сетевую связность. Ситуация рядовая, так что решение в целом понятное. У меня было несколько заметок по этой теме. Расскажу, как я решал задачу.

Есть удобный инструмент cdebug. Представляет из себя обычный бинарник. Скачиваем его на хост, где работает контейнер:

# mkdir ~/cdebug && cd ~/cdebug
# wget https://github.com/iximiuz/cdebug/releases/download/v0.0.18/cdebug_linux_amd64.tar.gz
# tar xzvf cdebug_linux_amd64.tar.gz

Подключаемся к нашему контейнеру:

# ./cdebug exec -it openvpn-monitor

Оказываемся в его консоли и получаем все утилиты из комплекта BusyBox. Там мне понадобились буквально 2 утилиты: ping и telnet. Сначала пинганул VPN сервер и убедился, что сетевая связность есть. Потом через telnet понял, что не подключаюсь к настроенному порту консоли.

Оказалось, что банально файрвол блокировал запросы. В принципе, я об этом догадывался, но там много правил было наворочено. Думал, что доступ будет. Не хотелось лишний раз трогать iptables и включать логирование всех заблокированных пакетов. Там бы я тоже увидел, что соединения блокируются. Вариант с cdebug показался проще. Убедился наверняка, что проблема с файрволом и поменял некоторые правила.

С помощью cdebug можно подключаться к подам кубера. В докере можно пробрасывать новые порты из контейнера на хост без перезапуска контейнера. Можно подцепить к контейнеру образ с tshark на борту и собрать трафик изнутри контейнера. Очень простая и удобная программа. Если работаете с контейнерами, рекомендую сохранить и освоить.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops

У меня на канале выходит много заметок с использованием Docker. Хочу высказать своё мнение по поводу его использования. Где-то считаю его уместным, а где-то не очень. Расскажу, как к этому отношусь.

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

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

Возьмём к примеру сервер мониторинга Zabbix. Он что через Docker контейнер ставится в пару действий, что через пакетный менеджер. То есть использование контейнера не упрощает установку, поэтому я не вижу смысла его ставить в прод через Docker. Он ставится и обновляется в одно действие:

# apt install zabbix-server-mysql
# apt update zabbix-server-mysql

И через Docker:

# docker run --name zabbix-server-mysql -e DB_SERVER_HOST="some-mysql-server" -e MYSQL_USER="some-user" -e MYSQL_PASSWORD="some-password" --init -d zabbix/zabbix-server-mysql:tag

Зачем тут лишняя сущность в виде Docker? Он будет иметь смысл для каких-то тестовых сборок из набора контейнеров, чтобы быстро запускать в разных средах, что-то тестировать, удалять и т.д. Тогда да, можно собрать compose и использовать. Но если нужно будет поставить в прод, то я поставлю из пакетов. Мне так проще и удобнее в эксплуатации.

То же самое относится к Nginx, Angie, Mysql, Php-fpm, Prometheus и т.д. То, что по сути состоит из пакета или бинарника и файла конфигурации к нему не вижу смысла запускать в постоянную эксплуатацию в контейнере. Если у разработчиков есть собранные пакеты, то буду использовать их.

Другое дело более сложный в плане установки софт, для которого пакетов нет. Тогда вручную его собирать, устанавливать, обновлять и поддерживать может быть очень хлопотно. Наглядные примеры, с которыми сталкивался сам - Onlyoffice, Webpagetest. У первого хоть и есть пакеты, но с ними много проблем с зависимостями. Часто нельзя обновиться без ошибок. У второго вообще пакетов нет, его ставить вручную – пуд соли съесть. Причём я ставил, вопрос решаемый, но очень трудоёмкий. Не хочется этим заниматься.

❗️Отдельно выделю софт, который может быть полностью сконфигурирован через переменные окружения при запуске контейнера и не требует подключения файлов конфигурации. Тут без вопросов, запустить в одну команду с ключами проще, чем ставить и отдельно готовить файл конфигурации. Пример - Traefik. У него доступно динамическое управление конфигурацией через переменные. Это удобно.

☝️ Подвожу итог. Всё, что не касается микросервисов, я запускаю в Docker только если установка из пакетов невозможна, либо слишком трудоёмка. Продукты, для которых у разработчиков есть репозитории под Debian, будут установлены из репозиториев. Речь идёт именно о промышленной эксплуатации, а не тестовых запусках.

Если речь идёт о связке нескольких продуктов в единое целое, то тоже буду смотреть на сложность установки и обновления. Если связку можно поставить по отдельности и потом через apt upgrade обновлять, то скорее всего соберу из пакетов. Если нужны будут дополнительные действия после обновления пакетов, то скорее всего буду использовать предоставленный docker compose.

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

#docker #мнение

Иногда перед запуском контейнеров в Docker Compose хочется выполнить какой-нибудь скрипт или просто набор команд. У данной задачи может быть много различных решений. Предлагаю одно из них, когда перед запуском основных контейнеров запускается какой-то малюсенький c оболочкой, например, sh.

С помощью такого трюка можно запустить какие-то миграции для БД или залить туда какой-то дамп с данными или схемой, сгенерировать какой-нибудь конфиг, создать нужные директории или просто что-то записать, если по какой-то причине вам это надо сделать именно там (куда же без костылей). Для того, чтобы не тащить внешние скрипты, выполним всё прямо в command первого контейнера.

Удобно для этого взять busybox, потому что там много всего есть и он маленький. Но можно обойтись и голым alpine.

services:
 init-nginx:
  image: alpine
  command: ["/bin/sh", "-c", "echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf && echo 'Compose Exec' > /html/index.html"]
  volumes:
   - nginx_config:/config
   - nginx_html:/html

 nginx:
  image: nginx:latest
  volumes:
   - nginx_config:/etc/nginx/conf.d
   - nginx_html:/usr/share/nginx/html
  ports:
   - "8080:80"
  depends_on:
   init-nginx:
    condition: service_completed_successfully

volumes:
 nginx_config:
 nginx_html:

Прямо в compose файле создали конфигурацию Nginx и добавили статическую страничку. Вместо длинной строки command можно записать более наглядно:

  entrypoint: /bin/sh
  command:
   - "-c"
   - |
    echo 'server { listen 80; root /usr/share/nginx/html; }' > /config/nginx.conf
    echo 'Compose Exec' > /html/index.html

Если что-то пойдёт не так и команда не будет выполнена успешно, то второй контейнер не запустится из-за condition: service_completed_successfully.

Если надо что-то сделать на самом хосте перед запуском контейнеров, то просто через volumes подключаем директорию хоста и делаем там всё, что нам надо.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops

Для тех, кто ещё не слышал или не знает, расскажу новости про ограничения на загрузку образов из Docker Hub. Вышла какая-то непонятная история, поэтому решил разобраться. Компания Docker анонсировала внедрение новых лимитов на загрузку образов из их хранилища, причём довольно суровых. Обещали только 10 загрузок в час для неаутентифицированных пользователей. То есть сделали в час 10 docker pull и получили временный бан, пока лимит не сбросится.

Ограничение довольно суровое даже для каких-то личных историй с тестами локально, не говоря уже об использовании в пайплайнах. Прогнал несколько отладочных тестов и всё. Для аутентифицированных пользователей, даже бесплатных, обещали 100 запросов в час, что в целом уже приемлемо и можно пользоваться, как прежде.

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

Зашёл на днях на страничку с лимитами и удивился, так как никаких новых лимитов там нет, можно не суетиться. Хотя я своими глазами видел, что они были, и даже отдельно была выделена новость, что с 1-го апреля они изменились. По факту сейчас всё так же, как и было: 100 запросов за 6 часов без аутентификации и 200 с ней. Протёр глаза и понял, что мне не мерещится. Реально изменений нет.

Сходу как-то даже новости на нашёл на эту тему. Практически молча всё откатили обратно, как было. Немного поискав, нашёл обновлённую старую новость от 21 февраля:

April 8, 2025: No changes to Docker Hub rate limits at this time

Не знаю, по какой причине, но они передумали вводить новые лимиты. И пообещали, что если опять надумают, то предупредят минимум за 6 месяцев.

Для того, чтобы не зависеть от каких-либо ограничений со стороны Docker Hub, можно использовать свои registry. Настроить их очень просто и быстро. Вообще никаких проблем:

▪️Nexus
▪️Harbor
▪️Gitlab Registry
▪️Docker Registry + UI

Для того, чтобы туда автоматом закидывать образы с Docker Hub, можно воспользоваться, к примеру, Sinker. Или чем-то ещё. Таких утилит много. Можно настроить обращения к Docker Hub так, чтобы не выходить за лимиты, и держать свой локальный registry с актуальными образами.

#docker #devops

У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:

⇨ Проверка безопасности Docker образов с помощью Trivy

Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.

TruffleHog поддерживает следующие источники информации:

◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры

И некоторые другие источники. Не стал их все перечислять.

Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.

Работает примерно так:

# trufflehog git https://github.com/trufflesecurity/test_keys

Это пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:

# curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin

Можно просто в Docker запустить:

# docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys

Если запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.

Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:

# trufflehog filesystem --config=$PWD/generic.yml /var/log

Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.

Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#docker #devops #cicd #security