wf_dockerfile_build
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_repousing 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_pathandbuild_context(paths relative to the root ofcode_repo) with the build-time arguments and secrets provided bysecretsandargs, respectively. - Merge the generated images into a multi-platform image and push
the result to the ECR repository indicated by
image_repowith the image tag set to the git commit hash of the code that was checked out fromcode_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
We provide an example of using this module here.
The critical configuration values are:
code_repo: The repository containing your Dockerfile and code to build.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/barthen 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.
Providers
The following providers are needed by this module:
-
aws (5.80.0)
-
kubectl (2.1.3)
-
kubernetes (2.34.0)
-
pf (0.0.7)
Required Inputs
The following input variables are required:
code_repo
Description: The URL of the git repo containing the Dockerfile to build. Must NOT contain a protocol prefix.
Type: string
image_repo
Description: The name of the AWS ECR repository where generated images will be pushed
Type: string
name
Description: The name of the WorkflowTemplate
Type: string
namespace
Description: The namespace to deploy the WorkflowTemplate into
Type: string
Optional Inputs
The following input variables are optional (have default values):
args
Description: A mapping of build-time arguments to their respective values
Type: map(string)
Default: {}
build_context
Description: Relative path from the root of the repository to the build context to submit to BuildKit
Type: string
Default: "."
build_timeout
Description: The number of seconds after which the build will be timed out
Type: number
Default: 3600
code_storage_gb
Description: The size of the volume to mount the code into
Type: number
Default: 1
cpu_millicores
Description: The amount of CPU to allocate to pods in the workflow (in millicores)
Type: number
Default: 25
dockerfile_path
Description: Relative path from the root of the repository to the Dockerfile / Containerfile to submit to Buildkit
Type: string
Default: "./Dockerfile"
extra_ecr_repo_arns_for_pull_access
Description: ARNs of private ECR repositories from which the Dockerfile pulls base images FROM
Type: list(string)
Default: []
git_password
Description: The password to use when checking out the code to deploy
Type: string
Default: ""
git_ref
Description: The default git ref to checkout and build if none is provided to the WorkflowTemplate when executing the Workflow
Type: string
Default: "main"
git_username
Description: The username to use when checking out the code to deploy
Type: string
Default: ""
image_tag_prefix
Description: The prefix to prepend to the image tag
Type: string
Default: ""
memory_mb
Description: The amount of memory to allocate to pods in the workflow (in MB)
Type: number
Default: 100
pull_through_cache_enabled
Description: Whether to use the ECR pull through cache for the deployed images
Type: bool
Default: true
push_image_enabled
Description: True iff images should be pushed to ECR in addition to being built
Type: bool
Default: true
secrets
Description: A mapping of build-time secret ids to their respective values
Type: map(string)
Default: {}
Outputs
The following outputs are exported:
arguments
Description: The arguments to the WorkflowTemplate
aws_role_arn
Description: The name of the AWS role used by the Workflow's Service Account
aws_role_name
Description: The name of the AWS role used by the Workflow's Service Account
entrypoint
Description: The name of the first template in the Workflow
name
Description: The name of the WorkflowTemplate
Maintainer Notes
No notes