Comments (9)
ah - this might not be possible with the nested DTOs used to configure images/builds. e.g. I tried adding...
public class ImageConfiguration implements StartOrderResolver.Resolvable {
@Parameter(required = true, property = "docker.image")
private String name;
and it seems to be ignored ;)
from docker-maven-plugin.
at least the XML in user projects could use ${docker.image}, ${docker.from}, ${docker.registry} I guess; we could still do the env var / ports stuff though? Then the maven plugin can be defined once in a base project and then configured using maven properties in child projects
from docker-maven-plugin.
Good points, James. Currently I'm at Devoxx, hopefully have some time this evening and maybe come up with a good solution for your use case. Have still to read through your comments completely first, though ;-)
from docker-maven-plugin.
BTW I went with just lots of copy/pasting for now adding in lots of ${docker.foo} variables everywhere
https://github.com/fabric8io/quickstarts/blob/master/quickstarts/java/camel-spring/pom.xml#L153
its only for env and ports couldn't copy/paste the same blob of XML into all projects. It'd be really nice for this to be the default though, so there's less to type/maintain
from docker-maven-plugin.
Just thought a bit about your suggestion I think it would be indeed awesome to have some easy way to share configuration properties among the various plugins.
However I doubt a bit that the properties-road is the way to go, because:
- Sharing properties subtly tie the plugins together because of shared naming of props (i.e. if the kube plugin changes naming, the other plugins must follow). Might not be so dangerous, but if a problem occurs here, that will be quite hard to detect.
- The nature of the props are not flat (envs, ports are maps) and a flat property list doesn't really fit. Of course, one can find a way around this (with naming conventions as you suggest), but personally I would find to have a hierarchically configuration format (XML, JSON, YAML) would feel better.
I think supporting properties as you suggest is fine, but we should put the responsibility to one plugin, with the other plugins supporting the syntax. Let's say fabric8 is the leading plugin, then one could say the docker-maven-plugin has support for the fabric8 plugin (for a specific version). So its clear, that they are separate.
The, it would be nice to have a universal, probably external configuration format (which then can be referenced from the plugins' configuration) describing this. There are already some (fig, kubernetes, soon: groups.yml when Docker supports intrinsic composition).
Another question for me is: For the fabric8 case, do you always have a single image or should multiple images be configured via properties ? If a single image is sufficient, I think I could have a nice default with properties which simply also only configure a single image (or add an extra image to the list of configured images in the docker-maven-plugin's config).
For globally applicable properties (registry, etc.) I will introduce properties, too (Currently the registry stuff still needs some polishing).
'will start to implement the property default for a single image soon ...
from docker-maven-plugin.
External configuration
In order to avoid implicit dependencies on property names I suggest to create an external link to an 'external' configuration. This external configuration then can specify one or more image configuration (with run and build parts). Examples for external configurations are:
- Properties from the
fabric8
Plugin or even direct access to the plugin's configuration (if this is feasible from within Maven). - Reference to a
fig.yml
(or later forgroups.yml
when Docker groups are released) for extracting the plugin's configuration.
My suggestion is to include this as part of the regular configuration, e.g.
<configuration>
<images>
<image>
<reference>
<!-- Lookup the known properties evaluated by the fabric8 plugin -->
<type>fabric8</type>
</reference>
</image>
<image>
<reference>
<!-- Use a Fig definition and add one or more images to the list -->
<type>fig</type>
<definition>src/main/resources/fig.yml</definition>
</reference>
</image>
<!-- "Normal" image definitions -->
.....
</images>
</configuration>
Then the docker-maven-plugin
has a list of plugins (keyed by type
) which know how to create image definitions for these external systems. I like the idea of having plugins for a plugin ;-) Also this would directly support my use case of using fig compositions files directly for this plugin.
What do you think about this idea ?
We could go even farther: Considered we have such a plugin infrastructure, we could use Maven's DI (via Plexus) to get these config plugin from outside of this docker plugin. That way (if this is possible, still have to lookup some Plexus magic) the fabric8 plugin itself could maintain its configuration handling (and property lookup) so that there is even less dependency. The only drawback would be that the fabric8 Plugin then would have some code dependencies on this docker-maven-plugin in order to implement the interface
from docker-maven-plugin.
I implemented a first version for this feature for referenced configuration. The snapshot 0.10.5-SNAPSHOT has been pushed to Maven central.
You can try it with the following configuration:
<profile>
<id>props</id>
<properties>
<docker.name>jolokia/${project.artifactId}:${project.version}</docker.name>
<docker.alias>service</docker.alias>
<docker.from>${image}</docker.from>
<docker.assemblyDescriptor>src/main/docker-assembly.xml</docker.assemblyDescriptor>
<docker.env.CATALINA_OPTS>-Xmx32m</docker.env.CATALINA_OPTS>
<docker.env.JOLOKIA_OPTS>1</docker.env.JOLOKIA_OPTS>
<docker.ports.jolokia.port>8080</docker.ports.jolokia.port>
<docker.wait.url>http://localhost:${jolokia.port}/jolokia</docker.wait.url>
<docker.time>10000</docker.time>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.jolokia</groupId>
<artifactId>docker-maven-plugin</artifactId>
<configuration combine.self="override">
<images>
<image>
<reference>
<type>props</type>
<prefix>docker</prefix>
</reference>
</image>
</images>
</configuration>
</plugin>
</plugins>
</build>
</profile>
Is that approximately that what you need ? In the native configuration ports
and env
configuration are separately definable which in this simple format is not the case (the same is both for building and running images).
Maybe you could give it a try ? You can find the code (along with the example) in branch 42-external-config
. The example is in samples/data-jolokia-demo
and can be switched on with the profile props
.
from docker-maven-plugin.
Oh that looks awesome!!! :) Many thanks!
Providing a configurable prefix sounds like a nice way to do things; then folks can share properties; or make them unique between properties if required etc.
I agree with your other comments too. It does seem maven properties are a nice compositional way to configure things. What I don't like about the external configuration file thing is; if you're going to copy/paste a blob of properties/xml/json from project to project, you may as well just copy the XML inside the plugin XML's <configuration> ;). Having an external config file just seems to make things more brittle and in many cases doesn't have any reuse ability. (The difference is for things like assembly.xml files which are often just parameterised with the current project artifact/version).
i.e. the thing I like about maven properties is that if we have a project which defines, say, a bunch of different images which all share the same base image and env vars; we can keep things DRY and put those into a parent pom.xml; then just override/add new properties when required - rather than copying/pasting a config file into every project.
Another idea we had (Jimmi Dyson) was to have an uber mvn plugin that invoked all the other plugins directly passing in the configuration; though that does seem quite brittle and we need to keep re-releasing the uber plugin as any other plugin changes. So I'm liking the loose coupling approach via maven properties so far - seems the least sucky way to do it at least ;).
I wish also there was a way to define a BOM like thing for maven plugins; so we could have standard configurations for things like the docker-maven-plugin / fabric8-maven-plugin / jube-maven-plugin. So far the closest I've seen in this direction is maven tiles but I've not had time to play with it yet.
from docker-maven-plugin.
I agreed that we might reuse in the configuration could be better, and I also wished there would be better (or any ;-) support for composition of poms (even support for standard XML includes would be a step in the right direction).
As mentioned above on the roadmap is support for Fig configuration and the forthcoming docker composition files. Maybe that could be a common base for our configuration needs ? (though not sure whether this syntax supports all features required).
I just released 0.10.5 with the property support as discussed (with some minor changes in the port mapping syntax since the last checking), so I'm going to close this issue for now. Feel free to reopen in case.
from docker-maven-plugin.
Related Issues (20)
- RegistryServiceTest : remove unused variable `hasImage` and `dockerFileUtilMockedStatic` HOT 3
- LogRequestor : Replace `com.google.common.base.Charsets.UTF_8` with `StandardCharsets.UTF_8` HOT 5
- Turning on JIB mode breaks multi-assembly images HOT 2
- <run><wait> no longer working correctly
- Cannot find default setter in class io.fabric8.maven.docker.config.ImageConfiguration while trying to execute docker:start goal HOT 1
- Can't use <packaging>docker</packaging> in a multi-module project HOT 1
- Version 0.44.0 fails to use the `<args>` configuration to populate the Docker build-args HOT 5
- support Dockerfile RUN <<EOF HOT 1
- docker:push failed with ARG in FROM HOT 5
- DockerComposeServiceWrapper : Use `isEmpty()` to check collection is empty HOT 3
- WatchService : Anonymous `new Runnable()` can be replaced with lambda HOT 5
- Quickstarts : Improve `it/spring-boot-with-jib` integration test HOT 2
- Ability to
- Error Encountered When Building Multi-Architecture Docker Images Using docker-maven-plugin HOT 1
- Write portPropertyFile as soon as the container is started
- Unable to push docker images to Nexus using "docker-maven-plugin" HOT 1
- External Compose and Wait seems not working HOT 1
- Expected a com.google.gson.JsonObject but was com.google.gson.JsonArray
- Follow settings ingored unless specified from command line HOT 1
- How to mount secrets on build?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-maven-plugin.