terraform инфраструктура на уровне кода pdf

Книга «Terraform: инфраструктура на уровне кода»

Привет, Хаброжители! Книга предназначена для всех, кто отвечает за уже написанный код. Это относится к сисадминам, специалистам по эксплуатации, релиз-, SR-, DevOps-инженерам, разработчикам инфраструктуры, разработчикам полного цикла, руководителям инженерной группы и техническим директорам. Какой бы ни была ваша должность, если вы занимаетесь инфраструктурой, развертываете код, конфигурируете серверы, масштабируете кластеры, выполняете резервное копирование данных, мониторите приложения и отвечаете на вызовы в три часа ночи, эта книга для вас.

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

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

Первое издание вышло в 2017 году. В мае 2019-го я готовил второе издание и был очень удивлен тому, как все изменилось за пару лет! Эта книга по своему объему почти в два раза превосходит предыдущую и включает две полностью новые главы. Кроме того, существенно обновлены все оригинальные главы и примеры кода.

Если вы уже прочитали первое издание и хотите узнать, что изменилось, или вам просто интересно посмотреть, как эволюционировал проект Terraform, вот несколько основных моментов.

Отрывок. Как тестировать код Terraform

(вопросам автоматического тестирования в книге уделено далее гораздо больше внимания)

Мир DevOps полон разных страхов: все боятся допустить простой в работе, потерять данные или быть взломанными. При внесении любого изменения вы всегда спрашиваете себя, какие последствия оно будет иметь. Будет ли оно вести себя одинаково во всех окружениях? Вызовет ли оно очередной перебой в работе? И, если это случится, насколько вам придется задержаться на работе на этот раз, чтобы все исправить? По мере роста компании все больше ставится на кон, что делает процесс развертывания еще страшнее и повышает риск ошибок. Многие компании пытаются минимизировать этот риск за счет менее частых развертываний, но в итоге каждое отдельное развертывание становится более крупным и склонным к ошибкам.

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

В этой главе мы пройдемся по процессу тестирования инфраструктурного кода, как ручного, так и автоматического, с акцентом на последний.

Ручные тесты

Размышляя о том, как тестировать код Terraform, полезно провести некоторые параллели с тестированием кода, написанного на языках программирования общего назначения, таких как Ruby. Представьте, что вы пишете простой веб-сервер на Ruby в файле web-server.rb:

Этот код вернет ответ 200 OK с телом Hello, World для URL-адреса /; для любого другого адреса ответ будет 404. Как бы вы протестировали этот код вручную? Обычно для этого добавляют еще немного кода, чтобы запускать веб-сервер локально:

Если запустить этот файл в терминале, он загрузит веб-сервер на порте 8000:

Чтобы проверить работу этого сервера, можно воспользоваться браузером или curl:

Теперь представьте, что мы изменили этот код, добавив в него точку входа /api, которая возвращает 201 Created и тело в формате JSON:

Чтобы вручную протестировать этот обновленный код, нажмите Ctrl+C и перезагрузите веб-сервер, запустив скрипт еще раз:

Для проверки новой версии можно снова воспользоваться командой curl:

Основы ручного тестирования

Как будет выглядеть подобного рода ручное тестирование в Terraform? Например, из предыдущих глав у вас остался код для развертывания ALB. Вот фрагмент файла modules/networking/alb/main.tf:

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

Из этого следует ключевой вывод о тестировании № 1: тестирование кода Terraform не может проходить локально.

Это относится не только к Terraform, но и к большинству средств IaC. Единственный практичный способ выполнять ручное тестирование в Terraform — развернуть код в реальном окружении (то есть в AWS). Иными словами, самостоятельный запуск команд terraform apply и terraform destroy, которым вы занимались, читая книгу, — это и есть ручное тестирование в Terraform.

Это одна из причин, почему так важно иметь в папке examples каждого модуля простые в развертывании примеры (см. главу 6). Чтобы протестировать модуль alb, проще всего воспользоваться демонстрационным кодом, который вы создали в examples/alb:

Чтобы развернуть этот пример, нужно выполнить команду terraform apply, как вы это неоднократно делали:

В конце развертывания можно использовать такой инструмент, как curl, чтобы, к примеру, убедиться, что по умолчанию ALB возвращает 404:

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

Напомню: ALB возвращает 404 ввиду отсутствия в конфигурации других правил прослушивателя, а действие по умолчанию в модуле alb имеет ответ 404:

Итак, вы уже умеете запускать и тестировать свой код. Теперь можно приступить к внесению изменений. Каждый раз, когда вы что-то меняете (чтобы, например, действие по умолчанию возвращало 401), вам нужно использовать команду terraform apply, чтобы развернуть новый код:

Чтобы проверить новую версию, можно заново запустить curl:

Когда закончите, выполните команду terraform destroy, чтобы удалить ресурсы:

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

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

Очистка ресурсов после тестов

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

Вам как минимум следует создать в команде такую культуру, когда после окончания тестирования разработчики удаляют все, что они развернули, с помощью команды terraform destroy. Возможно, удастся найти инструменты для очистки лишних или старых ресурсов, которые можно запускать на регулярной основе (скажем, с помощью cron). Вот некоторые примеры для разных сред развертывания.

Запускается aws-nuke следующим образом:

Автоматические тесты

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

Существует три типа автоматических тестов.

Для Хаброжителей скидка 25% по купону — Terraform

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.

Источник

Terraform: новый подход к Infrastructure as code

Привет, коллеги! Пока блистательный Илон Маск вынашивает амбициозные планы терраформирования Марса, мы интересуемся новыми возможностями, связанными с парадигмой «Infrastructure as Code» и хотим предложить вам перевод статьи об одном из представителей «великолепной семерки» — Terraform. Книга Евгения Брикмана по теме неплохая, но ей скоро год, так что просим высказаться — хотите ли увидеть ее на русском языке

Слово Камалу Мархуби (Kamal Marhubi) из компании Heap.

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

Terraform и инфраструктура на уровне кода

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

Вот как, к примеру, в Terraform определяется инстанс EC2 с томом EBS:

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

Модель данных Terraform

В общей перспективе модель данных Terraform проста: Terraform управляет ресурсами, а у ресурсов есть атрибуты. Несколько примеров из мира AWS:

Не всякий ресурс Terraform – это ресурс AWS

Понять такую модель данных с ресурсами и атрибутами не столь сложно, однако, она может не вполне совпадать с API облачного провайдера. Фактически, единственный ресурс Terraform может соответствовать как одному, так и нескольким базовым объектам облачного провайдера – либо даже не соответствовать ни одному. Вот несколько примеров из AWS:

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

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

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

Мы ошиблись с выбором

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

До недавнего времени мы использовали обходной путь и заставляли Terraform синхронизироваться в несколько этапов:

Состояние Terraform: переходим к хирургии

Учитывая, что у нас добавлялось более тысячи ресурсов, мы определенно не собирались делать это вручную. Состояние Terraform хранится в формате JSON. Хотя, этот формат стабилен, в документации указано, что «непосредственно редактировать файлы с состоянием не рекомендуется». Нам бы все равно пришлось это делать, но мы хотели быть уверены, что делаем это верно. Мы решили не заниматься обратной разработкой формата JSON, а написали программу, которая использует внутренние элементы Terraform как библиотеку для считывания, изменения и записи. Это было не так просто, поскольку для всех из нас это была первая программа на Go, с которой довелось работать! Но мы считали, что необходимо убедиться: да мы не перепутаем в одну кучу все Terraform-состояния всех инстансов нашей базы данных.

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

Терраформируем аккуратно

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

Всегда готовьте план –out и следуйте этому плану

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

Для перебора изменений сделайте специальную роль IAM «только для чтения»

Работая с AWS, можно управлять в Terraform ролями IAM и соответствующими правами доступа. Роль в Terraform выглядит так:

В assume_role_policy просто выводится список пользователей, которые вправе принять эту роль.

Организовать такую роль оказалось гораздо легче, чем переписывать все состояние Terraform для использования aws_volume_attachment с томами нашей базы данных. Мы знали, что никаких изменений в инфраструктуре AWS не планируется – поменяться должно было лишь ее представление в Terraform. В конце концов, мы совершенно не собирались менять инфраструктуру – зачем же нам такая возможность?

Идеи на будущее

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

Еще один участок работы, где так хочется добиться легкости и безопасности – это рецензирование изменений, вносимых в инфраструктуру. На данном этапе при рецензировании мы просто копипастим вывод terraform plan как комментарий к обзору – и, когда вариант будет одобрен, вносим все изменения вручную.

Источник

Terraform инфраструктура на уровне кода pdf

Евгений Брикман

Terraform: инфраструктура на уровне кода

Научный редактор К. Русецкий

Переводчики О. Сивченко, С. Черников

Литературный редактор В. Байдук

Художник В. Мостипан

Корректоры Е. Павлович, Е. Рафалюк-Бузовская

Евгений Брикман

Terraform: инфраструктура на уровне кода. — СПб.: Питер, 2020.

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

Посвящается маме, папе, Лайле и Молли

Введение

Давным-давно в далеком-предалеком вычислительном центре древнее племя могущественных существ, известных как «сисадмины», вручную развертывало инфраструктуру. Каждый сервер, база данных (БД), балансировщик нагрузки и фрагмент сетевой конфигурации создавались и управлялись вручную. Это было мрачное и ужасное время: страх простоя, случайной ошибки в конфигурации, медленных и хрупких развертываний и того, что может произойти, если сисадмины перейдут на темную сторону (то есть возьмут отпуск). Но спешу вас обрадовать — благодаря движению DevOps у нас теперь есть замечательный инструмент: Terraform.

Terraform (https://www.terraform.io/) — это инструмент с открытым исходным кодом от компании HashiCorp. Он позволяет описывать инфраструктуру в виде кода на простом декларативном языке и развертывать ее/управлять ею в различных публичных облачных сервисах (скажем, Amazon Web Services, Microsoft Azure, Google Cloud Platform, DigitalOcean), а также частных облаках и платформах виртуализации (OpenStack, VMWare и др.) всего несколькими командами. Например, вместо того чтобы вручную щелкать кнопкой мыши на веб-странице или вводить десятки команд в консоль, вы можете воспользоваться следующим кодом и сконфигурировать сервер в AWS:

resource «aws_instance» «example» <

Чтобы его развернуть, введите следующее:

Благодаря своей простоте и мощи Terraform стал ключевым игроком в мире DevOps. Он позволяет заменить громоздкие, хрупкие и неавтоматизированные средства управления инфраструктурой на надежный автоматизированный инструмент, поверх которого вы можете объединить все остальные элементы DevOps (автоматическое тестирование, непрерывную интеграцию и непрерывное развертывание) и сопутствующий инструментарий (например, Docker, Chef, Puppet).

Прочитайте эту книгу, и вы сможете сразу приступить к работе с Terraform.

Начав с простейшего примера Hello, World, вы научитесь работать с полным стеком технологий (кластером серверов, балансировщиком нагрузки, базой данных), рассчитанным на огромные объемы трафика и крупные команды разработчиков, уже после прочтения лишь нескольких глав. Это практическое руководство не только научит принципам DevOps и инфраструктуры как кода (infrastructure as code, или IaC), но и проведет вас через десятки примеров кода, которые можно попробовать выполнить дома. Поэтому держите компьютер под рукой.

Дочитав книгу, вы будете готовы к работе с Terraform в реальных условиях.

Целевая аудитория книги

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

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

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

Источник

Новости

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

Первое издание вышло в 2017 году. В мае 2019-го я готовил второе издание и был очень удивлен тому, как все изменилось за пару лет! Эта книга по своему объему почти в два раза превосходит предыдущую и включает две полностью новые главы. Кроме того, существенно обновлены все оригинальные главы и примеры кода.

Если вы уже прочитали первое издание и хотите узнать, что изменилось, или вам просто интересно посмотреть, как эволюционировал проект Terraform, вот несколько основных моментов.

Отрывок. Как тестировать код Terraform

(вопросам автоматического тестирования в книге уделено далее гораздо больше внимания)

Мир DevOps полон разных страхов: все боятся допустить простой в работе, потерять данные или быть взломанными. При внесении любого изменения вы всегда спрашиваете себя, какие последствия оно будет иметь. Будет ли оно вести себя одинаково во всех окружениях? Вызовет ли оно очередной перебой в работе? И, если это случится, насколько вам придется задержаться на работе на этот раз, чтобы все исправить? По мере роста компании все больше ставится на кон, что делает процесс развертывания еще страшнее и повышает риск ошибок. Многие компании пытаются минимизировать этот риск за счет менее частых развертываний, но в итоге каждое отдельное развертывание становится более крупным и склонным к ошибкам.

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

В этой главе мы пройдемся по процессу тестирования инфраструктурного кода, как ручного, так и автоматического, с акцентом на последний.

Ручные тесты:

Автоматические тесты:

Ручные тесты

Размышляя о том, как тестировать код Terraform, полезно провести некоторые параллели с тестированием кода, написанного на языках программирования общего назначения, таких как Ruby. Представьте, что вы пишете простой веб-сервер на Ruby в файле web-server.rb:

Этот код вернет ответ 200 OK с телом Hello, World для URL-адреса /; для любого другого адреса ответ будет 404. Как бы вы протестировали этот код вручную? Обычно для этого добавляют еще немного кода, чтобы запускать веб-сервер локально:

Если запустить этот файл в терминале, он загрузит веб-сервер на порте 8000:

Чтобы проверить работу этого сервера, можно воспользоваться браузером или curl:

Теперь представьте, что мы изменили этот код, добавив в него точку входа /api, которая возвращает 201 Created и тело в формате JSON:

Чтобы вручную протестировать этот обновленный код, нажмите Ctrl+C и перезагрузите веб-сервер, запустив скрипт еще раз:

Для проверки новой версии можно снова воспользоваться командой curl:

Источник