Pull to refresh

Comments 30

Спасибо за статью!
было бы интересно узнать, как мониторите докер и сколько хостов с приложением работают одновременно?
в конкретно описываемом случае наиболее важной задачей была возможность ведения активной разработки и демонстрации актуального состояния системы бизнес-заказчикам при условии, что наша система взаимодействует с реальными базами и различными штуками в банке, поэтому развернуто приложение было на одном хосте, но в нескольких экземплярах (гит-мастер, тест, прелайв и тп)
Энтерпрайз+докер+мониторинг — это такое комбо, которое тянет как минимум на отдельную развернутую статью полную боли и страданий.
Работаю непосредственно с таким комбо, поэтому интересуют подходы именно к мониторингу, может у кого то есть лучше практики, чем я использую :)
Моя и всех моих коллег светлая мечта постепенно прийти к решению, когда каждый сервис отдает некую health-check ручку, а система оркестрации за нее регулярно дергает.

Со всеми «новыми» системами так и делаем с самого начала, а вот с существующими приходится всякие подпорки придумывать, и в них и тоска и боль и страдание, как верно подметил коллега выше.

А как вы решаете вопрос с откатом по бизнес-требованиям?


Предположим все тесты прошли, деплой прошел и все хорошо, но через пару часов выясняется, что что-то работает не так, как надо. Как в этом случае выполняется откат?

Думаю, для отката должны быть припасены Git ветка productRelease с кодом ПО предыдущей версии, сборки обкатанных образов Docker в Artifactory, прочие необходимые настройки и артефакты и отдельный pipeline в Jenkins, который это развернет. В нашем проекте схема такая.

kruftik, спасибо за статью.
Все почти так, за исключением того, что когда образ уже испечен, что там творится в гит-е уже не принципиально :)
В случае контейнерезированных приложений такие штуки решаются совершенно просто — каждая выкатываемая версия — это тег докер-образа с номером версии + тег latest. Если надо откатиться, мы просто запускаем контейнер из образа с тегом -1 от текущей и все.
Классный гайд, спасибо.
Про прод не очень понял — на проде вы тоже в докере крутите приложения, или там всё-таки используется виртуализация\bare metal?
Для своей компании никак не можем разрешить дилемму для нового проекта — т.к. у нас окружение приложения будет меняться крайне редко (в основном, security фиксы), есть ли смысл использовать докер вообще.
Да, все в докере, а сами контейнеры уже по разному бывает, где-то на голом железе, где-то в виртуалках.
Мы уже какое-то количество лет весь новый софт и извне и разработанный внутри стараемся запускать в контейнерах, так всем проще. Исключения, конечно, случаются.
Спасибо за статью!
В процессе чтения возник вопрос.
А почему не было рассмотрено решение а-ля GIT + CI\CD + Task Manager в лице Gitlab?
На своей работе я полностью ушел из Jenkins, который костыльным образом запускал проект, в сторону Gitlab и, в итоге, развернул систему, которая в режиме CI\CD делает сборку проекта сразу на 2 ОС (требования руководства) удаленно (то есть проект сразу разворачивается на нужных машинах): Windows и Linux.
Любые изменения фиксируются в Task manager'е, чтобы можно было оперативно посмотреть изменения по задаче, которые были внесены.
Мы сейчас пилотируем разные интегрированные решения, с более дружелюбным интерфейсом, чем старик Jenkins, в том числе и гитлаб, но пока, к сожалению, золотого грааля отыскать не удалось :-(
Огромный плюс Jenkins-а — наличие плагинов для любой кофеварки и достаточно посильный для многих Java-стэк разработчиков процесс написания собственных расширений.
Мне как раз для разных кофеварок и помогла специфика Gitlab в виде описания сценариев.
В привязке к ОС и ее средствам (все нужные и удобные инструменты писал путем батников и shell скриптов) через gitlab runner.
Вопрос был нацелен на попытку понять причину выбора между Jenkins и Gitlab в сторону Jenkins. При этом большинство авторов, которые выбрали Jenkins, описывают много проблем, связанных именно с Jenkins.
Большинство тех проблем, которые они встречают, я не встретил в Gitlab.
Поэтому было интересно узнать причину.
И спасибо =)
GitLab хорош и часто даже весьма прекрасен своей высокой степенью интеграции и функциональности во том числе и бесплатной редакции при условии, что все серые будни кода протекают внутри него (гит-репозиторий, код-ревью, ci/cd-сервер, etc). Если же какие-то части этой инфраструктуры живут отдельно, то в значительная часть функциональности в бесплатной редакции перестает быть доступной, а его платные редакции кажутся очень-очень платными.

Тем не менее, никто еще не ставил точки в вопросе выбора решения для подобных задач и GitLab в них не последний кандидат.
Me1ram,

юзаете классический jenkins или jenkins blue ocean.

— в данном проекте используем обычный интерфейс

Если я правильно понял у вас докер репозиторий внутрий Артифактори?

да, все верно
Эндпоинты в nginx к nodejs фронтовым приложениям создаете руками?
То есть запустили nodejs фронт, как nginx догадается что нужно проксировать по эндпоинту на нужный nodejs фронт?
В данном проекте фронт-сервисов мало, поэтому просто руками дописываем, а близком по духу проекте по соседству используется схема, в которой используется docker-gen и прочие подобные штуки, когда вешается слушатель на события докера о появлении или смерти сервисов с определенными метками, генерирующий конфиг nginx-а.
Еще полезная вещь — динамическое развертывание окружений из feature branches. То есть кто-то создал ветку, пушнул её в репозиторий и CI/CD автоматически развернул систему из этой ветки. Я сделал такое решение на основе GitLab Review Apps. Адресация происходит по поддомену с именем ветки. К примеру, если пушится ветка с названием new-cool-feature, приложение разворачивается по адресу new-cool-feature.example.com. Эта ссылка автоматически указывается в описании пул-реквеста. То есть, кроме ревью кода можно также производить ревью непосредственно работающего приложения. После удаления ветки окружение полностью удаляется.

Технически реализовал с помощью GitLab CI, Kubernetes и Helm. В исходниках лежит helm chart для разворачивания всей системы. При пуше изменений в ветку создается k8s namespace, если он еще не был создан. И потом происходит установка/обновление helm release. При удалении ветки и namespace и release удаляются.

В итоге команде стало очень удобно тестировать разрабатываемый функционал. Пишешь код, пушишь в ветку, ждешь 5 минут и можешь пользоваться приложением на окружении.
да, элегантная и красивая схема, тоже думаем прийти к ней в скором времени, смотрим на разные варианты, думаем. Единственное, что всегда нужно думать о количестве разрабатываемых параллельно фич, а то сервера(ов) для запуска всех фича-бранчей может и не хватить, особенно если приложения достаточно монолитные и массивные :)
Да, эта схема требует больше ресурсов. Каждый пуш в origin ведёт к запуску всего пайплайна, сборке образов, прогону тестов (если есть), обновлению приложения на окружении. Но железо/виртуалки сейчас недорогие, зачастую ради удобства процесса проще их докупить. Ну и схема с kubernetes хороша тем, что если веток станет слишком много, то просто добавляем узлов в кластер и всё, ничего больше донастраивать не надо. Kubernetes сам позаботиться от том, чтобы распределить контейнеры по узлам.

Простите, а как связаны бизнес и снижение Т2М с развертыванием на тестовую среду?
Бизнесу пока от вашего CI ни жарко, ни холодно. Продукт еще до пользователя надо довести, не только до разработчика (и возможно до тестировщика)

Совершенно верное замечание. В ответ на которое хотелось бы подчеркнуть, что процесс, при котором каждое изменение требует ручной выкатки на тестовую (ые) среду или хотя бы какого-бы то ни было участия гуманоидов, совершенно точно не сокращает пресловутый т2м, а скорее
всего даже вовсе действует обратным образом.

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

:) Тогда зачем вы этот самый бизнес упомянули в самом начале? Потому что это начало пути к снижению т2м и бизнес смотрит на демонстрацию возможностей продукта на тестовом окружении?

Нет, все дело в том, бывают не только внешние юзеры, но и внутренние и стараться понижать т2м для последних тоже необходимо, поскольку их customer satisfaction, хотя и не напрямую, но оказывает сильное влияние на бизнес-показали компании.

Действительно, наверное, стоило явно отметить, что под словом «бизнес» подразумевались любые подразделения, которые могут быть заказчиком продукта, в том числе и предназначенного для внутреннего пользователя, а не только явно приносящих прибыль непосредственно.

Понятно. Спасибо за разъяснения
Я просто после фразы про бизнес почему-то ждал, что дело дойдет до промышленной эксплуатации. Ну или хотя бы внутренней промышленной эксплуатации.
Для меня тестовая среда — это песочница для демонстрации или тестирования с тестовыми данными. А внутренние пользователи сидят на своем внутреннем проме. Или вы накатываете на внутренний пром?

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) на предыдущем шаге.
Шел 2018 год. Все также люди вместо ансибла делали башсибл. Зачем там столько shell? Это ж страшно!
Шел 2018-й год, а мы все используем наработки 30-летней и более давности (тому же Линукс уже 25 лет). И как-то живем…
что касается команд типа:
rm /etc/zypp/repos.d/* || exit 0

— то это самый простой способ удалить ВСЕ имеющиеся в системе репозитории. он вполне удобен, особенно с учетом не требующейся здесь «идемпотентности».

использование же вызовов команд docker и docker-compose через модуль shell обусловлен тем, что все docker-специфичные штуки в ansible требуют установленного на целевых хостах питонячего модуля docker-py, который требует или установки пакета с ним или установки pip для того, чтобы его самого установить, а также часто конфликтует по версии с самими пакетами docker/docker-compose.

Последнее, к слову, на мой взгляд вполне «удовлетворительно для использования». При использовании docker-compose идемпотентность вызовов обеспечивается им самим.
Sign up to leave a comment.