[Terraform + SaltStack] Готовим PrestoDB кластер в скороварке (Часть #1)

Что здесь интересного?

Рецепт приготовления вкусного и полезного PrestoDB кластера используя скороварку на базе Terraform и SaltStack в публичном облаке AWS. Рассмотрим подробно нюансы подготовки к работе самой скороварки, необходимые шаги для правильного приготовления самого блюда и, естественно, немножко расскажем о потреблении готового блюда. Эту часть можно использовать как учебный материал по Terraform.

итак, приступим:

Ингредиенты для рецепта

• Terraform — 1 шт.
• SaltStack — 1 мастер и 1+ миньен
• PrestoDB — 1 координатор и 1+ воркер
• AWS аккаунт — 1 шт.
• Смекалка и напильник — по вкусу

Рассмотрим ингредиенты подробнее: (без правил их приготовления)
1. Terraform — Замечательный инструмент от парней из Hashicorp (они же сделали такие, весьма полезные, штуки как Vagrant, Consul, Packer, Vault и др.) используемый для создания и модификации инфраструктур в различных облачных и не только окружениях.
2. SaltStack — Инструмент для автоматизированного конфигурирования и настройки серверов. Ваш покорный слуга уже писал об этом здесь и тут.
3. PrestoDB — Надстройка над Big Data провайдерами для возможности делать запросы к ним на родном и понятном SQL. Разработана ребятами из Facebook, которые перевели ее в статус OSS за что им огромное спасибо.
4. AWS (или любое другое публичное/приватное облако, к примеру: GCE или OpenStack) из списка поддерживаемых Terraform в котором будет в последствии работать наш PrestoDB кластер. Мы будем использовать AWS т.к. он наиболее распространен (среди public cloud платформ) и понятен многим без массы дополнительных пояснений.
5. В статье будут описаны лишь базовые принципы работы связки указанных продуктов, и некоторые хитрости для облегчения процесса, но я не буду подробно останавливаться на нюансах работы того или иного компонента — по каждому из них в принципе можно написать книгу. Потому адаптировать указанные приемы используя голову очень приветствуется. И еще — не пишите в комментариях, что что-то настроено не оптимально (в частности PrestoDB) — это не та цель которую я преследую.

Готовим скороварку!

В любом кулинарном рецепте есть умолчание о том, что сковородки и кастрюли уже готовы к приготовлению, но в нашем случае правильная подготовка скороварки (Terraform+SaltStack) является чуть-ли не на 80% залогом успешного приготовления блюда.
Итак — начнем с Terraform. Ну есть же CloudFormation для AWS или SaltCloud от создателей SaltStack так почему же выбран именно Terraform? Основная фишка Terraform в его простоте и понятном DSL — для создания инстанса (или 10ти) необходимо и достаточно такого описания (подразумеваем Terraform скачан и находится в пределах $PATH):

provider "aws" {
        access_key = "XXXXXXXXXXXXXXXXXXXXX" # AWS IAM key 
        secret_key = "******************************************" # AWS IAM secret
        region = "us-east-1" # region used to create resources
}

resource "aws_instance" "example_inst" {
        ami = "ami-6d1c2007" # CentOS 7 AMI located in US-East-1
        instance_type = "t2.medium" 
        count = "1" # or "10" can be used for parallel creation
        vpc_security_group_ids = [ "default-sg" ] # some security group with at least 22 port opened 
        key_name = "secure_key" # pre created AWS E2 key pair
        subnet_id = "sub-abcdef123" # AWS VPC subnet 
}

и простой последовательности команд:

terraform plan
terraform apply

описательная часть вполне понятна и, мне кажется, не требует пояснений для тех, кто знаком с AWS. Подробнее про доступные AWS ресурсы тут. Конечно же подразумеваем, что AWS аккаунт, ключи которого указаны в Terraform конфигурации, имеет привилегии на создание необходимых ресурсов.
Собственно самое интересное кроется в вызовах самого Terraform — terraform plan — делает «прикидку» того, что необходимо сделать с последнего состояния (в нашем примере — надо создать новый инстанс) и показывает какие ресурсы будут созданы, удалены или модифицированы, apply — собственно запустит процесс создания запланированных ресурсов. В случае если Terraform уже запускался и Вы изменили конфигурацию (скажем, добавили инстансов) на этапе планирования будет показано какие недостающие ресурсы будут созданы и apply может создать недостающие.

terraform destroy

поможет полностью убрать все ресурсы созданные при помощи Terraform (учитываются находящиеся в текущем каталоге .tfstate файлы, хранящие описание состояние созданной инфраструктуры).
Важный момент, о котором не стоит забывать — terraform в большинстве случаев не будет модифицировать уже имеющиеся ресурсы — он просто удалит старые и пересоздаст заново. Это значит, к примеру, что если вы создали инстанс типа t2.medium и потом поменяли конфигурацию указав новый тип для инстанса, скажем m4.xlarge, то при запуске apply Terraform сначала уничтожит ранее созданный, а потом создаст новый. Это может показаться странным для пользователей AWS (можно было остановить инстанс, поменять его тип и запустить заново не потеряв при этом данных на диске) но это сделано для предоставления одинаково прогнозируемого поведения на всех платформах. И еще одно: Terraform не умеет (да и не должен уметь по своей природе) контролировать ресурсы во время их жизненного цикла — это значит, что Terraform не предоставляет команды типа stop или reboot для созданных с его помощью инстансов — Вы должны использовать другие средства для управления созданной инфраструктурой.
Terraform предоставляет прекрасный набор функционала доступный в своем DSL — это переменные (https://www.terraform.io/docs/configuration/variables.html), интерполяторы (необходимы для итерирования, модификации переменных), модули и т.д. Вот один из примеров использования всего этого:

# Cluster shortname
variable cluster_name { default = "example-presto" }

# Count of nodes in cluster
variable cluster_size { default = 3 }

# Default owner for all nodes
variable cluster_owner { default = "user@example.com" }

# Default AWS AMI to use for cluster provisioning
variable cluster_node_ami { default = "ami-6d1c2007" }

# Default AWS type to use for cluster provisioning
variable cluster_node_type { default = "t2.large" }

# Defualt VPC subnet
variable cluster_vpc_subnet { default = "subnet-da628fad" }

# Default Security group to apply to instances
variable cluster_sg { default = "sg-xxxxxxx" }

# Default KeyPair to use for provisioning
variable cluster_keyname { default = "secure_key" }

# Cluster worker nodes
resource "aws_instance" "worker_nodes" {
        
        ami = "${var.cluster_node_ami}"
        instance_type = "${var.cluster_node_type}"
        count = "${var.cluster_size - 1}" # one node will be used for coordinator
        vpc_security_group_ids = [ "${var.cluster_sg}" ]
        key_name = "${var.cluster_keyname}"
        subnet_id = "${var.cluster_vpc_subnet}"

        disable_api_termination = true

        tags {
                Name = "${var.cluster_name}-cluster-worker-${format("%02d", count.index+1)}"
                Owner = "${var.cluster_owner}"
                Purpose = "PrestoDB cluster '${var.cluster_name}' node ${format("%02d", count.index+1)}"
        }
}

тут пример использования переменных, арифметических операций над ними, интерполяция с помощью format, использование индекса текущего элемента (если создается несколько однотипных инстансов), а также тегирование ресурсов.
Но только лишь создания/уничтожения инстансов не достаточно — необходимо их еще как-то инициализировать (скопировать файлы, установить и настроить специфичный софт, обновить систему, провести конфигурацию кластера и т.д.) для этого Terraform вводит понятие Provisioners. К основным из них относятся file, remote-exec, chef и null-resource. Типичными операциями являются копирование файлов и запуск скриптов на удаленном инстансе.
Вот предыдущий пример с включенными операциями провиженинга:

# Localy stored SSH private key filename
variable cluster_keyfile { default = "~/.ssh/secure_key.pem" }

# Cluster worker nodes
resource "aws_instance" "worker_nodes" {
        
        ami = "${var.cluster_node_ami}"
        instance_type = "${var.cluster_node_type}"
        count = "${var.cluster_size - 1}" # one node will be used for coordinator
        vpc_security_group_ids = [ "${var.cluster_sg}" ]
        key_name = "${var.cluster_keyname}"
        subnet_id = "${var.cluster_vpc_subnet}"

        disable_api_termination = true

        tags {
                Name = "${var.cluster_name}-cluster-worker-${format("%02d", count.index+1)}"
                Owner = "${var.cluster_owner}"
                Purpose = "PrestoDB cluster '${var.cluster_name}' node ${format("%02d", count.index+1)}"
        }

        # Copy bootstrap script
        provisioner "file" {
                source = "bootstrap-script.sh"
                destination = "/tmp/bootstrap-script.sh"
                connection {
                        type = "ssh"
                        user = "centos"
                        private_key = "${file("${var.cluster_keyfile}")}"
                }
        }

        # Running provisioning commands
        provisioner "remote-exec" {
                inline = [
                        "yum -y update",
                        "sudo sh /tmp/bootstrap-script.sh"
                ]
                connection {
                        type = "ssh"
                        user = "centos"
                        private_key = "${file("${var.cluster_keyfile}")}"
                }
        }
}

Основное замечание — указание информации о соединении к удаленному хосту — для AWS это чаще всего доступ по ключу — потому Вы должны указать где именно этот ключ лежит (для удобства была введена переменная). Обратите внимание, что атрибут private_key в секции connection не может принимать путь к файлу (только ключ текстом) — вместо этого используется интерполятор $file{} который открывает файл на диске и возвращает его содержимое.
Мы добрались до создания простого кластера состоящего из нескольких инстансов (не будем вдаваться в подробности содержимого файла bootstrap-script.sh — положим, что там прописана установка необходимого софта). Давайте рассмотрим, как в нашей скороварке делать кластера с выделенным мастером. В общем будем полагать, что worker ноды кластера должны знать где находится master нода для того, чтобы в ней зарегистрироваться и в дальнейшем получать задачи (давайте оставим всякие вкусности типа Raft и Gossip протоколы для установления мастера и распространения информации в кластере для других статей) — для простоты — положим worker должен знать ip адрес master-а. Как это реализовать в Terraform? Для начала надо создать отдельный инстанс для master-а:

resource "aws_instance" "master_node" {
        ami = "${var.cluster_node_ami}"
        instance_type = "${var.cluster_node_type}"
        count = "1"

        <...skipped...>

        provisioners {
        <...skipped...>
        }
}

затем, добавим зависимость в worker ноды:

# Clurter worker nodes
resource "aws_instance" "worker_nodes" {
        depends_on = ["aws_instance.master_node"] # dependency from master node introduced
        ami = "${var.cluster_node_ami}"
        instance_type = "${var.cluster_node_type}"
        count = "${var.cluster_size - 1}" # one node will be used for coordinator
        
        <...skipped...>
}

модификатор ресурса depends_on можно использовать для задания порядка выполнения задач по созданию инфрастуктур — Terraform не будет создавать worker ноды до тех пор пока не будет полностью создана master нода. Как видно из примера в качестве зависимости(тей) можно указывать список конструируемый из типа ресурса с указанием через точку его имени. В AWS Вы можете создавать не только инстансы, но и VPC, сети и т.д. — их нужно будет указывать как зависимости для использующих VPC ресурсов — это будет гарантировать правильный порядок создания.
Но, продолжим с передачей адреса master ноды всем worker нодам. Для этого Terraform предоставляет механизм ссылок на раннее созданные ресурсы — т.е. вы можете просто извлечь информацию о ip адресе master ноды в описании worker-а:

# Clurter worker nodes
resource "aws_instance" "worker_nodes" {
        depends_on = ["aws_instance.master_node"] # dependency from master node introduced
        ami = "${var.cluster_node_ami}"
        instance_type = "${var.cluster_node_type}"
        count = "${var.cluster_size - 1}" # one node will be used for coordinator
        
        <...skipped...>

       # Running provisioning commands
        provisioner "remote-exec" {
                inline = [
                        "yum -y update",
                        "sudo sh /tmp/bootstrap-script.sh ${aws_instance.master_node.private_ip}" # master-ip passed to script
                ]
                connection {
                        type = "ssh"
                        user = "centos"
                        private_key = "${file("${var.cluster_keyfile}")}"
                }
        }
}

т.е. при помощи переменных вида ${aws_instance.master_node.private_ip} можно получить доступ к почти любой информации о ресурсе. В данном примере подразумеваем, что bootstrap-script.sh может принимать в качестве параметра адрес master ноды и использовать его в последствии для внутреннего конфигурирования.
Иногда не достаточно и таких связей, — к примеру, необходимо вызвать какие-то скрипты на стороне master ноды после подключения worker нод (принять ключи, запустить init задачи на worker нодах и т.п.) для этого есть механизм который в Terraform называется null-resource — это fake ресурс который с помощью механизма зависимостей (см. выше) может быть создан после того, как будут созданы все master и worker ноды. Вот пример такого ресурса:

resource "null_resource" "cluster_provision" {
        depends_on = [
                "aws_instance.master_node",
                "aws_instance.worker_nodes"
        ]

        # Changes to any instance of the workers' cluster nodes or master node requires re-provisioning
        triggers {
                cluster_instance_ids = "${aws_instance.master_node.id},${join(",", aws_instance.worker_nodes.*.id)}"
        }

        # Bootstrap script can run only on the master node
        connection {
                host = "${aws_instance.master_node.private_ip}"
                type = "ssh"
                user = "centos"
                private_key = "${file("${var.cluster_keyfile}")}"
        }

        provisioner "remote-exec" { 
                inline = [
                        <... some after-provision scripts calls on master node...>
                ]
        }
}

небольшое пояснение:
1. depends_on — мы указываем список тех ресурсов, которые должны быть готовы заранее.
2. triggers — формируем стоку (id всех инстансов через запятую, в нашем случае) изменение которой вызовет выполнение всех указанных в этом ресурсе провизионеров.
3. указываем на каком инстансе нужно выполнить скрипты провизионинга указанные в этом ресурсе в секции connection.

Если Вам нужно совершить несколько шагов на разных серверах — создавайте несколько null-resource с указанием необходимых зависимостей.

В целом, описанного будет достаточно для создания достаточно сложных инфрастурктур с помощью Terraform.
Вот еще несколько важных советов для тех, кто любит учиться на чужих ошибках:
1. Не забывайте бережно хранить .tfstate файлы в которых Terraform хранит последнее состояние созданной инфрастуркутуры (ко всему — это json файл, который можно использовать как исчерпывающий источник информации о созданных ресурсах)
2. Не меняйте созданные при помощи Terraform ресурсы вручную (используя консоли управления самим сервисами и другие внешние фреймворки) — при следующем запуске plan & apply вы получите пересоздание не соответствующего текущему описанию ресурса, что будет весьма неожиданно и часто плачевно.
3. Старайтесь сначала оттестировать свои конфигурации на небольших по размеру инстансах / небольшом их количестве, — много ошибок очень тяжело отловить в ходе создания конфигураций, а встроенный в Terraform валидатор покажет только синтаксические ошибки (и то не все).

Во второй части рассмотрим продолжение приготовления к работе скороварки — опишем как положить на верх созданной инфраструктуры SaltStack master + minions чтобы поставить PrestoDB.