а, так ты в качестве агента используешь сам контроллер? ну, такое... в проде так делать не стоит
Читать полностью…доступ контроллера к сокету докера нужен только в случае использования докер-плагина (тот, который создаёт динамические агенты на контейнерах).
Читать полностью…В зависимости от удобства работы с docker. Недавно делал перенос с Jenkins Master Node с Windows на Linux. Проблем кроме как с правами на директории не возникло. Впечатление очень приятное создалось об архитектуре Jenkins. Фактически все лежит в одной папке - плагины, билды, секреты, отдельным файлом настройки, включая настройки авторизации, если что её можно "придушить", если например был настроен доступ по AD, а с нового места не доступен LDAP или Radius сервер.
Мой вывод - работа Jenkins в Docker или нет это вопрос того как удобнее с ним работать. Докеризация ничем не облегчает для меня лично использование или перенос.
На многопроцессорных мощностях с избыточными дисковыми хранилищем про запас и ОЗУ что бы не ниже 320 великолепных. Вдруг, что то пойдёт не так
Читать полностью…Доброго времени всем.
Подскажите, как лучше разворачивать дженкинс: в докере или нет?
Планируется один мастер, который будет собирать прошивки, а так же несколько агентов, которые будут цеплять собранные прошивки и запускать тесты на железках.
Агент планируется на одноплатниках, мастер на сервере.
да, в джобе не работает:
/var/folders/_3/f5p875pj7v95jbd4c6qv5fhr0000gn/T/jenkins2765818397710764199.sh: line 4: syntax error near unexpected token `buildResult:'
Build step 'Выполнить команду shell' marked build as failure
В общем, после эксмпериментов выяснилось следующее:
Если нет автоматическго запуска сервера после сборки, то контейнер завершает свою работу.
т. е. docker start <имя контейнера> не приводит к какому-либо результату.
диллема.
Я плагинами не пользуюсь. Монтирую сокет и вызываю докер напрямую.
Если им не собирать имиджи, тогда да, проблем нет.
Но в этом и проблема, что десяток вариантов все сделать и тому кто не нашел свой "вариант", соберёт кучу проблем
Если речь про сокет то
- Docker прекрасно живет на tcp
- Если собрать образ нужно то как я уже писал докер как таковой внутри не нужен
потому что это конструкция для пайплайна, не для шелл-скрипта. Для шелла надо иначе. Что-то вроде:
( docker stop <container> && docker rm <container> ) || echo 'not found'
Но тут всё завалится, если нет запущенного контейнера. Так что надо больше вложенностей добавить )
А. Так это freestyle-джоба, что ли?
емнип, обработка ошибок возможна только в случае пайплайна. Под рукой сейчас экземпляра дженкинса нет, проверить не могу
А зачем там docker start, если запускаться должен свежий образ?
Или я сильно пролабал контекст?
Если я прав, то надо сначала грохнуть запущенный контейнер, потом запускать с опцией -d
docker run -d <image>
И еще один момент. если попытаться удалить несуществующий образ перед началом сборки, то операция будет провалена, и сценарий Jenkins зафейлится
Читать полностью…Я похоже пролабал контекст. Но Сборка запуск и смоук тесты это разные стадии. Смоук и сборка могут идти в том же контейнере. А запуск он на хосте и в другой стадии.
Читать полностью…У контейнера должен быть уникальный тег-версия. Пройдет тесты - перекинешь latest на этот тег
Читать полностью…