Всем большой привет. Меня зовут Виктор, и я DevOps-инженер в команде Nixys. Мы решили выложить обучающее видео, которое будет полезно новичкам в мире DevOps. Тема сегодняшнего туториала - “Знакомство с Terraform”. Также под видео мы поделимся наиболее важными, на наш взгляд, преимуществами этого инструмента.

Кстати, есть небольшая история о том, почему мы вообще решили выкладывать видео. Некоторое время назад мы сняли несколько обучающих видео для внутреннего использования, которые лежали у нас на YouTube - на момент написания статьи мы запилили 7 роликов: 5 на джуна и 2 на мидла. И однажды один из знакомых ребят поделился с нами, что выполнял тестовое задание в одну из IT-компаний по нашим обучающим видео (которые, как мы вообще-то думали, в ПРИВАТНОМ режиме). Благодаря этому слепому случаю мы обнаружили, что количество просмотров некоторых роликов сильно перевалило количество сотрудников компании, а значит даже без нашего ведома приносят некоторую пользу. Так мы решили уже целенаправленно делиться нашими знаниями с более широкой аудиторией (жадничать мы не привыкли).

Итак, видеоролик под названием:

"DevOps с Nixys | Знакомство с Terraform - Tutorial для начинающих #1". 

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

О чём собственно само видео?

В видео демонстрируются возможности особенного подхода к управлению своей инфраструктуры в коде - Infrastructure as Code, или IaC. Как следует из названия, это подход для управления и описания своей инфраструктуры через конфигурационные файлы, а не через ручное редактирование конфигураций на серверах или интерактивное взаимодействие. С помощью замечательного инструмента Terraform мы разворачиваем небольшую облачную инфраструктуру в Yandex Cloud.

Сегодня мы не показываем, как правильно писать код на Terraform, а лишь демонстрируем толику его возможностей. В частности, мы развернули сеть и подсеть, где создали виртуальную машину, к которой привязали настроенную группу безопасности и выделили статичный IP. В самой ВМ мы также произвели настройку примитивнейшего веб-сервера. Кроме того, настроили хранение файла состояния terraform.tfstate в объектном хранилище.

Ну и зачем нам этот ваш Terraform?

Итак, теперь поговорим о том, для чего важен и нужен Terraform, о его преимуществах. Не будем подробно расписывать, что такое Terraform вообще, так как за нас это сделали уже давно - на Хабре есть куча полезнейших статей по теории и практике. Остановимся именно на целесообразности его использования. 

1. Скорость и уменьшение затрат

   Поднятие инфраструктуры вручную занимает меньше времени, да. Но только в самый первый раз. Тестовое окружение нужно? Да. И что же, снова поднимать всё то же самое? Вроде и не проблема, но давайте посчитаем: 

   1) Для простоты возьмем за основу круглые числа (очень условно). Пусть стоимость часа работы инженера = 1000 рублей. Допустим, поднять инфраструктуру руками = 100 часов. Поднять dev окружение = 0,75*100, (инженер же уже набил руку, и второй раз сделает это быстрее). Если нужен stage, то умножаем на два: 2*0,75*100. Итого, на все окружения затрачено - 250 часов и 250 000 рублей.

   2) А теперь давайте представим (опять-таки условно), что упал дата-центр и вам снова придётся заплатить за ту же работу 250 000 рублей. Итого, свыше 500 000 рублей + придётся ждать те же 100 часов, чтобы поднять хотя бы prod-окружение, залить данные и запустить его.

   3) При использовании Terraform время на поднятие инфраструктуры занимает у всех по-разному, в зависимости от опыта инженера и сложности самой инфраструктуры, но обычно это где-то X2, т.е. 200 часов, плюс стоимость часа работы инженера, который умеет работать с таким инструментом, уже будет выше - например, 1500 рублей. Чтобы поднять test- и stage-окружение нужно лишь поменять несколько переменных в коде - и всё! Я даже не знаю, с каким коэффициентом это считать, пусть будет 0,05*100 (т.е. по 5 часов на одно окружение). Итого - 210 часов, и 315 000 рублей. Пока не так радужно…

   4) А если снова смоделировать падение дата-центра? Код у нас остался, поэтому поднять новую инфраструктуру, примерно 6 часов, или почти один рабочий день. Причем большую часть времени займёт восстановление данных из бэкапов (конечно они могут быть гигантских размеров и тогда получится дольше, но тут уж ничего не попишешь). Итог - 321 000 рублей и день простоя :)

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

2. Исключение человеческого фактора.

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

   А что же насчет Terraform? В этом и есть его преимущество, если конфигурация написана правильно, то сколько бы времени не прошло и сколько бы раз вы не запускали terraform apply, результат будет одинаковый. Можно спокойно пересоздать сервер и залить туда свежий бэкап, если требуется. Я не говорю уже про случаи, когда что-то может произойти с дата-центром.

3. Стандартизация

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

4. Контроль версий

   Подход Infrastructure as Code подразумевает, что инфраструктура хранится в виде кода, соответственно, мы можем применять такую вещь, как система контроля версий, т.е. IaC позволяет документировать, регистрировать и отслеживать каждое изменение конфигурации. Ну прям сказка!

И предвосхищая ещё один ваш вопрос..

Почему бы тогда не нанять высококвалифицированного специалиста, чтобы он написал код? Зачем содержать своего сотрудника или платить другой компании за сопровождение?

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

Вывод

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

Спасибо за внимание.

P.S.: Подписывайтесь на наш Telegram-канал DevOps, где мы публикуем новости из мира DevOps.