Русский
Русский
English
Статистика
Реклама

Packer

Путь разработчика в SRE зачем идти в инфраструктуру и что из этого выйдет

30.06.2020 20:09:15 | Автор: admin
Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.




В Додо Пицце больше 600 пиццерий в 13 странах мира, а большая часть процессов в пиццериях управляется с помощью информационной системы Dodo IS, которую мы сами пишем и поддерживаем. Поэтому надёжность и стабильность системы важны для выживания.

Сейчас стабильность и надёжность информационной системы в компании поддерживает команда SRE (Site Reliability Engineering), но так было не всегда.

Предыстория: параллельные миры разработчиков и инфраструктуры


Много лет я развивался как типичный fullstack-разработчик (и немного scrum-мастер), учился писать хороший код, применял практики из Extreme Programming и старательно уменьшал количество WTF в проектах, к которым прикасался. Но чем больше появлялось опыта в разработке ПО, тем больше я осознавал важность надёжных систем мониторинга и трейсинга приложений, качественных логов, тотального автоматического тестирования и механизмов, обеспечивающих высокую надёжность сервисов. И всё чаще стал заглядывать через забор к команде инфраструктуры.

Чем лучше я понимал, в какой среде работает мой код, тем сильнее удивлялся: автоматические тесты на всё и вся, CI, частые релизы, безопасный рефакторинг и коллективное владение кодом в мире софта уже давно обыденны и привычны. При этом в мире инфраструктуры до сих пор нормально отсутствие автоматических тестов, внесение изменений в продакшн системы в полуручном режиме, а документация часто есть только в головах отдельных людей, но не в коде.

Этот культурный и технологический разрыв вызывает не только недоумение, но и проблемы: на стыке разработки, инфраструктуры и бизнеса. С частью проблем в инфраструктуре сложно бороться из-за близости к железу и относительно слабо развитых инструментов. Но остальное вполне можно победить, если начать смотреть на все свои Ansible-плейбуки и Bash-скрипты как на полноценный программный продукт и применять к ним те же требования.

Бермудский треугольник проблем


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

Проблемы разработчиков


Два года назад мы поняли, что большая сеть пиццерий не может жить без собственного мобильного приложения и решили его написать:

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



Косяков на старте было, конечно, много, но больше всего мне запомнился один. На время разработки на продакшене был развёрнут один слабый сервер, почти калькулятор, который обрабатывал запросы с приложения. Перед публичным анонсом приложения его нужно было увеличить мы живем в Azure, и это решалось нажатием одной кнопки.

Но эту кнопку никто не нажал: команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение. Они решили, что следить за продакшеном некритичного сервиса обязанность команды приложения. А разработчик бэкенда (это был его первый проект в Додо) решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.

Тем разработчиком был я. Тогда я вывел для себя очевидное, но важное правило:
Если хочешь, чтобы твоё приложение жило долго и счастливо, внимательно следи за тем, где и как оно выполняется на проде. Даже если для этого есть специально обученные люди.

Сейчас это не сложно. В последние годы появилось огромное количество инструментов, которые позволяют программистам заглянуть в мир эксплуатации и ничего не сломать: Prometheus, Zipkin, Jaeger, ELK стек, Kusto.

Тем не менее у многих разработчиков до сих пор есть серьёзные проблемы с теми, кого называют инфраструктурой/DevOpsами/SRE. В итоге программисты:

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

Проектируют свои системы в отрыве от реальности и не учитывают, где и как будет выполняться их код. Например, архитектура и дизайн системы, которая разрабатывается для жизни в облаке, будет отличаться от дизайна системы, которая хостится on-premise.

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

Не могут оптимизировать деньги и другие ресурсы компании, которые используются для поддержания их кода. По нашему опыту бывает так, что команда инфраструктуры просто заливает проблему деньгами, например, увеличивая размер сервера БД на продакшене. Поэтому часто проблемы кода даже не доходят до программистов. Просто почему-то инфраструктура начинает стоить дороже.

Проблемы инфраструктуры


Сложности есть и на другой стороне.

Сложно управлять десятками сервисов и окружений без качественного кода. У нас в GitHub сейчас больше 450 репозиториев. Часть из них не требует операционной поддержки, часть мертва и сохраняется для истории, но значительная часть содержит сервисы, которые нужно поддерживать. Им нужно где-то хоститься, нужен мониторинг, сбор логов, единообразные CI/CD-пайплайны.

Чтобы всем этим управлять, мы ещё недавно активно использовали Ansible. В нашем Ansible-репозитории было:

  • 60 ролей;
  • 102 плейбука;
  • обвязка на Python и Bash;
  • тесты в Vagrant, запускаемые вручную.

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

Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или некогда запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.

Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.

Многие инструменты требуют встраивания в код приложения. Ребята из инфраструктуры знают, что нужно мониторить, как логировать и на какие вещи обращать внимание для трейсинга. Но встроить это всё в код приложения часто не могут. А те, кто могут, не знают что и как встраивать.

Сломанный телефон. В сотый раз объяснять, что и как мониторить, неприятно. Проще написать общую библиотеку, чтобы передать её программистам для переиспользования в своих приложениях. Но для этого нужно уметь писать код на том же языке, в том же стиле и с теми же подходами, которые используют разработчики ваших приложений.

Проблемы бизнеса


У бизнеса тоже есть две большие проблемы, которые нужно решать.

Прямые потери от нестабильности системы, связанной с надёжностью и доступностью.
В 2018 году у нас произошёл 51 критический инцидент, а критичные элементы системы не работали в сумме больше 20 часов. В деньгах это 25 млн. рублей прямых потерь из-за несозданных и недоставленных заказов. А сколько мы потеряли на доверии сотрудников, клиентов и франчайзи, подсчитать невозможно, в деньгах это не оценивается.

Расходы на поддержку текущей инфраструктуры. При этом компания поставила перед нами цель на 2018 год: в 3 раза уменьшить стоимость инфраструктуры в пересчёте на одну пиццерию. Но ни программисты, ни DevOps-инженеры в рамках своих команд не могли даже приблизиться к решению этой задачи. Этому есть причины:

  • с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
  • с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
  • с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

И что с этим делать?


Как решить все эти проблемы? Решение мы нашли в книге Site Reliability Engineering от Google. Когда прочли, поняли это то, что нам нужно.

Но есть нюанс чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.

Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.

Из хороших практик SRE у нас уже были:

  • механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
  • процессы для дежурств 24/7 on-call;
  • практика ведения постмортемов по инцидентам и их анализ;
  • нагрузочное тестирование;
  • CI/CD-пайплайны для прикладного софта;
  • хорошие программисты, которые пишут хороший код;
  • евангелист SRE в команде инфраструктуры.

Но были и проблемы, которые хотелось решить в первую очередь:

Команда инфраструктуры перегружена. На глобальные улучшения не хватало времени и сил из-за текущей операционки. Например, мы очень долго хотели, но не могли избавиться от Elasticsearch в своём стеке, или продублировать инфраструктуру у другого облачного провайдера, чтобы избежать рисков (тут могут посмеяться те, кто уже пробовал в мультиклауд).

Хаос в коде. Инфраструктурный код был хаотичен, разбросан по разным репозиториям и нигде не задокументирован. Всё держалось на знаниях отдельных людей и больше ни на чём. Это была гигантская проблема управления знаниями.

Есть программисты, а есть инженеры инфраструктуры. Несмотря на то, что у нас достаточно хорошо была развита культура DevOps, всё ещё было это разделение. Два класса людей с абсолютно разным опытом, которые говорят на разных языках и пользуются разными инструментами. Они, конечно, дружат и общаются, но часто не понимают друг друга из-за совершенно разного опыта.

Онбординг SRE-команды


Чтобы решить эти проблемы и как-то начать двигаться в сторону SRE, мы запустили проект онбординга. Только это был не классический онбординг обучение новых сотрудников (новичков), чтобы добавить людей в текущую команду. Это было создание новой команды из инженеров инфраструктуры и программистов первый шаг к полноценной структуре SRE.

На проект мы выделили 4 месяца и поставили три цели:

  1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
  2. Написать IaC описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
  3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

Состав участников: 9 человек, 6 из них из команды разработки, 3 из инфраструктуры. На 4 месяца они должны были уйти из обычной работы и погрузиться в обозначенные задачи. Чтобы поддерживать жизнь в бизнесе, ещё 3 человека из инфраструктуры остались дежурить, заниматься операционкой и прикрывать тылы. В итоге проект заметно растянулся и занял больше пяти месяцев (с мая по октябрь 2019-го года).

Две составляющие онбординга: обучение и практика


Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.

Обучение. На обучение выделялось минимум 3 часа в день:

  • на чтение статей и книг из списка литературы: Linux, сети, SRE;
  • на лекции по конкретным инструментам и технологиям;
  • на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

Ещё один инструмент обучения внутреннее демо. Это еженедельная встреча, на которой каждый (кому есть, что сказать) за 10 минут рассказывал о технологии или концепции, которую он внедрил в нашем коде за неделю. Например, Вася поменял пайплайн работы с Terraform-модулями, а Петя переписал сборку образов на Packer.

После демо мы заводили обсуждения под каждой темой в Slack, где заинтересованные участники могли асинхронно обсуждать всё детальнее. Так мы избегали длинных встреч на 10 человек, но при этом все в команде хорошо понимали, что происходит с нашей инфраструктурой и куда мы катимся.



Практика. Вторая часть онбординга создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.



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

Концепты. Мы экспериментировали с разными технологиями, языками, подходами, выясняли, как можем описать нашу инфраструктуру, какие инструменты стоит для этого использовать.

Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.

Пересоздание стендов для нагрузочного тестирования и продакшена. Это четвёртый этап, который должен был идти после онбординга, но его пока отложили, так как профита от него, как ни странно, гораздо меньше, чем от дев-окружений, которые создаются/пересоздаются очень часто.

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

Наши инструменты для IaC
  • Terraform для описания текущей инфраструктуры.
  • Packer и Ansible для создания образов виртуальных машин.
  • Jsonnet и Python как основные языки разработки.
  • Облако Azure, потому что у нас там хостинг.
  • VS Code IDE, для которой создали единые настройки, расширенный набор плагинов, линтеров и прочего, чтобы писать унифицированный код и расшарили их между всеми разработчиками.
  • Практики разработки одна из основных вещей, ради которой затевался весь этот карнавал.


Практики Extreme Programming в инфраструктуре


Главное, что мы, как программисты, принесли с собой это практики Extreme Programming, которые используем в работе. XP гибкая методология разработки ПО, соединяющая в себе выжимку из лучших подходов, практик и ценностей разработки.

Нет ни одного программиста, который бы не использовал хотя бы несколько из практик Extreme Programming, даже если он об этом не знает. При этом в мире инфраструктуры данные практики обходят стороной, несмотря на то, что они в очень большой степени пересекаются с практиками из Google SRE.

О том, как мы адаптировали XP для инфраструктуры, есть отдельная статья. Но если вкратце: практики XP работают и для кода инфраструктуры, пусть с ограничениями, адаптациями, но работают. Если хотите их применять у себя, зовите людей с опытом применения этих практик. Большинство из этих практик так или иначе описаны в той самой книге о SRE.

Всё могло бы сложиться хорошо, но так не бывает.

Технические и антропогенные проблемы на пути


В рамках проекта было два вида проблем:

  • Технические: ограничения железного мира, недостаток знаний и сырые инструменты, которыми приходилось пользоваться, потому что других нет. Это привычные любому программисту проблемы.
  • Человеческие: взаимодействие людей в команде. Общение, принятие решений, обучение. С этим было хуже, поэтому нужно остановиться подробнее.

Мы начали развивать команду онбординга так, как стали бы делать это с любой другой командой программистов. Мы ожидали, что будут обычные стадии формирования команды по Такману: шторминг, норминг, а в конце мы выйдем на производительность и продуктивную работу. Поэтому не переживали, что вначале возникали какие-то сложности в общении, принятии решений, сложности с тем, чтобы договориться.

Прошло два месяца, но фаза шторминга продолжалась. Только ближе к концу проекта мы осознали, что все проблемы, с которыми мы боролись и не воспринимали, как связанные друг с другом были следствием общей корневой проблемы в команде сошлись две группы абсолютно разных людей:

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

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

Но избежать этого столкновения невозможно. Если позовёте в проект сильных программистов и слабых инженеров инфраструктуры, то у вас будет однонаправленный обмен знаний. Наоборот тоже не работает одни проглотят других и всё. А вам нужно получить некую смесь, поэтому нужно быть готовым к тому, что притирка может оказаться очень долгой (в нашем случае мы смогли стабилизировать команду лишь спустя год, попрощавшись при этом с одним из самых сильных в техническом плане инженеров).

Если хотите собрать именно такую команду, не забудьте позвать сильного Agile- коуча, scrum-мастера, или психотерапевта что больше нравится. Возможно, они помогут.

Итоги онбординга


По итогам проекта онбординга (он завершился в октябре 2019 года) мы:

  • Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
  • Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
  • Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
  • Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

Вместо выводов: инсайты, не наступайте на наши грабли


Несколько инсайтов от разработчика. Не наступайте на наши грабли, сэкономьте себе и окружающим нервы и время.

Инфраструктура пока в прошлом. Когда я учился на первом курсе (15 лет назад) и начинал изучать JavaScript, у меня из инструментов были NotePad ++ и Firebug для отладки. C этими инструментами уже тогда нужно было делать какие-то сложные и красивые вещи.

Примерно так же я ощущаю себя сейчас, когда работаю с инфраструктурой. Текущие инструменты только формируются, многие из них ещё не вышли в релиз и имеют версию 0.12 (привет, Terraform), а у многих регулярно ломается обратная совместимость с предыдущими версиями.

Для меня, как энтерпрайз-разработчика, использовать на проде такие вещи абсурд. Но других просто нет.

Читайте документацию. Как программист, я относительно редко обращался к докам. Я достаточно глубоко знал свои инструменты: любимый язык программирования, любимый фреймворк и БД. Все дополнительные инструменты, например, библиотеки, обычно написаны на том же языке, а значит всегда можно посмотреть в исходники. IDE всегда подскажет, какие и где нужны параметры. Даже если я ошибусь, то быстро это пойму, запустив быстрые тесты.

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

Комментарии в коде инфраструктуры неизбежны. В мире разработки комментарии признак плохого кода. Они быстро устаревают и начинают врать. Это признак того, что разработчик не смог иначе выразить свои мысли. При работе с инфраструктурой комментарии так же признак плохого кода, но без них уже не обойтись. Для разрозненных инструментов, которые слабо связаны друг с другом и ничего не знают друг о друге, без комментариев не обойтись.

Часто под кодом скрываются обычные конфиги и DSL. При этом вся логика происходит где-то глубже, куда нет доступа. Это сильно меняет подход к коду, тестированию и работе с ним.

Не бойтесь пускать разработчиков в инфраструктуру. Они могут привнести полезные (и свежие) практики и подходы из мира разработки ПО. Пользуйтесь практиками и подходами от Google, описанными в книге про SRE, получайте пользу и будьте счастливы.

PS: Я специально не стал затрагивать в этой статье темы микросервисов, Кубернетеса и прочие хайповые вещи, с которыми приходится учиться жить, так как это большая тема для отдельной статьи.

PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится два блока по два дня и домашние задания между ними.

Чтобы узнать подробнее о том, что будет происходить на DevOps Live и что полезного вынесут инженеры, безопасники, тимлиды и CTO, подписывайтесь на рассылку и следите за публикациями в блоге.
Подробнее..

Что такое Immutable Infrastructure

02.09.2020 12:08:46 | Автор: admin

Меня зовут Никита, я системный инженер в компании SEMrush. И в этой статье я расскажу вам, что такое Immutable Infrastructure, какие у этого подхода есть преимущества и недостатки и как мы его используем в компании.



Если вы ни разу не слышали такое словосочетание, то усаживайтесь поудобнее, будет интересно.


Что это такое


Immutable Infrastructure подход к созданию неизменяемой инфраструктуры. Идея его не нова в мире, хоть и не слишком распространена. Мы начали его использовать, когда поняли, что не все можно запустить в Kubernetes, и нам нужны виртуальные машины.


Это подход о виртуалках, к которым надо относиться как к "пакетам" или контейнерам. Образ виртуальной машины, приложение и его окружение неделимое целое. Деплой новой версии приложения подразумевает создание нового образа виртуальной машины, развертывание из него виртуалки и введение машины в строй на замену "старых" виртуалок. В общем, это практически попытка сделать контейнер из виртуалки.


Ниже мы рассмотрим преимущества и недостатки этого подхода, но прежде я хотел бы вставить небольшую оговорку.


Мы в компании активно используем облако GCP, поэтому не админим железо, на котором запускаются виртуалки. У GCP есть мощный API и множество SaaS продуктов, использование которых делает возможным применение Immutable подхода. Если у вас KVM-хосты, и вы выкатываете виртуалки скриптиком, то вряд ли вам подойдет такое решение. Но при использовании любого облака (Openstack, AWS, Azure и т.д.), можно имплементировать данный подход. Я опишу его применение совместно со всей мощью облака, где, например, создание виртуалки происходит POST-запросом, а увеличение диска производится на лету.


Преимущества Immutable


Такой подход к организации инфраструктуры несет в себе практически все те же плюсы, что дает Docker и Kubernetes, только для виртуальных машин, а именно:


  1. Повторяемое окружение
    Обычно на сервер устанавливается операционная система определенной версии, настраивается окружение для приложения и происходит деплой самого приложения. Но если вы захотите через какое-то время развернуть точно такой же сервер с вашим приложением, то точно такой же у вас никак не получится: какие-то пакеты устарели, на другие пакеты выпущены security патчи, ядро уже тоже обновилось. В итоге вы получаете два похожих сервера. И вот эта разница часто является ключевой и может привести к багам и ошибкам. С Immutable Infrastructure у вас всегда есть образ виртуальной машины, который точно запустится и будет повторять реальное окружение точь-в-точь. В нем уже все предустановлено: все системные пакеты и библиотеки одной версии, а окружение приложения не изменится со временем. Вы можете повторно развернуть или масштабировать сервис спустя годы, лишь бы у вас был образ.
  2. Инфраструктура как код
    Immutable infrastructure всегда описана как код, потому что на каждый коммит (релиз) нам нужно создавать новый образ виртуальной машины, а также проводить его через пайплайны CI/CD. Это не получится делать руками.
  3. Неизменяемое окружение
    Как и в случае с Docker контейнером, виртуальная машина не может быть изменена. Не придет какой-нибудь configuration management инструмент или unattended upgrades, которые установят новые версии пакетов и все сломают. Там просто нет этих механизмов. Они не нужны и даже специально отключаются, потому что все, что нужно для функционирования приложения, уже установлено в системе. Окружение неизменяемо во времени и всегда одно и то же, пока не произошел релиз новой версии приложения.
  4. Отсутствие configuration drift
    Может быть такое, что у вас есть 100 серверов, на которые нужно вылить новый апдейт, и на несколько из них выкладка зафейлилась по какой-то причине. Тогда ваша конфигурация разъезжается, и вы не имеете одинакового окружения на всех машинах в вашей системе. Или у вас работает unattended upgrade, который периодически ставит обновления безопасности, и где-то ему удалось поставить пакет, а где-то нет. Immutable же гарантирует неизменяемость виртуалок во времени, а также то, что на них одна одинаковая версия всех приложений, зависимостей и операционной системы.
  5. Независимость от внешних источников
    В ходе настройки окружения приложению необходимы различные зависимости, которые тянутся из внешних источников. Если внешний источник недоступен, то создание новых инстансов может быть зафейлено. С Immutable такого не произойдет. Все зависимости уже установлены в образе, что гарантирует работоспособность приложения после старта. С таким подходом мы выносим failure point на этап билда образа, а не на этап деплоя, когда что-то пошло не так при обновлении на production VM. После того, как образ собран, мы точно знаем, что виртуалка рабочая, и осталось задеплоить ее как обычно.
  6. Отсутствие устаревших систем
    С Immutable нет проблемы "старых" серверов с высоким аптаймом, которые страшно не только обновить, но и даже перезагрузить. Любое изменение это новый билд образа и новая виртуалка.
  7. Простое масштабирование
    Всегда есть некий срез во времени вашего приложения, поднять новый инстанс которого можно по щелчку пальцев.
  8. Все плюсы облака
    В облаке дешево и легко создавать новые ресурсы, запрашивать столько CPU и RAM, сколько необходимо. Кроме того, можно интегрировать виртуалки с другими сервисами GCP: Load balancers, GCS для бэкапов, Autoscaler, Cloud SQL и т.д.
  9. Трансформация разработки
    Такой подход к инфраструктуре и осознание того, что инфраструктурная часть неотделима от самого кода и приложения, что минимальная единица это виртуальная машина, заставляет изменить и подход к разработке приложения. Нужно проектировать свое приложение исходя из того, что оно будет immutable. Приложение должно "осознавать" свою эфемерность и быть готовым быть замененным новой версией самого себя. Деплой таких приложений тоже отличается, поэтому нужно предусмотреть нюансы на этапе проектирования.
  10. Базовые образы
    Можно создать образы виртуальных машин различных ОС с предустановленным ПО, которые будут являться базовыми. Далее их можно расширять, устанавливая туда конкретные приложения и окружения для них. Все по аналогии с Docker образами.
  11. Простые откаты
    Чтобы откатиться на предыдущую версию, достаточно просто поднять виртуалку с предыдущим образом. Как будто бы запускаешь контейнер.
  12. Идентичные окружения
    Вы собираете новый образ виртуальной машины и запускаете его в Dev окружении на тестирование. Если тестирование прошло успешно, вы запускаете ТОТ ЖЕ САМЙ ОБРАЗ (только с другим конфигом для provisioner) в Prod окружении.

Но есть нюансы


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


  1. Более сложный деплой
    Immutable подразумевает, что каждый раз при любом изменении вы создаете новый образ, на основе которого запускаете виртуалку. После этого вам может понадобится сконфигурировать приложение (чтобы оно получило свои переменные, конфиги, вступило в кластер и т.д.). Это все необходимо автоматизировать и это может быть достаточно сложно. Пайплайн обновления и его логика могут получаться развесистыми.
  2. Даунтайм при обновлениях
    Если есть приложение, которое крутится на виртуалке и использует какие-то данные, хранящиеся локально, то выкладка новой версии приложения подразумевает ряд процессов: выключение текущей виртуалки, отсоединение от нее диска, поднятие нового инстанса, подключение диска к нему. Понятно, что это ведет к даунтайму (по правде сказать, в таком случае перерыв в работе сервиса, но просто более короткий, был бы даже если бы и не использовался Immutable подход). Узкие места: единственный инстанс и локальный storage. Решить это можно через системы динамической конфигурации, несколько инстансов (горячий, холодный резерв или одновременная работа), удаленный storage (но тут уже будет возможный downgrade производительности дисковой подсистемы). Все это зависит от конкретного кейса и архитектуры приложения. Если это Stateless воркеры, то для них данная концепция подходит как никакая другая. А у нас, например, на инфраструктурных сервисах есть SLA, в рамках которого мы иногда можем сделать даунтайм для обновления.
  3. Отсутствие постоянных апдейтов
    Как это ни странно, но у Immutable есть обратная сторона своего же преимущества это отсутствие постоянных апдейтов, security патчей и т.д., которые в обычной системе могут быть настроены на автоматическую установку. В образе не обновится ничего, пока вы не соберете и не задеплоите обновленный вами образ.

Выше я описал данный подход как идеальный случай. Мы стараемся придерживаться Immutable идеологии по максимуму, но на сколько полно получится реализовать идею, зависит от приложения, его сложности, архитектуры, особенностей деплоя и т.д. Иногда не получится автоматизировать прям всё-всё (или это будет дорого и трудозатратно), поэтому всегда нужно придерживаться здравого смысла. Не надо делать Immutable ради Immutable. В первую очередь нужно понимать, какие преимущества вы получите и достаточно ли их. И готовы ли вы к недостаткам.


Push и Pull модели


При проектировании нужно учитывать, какой модели будет соответствовать ваше приложение. Существует два основных пути:


Push


Такая модель не подразумевает, что приложение может автоматически масштабироваться, а соответственно, количество виртуалок строго постоянно в течение времени. Это значит, что новая машина запускается по коммиту собирается новый образ, создается новая виртуалка, CI/CD накатывает в нее необходимую конфигурацию, приложение запускается. То есть конфигурация происходит снаружи пушится в виртуалку.


Pull


При таком подходе может работать автоскейлинг, а виртуалки будут в инстанс группе (ну или использовать схожий механизм). Это значит, что создание новой виртуалки будет происходить автоматически, а не по воли оператора или процесса CI. Новосозданная машина должна иметь в себе все необходимое для само конфигурации. То есть конфигурация происходит изнутри пуллится самой виртуалкой (в себя).


В зависимости от модели нужно по-разному подходить к проектированию CI/CD пайплайна и процесса деплоя.


В главных ролях


При работе с неизменяемой инфраструктурой нам помогают эти инструменты:


  1. Packer программа от Hashicorp, которая позволяет создавать образы виртуальных машин, на базе разных облачных провайдеров. Packer берет указанный базовый образ, создает из него виртуалку в нужном облачном провайдере, накатывает в нее конфигурацию с помощью любого из множества провижинеров, а в конце создает из ее диска установочный образ, который можно использовать в выбранном облаке.
  2. Terraform еще одна утилита от Hashicorp, которая, наверное, уже не нуждается в представлении. Позволяет описать необходимые инфраструктурные ресурсы нужного облачного провайдера и, используя этот манифест, приводит конфигурацию облака к описанному в конфиге.
  3. Ansible инструмент, с которым также знакомы почти все. Он нам нужен для того, чтобы делать provision образа и создаваемой виртуалки настраивать окружение.
  4. Gitlab CI мы используем Gitlab, поэтому и всю автоматизацию пишем на нем.
  5. GCP собственно, облако, которое делает запуск виртуалки легким и простым, а также позволяет создавать множество других ресурсов.

Immutable Images


Образ VM является основным артефактом деплоя. У нас есть собственные базовые образы, которые собираются на основе образов Google, специально заточенных под работу в их облаке, образы приложений с каким-то предустановленным, но не сконфигуренным ПО (nginx, mysql, mongodb и т.д.), и продуктовые образы. Последние содержат в себе все необходимое для работы конкретного продукта или его компонента (это может быть образ с настроенной БД, вэб-сервером, бэкэндом). Как можно понять, каждый образ в иерархии базируется на каком-то родителе и расширяет его. Для конфигурации образов (подготовки окружения) мы используем Ansible отличный инструмент, позволяющий доставлять one-shot конфигурацию.


Если вы разрабатываете концепцию образов виртуальных машин, важно как можно раньше придумать и внедрить конвенцию именования образов. Имя образа должно четко и однозначно определять ОС, на базе которого он собран, и его основную функцию (ПО, его версия), для чего он был собран. Тогда в дальнейшем будет намного проще и удобнее с ними работать.


Image Family


У образа в GCP есть имя, метки, статус, а также принадлежность к какой-то Image Family.


Image Family удобный механизм, объединяющий все версии одного образа под одной "семьей". Это упрощает использование базовых образов если вам не нужно точно знать, какую вы используете версию образа, его название, которое включает дату и т.д., вы просто указываете image family, на базе которого вы хотите собраться, и все. Это аналог тега latest в докере.


Однако, если при сборке образа использование Image Family вполне оправдано, то при деплое вам обязательно нужно использовать Image Name и указывать конкретный образ, который вы хотите задеплоить (только что собранный). Как и latest в докере, использование family может привести к дрифту версий или неожиданным изменениям на проде.


Кратко принцип работы с Image Family выглядит так:
У вас есть image-v1 это самая последняя версия образа вашего приложения. my-image-family указывает на данный образ


gcloud compute images create image-v1 \    --source-disk disk-1 \    --source-disk-zone us-central1-f \    --family my-image-familygcloud compute images describe-from-family my-image-familyfamily: my-image-familyid: '50116072863057736'kind: compute#imagename: image-v1

Вы создаете новый образ image-v2, и теперь my-image-family указывает на него.


gcloud compute images create image-v2 \    --source-disk disk-2 \    --source-disk-zone us-central1-f \    --family my-image-familygcloud compute images describe-from-family my-image-familyfamily: my-image-familyid: '50116072863057756'kind: compute#imagename: image-v2

По какой-то причине нужно откатиться на предыдущую версию, и теперь my-image-family снова указывает на image-v1:


gcloud compute images deprecate image-v2 \    --state DEPRECATED \    --replacement image-v1gcloud compute images describe-from-family my-image-familyfamily: my-image-familyid: '50116072863057736'kind: compute#imagename: image-v1

Обновление и ротация базовых образов


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


У образов виртуальных машин в GCP есть текущее состояние:
READY образ готов к использованию
DEPRECATED образ признан deprecated. Такие образы не отображаются в веб-консоли по-умолчанию, но доступны для gcloud и terraform. В случае их использования выдается предупреждение.
OBSOLETE образ в этом статусе уже недоступен для использования.
DELETED образ помечен удаленным, но еще существует физически.
REALLY_DELETED такого статуса в реальности нет, но спустя некоторое время, как образ был помечен DELETED, он будет удален по-настоящему.


Используя эти статусы, мы создали процесс ротации образов. На картинке ниже представлен жизненный цикл образа и его основные этапы.



Для базовых образов мы делаем автообновление. Раз в сутки производится автоматическая проверка наличия обновления пакетов, входящих в состав образа. Если обновления найдены, производится сборка новой версии образа и указатель image-family сдвигается на нее. После этого происходит ротация всех образов, относящихся к данной image-family.


Для автоматизации жизненного цикла мы написали скрипт image-rotator, который в ближайшее время мы выложим в публичный доступ (в статью будет добавлена ссылка). Его принцип работы следующий:


  1. Скрипту передаются нужные переменные, главной из которых является --image-family. Так он понимает, с чем ему нужно работать
  2. Скрипт находит все образы, принадлежащие данной Image Family, и дальше работает со всеми этими образами КРОМЕ последнего актуального образа, на который указывает Image Family в данный момент
  3. Далее среди этих образов он делает следующее:
    • Все READY образы делает DEPRECATED и проставляет им дату, когда они должны стать OBSOLETE
    • Все DEPRECATED образы, у которых дата obsolete меньше текущей даты, переводит в состояние OBSOLETE и выставляет дату, когда образ должен стать DELETED
    • Все OBSOLETE образы обрабатывает по аналогии с DEPRECATED
    • То же самое с DELETED. Если у DELETED образа подошла дата удаления, то скрипт удаляет образ навсегда

Схема пайплайна


Итак, теперь, когда мы разобрались с основными моментами, можно рассмотреть общий процесс деплоя.


На рисунке ниже, схематично, представлен данный процесс.


Мы подразумеваем, что сначала деплоим приложение в Dev-среду из Master-ветки (название ветки здесь не принципиально), где оно тестируется. После чего, деплоим тот же самый образ на Prod-окружение из другой ветки stable, посредством синхронизации двух веток через Merge Request.


Этот пайплайн схематичен и может быть усложнен для достижения конкретных целей или абсолютной автоматизации. Например, в наших пайплайнах, дополнительно к тому, что показано на схеме автоматизировано:


  • Интеграция с Hashicorp Vault для получения секретов
  • Использование снапшотов дисков с данными Prod-инстанса для создания Dev окружения
  • Использование последнего бэкапа CloudSQL (примечание: база данных как сервис от Google (MySQL, PostgreSQL)) Prod-инстанса для создания базы данных в Dev-окружении
  • Удаление Dev-окружения в конце тестирования (это же облако, нам не хочется тратить лишние деньги)

Дальше Terraform создает виртуалку с приложением в Dev-окружении, создает диск со свежими данными из образа, сделанного в п.1. Так мы получаем свежие независимые данные, на которых протестируем новую виртуалку. Бонусом случайно проверяем бэкапы Prodа :)


Заключение


На этом с теорией покончено. И к сожалению (или к счастью для тех, кто не любит много буков), на самом интересном я заканчиваю свое изложение, так как статья уже получилась достаточно объемной, и реальный пример сервиса, разворачиваемого с помощью данной концепции, она уже не вместит. Напишите в комментариях, если статья получилась интересной/полезной, и хочется посмотреть, как это сделано на практике: с кодом, реальным CI/CD и пояснениями. Я буду благодарен вам за обратную связь.


Immutable Infrastructure подход, который имеет свои плюсы и минусы. Подход, который подойдет не для каждого сервиса или приложения. И я повторюсь, использовать его надо, понимая и принимая все его плюсы и минусы. И конечно, пусть всегда торжествует здравый смысл. Вы всегда можете взять какую-то его часть и использовать только ее, если это дает вам преимущества.


Сейчас мы в команде работаем над усовершенствованием концепции и нашей реализации, так как через некоторое время использования ее в том виде, в котором она описана здесь, мы поняли, что нам есть над чем работать, и у нас есть идеи как все сделать лучше. И когда все получится, мы напишем еще одну статью, в которой поделимся нашими наработками.

Подробнее..

Перевод Применение паттернов Netflix DevOps к Windows

11.01.2021 12:12:41 | Автор: admin

Когда говорят про DevOps обычно всегда подразумевают работу с Linux. Но есть большое количество решений под Windows. Как осуществлять сборку Windows c помощью Packer в своем блоге поделился Netflix (Джастин Фелпс и Мануэль Корреа - Applying Netflix DevOps Patterns to Windows). Предлагаю перевод статьи.

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

Artisan Crafted Images

В культуре DevOps в Netflix группа, ответственная за создание сервиса, также отвечает за развертывание, тестирование, инфраструктуру и работу этой службы. Основная обязанность инженеров Netflix - выявление пробелов и болевых точек при разработке и эксплуатации сервисов. Хотя большинство наших сервисов работают на Linux Amazon Machine Images (AMI), все еще существует множество сервисов, критически важных для Netflix Playback Experience, работающих на инстансах Windows Elastic Compute Cloud (EC2).

Мы изучили наш процесс создания образов Windows AMI и обнаружили, что он подвержен ошибкам и полон утомительных усилий. Сначала инженер запускал инстанс EC2 и ждал, пока он перейдет в режим онлайн. Как только экземпляр оказывался доступен, инженер использовал инструмент удаленного администрирования, такой как RDP, для входа в экземпляр для установки программного обеспечения и настройки параметров. Затем этот образ сохранялся как AMI и использовался в Auto Scale Group для развертывания кластера инстансов. Поскольку этот процесс занимал много времени и был долгим, в наших экземплярах Windows обычно отсутствовали последние обновления безопасности от Microsoft.

В прошлом году мы решили улучшить этот процесс.

Были следующие проблемы:

  • устаревшая документация.

  • обновления ОС.

  • высокие когнитивные издержки.

  • отсутствие непрерывного тестирования.

Масштабирование создания образов.

Наш существующий инструмент создания AMI - Aminator - не поддерживает Windows, поэтому нам пришлось использовать другие инструменты.

Когда мы пытались улучшить методологию создания образов, мы преследовали несколько целей:

Конфигурация как код

Первая часть нашего нового решения для создания образов Windows - Packer. Packer позволяет описать процесс настройки образов в виде файла JSON. Мы используем конструктор amazon-ebs Packer для запуска инстанса EC2. После подключения Packer использует WinRM для копирования файлов и выполнения сценариев PowerShell для экземпляра. Если все шаги настройки выполнены успешно, Packer сохраняет новый AMI. Файл конфигурации, сценарии, на которые имеются ссылки, и описание зависимостей артефактов находятся во внутреннем репозитории git. Теперь у нас есть конфигурация инстанса и программного обеспечения в виде кода. Это означает, что эти изменения можно отслеживать и просматривать, как и любые другие изменения кода.

Packer требуется специфическая информация для вашей среды создания образов и расширенные разрешения AWS IAM. Чтобы упростить использование Packer для наших разработчиков программного обеспечения, мы объединили специфичную для Netflix информацию о среде AWS и вспомогательные сценарии. Изначально мы сделали это с репозиторием git и файлами переменных Packer. Также был специальный экземпляр EC2, где Packer выполнялся как задания Jenkins. Эта установка была лучше, чем создание образов вручную, но у нас все же были некоторые проблемы с эргономикой. Например, стало сложно гарантировать, что пользователи Packer получают обновления.

Последняя часть нашего решения - найти способ упаковать наше программное обеспечение для установки в Windows. Это позволит повторно использовать вспомогательные сценарии и инструменты инфраструктуры, не требуя от каждого пользователя копировать это решение в свои сценарии Packer. В идеале это должно работать аналогично тому, как приложения упаковываются в процессах Animator. Мы решили эту проблему, используя Chocolatey, менеджер пакетов для Windows. Пакеты Chocolatey создаются и затем сохраняются во внутреннем репозитории артефактов. Этот репозиторий добавлен в качестве источника для команды choco install. Это означает, что мы можем создавать и повторно использовать пакеты, которые помогают интегрировать Windows в экосистему Netflix.

Использование Spinnaker для непрерывной доставки

Базовый Dockerfile позволяет обновлениям Packer, вспомогательным скриптам и конфигурациям среды распространяться через весь процесс создания образов Windows.Базовый Dockerfile позволяет обновлениям Packer, вспомогательным скриптам и конфигурациям среды распространяться через весь процесс создания образов Windows.

Чтобы сделать процесс создания образов более надежным, мы решили использовать образ Docker, содержащий Packer, конфигурацию нашей среды и вспомогательные скрипты. В дальнейшем пользователи создают свои собственные образы Docker на основе этого базового образа. Это означает, что мы можем обновить базовый образ, добавив в него новую информацию о среде и вспомогательные сценарии, и пользователи будут получать эти обновления автоматически. Со своим новым образом Docker пользователи запускают свои задания по созданию образов Packer с помощью Titus, нашей системы управления контейнерами. Задание Titus создает файл свойств как часть пайплайна Spinnaker. Полученный файл содержит AMI ID и используется на более поздних этапах пайплайна для деплоя. Создание образа в Titus сняло ограничение на использование одного экземпляра EC2, что позволило выполнять задания. Теперь каждое изменение в инфраструктуре тестируется, обрабатывается и развертывается, как и любое другое изменение кода. Этот процесс автоматизирован с помощью пайплайна Spinaker:

пример пайплайна Spinaker, показывающий этапы создания, сборки и развертывания образов.пример пайплайна Spinaker, показывающий этапы создания, сборки и развертывания образов.

На этапе сборки Kayenta используется для сравнения показателей между базовым образом (текущий AMI) и тем что собирается (новый AMI). На сборочном этапе оценка будет определяться на основе таких показателей, как CPU, threads, latency и GC pause. Если эта оценка находится в пределах допустимого порога, AMI развертывается в каждой среде. Запуск сборки для каждого изменения и тестирование AMI в производственной среде позволяет нам получить представление о влиянии обновлений Windows, изменений скриптов, настройки конфигурации веб-сервера и т. д.

Избавление от тяжелого труда(Eliminate Toil)

Автоматизация этих утомительных рабочих задач позволяет командам работать быстрее. Нашим инженерам больше не нужно вручную обновлять Windows, Java, Tomcat, IIS и другие службы. Мы можем легко протестировать изменения настройки сервера, обновления программного обеспечения и другие модификации среды выполнения. Каждое изменение кода и инфраструктуры проходит через один и тот же конвейер тестирования и развертывания.

Получение преимуществ

Изменения, которые раньше требовали нескольких часов ручной работы, теперь легко модифицировать, тестировать и развертывать. Другие группы могут быстро развернуть безопасные и воспроизводимые инстансы в автоматическом режиме. Услуги более надежны, тестируемы и документированы. Изменения в инфраструктуре теперь рассматриваются, как и любые другие изменения кода. Это снимает ненужную когнитивную нагрузку и документирует наши знания. Исключение тяжелого труда позволило команде сосредоточиться на других функциях и исправлениях ошибок. Все эти преимущества снижают риск сбоя, который может повлиять на клиента. Принятие шаблона Immutable Server для Windows с использованием Packer и Chocolatey принесло большие преимущества.

Подробнее..
Категории: Devops , Netflix , Packer , Iac

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru