<p>The key words here are:</p>

<blockquote>
  <p>Pipeline on Bitbucket</p>
</blockquote>

<p>You already have a pipeline. <em>This</em> is where you would stick the deployment command. </p>

<p>AFAIK there is no standard tooling for registries to 'push out' any changes; you'd have to code a custom integrator that continually polls for changes and compares. This would be a lot of work. Same goes for having your servers directly listen for changes on the registry.</p>

<p>It would be far easiest (and is the standard) to simply have your build pipeline issue the deployment command after its successfully pushed a new image to the registry. </p>

<p>There are benefits to this: </p>

<ul>
<li>your pipeline is aware of whether the push to the registry failed or passed (and you can handle that failure gracefully with retries)</li>
<li>your pipeline will be aware of the new registry tag</li>
<li>your pipeline can control <em>exactly</em> which tag gets pushed where, when, and how quickly</li>
<li>your pipeline has the same insight to whether the deployment passed or failed, and can attempt retries or perform notifications of failure</li>
</ul>

CC BY-SA 3.0
2018-03-02T17:15:23.380Z
In general, instead of having a consumer poll a registry it's easier to just have it triggered from the pipeline pushing to the registry, even if you don't want that pipeline to actually execute the deployment for that consumer. Handy if the consumer itself is in another pipeline, for example (sometimes splitting a single complex pipeline into multiple simpler ones can be desired).
Dan Cornilescu
CC BY-SA 3.0
2018-03-02T16:24:54.863Z
2018-03-02T16:24:54.863Z
BoomShadow
<p>I'm fairly new to CI/CD so this is probably a noob question. </p>

<p>Anyway, here's my current setup: 
* Bitbucket repo
* Registry service on AWS (ECS Registry) 
* Pipeline on Bitbucket that builds a docker image on master branch update and pushes it to the registry. </p>

<p>So far so good, I'm missing the last part where my server (EC2 instance) listens for registry updates and executes a deployment command like docker-compose pull &amp;&amp; etc. </p>

<p>What tools can your recommend me to do this?</p>

<docker><continuous-deployment><registry>
trigger command on registry update
Simon Ertl
# trigger command on registry update

(Asked by: username_0 on 2018-03-02)

I'm fairly new to CI/CD so this is probably a noob question.

Anyway, here's my current setup:
\* Bitbucket repo
\* Registry service on AWS (ECS Registry)
\* Pipeline on Bitbucket that builds a docker image on master branch update and pushes it to the registry.

So far so good, I'm missing the last part where my server (EC2 instance) listens for registry updates and executes a deployment command like docker-compose pull && etc.

What tools can your recommend me to do this?

**Tags:** docker, continuous-deployment, registry


---

## 1 answers

### Answer by username_1 on 2018-03-02. Score: 2 | Accepted answer

The key words here are:

> Pipeline on Bitbucket

You already have a pipeline. *This* is where you would stick the deployment command.

AFAIK there is no standard tooling for registries to 'push out' any changes; you'd have to code a custom integrator that continually polls for changes and compares. This would be a lot of work. Same goes for having your servers directly listen for changes on the registry.

It would be far easiest (and is the standard) to simply have your build pipeline issue the deployment command after its successfully pushed a new image to the registry.

There are benefits to this:

* your pipeline is aware of whether the push to the registry failed or passed (and you can handle that failure gracefully with retries)
* your pipeline will be aware of the new registry tag
* your pipeline can control *exactly* which tag gets pushed where, when, and how quickly
* your pipeline has the same insight to whether the deployment passed or failed, and can attempt retries or perform notifications of failure

> **Comments:**
> **username_2**: In general, instead of having a consumer poll a registry it's easier to just have it triggered from the pipeline pushing to the registry, even if you don't want that pipeline to actually execute the deployment for that consumer. Handy if the consumer itself is in another pipeline, for example (sometimes splitting a single complex pipeline into multiple simpler ones can be desired).  

---

