DocumentDB - на мой взгляд лучший бизнес-лещ, который Амазон отвесил open-source коммьюнити.
А вы, должно быть, думаете, что я Амазон только хвалить умею.
Работаю сейчас с Fargate. Задача: собрать CFN-стек с необходимыми ресурсами (кластер, task definition, сервисы, балансировщик и прочее), а также настроить CI/CD под это дело.
Работы на самом деле не то, чтобы много - на сам стек у меня ушло где-то часа полтора + минут 40 чтобы настроить pipeline. Веселье началось, когда я начал продумывать, как мне подавать TaskDefinition template ECS’у.
Вариантов тут два: либо ставить и использовать ecs-cli, либо awscli. Не желая тратить время на первое, я пошел “проверенным” путем.
TaskDefinition template - JSON-документ в котором описываются параметры контейнеров (которых может быть больше одного), а также параметры самого task, т.е. роли, кол-во ЦПУ и памяти, конфигурация сети и прочее.
Первое, на что поругался awscli, были null значения ключей. Например в healthcheck.
Invalid type for parameter containerDefinitions[0].healthCheck, value: None, type: <type 'NoneType'>, valid types: <type 'dict'>Если вы в документе прописываете ключ, но не присваиваете ему значение (т.е. null), то валидатор поругается. Он ожидает увидеть строку, число, список или словарь, но никак не null. Делаем ход конем и подсовываем “пустые” значения (например
“hostname”: “”).
Дальше круче - пошла ругань на то, что параметры аутентификации для Docker репозитория несовместимы с ECR репозиториями, и это при том, что в repositoryCredentials.credentialsParameter у меня была пустая строка).
Ну и совсем мясо - при использовании
“networkMode”: “awsvpc” (которого кстати в документации CFN нету, есть только host и bridge) и ключа
“hostname” Амазон снова поругается на несовместимость этих двух параметров.
An error occurred (ClientException) when calling the RegisterTaskDefinition operation: hostname is not supported on container when networkMode=awsvpc.Каким же сюрпризом для меня стало то, что подавая параметры в шаблоне, register-task-definition автоматом пытается применить все ключи, даже если их значения пусты. (DCOS к примеру будет игнорировать ключ с пустым значением).
Валидатор это дело пропускает, он проверяет только тип данных в значениях, и ругаться начнет только API, получив некорректный шаблон.
Решение было простым до неприличия - удаление ключей из шаблона.
Многие говорят, что Амазон это плохо, Амазон подсадит вас на иглу, а затем возьмет и заблокирует и заберет ваши денежки и посадит в анальное рабство (и прочие пункты из сборника мифов мамкиных инфраструктурщиков, которые дальше раздела EC2 никуда не ходили), но что меня настораживает, так это видеть такие, ИМХО, недочеты в элементарных местах, где их не ожидаешь. А где есть небольшой недочет, там же может быть и несметное количество багов, которых тоже не ждешь.
Впрочем, не мне судить разработчиков AWS, особенно учитывая те скотские (на основе отзывов в интернетах) условия, в которых они работают (
https://www.nytimes.com/2015/08/16/technology/inside-amazon-wrestling-big-ideas-in-a-bruising-workplace.html).
