1 réponse
- Le plus récent
- Le plus de votes
- La plupart des commentaires
0
Former2 is your best option. It's meant to be a starting point for your CloudFormation template, to save time compared to writing from scratch, but it won't produce a perfect "black box". It doesn't replace having a good understanding of your template and debugging it unfortunately.
Contenus pertinents
- demandé il y a un an
- demandé il y a un mois
- demandé il y a un an
AWS OFFICIELA mis à jour il y a 3 mois- AWS OFFICIELA mis à jour il y a 2 ans
Infrastructure as Code (IaC) is key. A typical workload will have CloudFormation templates (or CDK or Terraform) that are deployed in multiple environments e.g. Dev, Test, UAT and Prod accounts, without change. Only parameter values change so you're deploying tested and proven code to Production. Some templates, particularly more DevOps-focused ones, will be deployed across many if not all accounts in the Organization using StackSets - again it's the same template code.
Templates are often written from scratch but tools like Former2 can be used too to do some legwork if you have some existing deployed resources you want to mimic. But then the template you've generated needs some major work, like working out what needs to change as you deploy across multiple environments, and ensuring this is driven by Parameters etc. And addition of lots of comments - which is one reason why you should use YAML and not JSON CloudFormation templates! :)
Thanks for the response, then how come big companies manage this type of requirement, if they have many Environments, will they set them up one by one manually? just I want to understand how they manage.