keepRunning, keepContainer should use its value for image names

[fabric8io]

keepRunning, keepContainer should use its value for image names

[jgangemi]

as mentioned previously, i do want to contribute to this project and first up is adding the ability to specify a container name when it is started. given this functionality is related, thought we should discuss...

i'm not sure what you've proposed here makes sense...what if i specify a name for 'keepRunning' and 'keepContainer', which one gets used?

would it be better to just leave those as boolean flags and create a top level element (name, containerName, something else?) that can be used to configure this?

[rhuss]

Perfect, your contributions are highly appreciated ;-) (Please note, that I'm adding soon a document explaining how to contribute best which is a bit similar to the way docker does, especially the sign off. 'hope that's ok for you)

Currently the configuration of this plugin is centered around Images. For building and pushing stuff this is the natural choice. But also for creating and running containers this makes things simpler: Containers are started on the fly from named images and then also stopped. Image names take two forms: A full repository name (e.g. consol/tomcat:7.0) and a custom alias (like server) which is known only within the plugins. So all container related operations are done by specifying the image name or alias and the plugin keeps the relations between the image and the container internal. This makes thins easier to explain and less complicated to use (because you cannot confuse image and container names).

Until there is a good use case for explicitly naming containers I would like to keep it that simple.

For example:

Consider we have two images: postgresql (alias: "db") and consol/tomcat:7.0 (alias: "server"). Then you can use

 # Create and start DB container:
 mvn docker:start -Dimage=db

 # Start both ....
 mvn docker:start -Dimage=db,server

  # ... or of course
 mvn docker:start

 # Stop only the containers created from the DB image:
 mvn docker:stop -Dimage=db

And for -DkeepRunning and -DkeepContainer I would like to have the same semantics:

 # Keep all containers running after integration test:
 mvn clean install -DkeepRunning

 # ... or
 mvn clean install -DkeepRunning=db,server

 # Keep only the DB container running:
 mvn clean install -DkeepRunning=db

 # Remove all containers except the server container
 mvn clean install -DkeepContainer=server

Does this sound reasonable to you ? (I'm really open for adding container names if there is a good use case).

(BTW, the code for matching an image name or alias from a property is here. Should be moved probably in an utility class)

[jgangemi]

your project, your rules - although i do see the sign off thing as being an issue but only from the sense of just forgetting to do it.

thanks for the explanation, that clarifies what you're looking for.

as for naming, i want to use this plugin to do actual deployments to docker outside of just unit-testing (this was my original impetus to add the host binding, which as an aside, seems to be missing from the updated documentation) and not being able to name the container means i have no idea what application it actually corresponds to, eg:

CONTAINER ID        IMAGE                 COMMAND                CREATED             STATUS              PORTS                     NAMES
a2f7f7c648e9        azul/zulu-openjdk:8   "java -jar /maven/re   21 hours ago        Up 4 seconds        0.0.0.0:49154->8080/tcp   dreamy_colden       

dreamy_colden is not very descriptive of what this container actually is and i don't want to go around re-tagging the jdk image just to indicate what app it's being used for.

[rhuss]

I would avoid the signing stuff, too but people recommend this as a common practice.

Back to technics ;-)

I see your point now. There are in principle two patterns, how images are created and run:

• Two containers, one generic one (like your Java image) and one data containers holding the (micro) service and which is started directly. This command is cut off in your example and the image name is too generic. Indeed, here a container name would be beneficial.
• One single container from a merged image, which has the generic (java) image as base and the service within this image, too. This image has a new, specific name which makes it easy to recognize with docker ps (that's how I often do it)

My suggestion is as follows: By default, wie name the container with the Image alias (if given). If this name is already taken, a number is added (this can be the case if you start the container multiple times).

Additionally one might then add an option like noContainerNaming but this is probably not even necessary.

What do you think about this solution ?

I will open a new issue for this. Thanks for explaining your use case to me ....

[rhuss]

I'm closing this issue and let's continue over at #48