Как вы помните, мне пришлось немало повозиться с десятком разных способов развертывания DCOS.

Чего я добивался? Я искал способ развернуть кластер, который можно очень легко и без лишних телодвижений увеличивать, уменьшать и, что самое важное, обновлять до последней версии - причем желательно автоматически.

CloudFormation не решал моей проблемы, дефолтный Bootstrap метод тоже (много надо делать руками). В итоге на встрече с командой шеф велел не заморачиваться апгрейдом. Мы можем себе позволить делать это руками (DCOS выпускает новую версию в лучшем случае раз в полгода), а самое важное это отказоустойчивость агентов, потому что customer impact.

Так что вот вам еще совет - не надо стремиться обеспечить 100% uptime системам, которые не влияют на KPI и SLA,

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

У шаблонов DCOS на Terraform и CloudFormation есть две большие разницы. Если CF нужен строго для ознакомительных целей, то Terraform был собран фанатами и поддерживается, собственно, самими фанатами. Ребята потратили немало времени, чтобы это собрать, обкатать на разных платформах, и обновляют его с каждой новой версией.

Запустить кластер мне удалось с полпинка с минимальным количеством ошибок. Не смотря на то, что я не пользовался Terraform раньше и старался держаться подальше от продуктов Hashicorp по User Experience соображением, я заметил, что Terraform обладает неоспоримым преимуществом перед CloudFormation.

Когда вы создаете CF стек, для того чтобы прогнать его еще раз, вам нужно что-то изменить - либо в самом стеке, либо в его параметрах. При попытке собрать уже собранный стек еще раз, CF пошлет вас куда подальше (и будет прав). Это правильная политика, но если вы затем ручками удалите какой-нибудь ресурс, то прогнать стек еще раз не удастся. В интернете люди предлагают добавить параметр инкремента и обновлять его каждый раз, когда захочется повторить сборку.
Касательно EC2 это можно решать через ASG, но в остальном приходится довериться здравому смыслу ваших коллег (что у них не хватит ума что-то радостно стереть просто так.)

Terraform же “запоминает” ресурсы, которые создал, и когда вы делаете terraform apply, он побежит к AWS, проверит ресурсы, а потом скажет вам, что он собирается делать. Это очень здорово - собранные им ресурсы записываются в метаданные, и если вы удалите EC2 instance или S3 bucket или RDS instance руками, то Terraform потом его вам еще раз соберет, и мало того - если удаленный ресурс являлся зависимостью для других, то он и их пересоберет!

Я теперь вынужден пройти парочку обучений по Terraform, но предварительные результаты исследований мне нравятся. Мой старший коллега в прошлом много работал с ним и подтвердил его надежность как IaaC утилитки, а шеф дал добро на применение любого решения, которое fit for purpose.
На этом можно сказать, что моя катавасия с DCOS подошла к концу. Я еще далек от завершения поставленной задачи (кластер еще надо запустить, протестировать и перенести на него наш тулинг), но полученный опыт бесценен.