Ability to Specify registry per-image

[mistresseve666]

Would it be possible to, say, add a flag that would push the images to a private registry upon a successful start?

This would be helpful for CI environments, where your container runs unit/acceptance tests first before starting the main application. By pushing to the registry, you're able to create an artifact of the successful image.

See below response for additional details.

[makeusabrew]

I don't see this as part of decking's remit to be honest; in fact part of me doesn't really like it dealing with images at all. Is there any advantage here to just having the CI process explicitly docker push <img>?

[mistresseve666]

Helps automate the entire process. If you hardcode an image name in your CI script, you need to make sure it always matches the one in your decking.json file, etc.

I suppose the issue is partially miss-titled -- or asking two different things...

It would be nice to specify a private registry URL once and not have to liter it all over your decking.json file every time an image is referenced, i.e. "myregistry:5000/my/image"

For example, based on @stephenmelrose's docker-multi-container-example:

{
    "registry": {
        "myregistry": "myprivateregistry.company.com:5000",
        "bobsregistry": "bobsregistry.company.com:5000"
    }
    "images": {
        "dmce/log-data": {"file": "./images/log-data", "registry": "myregistry"},
        "dmce/mysql-data": {"file": "./images/mysql-data", "registry": "myregistry"},
        "dmce/php-base": {"file": "./images/php-base", "registry": "myregistry"},
        "dmce/php-dev": {"file": "./images/php-dev", "registry": "myregistry"},
        "bob/nginx": {"registry": "bobsregistry"}
    },
    "containers": {
        // ...
        "nginx": {
            "image": "bob/nginx",
            "port": ["80"],
            "dependencies": ["php:php"],
            "mount-from": ["log-data"]
        }
    }
}

A new section is added that specifies registeries used. A registry key of "docker" could be reserved to refer to the official docker registry.

The images values become an object, with a registry keyword specifying which registry it should pull the image from. A file keyword can be added to specify you want the image built, and then possibly pushed to a specific registry if specified.

If an image is defined within the images section, it effectively becomes an alias to registry:imagename. You'd be able to, maybe do:

    "images": {
        "docker/nginx": {"registry": "docker", "name": "nginx"},
        "nginx": "./images/my-nginx"
    },

to specify a custom name for the official nginx image, and use "nginx" as a name for your personal nginx image.

It sounds convoluted, but for cases where you need to use combinations of images from various registries it'll help reduce the amount of registryhost:port scattered across the decker.json file.

[makeusabrew]

I can't see image names changing very frequently as part of a decking manifest, so the issue of having to manually keep them in sync between decking and a CI workflow isn't too much of a big deal. Given that the file is just JSON it'd be easily enough to pluck the images out of if it was something which really did need automating as part of a larger workflow.

The secondary point about making private (or alternative) repositories a bit more of a first class concept carries a bit more merit, but at the same time introduces a conflict with the first motivation - because you could quite legitimately docker pull nginx but not have permissions to docker push. Making decking aware of the nuances between what's pushable and what's not just isn't worth it.

I'll give the registries (or registry) key some thought as it does carry merit; you're right that repeating a registry name everywhere is a pain, but then again the way docker implements custom repositories by baking them into the image name (last time I looked - admittedly around Docker 0.8 or so) is pretty repetitive anyway so it's not an extra burden Decking imposes on users. If anything I'd be tempted to look at being able to nest images to keep it even DRYer, but that imposes its own problems. E.g.

"images": {
  "myprivateregistry.company.com:5000": {
        "dmce/log-data": "path/to/dockerfile",
        "dmce/mysql-data": "path/to/dockerfile"
    }
  }

Although that of course makes it harder to parse images Vs registry declarations etc.

Will give it some thought.