Comments 18
Статья полезная, но..... у меня всегда только один вопрос - ЗАЧЕМ? Зачем усложнять себе жизнь докером? Почему не развернуть это все на обычной виртуалке, а новые агенты например разворачивать через Ansible? В чем профит? Любая IaC тулза гарантирует идемпотентность.
Если отвечать честно, то на момент внедрения не было специалиста с экспертизой в Ansible и аналогов, а компетентности в Docker было достаточно. И казалось, что "условно за день" можно справиться своими силами без изучения Ansible. Задача оказалось разовой, работает вполне годно, удовлетворяет наши потребности.
Если бы был человек, который знает Ansible, скорее всего тогда бы делали с его помощью.
Спасибо за ответ. С этой точки зрения выглядит логично.
"компетентности в Docker было достаточно" для того, чтобы воткнуть вольюмы, privileged, и host-network. Ах да, еще root в контейнере "как быстрое решение". Ну и как вишенка на торте - отключенный лог-драйвер.
Ну т.е. вам просто нужен был chroot готовый для агента?
Затем что инфраструктуру, которая на каждый билд будет создавать чистую виртуалку (в которой не осталось ошмётков от предыдущих билдов), поднять сложнее чем инфраструктуру, которая на каждый билд будет создавать чистый контейнер.
Насколько я понял, такой задачи не стояло. Максимум речь была про переезд билд-агента на новую вм. Да и слабо себе могу представить ситуацию, при которой вам потребуется создавать НОВЫЙ агент на каждый билд. У нас например агенты молотили практически без перерыва, и каждый раз поднятие и остановка образа агента несла бы в себе дополнительные ненужные накладные расходы. Если у вас есть другой опыт - поделитесь, будет интересно. Я не холивара ради вопрос задавал :)
См. любой современный CI. GitHub Actions, GitLab CI, CircleCI, Travis, етц. Все они гарантируют запуск билда в девственно чистом окружении.
Не, подождите. С этими-то понятно, у них это by design. Я больше про Teamcity.
В этом есть смысл, но например на нашей практике сборки .NET/Angular кода без постоянного кэша nuget и npm пакетов... это была бы боль. It depends.
Кэш - это контролируемые ошмётки от предыдущих билдов, и во всех этих CI оно поддерживается. А вот какие-нибудь зависшие процессы (или ещё хуже, не зависшие, а продолжающие что-то делать после того как билд формально завершился) - это плохие, негодные ошмётки.
Лично нас кэш сильно выручает при выкачивании репозитория, а непосредстветвенно сборка у нас происходит при создании мультистейдж Docker образа - там всё чистенько. Плюс стоит настройка TeamCity, чтобы директория для билда чистилась перед сборкой.
С зависшими процессами лично мы не сталкивались, все шаги у нас можно разбить на 3 группы:
Подготовка аргументов. Это простейшие bash скрипты, там нечему зависать.
Собственно, сборка Docker образа. Сделано через обёртки TeamCity - при стопах билдов и тому подобному зависаний не заметили.
Пуш в Docker Hub.
Но в любом случае документация настоятельно рекомендует помнить о возможных проблемах безопасности (почитать можно здесь и здесь), и действовать на "свой страх и риск", потому что билды смогут получить рутовые права к хостовой машине. Мы поигрались с первым вариантом и решили выбрать второй.
Первый "здесь" не ссылается никуда
Способ через --priveleged точно так же позволяет билд-процессу заовнить хост-машину, это описано в вашей же ссылке "Документация"
NOTE: both of these options require extra trust to your builds, as a build may get root access to the host where the TeamCity agent container is running.
Судя по документации, у docker sock есть особенности при работе двух билд агентов на одном хосте, надо будет дополнительно настраивать.
И ещё из билда можно грохнуть контейнер билд агента.
Правильно ли я понял?
Есть хост с докером, в начале билда создаётся контейнер с пробросом sock, в него передаются сорцы (через вольюм или простым копированием), и внутри этого контейнера собирается итоговый образ через docker build... ?
Или сам контейнер создаётся на основе образа с компилятором и просто запускается башовая команда на компиляцию?
Статья отличная - два дня бился над той же проблемой, пока здесь не вычитал, что нужны образы агентов "teamcity-agent:****-linux-sudo", а не просто "teamcity-agent".
Автору большое спасибо!
Проблемы при сборке Docker образов внутри Docker контейнеров на TeamCity