Geodesic modules are Git repositories that extend the Geodesic base docker image and contain all Infrastructure as Code.
⇠ Select one of these pages to learn more about the topic.
We believe that infrastructure as code should be treated just like all other code: tested, bundled into artifacts and automatically deployed. This is what
geodesic solves. A geodesic module is a docker container/image which contains all the Infrastructure as Code necessary to provsion logically related IaaS resources (e.g. AWS Organizations, IAM Roles/Permissions, CDNs, S3 Buckets, Kubernetes Clusters, etc).
For example, when we need to provision resources using
terraform, we’ll build a docker container that inherits from the
geodesic base image and
COPY all the
*.tf code into the image on
docker build. Now we can run that container to provision infrastructure anywhere we have
docker installed (for example from CI/CD systems), without needing to configure, version and maintain a bunch of native tools. In practice, we use geodesic modules to bundle terraform code, kops manifests, ansible code, and more.
Geodesic modules are used to logically organize infrastructure as code by leveraging git repositories. We’re able to keep code extremely DRY, while at the same time incredibly maintaining modularity and stability. We accomplish this by leveraging a few common patterns:
- Docker inheritance
- Multi-stage Docker Builds
- Terraform Root modules
- Terraform Modules
- Polyrepos to logically organize infrastructure. Use modules to capture/import business logic.
We prefer the polyrepo approach to the monorepo approach when it comes in infrastructure. Git repositories allow us to surgically tag/version infrastructure code that represents some kind of business logic.
For example, we often prescribe organizing repositories by AWS organization. For the purpose of documentation, we’ll use
cloudposse.co as the example organization.
root.cloudposse.co module represents an organization’s “root” or “top level” AWS account. This is typically your billing organization and handles IAM user account provisioning.
It should also use the
aws_organizations_organization and organizations_account to provision all the subaccounts within the root organization.
prod.cloudposse.co module represents an organization’s “production infrastructure”. It’s a subaccount of the
staging.cloudposse.co module represents an organization’s “staging infrastructure”. Typically, we treat this as a “pre-production” environment, which means it should remain stable and treated as though it were a real production environment. This environment gives developers access to a “production-like” environment, without the consequences, risks and liaiblities of actually operating in production.
dev.cloudposse.co module represents an organization’s “development infrastructure”. This module is used as a sandbox environment where developers and test the waters and get familiar with AWS. We prescribe that organizations give all developers “Administrator” level privileges to this account where developers may test the waters.
audit.cloudposse.co module represents an organization’s “audit logs infrastructure”. By leveraging our
terraform-aws-cloudtrail-s3-bucket modules, we make it exceptionally easy to ship CloudTrail logs from all your organizations to one central, highly restrictive organization whose sole purpose is to provide a tamper-proof, encrypted, system of record for infrastructure logs with lifecycle rules.
We provide an example invocation of this pattern in our
testing.cloudposse.co module represents an organizational unit used for continuous integration and testing of infrastructure code. By provisioning a separate, dedicated organizational unit (or just account) for this we are able to silo testing infrastructure so it doesn’t pollute or in any way impact other environments.