Except for the assembly configuration all other configuration options are ignored for now.

When only a single image should be built with a Dockerfile no XML configuration is needed at all. All what need to be done is to place a Dockerfile into the top-level module directory, alongside to pom.xml . You can still configure global aspects in the plugin configuration, but as soon as you add an <image> in the XML configuration, you need to configure also the build explicitly.

The image name is by default set from the Maven coordinates ( %g/%a:%l , see Image Name for an explanation of the params which are essentially the Maven GAV) This name can be set with the property docker.name .

If you want to add some <run> configuration to this image for starting it with docker:run then you can add an image configuration but without a <build> section in which case the Dockerfile will be picked up, too. This works only for a single image, though.

fabric8-maven-plugin filters given Dockerfile with Maven properties, much like the maven-resource-plugin does. Filtering is enabled by default and can be switched off with a build config <filter>false</filter> . Properties which we want to replace are specified with the ${..} syntax. Replacement includes Maven project properties such as ${project.artifactId} , properties set in the build, command-line properties, and system properties. Unresolved properties remain untouched.

This partial replacement means that you can easily mix it with Docker build arguments and environment variable reference, but you need to be careful. If you want to be more explicit about the property delimiter to clearly separate Docker properties and Maven properties you can redefine the delimiter. In general, the filter option can be specified the same way as delimiters in the resource plugin. In particular, if this configuration contains a * then the parts left, and right of the asterisks are used as delimiters.

For example, the default <filter>${*}</filter> parse Maven properties in the format that we know. If you specify a single character for <filter> then this delimiter is taken for both, the start and the end. E.g a <filter>@</filter> triggers on parameters in the format @…​@ , much like in the maven-invoker-plugin . Use something like this if you want to clearly separate from Docker builds args. This form of property replacement works for Dockerfile only. For replacing other data in other files targeted for the Docker image, please use the maven-resource-plugin or an assembly configuration with filtering to make them available in the docker build context.

The following example uses a Dockerfile in the directory src/main/docker/demo and replaces all properties in the format @property@ within the Dockerfile.

<plugin>
 <configuration>
   <images>
     <image>
       <name>user/demo</name>
       <build>
         <dockerFileDir>demo</dockerFileDir>
         <filter>@</filter>
       </build>
     </image>
   </images>
 </configuration>
</plugin>

This plugin supports so call dmp-plugins which are used during the build phase. dmp-plugins are enabled by just declaring a dependency in the plugin declaration:

<plugin>
  <groupId>io.fabric8</groupId>
  <artifactId>docker-maven-plugin</artifactId>
  <dependencies>
    <dependency>
      <groupId>io.fabric8</groupId>
      <artifactId>run-java-sh</artifactId>
      <version>1.2.2</version>
    </dependency>
  </dependencies>
</plugin>

These plugins contain a descriptor META-INF/maven/io.fabric8/dmp-plugin with class names, line-by-line:

io.fabric8.runsh.RunShLoader

During a build with docker:build , those classes are loaded and certain fixed method are called.

The following methods are supported:

If a configured plugin does not provide method of this name and signature, then it will be simply ignored. Also, no interface needs to be implemented to keep the coupling low.

The following official dmp-plugins are known and supported:

All build relevant configuration is contained in the <build> section of an image configuration. The following configuration options are supported:

Map specifying the value of Docker build args which should be used when building the image with an external Dockerfile which uses build arguments. The key-value syntax is the same as when defining Maven properties (or labels or env ). This argument is ignored when no external Dockerfile is used. Build args can also be specified as properties as described in Build Args

buildOptions

Map specifying the build options to provide to the docker daemon when building the image. These options map to the ones listed as query parameters in the Docker Remote API and are restricted to simple options (e.g.: memory, shmsize). If you use the respective configuration options for build options natively supported by the build configuration (i.e. squash , noCache , cleanup=remove for buildoption forcerm=1 and args for build args) then these will override any corresponding options given here. The key-value syntax is the same as when defining environment variables or labels as described in Setting Environment Variables and Labels .

buildx

Specifies the buildx configuration for multi-architecture images. See Buildx Options

createImageOptions

Map specifying the create image options to provide to the docker daemon when pulling or importing an image. These options map to the ones listed as query parameters in the Docker Remote API and are restricted to simple options (e.g.: fromImage, fromSrc, platform).

cleanup

Cleanup dangling (untagged) images after each build, including any stopped containers created from them. Also cleanup dangling images as a result of image tagging, auto-pulling a base image, or auto-pulling a cacheFrom image. Default is try , which tries to remove the old image, but doesn’t fail the build if this is not possible (e.g. because the image is still used by a running container). Other possible values are remove , if you want to fail the build, or none , to skip cleanup altogether.

contextDir

Path to a directory used for the build’s context. You can specify the Dockerfile to use with dockerFile , which by default is the Dockerfile found in the contextDir . The Dockerfile can be also located outside of the contextDir , if provided with an absolute file path. See External Dockerfile for details.

A command to execute by default (i.e. if no command is provided when a container for this image is started). See Startup Arguments for details.

compression

The compression mode how the build archive is transmitted to the docker daemon ( docker:build ) and how docker build archives are attached to this build as sources ( docker:source ). The value can be none (default), gzip or bzip2 .

dockerFile

Path to a Dockerfile which also triggers Dockerfile mode . See External Dockerfile for details.

dockerFileDir ( deprecated in favor of contextDir )

Path to a directory holding a Dockerfile and switch on Dockerfile mode . See External Dockerfile for details. This option is deprecated in favor of _contextDir and will be removed for the next major release_.

dockerArchive

Path to a saved image archive which is then imported. See Docker archive for details.

entryPoint

An entrypoint allows you to configure a container that will run as an executable. See Startup Arguments for details.

The environments as described in Setting Environment Variables and Labels .

filter

Enable and set the delimiters for property replacements. By default properties in the format ${..} are replaced with Maven properties. You can switch off property replacement by setting this property to false . When using a single char like @ then this is used as a delimiter (e.g @…​@ ). See Filtering for more details.

The base image which should be used for this image. If not given this default to busybox:latest and is suitable for a pure data image.

fromExt

Specific pull policy for the base image. This overwrites any global pull policy. See the globale configuration option imagePullPolicy for the possible values and the default.

loadNamePattern

Scan the archive specified in dockerArchive and find the actual repository and tag in the archive that matches this name pattern . After loading the archive, link the image name configured in the POM to the repository and tag matched in the archive.

labels

Labels as described in Setting Environment Variables and Labels .

maintainer

The author ( MAINTAINER ) field for the generated image

network

Set the networking mode for the RUN instructions during build

noCache

Don’t use Docker’s build cache. This can be overwritten by setting a system property docker.noCache when running Maven.

squash

Squash newly built layers into a single new layer. This can be overwritten by setting a system property docker.squash when running Maven.

cacheFrom

A list of <image> elements specifying image names to use as cache sources. During image build, it will attempt to pull these images, but not fail the build. Follows imagePullPolicy semantics.

optimise

if set to true then it will compress all the runCmds into a single RUN directive so that only one image layer is created.

ports

The exposed ports which is a list of <port> elements, one for each port to expose. Whitespace is trimmed from each element and empty elements are ignored. The format can be either pure numerical ("8080") or with the protocol attached ("8080/tcp").

shell

Shell to be used for the runCmds . It contains arg elements which are defining the executable and its params.

runCmds

Commands to be run during the build process. It contains run elements which are passed to the shell. Whitespace is trimmed from each element and empty elements are ignored. The run commands are inserted right after the assembly and after workdir into the Dockerfile. This tag is not to be confused with the <run> section for this image which specifies the runtime behaviour when starting containers.

if set to true disables building of the image. This config option is best used together with a maven property

skipPush

if set to true disables pushing of the image. This config option is best used together with a maven property

skipTag

If set to true this plugin won’t add any tags to images. Property: docker.skip.tag

List of additional tag elements with which an image is to be tagged after the build. Whitespace is trimmed from each element and empty elements are ignored.

User to which the Dockerfile should switch to the end (corresponds to the USER Dockerfile directive).

volumes

List of volume elements to create a container volume. Whitespace is trimmed from each element and empty elements are ignored.

workdir

Directory to change to when starting the container.

useDefaultExcludes

If set to true this plugin won’t include any hidden files in the docker image.

From this configuration this Plugin creates an in-memory Dockerfile, copies over the assembled files and calls the Docker daemon via its remote API.

<build>
  <from>java:8u40</from>
  <maintainer>[email protected]</maintainer>
    <tag>latest</tag>
    <tag>${project.version}</tag>
  </tags>
  <ports>
    <port>




    
8080</port>
  </ports>
  <volumes>
    <volume>/path/to/expose</volume>
  </volumes>
  <buildOptions>
    <shmsize>2147483648</shmsize>
  </buildOptions>
  <shell>
      <arg>/bin/sh</arg>
      <arg>-c</arg>
    </exec>
  </shell>
  <runCmds>
    <run>groupadd -r appUser</run>
    <run>useradd -r -g appUser appUser</run>
  </runCmds>
  <entryPoint>
    <!-- exec form for ENTRYPOINT -->
      <arg>java</arg>
      <arg>-jar</arg>
      <arg>/opt/demo/server.jar</arg>
    </exec>
  </entryPoint>
  <assembly>
    <mode>dir</mode>
    <targetDir>/opt/demo</targetDir>
    <descriptor>assembly.xml</descriptor>
  </assembly>
</build>

In order to see the individual build steps you can switch on verbose mode either by setting the property docker.verbose or by using <verbose>true</verbose> in the Global configuration

5.1.2. Assembly

The <assembly> element within <build> has an XML structure and defines how build artifacts and other files can enter the Docker image. Multiple <assembly> elements may be specified by adding them to an <assemblies> element. If both <assembly> and <assemblies> are present in <build> , the <assembly> element is treated as if it were the last child of <assemblies> .

When multiple assemblies are provided, each will be added as a separate layer in the image.

Assembly name, which is maven by default. This name is used for the archives and directories created during the build. This directory holds the files specified by the assembly. If an external Dockerfile is used than this name is also the relative directory which contains the assembly files. If multiple assemblies are provided, they must each have a unique name.

targetDir

Directory under which the files and artifacts contained in the assembly will be copied within the container. The default value for this is /<assembly name> , so /maven if name is not set to a different value. This option has no meaning when an external Dockerfile is used.

inline

Inlined assembly descriptor as described in Assembly Descriptor below.

descriptor

Path to an assembly descriptor file, whose format is described Assembly Descriptor below.

descriptorRef

Alias to a predefined assembly descriptor. The available aliases are also described in Assembly Descriptor below.

dockerFileDir

Directory containing an external Dockerfile. This option is deprecated, please use <dockerFileDir> directly in the <build> section .

exportTargetDir

Specification whether the targetDir should be exported as a volume. This value is true by default except in the case the targetDir is set to the container root ( / ). It is also false by default when a base image is used with from since exporting makes no sense in this case and will waste disk space unnecessarily.

ignorePermissions

Specification if existing file permissions should be ignored when creating the assembly archive with a mode dir . This value is false by default. This property is deprecated, use a permissions of ignore instead.

Mode how the how the assembled files should be collected:

keep to respect the assembly provided permissions, exec for setting the executable bit on all files (required for Windows when using an assembly mode dir )

auto to let the plugin select exec on Windows and keep on others.

tarLongFileMode

Sets the TarArchiver behaviour on file paths with more than 100 characters length. Valid values are: "warn"(default), "fail", "truncate", "gnu", "posix", "posix_warn" or "omit"

User and/or group under which the files should be added. The user must already exist in the base image.

It has the general format user[:group[:run-user]] . The user and group can be given either as numeric user- and group-id or as names. The group id is optional.

If a third part is given, then the build changes to user root before changing the ownerships, changes the ownerships and then change to user run-user which is then used for the final command to execute. This feature might be needed, if the base image already changed the user (e.g. to 'jboss') so that a chown from root to this user would fail. ( This third user part has been marked as deprecated and will not be supported in future versions of this plugin. )

For example, the image jboss/wildfly use a "jboss" user under which all commands are executed. Adding files in Docker always happens under the UID root. These files can only be changed to "jboss" is the chown command is executed as root. For the following commands to be run again as "jboss" (like the final standalone.sh ), the plugin switches back to user jboss (this is this "run-user") after changing the file ownership. For this example a specification of jboss:jboss:jboss would be required.

In the event you do not need to include any artifacts with the image, you may safely omit this element from the configuration.

Assembly Descriptor

With using the inline , descriptor or descriptorRef option it is possible to bring local files, artifacts and dependencies into the running Docker container. A descriptor points to a file describing the data to put into an image to build. It has the same format as for creating assemblies with the maven-assembly-plugin with following exceptions:

<formats> are ignored, the assembly will allways use a directory when preparing the data container (i.e. the format is fixed to dir )

The <id> is ignored since only a single assembly descriptor is used (no need to distinguish multiple descriptors)

Also you can inline the assembly description with a inline description directly into the pom file. Adding the proper namespace even allows for IDE autocompletion. As an example, refer to the profile inline in the data-jolokia-demo 's pom.xml.

Alternatively descriptorRef can be used with the name of a predefined assembly descriptor. The following symbolic names can be used for descriptorRef :

artifact-with-dependencies

Attaches project’s artifact and all its dependencies. Also, when a classpath file exists in the target directory, this will be added to.

artifact

Attaches only the project’s artifact but no dependencies.

dependencies

Attaches only the project’s dependencies. Also, when a classpath file exists in the target directory, this will be added too.

release-dependencies

Attaches only the project’s released (non-snapshot) dependencies.

snapshot-dependencies

Attaches only the project’s snapshot dependencies.

project

Attaches the whole Maven project but without the target/ directory.

rootWar

Copies the artifact as ROOT.war to the exposed directory. I.e. Tomcat will then deploy the war under the root context.

will add the created artifact with the name ${project.build.finalName}.${artifact.extension} and all jar dependencies in the targetDir (which is /maven by default).

All declared files end up in the configured targetDir (or /maven by default) in the created image.

<images>
  <image>
    <build>
      <assemblies>
        <assembly>
            <name>deps-release</name>
            <descriptorRef>release-dependencies</descriptorRef>
            <targetDir>/work/lib</targetDir>
        </assembly>
        <assembly>
            <name>deps-snapshot</name>
            <descriptorRef>snapshot-dependencies</descriptorRef>
            <targetDir>/work/lib</targetDir>
        </assembly>
        <assembly>
            <descriptorRef>artifact</descriptorRef>
            <targetDir>/work</targetDir>
        </assembly>
      </assemblies>
      .....
    </build>
  </image>
</images>

will create three layers:

If the assembly references the artifact to build with this pom, it is required that the package phase is included in the run. Otherwise the artifact file, can’t be found by docker:build . This is an old outstanding issue of the assembly plugin which probably can’t be fixed because of the way how Maven works. We tried hard to workaround this issue and in 90% of all cases, you won’t experience any problem. However, when the following warning happens which might lead to the given error:

[WARNING] Cannot include project artifact: io.fabric8:helloworld:jar:0.20.0; it doesn't have an associated file or directory.
[WARNING] The following patterns were never triggered in this artifact inclusion filter:
o  'io.fabric8:helloworld'
[ERROR] DOCKER> Failed to create assembly for docker image  (with mode 'dir'): Error creating assembly archive docker: You must set at least one file.

then you have two options to fix this:

In the following example a dependency from the pom.xml is included and mapped to the name jolokia.war . With this configuration you will end up with an image, based on busybox which has a directory /maven containing a single file jolokia.war . This volume is also exported automatically.

<assembly>
  <inline>
    <dependencySets>
      <dependencySet>
        <includes>
          <include>org.jolokia:jolokia-war</include>
        </includes>
        <outputDirectory>.</outputDirectory>
        <outputFileNameMapping>jolokia.war</outputFileNameMapping>
      </dependencySet>
    </dependencySets>
  </inline>
</assembly>

Another container can now connect to the volume an 'mount' the /maven directory. A container from consol/tomcat-7.0 will look into /maven and copy over everything to /opt/tomcat/webapps before starting Tomcat.

If you are using the artifact or artifact-with-dependencies descriptor, it is possible to change the name of the final build artifact with the following:

<build>
  <finalName>your-desired-final-name</finalName>
</build>

Please note, based upon the following documentation listed here , there is no guarantee the plugin creating your artifact will honor it in which case you will need to use a custom descriptor like above to achieve the desired naming.

Currently the jar and war plugins properly honor the usage of finalName .

5.1.3. Startup Arguments

Using entrypoint and cmd it is possible to specify the entry point or cmd for a container.

The difference is, that an entrypoint is the command that always be executed, with the cmd as argument. If no entrypoint is provided, it defaults to /bin/sh -c so any cmd given is executed with a shell. The arguments given to docker run are always given as arguments to the entrypoint , overriding any given cmd option. On the other hand if no extra arguments are given to docker run the default cmd is used as argument to entrypoint .

5.1.4. Build Args

As described in section Configuration for external Dockerfiles Docker build arg can be used. In addition to the configuration within the plugin configuration you can also use properties to specify them:

Set a system property when running Maven, eg.: -Ddocker.buildArg.http_proxy=http://proxy:8001 . This is especially useful when using predefined Docker arguments for setting proxies transparently.

Set a project property within the pom.xml , eg.:

5.1.5. Healthcheck

Healthchecks has been introduced since Docker 1.12 and are a way to tell Docker how to test a container to check that it’s still working. With a health check you specify a command which is periodically executed and checked for its return value. If the healtcheck return with an exit 0 the container is considered to be healthy, if it returns with 1 then the container is not working correctly.

The healtcheck configuration can have the following options

Command to execute, which can be given in an shell or exec format as described in Startup Arguments .

interval

Interval for how often to run the healthcheck. The time is specified in seconds, but a time unit can be appended to change this.

Mode of the healthcheck. This can be cmd which is the default and specifies that the health check should be executed. Or none to disable a health check from the base image. Only use this option with none for disabling some healthcheck from the base image.

retries

How many retries should be performed before the container is to be considered unhealthy.

startPeriod

Initialization time for containers that need time to bootstrap. Probe failure during that period will not be counted towards the maximum number of retries. However, if a health check succeeds during the start period, the container is considered started and all consecutive failures will be counted towards the maximum number of retries. Given in seconds, but another time unit can be appended.

timeout

Timeout after which healthckeck should be stopped and considered to have failed. Given in seconds, but another time unit can be appended.

5.1.6. Multi-Architecture Build

Buildx is enabled when there is a non-empty <platform> element inside the <buildx> configuration.

The local image cache cannot hold multi-architecture images nor can it have two platform specific images of the same name. Thus the build goal will build and save a single-architecture image to the local image cache if possible:

If the <platform> element contains more than one platform including the native platform, the native platform be used.

If the <platform> element contains more than one platform not including the native platform, no image will be built.

These rules only apply to the image built and loaded into the local image cache with the build goal. They do not apply to the push goal which will always build and push either a single-architecture or multi-architecture image with whatever platforms are specified in the <platform> element.

The recommended <buildx> configuration is to specify all supported platforms, including the native platform, in the <platform> element. This allows local integration testing of the build image from the local cache. During install or deploy phase, the build machine will build and push a multi-architecture image containing all specified platforms to the registry. Any downstream consumers, regardless of native architecture, will be able to use the multi-architecture image.

The <buildx> element within <build> defines how to build multi-architecture images.

builderName

Name of builder to use with buildx. If not supplied, the builder is named maven . The builder is created as necessary. The builder manages the build cache.

driverOpts

Optional list of driverOpts to use with the builder. The driverOpts are passed to the builder when it is created.

nodeName

Specify the name of the node to be created or modified.

configFile

Configuration file for builder. Non-absolute files are relative to the maven project directory. If configFile starts with ~/ , the configuration file is relative to the user’s home directory.

dockerStateDir

State directory for docker builder. This directory holds docker builder configurations and context state. Sharing a state directory across builds will share the cache and will decrease pull times. Non-absolute files are relative to the maven project directory. If dockerConfigDir starts with ~/ , the configuration directory is relative to the user’s home directory.

platforms

A list of <platform> elements specifying platform to build. A platform has syntax of OS/architecture (e.g. linux/amd64, linux/arm64, darwin/amd64). Each <platform> element may have a comma separated list of platforms. Empty <platform> elements are ignored. If no platform architecture is specified, buildx is not used. You can use

attestations

The configuration of attestation modes. The <provenance> element may be set to min , max , or false . The <sbom> element may be set to true or false . The <provenance> element defaults to min and the <sbom> element defaults to false .

cacheFrom

A value to be passed through to the --cache-from option of docker buildx build . See docker buildx reference docs .

cacheTo

A value to be passed through to the --cache-to option of docker buildx build . See docker buildx reference docs .

secret

Two Maps, under envs and files of <ID>VALUE</id> elements specifying the values of Docker Buildx secret to give to the build as --secret id=ID[,[env|src]=VALUE] .

5.2. docker:start

This goal creates and starts docker containers. This goal evaluates the configuration’s <run> section of all given (and enabled images).

Also you can specify docker.follow as system property so that the docker:start will never return but block until CTRL-C is pressed. That is similar to the option -i for docker run . This will automatically switch on showLogs so that you can see what is happening within the container. Also, after stopping with CTRL-C, the container is stopped (but not removed so that you can make postmortem analysis). docker:run is an alias for docker:start with docker.follow enabled.

By default container specific properties are exposed as Maven properties. These properties have the format docker.container.<alias>.<prop> where <alias> is the name of the container (see below) and <prop> is one of the following container properties:

Instead of the <alias> a fixed property key can be configured in the image’s <run> configuration with the option exposedPropertyKey .

For example the Maven property docker.container.tomcat.ip would hold the Docker internal IP for a container with an alias "tomcat". You can set the global configuration exposeContainerInfo to an empty string to not expose container information that way or to a string for an other prefix than docker.container .

5.2.1. Configuration

In addition to the Global configuration , this goal supports the following global configuration options.

containerNamePattern

Default pattern for naming all containers when they are created. See Container Names for details.

docker.containerNamePattern

showLogs

In order to switch on globally the logs showLogs can be used as global configuration (i.e. outside of <images> ). If set it will print out all standard output and standard error messages for all containers started. As value the images for which logs should be shown can be given as a comma separated list. This is probably most useful when used from the command line as system property docker.showLogs .

docker.showLogs

startParallel

Starts docker images in parallel while dependencies expressed as Link or dependsOn are respected. This option can significantly reduce the startup time because independent containers do not need to wait for each other.

docker.startParallel

autoRemove

If true automatically remove the container when it exits. This has no effect if Restart Policy has been set.

capAdd

List of add elements to specify kernel parameters to add to the container.

capDrop

List of drop elements to specify kernel parameters to remove from the container.

sysctls

Map of namespaced kernel parameters ( sysctls ) to set in the container.

Command which should be executed at the end of the container’s startup. If not given, the image’s default command is used. See Startup Arguments for details.

containerNamePattern

Pattern for naming the container when it is created. See Container Naming Strategy for details.

domainname

Domain name for the container

List of host elements specifying dns servers for the container to use

dnsSearch

List of host elements specifying dns search domains

entrypoint

Entry point for the container. See Startup Arguments for details.

Environment variables as subelements which are set during startup of the container. They are specified in the typical maven property format as described Environment and Labels .

envPropertyFile

Path to a property file holding environment variables. If given, the variables specified in this property file overrides the environment variables specified in the configuration.

extraHosts

List of host elements in the form host:ip to add to the container’s /etc/hosts file. Additionally, you may specify a host element in the form host:host to have the right side host ip address resolved at container startup.

exposedPropertyKey

Set the property part for the exposed container properties as described above . This will take precedence of the image’s alias which is the default value. For example, when this property is set to jboss , then for this container its IP address is exposed in Maven property docker.container.jboss.ip regardless how the image is named.

hostname

Hostname of the container

imagePullPolicy

Specific pull policy for downloading the image. This overwrites any global pull policy. See the global imagePullPolicy configuration option for the possible values and the default.

labels

Labels which should be attached to the container. They are specified in the typical maven property format as described in Environment and Labels .

links

Network links for connecting containers together as described in Network Links .

Log configuration for whether and how log messages from the running containers should be printed. This also can configure the log driver to use. See Logging for a detailed description.

isolation

This option sets container’s isolation technology. See Isolation for a detailed description.

memory

Memory limit in bytes.

memorySwap

Total memory limit (memory + swap) in bytes. Set memorySwap equal to memory to disable swap. Set to -1 to allow unlimited swap.

namingStrategy

This option is deprecated, please use a containerNamePattern instead Naming strategy for how the container name is created:

portPropertyFile

File path into which the mapped port properties are written. The format of this file and its purpose are also described in Port mapping

ports

Port mappings for exposing container ports to host ports.

platform

Specify an explicit platform to use when starting a docker container. May be set with property docker.platform . Defaults to native platform.

privileged

If true give container full access to host

readOnly

If true mount the container’s root filesystem as read only

restartPolicy

Restart Policy

securityOpts

List of <opt> elements to specify kernel security options to add to the container. See below for an example.

shmSize

Size of /dev/shm in bytes.

If true disable creating and starting of the container. This option is best used together with a Maven property which can be set from the outside.

stopMode

Specifies how to stop a running container. It supports the modes graceful and kill as values, with graceful being the default.

tmpfs

List countaintin <mount> elements for directories to mount with a temporary filesystem. Optionally, mount options can be appended after a ':'. See below for an example.

ulimits

ulimits for the container. This list contains <ulimit> elements which three sub elements:

<name> : The ulimit to set (e.g. memlock ). Please refer to the Docker documentation for the possible values to set

<hard> : The hard limit

<soft> : The soft limit

volumes

Volume configuration for binding to host directories and from other containers. See Volumes for details.

Condition which must be fulfilled for the startup to complete. See Wait for all possible ways to wait for a startup condition.

workingDir

Working directory for commands to run in

5.2.2. Environment and Labels

When creating a container one or more environment variables can be set via configuration with the env parameter

If you put this configuration into profiles you can easily create various test variants with a single image (e.g. by switching the JDK or whatever).

It is also possible to set the environment variables from the outside of the plugin’s configuration with the parameter envPropertyFile . If given, this property file is used to set the environment variables where the keys and values specify the environment variable. Environment variables specified in this file override any environment variables specified in the configuration.

Labels can be set inline the same way as environment variables:

<labels>
   <com.example.label-with-value>foo</com.example.label-with-value>
   <version>${project.version}</version>
   <artifactId>${project.artifactId}</artifactId>
</labels>

5.2.3. Port Mapping

The <ports> configuration contains a list of port mappings. Whitespace is trimmed from each element and empty elements are ignored. Each mapping has multiple parts, each separate by a colon. This is equivalent to the port mapping when using the Docker CLI with option -p .

A port stanza may take one of the following forms:

18080:8080

Tuple consisting of two numeric values separated by a : . This form will result in an explicit mapping between the docker host and the corresponding port inside the container. In the above example, port 18080 would be exposed on the docker host and mapped to port 8080 in the running container.

host.port :80

Tuple consisting of a string and a numeric value separated by a : . In this form, the string portion of the tuple will correspond to a Maven property. If the property is undefined when the start task executes, a port will be dynamically selected by Docker in the ephemeral port range and assigned to the property which may then be used later in the same POM file. The ephemeral port range is configured by the /proc/sys/net/ipv4/ip_local_port_range kernel parameter, which typically ranges from 32678 to 61000. If the property exists and has numeric value, that value will be used as the exposed port on the docker host as in the previous form. In the above example, the docker service will elect a new port and assign the value to the property host.port which may then later be used in a property expression similar to <value>${host.port}</value> . This can be used to pin a port from the outside when doing some initial testing similar to mvn -Dhost.port=10080 docker:start

bindTo : host.port :80

Tuple consisting of two strings and a numeric value separated by a : . In this form, bindTo is an ip address on the host the container should bind to. As a convenience, a hostname pointing to the docker host may also be specified. The container will fail to start if the hostname can not be resolved.

+ host.ip : host.port :80

Tuple consisting of two strings and a numeric value separated by a : . In this form, the host ip of the container will be placed into a Maven property name host.ip . If docker reports that value to be 0.0.0.0 , the value of docker.host.address will be substituted instead. In the event you want to use this form and have the container bind to a specific hostname/ip address, you can declare a Maven property of the same name ( host.ip in this example) containing the value to use. host:port works in the same way as described above.

By default TCP is used as protocol but you can also use UDP by appending '/udp' to the port number.

The following are examples of valid configuration entries:

<properties>
  <bind.host.ip>1.2.3.4</bind.host.ip>
  <bind.host.name>some.host.pvt</bind.host.name>
</properties>
<ports>
  <port>18080:8080</port>
  <port>15060:5060/udp</port>
  <port>host.port:80</port>
  <port>127.0.0.1:80:80</port>
  <port>localhost:host.port:80</port>
  <port>+container.ip.property:host.port:5678</port>
  <port>+bind.host.ip:host.port:5678</port>
  <port>+bind.host.name:5678:5678</port>
</ports>

Another useful configuration option is portPropertyFile which can be used to write out the container’s host ip and any dynamic ports that have been resolved. The keys of this property file are the property names defined in the port mapping configuration and their values those of the corresponding docker attributes.

This property file might be useful with tests or with other maven plugins that will be unable to use the resolved properties because they can only be updated after the container has started and plugins resolve their properties in an earlier lifecycle phase.

If you don’t need to write out such a property file and thus don’t need to preserve the property names, you can use normal maven properties as well. E.g. ${host.var}:${port.var}:8080 instead of +host.var:port.var:8080 .

5.2.4. Links

The <links> configuration contains a list of containers that should be linked to this container according to Docker Links . Each link can have two parts where the optional right side is separated by a : and will be used as the name in the environment variables and the left side refers to the name of the container linking to. This is equivalent to the linking when using the Docker CLI --link option.

Example for linking to a container with name or alias postgres :

<links>
  <link>postgres:db</link>
</links>

This will create the following environment variables, given that the postgres image exposes TCP port 5432:

DB_NAME=/web2/db
DB_PORT=tcp://172.17.0.5:5432
DB_PORT_5432_TCP=tcp://172.17.0.5:5432
DB_PORT_5432_TCP_PROTO=tcp
DB_PORT_5432_TCP_PORT=5432
DB_PORT_5432_TCP_ADDR=172.17.0.5

Additionally, each <link> element can specify a comma separated set of links. Comma (and whitespace) can be used to separate links since valid docker link names/aliases contain only characters, digits, underscores, periods and dashes.

<links>
  <link>postgres:db, search, saml:identity</link>
</links>

If you wish to link to existing containers not managed by the plugin, you may do so by specifying the container name obtained via docker ps in the configuration.

Please note that the link behaviour also depends on the network mode selected. Links as described are referred to by Docker as legacy links and might vanish in the future. For custom networks no environments variables are set and links create merely network aliases for the linked container. To express start order dependencies using custom networks refer to the dependsOn configuration.

For a more detailed documentation for the new link handling please refer to the Docker network documentation

5.2.5. Network

The <network> element in the <run> configuration section can be used to configure the network mode of the container. This is now the preferred way for linking containers together. It knows the following sub elements:

container : Connect to the network of the specified container. The name of the container is taken from the <name> element.

custom : Use a custom network, which must be created before by using docker network create . Alternatively you can set the docker.autoCreateCustomNetworks global configuration parameter to true to automatically create custom networks. Custom networks are available for Docker 1.9 and newer. For more about the networking options please refer to the Docker documentation .

none : No network will be setup.

For mode container this is the container name, which is this image alias. For Mode custom this is the name of the custom network.

alias

One or more alias element can be provided which gives a way for a container to be discovered by alternate names by any other container within the scope of a particular network. This configuration only has effect for when the network mode is custom . More than one alias can be given by providing multiple entries.

If no mode is given but a name , then a custom network mode is assumed. For the simple modes which does not take an argument ( none , bridge or host ) a single <net> mode </net> can be used as alternative to using <network> with a <mode> subelement.

<network>
   <mode>custom</mode>
   <name>my-network</name>
   <alias>box1</alias>
   <alias>box2</alias>
</network>

or for a simple host network:

<net>host</net>

5.2.6. Depends-On

Custom networks do not provide a mechanism like <links> to express strong links between containers. They are normally not required because docker ensures that all containers within the same custom network can eventually resolve each other via DNS.

Your containers should preferably be able to deal with temporarily unresolvable dependencies but in some cases it is helpful to be able to rely the availability of other infrastructure containers.

The <dependsOn> configuration can be used to expresses custom network dependencies between your containers. docker:start will ensure that all dependencies a container depends on are completely started (fulfilling all <wait> conditions) before the depending container is started.

Additionally, each <container> element can specify a comma separated set of containers. Comma (and whitespace) can be used to separate containers since valid docker container names contain only characters, digits, underscores, periods and dashes.

<configuration>
  <!-- .... -->




    

    <dependsOn>
      <container>postgres</container>
      <container>logstash</container>
    </dependsOn>
</configuration>

5.2.7. Restart Policy

Specify the behavior to apply when the container exits. These values can be specified withing a <restartPolicy> section with the following sub-elements:

The behavior to apply when the container exits. The value is an object with a name property of either "always" to always restart or "on-failure" to restart only when the container exit code is non-zero. If on-failure is used, MaximumRetryCount controls the number of times to retry before giving up. The default is not to restart. (optional)

5.2.8. Volumes

A container can bind (or "mount") volumes from various source when starting up: Either from a directory of the host system or from another container which exports one or more directories. The mount configuration is specified within a <volumes> section of the run configuration. It can contain the following sub elements:

List of <image> elements which specify image names or aliases of containers whose volumes should be imported.

List of <volume> specifications (or host mounts ). Use /path to create and expose a new volume in the container, /host_path:/container_path to mount a host path into the container and /host_path:/container_path:ro to bind it read-only.

In this example the container creates a new volume named /logs on the container and mounts /opt/host_export from the host as /opt/container_import on the container. In addition all exported volumes from the container which has been created from the image jolokia/docker-demo are mounted directly into the container (with the same directory names under which the exporting container exposes these directories). This image must be also configured for this plugin. Instead of the full image name, an alias name can be used, too.

If a volume name instead of a path is referenced to in <bind> and a volume configuration exists with this name, then this this volume is created upfront with the provided options instead of using default options.

You can use Maven variables in the path specifications. This should even work for boot2docker and docker-machine:

<volumes>
    <volume>${project.build.directory}/${project.artifactId}-${project.version}:/usr/local/tomcat/webapps/${project.name}</volume>
    <volume>${project.basedir}/data:/data</volume>
  </bind>
</volumes>

You can also use relative paths. Relative paths are interpreted relative to the Maven project base directory. Paths that begin with ~ are interpreted relative to the JVM’s HOME or user.home directory.

<volumes>
    <volume>src/main/webapps/foo:/usr/local/tomcat/webapps/foo</volume>
    <volume>./target:/data</volume>
    <volume>~:/home/user</volume>
    <volume>~/.m2/repository:/home/user/.m2/repository</volume>
  </bind>
</volumes>

If you wish to mount volumes from an existing container not managed by the plugin, you may do by specifying the container name obtained via docker ps in the configuration.

5.2.9. Wait

While starting a container is it possible to block the execution until some condition is met. These conditions can be specified within a <wait> section which the following sub-elements:

status Status code which if returned is considered to be a successful ping. This code can be given either as a single number (200) or as a range (200..399). The default is 200..399

allowAllHosts If url is an HTTPS url and this option is set, then server certificates are not validated. By default they are checked for a proper CA signature.

Regular expression which is applied against the log output of an container and blocks until the pattern is matched. You can use (?s) in the pattern to switch on multi line matching.

Time in milliseconds to block.

Time in milliseconds between sending SIGTERM and SIGKILL when stopping a container. Since docker itself uses second granularity, you should use at least 1000 milliseconds.

shutdown

Time to wait in milliseconds between stopping a container and removing it. This might be helpful in situation where a Docker croaks with an error when trying to remove a container to fast after it has been stopped.

Commands to execute during specified lifecycle of the container. It knows the following sub-elements:

mode can be either mapped which uses the mapped ports or direct in which case the container ports are addressed directly. In the later case the host field should be left empty in order to select the container ip (which must be routed which is only the case when running on the Docker daemon’s host directly). Default is direct when host is localhost , mapped otherwise. The direct mode might help when a so called user-proxy is enabled on the Docker daemon which makes the mapped ports directly available even when the container is not ready yet.

host is the hostname or the IP address. It defaults to ${docker.host.address} for a mapped mode and the container ip address for the direct mode.

ports is a list of TCP ports to check. These are supposed to be the container internal ports.

healthy

Check that waits until the container health state becomes healthy . A container is considered healthy when its configured healtcheck succeeds.

This behaviour mimics the docker compose dependsOn condition: service_healthy .

Check that waits until a container finishes with the given exit code.

As soon as one condition is met the build continues. If you add a <time> constraint this works more or less as a timeout for other conditions. The build will abort if you wait on an url or log output and reach the timeout. If only a <time> is specified, the build will wait that amount of milliseconds and then continues.

This setup will wait for the given URL to be reachable but ten seconds at most. Additionally, it will wait for the TCP ports 3306 and 9999. Also, when stopping the container after integration tests, the build wait for 500 ms before it tries to remove the container (if not keepContainer or keepRunning is used). You can use maven properties in each condition, too. In the example, the ${host.port} property is probably set before within a port mapping section.

The property ${docker.host.address} is set implicitly to the address of the Docker host. This host will be taken from the docker.host configuration if HTTP or HTTPS is used. If a Unix socket is used for communication with the docker daemon, then localhost is assumed. You can override this property always by setting this Maven property explicitly.

5.2.10. Logging

When running containers the standard output and standard error of the container can be printed out. Several options are available for configuring the log output:

enabled

If set to false log output is disabled. This is useful if you want to disable log output by default but want to use the other configuration options when log output is switched on on the command line with -Ddocker.showLogs . Logging is enabled by default if a <log> section is given.

prefix

Prefix to use for the log output in order to identify the container. You can use placeholders in the prefix which are replaced on the fly:

NONE Switch off timestamp output. Useful on the command line ( -Ddocker.logDate=NONE ) for switching off otherwise enabled logging.

DEFAULT A default format in the form HH:mm:ss.SSS

MEDIUM java.time medium date time format

SHORT java.time short date time format

LONG java.time long date time format

ISO8601 Full ISO-8601 formatted date time with milliseconds

color

Color used for coloring the prefix when coloring is enabled (i.e. if running in a console and useColor is set). The available colors are YELLOW , CYAN , MAGENTA , GREEN , RED , BLUE . If coloring is enabled and now color is provided a color is picked for you.

Path to a file to which the log output is written. This file is overwritten for every run and colors are switched off.

driver

Section which can specify a dedicated log driver to use. A <name> tag within this section depicts the logging driver with the options specified in <opts> . See the example below for how to use this.

Specify isolation technology for container

The following configuration option under <run> session is equivalent of --isolation <value> when running a docker container

This option is useful in situations where you are running Docker containers on Windows. The --isolation <value> option sets a container’s isolation technology. On Linux, the only supported is the default option which uses Linux namespaces.

default

Use the value specified by the Docker daemon’s --exec-opt or system default (see below).

process

Shared-kernel namespace isolation (not supported on Windows client operating systems older than Windows 10 1809).

hyperv

Hyper-V hypervisor partition-based isolation.

The default isolation on Windows server operating systems is process. The default isolation on Windows client operating systems is hyperv. An attempt to start a container on a client operating system older than Windows 10 1809 with --isolation process will fail.

See isolation technology for container for a detailed description.

5.3. docker:stop

Stops and removes a docker container. This goal stops every container started with <docker:start> either during the same build (e.g. when bound to lifecycle phases when doing integration tests) or for containers created by a previous call to <docker:start>

If called within the same build run, only the containers that were explicitly started during the run will be stopped. Existing containers started using docker:start for the project will not be affected.

If called as a separate invocation, the plugin will stop and remove any container it finds whose image is defined in the project’s configuration. Any existing containers found running whose image name matches but were not started by the plugin will not be affected.

In case the naming strategy for an image is alias (i.e. the container name is set to the given alias), then only the container with this alias is stopped. Other containers originating from the same image are not touched.

It should be noted that any containers created prior to version 0.13.7 of the plugin may not be stopped correctly by the plugin because the label needed to tie the container to the project may not exist. Should this happen, you will need to use the Docker CLI to clean up the containers and/or use the docker.allContainers option listed below.

For tuning what should happen when stopping there are four global parameters which are typically used as system properties: allContainers , keepContainer , keepRunning and removeVolumes .

allContainers

Stops and removes any container that matches an image defined in the current project’s configuration. This was the default behavior of the plugin prior up to version 0.13.6

docker.allContainers

containerNamePattern

Default pattern that docker:start uses for naming containers when they are created. See Container Names for details. This should match the setting for docker:start goals if the goals are configured in separate executions.

docker.containerNamePattern

keepContainer

If set to true not destroy container after they have been stopped. Default is false.

docker.keepContainer

keepRunning

If set to true actually don’t stop the container. This apparently makes only sense when used on the command line when doing integration testing (i.e. calling docker:stop during a lifecycle binding) so that the container are still running after an integration test. This is useful for analysis of the containers (e.g. by entering it with docker exec ).

docker.keepRunning

removeVolumes

If set to true will remove any volumes associated to the container as well. This option will be ignored if either keepContainer or keepRunning are true.

docker.removeVolumes

stopNamePattern

If a list of name patterns is provided, any containers matching the patterns will be stopped and removed (depending on the values of keepContainer and keepRunning ), independently of whether there is an image configuration .

docker.stopNamePattern

executeStopOnVMShutdown

If true , the containers are not stopped right away, but when the build is finished (success or failed).

Defaults to false .

docker.executeStopOnVMShutdown

5.4. docker:push

This goal uploads images to the registry which have a <build> configuration section. The images to push can be restricted with the global option filter (see Global Configuration for details). The registry to push is by default docker.io but can be specified as part of the images’s name name the Docker way. E.g. docker.test.org:5000/data:1.5 will push the image data with tag 1.5 to the registry docker.test.org at port 5000 . Security information (i.e. user and password) can be specified in multiple ways as described in section Authentication .

By default a progress meter is printed out on the console, which is omitted when using Maven in batch mode (option -B ). A very simplified progress meter is provided when using no color output (i.e. with -Ddocker.useColor=false ).

skipPush

If set to true the plugin won’t push any images that have been built.

docker.skip.push

skipTag

If set to true this plugin won’t push any tags

docker.skip.tag

pushRegistry

The registry to use when pushing the image. See Registry Handling for more details.

docker.push.registry

retries

How often should a push be retried before giving up. This useful for flaky registries which tend to return 500 error codes from time to time. The default is 0 which means no retry at all.

docker.push.retries

5.5. docker:watch

When developing and testing applications you will often have to rebuild Docker images and restart containers. Typing docker:build and docker:start all the time is cumbersome. With docker:watch you can enable automatic rebuilding of images and restarting of containers in case of updates.

docker:watch is the top-level goal which performs these tasks. There are two watch modes, which can be specified in multiple ways:

This mode works only when there is a <build> section in an image configuration. Otherwise no automatically build will be triggered for an image with only a <run> section. Note that you need the package phase to be executed before otherwise any artifact created by this build can not be included into the assembly. As described in the section about docker:start this is a Maven limitation. * run : Automatically restart container when their associated images changes. This is useful if you pull a new version of an image externally or especially in combination with the build mode to restart containers when their image has been automatically rebuilt. This mode works reliably only when used together with docker:start .

$ mvn docker:start docker:watch -Ddocker.watchMode=run

The mode can also be both or none to select both or none of these variants, respectively. The default is both .

docker:watch will run forever until it is interrupted with CTRL-C after which it will stop all containers. Depending on the configuration parameters keepContainer and removeVolumes the stopped containers with their volumes will be removed, too.

When an image is removed while watching it, error messages will be printed out periodically. So don’t do that ;-)

Dynamically assigned ports stay stable in that they won’t change after a container has been stopped and a new container is created and started. The new container will try to allocate the same ports as the previous container.

If containers are linked together network or volume wise, and you update a container which other containers dependent on, the dependant containers are not restarted for now. E.g. when you have a "service" container accessing a "db" container and the "db" container is updated, then you "service" container will fail until it is restarted, too.

A future version of this plugin will take care of restarting these containers, too (in the right order), but for now you would have to do this manually.

containerNamePattern

Default pattern for naming all containers when they are created. See Container Names for details.

docker.containerNamePattern

keepContainer

As for docker:stop , if this is set to true (and keepRunning is disabled) then all container will be removed after they have been stopped. The default is true .

docker.keepContainer

keepRunning

If set to true all container will be kept running after docker:watch has been stopped. By default this is set to false .

docker.keepRunning

removeVolumes

if set to true will remove any volumes associated to the container as well. This option will be ignored if either keepContainer or keepRunning are true .

docker.removeVolumes

watchInterval

Interval in milliseconds how often to check for changes, which must be larger than 100ms. The default is 5 seconds.

docker.watchInterval

watchMode

Watch mode specifies what should be watched

copy : Changed files are copied into the container. The container can be either running or might be already exited (when used as a data container linked into a platform container ). Requires Docker >= 1.8.

both : build and run combined

none : Neither watching for builds nor images. This is useful if you use prefactored images which won’t be changed and hence don’t need any watching. none is best used on an per image level, see below how this can be specified.

docker.watchMode

watchPostExec

A command which is executed within the container after files are copied into this container when watchMode is copy . Note that this container must be running.

watchPostGoal

A maven goal which should be called if a rebuild or a restart has been performed. This goal must have the format <pluginGroupId>:<pluginArtifactId>:<goal> and the plugin must be configured in the pom.xml . For example a post-goal io.fabric8:fabric8:delete-pods will trigger the deletion of PODs in Kubernetes which in turn triggers are new start of a POD within the Kubernetes cluster. The value specified here is the the default post goal which can be overridden by <postGoal> in a <watch> configuration.

Image specific watch configuration goes into an extra image-level <watch> section (i.e. <image><watch>...</watch></image> ). The following parameters are recognized:

Each image can be configured for having individual watch mode. These take precedence of the global watch mode. The mode specified in this configuration takes precedence over the globally specified mode.

interval

Watch interval can be specified in milliseconds on image level. If given this will override the global watch interval.

postGoal

Post Maven plugin goal after a rebuild or restart. The value here must have the format <pluginGroupId>:<pluginArtifactId>:<goal> (e.g. io.fabric8:fabric8:delete-pods )

postExec

Command to execute after files are copied into a running container when mode is copy .

Given this configuration

mvn package docker:build docker:start docker:watch

You can build the service image, start up all containers and go into a watch loop. Again, you need the package phase in order that the assembly can find the artifact build by this project. This is a Maven limitation. The db image will never be watch since it assumed to not change while watching.

5.6. docker:remove

This goal can be used to clean up images. By default all images with a build configuration are removed. You can tune this by setting the property removeMode (property: docker.removeMode ) to one of the following values:

Previously, this could be tuned also by providing the property removeAll which indicates to remove all images managed by this build. Otherwise only data images were delete before 0.24.0. removeAll is deprecated and will be removed soone. Please use removeMode instead.

As with the other goals, the configuration image can be used to tune the images to remove. All containers belonging to the images are removed as well as the all tags assigned to this image

Considering three images 'db','tomcat' and 'data' where 'data' is the only image with a build configuration:

removeNamePattern

If a list of name patterns is provided, any images matching the patterns will be removed, independently of whether there is an image configuration marked for removal.

docker.removeNamePattern

With this goal it is possible to print out the logs of containers started from images configured in this plugin. By default only the latest container started is printed, but this can be changed with a property. The format of the log output is influenced by run configuration of the configured images. The following system properties can the behaviour of this goal:

docker.logAll

If set to true the logs of all containers created from images configured for this plugin are printed. The container id is then prefixed before every log line. These images can contain many containers which are already stopped. It is probably a better idea to use docker logs diretly from the command line.

docker.follow

If given will wait for subsequent log output until CRTL-C is pressed. This is similar to the behaviour of docker logs -f (or tail -f ).

docker.filter

Filter to restrict the set of images for which log should be fetched. This can be a comma separated list of image or alias names.

docker.logDate

Date format to use. See " Logging " for available formats.

This goal copies files and directories from a container. When called, then all images which are configured in the project and having copy element in the image configuration are iterated.

In addition to the Global configuration , this goal supports the following configuration options:

createContainers

Whether to create temporary containers or to copy from existing containers.

If true then a temporary container is created (but not started) before the copying and is removed after completion of the copying, even if the copying failed. Container image is pulled from registry following imagePullPolicy .

If false then copying from existing containers:

If the goal is called together with docker:start goal, then the copying is performed only from containers started by that goal.

Otherwise, the copying is performed from containers matching configured image and copyNamePattern property of image configuration is examined:

If copyNamePattern pattern is defined, then it is used to match containers.

Otherwise, image name is used to match containers, i.e. containers created from the image with the same name are examined.

Temporary containers are created and removed or existing containers are examined in the order of image configurations.

Defaults to false .

docker.createContainers

pullRegistry

The registry used for pulling image when creating temporary container and imagePullPolicy allows or requires pulling respective image. Ignored if createContainers is false .

docker.pull.registry

containerNamePattern

Naming pattern for how to name containers when created.

Ignored if createContainers is false .

Defaults to default container naming pattern ( %n-%i ).

docker.containerNamePattern

copyAll

Whether to copy from all matching containers or only from the newest ones.

Ignored if createContainers is true .

Defaults to false .

docker.copyAll

The copy image configuration element is honored by the goal and has the following sub elements:

entries

List of items to copy from a container. Each item is wrapped with <entry> and </entry> tags. Refer to Copy entry format for the format of a single list item. Copying is performed in the order of list items.

Optional, i.e. can be omitted or can have an empty list of items.

containerPath

Path to a container file or a container directory, which needs to be copied. If the path is not absolute, then it is considered relative to the container working directory.

hostDirectory

Path to a host directory where a copied file or a copied directory needs to be placed. "host" means the machine where the copy goal is executed, i.e. where respective maven project is built.

If the path is not absolute, then it is considered relative to the maven project base directory. If a container directory is copied, then a directory with the same name is created under the path defined by hostDirectory , i.e. a whole container directory is copied but not just its content.

Optional. If omitted then project base directory is used.

5.9. docker:source

The docker:source target can be used to attach a docker build archive containing the Dockerfile and all added files to the Maven project with a certain classifier. It reuses the configuration from docker:build .

By default, only the first image configuration is used for creating the source archive. You can export all image configurations by setting the sourceMode configuration to all :

<plugin>
  <artifactId>docker-maven-plugin</artifactId>
  <configuration>
    <!-- source mode can be "first" or "all" -->
    <sourceMode>




    
all</sourceMode>
    <!-- .... -->
  </configuration>
</plugin>

For exporting all image configurations, docker:source uses the image’s alias as part of the classifier, so it is mandatory that the alias is set for this goal to work when all images should be exported this way. The classifier is calculated as docker-<alias> so when the alias is set to service , then the classifier is docker-service .

If you only export the first image configuration (which is the default), then the classifier is just docker (without alias).

docker:source can be attached to a Maven execution phase, which is generate-sources by default.

For example, this configuration will attach the docker build archive to the artifacts to store in the repository:

<plugin>
  <artifactId>docker-maven-plugin</artifactId>
  <!-- ..... -->
  <executions>
     <execution>
       <id>sources</id>
       <goals>
         <goal>source</goal>
       </goals>
     </execution>
  </executions>
</plugin>

If not bound to an execution phase, docker:source requires that the artifact has been created so you call it best together with package

5.10. docker:save

The docker:save target saves an image defined in the build configuration to a local file, analogous to docker save . If the option saveFile is not set, the file name is calculated automatically:

Please note that the exported image contains all image layers and can be quite large (also, it takes a bit to export the image).

The file name extension is used to select a compression method for the output.

If saveClassifier is set, the saved archive will be attached to the project using the provided classifier and the type determined from the file name. The placeholder %a will be replaced with the image alias.

Note that using overriding the default to use docker or docker-%a may lead to a conflict if a source archive is also attached with docker:source .

saveName

The name of the image configuration to save. Must not be used together with alias .

docker.save.name

saveAlias

The alias of the image configuration to save. Must not be used together with name .

docker.save.alias

saveFile

The filename to save.

docker.save.file or docker.file or file

saveClassifier

If set, attach the the saved archive to the project with the provided classifier. A placeholder of %a will be replaced with the image alias.

docker.save.classifier

skipSave

A boolean flag whether to skip execution of the goal.

docker.skip.save

~/work/repos/docker-maven-plugin/samples/zero-config : $ mvn docker:tag -Ddocker.image.tag=0.9.0
[INFO] Scanning for projects...
[INFO]
[INFO] -----------< io.fabric8.dmp.samples:demp-sample-zero-config >-----------
[INFO] Building demp-sample-zero-config
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- docker-maven-plugin:dmpversion:tag (default-cli) @ demp-sample-zero-config ---
[INFO] DOCKER> Tagging image samples/demp-sample-zero-config:0.9.0 successful!
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.155 s
[INFO] Finished at: 2020-06-27T14:05:33+05:30
[INFO] ------------------------------------------------------------------------
~/work/repos/docker-maven-plugin/samples/zero-config : $ docker images | grep 0.9.0
samples/demp-sample-zero-config                        0.9.0                       ac5c5991505d        About an hour ago   479MB

5.12. docker:volume-create

This goals creates one or more standalone Docker volume , which can be referenced in a docker:start configuration for linking to a volume during runtime. Each volume has therefore a unique and referenceable name. Beside the volume driver and driver options can be specified.

<plugin>
  <configuration>
    <volumes>
       <volume>
         <name>temp-volume</name>
         <driver>local</driver>
           <type>tmpfs</type>
           <device>tmpfs</device>
           <o>size=100m,uid=1000</o>
         </opts>
         <labels>
           <volatileData>true</volatileData>
         </labels>
       </volume>
    </volumes>
  </configuration>
</plugin>

The following options are available when creating volumes:

driver

Volume driver to use. By default the driver local is used which is created on the local file system. Please refer to your Docker installation which additional drivers are available.

Driver specific options passed in as custom <key>value</key> where its maps to key=value pairs for driver options as they can be provided from the Docker CLI, too. Each volume driver supports different options. The options supported by the local driver are the well known Linux mount options .

labels

Labels given as <key>value</key> similar to image labels described in Environment and Labels . These labels are used to tag the volumes themselves.

5.13. docker:volume-remove

This goals is the counterpart to docker:volume-create and removes a volume. Docker volumes are configured outside of Docker images, but can be referenced by them. The configuration is the same as for docker:volume-create

Example:

<plugin>
  <configuration>
    <volumes>
       <volume>
         <name>temp-volume</name>
       </volume>
    </volumes>
  </configuration>
</plugin>

The configuration is quite simple. Only the name of the volume to delete is required.

For special configuration needs, there is the possibility to get the runtime and build configuration from places outside the plugin’s configuration. This is done with the help of <external> configuration sections which at least has a <type> subelement. This <type> element selects a specific so called "handler" which is responsible for creating the full image configuration. A handler can decide to use the <run> and <build> configuration which could be provided in addition to this <external> section or it can decide to completely ignore any extra configuration option.

A handler can also decide to expand this single image configuration to a list of image configurations. The image configurations resulting from such a external configuration are added to the regular <image> configurations without an <external> section.

The available handlers are described in the following.

6.1. Properties

For simple needs the image configuration can be completely defined via Maven properties which are defined outside of this plugin’s configuration. Such a property based configuration can be selected with an <type> of properties . As extra configuration a prefix for the properties can be defined which by default is docker .

For single-image configurations it is also possible to active property based configuration via an externally set property.

By default, property based configuration uses only properties, ignoring any <build> and <run> sections. To combine values from both sources, use the property mode configuration .

Properties are read from the Maven project (defined in <properties> or global Maven configuration from settings.xml ) and, since 0.25.0, from any -D flags given to Maven (takes priority over project properties).

<image>
  <external>
     <type>properties</type>
     <prefix>docker</prefix> <!-- this is the default -->
     <mode>only</mode> <!-- this is the default -->
  </external>
</image>

Given this example configuration a single image configuration is built up from the following properties, which correspond to the corresponding values in the <build> and <run> sections. A build configuration is only created when a docker.from or a docker.fromExt is set.

docker.args.BUILDVAR

Set the value of a build variable. The syntax is the same as for specifying environment variables (see below).

docker.assembly.baseDir

Directory name for the exported artifacts as described in an assembly (which is /maven by default).

docker.assembly.descriptor

Path to the assembly descriptor when building an image

docker.assembly.descriptorRef

Name of a predefined assembly to use.

docker.assembly.exportBaseDir

If true export base directory

docker.assembly.ignorePermissions

If set to true existing file permissions are ignored when creating the assembly archive. Deprecated, use a permission mode of ignore instead.

docker.assembly.permissions

can be ignore to use the permission as found on files regardless on any assembly configuration, keep to respect the assembly provided permissions, exec for setting the executable bit on all files (required for Windows when using an assembly mode dir ) or auto to let the plugin select exec on Windows and keep on others. keep is the default value.

docker.assembly.dockerFileDir

specifies a directory containing an external Dockerfile that will be used to create the image. This is deprecated please use docker.dockerFileDir or docker.dockerFile instead.

docker.noCache

Don’t use Docker’s build cache. This can be overwritten by setting a system property docker.noCache when running Maven.

docker.bind.idx

Sets a list of paths to bind/expose in the container. See List Properties .

docker.build.network

Set the networking mode for the RUN instructions during build

docker.buildArg.VARIABLE

Set a ARG to be available during build of image. Note : this is handled separately from external configuration, and is always available. See Build Args for more details.

docker.buildx.builderName

Name of buildx builder

docker.buildx.cache

Location of image cache

docker.buildx.configFile

Configuration file for buildx builder

docker.buildx.platform

Platform for multi-architecture image

docker.buildx.cacheFrom

Cache source for buildx builder

docker.buildx.cacheTo

Cache destination for buildx builder

docker.capAdd.idx

List of kernel capabilities to add to the container. See List Properties .

docker.capDrop.idx

List of kernel capabilities to remove from the container. See List Properties .

docker.sysctls.KEY

Sets a namespaced kernel parameter ( sysctl ) in the container.

docker.cleanup

Cleanup dangling (untagged) images after each build, including any stopped containers created from them. Also cleanup dangling images as a result of image tagging, auto-pulling a base image, or auto-pulling a cacheFrom image. Default is try , which tries to remove the old image, but doesn’t fail the build if this is not possible (e.g. because the image is still used by a running container). Other possible values are remove , if you want to fail the build, or none , to skip cleanup altogether.

docker.cmd

Command to execute. This is used both when running a container and as default command when creating an image.

docker.copy.entries.idx.containerPath

containerPath sub element of copy configuration entry . idx can be an integer number, or a string. Empty string is allowed.

idx defines order of copying. Entries which idx is an integer number are copied first in ascending order by the parsed value of idx . Entries which idx is not an integer number are copied second in ascending alphabetical order by idx .

docker.copy.entries.idx.hostDirectory

hostDirectory sub element of copy configuration entry . idx should match the one from docker.copy.entries.idx.containerPath external property.

docker.copyNamePattern

Set copyNamePattern of image configuration.

docker.cpus

Specify how much of the available CPU resources a container can use

docker.cpuset

Limit the container to specific CPUs or cores. This can be provided either as a comma-separated list or a hyphen-separated range.

docker.cpushares

Set the proportion of the host machine’s cpu cycles available to the container

docker.cacheFrom.idx

Defines a list of image names to use as cache sources. See List Properties .

docker.domainname

Container domain name

docker.dns.idx

List of dns servers to use. See List Properties .

docker.dnsSearch.idx

List of dns search domains. See List Properties .

docker.dockerArchive

specify an archive which can be loaded with docker load . Use this as an alternative to docker.dockerFile or docker.dockerFileDir

docker.dockerFile

specifies a Dockerfile to use. This property must point to the Dockerfile itself.

docker.dockerFileDir

specifies a directory containing an external dockerfile that will be used to create the image. The dockerfile must be name Dockerfile

docker.entrypoint

Container entry point

docker.exposedPropertyKey

Property part for the exposed container properties like internal IP addresses as described in docker:start .

docker.env.VARIABLE

Sets an environment variable used in build and run. E.g. <docker.env.JAVA_OPTS>-Xmx512m</docker.env.JAVA_OPTS> sets the environment variable JAVA_OPTS . Multiple such entries can be provided. This environment is used both for building images and running containers. The value cannot be empty but can contain Maven property names which are resolved before the Dockerfile is created.

docker.envBuild.VARIABLE

Sets an environment variable used in build only. E.g. <docker.envBuild.JAVA_OPTS>-Xmx512m</docker.envBuild.JAVA_OPTS> sets the environment variable JAVA_OPTS . Multiple such entries can be provided. This environment is building images only. The value cannot be empty but can contain Maven property names which are resolved before the Dockerfile is created.

docker.envRun.VARIABLE

Sets an environment variable used in run only. E.g. <docker.envRun.JAVA_OPTS>-Xmx512m</docker.envRun.JAVA_OPTS> sets the environment variable JAVA_OPTS . Multiple such entries can be provided. This environment is used both for running containers only. The value cannot be empty but can contain Maven property names which are resolved before the Dockerfile is created.

docker.envPropertyFile

specifies the path to a property file whose properties are used as environment variables in run. The environment variables takes precedence over any other environment variables specified.

docker.extraHosts.idx

List of host:ip to add to /etc/hosts . See List Properties .

docker.filter

Enable and set the delimiters for property replacements. By default properties in the format ${..} are replaced with Maven properties. You can switch off property replacement by setting this property to false . When using a single char like @ then this is used as a delimiter (e.g @…​@ ). See Filtering for more details.

docker.from

Base image for building an image. Must be set when an image is created (or fromExt )

docker.fromExt.VARIABLE

Base image for building an image (extended format), which also triggers a build of an image.

docker.healthcheck.cmd

Command to use for a healthcheck

docker.healthcheck.interval

Interval for how often to run a healthcheck (in seconds or with a given time unit)

docker.healthcheck.mode

If se to none disable a healthcheck from a base image

docker.healthcheck.retries

Number of retries for how often to retry a healthcheck until it is considered to have failed

docker.healthcheck.startPeriod

Initialization time for containers that need time to bootstrap. Probe failure during that period will not be counted towards the maximum number of retries. However, if a health check succeeds during the start period, the container is considered started and all consecutive failures will be counted towards the maximum number of retries. (in seconds or with a given time unit)

docker.healthcheck.timeout

Timeout after which a healthcheck command is considered to be failed (in seconds or with a given time unit)

docker.hostname

Container hostname

docker.imagePropertyConfiguration

Special property to activate property configuration without altering XML file (see Activating property configuration externally ).

docker.imagePullPolicy.build

Specific pull policy used when building images. See imagePullPolicy for the possible values.

docker.imagePullPolicy.run

Specific pull policy used for downloading images to run. See imagePullPolicy for the possible values.

docker.labels.LABEL

Sets a label which works similarly like setting environment variables.

docker.loadNamePattern

Search the archive specified in docker.dockerArchive for the specified image name and creates a tag from the matched name to the build image name specified in docker.name .

docker.log.enabled

Use logging (default: true )

docker.log.prefix

Output prefix

docker.log.color

ANSI color to use for the prefix

docker.log.date

Date format for printing the timestamp

docker.log.driver.name

Name of an alternative log driver

docker.log.driver.opts.VARIABLE

Logging driver options (specified similarly as in docker.env.VARIABLE )

docker.links.idx

defines a list of links to other containers when starting a container. For example <docker.links.1>db</docker.links.1> specifies a link to the image with alias 'db'. See List Properties .

docker.maintainer

defines the maintainer’s email as used when building an image

docker.memory

Memory limit in bytes.

docker.memorySwap

Total memory limit (memory + swap) in bytes. Set docker.memorySwap equal to docker.memory to disable swap. Set to -1 to allow unlimited swap.

docker.name

Image name

docker.namingStrategy

Container naming (either none or alias )

docker.network.mode

Network mode to use which can be none , host , bridged , container or custom

docker.network.name

Name of the custom network when mode is custom , or for mode container the image alias name used to create the container.

docker.network.alias.idx

One or more aliase for a custom network. Only used when the network mode is custom . See List Properties .

docker.noCache

Don’t use a cache when building the image

docker.squash

Squash newly built layers into a single layer (API 1.25+, need to be enabled in the Docker daemon configuration)

docker.optimise

if set to true then it will compress all the runCmds into a single RUN directive so that only one image layer is created.

docker.portPropertyFile

specifies a path to a port mapping used when starting a container.

docker.ports.idx

Sets a port mapping. For example <docker.ports.1>jolokia.ports:8080<docker.ports.1> maps the container port 8080 dynamically to a host port and assigns this host port to the Maven property ${jolokia.port} . See Port mapping for possible mapping options. When creating images images only the right most port is used for exposing the port. For providing multiple port mappings, the index should be count up. See List Properties for more information about list properties.

docker.registry

Registry to use for pushing images.

docker.restartPolicy.name

Container restart policy

docker.restartPolicy.retry

Max restart retries if on-failure used

docker.run.idx

List of commands to RUN when creating the image. See List Properties .

docker.securityOpts.idx

List of opt elements to specify kernel security options to add to the container. For example docker.securityOpt.1=seccomp=unconfined . See List Properties .

docker.shmsize

Size of /dev/shm in bytes.

docker.tags.idx

List of tags to apply to a built image. See List Properties .

docker.tmpfs.idx

One or more mount points for a tmpfs . Add mount options after a : . See List Properties .

docker.ulimits.idx

Ulimits for the container. Ulimit is specified with a soft and hard limit <type>=<soft limit>[:<hard limit>] . For example docker.ulimits.1=memlock=-1:-1 . See List Properties .

docker.user

User to switch to at the end of a Dockerfile. Not to confuse with docker.username which is used for authentication when interacting with a Docker registry.

docker.volumes.idx

defines a list of volumes to expose when building an image. See List Properties .

docker.volumesFrom.idx

defines a list of image aliases from which the volumes should be mounted of the container. For examples <docker.volumesFrom.1>data</docker.volumesFrom.1> will mount all volumes exported by the data image. See List Properties .

docker.wait.http.url

URL to wait for during startup of a container

docker.wait.http.method

HTTP method to use for ping check

docker.wait.http.status

Status code to wait for when doing HTTP ping check

docker.wait.time

Amount of time to wait during startup of a container (in ms)

docker.wait.log

Wait for a log output to appear.

docker.wait.exec.postStart

Command to execute after the container has start up.

docker.wait.exec.preStop

Command to execute before command stops.

docker.wait.exec.breakOnError

If set to "true" then stop the build if the a postStart or preStop command failed

docker.wait.shutdown

Time in milliseconds to wait between stopping a container and removing it.

docker.wait.tcp.mode

Either mapped or direct when waiting on TCP connections

docker.wait.tcp.host

Hostname to use for a TCP wait checks

docker.wait.tcp.port.idx

List of ports to use for a TCP check. See List Properties .

docker.wait.kill

Time in milliseconds to wait between sending SIGTERM and SIGKILL to a container when stopping it.

docker.workdir

Container working directory where the image is build in

docker.workingDir

Current Working dir for commands to run in when running containers

Multiple property configuration handlers can be used if they use different prefixes. As stated above the environment and ports configuration are both used for running container and building images. If you need a separate configuration you should use explicit run and build configuration sections.

List properties refer to XML configurations items that accept a list of values, like <build><tag> or <run><ports> . To specify values using properties, you must declare a property for each value you want to add to the list, and add a idx suffix to the property name to determine its position in the resulting list. For example:

<docker.ports.1>80<docker.ports.1>
<docker.ports.2>8080<docker.ports.2>
<docker.tags.jenkins>${BUILD_TIMESTAMP}</docker.tags.jenkins>
<docker.tags.current>latest</docker.tags.current>

The idx suffix defines the order of copying. Entries which idx is an integer number are copied first in ascending order by the parsed value of idx . Entries which idx is not an integer number are copied second in ascending alphabetical order by idx .

By default the property handler will only consider properties and ignore any other image configuration in the XML/POM file. This can be changed by adding the <mode> configuration (since version 0.25.0), which can have one of the following values:

Only look at properties, ignore any <run> or <build> sections for this image. This is the default, and also the behavior in versions before 0.25.0.

override

Use property if set, else fall back to value found in <run> or <build> sections for this image.

fallback

Use value found in <run> or <build> sections for this image, else fall back to to property value.

Effectively disable properties, same as not specifying the <external> section at all.

It also possible to activate property configuration by setting the property docker.imagePropertyConfiguration to a valid property mode , without adding an <external> section. The plugin will then use any properties with default docker. prefix. This can be useful if most of the configuration is specified in XML/POM file, but there is need to override certain configuration values without altering the POM file (instead add this to a parent POM or global settings.xml).

If set in parent POM, but not wanted in specific project, the property could be overriden locally with the value skip to disabled property configuration for that particular project. If set in settings.xml however, by Maven design, that value will always take precedence over any properties defined in pom.xml.

For configurations with multiple images, using this property will by default produce an error. All images would then use the same docker property prefix, resulting in multiple identical configurations. This can be overruled by adding an explicit <external> configuration element with an explicit <prefix> to all images (or at least all but one). Normally you’d want to use different prefix for each image, but if explicitly set it does allow you to use the same prefix (even docker ) on all images. This is useful in case you just want to share a few properties. This only makes sense when property mode is override or fallback and image-specific configuration are defined in the POM configuration.

For examples, see here

For some fields it may be desired to merge values from both POM and properties. For example, in a certain run environment we might want to inject a http_proxy environment variable, but we do not want to add this to the POM file.

This is solved using a Combine policy which can be either replace or merge . Merge is only available for configuration of Map or List type. For scalar values such as strings and integers, it is not supported. For Maps, both sources are merged, with the priority source taking precedence. For Lists, they are concatenated, with values from the priority source being added first.

Combine policy is specified per configuration key/property, and the default in most cases is currently replace . The following keys have merge as default policy:

This can be overridden individually for all configuration keys (of map/list type) by setting an additional property suffixed ._combine . For example, to not merge ports, set docker.ports._combine=replace , and to enable merging of dns, set docker.dns._combine=merge .

<properties>
  <docker.name>jolokia/demo</docker.name>
  <docker.alias>service</docker.alias>
  <docker.from>consol/tomcat:7.0</docker.from>
  <docker.assembly.descriptor>src/main/docker-assembly.xml</docker.assembly.descriptor>
  <docker.env.CATALINA_OPTS>-Xmx32m</docker.env.CATALINA_OPTS>
  <docker.label.version>${project.version}</docker.label.version>
  <docker.ports.jolokia.port>8080</docker.ports.jolokia.port>
  <docker.wait.url>http://localhost:${jolokia.port}/jolokia</docker.wait.url>
</properties>
<build>
  <plugins>
    <plugin>
      <groupId>io.fabric8</groupId>
      <artifactId>docker-maven-plugin</artifactId>
      <configuration>
        <images>
          <image>
            <external>
              <type>properties</type>
              <prefix>docker</prefix>
            </external>
          </image>
        </images>
      </configuration>
    </plugin>
  </plugins>
</build>

<properties>
  <docker.assembly.descriptor>src/main/docker-assembly.xml</docker.assembly.descriptor>
  <docker.env.CATALINA_OPTS>-Xmx32m</docker.env.CATALINA_OPTS>
  <docker.label.version>${project.version}</docker.label.version>
  <docker.ports.jolokia.port>8080</docker.ports.jolokia.port>
  <docker.wait.url>http://localhost:${jolokia.port}/jolokia</docker.wait.url>
</properties>
<build>
  <plugins>
    <plugin>
      <groupId>io.fabric8</groupId>
      <artifactId>docker-maven-plugin</artifactId>
      <configuration>
        <images>
          <image>
            <external>
              <type>properties</type>
              <prefix>docker</prefix>
              <mode>override</mode>
            </external>
            <name>jolokia/demo</name>
            <alias>service</alias>
            <build>
              <from>consol/tomcat:7.0</from>
              <labels>
                <software>tomcat</software>
              </labels>
            </build>
          </image>
        </images>
      </configuration>
    </plugin>
  </plugins>
</build>

This would build the same image as the previous example. If instead built with mvn docker:build -Pdocker.from=console/tomcat:8.0 -Ddocker.tags.0=tc8-test it would build from that image instead, and also add that tag to the image.

If -Ddocker.labels.status=beta is added, the image would be given two labels: status=beta and software=tomcat . If -Ddocker.labels._combine=replace is added, the image would be given one label only: status=beta .

Global ~/.m2/settings.xml file:

<profiles>
  <profile>
    <id>http-proxy</id>
    <properties>
      <docker.buildArg.http_proxy>http://proxy.example.com:8080</docker.buildArg.http_proxy>
      <docker.runArg.http_proxy>http://proxy.example.com:8080</docker.runArg.http_proxy>
      <docker.imagePropertyConfiguration>override</docker.imagePropertyConfiguration>
    </properties>
  </profile>
</profiles>

When the plugin is executed, on a machine with the given settings.xml, the plugin will see the docker.imagePropertyConfiguration configuration and enable the property merging feature. When building, it will inject the http_proxy build ARG, and when running, it will inject the http_proxy ENV variable. The rest of the configuration will be sourced from the XML, unless the Maven project has any other docker.* properties defined.

Using the same global ~/.m2/settings.xml file as in previous example, but with two image definitions and no extra configuration will cause an error, saying that you cannot use property docker.imagePropertyConfiguration on projects with multiple images.

By adding an explicit external configuration directive with the same prefix in both images, this error is disabled.

<build>
  <plugins>
    <plugin>
      <groupId>io.fabric8</groupId>
      <artifactId>docker-maven-plugin</artifactId>
      <configuration>
        <images>
          <image>
            <external>
              <type>properties</type>
              <prefix>docker</prefix>
              <mode>override</mode>
            </external>
            <name>jolokia/demo</name>
            <alias>service</alias>
            <build>
              <from>consol/tomcat:7.0</from>
            </build>
          </image>
          <image>
            <external>
              <type>properties</type>
              <prefix>docker</prefix>
              <mode>override</mode>
            </external>
            <name>jolokia/demo2</name>
            <alias>service2</alias>
            <build>
              <from>consol/tomcat:7.0</from>
            </build>
          </image>
        </images>
      </configuration>
    </plugin>
  </plugins>
</build>

The behaviour will now be same as previous example. Note that you must explicitly state <mode>override</mode> , otherwise it will use the default only .

6.2. Docker Compose

This plugin supports also configuration via a docker-compose file, especially for running containers specified in docker-compose.yml . Docker Compose handling is available also as an external configuration provider.

<image>
  <alias>webapp</alias> (1)
  <name>fabric8/compose-demo:latest</name>
  <external> (2)
     <type>compose</type> (3)
     <basedir>src/main/docker</basedir> (4)
     <composeFile>docker-compose.yml</composeFile>
  </external>
  <build> (5)
    <assembly>....</assembly>
  </build>
  <run>...</run>
  <watch>...</watch>
</image>

<plugin>
  <configuration>
    <image>consol/tomcat-7.0</image>
    <authConfig>
      <username>jolokia</username>
      <password>s!cr!t</password>
    </authConfig>
  </configuration>
</plugin>

mvn -Ddocker.username=jolokia -Ddocker.password=s!cr!t docker:push

<servers>
  <server>
    <id>docker.io</id>
    <username>jolokia</username>
    <password>s!cr!t</password>
  </server>
</servers>

<plugin>
  <configuration>
    <image>consol/tomcat-7.0</image>
    <authConfig>
         <username>jolokia</username>
         <password>s!cr!t</password>
      </push>
    </authConfig>
  </configuration>
</plugin>

oc login
mvn -Ddocker.registry=docker-registry.domain.com:80/default/myimage \
    -Ddocker.username=$(oc whoami) \
    -Ddocker.password=$(oc whoami -t)

oc login
mvn -Ddocker.registry=docker-registry.domain.com:80/default/myimage \
    -Ddocker.useOpenShiftAuth

$ mvn --encrypt-password
Password:
{QJ6wvuEfacMHklqsmrtrn1/ClOLqLm8hB7yUL23KOKo=}