Комментарии 16
В начале видео, где идёт уточнение терминологии, как раз говорится про различие между интуитивным обобщённым пониманием GitOps и конкретной имплементацией с pull-моделью и обязательным промежуточным репом. Данная имплементация использует докер-образы из registry и не отвечает за их корректную сборку и тегирование. Именно о такой имплементации идёт речь в видео. Вот ссылки на почитать, чтобы понять о чём идёт речь: https://blog.argoproj.io/introducing-argo-cd-declarative-continuous-delivery-for-kubernetes-da2a73a780cd, https://www.weave.works/technologies/gitops/.
Привет. Около 10 лет я всячески пытаюсь использовать и продвигать immutable-инфраструктуру. Из публичного, самое старое, что я сходу смог найти вот: https://youtu.be/mT5U862_ydU. Видео чуть глубже. Ну или, по крайней мере, я пытался сделать его чуть глубже.
Очень большое спасибо за критику подхода. Но как-то статья не выглядит законченной. На самом интересном месте все обрывается… и идет ссылка на свой инструмент werf.
Касательно GitOps — действительно проблемы есть, но они лежат вовсе не в порядке применения образа и манифеста. Но это нужно долго расписывать )
Ну, окей. Как простой пример — деплой должен быть сериализуемый и конкурентный (скорее наоборот). Теперь посмотрим как это реализуют эти концепции:
GitOps: если мы попытаемся выкатить несколько релизов подряд — применить тот, который будет в git репозитории на момент синхронизации с gitops-оператором. Это означает, что приложение должно быть написано особым образом, я бы сказал — self-contained, т.е. содержать в себе полный пакет миграций или переходов между всеми версиями. Возможно? Да. Накладывает ли это ограничения на то, как писать приложение? Несомненно. Может ли это вызывать проблемы? Опять же — очевидно — да.
CIOps: что будет если мы запустим деплой новой версии, не дождавшись окончания деплоя предыдущей версии? Такая ситуация вполне возможна, если у нас деплои идут очень часто. Да ничего хорошего — мы попросту получаем "гоночную" ситуацию и по сути тот деплой, который завершится позже — тот и применится. Так мы можем по факту остаться на более старой версии приложения, чем ожидали. Решение какое? Либо контролировать порядок деплоя ручным способом (ответственный человек нажимает кнопочки в панели гитлаба в нужном порядке и контролирует результат), либо встраивать какую-то систему блокировок (и/или очередей) — чтобы ГАРАНТИРОВАННО в конкретный момент времени шел максимум один деплой, а следующий запускался после успеха предыщего.
Еще оба подхода нам ничего не говорят о том, если у нас есть зависимости от других, внешних компонент, либо напротив — что-то зависит от нас. И тогда тем более может понадобится обеспечить порядок деплоев.
Означает ли это все, что ни один из подходов нельзя использовать? Конечно, нет. Просто нужно понимать ограничения и уметь с ними работать.
Детерминизм ✗ Состояние в Kubernetes целиком и полностью определяется тем, что написано в Git. Как я уже говорил, это неправда, потому что состояние зависит ещё от container registry. Если кто-то изменит состояние реестра, изменит образ в реестре… развалится практически всё. Подробности будут ниже.
Является ли это проблемой? Нет. Нужно аккуратно работать с registry, и по возможности — использовать концепцию immutable тегов. Тогда мы гарантируем однозначное соответствие и проблема будто решается.
Например, GitOps-оператор может заметить новый образ в container registry до того, как новые манифесты будут коммитнуты (и увидены им)
это так не работает. Либо вы включаете автодеплой и тогда GitOps оператор смотрит на образы и потом перезаписывает манифесты в git необходимым образом, либо вы отключаете слежение за версией образа в docker registry и изменения в манифестах становятся единственным источником правды.
Однако это не означает, что изменения были успешно применены в кластере. Поэтому нужно заглянуть в какую-то другую систему… И мы вынуждены делать это даже для того, чтобы проверить совсем простые вещи — например, чтобы убедиться, валидны ли новые манифесты.
тоже не является проблемой. Очевидно, что новая версия может сломаться как сразу (если она криво собрана, причем откровенно, либо не удовлетворены зависимости — но тогда вопрос, почему мы это на тесте не определили), либо спустя определенное время (например, новая версия более ресурсоемка, либо в ней утечка, либо что-то еще). На оба случая в любом случае НЕОБХОДИМ мониторинг. Да даже для ops нужен мониторинг. И в обоих случаях необходимо принятие решение — что мы делаем (ручное или автоматизированное).
Идеально для деплоя — сценарий запуска с progressive deploy или канарейкой. С откатом на прошлую версию. А такой сценарий деплоя априори асинхронный и замкнут на обратную связь от системы мониторинга.
Проблему запуска деплоя новой версии, когда не дождались окончания деплоя старой версии мы в werf решаем с помощью блокировки релиза по имени. В один момент времени выкатывается только один релиз с определённым именем, другой выкат будет дожидаться предыдущего (реализовано это с помощью распределённых блокировок через Kubernetes, деплой может быть запущен с любого хоста).
спасибо, хороший плюсик в сторону werf
блокировки релиза по имени
как реализуется снятие блокировки? Автоматом?
Клиент, который взял блокировку, обязан её периодически продлять. Другой клиент, который ждёт блокировки может заметить, что она уже давно не продлевалась (есть некоторый небольшой timeout) и перехватить её. Если первый клиент не смог продлить блокировку из-за сетевого глюка, то он в какой-то момент придёт продлевать блокировку, которую уже перехватили — он это заметит и включит "особый обработчик" данной ситуации, который в случае werf как можно быстрее crash-ит текущий процесс.
Сами блокировки оформлены в виде отдельного проекта: https://github.com/werf/lockgate.
Такой подход в lockgate не даёт 100% гарантию корректности для любого проекта, однако предоставляет возможность определить в своём проекте этот обработчик ситуации с перехватом блокировки. В случае werf аварийного завершения процесса в этой ситуации пока хватает, да и на практике кейс возникает очень редко.
Грубо говоря, если я решил начать писать пет-проект транслятора своего ЯП, нужен ли мне GitOps, Kubernetes и иже с ними?
Или если моя группа занимается числодробилкой на условном Фортране путём переписывания 20-летних сырцов под новую установку/модель?
Kubernetes для pet-проекта не звучит как что-то логичное. Вы столкнетесь с высокими затратами на внедрение (большой порог вхождения) и поддержку (всё это магически само не работает, если у вас, конечно, не какое-то платное managed-решение). Если просто хочется получить новые навыки, то это, конечно, совсем другой разговор… Но если речь именно про некую пользу для проекта, то: какие задачи вы вообще хотите решить? Я бы исходил из того, какие проблемы есть, что конкретно требуется улучшить, чего в конечном счете добиться. И уже из этого выбирать подходящие технологии и подходы, и только тогда можно оценивать адекватность затрат (финансовых/временных) на них.
Подробных исследований про трудозатраты на внедрение/обучение/…, думаю, ещё просто не существует.Это звучит странно. Описание любой технологии должно включать в себя описание решаемой проблемы и границу применимости (как принципиальную для данной технологии, так и относительно текущей среды). Иначе как компании определить, что ей нужны услуги условной Weaveworks?
какие задачи вы вообще хотите решить?Это и есть мой вопрос. Какие задачи технология предлагает решить и какая цена предлагаемого решения?
Давайте в качестве примера возьмём pet-проекты.
Если есть хотя бы маленькая вероятность того, что код надо будет откатывать к предыдущему состоянию, или параллельно рассматривать несколько независимо разрабатываемых версий, или что будет несколько разработчиков, то надо использовать систему контроля версий. Цена — 10ч на обучение (разово), труд на составление коммитов и отведённая память под репозиторий.
Если нужно через 2+ лет восстановить точное окружение, в котором собиралась и исполнялась программа, то имеет смысл использовать докер. Цена (по крайней мере, в прошлом) — привязка к Linux, 10ч на базовое обучение (разово) и 1ч на составление Docker-файла (разово на проект), труд по управлению контейнерами и незначительные накладные расходы на запуск контейнера.
Можете продолжить в так же для k8s и gitops?
Если нужно через 2+ лет восстановить точное окружение, в котором собиралась и исполнялась программа, то имеет смысл использовать докер.
добавлю. Это не так. Только если Вы не сохраните целевой докер-образ в репозитории и будете его хранить 2 года. Спустя 2 года собрать докер образ из исходного Dockerfile по вполне понятным причинам будет невозможно
Можете продолжить в так же для k8s и gitops?
можно....
добавлю. Это не так. Только если Вы не сохраните целевой докер-образ в репозитории и будете его хранить 2 года. Спустя 2 года собрать докер образ из исходного Dockerfile по вполне понятным причинам будет невозможноВы совершенно правы. Это важный момент, который следует упомянуть в разделе «цена». Иначе воспроизводимость превратиться в тыкву.
Большая половина рассказа строится на утверждении "Если по какой-либо причине мы соберем образ дважды (из одного и того же коммита), можно получить не только небольшие бинарные различия (потому что это два разных образа), но и два действительно разных образа (образы с разными содержимым). " Но я так и не понял почему это так? Почему две сборки подряд из одного коммита будут не идентичными?
Почему две сборки подряд из одного коммита будут не идентичными?
Например потому что мы никак не контролируем что происходит в сборочных инструкциях типа:
- apt-get update
- apt-get install some-solution
— и версия some-solution может быть разной.
И далее мы и не пытаемся контролировать эти инструкции, потому что это слишком глобальная и в реальности невыполнимая задача. Вместо этого мы идём с другой стороны: даём гарантию иммутабельности образов, собранных из коммита, гарантию атомарности при публикации этих образов, гарантию того, что из одного коммита будет выводится одно и то же имя опубликованного образа.
Именно таким путём идёт werf со своей распределённой сборкой и специальным тегированием.
Что же такое GitOps? Его свойства и недостатки