Сломалась сборка образов в Gitlab

 Сегодня сборка Docker образов сломалась на docker-machine ранерах.

*** WARNING: Service runner-xxxxxxxx-project-xxxxx-concurrent-0-xxxxxxxxxxxxxx-docker-0 probably didn't start properly.
Health check error:
service "runner-xxxxxxxx-project-xxxxx-concurrent-0-xxxxxxxxxxxxxx-docker-0-wait-for-service" health check: exit code 1
Health check container logs:
2025-11-11T14:15:01.392368160Z FATAL: No HOST or PORT found                      
Service container logs:
2025-11-11T14:15:01.155180886Z cat: can't open '/proc/net/ip6_tables_names': No such file or directory
2025-11-11T14:15:01.156146175Z cat: can't open '/proc/net/arp_tables_names': No such file or directory
2025-11-11T14:15:01.159149102Z iptables v1.8.11 (nf_tables)
2025-11-11T14:15:01.198255845Z time="2025-11-11T14:15:01.197837859Z" level=info msg="Starting up"
2025-11-11T14:15:01.201660747Z time="2025-11-11T14:15:01.201577762Z" level=warning msg="Binding to IP address without --tlsverify is insecure and gives root access on this machine to everyone who has access to your network." host="tcp://0.0.0.0:2375"
2025-11-11T14:15:01.201682858Z time="2025-11-11T14:15:01.201643206Z" level=warning msg="Binding to an IP address, even on localhost, can also give access to scripts run in a browser. Be safe out there!" host="tcp://0.0.0.0:2375"
2025-11-11T14:15:01.201770114Z time="2025-11-11T14:15:01.201692789Z" level=warning msg="[DEPRECATION NOTICE] In future versions this will be a hard failure preventing the daemon from starting! Learn more at: https://docs.docker.com/go/api-security/" host="tcp://0.0.0.0:2375"

Вызовы docker завершались ошибкой

ERROR: Cannot connect to the Docker daemon at tcp://docker:2375. Is the docker daemon running?

Связано это с выходом Docker 29.0.0, который перестал быть совместимым с docker-machine (подробности есть в gitlab-org/gitlab-runner #39100 и cattle-ops/terraform-aws-gitlab-runner #1324).

Для исправления достаточно откатиться на предыдущую версию Docker добавив engine-install-url=https://releases.rancher.com/install-docker/28.3.3.sh в MachineOptions

Если используется модуль cattle-ops/terraform-aws-gitlab-runner, то это делается через добавление параметра

  runner_worker_docker_machine_ec2_options = [
    "engine-install-url=https://releases.rancher.com/install-docker/28.3.3.sh",
  ]

Привилегии приложений в контейнерах

Хорошей практикой является принцип наименьших привилегий (давать только те права которые нужны для выполнения задачи). На практике разработчики зачастую идут путём наименьшего сопротивления и копируют "рецепты" из интернета.

Далее несколько частых случаев с которыми мне доводится сталкиваться и варианты их решения.

Прослушивание портов ниже 1024

Если программа требует повышения привилегий для прослушивания портов 80 и 443 (или любых других до 1024), то можно изменить конфигурацию для прослушивания портов выше 1024 (например 8080 и 8443), а на балансировщике сделать преобразование портов. Если переназначение портов невозможно, то можно воспользоваться Linux capabilities и выдать только CAP_NET_BIND_SERVICE вместо выдачи прав пользователя root.

Очередное усыхание Docker Hub

 Всего через 5 дней (с 1 апреля 2025) Docker Hub вводит новые лимиты на скачивание образов. Изначально их планировали вводить с 1 марта 2025, но сдвинули на один месяц:

• 10 скачиваний в час для неавторизованных пользователей
• 100 скачиваний в час для авторизованных пользователей с бесплатным аккаунтом

Сейчас действуют такие лимиты (посмотреть их можно через Wayback Machine):

• 100 скачиваний за 6 часов для неавторизованных пользователей
• 200 скачиваний за 6 часов для  авторизованных пользователей с бесплатным аккаунтом

Количество скачиваний учитывает запросы к манифесту (/v2/*/manifests/*), для multi-arch образов будет два запроса вместо одного.

Образы которые участвуют в программах Docker Sponsored Open Source и Docker Verified Publisher не должны учитываться в этих лимитах.

Новых лимитов скорее всего не хватит чтобы даже мелкий kubernetes кластер пережил апгрейд нод. Если вы используете образы с DockerHub в своих окружениях, то стоит задуматься над использованием зеркал (например Amazon ECR Public Gallery) или загрузить нужные образы в локальный registry до того как это станет проблемой.

В GCP Cloud Build и GKE используется кеширование популярных образов Docker Hub через использование mirror.gcr.io:

Google Cloud services such as Cloud Build and Google Kubernetes Engine automatically check for cached images before attempting to pull an image from Docker Hub.

Проверка работы Distribution Registry

 Чтобы проверить работоспособность Distribution Registry достаточно только curl. Для примера получу манифест для образа registry.example.com/helloworld-python:latest

$ REGISTRY_USERNAME=read-only
$ REGISTRY_SERVER=registry.example.com
$ IMAGE_NAME=helloworld-python
$ IMAGE_TAG=latest

$ curl --user $REGISTRY_USERNAME \
  --header 'Accept: application/vnd.docker.distribution.manifest.v2+json' \
  https://$REGISTRY_SERVER/v2/$IMAGE_NAME/manifests/$IMAGE_TAG

Failed to establish a new connection: [Errno -2] Name does not resolve

Оптимизировал размер образа, который построен на базе Google Cloud SDK и столкнулся с ошибкой локальной сборки после переключения с google/cloud-sdk:497.0.0-slim на google/cloud-sdk:497.0.0-alpine:

Beginning update. This process may take several minutes.
ERROR: gcloud crashed (ConnectionError): HTTPSConnectionPool(host='dl.google.com', port=443): Max retries exceeded with url: /dl/cloudsdk/channels/rapid/components-2.json (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f2c42715950>: Failed to establish a new connection: [Errno -2] Name does not resolve'))

If you would like to report this issue, please run the following command:
  gcloud feedback

To check gcloud for common problems, please run the following command:
  gcloud info --run-diagnostics

Тестовый Dockerfile выглядит так:

FROM google/cloud-sdk:497.0.0-alpine

RUN gcloud components install gke-gcloud-auth-plugin && \
    gke-gcloud-auth-plugin --version

Медленная сборка Docker образа

На прошлой неделе начались заметил очень медленную сборку Docker образов на базе Ubuntu. Скорость загрузки с archive.ubuntu.com / security.ubuntu.com была в районе 400kB/s и ping до этих хостов был в районе 250ms. Поскольку на аналогичную проблему жаловался и коллега, то маловероятно что проблема с моим подключением к Internet (тем более что speedtest.net не показал ничего криминального).

Решить эту проблему можно несколькими способами:

1. Использовать местное зеркало Ubuntu (потребует редактирования Dockerfile)
2. Использовать кеширующий прокси сервер в конфигурации APT (потребует редактирования Dockerfile)
   
3. Использовать альтернативный DNS сервер, который будет резолвить archive.ubuntu.com/security.ubuntu.com на IP адрес зеркала (при условии что в sources не используется HTTPS)

Времени было мало и потому пошёл путём наименьшего сопротивления - использовал аргумент --add-host для команды docker build

$ docker build --add-host=archive.ubuntu.com:<IP> \
               --add-host=security.ubuntu.com:<IP> -t image-name .

Пакеты всё ещё скачивает из Internet, но зато подходит для большинства случаев и не требует дополнительных сервисов.

Тест работает локально, но не работает в CI пайплайне

В процессе прикручивания Continuous Integration (CI) к приложению столкнулся с ситуацией когда end-to-end сценарий тестирования не работает в пайплайне. В то же время он корректно отрабатывает на локальной машине. У окружения CI отстутствует прямой доступ в Internet, но это не должно играть никакой роли т.к. сценарий написан таким образом, что приложение не предполагает ходить за пределы локальной машины.

Тестовый сценарий запускает контейнеры для всех сервисов приложения, загружает контрольный набор данных в источник, запускает обработку и затем следит за ходом работы, отслеживая контрольные точки. Все выполнялось правильно до этапа где проверяется наличие ожидаемых объектов в объектном хранилище. Причем оно было полностью пустым, что указывало на серьезный сбой.

Подключаюсь к Spark UI и вижу что задание обработки данных напрочь отсутвует. Далее смотрю логи компонента, который отвечает за его создание, но там никакого криминала нет. Иду в контейнер Spark Worker и начинаю медитировать на логи, а точнее их практически полное отсутствие.

Монтирование EFS в кластере AWS ECS

Есть несколько способов смонтировать EFS в ECS кластере:

• монтировать EFS на ноде кластера из cloud-init/puppet/chef/ansible/etc и делать bind mount в контейнер при старте (придется монтировать EFS на каждой ноде кластера где может запуститься контейнер)
• монтировать EFS внутри контейнера контейнера (требует privileged для контейнера, т.к. монтирование файловой системы зависит от CAP_SYS_ADMIN)
• использовать EFS в качестве docker volume (вроде появилось начиная с docker api 1.21, но я точно не уверен)

Хочу подробнее остановиться на последнем варианте, т.к. на мой взгляд он наиболее универсальный, но требует относительно свежий docker daemon и ecs-agent.