Argo Workflow Template: Dockerfile Build Deployment

This module will only run inside of clusters that have the kube_buildkit addon deployed.

This module creates an Argo WorkflowTemplate that will use BuildKit to build a Dockerfile from an indicated code repository and push it to the account’s ECR registry.

In particular, generated Workflows will perform the following actions:

Check out the source code indicated by code_repo using our standard checkout process.
Automatically configure authentication with the ECR registry for the account where the Workflow runs.
Scale-up the cluster’s BuildKit instances if needed.
Submit both arm64 and amd64 builds to BuildKit using the indicated dockerfile_path and build_context (paths relative to the root of code_repo) with the build-time arguments and secrets provided by secrets and args, respectively.
Merge the generated images into a multi-platform image and push the result to the ECR repository indicated by image_repo with the image tag set to the git commit hash of the code that was checked out from code_repo.

Arguments for Generated Workflows

Parameter	Default	Order	Description
`git_ref`	`var.git_ref`	0	The git reference to use when checking out the `var.code_repo` for the build.

Usage

Here is an example of using the module:

module "image_builder" {
  source = "${var.pf_module_source}wf_dockerfile_build${var.pf_module_ref}"

  name = "image-builder"
  namespace = local.namespace

  code_repo = "github.com/example-org/service.git"
  dockerfile_path = "./Dockerfile"
  build_context = "."
  image_repo = "example-service"
  args = {}
  secrets = {}
}

The critical configuration values are:

code_repo: The repository containing your Dockerfile and code to build.
image_repo: The AWS ECR repository where the container images will be pushed.
dockerfile_path: (Optional) A relative path from the root of the repo to your Dockerfile (or Containerfile).
build_context: (Optional) The build context to submit to BuildKit.
args: (Optional) The build arguments to set.
secrets: (Optional) The build secrets to set.

Make sure you review our guide on how to optimize your Dockerfiles and build processes.

Authenticating with Private Code Repositories

git_username and git_password can be used for authenticating with a private code_repo. See our documentation for what values to provide. The only permissions needed by this Workflow is read access to the source code.

Using Private Base Images

If your Dockerfile sources images from a private ECR repository such as this:

FROM xxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/some-image:latest
RUN /foo/bar

then you will need to grant this Workflow permissions to pull from those repositories. To do that, provide the ECR repository ARNs to the extra_ecr_repo_arns_for_pull_access input.

Note that if any provided ECR repository is in a separate AWS account from this Workflow, you must also follow this guide.

Build Instance Sizing

The containers running in this workflow only perform very basic orchestration operations. The build processes actually occur directly in the BuildKit instances.

If you are finding you need to increase the resource requests or limits for your build processes, you will need to adjust the parameters of the kube_buildkit module.

Single Platform Images

By default, this module will build a multi-platform image that can run on both arm64 and amd64 architectures. However, if you are running in an environment where you only need to support a single architecture, you can set either arm_builder_enabled or amd_builder_enabled to false.