Полезность таких инструментов IaaS Provisoning, как Terraform?

Question

У меня возникла небольшая путаница относительно всей идеи «Инфраструктура как код» или подготовки IaaS с такими инструментами, как Terraform.

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

Помимо Infrastructure as Code, являющейся «классной» альтернативой ручному выделению ресурсов в AWS console, я не понимаю, почему это на самом деле полезно.

Возьмем, к примеру, типичное развертывание веб-сайта с базой данных. Зачем мне вообще нужно запускать план Terraform после первоначальной подготовки этой инфраструктуры? Поскольку все, что мне нужно, подготовлено в моей учетной записи AWS, в каких случаях мне потребуется «повторно подготовить» эту инфраструктуру?

Согласно этому предположению, процесс подготовки всего, что мне нужно, является первым -загружено для начала, так зачем мне изучать инструменты, когда я могу просто нажать несколько кнопок на консоли AWS, когда я впервые развертываю свой веб-сайт?

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

Заранее спасибо!

Answer 1

• 1000 :

• Применяйте все те же принципы разработки, которые у вас есть при написании традиционного кода. Вы можете использовать комментарии, чтобы задокументировать свою инфраструктуру. Вы можете отслеживать все изменения и того, кто их сделал, используя систему контроля версий программного обеспечения (например, git).

• вы можете легко поделиться архитектура вашей инфраструктуры. Ваши VP C и ALB не работают? Просто опубликуйте свой код terraform в SO или поделитесь с коллегой для обзора. Это намного проще, чем делиться снимками экрана вашего VP C и ALB, когда это делается вручную.

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

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

• проверять изменения перед их выполнением. Ручное обновление вашей инфраструктуры может иметь катастрофические последствия из-за эффекта домино. Изменение одного может изменить / сломать многие другие компоненты вашей архитектуры. Используя инфраструктуру в виде кода, вы можете предварительно просмотреть изменения и хорошо понять возможные последствия, прежде чем вносить изменения.

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

Answer 2

Мне очень нравится ответ @ Marcin.

Вот некоторые дополнительные моменты из моего опыта:

• Что касается контроля версий программного обеспечения если вы может не только просматривать историю / авторов, выполнять проверку кода, но и рассматривать изменения инфраструктуры как функции продукта. Скажем, например, вы добавляете поддержку CDN в свое приложение, поэтому вам нужно внести некоторые изменения в свою инфраструктуру (для предоставления облачной службы CDN), приложение (для фактической поддержки и работы с CDN) и ваши конвейеры (для доставки статистики *). 1036 * в CDN, если вы используете этот подход). Если все изменения, связанные с этой новой функцией, будут в одной ветке - все изменения, связанные с функциями, будут прозрачны для всех в команде, и их можно будет легко отследить позже.

• Другое дело связанные с контролем версий - это возможность легко настраивать и уничтожать инфраструктуры для приложений обзора полуавтоматически, используя триггеры и возможности ваших инструментов CI / CD для автоматического и ручного тестирования. Можно даже запускать автоматические тесты для ваших изменений в объявлении инфраструктуры.

• Если вы работаете над несколькими похожими проектами или если вашему проекту требуется несколько похожих, но изолированные друг от друга среды, Ia C может помочь сэкономить бесчисленные часы подготовки и отслеживания всего. Хотя это не всегда серебряная пуля, но почти во всех случаях она помогает сэкономить время и избежать большинства случайных ошибок.

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