Программирование начинается в главе 2, где вы научитесь развертывать кластер веб-серверов с помощью Terraform от начала и до конца. После этого следуйте инструкциям в каждой последующей главе, развивая и улучшая этот пример.
Вносите изменения так, как указано в книге, пытайтесь писать весь код самостоятельно и используйте примеры из репозитория в GitHub только для того, чтобы свериться или прояснить непонятные моменты.
Версии
Все примеры в этой книге проверены на версии Terraform 0.12.x, которая на момент написания является последним крупным обновлением. Поскольку Terraform — относительно новый инструмент, который все еще не достиг версии 1.0.0, вполне вероятно, что будущие выпуски будут содержать обратно несовместимые изменения и некоторые из рекомендуемых методик со временем поменяются и эволюционируют.
Я попытаюсь выпускать обновления как можно чаще, но проект Terraform движется очень быстро. Чтобы не отставать, вам самим придется прилагать определенные усилия. Чтобы не пропустить последние новости, статьи и обсуждения, связанные с Terraform и DevOps, посещайте сайт этой книги по адресу http://www.terraformupandrunning.com/ и подпишитесь на информационную рассылку (http://www.terraformupandrunning.com/#newsletter)!
Использование примеров кода
Эта книга предназначена для того, чтобы помочь вам решать ваши задачи. Вы можете свободно использовать примеры кода в своих программах и документации. Если вы не воспроизводите существенную часть кода, не нужно с нами связываться. Это, скажем, касается ситуаций, когда вы включаете в свою программу несколько фрагментов кода, которые приводятся в книге. Однако продажа или распространение CD с примерами из книг издательства O’Reilly требует отдельного разрешения. Если вы цитируете эту книгу с примерами кода при ответе на вопрос, разрешение не требуется. Но нужно связаться с нами, если хотите включить существенную часть приводимого здесь кода в документацию своего продукта.
Мы приветствуем, но не требуем отсылки на оригинал. Отсылка обычно состоит из названия, имени автора, издательства, ISBN. Например: «Terraform: инфраструктура на уровне кода», Евгений Брикман. Питер, 2020. 978-5-4461-1590-7.
Если вам кажется, что то, как вы обращаетесь с примерами кода, выходит за рамки добросовестного использования или условий, перечисленных выше, можете обратиться к нам по адресу permissions@oreilly.com.
Условные обозначения
В этой книге используются следующие типографические обозначения.
Курсив
Обозначает новые термины и важные моменты.
Рубленый
Обозначает URL, адреса электронной почты и элементы интерфейса.
Моноширинный шрифт
Используется в листингах кода, а также в тексте, обозначая такие программные элементы, как имена переменных и функций, базы данных, типы данных, переменные среды, операторы и ключевые слова, названия папок и файлов, а также пути к ним.
Жирный моноширинный шрифт
Обозначает команды или другой текст, который должен быть введен пользователем.
Курсивный моноширинный шрифт
Обозначает текст, вместо которого следует подставить пользовательские значения или данные, зависящие от контекста.
Этот значок обозначает примечание общего характера.
Этот значок обозначает предупреждение или предостережение.
Благодарности
Джош Падник
Без тебя эта книга не появилась бы. Ты тот, кто познакомил меня с Terraform, научил основам и помог разобраться со всеми сложностями. Спасибо, что поддерживал меня, пока я воплощал наши коллективные знания в книгу. Спасибо за то, что ты такой классный соучредитель. Благодаря тебе я могу заниматься стартапом и по-прежнему радоваться жизни. И больше всего я благодарен тебе за то, что ты хороший друг и человек.
O’Reilly Media
Спасибо за то, что выпустили еще одну мою книгу. Чтение и написание книг коренным образом изменили мою жизнь, и я горжусь тем, что вы помогаете мне делиться некоторыми из моих текстов с другими. Отдельная благодарность Брайану Андерсону за его помощь в подготовке первого издания в рекордные сроки и Вирджинии Уилсон, благодаря которой мне каким-то образом удалось поставить новый рекорд со вторым изданием.
Сотрудники Gruntwork
Не могу выразить, насколько я благодарен вам всем за то, что вы присоединились к нашему крошечному стартапу. Вы создаете потрясающее ПО! Спасибо, что удерживали компанию на плаву, пока я работал над вторым изданием этой книги. Вы замечательные коллеги и друзья.
Клиенты Gruntwork
Спасибо, что рискнули связаться с мелкой, неизвестной компанией и согласились стать подопытными кроликами для наших экспериментов с Terraform. Задача Gruntwork — на порядок упростить понимание, разработку и развертывание ПО. Нам не всегда это удается (в книге я описал многие из наших ошибок!), поэтому я благодарен за ваше терпение и желание принять участие в нашей дерзкой попытке улучшить мир программного обеспечения.
HashiCorp
Спасибо за создание изумительного набора инструментов для DevOps, включая Terraform, Packer, Consul и Vault. Вы улучшили мир DevOps, а заодно и жизни миллионов разработчиков.
Киф Моррис, Сет Варго, Маттиас Гис, Рокардо Феррейра, Акаш Махаян, Мориц Хейбер
Спасибо за вычитку первых черновиков книги и за большое количество подробных и конструктивных отзывов. Ваши советы улучшили эту книгу.
Читатели первого издания
Те из вас, кто купил первое издание, сделали возможным создание второго. Спасибо. Ваши отзывы, вопросы, предложения относительно исходного кода и постоянная жажда новостей послужили мотивацией примерно для 160 дополнительных страниц нового материала. Надеюсь, новый текст окажется полезным, и с нетерпением жду дальнейшего давления со стороны читателей.
Мама, папа, Лайла, Молли
Так получилось, что я написал еще одну книгу. Это, скорее всего, означает, что я проводил с вами меньше времени, чем мне бы хотелось. Спасибо за то, что отнеслись к этому с пониманием. Я вас люблю.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
1 Подробности ищите в руководствах по обновлению Terraform по адресу www.terraform.io/upgrade-guides/index.html.
2 Список провайдеров для Terraform можно найти на странице www.terraform.io/docs/providers/.
1. Почему Terraform
Программное обеспечение (ПО) нельзя считать завершенным, если оно просто работает на вашем компьютере, проходит тесты и получает одобрение при обзоре кода (code review). ПО не готово, пока вы не доставите его пользователю.
Доставка ПО включает в себя множество задач, которые необходимо решить для того, чтобы сделать код доступным для клиента. Это подразумевает запуск кода на боевых (production) серверах, обеспечение его устойчивости к перебоям в работе и всплескам нагрузки, защиту от злоумышленников. Прежде чем погружаться в мир Terraform, стоит сделать шаг назад и поговорить о роли этого инструмента в большом деле доставки программного обеспечения.
В этой главе мы подробно обсудим следующие темы.
• Появление DevOps.
• Что такое инфраструктура как код.
• Как работает Terraform.
• Сравнение Terraform с другими инструментами для работы с инфраструктурой как с кодом.
Появление DevOps
Если бы в недалеком прошлом вы захотели создать компанию — разработчик ПО, вам бы пришлось иметь дело с большим количеством оборудования. Для этого нужно было бы подготовить шкафы и стойки, поместить в них серверы, подключить кабели и провода, установить систему охлаждения, предусмотреть резервные системы питания и т. д. В те дни было логично разделять работников на две команды: разработчиков (developers, Devs), которые занимались написанием программ, и системных администраторов (operations, Ops), в чьи обязанности входило управление этим оборудованием.
Типичная команда разработчиков собирала свое приложение и «перебрасывала его через стену» команде сисадминов. Последние должны были разобраться с тем, как его развертывать и запускать. Большая часть этого процесса выполнялась вручную. Отчасти потому, что это неизбежно требовало подключения физического аппаратного обеспечения (например, расстановки серверов по стойкам и разводки сетевых кабелей). Но программные аспекты работы системных администраторов, такие как установка приложений и их зависимостей, часто выполнялись вручную путем выполнения команд на сервере.
До поры до времени этого было достаточно, но по мере роста компании начинали возникать проблемы. Обычно выглядело так: поскольку ПО доставлялось вручную, а количество серверов увеличивалось, выпуск новых версий становился медленным, болезненным и непредсказуемым. Команда сисадминов иногда допускала ошибки, и в итоге некоторые серверы требовали немного других настроек по сравнению со всеми остальными (это проблема, известная как дрейф конфигурации). Поэтому росло число программных ошибок. Разработчики пожимали плечами и отвечали: «У меня на компьютере все работает!» Перебои в работе становились все более привычными.
Команда администраторов, уставшая от вызовов в три часа ночи после каждого выпуска, решала снизить частоту выпуска новых версий до одного в неделю. Затем происходил переход на месячный и в итоге на полугодовой цикл. За несколько недель до полугодового выпуска команды пытались объединить все свои проекты, что приводило к большой неразберихе с конфликтами слияния. Никому не удавалось стабилизировать основную ветку. Команды начинали винить друг друга. Возникало недоверие. Работа в компании останавливалась.
В наши дни ситуация меняется коренным образом. Вместо обслуживания собственных вычислительных центров многие компании переходят в облако, пользуясь преимуществами таких сервисов, как Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP). Вместо того чтобы тесно заниматься оборудованием, многие команды системных администраторов проводят все свое время за работой с программным обеспечением, используя инструменты вроде Chef, Puppet, Terraform и Docker. Вместо расставления серверов по стойкам и подключения сетевых кабелей многие сисадмины пишут код.