Pushing Containers

In order to push to Docker registries you can use the either the internal/docker-push step or the internal/docker-scratch-push step.

The difference between these two steps is that the docker-push step pushes the current container and the docker-scratch-push uses a baseimage. For more details on the internal/docker-scratch-push step see Internal steps.

The following examples show how to push to Docker registries, such as Docker Hub and Quay.io,that adhere to the docker API.

Note: When pushing to both public and private registries, make sure you’ve created the repository first.

Wercker supports pushing to the following registries:

Pushing to the public Docker Hub

deploy:
  steps:
    - internal/docker-push:
        username: $USERNAME
        password: $PASSWORD
        tag: my-amazing-tag
        repository: turing/bar
        registry: https://registry.hub.docker.com

The $USERNAME and $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 bar image), and registry is the URL of your Docker registry.

NOTE: The internal/docker-push step only works with registries that comply with the Docker Registry format. If you want to push to a registry that supports V2 of the API, simply append “/v2” to your registry URL.

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 this:

deploy:
  steps:
    - internal/docker-push:
        username: $USERNAME
        password: $PASSWORD
        tag: my-amazing-tag
        cmd: my-amazing-command
        ports: "5000"
        repository: turing/bar
        registry: https://registry.hub.docker.com

The same is true for an entrypoint directive:

deploy:
  steps:
    - internal/docker-push:
        username: $USERNAME
        password: $PASSWORD
        tag: my-amazing-tag
        entrypoint: my-entrypoint
        repository: turing/bar
        registry: https://registry.hub.docker.com

Note: If you’re pushing to the Docker Hub, the registry field is optional and can be omitted.

Pushing to Quay.io

If you want to push to a different (private) registry such, as Quay.io, you would create the following wercker.yml file:

deploy:
  steps:
    - internal/docker-push:
        username: $USERNAME
        password: $PASSWORD
        tag: my-amazing-tag
        repository: quay.io/knuth/foo
        registry: https://quay.io

Again, $USERNAME and $PASSWORD are pipeline environment variables. Prefix the repository field with the domain name of your registry when not using the Docker Hub. Here we push to the repo with username knuth and the image foo.

Pushing to the Google Container Registry (gcr.io)

When pushing to Google Container Registry (also known as gcr.io) you need authenticate by using a JSON key file associated with a service account.

Note that the username must be set to _json_key; otherwise the authentication will fail. You can store the contents of the JSON file in an environment variable called $GCR_JSON_KEY_FILE.

Also, GCR no longer supports Docker API v1, so you must append "/v2" to the registry parameter, as below. Failing to do this will result in HTTP 405 errors from GCR.

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 Amazon ECR

Pushing to ECR requires some extra paramaters, as below:

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 will be set to the branch name.