Реализовать в #CloudFormation #templates зависимость значений от environment не очень сложно. Однако когда требуется переменное количество параметров (т.е. для одного окружения один набор переменных, а для другого - отличный), то для этого Амазон сделал в своё время Fn::Transform.
Однако из-за того, что это (Transform) суть костыльный костыль, реализуемый как надстройка в виде лямбды, которая запускается перед скармливанием CloudFormation конечного вида шаблона, то реальный опыт работы с Transform оказался весьма болезненный.
Потому совет: если можно не использовать Transform - лучше не использовать.
Альтернативой может быть использование #Conditions.
Например, вот реальный кейс. Потребовалось для multi environment шаблона реализовать логику различного набора переменных для #ECS #task_definition - на тестовом окружении требовалось задать другие переменные, при этом обычные не должны быть определены совсем, т.к. чувствительное приложение, написанное в давние времена, спотыкалось о них и падало.
В результате дефолтная таска была скопирована и создана ещё одна такая же, только с нужными переменными. И добавлен волшебный condition, который из двух этих тасок в сервисе подключал нужную:
https://github.com/applerom/cloudformation-examples/blob/master/ecs/task-definition-with-different-set-of-variables.yaml
По умолчанию логика ни для какого (уже ранее имеющегося) окружения не поменяется (т.к. по умолчанию UseTestVariables = 'no'), а для тестового сработает
Итого - всё работает стандартно и без трансформатора.
Однако из-за того, что это (Transform) суть костыльный костыль, реализуемый как надстройка в виде лямбды, которая запускается перед скармливанием CloudFormation конечного вида шаблона, то реальный опыт работы с Transform оказался весьма болезненный.
Потому совет: если можно не использовать Transform - лучше не использовать.
Альтернативой может быть использование #Conditions.
Например, вот реальный кейс. Потребовалось для multi environment шаблона реализовать логику различного набора переменных для #ECS #task_definition - на тестовом окружении требовалось задать другие переменные, при этом обычные не должны быть определены совсем, т.к. чувствительное приложение, написанное в давние времена, спотыкалось о них и падало.
В результате дефолтная таска была скопирована и создана ещё одна такая же, только с нужными переменными. И добавлен волшебный condition, который из двух этих тасок в сервисе подключал нужную:
https://github.com/applerom/cloudformation-examples/blob/master/ecs/task-definition-with-different-set-of-variables.yaml
По умолчанию логика ни для какого (уже ранее имеющегося) окружения не поменяется (т.к. по умолчанию UseTestVariables = 'no'), а для тестового сработает
TaskDefinition: !If [ UseTest, !Ref ecsTaskTest, !Ref ecsTask ].Итого - всё работает стандартно и без трансформатора.
IAM с самоуничтожением
Можно ли сделать такие политики для IAM, чтобы они отработали и уничтожились через некоторое время?
Чтобы совсем уничтожились - придётся наворачивать лямбду. А чтобы просто отработали лишь на какое-то определённое время — запросто.
Для этого нужно использовать Date Condition Operators, например, так:
#IAM #policy
Можно ли сделать такие политики для IAM, чтобы они отработали и уничтожились через некоторое время?
Чтобы совсем уничтожились - придётся наворачивать лямбду. А чтобы просто отработали лишь на какое-то определённое время — запросто.
Для этого нужно использовать Date Condition Operators, например, так:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/my-file",
"Condition": {
"DateGreaterThan": {
"aws:CurrentTime": "2020-01-04T10:00Z"
},
"DateLessThan": {
"aws:CurrentTime": "2020-01-05T18:00Z"
}
}
}
]
}
Т.е. доступ к my-bucket/my-file будет лишь с завтрашнего утра до послезавтрашнего вечера.#IAM #policy