Автор: Даже не знаю, как так получилось, но даже регулярно пересекаясь с Google Cloud Platform последние два года, я абсолютно упустил тот факт, что в GCP есть свой собственный инструмент для автоматизации развёртывания инфраструктуры: создания виртуальных машин, аккаунтов, сетей и прочего. Но он реально есть! В главном меню даже есть ссылка.
Инструмент называется Deployment Manager и он может автоматически создать практически всё, что есть Google Cloud. Прямо с одной команды. Так как DM разрабатывал Гугл, то у первого весьма извилистая кривая обучения, не всегда свежая документация, и иногда неочевидные логика. Но штука работает. Так как до этого я в основном автоматизировал развёртывание приложений от хоста и вверх — через всякие Vagrant, Ansible, docker-compose или kubectl, по посмотреть, как делать первую половину задачи — от хоста и вниз, — будет весьма интересно.
Как это работает
Принцип в чём-то похож на тот, что используется в docker-compose или Ansible. Мы задаём файл конфигурации, который описывает инфраструктуру приложения — виртуальные машины, сети, файрволы и остальное, а Deployment Manager из этого файла их и создаёт. Так как он относится к конфигурации как единому юниту развёртывания — «деплойменту», то позже по нему можно запросить статус, обновить какие-то узлы, или даже удалить целиком.
Что интересно (но совсем не удивительно), DM не станет создавать, например, новые виртуальные машины, если эти машины уже есть. Это поведение по умолчанию, его можно переопределить, и оно отлично иллюстрирует концепцию декларативной «желаемой конфигурации», а не императивного «сделай вот так». С этим поведением, правда, может выйти и косяк. Например, если два деплоймента создают виртуальные машины с одинаковым именем, то тот, кто пришёл последним, свою машину не создаст, а вместо этого попытается отдолжить её у товарища. Дебагить такие штуки — очень увлекательно.
Простой пример конфигурации деплоймента
Вот, например, как можно декларативно создать виртуальную машину:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
resources: - name: tiny-vm type: compute.v1.instance properties: zone: us-central1-a machineType: zones/us-central1-a/machineTypes/f1-micro disks: - deviceName: boot type: PERSISTENT boot: true autoDelete: true initializeParams: sourceImage: projects/ubuntu-os-cloud/global/images/family/ubuntu-1804-lts networkInterfaces: - network: global/networks/default |
Если перед этим мы где-тто установили и настроили Cloud SDK, а гугловый Deployment Manager API включён (что очень часто случается по умолчанию), то из командной строки эту конфигурацию можно отправить прямиком в облако:
|
1 2 3 4 5 6 7 |
gcloud deployment-manager deployments \ create my-deployment \ --config simple-config.yaml # ... # Create operation operation-1533697749330-572e3d58aa851-2623ddda-996fe75b completed successfully. # NAME TYPE STATE ERRORS INTENT # tiny-vm compute.v1.instance COMPLETED [] |
Смотрим на результаты
А теперь мы можем убедиться, что деплоймент удался. Во-первых, посмотрим, что он реально создался:
|
1 2 3 |
gcloud deployment-manager deployments list # NAME LAST_OPERATION_TYPE STATUS DESCRIPTION MANIFEST ERRORS # my-deployment insert DONE manifest-1533697749667 [] |
А во-вторых, проверим, что созданная им виртуальная машина тоже где-то рядом:
|
1 2 3 |
gcloud compute instances list # NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS # tiny-vm us-central1-a f1-micro 10.128.0.2 35.184.94.132 RUNNING |
Небольшое улучшение: добавляем машине внешний IP
Вот что можно сделать лучше. В такой конфигурации у виртуальной машины не будет внешней айпишки, так что все входящие соединения из внешней, не внутренней гугловой сети, туда не пройдут. В том числе это касается и попыток зайти на VM по SSH.
Исправить это очень легко. Нужно всего-лишь добавить такой вот accessConfig в networkInterfaces, и все разрешённые файрволом соединения смогут пройти. Если VM создавалась в дефолтной сети, то SSH будет разрешён по-умолчанию.
|
1 2 3 4 5 6 |
# ... networkInterfaces: - network: global/networks/default accessConfigs: - name: External NAT type: ONE_TO_ONE_NAT |
Более реалистичный пример
Создавать виртуалки по одиночке очень здорово для блог-постов, но для реального мира этого маловато. В нормальной жизни скорее всего придётся создавать сразу несколько ресурсов. Какие-то из них будут ссылаться друг на друга, и поэтому в деплойменте появятся явные и неявные зависимости, а это значит, что создавать их нужно по очереди и в определённом порядке. Так как Deployment Manager создаёт ресурсы параллельно и все сразу, то эту иерархию и очерёдность надо будет как-то обозначить.
Есть как минимум два способа это сделать: через метаданные и через ссылки.
Явные зависимости через метаданные
Это самый простой, но по моему мнению немного брутфорсный способ задать иерархию. Например, если нам нужно создать сеть и подключённую к ней виртуальную машину, то обозначить очерёдность «сначала создай сеть, потому машину» можно вот так:
|
1 2 3 4 5 6 7 8 9 10 |
resources: - name: not-that-tiny-network type: compute.v1.network # ... - name: tiny-vm type: compute.v1.instances metadata: dependsOn: - not-that-tiny-network # ... |
С другой стороны, если один облачный ресурс зависит от другого, то скорее всего ему нужно будет знать какие-то из атрибутов этого ресурса: имя, IP адрес, ссылку, или что-нибудь ещё. Намного разумнее было бы напрямую задать ссылку на этот атрибут, и таким образом сделать иерархию может менее явной, но зато более разумной.
Зависимости через ссылки
Посмотрим на такой пример. Допустим, мы хотим создать виртуальную машину, подключённую к отдельной сети, и в которую разрешён SSH. В терминологии GCP нам нужно будет создать три ресурса: сеть, правило в файрволе и виртуальную машину. А именно, сначала сеть, а уже потом всё остальное. Чтобы объяснить это DM’у, можно расставить вот такие ссылки-зависимости:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
resources: - name: tiny-vm # A VM type: compute.v1.instance properties: zone: us-central1-a machineType: zones/us-central1-a/machineTypes/f1-micro disks: - deviceName: boot type: PERSISTENT boot: true autoDelete: true initializeParams: sourceImage: projects/ubuntu-os-cloud/global/images/family/ubuntu-1804-lts networkInterfaces: - network: $(ref.my-network.selfLink) accessConfigs: - name: External NAT type: ONE_TO_ONE_NAT - name: my-network # A network type: compute.v1.network properties: IPv4Range: 10.0.0.1/16 - name: allow-inbound-ssh # A firewall rule type: compute.v1.firewall properties: network: $(ref.my-network.selfLink) sourceRanges: - 0.0.0.0/0 allowed: - IPProtocol: tcp ports: - 22 |
Когда мы отправим эту конфигурацию в облако, то уже через UI будет очень заметно, что ресурсы создаются по очереди:
Через пару секунд:
Ну и конечно можно проверить, что VM действительно подключена к новой сети, и SSH-правило для файрвола тоже там:
Заключение
Обычно к концу во таких экспериментов в новыми инструментами у меня появляется слабо выраженный стокгольмский синдром, и они мне начинают нравиться вне зависимости от того, хороши они, или нет. И сейчас вот именно такой случай.
Deployment Manager — вполне прикольный. Да, с ним немного тяжело начать, потому что внятных примеров для него как-то не особо, да и те, что есть, не всегда работают с текущей версией гуглового API. Да, чтобы найти ответы на некоторые очень очевидные вопросы, вроде какие конфигурационные свойства можно задавать, или как проверить правильность схемы шаблона, нужно делать неожиданно много Гугла. Но пока мне удавалось найти хоть что-то, так что жить можно.
Сейчас мне интересно, насколько DM пересекается по фичам с Terraform, который работает в том же поле. По ощущениям, DM будет проигрывать. Хотя кто его знает, с Terraform я ведь ещё не работал. Но, думаю, прежде чем соваться туда, стоит посмотреть на ещё парочку интересных штук от Deployment Manager, благо они там есть.
