#geodesic (2021-03)

This repo is currently out of date and docs won’t help you too much

We have some fresh documentation up at https://docs.cloudposse.com/

We archived everything that was no longer relevant and are starting to rollout the current docs

Geodesic tutorial dropped this week

https://docs.cloudposse.com/tutorials/geodesic-getting-started/

But geodesic is just one once. The ref arch docs are still pending.

Thanks Erik, I’ll take a look

odd - in chrome and chrome canary the text is not wrapping

Wow that’s new…. will look into it.

fixed!

Spacelift is gitops and you can use atmos and Atlantis with a bit of craft

In Atmos you can have different version modules per component

@Markus Muehlberger we’re slowly releasing the documentation and tutorials

We haven’t yet adopted vendir due to some missing functionality

Thanks @jose.amengual and @Erik Osterman (Cloud Posse). This is tutorial looks really helpful for some things I’m missing.

One final question though: Is atmos designed to be a mono repo, or are you still splitting repositories up per AWS account (as I’ve seen different files for dev, staging and prod in the same example)?

We’ve entirely abandoned one-repo-per-account. Mea culpa. That pattern didn’t make gitops easy.

Our current approach was designed with gitops in mind from the ground up

That sounds really amazing! Thanks Erik!

@Erik Osterman (Cloud Posse) just published the updates from https://github.com/cloudposse/docs/pull/531 for this one.

Also, I’m of the mind that we should create a #sweetops or similar channel to announce these docs / discuss the methodology holistically. What do you think?

Thanks Matt! I followed this one and couldn’t get through docker run . It outputted bash script. I ran make install instead.

@Marcin Brański* it might have been that you had an old image of geodesic on your local machine? I would delete all older images of Geodesic on your machine and try again — I’ve run into that myself with the new version of geodesic since it’s easy to do.

@Marcin Brański that means it’s an old image. Those UX issues are fixed

A Docker pull will resolve it

Using vendir effectively is blocked by https://github.com/vmware-tanzu/carvel-vendir/issues/37

So we’re currently not using it until we can get around to opening a PR for this.

Generally, upgrading of root modules (components) is not feasible in a mature environment.

Root modules are the foundation and upgrading them is often a violent operation.

Instead, our root modules (components) point to upstream modules which can be upgraded.

Our (cloudposse) objective using vendir is primarily to accelerate the coldstart process.

also, @Marcin Brański our terraform-aws-components there are already quite out of date. We have new ones. If you reach out to me directly, I can probably get you access to newer ones provided you help us upstream them.

Yeah man. I noticed they are outdated so I had to use tf13 because of that.

Our (cloudposse) objective using vendir is primarily to accelerate the coldstart process. Understand, I thought it’s new pattern where vendir would populate components but it seems we should be putting new modules (manually) to components dir and not execute vendir beside bootstrapping, yeah?

Early access to updated modules would be great.

What I ran into today is that variables (none of them, context as well) from terraform module are not passed to modules

  tfstate-backend:
    vars:
      namespace: terraform
      force_destroy: false
      prevent_unencrypted_uploads: true
      enable_server_side_encryption: true

but global vars works… I need to wrap my head around that…

So for multiaccount setup it’s recommended multi repo?

t it seems we should be putting new modules (manually) to components dir and not execute vendir beside bootstrapping, yeah? Correct

Early access to updated modules would be great. Yup, shoot me an email and let’s discuss. This benefits everyone.

What I ran into today is that variables (none of them, context as well) from terraform module are not passed to modules Nah, that’s probably just a whitespace issue

component vars are passed to the terraform modules.

So for multiaccount setup it’s recommended multi repo? ( No - we’ve entirely walked away from this approach. We use a mono repo for infrastructure.

mult-repo is not gitops friendly - it makes coldstarts expensive and difficult to automate

I will shoot you an email later today when I will be more familiar with atmos . I need some more time to ask better questions but I love the idea

My bad with not passing context was that I mixed reference architecture, atmos example and atmos tutorial which resulted in wrong yaml definition. I had:

components:
    vpc:
      vars:
        cidr_block: "10.100.0.0/16"

where it should be

components:
  terraform:
    vpc:
      vars:
        cidr_block: "10.100.0.0/16"

ya, yes, that ref arch is out-of-date and old/misleading

sigh… so many easter eggs! just in time for easter