wanderland-aws-pack adds the aws adapter kind to wanderland-core's adapter registry and ships the boundaries and resolvers an AWS deployment runs on. The live advaita-deploy projects — az2, ars, parsing, parsing-cel, aem — boot on this pack. Their deploys reach AWS through three things the pack provides: the aws adapter (one mount per service, method_missing forwarding to the SDK), the CloudFormation provisioner that drives a stack through a change set, and the !SsmLookup resolver that reads cross-stack infrastructure addresses at dispatch.
The weight on this page follows the weight in the configs. cfn_provisioner and publish_cfn_outputs fill the provision and publish slots of infrastructure_deployment, and cfn_provisioner is also the actor inside the deploy component of every containerized_deployment project that ships its ECS service as CloudFormation. !SsmLookup and the !Verify IAM pre-flight run on every deploy. The ECS-API boundaries (ecs_service_deploy and friends) define the task definition and service inline in the deployment YAML instead of in CloudFormation; that path is legacy. The ECS read boundaries are diagnostics.
Add the gem and the per-service SDK gems the adapter wraps. The entry file requires wanderland-core, registers the aws adapter kind, requires every boundary, requires the !SsmLookup resolver, and registers the IAM-role ARN pattern with the global Patterns registry.
# Gemfile
gem "wanderland-aws-pack", path: "../wanderland-aws-pack"
gem "aws-sdk-cloudformation", "~> 1.0"
gem "aws-sdk-ecs", "~> 1.0"
gem "aws-sdk-ssm", "~> 1.0"
gem "aws-sdk-ecr", "~> 1.0"
The deploy path — the boundaries and resolvers a CloudFormation-shaped project uses:
| Symbol | Slot / role | What it does |
|---|---|---|
cfn_provisioner |
provision slot, or the deploy component actor |
Drive a CFN stack through a change set; apply and preview modes |
publish_cfn_outputs |
publish slot |
Read the stack's outputs, write each to SSM at /<system>/<environment>/<sub_environment>/<logical_id> |
publish_components |
publish slot, multi-stack |
Walk pipeline.components and publish each component's stack outputs |
!SsmLookup |
resolver (:dispatch) |
Read an SSM parameter at dispatch, or verify its existence at boot |
!Verify IAM pattern |
boot pre-flight | Wrap a role ARN; boot batches one iam:GetRole per unique role |
ecr_repository_provisioner |
collect / pre-build | Ensure the ECR repository at args.image_name exists; describe, then create on a miss |
ecr_docker_login |
collect / pre-build | Log the local docker daemon into the ECR registry derived from args.image_name |
The direct-ECS path (legacy) — define the task definition and service inline in the deployment YAML and drive them through the ECS API, skipping CloudFormation. ecs_service_deploy is the deploy-slot wrapper; it dispatches the three sub-boundaries below. The CloudFormation path above keeps one source of truth for the ECS resources and is what the application services run, so treat this set as legacy:
| Symbol | Role | What it does |
|---|---|---|
ecs_service_deploy |
deploy slot wrapper |
Register the task def, create/update the service, wait for stability |
register_task |
sub-step | Register an ECS task definition from aws.AWS::ECS::TaskDefinition.<name> |
poke_service |
sub-step | Create or update an ECS service from aws.AWS::ECS::Service.<name> |
wait_service_stable |
sub-step | Poll ECS until the service has one active deployment at desired_count |
Diagnostics and promotion reads — read-only boundaries that report state or feed a promotion. live_image runs as a collect step on a deploy-only run, reading the image a running service uses so the next stage promotes it. The rest answer questions:
live_image (collect promotion read) · ecs_cluster_report · ecs_describe_cluster · ecs_list_services · ecs_describe_services · ecs_describe_task_definition · aws_caller_identity · verify_aws_resources · cfn_template_analyzer.
ecs_service_deploy defines the task definition and service inline in the deployment YAML — aws.AWS::ECS::TaskDefinition.<name> and aws.AWS::ECS::Service.<name> — and drives them through the ECS API. It is a wrapper: it dispatches register_task (register the task definition), then poke_service (create the service, or update it to the new task def), then wait_service_stable (poll until one active deployment sits at desired_count). A sub-boundary's halt becomes the wrapper's halt.
Treat this path as legacy. Declaring the service and task definition in CloudFormation keeps one source of truth for the ECS resources and is the path the application services run; this boundary set is likely to be retired. The vivarta-jenkins controller deploy is the remaining inline user.