Pinned Module Composition
Every deployable root composes the same published module at the same pinned version, so roots differ only in backend, domain, and credentials.
- Kind
- Architecture
- Domain
- Infrastructure & Runtime
- Applies at
env/- Status
- Stable
- Source
docs/ARCHITECTURE.md
01 Defines
An arrangement in which the whole infrastructure pattern lives in one published module, and each environment’s root is a thin wrapper that calls it at the same version with only its backend, domain, and credentials changed.
02 Applies when
- One deployed unit exists in several places — a developer copy, a shared non-production tier, production.
- What is tested before production has to be the same deployment that production receives.
- The infrastructure pattern is mature enough to publish as a versioned module.
03 Boundaries
- Roots hold wiring only; they do not add resources around the module or fork its behaviour.
- Differences between environments are limited to inputs the module exposes, not edits to the pattern.
- Upgrading the module is a deliberate change to every root, not a drift between them.
Expected behaviour
- 01Each root contains a backend, a domain, credentials, and one module block — little else.
- 02Every root references the same module source at the same version.
- 03Tier-specific choices, such as switching off monitoring for disposable copies, are made through module inputs.
- 04Roots expose the same outputs, so one deployer can drive any of them.
Behaviour#
The repository deploys one static website to several places. Rather than describe that website’s infrastructure several times, it describes it once — the S3 bucket, CloudFront distribution, ACM certificate, and DNS records — as a published module, and gives each environment a root that does nothing but call it.
Because every root runs the same module at the same version, the pattern lives in exactly one place and every environment is the same deployment. A change tested in a developer’s copy is the change production will get, because there is no second implementation for it to diverge from.
- 01 Publish The site pattern is released to the module registry Modules
- 02
Compose
Each root adds one
module "this"block at the shared version - 03 Configure Roots differ only in backend, domain, and credentials
- 04 Deploy One deployer runs any root and reads the same three outputs Parameterless Deployment
What differs between roots#
| Concern | workspaces/site | env/prod/release |
|---|---|---|
| Backend | One key; a state object per workspace | Its own key; owns its state |
| Domain | sampletest-${terraform.workspace}.dev.prosyon.ca | sampletest.dev.prosyon.ca |
| Credentials | Profiles sandbox001 and domains | Profiles sandbox001 and domains |
| Module inputs | domain, enable_monitoring = false | domain |
| Outputs | bucket_name, cloudfront_distribution_id, site_url | The same three |
The documentation also describes a shared staging root at env/staging/release
following the same shape. That root is not present in this repository; the
pattern holds for however many roots exist.
Layout#
- env/
- prod/
- release/ Production root: backend, domain, credentials Environments
- workspaces/
- site/ Developer root: same module, workspace-derived domain Workspaces
Examples#
Set side by side, the two module blocks differ by a single input:
module "this" {
source = "registry.forge.prosyon.ca/patterned-designs/hcl-aws-cloudfront-s3-static-website-xam--variant-shared/aws"
providers = {
aws = aws
aws.us_east_1 = aws.us_east_1
aws.dns = aws.dns
}
domain = local.site_domain
}
module "this" {
source = "registry.forge.prosyon.ca/patterned-designs/hcl-aws-cloudfront-s3-static-website-xam--variant-shared/aws"
providers = {
aws = aws
aws.us_east_1 = aws.us_east_1
aws.dns = aws.dns
}
domain = local.site_domain
enable_monitoring = false
}
Connections