SweetOps #refarch for September, 2023

2023-09-14

Erik Osterman (Cloud Posse)

https://sweetops.slack.com/archives/CQCDCLA1M/p1694691101856679

Hey everyone - apologies if this is the wrong channel for this - happy to move if this is the case. I’m at a new org and I’m on the verge of migrating everything away from the current deployed setup (all AWS console) into IaC. I’ve got good experience with Terraform (mainly vanilla and some Terragrunt) but I want to get my head around a proper structure and some strong conventions. I’ve looked into the CloudPosse offerings, but think it’s likely too much for my organisation to go for. The things I’m looking for are: • Ability to instrument and deploy multiple AWS accounts and integrate them with SSO • The ability to eventually manage the entire deployment of IaC from a pipeline - exclusively • Implement my own modules (non-CloudPosse provided) ones with relative ease. Has anyone gone fully “in” on the Atmos toolchain and associated structure? Would you be happy to briefly explain your setup? And if you are using Atmos / SweetOps how are you finding it - assuming you are just using the open-source parts of the setup.

For some context - I am the sole engineer to manage infrastructure (amongst other responsibilities) - so I’d like to make the right choice at the start, as I don’t want to spend a long time implementing things that already have had time and energy put into them. The alternatives for me are things like Terragrunt - so if you choose Atmos over TG - would be keen to hear your thoughts!

johncblandii

03:57:53 PM

@James Worville I actually am in your same boat just farther along the path. We had the same thing, but a mix of console, terraform, serverless.io, and CloudFormation code to manage a decent amount of infra.

We reworked all of it on the CP approach with vendored components, custom, and vendored w/ changes (using the override pattern) all deployed through Spacelift coupled with GitHub Actions.

I’ve heard from others internally and they’re pleased with the cleanliness and direct process for managing our infra; especially compared to the current (almost former) approach.

0 regrets.

Hey everyone - apologies if this is the wrong channel for this - happy to move if this is the case. I’m at a new org and I’m on the verge of migrating everything away from the current deployed setup (all AWS console) into IaC. I’ve got good experience with Terraform (mainly vanilla and some Terragrunt) but I want to get my head around a proper structure and some strong conventions. I’ve looked into the CloudPosse offerings, but think it’s likely too much for my organisation to go for. The things I’m looking for are: • Ability to instrument and deploy multiple AWS accounts and integrate them with SSO • The ability to eventually manage the entire deployment of IaC from a pipeline - exclusively • Implement my own modules (non-CloudPosse provided) ones with relative ease. Has anyone gone fully “in” on the Atmos toolchain and associated structure? Would you be happy to briefly explain your setup? And if you are using Atmos / SweetOps how are you finding it - assuming you are just using the open-source parts of the setup.

For some context - I am the sole engineer to manage infrastructure (amongst other responsibilities) - so I’d like to make the right choice at the start, as I don’t want to spend a long time implementing things that already have had time and energy put into them. The alternatives for me are things like Terragrunt - so if you choose Atmos over TG - would be keen to hear your thoughts!

1

johncblandii

03:59:05 PM

We also utilized CP professional services to help jump start our process too. That was invaluable to ensure things were done right; which it wasn’t all done right initially so they helped fix it.

2023-09-19

johncblandii

03:54:35 PM

Any plans for aws-inspector v2 integration?

Erik Osterman (Cloud Posse)

06:57:46 PM

@Matt Gowie @Veronika Gnilitska contributed this in https://github.com/cloudposse/terraform-aws-components/pull/781

#781 feat: add module for AWS Inspector V2

what

• Adds module to support basic configuration for AWS Inspector V2. • Similar to terraform-aws-components/modules/guardduty, this supports complex deployment within two steps: setup Delegated Administration account + configure organization-wide findings collecting.

why

• This hasn’t been introduced yet.

references

• N/A.

Erik Osterman (Cloud Posse)

06:58:06 PM

We’re holding off on merging until we tackle how to handle community contributions

Erik Osterman (Cloud Posse)

06:58:23 PM

The plan is to create a separate subpath of terraform-aws-components for community/ contributions.

johncblandii

06:58:40 PM