Комментарии 13
Круто!!! Спасибо автору️
Очень интересно написано
Скорее за перевод, но все равно спасибо...
Как-то читаешь и ощущение, что фичи по развёртыванию пилятся в основном в расчёте на Кубер, да не один кластер. Грустно, когда других причин поднимать кластер нет, потому что очень дорого поддерживать.
Они на половину завязаны на gke (в плане дел, имхо их чутка спроспонсировали), +200$ дают на это (или около того). Там можно держать кластер из 1 прерываемой ноды.
VolCh, спасибо за отзыв!
Я работаю архитектором решений в GitLab и, наверное, соглашусь с вами: огромная часть функционала по развертывания завязана на K8s. Мы это прекрасно осознаем понимаем и пытаемся добавлять возможности развертывания без Кубера
В качестве примера можете посмотреть на недавно развиваемую инициативу "5 Minute Production App": https://about.gitlab.com/blog/2020/12/15/first-code-to-ci-cd-deployments-in-5-minutes/ (к сожалению, на английском) целью которой создать простой и легкий механизм выката в production за кратчайший срок (без использования K8s). Фокус начальной итерации стало развертывание приложений в AWS, но в будущем планируем дорабатывать и добавлять другие облачные (и не только) таргеты.
Если есть возможность, поделитесь каких возможностей в плане развертывания хотелось бы увидеть вам?
Ого! )
Вот как раз необлачные, классические таргеты интересуют, но с контейнерами желательно. Причём c моделью несколько приложений/сервисов на одном хосте. С поддержкой блю/грин какой-то на уровне, например, конфигов nginx или haproxy. Вернее с возможностью фиксировть что приложение/сервис такой-то ревизии такой-то успешно залито на сервер такой-то в blue "половину" (или на блю-сервер) и сервер уже её обслуживает. Или создавать динамически окружения под фиче-ветку на базе технологий типа виртуальных хостов в веб-серверах. Проблема не создать даже, проблема как-то иметь информацию внутри CI/CD где что развёрнуто в таких сценариях. Как на дашбордах, так и внутри пайплайнов.
С кубером когда работал было хорошо в этом плане. Не идеально, но хорошо ), сейчас на проекте физическое и виртуальное железо в режиме "напихано всё что влезло и немного больше" и очень не хватает такой информации.
Если подробнее интересны кейсы, то могу расписать на выходных.
Спасибо!
Примерно понял так:
Хочется иметь возможность получить информацию, на каких хостах (физические / виртуальные) был произведено развертывание. (а также обратное: посмотреть какие именно деплойменты запущены на ресурсе)
Если сможете поделиться конкретными кейсами и сценарии, то это поможет формулировке feature request для продуктовой команды. Спасибо большое!
Вышел релиз GitLab 13.7 с проверяющими для мерж-реквестов и автоматическим откатом при сбое