#recommendation - периодически обновлять #AMI (в т.ч. докерных образов, как минимум сервисного) - раз в квартал (так обычно выходят обновления Amazon Linux).
Для срочных патчей (очередная критическая уязвимость чего бы то ни было) - отработать процедуру запуска критических обновлений.
Для срочных патчей (очередная критическая уязвимость чего бы то ни было) - отработать процедуру запуска критических обновлений.
#recommendation Для важных (неочевидных, а для кого-то - просто всех) выходных переменных #CloudFormation #templates стоит добавлять описание:
Outputs:
## Common parameters
dnsKong:
Value: !Ref dnsKong
Description: Kong External ELB DNS
Export:
Name: dnsKong#recommendation — для имён переменных в #CloudFormation #templates лучше не использовать имена переменных, начинающихся с имени стэка, т.к. в Physical ID добавляется имя стэка и возникает визуальная путаница (особенно при использовании #nested_stacks):
jdot-St1IAM-16Z64H1UDUQF3-jdotInstanceProfile-WJ74BPFLW925#recommendation Используемая практика именования переменных в #CloudFormation #templates у самого Амазана весьма ущербная - параметры начинаются с маленькой буквы p, а ресурсы начинаются с маленькой r:
Ущербность выявляется, когда выходишь за пределы одного стэка (особенно явно в #nested_stacks) — приходится переименовывать "бывшие" в одном стэке ресурсы в параметры в другом, что приводит при такой схеме к смене имени и сильно затрудняет сопровождение, а также плодит ошибки при переиспользование кода.
За многие годы я пришёл к другой схеме именования - параметры и ресурсы (если их нужно передавать) имеют одинаковые имена, лишь только добавляется правило, что все ресурсы начинаютс с маленькой буквы, а параметры с большой.
Кроме того, в имени ресурса почти всегда принципиально видеть тип, потому пример выше преобразуется в:
Сначала кажется, что это как раз добавит путаницу, но очень скоро станет понятно, что обычно совпадающие имена (лишь начинающиеся с разной буквы) встречаются редко (обычно при создании бакетов или юзеров, где передаётся их имя), а возможность поиска по всему проекту(-ам) для последующего оптового переименования в случае надобности - крайне удобна.
pDMZSubnetA
rDMZSubnetA
Ущербность выявляется, когда выходишь за пределы одного стэка (особенно явно в #nested_stacks) — приходится переименовывать "бывшие" в одном стэке ресурсы в параметры в другом, что приводит при такой схеме к смене имени и сильно затрудняет сопровождение, а также плодит ошибки при переиспользование кода.
За многие годы я пришёл к другой схеме именования - параметры и ресурсы (если их нужно передавать) имеют одинаковые имена, лишь только добавляется правило, что все ресурсы начинаютс с маленькой буквы, а параметры с большой.
Кроме того, в имени ресурса почти всегда принципиально видеть тип, потому пример выше преобразуется в:
SubnetDmzA
subnetDmzA
Сначала кажется, что это как раз добавит путаницу, но очень скоро станет понятно, что обычно совпадающие имена (лишь начинающиеся с разной буквы) встречаются редко (обычно при создании бакетов или юзеров, где передаётся их имя), а возможность поиска по всему проекту(-ам) для последующего оптового переименования в случае надобности - крайне удобна.
GitHub
cloudformation-examples/s3/cross-account-cross-region-replication/source-region.yml at master · applerom/cloudformation-examples
AWS CloudFormation code examples. Contribute to applerom/cloudformation-examples development by creating an account on GitHub.