ACM.434 Also building docker containers with files from different directories or contexts and problems with buildx on Amazon Linux
In the last post I explained how I want to restructure my accounts to support the job execution framework I’m building and why I need a separate container for the initial organization deployment — because there is no job execution framework when you initially start deploying.
Here’s where I make some changes I’ve wanted to demonstrate for a while. I want to create separate repositories for each job and the job configurations so people can create and run new jobs without changing the core job execution framework.
I’m going to create separate repositories for separate components. That provides the flexibility to easily add new types of jobs (containers) which I need to do now to create my root management account initialization container.
AWSJobExecutionFramework — A repository for the framework code that executes jobs using a common set of code. When someone deploys a job they can start with this reusable code base. This code base has the code to run the jobs only, nothing job-specific.
job-awsorginit — This repository contains a Dockerfile for the initial container image used to deploy the organization, initial user and role, and the first account and organization administrator in a new AWS account. You can’t use the job execution framework when the job execution framework hasn’t been deployed.
job-awsdeploy —This repository contains a Dockerfile used to build a container image that uses the job execution framework — meaning it requires an SSM parameter that contains the job configuration and a secret with credentials in the same account to deploy the job.
jobconfig-deploy — This repository contains the configurations for deployment jobs. In order to deploy a job using the awsdeploy job, the job configuration needs to first exist in SSM Parameters store. This repository maintains the job configurations separately from…
