• Как развертывать обновления. Когда выходит новая версия контейнера Docker, наш код выкатывает три новые реплики, ждет, когда они станут работоспособными, и затем удаляет три старые копии.
Так много возможностей всего в нескольких строчках на YAML! Чтобы развернуть свое приложение в Kubernetes, нужно выполнить команду kubectlapply-fexample-app.yml. Чтобы выкатить обновления, вы можете отредактировать YAML-файл и снова запустить kubectlapply.
Средства инициализации ресурсов
В отличие от инструментов для управления конфигурацией, шаблонизации серверов и оркестрации, код которых выполняется на каждом сервере, средства инициализации ресурсов, такие как Terraform, CloudFormation и OpenStack Heat, отвечают за создание самих серверов. С их помощью можно создавать не только серверы, но и базы данных, кэши, балансировщики нагрузки, очереди, системы мониторинга, настройки подсетей и брандмауэра, правила маршрутизации, сертификаты SSL и почти любой другой аспект вашей инфраструктуры (рис. 1.5).
Рис. 1.5. Средства инициализации ресурсов можно использовать в связке с вашим облачным провайдером, чтобы создавать серверы, базы данных, балансировщики нагрузки и любые другие элементы вашей инфраструктуры
Например, следующий код развертывает веб-сервер с помощью Terraform:
resource "aws_instance" "app" {
instance_type = "t2.micro"
availability_zone = "us-east-2a"
ami = "ami-0c55b159cbfafe1f0"
user_data = <<-EOF
#!/bin/bash
sudo service apache2 start
EOF
}
Не нужно волноваться, если вам непонятны какие-то элементы данного синтаксиса. Пока что сосредоточьтесь на двух параметрах.
•ami определяет идентификатор образа AMI, который нужно развернуть на сервере. Вы можете присвоить ему ID образа, собранного из шаблона Packer web-server.json в подразделе «Средства оркестрации» на с. 35. В нем содержатся PHP, Apache и исходный код приложения.
•user_data. Этот bash-скрипт выполняется при загрузке веб-сервера. В предыдущем примере этот скрипт используется для запуска Apache.
Иными словами, это демонстрация того, как объединить инициализацию ресурсов и шаблонизацию серверов, что является распространенной практикой в неизменяемой инфраструктуре.
Преимущества инфраструктуры как кода
Теперь, когда вы познакомились со всевозможными разновидностями IaC, можно задаться вопросом: зачем нам это нужно? Зачем изучать целую кучу новых языков и инструментов, обременяя себя еще большим количеством кода, который нужно поддерживать?
Дело в том, что код довольно мощный. Усилия, которые идут на преобразование ручных процессов в код, вознаграждаются огромным улучшением ваших возможностей по доставке ПО. Согласно докладу о состоянии DevOps за 2016 год (bit.ly/31kCUYX), организации, применяющие такие методики, как IaC, развертывают код в 200 раз чаще и восстанавливаются после сбоев в 24 раза быстрее, а на реализацию новых функций уходит в 2555 раз меньше времени.
Когда ваша инфраструктура определена в виде кода, можно существенно улучшить процесс доставки ПО, используя широкий диапазон методик из мира программирования. Это дает преимущества.
•Самообслуживание. В большинстве команд, которые развертывают код вручную, мало сисадминов (часто один), и только они знают все магические заклинания для выполнения развертывания и имеют доступ к промышленной среде. Это становится существенным препятствием на пути роста компании. Если же ваша инфраструктура определена в виде кода, весь процесс развертывания можно автоматизировать, благодаря чему разработчики смогут доставлять свой код тогда, когда им это нужно.
• Скорость и безопасность. Автоматизация значительно ускоряет процесс развертывания, потому что компьютер может выполнить все его этапы куда быстрее человека. При этом повышается безопасность, так как автоматический процесс будет более последовательным, воспроизводимым и устойчивым к ошибкам с человеческим фактором.
• Документация. Вместо того чтобы держать состояние инфраструктуры в голове одного сисадмина, вы можете описать его в исходном файле, который каждый сможет прочитать. Иными словами, IaC играет роль документации, позволяя любому работнику компании понять, как все работает, даже если сисадмин уходит в отпуск.
• Управление версиями. Исходные файлы IaC можно хранить в системе управления версиями, благодаря чему в журнале фиксаций кода будет записана вся история вашей инфраструктуры. Это очень помогает при отладке, так как в случае возникновения проблемы всегда можно первым делом открыть журнал и посмотреть, что именно поменялось в вашей инфраструктуре. Вслед за этим проблему можно решить за счет простого отката к предыдущей версии кода IaC, в которой вы уверены.
• Проверка. Если состояние вашей инфраструктуры описано в файле, при каждом его изменении можно устраивать разбор кода, запускать набор автоматических тестов и прогонять его через средства статического анализа. Опыт показывает, что все это значительно уменьшает вероятность дефектов.
• Повторное использование. Вы можете упаковать свою инфраструктуру в универсальные модули, и вместо того, чтобы производить развертывание каждого продукта в каждой среде с нуля, у вас будет возможность использовать в качестве основы известные, задокументированные и проверенные на практике компоненты8.
•Радость. Есть еще одна очень важная причина, почему вы должны использовать IaC, которую часто упускают из виду: радость. Развертывание кода и управление инфраструктурой вручную — рутинный и утомительный процесс. Разработчики и сисадмины терпеть не могут такого рода работу, поскольку в ней нет никакого творчества, вызова или признания. Вы можете идеально развертывать код на протяжении месяцев, и никто даже не заметит, пока в один прекрасный день вы не напортачите. Это создает напряженную и неприятную обстановку. IaC предлагает лучшую альтернативу, которая позволяет компьютерам и людям делать то, что они умеют лучше всего: автоматизировать и, соответственно, писать код.
Теперь вы понимаете, почему IaC важна. Следующий вопрос: является ли Terraform лучшим средством IaC именно для вас? Чтобы на это ответить, мы кратко рассмотрим принцип работы Terraform, а затем сравним его с другими популярными продуктами в этой области, такими как Chef, Puppet и Ansible.
Как работает Terraform
Вот обобщенная и немного упрощенная картина того, как работает Terraform. Terraform — это инструмент с открытым исходным кодом от компании HashiCorp, написанный на языке программирования Go. Код на Go компилируется в единый двоичный файл (если быть точным, по одному файлу для каждой поддерживаемой операционной системы) с предсказуемым названием terraform.
Этот файл позволяет развернуть инфраструктуру прямо с вашего ноутбука или сборочного сервера (либо любого другого компьютера), и для всего этого не требуется никакой дополнительной инфраструктуры. Все благодаря тому, что внутри исполняемый файл terraform делает от вашего имени API-вызовы к одному/нескольким провайдерам, таким как AWS, Azure, Google Cloud, DigitalOcean, OpenStack и т. д. Это означает, что Terraform использует инфраструктуру, которую эти провайдеры предоставляют для своих API-серверов, а также их механизмы аутентификации, которые вы уже применяете (например, ваши API-ключи для AWS).
Но откуда Terraform знает, какие API-вызовы нужно делать? Для этого вам необходимо создать текстовые файлы с конфигурацией, в которых описывается, какую инфраструктуру вы хотите создать. В концепции «инфраструктура как код» эти файлы играют роль кода. Вот пример конфигурации Terraform:
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
resource "google_dns_record_set" "a" {
name = "demo.google-example.com"
managed_zone = "example-zone"
type = "A"
ttl = 300
rrdatas = [aws_instance.example.public_ip]
}
Даже если вы никогда раньше не видели код Terraform, не должно быть особых проблем с тем, чтобы его понять. Этот фрагмент заставляет Terraform выполнить API-вызовы к двум провайдерам: к AWS, чтобы развернуть там сервер, и к Google Cloud, чтобы создать DNS-запись, которая указывает на IP-адрес сервера из AWS. Terraform позволяет использовать единый простой синтаксис (который вы изучите в главе 2) для развертывания взаимосвязанных ресурсов в нескольких разных облаках.
Вы можете описать всю свою инфраструктуру (серверы, базы данных, балансировщики нагрузки, топологию сети и т. д.) в конфигурационных файлах Terraform и сохранить их в системе управления версиями. Затем эту инфраструктуру можно будет развернуть с помощью определенных команд, таких как terraformapply. Утилита terraform проанализирует ваш код, преобразует его в последовательность API-вызовов к облачным провайдерам, которые в нем заданы, и выполнит эти API-вызовы от вашего имени максимально эффективным образом (рис. 1.6).
Рис. 1.6. Terraform — это утилита, которая преобразует содержимое ваших конфигурационных файлов в API-вызовы к облачным провайдерам
Если кто-то в вашей команде хочет изменить инфраструктуру, то вместо того, чтобы делать это вручную прямо на серверах, они редактируют конфигурационные файлы Terraform, проверяют их с помощью автоматических тестов и разбора кода, фиксируют обновленный код в системе управления версиями и затем выполняют команду terraformapply, чтобы сделать необходимые для развертывания изменений API-вызовы.
Прозрачная переносимость между облачными провайдерами
Поскольку Terraform поддерживает множество разных облачных провайдеров, часто возникает вопрос: обеспечивает ли этот инструмент прозрачную переносимость между ними? Например, если вы использовали Terrafo