fabric8io / docker-maven-plugin Goto Github PK
View Code? Open in Web Editor NEWMaven plugin for running and creating Docker images
Home Page: https://dmp.fabric8.io
License: Apache License 2.0
Maven plugin for running and creating Docker images
Home Page: https://dmp.fabric8.io
License: Apache License 2.0
having this in the readme would be super useful.
TL;DR; it'd be nice to add strings like "docker.from", "docker.registry" to the build configuration class.
e.g. on all these @parameter values:
https://github.com/rhuss/docker-maven-plugin/blob/master/src/main/java/org/jolokia/docker/maven/config/BuildImageConfiguration.java#L15
Also allowing maven properties to be used to define env vars & ports would be nice using docker.env.NAME=value and docker.port.container.NAME=8080 as properties.
Rather long background on this....
So on the fabric8 project we're reusing your awesome maven plugin for generating & pushing docker images, we're also generating kubernetes json files too:
http://fabric8.io/v2/mavenPlugin.html#generating-the-json
then a parallel project called Jube which implements a pure kubernetes implementation without docker (for folks running java middleware on non-linux or non-docker based operating systems) - which makes docker-like images (which are just zips with shell scripts so can be run on any platform that has a JVM):
http://fabric8.io/jube/mavenPlugin.html#building-your-image-zip
we've found there's often lots of common stuff between these 3 maven plugins (docker / fabric8 / jube) for building images or generating kubernetes json. Things like the base image name, the image name, the env vars, the ports.
Using maven properties can help keep configuration DRY; since we can inherit stuff and put configuration into base projects (as its often folks have multiple images with the same base; or often expose similar ports or env vars).
e.g. this parent project defines a bunch of ActiveMQ stuff so defines the image name (based on maven aritfact) along with exposing the jolokia contianer port and defines the docker.baseImage.
https://github.com/jstrachan/quickstarts/blob/changes/apps/pom.xml#L38
(Note I'm just about to migrate all these from 0.9.x :)
So what would be nice is to be able to use maven properties to configure the build configuration.
e.g. on all these @parameter values:
https://github.com/rhuss/docker-maven-plugin/blob/master/src/main/java/org/jolokia/docker/maven/config/BuildImageConfiguration.java#L15
it'd be nice to have a name, like "docker.from", "docker.registry" so we can share configuration between parent/child poms - and share configuration between maven plugins too.
One thing we found with the generation of kubernetes json and jube image zips; things like env vars and ports tend to be additive; you often have base things and wish to add new ports; or override env vars etc. So again using maven properties turned out to be a nice way to do it. e.g. any pom.xml can expose an extra container port via adding
<docker.port.container.jolokia>8778</docker.port.container.jolokia>
(BTW we used the '.container' suffix as kubernetes (and docker really) has the idea of internal container ports and external host ports; while the docker images don't yet allow you to specify the latter, certainly in kubernetes we can).
So for env vars and ports we found that just adding a little bit of code that if the user has not supplied a List/Map of ports/env vars, we look in the maven properties and build the list/map from those. e.g.
Here's the code:
https://github.com/jstrachan/fabric8/blob/changes/fabric8-maven-plugin/src/main/java/io/fabric8/maven/JsonMojo.java#L373-373
we're currently using "fabric8.env.FOO" as the naming convention; but I'd prefer it if we could all use "docker.env.FOO" really for all 3 maven plugins; then users can just configure things once in a nice DRY way.
e.g.
https://github.com/jstrachan/quickstarts/blob/changes/apps/fabric8-mq-autoscaler/pom.xml#L37-37
we use the same approach to defining labels in kubernetes json too; it works very nicely in maven as maven properties are much more composable.
I can supply a PR if you like; its really just adding a few strings to some @parameter values; and adding a factory method on the env vars / ports if there is nothing configured to look at the maven properties and create the List/Map from them. I figured I'd explain my thoughts first to see what you think
If an image is specified without a tag, autoPulling
works a bit weird currently:
latest
but another image with another tag is there then an error occursI would like it to work like that if no tag is specified:
latest
locally.latest
.i feel this is a bit different then issue #8, which is why i created a new one...
how do you feel about a docker:logs
command that mimics docker logs
? to start, it could perform the same default behavior as docker logs <container_id>
and additional features could be added later.
i'm finding myself typing mvn docker:logs
after running a mvn docker:start
only to realize that won't work which is rather annoying. :)
I wonder if we should post process it in some ways to shrining or replace bad characters; or at least validate it up front so that the build fails immedately so that folks don't spend a while building an image that can never be pushed since the image name isn't valid to push to a repo?
I.e. when pulling new images, a registry should be configurable
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.
Authentication against the docker daemon should be possible.
Hi again!
My project is making docker image using your plugin. This image is very simple and just contains a jar file and the command to run it. But the problem is that my jar file which were rpoduced by maven and it starts just fine, has different size than the one, copied to docker image. And the one in image cannot be started, image also cannot be run by docker because it says: Error: Invalid or corrupt jarfile maven/dlr-application-0.0.2-SNAPSHOT.jar
This is the size of copied to docker image jar:
-rw-rw-r-- 1 vagrant vagrant 35580429 Nov 18 17:17 dlr-application-0.0.2-SNAPSHOT.jar
And this is the size of the same jar, produced by maven:
-rw-rw-r-- 1 vagrant vagrant 20991343 Nov 18 17:17 dlr-application-0.0.2-SNAPSHOT.jar
so as you can see, first one which is copied by docker-maven-plugin is almost 2 times bigger and does not start.
Data container created with an assembly are cleaned up automatically with stop
, however, the image for this container still remains. We need an option/mechanism to get rid of this image as well.
sometimes folks wanna build stuff and push to the global registry; sometimes folks wanna push to a local registry. I wonder if the registry host should default to using an environment variable rather than a maven build property; as its kind of an environment thing?
e.g. I found we had to add these instructions to add a custom profile to ~/.m2/settings/xml to enable the 'default to env var' behaviour. I figured it might be nice to have this by default?
http://fabric8.io/v2/mavenPlugin.html#specifying-the-location-of-your-local-docker-registry
e.g. if a build is intended to use a private docker registry then maybe its better to get this from an environment variable?
i have the following in my assembly descriptor (it's just the relevant snippet)
<fileSet>
<directory>${project.build.scriptSourceDirectory}</directory>
<outputDirectory>/</outputDirectory>
<filtered>true</filtered>
<includes>
<include>startup.sh</include>
</includes>
<fileMode>755</fileMode>
</fileSet>
when my container gets built, the startup script doesn't have the correct permissions. i'm not sure if this something that should work in the context of this plugin or not.
i also tried setting the permission directly on the local filesystem to see if they carry over but was unsuccessful there as well. right now i'm working around this by specifying bash startup.sh
as the command but that somewhat less then idea.
is this a bug? if not, do you have any suggestions on how this could be handled? i want this contained within the data container that gets built rather then mucking w/ the image that will be running it (which in this case is the 'official' tomcat instance).
A new configuration option (like <env>
) should be added to allow setting of environment variables when starting the container (similar to the -e
option in docker run
)
docker:stop doesn't seem to be stopping the container. running mvn w/ the '-X -e' flags shows it configuring the mojo but not executing any calls to the container afterwards.
PR on its way....
I've seen a few folks trip up over this as right now it defaults to "http://localhost:2375" which will only work on linux. At least checking for DOCKER_HOST first will make it work well on Macs :)
Hi guys!
I am using your docker-maven-plugin. I configured docker to run on vagrant box and my application to create docker image and push it into a custom registry. The problem is that locally everything works just fine, but when I try to do the same using Jenkins job with the same maven version, settings and the same java version, it gives an error: [ERROR] Failed to execute goal org.jolokia:docker-maven-plugin:0.10.4:build (default-cli) on project dlr-parent: Unable to parse configuration of mojo org.jolokia:docker-maven-plugin:0.10.4:build: Error loading class 'org.jolokia.docker.maven.Image'
I have no any idea what can be wrong.
I was getting quite confused trying to figure out why the push wasn't working. I kept getting the errors shown below.
Turns out adding -Ddocker.username=jolokia -Ddocker.password=jolokia to the CLI fixed it. (Thanks for figuring that out @iocanel!).
I wonder if the plugin could do a big warning if the system properties are not specified and a server id (of the registry host:port) is not available; so new users grok what they need to do.
e.g. if there's no authConfig values and no system properties for docker.username / docker.password and no ~/.m2/settings.xml we should fail the build and output a big warning telling folks to add an authConfig, set the system properties or add something like this to their ~/.m2/settings.xml:
<server>
<id>192.168.59.103:5000</id>
<username>jolokia</username>
<password>jolokia</password>
</server>
then lots of users who just see this error will thank you ;)
INFO] --- docker-maven-plugin:0.9.12:build (default-cli) @ fabric8-mq ---
[INFO] Copying files to /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker/maven
[INFO] Building tar: /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker-tmp/docker-build.tar
[INFO] DOCKER> Created data image 192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT
[INFO]
[INFO] --- docker-maven-plugin:0.9.12:push (default-cli) @ fabric8-mq ---
[INFO] Copying files to /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker/maven
[INFO] Building tar: /workspace/java/fabric8-quickstarts/apps/fabric8-mq/target/docker-tmp/docker-build.tar
[INFO] DOCKER> Created data image 192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT
[WARNING] DOCKER> Couldn't parse answer chunk 'EOF
': org.json.JSONException: A JSONObject text must begin with '{' at 1 [character 2 line 1]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23.221s
[INFO] Finished at: Wed Nov 12 14:59:41 GMT 2014
[INFO] Final Memory: 39M/366M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.jolokia:docker-maven-plugin:0.9.12:push (default-cli) on project fabric8-mq: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jolokia:docker-maven-plugin:0.9.12:push (default-cli) on project fabric8-mq: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error)
at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:87)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image '192.168.59.103:5000/fabric8/fabric8-mq:2.0-SNAPSHOT' (code: 500, Internal Server Error)
at org.jolokia.docker.maven.access.DockerAccessUnirest.processChunkedResponse(DockerAccessUnirest.java:547)
at org.jolokia.docker.maven.access.DockerAccessUnirest.processPullOrPushResponse(DockerAccessUnirest.java:467)
at org.jolokia.docker.maven.access.DockerAccessUnirest.pullOrPushImage(DockerAccessUnirest.java:264)
at org.jolokia.docker.maven.access.DockerAccessUnirest.pushImage(DockerAccessUnirest.java:251)
at org.jolokia.docker.maven.PushMojo.executeInternal(PushMojo.java:23)
at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:85)
... 21 more
[ERROR]
Beside creating a plain data image on the fly which gets volume-linked into another container, it would be nice to support a mode where a base image (e.g. containing the app-server) and the created artefacrs are baked together to a single image which then can be pushed along.
It shouldn't be hard to extend the current approach:
It could be, that this is already possible ;-)
In order to avoid starting/stopping add an option docker.skip
which prevents any docker related option.
Especially for Micro Service which are build into a data image and started from there it would be nice to specify a defaul command as well. Currently the command from the base image is used (if any).
i have all my application specific properties in an external file that gets pulled into the build via a filter for substitutions, etc - this lets me clean up the poms and keep build/application properties in separate places.
i'd like to be able to do this for properties i've defined in the docker maven config (eg bind ports, etc) and pull in the appropriate file based on the active profile.
it's possible this is already covered by the impending external configuration updates (i haven't looked at the code yet) but if it's not, i could see that being a big hit w/ that functionality.
thoughts? wiling to tackle this myself, just want to have a discussion first. :)
being able to provision a single WAR artifact as a ROOT.war would be a nice assemblyDescriptorRef value; I can see folks wanting to provision a single WAR into tomcat as a container.
I can supply a PR if you like?
When using multiples containers (see #15) then it should be possible to link them together.
Currently the "raw" name of the warfile is in use, ie "myproject-1.0.0-SNAPSHOT.war", instead of the name specified in the build / finalName section of the pom.
Similar to https://github.com/spotify/docker-maven-plugin it should be possible to further tune the parameters for building the data image:
Dockerfile
BTW, @rculbertson, wouldn't it be an option to merge efforts ? I.e. one of the highlights of this plugin is to use a plain maven-assembly-plugin decscriptor for creating the data container (which is much more flexible than including files via path only).
A way for getting artefacts and depdendency as files into a container should be provided. This should work also with indirect setups like boot2docker. If possible, this should work with docker means alone, without requiring support by the container in use.
Some thoughts on this:
ADD
, build the image, create a container and link it to the container to start. This would still hold all the preconditions described above (works with indirect setups, no specific container setup required, etc ...), but it might be somewhat costly to create a temporary image only for getting files into a container.None of the solution above is without drawbacks. What is your suggestion ? Is there any elegant way to accomplish this ?
Maybe the scp suggestion is the most lightweight solution and a container need to be 'maven aware' anyway if he wants to do something with the artefacts coming in (like putting them into a directory like webapps
).
We are using a wildfly base image with an applied patch. The Dockerfile is
# Use the wildfly-8.1.0.Final image
FROM tdiesler/wildfly:8.1.0.Final
MAINTAINER Thomas Diesler <[email protected]>
# [TODO] Why does this not work?
# ADD wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /opt/jboss/wildfly
# Copy & Extract the WildFly Camel patch
COPY wildfly-camel-patch-1.0.0.CR3-SNAPSHOT.tar.gz /tmp/wildfly-camel-patch.tar.gz
RUN tar -xzf /tmp/wildfly-camel-patch.tar.gz -C /opt/jboss/wildfly
# Set the default command to run on boot
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone-camel.xml", "-b", "0.0.0.0"]
It seems that I cannot apply a patch with the docker-maven-plugin because it replaces /opt/jboss/wildfly and does not add to it.
To reproduce, please build
https://github.com/tdiesler/wildfly-camel/tree/docker-mvn-plugin
In docker/pom.xml I commented out the wanted target config
As we now have a way for create data docker container, it would be nice to not use it only for linking this into the app-server container during integration testing but also to offer a possibility to push it to a registry so that it can be used as a deployment mechanism.
So I can totally do this...
http://fabric8.io/v2/mavenPlugin.html#example
mvn clean install docker:build
docker push $DOCKER_REGISTRY/mydemo/war-camel-servlet:2.0.0-SNAPSHOT
(or I can type docker push XXX and just copy/paste the image name from the output of the "mvn docker:build) and that works too.
but if I try "docker:push") I always get a failure:
mvn clean install docker:push -X
[ERROR] Failed to execute goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:push (default-cli) on project fabric8-mq: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:push (default-cli) on project fabric8-mq: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error)
at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:84)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.plugin.MojoExecutionException: Error while pushing image 'dockerhost:5000/fabric8/fabric8-mq:2.0.0-SNAPSHOT' (code: 500, Internal Server Error)
at org.jolokia.docker.maven.access.DockerAccessUnirest.processChunkedResponse(DockerAccessUnirest.java:503)
at org.jolokia.docker.maven.access.DockerAccessUnirest.processPullOrPushResponse(DockerAccessUnirest.java:423)
at org.jolokia.docker.maven.access.DockerAccessUnirest.pullOrPushImage(DockerAccessUnirest.java:240)
at org.jolokia.docker.maven.access.DockerAccessUnirest.pushImage(DockerAccessUnirest.java:227)
at org.jolokia.docker.maven.PushMojo.executeInternal(PushMojo.java:23)
at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:82)
... 21 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
I've not had chance to delve into whats wrong though
Currently, only a name can be provided for push. Maybe it would be nice to allow multiple tags as well. Also, check, whether it makes sense to use a dedicated <registry>
config option.
why not just treat these as a list (same way as a maven configuration) so the various forms for mappings are supported?
docker.maven.ports.1 = 5678:8080
docker.maven.ports.2 = 0.0.0.0:80:80
docker.maven.ports.3 = host.port:22
i stumbled across this working on pull request #60.
The timeout for contacting the docker server should be configurable
When starting a container it would be nice to be wait for a certain text pattern in the output to appear. Along with 'waitand
waitForHttpthe new configuration option
waitForOutput` would add for fine control of the startup process.
as we build an image in a release, it'd be good to be able to also tag the base image too (if we can); so that if we wish we can rebuild a new version reusing the previous version.
So having a mvn goal to be able to pull and tag your base images first at the start of a release build; then using that exact version for the rest of the build would be great. Folks can then choose to either pull & retag; or reuse previous tagged base image versions.
This also avoids the base images changing during the build process; we can force a single pull per release build of each base image; they then get tagged and from then on we reuse the exact same image or all other images
Referencing docker issue moby/moby#8176
When stopping containers started during integration testing, the docker engine was returning a 500 error.
Tracing the error on my docker engine, I find the following:
Nov 24 09:11:52 integration2 docker: Cannot destroy container ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Driver devicemapper failed to remove root filesystem ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Device is Busy
Nov 24 09:11:52 integration2 docker: [50c6bc48] -job delete(ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e) = ERR (1)
Nov 24 09:11:52 integration2 docker: [error] server.go:1062 Handler for DELETE /containers/{name:.*} returned error: Cannot destroy container ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Driver devicemapper failed to remove root filesystem ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Device is Busy
Nov 24 09:11:52 integration2 docker: [error] server.go:91 HTTP Error: statusCode=500 Cannot destroy container ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Driver devicemapper failed to remove root filesystem ea0320f63b4c12fb08c1b703dfe5595a10fadef7e98eb6a69edc377924c0de1e: Device is Busy
I was able to replicate the same problem from the docker CLI by running:
docker run -d myimage/etc
wait for container to fully initialize.
docker stop ImgID;docker rm ImgId
results in the same error.
However, placing a pause into the operation allows the docker engine to complete the stop before the remove
docker stop ImgId; sleep 1000; docker rm ImgId works fine.
Add support for Fig and the successor Docker compositions via the new external configuration mechanism.
fig (http://www.fig.sh/) can manage development env easily. now docker-maven-plugin support "Starting and stopping Docker containers for integration testing and development". any idea to support " Starting and stopping Docker containers from fig.yml for integration testing and development"
it'd be nice if we just replaced "tcp://" with "http://" internally.
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:build (default-cli) on project java-camel-cdi: Execution default-cli of goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:build failed: java.net.MalformedURLException: unknown protocol: tcp
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.jolokia:docker-maven-plugin:0.9.10-SNAPSHOT:build failed: java.net.MalformedURLException: unknown protocol: tcp
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: java.lang.RuntimeException: java.net.MalformedURLException: unknown protocol: tcp
at com.mashape.unirest.request.HttpRequest.getUrl(HttpRequest.java:104)
at com.mashape.unirest.http.HttpClientHelper.prepareRequest(HttpClientHelper.java:164)
at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:128)
at com.mashape.unirest.request.BaseRequest.asString(BaseRequest.java:56)
at org.jolokia.docker.maven.access.DockerAccessUnirest.request(DockerAccessUnirest.java:321)
at org.jolokia.docker.maven.access.DockerAccessUnirest.hasImage(DockerAccessUnirest.java:72)
at org.jolokia.docker.maven.AbstractDataImageSupportMojo.checkImage(AbstractDataImageSupportMojo.java:137)
at org.jolokia.docker.maven.AbstractDataImageSupportMojo.createDataImage(AbstractDataImageSupportMojo.java:118)
at org.jolokia.docker.maven.BuildMojo.executeInternal(BuildMojo.java:19)
at org.jolokia.docker.maven.AbstractDockerMojo.execute(AbstractDockerMojo.java:78)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
... 20 more
Caused by: java.net.MalformedURLException: unknown protocol: tcp
at java.net.URL.<init>(URL.java:592)
at java.net.URL.<init>(URL.java:482)
at java.net.URL.<init>(URL.java:431)
at java.net.URI.toURL(URI.java:1096)
at com.mashape.unirest.request.HttpRequest.parseUrl(HttpRequest.java:50)
at com.mashape.unirest.request.HttpRequest.getUrl(HttpRequest.java:102)
... 30 more
[ERROR]
It should be possible to specify and start multiple containers during integration testing.
i need to bind/export volumes as mount points when a container starts up. this would allow a workaround for containers that do not do this already do this (eg. the 'official' docker tomcat container).
i was going to suggest just adding a child element to volumes
but perhaps that would be confusing, so maybe exports
instead? eg:
<exports>
<export>/path/in/container</export>
<export>/path/in/host:/path/in/container</export>
</exports>
let me know thoughts, i have an immediate need for this and can spend some time on it in the coming days (followed by the naming issue as that's now 2nd on my list).
I'd like to be able to pass in variables when creating a docker image with "mvn docker:build".
PR on its way!
doing so would allow me to maintain a single assembly descriptor for a project when i am also creating a zip export.
it doesn't need to do anything else but function as a symbolic name (based upon the description of it's usage in the maven docs).
It should be possible to stream logging output to the console of the build during an integration test (using docker logs
in some way)
Instead of waiting a fixed amount of time when starting a container, there should be a possibility for pinging an URL or port. The plugin should wait until this is available or until a timeout has occurred.
While building, only when pulling an image (which takes some time) log output is printed. Instead it would be nice to have all build steps printed.
Probably in some grey color so that it doesnot get into the way (use advance ANSI here).
so imagine you're working in development on an image that you wanna push to a registry so you can use it on multiple boxes (e.g. with kubernetes); so you might wanna use something like this...
<docker.image>${env.DOCKER_REGISTRY}/mystuff/${project.artifactId}:${project.version}</docker.image>
then wherever your private docker registry is at $DOCKER_REGISTRY you're good to go.
However then at some point you might wanna release these images to the global registry. Now we could replace the $DOCKER_REGISTRY with registry.index.docker.io; however the common convention is to omit a registry prefix if its the global one in docker image names.
So we'd wanna switch from ${env.DOCKER_REGISTRY}/mystuff/${project.artifactId}:${project.version} to just mystuff/${project.artifactId}:${project.version} when doing a release.
So I'm wondering is it maybe cleaner to not specify the registry in the image name; but use docker.registry instead? Then if docker.registry is specified and its not the public registry, the mvn plugins would prefix the image name with it; then do things the usual docker way - otherwise it would be omitted?
To do this on the fabric8 quickstarts I had to hack this a bit with profiles ;)
e.g. I defined a docker.registryPrefix property:
https://github.com/fabric8io/quickstarts/blob/master/apps/pom.xml#L39
which defaults to "${env.DOCKER_REGISTRY}/" which I then add to the front of docker names.
Then I use a profile (docker-public) to override this in each build....
https://github.com/fabric8io/quickstarts/blob/master/apps/pom.xml#L117
it works but it'd be kinda nicer to just specify the docker.registry (maybe on the CLI) and for that to work and do the right thing in terms of image name (omitting it from the image name if its a public image, or appending it for non-public registries)
Might be useful to remove temporary images/containers during building of an image. AFAIK there is a dedicated Docker API option for this in a recent API version.
i'm trying to build a data volume for an nginx and based on the directions, i need to place content in the following two places
/usr/nginx/share/html
/etc/nginx
to do this i set my /
and manage the output directories in the assembly.xml
file. the problem is /
is turned into a volume which makes the container unusable.
i'd like to propose the addition of a volumes
element that takes an explicit list of volumes to expose and if this is tag has values, it overrides exposing exportDir
as a volume.
thoughts?
Instead of being a pure flag, these variable should parse their content an use it as a list of image names to start / stop.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.