без кубера? У меня сейчас настроены gitlab runners на железе, systemd итд.
Непонятно: если поднять container registry, runner-ы будут собирать контейнеры, выкладывать в container registry. А дальше? по крону на воркерах апдейты делать? Как-то криво выглядит.
В теории можно обойтись без container registry, чтобы runner-ы собирали контейнеры и по сети кидали на воркеров. Со скоростью апдейтов нормально, в остальном ещё кривее выглядит.
работать будет любой из вариантов, но хотелось бы по лучшим практикам ,а не колхоз городить )
Докер - это просто инструмент среди прочих. Удобно его юзать отдельно от оркестрации - юзай. Всё зависит от поставленных задач. Все перечисленные варианты применимы в тех или иных условиях.
дык, именно что выглядит неудобно ) поэтому и спрашиваю.
если только docker-compose или аналоги... а то сильно заморочено выглядит
Вначале про CI, в конце про оркесирацию. Непонятно вопрос про CI или оркесирацию контейнеров? Для CI голый докер удобен. Сборка в изолированном окружении, поднять зависимости для прогона тестов и т.д. Для оркесирации голый докер не удобен, потому что оркестратор надо самому писать
Ты смешиваешь сборку артефактов и их деплой. Как ты из собираешься выкатывать - это, вообще, не головная боль CI. Люди обычно используют CI для того, чтобы запускать джобы деплоя, то этот процесс в целом сильно зависит от используемых технологий.
Ну и докер на CI-раннерах никак не зависит от того, как у тебя запускается workload на worker-ах. У тебя может быть сборка rpm-пакетов в CI в docker-контейнерах, а выкатка через установку этих пакетов ansible-ом на железки. А может быть сборка на раннерах на голом железе контейнерных образов c helm-чартами, а выкатка их в кубер.
и как правильно? ещё jenkins какой-нибудь взгромоздить между CI и воркерами?
Зачем? Обычно в CI раннерах исполняется код, деплоящий артефакты из хранилища на воркеры.
Обсуждают сегодня