Activities - Design & Deploy Cloud Infra

#	Name	Abbrev.	Guidance	Actions
Elaboration 7
1	Review SAO & Define Infra Requirements	DCI-1	Review SAO & Define Infra Requirements Objective Read docs/architecture/SAO.md, identify the AWS services needed for …	Read the 'DCI-1 Review SAO & Define Infra Requirements' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Review SAO & Define Infra Requirements ## Objective Read `docs/architecture/SAO.md`, identify the AWS services needed for the application, and produce a concise infrastructure requirements document that drives all subsequent CDK stack decisions. --- ## Process ### 1. Read SAO.md Extract from SAO.md: - Technology Stack Table — runtime versions, databases, caches, queues - § Deployment Strategy (DTA-14) — blue/green, canary, rolling - § Infrastructure (DTA-15) — cloud provider, region, compute platform - § Observability (DTA-13) — logging, metrics, tracing services ### 2. Map Application Needs → AWS Services \| Application Need \| EKS Path \| EB Path \| CDK Stack \| \|-----------------\|----------\|---------\|----------\| \| Container orchestration \| EKS \| Elastic Beanstalk \| EKS Stack / EB Stack \| \| Container registry \| ECR \| ECR \| EKS Stack / EB Stack \| \| Networking (VPC, subnets) \| VPC \| VPC \| VPC Stack \| \| DNS for blue/green \| Route53 \| Route53 (via CNAME swap) \| DNS Stack / EB handles internally \| \| NAT for private subnets \| NAT Gateway \| NAT Gateway \| VPC Stack \| \| TLS termination \| ALB + ACM \| EB managed ALB \| EKS Stack (ingress) / EB handles \| \| Secrets \| AWS Secrets Manager or K8s Secrets \| Secrets Manager or EB env properties \| EKS Stack / EB Stack \| \| Logging \| CloudWatch Logs \| CloudWatch Logs \| EKS Stack (add-ons) / EB handles \| ### 3. Choose Deployment Style Read the infrastructure skills available in this playbook. Pick one based on SAO.md § Deployment Strategy and § Infrastructure decisions: \| Style \| When to choose \| Skill \| \|---\|---\|---\| \| Kubernetes / EKS \| Multi-service, needs orchestration, team familiar with K8s \| K8s in EKS Deployment Patterns (#23) \| \| Elastic Beanstalk \| Single-service Django/web app, small team, want managed infra \| AWS EB Blue/Green Deployment \| Record the choice in `INFRA_REQUIREMENTS.md` under a new "Deployment Style" heading: ```markdown ## Deployment Style Chosen: [EKS / Elastic Beanstalk] Rationale: [Why this style fits the project — team size, service count, K8s familiarity, etc.] Skill Reference: [Skill name and ID] ``` All subsequent DCI and DCD activities must be executed using the patterns from the chosen skill. ### 4. Document Infra Requirements Create `docs/architecture/INFRA_REQUIREMENTS.md`. Tailor the content to your chosen deployment style: #### EKS Path ```markdown # Infrastructure Requirements ## AWS Region {region from SAO.md, e.g., us-east-1} ## Deployment Style Chosen: Kubernetes / EKS Rationale: Multi-service architecture with microservices orchestration needs Skill Reference: K8s in EKS Deployment Patterns (#23) ## Services Required \| Service \| Purpose \| Configuration \| \|---------\|---------\|---------------\| \| VPC \| Network isolation \| 2 public + 2 private subnets, NAT GW \| \| EKS \| Container orchestration \| Managed node group, 2-3 nodes \| \| ECR \| Container registry \| 1 repo per service \| \| Route53 \| DNS + blue/green switching \| Hosted zone, prod/idle weighted records \| ## Blue/Green Strategy - Two namespaces: `blue`, `green` - Route53 weighted records: `prod.{domain}` → active, `idle.{domain}` → standby - Switch = swap DNS weights (0/100 ↔ 100/0) ## Cost Estimate {Rough monthly cost for EKS + NAT + Route53} ## Security Requirements - Private subnets for EKS nodes - Security groups: EKS ↔ database, ALB ↔ EKS - IAM roles: EKS node role, CDK deploy role ``` #### EB Path ```markdown # Infrastructure Requirements ## AWS Region {region from SAO.md, e.g., us-east-1} ## Deployment Style Chosen: Elastic Beanstalk Rationale: Single Django application, small team, prefer managed infrastructure Skill Reference: AWS EB Blue/Green Deployment ## Services Required \| Service \| Purpose \| Configuration \| \|---------\|---------\|---------------\| \| VPC \| Network isolation \| 2 public + 2 private subnets, NAT GW \| \| Elastic Beanstalk \| Managed Docker platform \| 2 environments: {project}-prod, {project}-idle \| \| ECR \| Container registry \| 1 repo for web image \| \| S3 \| Deployment bundles \| elasticbeanstalk-{region}-{account} \| ## Blue/Green Strategy - Two EB environments: `{project}-prod` (physical A), `{project}-idle` (physical B) - CNAME swap: `swap-environment-cnames` flips prod ↔ idle roles - Prod is whichever env currently holds the `{project}-prod` CNAME ## Environment Variables - `EB_APP`: {project} - `EB_ENV_A`: {project}-prod - `EB_ENV_B`: {project}-idle - `EB_BUCKET`: elasticbeanstalk-{region}-{account} ## Cost Estimate {Rough monthly cost for 2 EB environments + NAT + S3} ## Security Requirements - Private subnets for EB instances - Security groups: EB ALB ↔ instances - IAM roles: EB service role, instance profile ``` ### 5. Validate with SAO.md Cross-check: every service in INFRA_REQUIREMENTS.md must trace back to a decision in SAO.md. If SAO.md doesn't cover infra decisions, flag it and update DTA first. --- ## Deliverables - ✅ SAO.md reviewed — infra-relevant sections extracted - ✅ Deployment style chosen — EKS or EB, documented with rationale - ✅ AWS service mapping — application needs → AWS services (both paths shown) - ✅ `docs/architecture/INFRA_REQUIREMENTS.md` created (tailored to chosen style) - ✅ Blue/green strategy documented (style-specific) - ✅ Cost estimate included ## Inputs Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating. - System Architecture Overview Template (Template, Required) — produced by Write SAO.md (#59).
2	Scaffold Infra Repo & CDK Project	DCI-2	Scaffold Infra Repo & CDK Project Objective Create an AWS CDK Python project with Makefile …	Read the 'DCI-2 Scaffold Infra Repo & CDK Project' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Scaffold Infra Repo & CDK Project ## Objective Create an AWS CDK Python project with Makefile for infra operations and a GitHub Actions workflow placeholder. Layout depends on deployment style from DCI-01. --- ## Process ### Path Selection Refer to `docs/architecture/INFRA_REQUIREMENTS.md` § Deployment Style. \| Style \| Repo layout \| \|-------\|-------------\| \| EKS \| Separate `{project}-infra` repository (recommended) \| \| Elastic Beanstalk \| `{project}-infra/` or `infra/` inside the application monorepo \| > Monorepo note (EB): Small teams often keep `infra/` in the app repo. CDK deploy and app CI/CD share secrets via `infra/.env`. Separate repo still valid for larger orgs. --- ## EKS Path ### 1. Create Infra Repository ```bash mkdir {project}-infra && cd {project}-infra && git init ``` ### 2. Initialize CDK Project ```bash python3 -m venv .venv && source .venv/bin/activate pip install aws-cdk-lib constructs mkdir -p stacks tests ``` Create `app.py` wiring `VpcStack`, `EksStack`, `DnsStack`. ### 3. Directory Structure ``` {project}-infra/ ├── app.py ├── cdk.json ├── requirements.txt ├── Makefile ├── .github/workflows/infra.yml ├── stacks/ │ ├── vpc_stack.py │ ├── eks_stack.py │ └── dns_stack.py ├── scripts/traffic_switch.py └── tests/test_stacks.py ``` --- ## Elastic Beanstalk Path ### 1. Create `infra/` Directory In app monorepo (or separate repo): ```bash mkdir -p infra/stacks infra/scripts infra/tests infra/lambda ``` ### 2. Initialize CDK Project Same venv/CDK setup as EKS path. Create `app.py` wiring stacks for your project, e.g.: - `MimirNetwork` — VPC lookup, EB security group, RDS ingress - `MimirApp` — EB app, `{project}-prod` / `{project}-idle`, ECR ref, CI IAM, alarms - `MimirBackups` — S3 pre-migrate bucket, SSM on EB instance role - `MimirSes` — SES configuration set (if transactional email) - `MimirDns` — Route53 CNAME → `{project}-prod.eba-…` (see DCI-05 EB path) ### 3. Directory Structure ``` infra/ ├── app.py ├── cdk.json ├── requirements.txt ├── .env.example ← secrets template (gitignored .env) ├── eb_live_platform_settings.json ← exported from live EB (no secrets) ├── stacks/ │ ├── network_stack.py │ ├── app_stack.py ← EB + ECR + CI IAM │ ├── backups_stack.py │ ├── ses_stack.py │ └── dns_stack.py ├── scripts/ │ ├── export_eb_live_settings.py │ └── diff_eb_live_vs_cdk.py ├── lambda/route53_cname/ ← idempotent CNAME UPSERT └── tests/test_stacks.py ``` ### 4. Two Sources of Truth (EB) \| What \| Where \| \|------\|--------\| \| Platform settings (VPC, ALB, instance type, non-secret env vars) \| `eb_live_platform_settings.json` — refresh after console changes \| \| Secrets (`DATABASE_URL`, `DJANGO_SECRET_KEY`, etc.) \| `infra/.env` at `cdk deploy` — never committed \| See AWS CDK with Python skill § EB Platform Settings Export. --- ## Infra Makefile (Both Paths) ```makefile .PHONY: help synth deploy destroy status test provision help: ## Show help @awk 'BEGIN {FS = ":.##"} /^[a-zA-Z_-]+:.?##/ { printf " %-20s %s\n", $$1, $$2 }' $(MAKEFILE_LIST) synth: ## Synthesize CDK stacks cdk synth deploy: ## Deploy all stacks cdk deploy --all --require-approval never test: ## Run CDK tests python -m pytest tests/ -v provision: ## Install CDK deps pip install -r requirements.txt ``` EB monorepo: add `##@ Deploy` targets to the app Makefile (`swap`, `eb-status`, `backup`) — see EB skill. --- ## Deliverables - ✅ CDK project initialized with stack placeholders for chosen style - ✅ Infra Makefile with synth/deploy/test targets - ✅ EB: `.env.example` + export/diff scripts scaffolded - ✅ Committed
3	Build VPC & Networking Stack	DCI-3	Build VPC & Networking Stack Objective Implement the VPC CDK stack with public/private subnets, NAT …	Read the 'DCI-3 Build VPC & Networking Stack' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Build VPC & Networking Stack ## Objective Implement the VPC CDK stack with public/private subnets, NAT Gateway, and security groups. This is the foundational networking layer that EKS and all other services depend on. --- ## Process ### 1. Implement `stacks/vpc_stack.py` Use the `aws_cdk_python` skill for reference patterns. Key constructs: - VPC with 2 AZs, 2 public + 2 private subnets - NAT Gateway (1 per AZ for HA, or 1 shared for cost savings) - Security Groups: EKS control plane, EKS nodes, database (if applicable) ```python from aws_cdk import Stack, aws_ec2 as ec2 from constructs import Construct class VpcStack(Stack): def __init__(self, scope: Construct, id: str, kwargs): super().__init__(scope, id, kwargs) self.vpc = ec2.Vpc( self, "Vpc", max_azs=2, nat_gateways=1, subnet_configuration=[ ec2.SubnetConfiguration( name="Public", subnet_type=ec2.SubnetType.PUBLIC, cidr_mask=24, ), ec2.SubnetConfiguration( name="Private", subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS, cidr_mask=24, ), ], ) # Security group for EKS nodes self.eks_sg = ec2.SecurityGroup( self, "EksNodeSg", vpc=self.vpc, description="Security group for EKS worker nodes", allow_all_outbound=True, ) ``` ### 2. Write CDK Tests ```python # tests/test_vpc_stack.py import aws_cdk as cdk from aws_cdk.assertions import Template from stacks.vpc_stack import VpcStack def test_vpc_created(): app = cdk.App() stack = VpcStack(app, "TestVpc") template = Template.from_stack(stack) template.resource_count_is("AWS::EC2::VPC", 1) def test_subnets_created(): app = cdk.App() stack = VpcStack(app, "TestVpc") template = Template.from_stack(stack) template.resource_count_is("AWS::EC2::Subnet", 4) # 2 public + 2 private ``` ### 3. Synthesize & Verify ```bash make synth # Should produce CloudFormation template without errors make test # CDK tests should pass ``` ### 4. Deploy VPC Stack Only ```bash npx cdk deploy VpcStack ``` Verify in AWS Console: - VPC created with correct CIDR - 4 subnets (2 public, 2 private) - NAT Gateway running - Route tables configured ### 5. Commit ```bash git add stacks/vpc_stack.py tests/test_vpc_stack.py git commit -m "infra: implement VPC stack with 2 AZ, NAT Gateway, security groups" ``` --- ## Deliverables - ✅ `stacks/vpc_stack.py` implemented with VPC, subnets, NAT, security groups - ✅ CDK tests for VPC stack passing - ✅ `make synth` succeeds - ✅ VPC deployed and verified in AWS Console
4	Build Compute & Container Registry Stack	DCI-4	Build Compute & Container Registry Stack Objective Provision the compute environment and container registry matching …	Read the 'DCI-4 Build Compute & Container Registry Stack' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Build Compute & Container Registry Stack ## Objective Provision the compute environment and container registry matching your chosen deployment style (from Activity #74). This activity forks into two implementation paths—EKS or Elastic Beanstalk—both delivering the same outcome: a running compute platform and accessible ECR repository. --- ## Process ### Path Selection Refer to `docs/architecture/INFRA_REQUIREMENTS.md` § Deployment Style. Follow the path for your chosen style. --- ## EKS Path Skill: K8s in EKS Deployment Patterns (#23) ### 1. Implement `stacks/eks_stack.py` Key constructs: - EKS Cluster with managed node group (2-3 `t3.medium` nodes) - ECR Repository for application container images - OIDC Provider for IAM Roles for Service Accounts (IRSA) - kubectl layer for CDK to interact with cluster - Blue/green namespaces created on cluster ```python from aws_cdk import Stack, RemovalPolicy, aws_eks as eks, aws_ec2 as ec2, aws_ecr as ecr, aws_iam as iam from constructs import Construct class EksStack(Stack): def __init__(self, scope: Construct, id: str, vpc: ec2.Vpc, kwargs): super().__init__(scope, id, kwargs) # EKS Cluster self.cluster = eks.Cluster( self, "Cluster", vpc=vpc, version=eks.KubernetesVersion.V1_29, default_capacity=0, endpoint_access=eks.EndpointAccess.PUBLIC_AND_PRIVATE, ) # Managed Node Group self.cluster.add_nodegroup_capacity( "WorkerNodes", instance_types=[ec2.InstanceType("t3.medium")], min_size=2, max_size=4, desired_size=2, disk_size=50, subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS), ) # ECR Repository self.ecr_repo = ecr.Repository( self, "AppRepo", repository_name="{project}", removal_policy=RemovalPolicy.RETAIN, lifecycle_rules=[ ecr.LifecycleRule(max_image_count=20, description="Keep last 20 images") ], ) # Create blue/green namespaces for ns in ["blue", "green"]: self.cluster.add_manifest( f"{ns}-namespace", { "apiVersion": "v1", "kind": "Namespace", "metadata": {"name": ns}, }, ) ``` ### 2. Configure kubectl Access ```bash aws eks update-kubeconfig --name {cluster-name} --region {region} kubectl get nodes # Should show 2 worker nodes kubectl get ns # Should show blue and green namespaces ``` ### 3. Test ECR Push ```bash aws ecr get-login-password --region {region} \| docker login --username AWS --password-stdin {account}.dkr.ecr.{region}.amazonaws.com docker pull nginx:alpine docker tag nginx:alpine {account}.dkr.ecr.{region}.amazonaws.com/{project}:test docker push {account}.dkr.ecr.{region}.amazonaws.com/{project}:test ``` --- ## Elastic Beanstalk Path Skill: AWS EB Blue/Green Deployment ### 1. Implement `stacks/eb_stack.py` Key constructs: - EB Application resource - Two EB Environments: `{project}-prod` (physical A), `{project}-idle` (physical B) - ECR Repository for Docker images - S3 Bucket for deployment bundles (use existing `elasticbeanstalk-{region}-{account}` bucket) ```python from aws_cdk import Stack, RemovalPolicy, aws_elasticbeanstalk as eb, aws_ec2 as ec2, aws_ecr as ecr, aws_iam as iam from constructs import Construct class EbStack(Stack): def __init__(self, scope: Construct, id: str, vpc: ec2.Vpc, kwargs): super().__init__(scope, id, kwargs) # EB Application self.app = eb.CfnApplication( self, "App", application_name="{project}", ) # ECR Repository self.ecr_repo = ecr.Repository( self, "AppRepo", repository_name="{project}", removal_policy=RemovalPolicy.RETAIN, lifecycle_rules=[ ecr.LifecycleRule(max_image_count=20, description="Keep last 20 images") ], ) # Service Role for EB service_role = iam.Role( self, "EBServiceRole", assumed_by=iam.ServicePrincipal("elasticbeanstalk.amazonaws.com"), managed_policies=[ iam.ManagedPolicy.from_aws_managed_policy_name("AWSElasticBeanstalkEnhancedHealth"), iam.ManagedPolicy.from_aws_managed_policy_name("AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy"), ], ) # Instance Profile instance_role = iam.Role( self, "EBInstanceRole", assumed_by=iam.ServicePrincipal("ec2.amazonaws.com"), managed_policies=[ iam.ManagedPolicy.from_aws_managed_policy_name("AWSElasticBeanstalkWebTier"), iam.ManagedPolicy.from_aws_managed_policy_name("AmazonEC2ContainerRegistryReadOnly"), ], ) instance_profile = iam.CfnInstanceProfile( self, "EBInstanceProfile", roles=[instance_role.role_name], ) # Environment A ({project}-prod initially) self.env_a = eb.CfnEnvironment( self, "EnvA", application_name=self.app.application_name, environment_name="{project}-prod", solution_stack_name="64bit Amazon Linux 2023 v4.3.0 running Docker", option_settings=[ eb.CfnEnvironment.OptionSettingProperty( namespace="aws:autoscaling:launchconfiguration", option_name="IamInstanceProfile", value=instance_profile.ref, ), eb.CfnEnvironment.OptionSettingProperty( namespace="aws:elasticbeanstalk:environment", option_name="ServiceRole", value=service_role.role_arn, ), ], ) self.env_a.add_dependency(self.app) # Environment B ({project}-idle initially) self.env_b = eb.CfnEnvironment( self, "EnvB", application_name=self.app.application_name, environment_name="{project}-idle", solution_stack_name="64bit Amazon Linux 2023 v4.3.0 running Docker", option_settings=[ eb.CfnEnvironment.OptionSettingProperty( namespace="aws:autoscaling:launchconfiguration", option_name="IamInstanceProfile", value=instance_profile.ref, ), eb.CfnEnvironment.OptionSettingProperty( namespace="aws:elasticbeanstalk:environment", option_name="ServiceRole", value=service_role.role_arn, ), ], ) self.env_b.add_dependency(self.app) ``` ### 2. Document EB Variables Add to `INFRA_REQUIREMENTS.md`: ```markdown ## EB Environment Variables (for CI/CD) - `EB_APP`: {project} - `EB_ENV_A`: {project}-prod - `EB_ENV_B`: {project}-idle - `EB_BUCKET`: elasticbeanstalk-{region}-{account} ``` ### 3. Verify EB Environments ```bash aws elasticbeanstalk describe-environments \ --application-name {project} \ --query 'Environments[].{Name:EnvironmentName,Status:Status,Health:Health,CNAME:CNAME}' \ --output table ``` Both environments should show `Status=Ready`. ### 4. Test ECR Push ```bash aws ecr get-login-password --region {region} \| docker login --username AWS --password-stdin {account}.dkr.ecr.{region}.amazonaws.com docker pull nginx:alpine docker tag nginx:alpine {account}.dkr.ecr.{region}.amazonaws.com/{project}:test docker push {account}.dkr.ecr.{region}.amazonaws.com/{project}:test ``` --- ## Commit (Both Paths) ```bash git add stacks/ git commit -m "infra: implement compute and container registry stack ({EKS\|EB})" ``` --- ## Deliverables (Style-Agnostic) - ✅ Compute environment running (EKS cluster with nodes OR two EB environments) - ✅ ECR repository accessible (push/pull verified) - ✅ Blue/green substrate in place (K8s namespaces OR EB environment pair) - ✅ Chosen style recorded in `INFRA_REQUIREMENTS.md` - ✅ CDK stack committed ## Inputs Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating. - Infra Repo Scaffold (Template, Required) — produced by Scaffold Infra Repo & CDK Project (#75). - VPC Stack (Code, Required) — produced by Build VPC & Networking Stack (#76). - INFRA_REQUIREMENTS.md (Document, Required) — produced by Review SAO & Define Infra Requirements (#74).
5	Build Route53 & DNS Stack	DCI-5	Build Route53 & DNS Stack Objective Implement DNS for blue/green traffic routing. Implementation differs by …	Read the 'DCI-5 Build Route53 & DNS Stack' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Build Route53 & DNS Stack ## Objective Implement DNS for blue/green traffic routing. Implementation differs by deployment style — do not mix patterns. --- ## Path Selection Refer to `INFRA_REQUIREMENTS.md` § Deployment Style. \| Style \| DNS model \| Switch mechanism \| \|-------\|-----------\|------------------\| \| EKS \| Weighted records: `prod.{domain}`, `idle.{domain}` \| `traffic_switch.py` swaps weights \| \| Elastic Beanstalk \| Single CNAME: `{domain}` → `{project}-prod.eba-…` \| EB `swap-environment-cnames` (no Route53 edit on promote) \| --- ## EKS Path Skill: AWS CDK with Python § Route53 Hosted Zone ### 1. Implement `stacks/dns_stack.py` Create hosted zone. Weighted prod/idle records managed by `scripts/traffic_switch.py` (not CDK) to avoid drift. ### 2. Create `scripts/traffic_switch.py` Actions: `switch`, `rollback`, `status` — swap Route53 weighted record targets. ### 3. Infra Makefile targets ```makefile traffic-switch: ## Swap prod/idle DNS weights python scripts/traffic_switch.py --action switch traffic-rollback: ## Restore previous weights python scripts/traffic_switch.py --action rollback ``` ### 4. Verify ```bash dig prod.{domain} dig idle.{domain} make traffic-switch && dig prod.{domain} # target changed ``` --- ## Elastic Beanstalk Path Skill: AWS EB Blue/Green Deployment § Pattern 7: Route53 for EB ### 1. DNS Mental Model ``` Public: https://app.example.com ↓ Route53 CNAME (TTL 60s) app-prod.eba-xxxxx.elasticbeanstalk.com ← fixed label name ↓ EB swap-environment-cnames whichever physical env currently owns that label ``` Critical: Route53 must point at the EB environment CNAME label (`{project}-prod.eba-…`), not the ALB ARN directly. ALB-alias breaks CNAME swap — live traffic won't follow promotion. ### 2. Implement `stacks/dns_stack.py` Use an idempotent Lambda custom resource to UPSERT the CNAME (avoids `ConflictingResourceExists` on re-deploy): ```python # Route53 CNAME: app.example.com → {project}-prod.eba-xxxxx.elasticbeanstalk.com # Lambda handler: ListResourceRecordSets + ChangeResourceRecordSets (UPSERT) ``` HTTPS terminates at the EB-managed ALB (ACM cert on :443 listener). No CloudFront required for basic setup. ### 3. No traffic_switch.py for EB Promotion is only `aws elasticbeanstalk swap-environment-cnames` (see EB skill Pattern 2). Route53 record stays fixed; EB rotates which env owns the `{project}-prod` label. ### 4. Verify ```bash dig +short app.example.com # Must resolve to whichever env currently holds app-prod.eba-… label make swap # in app repo sleep 90 # Route53 TTL + resolver cache dig +short app.example.com # same CNAME label, different backend env ``` --- ## Deliverables - ✅ EKS: hosted zone + `traffic_switch.py` + make targets - ✅ EB: CNAME to prod EB label via idempotent Lambda UPSERT - ✅ EB: documented why ALB-alias Route53 breaks swap - ✅ CDK tests passing - ✅ DNS resolving correctly for chosen style
6	Create Infra GH Workflow	DCI-6	Create Infra GitHub Actions Workflow Objective Create a GitHub Actions workflow that automates CDK infrastructure …	Read the 'DCI-6 Create Infra GH Workflow' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Create Infra GitHub Actions Workflow ## Objective Create a GitHub Actions workflow that automates CDK infrastructure deployment. Traffic switching is not in this workflow for EB — it lives in the app repo (`make swap` / `promote.yml`). --- ## Path Selection \| Style \| Infra workflow scope \| Traffic switch location \| \|-------\|---------------------\|------------------------\| \| EKS \| `cdk deploy` + optional `traffic-switch` job \| Infra repo `make traffic-switch` \| \| Elastic Beanstalk \| `cdk deploy` only \| App repo `promote.yml` or `make swap` \| --- ## Shared Pattern: Thin Wrapper Around Make ```yaml name: Infrastructure on: push: branches: [main] paths: - 'infra/' # monorepo layout # OR 'stacks/' # separate infra repo - 'cdk.json' workflow_dispatch: inputs: action: type: choice options: [deploy, status] permissions: id-token: write contents: read jobs: infra: runs-on: ubuntu-latest environment: infrastructure steps: - uses: actions/checkout@v4 - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.AWS_ROLE_ARN }} aws-region: ${{ vars.AWS_REGION }} - uses: actions/setup-python@v5 with: python-version: '3.12' - run: make provision - run: make deploy # or: cd infra && cdk deploy --all ``` > Auth: Prefer OIDC (`role-to-assume`). IAM access keys acceptable for single-team projects — see GitHub Actions Patterns skill § Release-Triggered Deploy. --- ## EKS Path Additions Add manual `traffic-switch` and `traffic-rollback` jobs with `environment: production` approval gate: ```yaml traffic-switch: if: github.event.inputs.action == 'traffic-switch' environment: production steps: - run: make traffic-switch ``` --- ## Elastic Beanstalk Path Do not add traffic-switch to infra workflow. Document in README: ```markdown ## Infra vs App deploy - Infra (this workflow): `cdk deploy --all` — VPC, EB envs, DNS CNAME, backups bucket - App (build-and-deploy.yml): test → ECR push → deploy-idle.sh → smoke - Promote (promote.yml or `make swap`): CNAME swap after human review ``` Refresh platform snapshot after console EB changes: ```bash python infra/scripts/export_eb_live_settings.py python infra/scripts/diff_eb_live_vs_cdk.py # expect 0 diffs before deploy ``` --- ## GitHub Environments \| Environment \| Reviewers \| Used for \| \|-------------\|-----------\|----------\| \| `infrastructure` \| 0–1 \| CDK deploy \| \| `production` \| 1–2 \| EKS traffic-switch or app promote.yml \| --- ## Deliverables - ✅ `.github/workflows/infra.yml` (or in `infra/.github/…` for separate repo) - ✅ CDK deploy on infra path changes - ✅ EB: no traffic-switch in infra workflow - ✅ EKS: optional traffic-switch with production approval - ✅ Workflow tested
7	Deploy & Verify Cloud Environment	DCI-7	Deploy & Verify Cloud Environment Objective Run full infrastructure deployment, verify AWS resources, and confirm …	Read the 'DCI-7 Deploy & Verify Cloud Environment' activity from playbook 'Junior Edda' (workflow 'Design & Deploy Cloud Infra'). Follow its guidance when assisting me. # Deploy & Verify Cloud Environment ## Objective Run full infrastructure deployment, verify AWS resources, and confirm blue/green switching end-to-end. Acceptance gate for DCI workflow. Follow the path matching your deployment style. --- ## Path Selection Refer to `INFRA_REQUIREMENTS.md` § Deployment Style. --- ## EKS Path ### 1. Full Deployment ```bash cd {project}-infra && make deploy ``` Expected: ~20–25 min (EKS cluster dominates). ### 2. Verify VPC, EKS, ECR, DNS ```bash kubectl get nodes # 2 Ready kubectl get ns # blue, green aws ecr describe-repositories dig prod.{domain} && dig idle.{domain} make traffic-switch && make traffic-rollback ``` ### 3. Document in `docs/architecture/INFRA_VERIFICATION.md` Use EKS checklist (VPC, subnets, NAT, EKS nodes, namespaces, ECR, Route53 weights, GH Actions deploy). --- ## Elastic Beanstalk Path ### 1. Full Deployment ```bash cd infra && cdk deploy --all --require-approval never ``` Expected: ~10–15 min (no EKS). ### 2. Verify Platform Snapshot ```bash python scripts/export_eb_live_settings.py python scripts/diff_eb_live_vs_cdk.py # Expect 0 platform diffs (secrets excluded) ``` ### 3. Verify EB Environments ```bash aws elasticbeanstalk describe-environments \ --application-name {project} \ --query 'Environments[].{Name:EnvironmentName,Status:Status,Health:Health,CNAME:CNAME,Version:VersionLabel}' \ --output table ``` Both `{project}-prod` and `{project}-idle` should be `Ready`. ### 4. Verify ECR, DNS, Backups ```bash # ECR push test aws ecr get-login-password \| docker login ... docker push {account}.dkr.ecr.{region}.amazonaws.com/{project}:verify-test # DNS: public domain → prod EB label dig +short app.example.com # S3 backup bucket exists aws s3 ls s3://{project}-db-backups-{account}/ # SSM: EB instances managed aws ssm describe-instance-information --filters Key=tag:elasticbeanstalk:environment-name,Values={project}-idle ``` ### 5. End-to-End Blue/Green (with app pipeline) Full acceptance requires app deploy — coordinate with DCD: ```bash gh release create v0.0.1-test # CI: deploy-idle.sh → idle smoke curl http://{idle-cname}/health/ # revision matches make swap # CNAME swap + prod smoke curl https://app.example.com/health/ ``` ### 6. Document in `docs/architecture/INFRA_VERIFICATION.md` \| Check \| Status \| Details \| \|-------\|--------\|---------\| \| VPC / SG \| ✅ \| … \| \| EB app + 2 envs \| ✅ \| Ready, Green/Yellow \| \| Platform snapshot diff \| ✅ \| 0 diffs \| \| ECR push/pull \| ✅ \| … \| \| Route53 CNAME → prod label \| ✅ \| not ALB-alias \| \| S3 backup bucket \| ✅ \| lifecycle 90d \| \| SSM on EB instances \| ✅ \| SendCommand works \| \| Idle deploy + smoke \| ✅ \| revision match \| \| CNAME swap + prod smoke \| ✅ \| HTTPS revision match \| --- ## Deliverables - ✅ All CDK stacks deployed for chosen style - ✅ Blue/green mechanism verified (Route53 weights or EB CNAME swap) - ✅ `docs/architecture/INFRA_VERIFICATION.md` documented - ✅ GH Actions infra deploy passing

Activities in Design & Deploy Cloud Infra