Wercker generally supports pushing to any private or public registry that implements Docker Token Authentication Specification. This page shows how to push images to the Docker registries, such as Docker Hub and Quay.io, that adhere to the
docker API. In addition to these, you'll see how you can push images to the Google Container Registry, Amazon ECR, Azure Container Registry, and Wercker Release Registry.
Note: When pushing images to both public and private registries, make sure you’ve created a repository first.
deploy: steps: - internal/docker-push: username: $USERNAME password: $PASSWORD tag: my-amazing-tag repository: turing/bar
$PASSWORD fields are environment variables that you should specify through the Wercker web interface. The
repo field contains the repository that you want to push to (in this case the username
turing with the
Note: If you’re pushing to the Docker Hub, the registry field is optional and can be omitted.
If your container needs a
cmd to be run on startup of the container along with a
port that your application listens on, you can “bake” that into the container as well using a configuration such as the following:
deploy: steps: - internal/docker-push: username: $USERNAME password: $PASSWORD tag: my-amazing-tag cmd: my-amazing-command ports: "5000" repository: turing/bar
The same is true for an
deploy: steps: - internal/docker-push: username: $USERNAME password: $PASSWORD tag: my-amazing-tag entrypoint: my-entrypoint repository: turing/bar
deploy: steps: - internal/docker-push: username: $USERNAME password: $PASSWORD tag: my-amazing-tag repository: quay.io/knuth/foo registry: https://quay.io
$PASSWORD are pipeline environment variables. Prefix the repository field with the domain name of your registry when not using the Docker Hub. Here, you push to the repo with username
knuth and the image
Note: When a registry URL does not contain a
internal/docker-pushstep authenticates with the registry using Docker Registry API v1. If you want to push to a registry that supports v2 of the API, then append “/v2” to your registry URL. You can also enable the v2 authentication by completely removing the registry field and just retaining the registry domain name as the prefix. For example:deploy: steps: - internal/docker-push: username: $USERNAME password: $PASSWORD tag: my-amazing-tag repository: quay.io/knuth/foo
Note that the username must be set to
_json_key; otherwise the authentication can fail. You can store the contents of the JSON file in an environment variable called
Also, GCR no longer supports Docker API v1, so you must append "/v2" to the registry parameter, as shown in the following example. Failing to do this can result in HTTP 405 errors from GCR. You can also omit the
deploy: - internal/docker-push: username: _json_key password: $GCR_JSON_KEY_FILE repository: gcr.io/<MY-PROJECT-ID>/<MY-IMAGE>; registry: https://gcr.io/v2
Pushing to ECR requires the following extra parameters:
box: busybox push-to-ecr: steps: - internal/docker-push: aws-access-key: $AWS_ACCESS_KEY_ID aws-secret-key: $AWS_SECRET_ACCESS_KEY aws-region: $AWS_REGION aws-registry-id: $AWS_REGISTRY_ID repository: your_repo_name
Note: If no tag is specified, the tag is set to the branch name.
The following example shows the settings required to push an image to the Azure Container Registry:
box: busybox push-to-acr: steps: - internal/docker-push: azure-client-id: $AZURE_CLIENT_ID azure-client-secret: $AZURE_CLIENT_SECRET azure-subscription-id: $AZURE_SUBSCRIPTION_ID azure-tenant-id: $AZURE_TENANT_ID azure-resource-group: $AZURE_RESOURCE_GROUP azure-registry-name: $AZURE_REGISTRY_NAME azure-login-server: $AZURE_LOGIN_SERVER repository: your_repo_name
Note: For more information on generating AZURE_CLIENT_ID or AZURE_CLIENT_SECRET, see Pushing to Azure with Wercker.