Container Registry

• Quay [builds, analyzes, distributes] your container images

https://quay.io/

• Registrator automatically registers and deregisters services for any Docker container by inspecting containers as they come online. Registrator supports pluggable service registries, which currently includes Consul, etcd and SkyDNS 2.

https://github.com/gliderlabs/registrator

• Docker Hub

Dev-test pipeline automation, 100,000+ free apps, public and private registries
https://hub.docker.com/

• Docker Hub is a cloud-based registry service which allows you to link to code repositories, build your images and test them, stores manually pushed images, and links to Docker Cloud so you can deploy 

images to your hosts.
It provides a centralized resource for container image discovery, distribution and change management, user and team collaboration, and workflow automation throughout the development pipeline.

Docker Hub provides the following major features:

    Image Repositories: Find and pull images from community and official libraries, and manage, push to, and pull from private image libraries to which you have access.
    Automated Builds: Automatically create new images when you make changes to a source code repository.
    Webhooks: A feature of Automated Builds, Webhooks let you trigger actions after a successful push to a repository.
    Organizations: Create work groups to manage access to image repositories.
    GitHub and Bitbucket Integration: Add the Hub and your Docker Images to your current workflows.

Docker Hub contains a number of Official Repositories. These are public, certified repositories from vendors and contributors to Docker

Docker Hub provides a place for you and your team to build and ship Docker images.
    Repositories, which allow you to push images from a local Docker daemon to Docker Hub, and
    Automated Builds, which link to a source code repository and trigger an image rebuild process on Docker Hub when changes are detected in the source code.
You can create public repositories which can be accessed by any other Hub user, or you can create private repositories with limited access you control.

A Docker Hub organization can contain public and private repositories just like a user account

Docker Hub repositories let you share images with co-workers, customers, or the Docker community at large.
If you’re building your images internally, either on your own Docker daemon, or using your own Continuous integration services, you can push them to a Docker Hub repository that you add to your Docker Hub user or organization account

Alternatively, if the source code for your Docker image is on GitHub or Bitbucket, you can use an “Automated build” repository, which is built by the Docker Hub services

When creating a new repository, you can choose to put it in your Docker ID namespace, or that of any organization that you are in the “Owners” team

You can add multiple images to a repository, by adding a specific :<tag> to it (for example docs/base:testing)
If it’s not specified, the tag defaults to latest.
You can name your local images  when you build it, using docker build -t <hub-user>/<repo-name>[:<tag>]
You can name your local images by re-tagging an existing local image docker tag <existing-image> <hub-user>/<repo-name>[:<tag>]
You can name your local images  by using docker commit <exiting-container> <hub-user>/<repo-name>[:<tag>] to commit changes.
docker push <hub-user>/<repo-name>:<tag>

A collaborator is someone you want to give access to a private repository. Once designated, they can push and pull to your repositories.


You can use a Hub repository webhook to notify people, services, and other applications after a new image is pushed to your repository (this also happens for Automated builds).
For example, you can trigger an automated test or deployment to happen as soon as the image is available.

A webhook is called only after a successful push is made.
The webhook calls are HTTP POST requests with a JSON payload.
If you have an automated build repository in Docker Hub, you can use Webhooks to cause an action in another application in response to an event in the repository. Docker Hub webhooks fire when an image is built in, or a new tag is added to, your automated build repository.
If you want to test your webhook, we recommend using a tool like requestb.in


Webhook chains allow you to chain calls to multiple services. For example, you can use this to trigger a deployment of your container only after it has been successfully tested, then update a separate Changelog once the deployment is complete
The first webhook in a chain will be called after a successful push. Subsequent URLs will be contacted after the callback has been validated.

You can build your images automatically from a build context stored in a repository.
A build context is a Dockerfile and any files at a specific location.
For an automated build, the build context is a repository containing a Dockerfile.
Automated Builds are supported for both public and private repositories on both GitHub and Bitbucket.

To use automated builds, you must have an account on Docker Hub and on the hosted repository provider (GitHub or Bitbucket).

Repository links let you link one Automated Build with another. If one Automated Build gets updated, Docker triggers a build of the other.

https://docs.docker.com/docker-hub/

• If you have an automated build repository in Docker Hub, you can use Webhooks to cause an action in another application in response to an event in the repository. Webhook is a POST request sent to a defined URL which provides the service. Docker Hub webhooks fire when an image is built in, or a new tag is added to, your automated build repository.

https://docs.docker.com/docker-hub/webhooks/

• Docker Cloud can integrate with your Slack team to provide notifications about stacks, services, containers, and nodes.

Only failures Only receive notifications about failed actions, containers that stop with a failed exit code, and nodes that become unreachable.
https://docs.docker.com/docker-cloud/slack-integration/