Хабрахабр

Infrastructure as code: первое знакомство

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

Продолжение серии статей, написанных по мотивам выступлений на нашем внутреннем мероприятии DevForum:

Кот Шрёдингера без коробки: проблема консенсуса в распределённых системах.
2. 1. (You are here)
3. Infrastructure as code. (In progress...)
4. Генерация Typescript контрактов по c# моделям. (In progress...)
... Введение в алгоритм консенсуса Raft.

Мы решили сделать команду SRE, воплотив идеи google sre. Набрали программистов из своих же разработчиков и отправили их обучаться на несколько месяцев.

Перед командой стояли следующие учебные задачи:

  • Описать нашу инфраструктуру, которая по большей части в Microsoft Azure в виде кода (Terraform и все, что около).
  • Научить разработчиков работе с инфраструктурой.
  • Подготовить разработчиков к дежурствам.

Вводим понятие Infrastructure as code

В обычной модели мира (классическом администрировании) знания об инфраструктуре находятся в двух местах:

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

В обоих случаях мы оказываемся в ловушке, становясь зависимыми:

  • либо от человека, который смертный, подверженный болезням, влюблённостям, перепадам настроения и просто банальным увольнениям;
  • либо от физически работающей машины, которая тоже падает, воруется, преподносит неожиданности и неудобства.

Само собой напрашивается решение, что в идеале всё надо перевести в человекочитаемый, поддерживаемый, качественно написанный код.

Таким образом инфраструктура как код (Incfastructure as Code – IaC) – это описание всей имеющейся инфраструктуры в виде кода, а также сопутствующие средства по работе с ним и воплощению из него же реальной инфраструктуры.

Зачем переводить всё в код

Они не могут запомнить всё. Люди – не машины. Всё автоматизированное потенциально работает быстрее, чем всё, что делает человек. Реакция у человека и машины разная. Самое главное – это один источник правды (single source of truth).

Откуда берутся новые SRE-инженеры

Итак, мы решили подключить новых SRE-инженеров, но откуда их брать? Книжка с правильными ответами (Google SRE Book) говорит нам: из разработчиков. Ведь они работают с кодом, а вы достигаете идеального состояния.

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

Проблемы Infrastructure as code

Теперь давайте посмотрим примеры того, как инфраструктура может быть зашита в код. Код хорошо написан, качественно, с комментами и отступами.

Пример кода из Terraforma.

Пример кода из Ansible.

Мы же с вами в реальном мире, а он всегда готов удивить вас, преподнести сюрпризы, проблемы. Господа, но если бы всё было так просто! Не обходится без них и здесь.

Первая проблема состоит в том, что в большинстве случаев IaC – это какой-то dsl. 1.

Точнее того, что у тебя должно быть: Json, Yaml, модификации от каких-то крупных компаний, которые придумали свой dsl (в терраформе используется HCL). А DSL, в свою очередь, – это описание структуры.

Беда в том, что в нём может легко не быть таких привычных нам вещей как:

  • переменные;
  • условия;
  • где-то нет комментариев, например, в Json, по дефолту их не предусмотрено;
  • функции;
  • и это я еще не говорю о таких высокоуровневых вещах, как классы, наследование и всё такое.

2. Вторая проблема такого кода – чаще всего это гетерогенная среда. Обычно вы сидите и работаете с C#, т.е. с одним языком, одним стеком, одной экосистемой. А тут у вас огромное разнообразие технологий.

Вы его анализируете, потом еще какой-то генератор выдает ещё 30 файлов. Вполне реальная ситуация, когда баш с питоном запускает какой-то процесс, в который подсовывается Json. Довольно сложно иметь строго хорошо описанный код, когда у вас настолько разнообразная среда. Для всего этого поступают входные переменные из Azure Key Vault, которые стянуты плагином к drone.io, написанным на Go, и переменные эти проходят через yaml, который получился в результате генерации из шаблонизатора jsonnet.

Здесь же мы работаем с большим количеством языков. Традиционная разработка в рамках одной задачи идет с одним языком.

Третья проблема – это тулинг. 3. И даже, если мы затупили, они скажут, что мы не правы. Мы привыкли к крутом редакторам (Ms Visual Studio, Jetbrains Rider), которые все делают за нас. Кажется, что это нормально и естественно.

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

12, хотя она зарелижена уже как 3 месяца. На момент написания статьи vscode-terraform plugin еще не выпустили для поддержки версии 0.

Пришло время забыть о...

  1. Debugging.
  2. Refactoring tool.
  3. Auto completion.
  4. Обнаружении ошибок при компиляции.

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

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

Когда есть документация – зашли, посмотрели. Как новичок вы пытаетесь познать терраформ, а IDE вам в этом нисколько не помогает. По крайней мере, на уровне int или string. Но если бы вы въезжали в новый язык программирования, то IDE подсказала бы, что есть такой тип, а такого нет. Это часто бывает полезным.

А как же тесты?

Вы спросите: «Как же тесты, господа программисты?» Серьёзные ребята тестируют всё на проде, и это жестко. Вот пример юнитеста для терраформ-модуля с сайта Microsoft.

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

Я кинул 5 параметров, мне выдалась портянка Json на 2000 строк. Проблема unit-теста в том, что мы с вами можем проверить корректность Jsonа на выходе. Я могу проанализировать, что здесь происходит, validate test result…

А надо писать в Go, потому что терраформ на Go – это хорошая практика того, что тестируешь в том языке, в котором ты пишешь. Сложно анализировать Json в Go. При этом – это лучшая библиотека для тестирования. Сама организация кода очень слабая.

Конечно, это Open Source. Сам Microsoft пишет свои модули, тестируя их таким способом. Я могу сесть и за недельку всё починить, заопенсорсить плагины VS-кода, терраформ, сделать плагин для райдера. Всё, о чем я говорю вы можете прийти и починить. Всё могу сделать. Может быть, написать парочку анализаторов, прикрутить линтеры, законтрибьютить библиотеку для тестирования. Но я не этим должен заниматься.

Лучшие практики Infrastructure as code

Едем дальше. Если в IaC нет тестов, плохо с IDE и тулингом, то должны быть хотя бы лучшие практики. Я просто пошёл в гугл-аналитику и провёл сравнение двух поисковых запросов: Terraform best practices и c# best practices.

Беспощадную статистику не в нашу пользу. Что мы видим? В C# разработке мы просто купаемся в материалах, у нас есть сверхлучшие практики, есть книги написанные экспертами, и также книжки, написанные на книжки другими экспертами, которые критикуют те книжки. По количеству материала – то же самое. Море официальной документации, статей, обучающих курсов, сейчас еще и open source разработка.

Как вообще эти модули раскидывать, что с ними делать? Что касается запроса по IaC: здесь вы по крупицам пытаетесь собрать инфу с докладов хайлоада или HashiConf, с официальной документации и многочисленных issue на гитхабе. Но это не точно. Кажется, что это реальная проблема… Есть же комьюнити, господа, где на любой вопрос тебе дадут 10 комментов на гитхабе.

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

Куда всё это движется и что делать

Можно всё бросить и пойти обратно на C#, в мир райдера. Но нет. Зачем вы вообще стали бы этим заниматься, если не найти решение. Далее я привожу свои субъективные выводы. Можете поспорить со мной в комментариях, будет интересно.

Лично я ставлю на несколько вещей:

  1. Развитие в данной сфере происходит очень быстро. Привожу график запросов по DevOps.

    Может быть тема хайповая, но сам факт того, что сфера растёт, вселяет некоторую надежду.

    Увеличение популярности ведет к тому, что может у кого-то будет время дописать наконец плагин к jsonnet для vscode, который позволит переходить к имплементации функции, а не искать ее через ctrl+shift+f. Если что-то растет настолько быстро, то обязательно появятся умные люди, которые скажут как надо делать, а как не надо. Тот же выход книги от гугла про SRE отличный тому пример. Когда всё развивается, появляется больше материалов.

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

    Он сильно помогает разобраться. Банальный пример: совместная работа через pair programming. Когда у тебя есть рядом сосед, который тоже что-то пытается понять, вместе вы поймёте лучше.

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

Заключение

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть