ACM.434 Also building Docker containers with files from different directories or contexts and issues with buildx on Amazon Linux
13 hours ago
In the last article I explained how I wanted to restructure my accounts to support the task execution framework I’m building and why I need a separate container for the initial org deployment because there is no task execution framework when you initially begin deployment.
This is where I make some changes that I’ve been wanting to demonstrate for a while. I want to create separate repositories for each task and task configurations so that users can create and run new tasks without changing the base task execution framework.
I will create separate repositories for separate components. This provides the flexibility to easily add new task types (containers) that I need to do now to create my root management account initialization container.
AWSJobExecutionFramework — A repository for framework code that executes tasks using a common set of code. When someone deploys a task, they can start with this reusable code base. This codebase only contains the code to run the tasks, nothing specific to a task.
work-awsorginit — This repository contains a Dockerfile for the initial container image used to deploy the initial organization, user and role, and the first account and organization administrator to a new AWS account. You cannot use the task execution framework when it has not been deployed.
work-awsdeploy — This repository contains a Dockerfile used to build a container image that uses the task execution framework, which means it requires an SSM setting that contains the task configuration and a secret with credentials in the same account to deploy the task.
jobconfig-deployment — This repository contains deployment task configurations. In order to deploy a job using awsdeploy job, the job configuration must first exist in the SSM parameter store. This repository keeps task configurations separate from…