Комментарии 30
было бы интересно узнать, как мониторите докер и сколько хостов с приложением работают одновременно?
Со всеми «новыми» системами так и делаем с самого начала, а вот с существующими приходится всякие подпорки придумывать, и в них и тоска и боль и страдание, как верно подметил коллега выше.
А как вы решаете вопрос с откатом по бизнес-требованиям?
Предположим все тесты прошли, деплой прошел и все хорошо, но через пару часов выясняется, что что-то работает не так, как надо. Как в этом случае выполняется откат?
kruftik, спасибо за статью.
Про прод не очень понял — на проде вы тоже в докере крутите приложения, или там всё-таки используется виртуализация\bare metal?
Для своей компании никак не можем разрешить дилемму для нового проекта — т.к. у нас окружение приложения будет меняться крайне редко (в основном, security фиксы), есть ли смысл использовать докер вообще.
В процессе чтения возник вопрос.
А почему не было рассмотрено решение а-ля GIT + CI\CD + Task Manager в лице Gitlab?
На своей работе я полностью ушел из Jenkins, который костыльным образом запускал проект, в сторону Gitlab и, в итоге, развернул систему, которая в режиме CI\CD делает сборку проекта сразу на 2 ОС (требования руководства) удаленно (то есть проект сразу разворачивается на нужных машинах): Windows и Linux.
Любые изменения фиксируются в Task manager'е, чтобы можно было оперативно посмотреть изменения по задаче, которые были внесены.
Огромный плюс Jenkins-а — наличие плагинов для любой кофеварки и достаточно посильный для многих Java-стэк разработчиков процесс написания собственных расширений.
В привязке к ОС и ее средствам (все нужные и удобные инструменты писал путем батников и shell скриптов) через gitlab runner.
Вопрос был нацелен на попытку понять причину выбора между Jenkins и Gitlab в сторону Jenkins. При этом большинство авторов, которые выбрали Jenkins, описывают много проблем, связанных именно с Jenkins.
Большинство тех проблем, которые они встречают, я не встретил в Gitlab.
Поэтому было интересно узнать причину.
И спасибо =)
Тем не менее, никто еще не ставил точки в вопросе выбора решения для подобных задач и GitLab в них не последний кандидат.
То есть запустили nodejs фронт, как nginx догадается что нужно проксировать по эндпоинту на нужный nodejs фронт?
Технически реализовал с помощью GitLab CI, Kubernetes и Helm. В исходниках лежит helm chart для разворачивания всей системы. При пуше изменений в ветку создается k8s namespace, если он еще не был создан. И потом происходит установка/обновление helm release. При удалении ветки и namespace и release удаляются.
В итоге команде стало очень удобно тестировать разрабатываемый функционал. Пишешь код, пушишь в ветку, ждешь 5 минут и можешь пользоваться приложением на окружении.
Простите, а как связаны бизнес и снижение Т2М с развертыванием на тестовую среду?
Бизнесу пока от вашего CI ни жарко, ни холодно. Продукт еще до пользователя надо довести, не только до разработчика (и возможно до тестировщика)
всего даже вовсе действует обратным образом.
В конкретном случае, проект предназначен для внутренних пользователей, которых обслуживает очень похожий пайплайн, которые просто заточен на автоматический запуск контейнеров по определнной метке, которые, в свою очередь, возникают при появлении новых тегов в гит-е.
:) Тогда зачем вы этот самый бизнес упомянули в самом начале? Потому что это начало пути к снижению т2м и бизнес смотрит на демонстрацию возможностей продукта на тестовом окружении?
Действительно, наверное, стоило явно отметить, что под словом «бизнес» подразумевались любые подразделения, которые могут быть заказчиком продукта, в том числе и предназначенного для внутреннего пользователя, а не только явно приносящих прибыль непосредственно.
Понятно. Спасибо за разъяснения
Я просто после фразы про бизнес почему-то ждал, что дело дойдет до промышленной эксплуатации. Ну или хотя бы внутренней промышленной эксплуатации.
Для меня тестовая среда — это песочница для демонстрации или тестирования с тестовыми данными. А внутренние пользователи сидят на своем внутреннем проме. Или вы накатываете на внутренний пром?
stage('Заливаем его в Artifactory') {
docker.withRegistry("https://repo.artifactory.bank", "LoginToArtifactory") {
sh "docker service update --image repo.artifactory.bank/dev-backend:${env.BUILD_ID} SMB_dev-backend"
}
}
Вот это не понял. По-моему, текст комментария не соответствует коду, т.к. фактически образ был добавлен в удаленный registry (т.е. artifactory) на предыдущем шаге.
rm /etc/zypp/repos.d/* || exit 0
— то это самый простой способ удалить ВСЕ имеющиеся в системе репозитории. он вполне удобен, особенно с учетом не требующейся здесь «идемпотентности».
использование же вызовов команд docker и docker-compose через модуль shell обусловлен тем, что все docker-специфичные штуки в ansible требуют установленного на целевых хостах питонячего модуля docker-py, который требует или установки пакета с ним или установки pip для того, чтобы его самого установить, а также часто конфликтует по версии с самими пакетами docker/docker-compose.
Последнее, к слову, на мой взгляд вполне «удовлетворительно для использования». При использовании docker-compose идемпотентность вызовов обеспечивается им самим.
CI/CD-пайплайн на примере одного небольшого проекта Уральской Дирекции ИТ