Comments 16
1) А зачем кастомный образ для Jenkins master, если можно просто пробросить докер сокет в контейнере, как показывают в документации?
2) А последний приведённый Jenkinsfile точно рабочий? Мне казалось, что если мы хотим указать agent в каком-то из stage, то мы должны в самом начале сделать agent none, или уже что-то изменилось?
3) Возможно сразу использованать docker-plugin более правильно, ведь также можно указать как удалённый сервер, так и локальный сокет.
2) А последний приведённый Jenkinsfile точно рабочий? Мне казалось, что если мы хотим указать agent в каком-то из stage, то мы должны в самом начале сделать agent none, или уже что-то изменилось?
3) Возможно сразу использованать docker-plugin более правильно, ведь также можно указать как удалённый сервер, так и локальный сокет.
- Официальный образ не содержит как минимум композа, если вам необходимо часть этапов выполнять вне сборочного контейнера. Но вы правильно заметили, что если вам внутренние утилиты не нужны, можно брать обычный образ и прокидывать сокет.
- Да рабочий. Вполне работает agent any в самом начале.
- Да, если у вас есть возмодность удаленных решений. Как я писал в самом низу, потом расскажу и про этот подход. Но если у вас в распоряжении 1 хост, то такой подход вполне себе спасает от описанных мною проблем.
2) Первое упоминание agent вне stage это агент по-умолчанию. Для тех stage, где он не укащан явно. Вместо any здесь так же глобально можно указать например docker-образ.
В stable helm чарте Jenkins для к8s есть динамически создаваемые агенты. Взгляните, очень полезная вещь. По моему даже на хабре описывали.
Хорошо, спасибо. Знаю что еще есть Jenkins X для куберенетиса.
apt-get update && \
apt-get -y install docker-ce && \
usermod -aG docker jenkins
RUN curl -L github.com/docker/compose/releases/download/1.25.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose
RUN apt-get clean autoclean && apt-get autoremove —yes && rm -rf /var/lib/{apt,dpkg,cache,log}/
анти-бест-практиз-докерфайл. обновляем список пакетов в одном слое, чистим за собой в слое через 1…
А вы не могли бы чуть подробнее описать, почему это плохо, и как было бы правильно?
Каждая инструкция создаёт новый слой на основе предыдущего. И если почистить /var/lib/{apt,dpkg,cache,log} не при установке пакетов (с помощью && после apt-get install), а в последующей инструкции, то образ от этого не станет меньше.
а это точно актуально?
github.com/rocker-org/rocker/issues/35
github.com/rocker-org/rocker/issues/35
docker run --rm debian:stretch cat /etc/apt/apt.conf.d/docker-clean
# Since for most Docker users, package installs happen in "docker build" steps,
# they essentially become individual layers due to the way Docker handles
# layering, especially using CoW filesystems. What this means for us is that
# the caches that APT keeps end up just wasting space in those layers, making
# our layers unnecessarily large (especially since we'll normally never use
# these caches again and will instead just "docker build" again and make a brand
# new image).
# Ideally, these would just be invoking "apt-get clean", but in our testing,
# that ended up being cyclic and we got stuck on APT's lock, so we get this fun
# creation that's essentially just "apt-get clean".
DPkg::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };
APT::Update::Post-Invoke { "rm -f /var/cache/apt/archives/*.deb /var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true"; };
Dir::Cache::pkgcache "";
Dir::Cache::srcpkgcache "";
Спасибо kruftik поправлю!
Зачем собирать изображение при сборке таски, если его можно залить в хаб?
И зачем DinD, если с мастера Дженкинса можно подключиться по SSH к сборочной ноде (ну или к своей же, если совсем туго с железом), и там уже запускать сборочные контейнеры shell-скриптом из пайплайна (лично мне кажется что так больше прозрачности в работе тасок)?
Зачем собирать изображение при сборке таски, если его можно залить в хаб?
Никто вам не мешает поступить так. Просто укажите в Jenkinsfile имя нужно вам образа. Я же просто показал такой пример. Вы сами вольны выбирать свой подход.
pipeline {
agent none
stages {
stage('Back-end') {
agent {
docker { image 'maven:3-alpine' }
}
steps {
sh 'mvn --version'
}
}
stage('Front-end') {
agent {
docker { image 'node:7-alpine' }
}
steps {
sh 'node --version'
}
}
}
}И зачем DinD, если с мастера Дженкинса можно подключиться по SSH к сборочной ноде (ну или к своей же, если совсем туго с железом), и там уже запускать сборочные контейнеры shell-скриптом из пайплайна (лично мне кажется что так больше прозрачности в работе тасок)?
Использование shell скриптов заставляет вас самих контролировать жизненный цикл сборки. А агент, после собрки позволяет потушить сборочный контейнер. Да вы можете все писать руками и при помощи баш скриптов, но тогда размер кода который вам необходимо поддерживать вырастет вразы.
Про SSH вам придется подключаться самим к себе, только смысла в этом нет. Лучше подключение использовать когда у вас > 1 машины, котоыре могут работать с Docker.
Вопросы от чайника:
- Зачем нужен докер агент? Можно просто выполнить команды докера скриптом?
- Как контролируется, что при создании контейнеров в них не будут примонтированы папки хоста? Папки вообще можно примонтировать при запуске sibling containers в докере, или всё должно быть упаковано в образ?
- Как контролируется выделение ресурсов контейнерам?
- Как контролируется, что все созданные контейнеры будут остановлены (и удалены, возможно, через какое-то время)?
- Как контролируется, что кэш образов и контейнеров докера не переполнит диски хоста?
Sign up to leave a comment.
Как собирать проекты в Jenkins, если нужно много разных окружений