#refarch (2024-05)

Cloud Posse Reference Architecture

2024-05-05

Marat Bakeev avatar
Marat Bakeev

Hey everyone, in the reference architecture - is there some idea of an internal account for internal tools, like a kubernetes cluster with centralized grafana, for example? Which account would it be? corp? auto? or something else?

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

yes absolutely, we have several internal accounts that we refer to as “core” accounts. We deploy both auto and corp accounts but nowadays typically only deploy auto unless someone has a specific use case for corp. We primarily use the EKS cluster in auto for GitHub self-hosted runners, but that’d be a great place to deploy grafana as well. Although at the moment we’re using AWS managed grafana

1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Yes, it comes down to cost. How many “tools” type accounts make sense and how much infra you want to run in there.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

So, we’ve gradually consolidated more and more “tools” type functionality into an account we generally call “auto”. Historically, we also deployed an corp account with an EKS cluster, for “corporate facing” apps, but do so less these days.

1

2024-05-06

2024-05-07

Nat Williams avatar
Nat Williams

I’ve noticed something when reading the docs/readmes for cloudposse terraform modules - the list of inputs can get really busy with all the contextual inputs that it becomes hard to find the the actual module-specific inputs. Has anyone ever talked about reorganizing the readmes to separate the inputs that are part of the context into a separate table?

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Yes,

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We want to redo the template for terraform-docs

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

so that we a) move context parameters to a separate section b) avoid tables

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

With the reliance more and more on complex objects, tables just don’t cut it

Nat Williams avatar
Nat Williams

yeah, it would be nice to be able to stretch the window big and actually see everything

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Yea, agreed. Good feedback.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

We’re working a lot on improving docs, and such, but I cannot say yet when that work will be scheduled. We have an internal task already for it.

Nat Williams avatar
Nat Williams

cool. thanks

2024-05-15

Taimur Gibson avatar
Taimur Gibson

Is there a way to set an ALB idle_timeout when deployed through the ecs module? I found this in the alb module but I don’t see how to configure that same setting for an ecs defined ALB https://github.com/cloudposse/terraform-aws-components/tree/main/modules/alb#input_idle_timeout

Ben Smith (Cloud Posse) avatar
Ben Smith (Cloud Posse)

Our ECS component, which creates the cluster and the loadbalancers for the cluster includes a module for the alb. It looks like it’s missing the idle_timeout var as a pass through from the module declaration but that wouldn’t be hard to change

Ben Smith (Cloud Posse) avatar
Ben Smith (Cloud Posse)

if you are using our components, i’d suggest vendoring down the ECS Component, and making that change locally (we’d love a PR too ).

Taimur Gibson avatar
Taimur Gibson

ok thanks! I’ll check it out

Taimur Gibson avatar
Taimur Gibson

I got this working. How can I open a PR for your repo?

2024-05-16

2024-05-17

Alex avatar

Hi,

trying to deploy privileged stack for AWS-Config, under superadmin role, got error:

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: error configuring S3 Backend: IAM Role (arn:aws:iam::xxx:role/xx-core-gbl-root-tfstate-ro) cannot be assumed.
│ 
│ There are a number of possible causes of this - the most common are:
│   * The credentials used in order to assume the role are invalid
│   * The credentials do not have appropriate permission to assume the role
│   * The role ARN is not valid
│ 
│ Error: NoCredentialProviders: no valid providers in chain. Deprecated.
│       For verbose messaging see aws.Config.CredentialsChainVerboseErrors
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@Dan Miller (Cloud Posse) @Ben Smith (Cloud Posse)

Dan Miller (Cloud Posse) avatar
Dan Miller (Cloud Posse)

It’s hard to determine from this message alone, but I might guess that your session for your superadmin user expired. Can you double check?

aws sts get-caller-identity
    keyboard_arrow_up