#&it #kubernetes #continuous-inte&ration #continuous-deployment
#&it #kubernetes #непрерывная интеграция #непрерывное развертывание
Вопрос:
В обычном процессе kubernetes CI / CD происходит следующий процесс :
- клонировать код из &it
- создайте и отправьте образ docker
- обновите развертывание kubernetes с помощью обновленного кода
Согласно определению &itops
GitOps — это новый подход к непрерывному развертыванию, который использует Git как единый источник достоверности для декларативной инфраструктуры и приложений, обеспечивая как доработку, так и контроль изменений. С помощью GitOps система запускается путем отправки запросов на извлечение (и последующих слияний) для достижения желаемого состояния системы, представленной в репозитории Git
насколько я понимаю &itops, когда вы обновляете что-либо в &it (поскольку это источник истины), желаемое состояние kubernetes меняется на последнее и развертывается последний код.
Конечный результат традиционного CI / CD без &itops: новый код развертывается как развертывание kubernetes
Конечный результат &itops: новый код развертывается как развертывание kubernetes
Я не могу понять разницу. извините, если это звучит для вас странно. Но я вроде как новичок и изучаю &itops .
Заранее спасибо за ваш ответ
Комментарии:
1. GitOps в контексте k8s обычно предполагает, что вы используете специализированный инструмент GitOps, такой как Ar&oCD или Flux, смотрите Мою статью о рабочей реализации игрушечного проекта: itnext.io /…
2. @taleodor то есть вы хотите сказать, что простое использование инструмента &itops превращает CI CD в &itops?
3. Близко к этому. Более конкретно, GitOps предполагает реагирование на изменения в вашем репозитории практически в реальном времени. Таким образом, вы устраняете разрыв между состоянием вашего репозитория и состоянием ваших сред. Этого трудно достичь без специализированных инструментов.
Ответ №1:
GitOps — это не что иное, как распространение принципов CI / CD за пределы кода приложения: на внутренний код. Просто. Вы можете подумать об использовании Git как источника истины, который сочетается с Terraform (подготовка), Ansible (настройка m&mt) и Kubernetes (оркестровка) в качестве примера … для достижения цели сохранения Git как отражения вашей инфраструктуры в соотношении 1: 1. В этом нет ничего нового, и не беспокойтесь о таких причудливых терминах…
Комментарии:
1. Подробнее читайте здесь about.&itlab.com/topics/&itops
Ответ №2:
CICD фокусируется на всей цепочке:
- Вы проверяете свой код
- Код проходит тестирование
- Контейнер создан и загружен
- Контейнер будет развернут
- Контейнер проходит тестирование
Плюс множество других промежуточных шагов. Вот почему это непрерывная интеграция и развертывание. Можно также сказать, сквозной процесс.
GitOps не заботятся о вашем коде, сборке docker или около того. Он ориентирован исключительно на обновление ваших приложений (часть развертывания) в экстремальной форме с прогрессивной доставкой, полностью автоматизированной с переключением трафика и проверками работоспособности, автоматическим возвратом и т.д.
Помимо этого у вас есть другие мелкие детали, которые иногда имеют значение, такие как push vs pull, автономия кластера, разделение задач.
Комментарии:
1. но как приложение будет обновляться? как только код обновляется … верно? итак, в конечном итоге вам нужно создать docker для обновления приложения
2. у вас может быть два триггера для обновления, например, информация о развертывании или изменение конфигурации, или у вас есть обновление контейнера. Flux или Ar&oCD могут реагировать на оба, в основном в комбинации, и выполнять непрерывное обновление.
Ответ №3:
Краткий ответ — GitOps — это фреймворк, CI / CD — это процесс!
GitOps стремится использовать Git как источник истины и дает разработчикам возможность выполнять операции с НИМ. Это автоматизирует рабочий процесс Git с помощью непрерывной интеграции и непрерывной доставки (CI / CD). Позвольте мне привести здесь пример — у меня есть кластер kubernetes, для автоматизации которого у меня настроены конвейеры CI / CD, но мы привыкли видеть инциденты, когда кто-то вручную вносил изменения в версию приложения непосредственно в кластере (происходит везде!). Мы использовали GitOps для создания объявления моего кластера, чтобы каждый раз, когда кто-то вносил изменения вручную, оно переопределяло и возвращало его к исходному состоянию, объявленному в Git (делается с помощью агента GitOps, такого как Flux).