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

Одна из идей DevOps – обеспечить команде на проекте единую инфраструктуру. Чтобы разработчики писали программы, а QA – тестировали в той же среде, в которой они будут потом использоваться.

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

Зачастую ради экономии средств полноценную инфраструктуру разворачивают только на продакшене, а в среде разработки и тестирования – что-то попроще. Код пишется и тестируется в одних условиях в надежде на то, что где-то так оно и будет работать в других. А «так» обычно не получается.

Далее – купленное оборудование нужно и близко не 24/7, большую часть времени оно простаивает, медленно покрываясь пылью и устаревая. Разработчики алчно посматривают на курс биткоина и все чаще шутят на тему того, что в свободное от работы время на оборудовании можно майнить биткоины, но едва ли кто-то переходит от слова к делу.

Каждый раз, когда в инфраструктуре надо что-то поменять, процедура настройки идет по привычным кругам ада: разработчики или QA сообщают админу о своих потребностях, он тратит время на настройку, и это далеко не пять минут. Если изначально разные компоненты инфраструктуры не очень хорошо взаимодействовали между собой и для их работы приходилось дописывать «костыли», то теперь админу надо будет вспомнить, что оно такое было, и повторить. И было бы здорово, если бы все потом использовалось дольше, чем настраивается.

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

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

В DevOps-практике это называется «инфраструктура как код»

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

«Инфраструктура как код» подразумевает, что все данные об инфраструктуре хранятся в виде скриптов в репозитории (в том же, которым пользуются разработчики проекта или другом, не принципиально) и извлекаются оттуда, когда нужно. Даже ждать, когда админ физически доберется до объекта, не надо – ведь все процедуры можно произвести «в облаке».

Если «ложится» один из серверов проекта, то это уже не повод для паники и бегства с корабля – восстановление инфраструктуры из готового файла занимает так же мало времени. Все уже было однажды создано, оттестировано на работоспособность и готово к внедрению сколько угодно раз и в любой момент.

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

Ценность такого подхода заключается в том, что он позволяет быстрее осуществлять «доставку» инфраструктуры туда, где она нужна, и оптимизировать неиспользуемые ресурсы. Например, для определенного проекта необходимо такое-то количество виртуальных машин и серверов с такими-то характеристиками, таким-то программным обеспечением, таким-то объемом накопителя. Если вы используете облако Azure, то проще всего создать шаблон инфраструктуры в Azure Resource Manager и быть уверенным, что все участники рабочей группы получат абсолютно одинаковые виртуальные машины – с теми же настройками и даже файлами в тех же каталогах. В дальнейшем при помощи одной команды можно будет просматривать все логи, связанные с работой инфраструктуры для этой группы и менять все на лету – подключать необходимые модули и библиотеки, менять настройки в соответствии с тем, что нужно для развертывания конкретного приложения, и быть уверенным, что нужна среда есть у всех, кто работает над проектом. Не вкладывая деньги и время в физическую инфраструктуру и оплачивая ровно то и ровно столько, сколько используется.

Microsoft Azure позволяет создавать инфраструктуру и управлять конфигурацией в том числе при помощи сторонних инструментов – таких как Chef и Puppet

Публичное облако не привязывает вас к определенной инфраструктуре в режиме 24/7. Соответственно, платить в нем можно только за те лицензии, объем накопителя, сервера и виртуальные машины, которые потребляет проект. Что-то из этого необходимо на весь период разработки, что-то – как виртуальные машины для тестирования – только часов 8-10 в день, на ночь их можно спокойно выключать (причем это все тоже настраивается один раз и работает всегда, если вдруг кто-то из команды решает совершить трудовой подвиг ночью или на выходных, то в единичных случаях правила тоже легко поменять на один момент). Это дает максимальный контроль над технической стороной проекта и над расходами на инфраструктуру.

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