sysadmins №44. GitOps: За и Против

• Роман Козлов и Олег Вознесенский обсуждают концепцию GITOps и ее недостатки.  

• Роман рассказывает о своем опыте работы с GITOps и его недостатках.  

• Роман объясняет, как управление конфигурацией и инфраструктурой развивалось от ручных операций до использования систем управления конфигурациями.  

• Он обсуждает проблемы, связанные с конфигурацией дрифтом и спиралью страха автоматизации.  

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

• Он призывает слушателей поделиться своим опытом работы с GITOps в чате.  

• В видео обсуждается развитие систем управления конфигурациями, включая их переход от "конфигурации как кота" к "инфраструктуре как коту".  

• Упоминается тест Лимончелли, который до сих пор актуален для проверки знаний системных администраторов.  

• Рассматривается переход от виртуализации к облакам, который привел к изменению подхода к управлению конфигурациями.  

• Обсуждается переход от "питомцев" к "стадам" в управлении конфигурациями, который связан с развитием виртуализации и облаков.  

• Упоминаются различные названия серверов, такие как "коровки" и "бычки", которые связаны с этим переходом.  

• Рассматривается развитие систем управления конфигурациями, включая различные волны и инструменты, такие как SafeEngine, Puppet и Chef.  

• Обсуждается переход от "запеченной" конфигурации к "прожженной", связанный с развитием виртуализации и облаков.  

• Упоминается, что администрирование Windows может быть "унизительным" из-за низкого порога входа и большого количества страниц документации.  

• Обсуждается, что Linux, с другой стороны, является "раздолбайской" системой, где все открыто и легко для понимания.  

• Компания Аутворкс предлагает концепцию "феникс серверов", где серверы постоянно переустанавливаются с нуля, используя манифесты системы управления конфигурациями.  

• Это попытка убрать проблему конфигурационного дрифта, когда изменения в конфигурации сервера могут привести к ошибкам.  

• Двенадцать факторов - методология, которая помогает адаптировать код к работе в облачной инфраструктуре.  

• Это включает в себя адаптацию кода к контейнерам, двенадцатифакторным приложениям и концепции "золотого имиджа".  

• Непродуктовые компании также могут использовать принципы и мюта инфрастрак для организации своей инфраструктуры и автоматизации действий.  

• Обновление конфигураций может привести к проблемам в сети, когда все, что есть на сервере, может быть отключено.  

• Для решения этой проблемы используются автоматизированные пайплайны доставки и подход "си".  

• Вводится понятие Continuous Delivery в дисциплине экстремального программирования.  

• Концепция заключается в том, чтобы интегрировать изменения в проект как можно чаще.  

• Это позволяет убедиться, что система работает нормально и готова к диплою на продакшн.  

• Continuous Delivery Pipeline может включать в себя различные инваменты, такие как предварительные тесты, сборка имиджа, дипло в стейшн-вайрменты, динамические тесты безопасности, приемочные тесты и интеграционные тесты.  

• Голден имидж - это образ, который собирается на начальном этапе и проходит через все инваменты для проверки воспроизводимости изменений.  

• Обновление образов может быть проблемой из-за разных доменов и рантаймов в разных окружениях.  

• Для решения этой проблемы предлагается использовать подход трак бейс девелопмент, где каждый комит, смешанный в мастер, выкатывается на продакшн.  

• Проблема конфигурационного дрифта также остается актуальной, и индустрия ждет концепцию, которая позволит отладить дипло и убрать эту проблему.  

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

• Упоминается, что для управления конфигурацией в Kubernetes используется множество инструментов, таких как Kube, Helm, HashiCorp Vault и другие.  

• В видео демонстрируется пример использования Helm в Kubernetes для управления конфигурацией.  

• Обсуждаются способы версионирования и передачи переменных в Helm чарты.  

• В видео обсуждается использование GitOps в Kubernetes, включая процесс непрерывной интеграции и доставки.  

• GitOps описывается как процесс, который описывает, как происходит релиз, и добавляет шаги при условии, что все тесты прошли успешно.  

• Гитопс - это подход к управлению конфигурацией, который использует Git как основной источник правды.  

• Конфигурация хранится в Git и изменяется только через Git.  

• Гитопс использует императивные конфигурации, которые описывают процесс, который должен произойти до получения конечного состояния системы.  

• Гитопс позволяет версионировать и хранить различные версии конфигурации.  

• Гид позволяет хранить секреты и обеспечивает безопасность, позволяя только определенным пользователям читать и изменять секреты.  

• Гитопс использует подход "пул", когда изменения конфигурации происходят внутри кластера или агента.  

• Это позволяет избежать выдачи секретов и доступа к сторонним компонентам.  

• Подход "ст-шестьдесят девять" - это когда клиентское устройство периодически выкачивает изменения из центрального репозитория.  

• Гитопс и Сяопс - два разных подхода к управлению конфигурациями и изменениями в кластерах.  

• Гитопс использует Git для хранения конфигурации, а Сяопс - нет.  

• Гитопс использует механизм реконсал для проверки актуальности конфигурации и приведения системы в актуальное состояние.  

• Реконсал - это механизм, который периодически проверяет изменения в конфигурации и приводит систему в актуальное состояние.  

• Если кто-то вручную изменил конфигурацию, гитопс инструмент приведет систему обратно к первоначальному состоянию.  

• Флюкс использует три-веймердж для применения конфигурации и отслеживает дрифт.  

• Флюкс также использует механизм реконсал для отслеживания изменений в конфигурации.  

• Человеческий фактор является основной причиной ошибок в процессе управления конфигурациями.  

• Гитопс подход стремится минимизировать точки соприкосновения, где люди могут что-то изменить вручную.  

• Автор обсуждает флаг сиди и арго сиди, отмечая, что арго сиди имеет большую команду разработчиков и более активно развивается.  

• Он также упоминает, что флаг сиди полностью открыт и не имеет коммерческой составляющей.  

• Автор демонстрирует установку и настройку флаг сиди, используя гидропозитории для управления приложениями.  

• Он также объясняет, как использовать гидропозитории для обновления приложений и как флаг сиди следит за актуальностью конфигурации.  

• Автор демонстрирует удаление и реконсал приложения, используя подход гетопс.  

• Он объясняет, что если что-то удаляется вручную, то флаг сиди все равно попытается привести кластер в актуальное состояние.  

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

• Обсуждение устойчивости инфраструктуры и возможных проблем, таких как поломка гидропозиторий или флюкс.  

• Обсуждение разделения между декларативным и императивным языками, где декларативные языки описывают желаемое состояние системы, а императивные языки выполняют конкретные действия для достижения этого состояния.  

• Обсуждение использования декларативных языков, таких как Kubernetes, и императивных языков, таких как Go, Python, Ruby, Java, для реализации операторов.  

• Обсуждение проблем, которые могут возникнуть при использовании императивных языков для определения конфигурации, таких как неправильное написание алгоритмов или внесение неправильных значений в переменные.  

• Обсуждение примеров из практики, когда неправильная конфигурация привела к созданию большого количества экземпляров приложения и затратам на оборудование.  

• Гитопс - это подход к разработке, который может быть внедрен в маленьких компаниях для унификации процессов и повышения эффективности.  

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

• Гитопс может быть полезен для веб-студий, где важно унифицировать процессы и избежать проблем с переходом между проектами.  

• Гитопс может увеличить сложность процессов доставки, но это общая проблема для всех подходов к разработке.  

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

• Для работы с гитопсом необходимы инструменты, такие как Helm, кастомные инструменты валидации и Kubernetes.  

• Важно изучить Continious Integration для работы с гитопсом, так как без него он не будет работать.  

• Важность правильной организации процессов и понимания культуры DevOps.  

• Изучение инструментов и практики без теории мертва.  

• Работа с лучшими и обучение у них.  

• Для небольшого проекта достаточно одного DevOps инженера.  

• Повышение квалификации разработчиков для возможности перехода в DevOps.  

• Разделение ответственности между DevOps и разработчиками.  

• Легаси проекты часто требуют переписать код или изменить конфигурацию.  

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

• Индустрия движется по пути создания и углубления абстракций.  

• DevOps помогает создавать высокоуровневые языки и системы расширений.  

• Совет для молодых инженеров: смотреть на DevOps с точки зрения обучения и применения к себе.  

• Олег рекомендует подписаться на группу "DevOps Jobs" и следить за актуальными вакансиями.  

• Он также упоминает ресурс "Rod Map", который помогает отслеживать требования и инструменты для инженеров DevOps.  

• Олег рекомендует читать базовые теории, такие как работы Мартина Фаулера и Река Эванса, для понимания направления DevOps.  

• Он также предлагает пройти бесплатные курсы, чтобы получить первоначальное понимание и точку входа в DevOps.  

• Олег подчеркивает, что взрослые люди могут учиться только тогда, когда понимают полезность обучения.  

• Он также отмечает, что для обучения взрослых требуется много воли и мотивации.  

• В заключение, Олег просит зрителей придумать имя для своего друга, который любит лазить в продакшн, и предлагает назвать его "Дрифт".