Name container by default with Image alias when starting container

[rhuss]

If an image has an <alias>, the container created during docker:start should be named with the alias. If already a container with name exists, then a suffix should be added until the name is unique. E.g. if the alias db is alread taken, try db_1, db_2, .... until a free name is found.

See #35 for a discussion about this.

[jgangemi]

so i'm just going to pick the discussion up here...

what happens if i have multiple aliases defined w/in the 'images' configuration, which one gets used?

i'm also not sure i would want the name to 'auto increment' if a container with the same name is running. personally, i would want that to be an error so perhaps that could be an option in the configuration.

[rhuss]

Each <image> in the configuration can have only one <alias> which must be unique among all images within the <images> section, e.g.

<images>
  <image>
    <name>postgresql</name>
    <alias>db</alias>
    ....
  </image>
  <image>
    <name>consol/tomcat-7.0:latest</name>
    <alias>server</alias>
    .....
  </image>
</images>

Since for each image one container is started, there can be no clash among the aliases. If no alias is provided, the container wouldn't get a custom name.

Advantage of the auto increment would be that you could still run an integration (mvn clean install) with starting and stopping of your containers even if you have still some containers up from the same image.

An alternative would be to not give the containers a name when there is already a container with this name.

But a global option would be probably ok, too. What's about having a <container-naming> ... </container-naming> with multiples modes:

• none --> no container naming enabled
• strict --> naming enabled, error when names are duplicate
• first --> only the first container gets a name, subsequents containers don't get a name
• inc --> increment a counter as suffix

?

[jgangemi]

yeah - i was thinking about this from the standpoint of using the data container and now i realize that the above solution works, i just need to change how i name the aliases for each of the images.

i'm starting to wonder if it would be better to create deploy/undeploy goals for this instead of cramming it into the existing start/stop goals.

obviously there is some overlap in functionality but that seems like it would offer more flexibility and avoid the need to do the container-mapping bits b/c we could say in the case of 'deploy' only one container w/ that name can ever exist at a time. if you wanted use a different name or deploy another instance, you could override it w/ a -D switch on the command line.

[rhuss]

I wouldn't want to have extra goals for this particular use case (also deploy doesn't sound right, this is associated more with a push to a registry, right ?).

But you can always overwrite the configured with <container-naming> with a system property:

mvn docker:start -Ddocker.containerNaming=strict
mvn clean install -Ddocker.containerNaming=none

Maybe <container-naming> (or docker.containerNaming for the property) is a bit long. Any suggestions for a shorter name ?

• <naming>
• <naming-scheme>
• ....

Hmm, don't find a better and shorter name (don't like my suggestions above because they are to generic)

[jgangemi]

i'm considering deploy in this case to be similar to that of tomcat, jboss, etc maven goals. i realize this doesn't 100% fit that model b/c you can start/stop tomcat/jboss independent of whether or not there is application code involved whereas you can't start/stop a docker container w/o the actual container itself but they are pretty close.

i still think having separate goals for this use case should be ruled out. in my case, the docker instance i am going to be deploying to is different then the docker instance i build/test against which means i need to be able to specify a different host which is somewhat cumbersome on the command line, but having a deploy goal means i could have some xml configuration that would allow me to define that host separately.

[rhuss]

Sorry, I didn't get that. You want to connect different images for different environments (dev/test) ?

Beside the fact, that I think that your approach (if I understand it right) discards a lot of the benefits that Docker can deliver (namely immutable servers which you pump through the continuous delivery pipeline as a whole with the server image being the same everywhere) you always can use different Maven profiles for different configurations and select your profile on the command line.

Or do you mean that you want to start/stop on different Docker Hosts (configuration <dockerHost>) ? and want to select the host on the command line ? The you can either use the profile approach or use -DdockerHost=tcp://... as argument.

Either way, introducing a new goal only for having different configurations is not the right way (goals are really heavy weight and must not overlap).

Another approach commonly seen is, that you docker:push your image to a registry (e.g. a private one, its easy to install) and let your CI server pull it from there. This is also in conformance with the continuous delivery mantra to build only once and reuse the artifacts (images) for the test phases until this very image goes into production.

BTW, I just see that I'm using camel case for the config, so containerNaming (or even containerNamingScheme) is better.

[jgangemi]

i want to be able to build the docker container on a build box, push it to my local registry, and then issue a command to the production server to stop the old image and pull/start the new one.

i felt having separate goals for this would make the implementation simpler b/c you could do away w/ all the different naming scheme logic. either you get a random name or the name defined in the pom. if you want to deploy two instances for whatever reason and defined a name in the pom, you need to use a -D switch to override.

as i said, your project, your rules so i'll see about making modifications to the start goal. :)

[jgangemi]

i have a basic implementation of this working but it requires the open pull requests for #108 to be merged first as it's built on top of that.

this is what the config looks like

<image>
  <name>busybox:latest</name>
  <alias>issue-48-named</alias>
  <namingScheme>alias</namingScheme>
  <run>
    <command>ping google.com</command>
  </run>
</image>

namingScheme is an enum that supports the following two values: none and alias w/ the default being none.

this resolves the use case i need to satisfy right now and the flexibility is there for more naming schemes to be added at a later date if the demand is there but for now i don't see the need.

open to suggestions if you don't like namingScheme as the element name and/or none and alias as the enum values.

[jgangemi]

this is ready to go pending the complete of the outstanding pull requests and any changes i need to sync w/ as a result.

i moved the namingScheme element into the run configuration where it makes more sense:

<image>
  <name>busybox:latest</name>
  <alias>issue-48-named</alias>
  <run>
    <command>ping google.com</command>
    <namingScheme>alias</namingScheme>
  </run>
</image>

it would be super great if 0.11.2 could be released once all the PRs (including this one when it goes up) get merged in.

[rhuss]

I'm halfway through the PRs and try my very best to release this weekend ;)

[jgangemi]

cool - i just didn't want to overwhelm you anymore then i did w/ changes stacked on changed. as soon as #110 goes in i'll sync on my end and create this PR.

[rhuss]

Fixed in 0.11.3