What do you think about a small example/tooling addition to simplify this ?
By the way, a bit related, I will send updates and details about Karaf DevX by the end of this week. Stay tuned ;) Regards JB > Le 14 avr. 2020 à 14:58, Alex Soto <alex.s...@envieta.com> a écrit : > > I am working now on a similar task. I have pre-populated the maven repository > directory (~/.m2/repository) from the container that made the build (I am > using multi-stage images), and set > > org.ops4j.pax.url.mvn.localRepository=/root/.m2/repository > > In `etc/org.ops4j.pax.url.mvn.cfg`. > > > Is there anything else I need to make the image self contained? JB, can you > elaborate about your reference to the system folder? > > > Best regards, > Alex soto > > > > >> On Apr 14, 2020, at 2:13 AM, Jean-Baptiste Onofre <j...@nanthrax.net >> <mailto:j...@nanthrax.net>> wrote: >> >> Hi, >> >> For the startup, you can already populate the system folder (by hand or >> using mvn deploy:deploy-file or mvn install:install-file). >> >> That’s what I’m doing in docker image preparation. >> >> Regards >> JB >> >>> Le 13 avr. 2020 à 21:09, Steinar Bang <s...@dod.no <mailto:s...@dod.no>> a >>> écrit : >>> >>> I have successfully created a docker image for my demo application based >>> on the official karaf 4.2.8 docker hub image. >>> >>> Here's what I did: >>> >>> 1. Copied etc/org.ops4j.pax.url.mvn.cfg from a karaf 4.2.8 instance, >>> and added my own maven repo >>> >>> https://gist.github.com/steinarb/62a070f6481d3e84c334a78f1c771e80#file-org-ops4j-pax-url-mvn-cfg-L113 >>> >>> <https://gist.github.com/steinarb/62a070f6481d3e84c334a78f1c771e80#file-org-ops4j-pax-url-mvn-cfg-L113> >>> >>> 2. Copied org.apache.karaf.features.cfg and added the feature repo of >>> the sample application >>> >>> https://gist.github.com/steinarb/fec331bcd37a0a7bdba850d33fcd0555#file-org-apache-karaf-features-cfg-L28 >>> >>> <https://gist.github.com/steinarb/fec331bcd37a0a7bdba850d33fcd0555#file-org-apache-karaf-features-cfg-L28> >>> and added the sample application to the list of boot features >>> >>> https://gist.github.com/steinarb/fec331bcd37a0a7bdba850d33fcd0555#file-org-apache-karaf-features-cfg-L52 >>> >>> <https://gist.github.com/steinarb/fec331bcd37a0a7bdba850d33fcd0555#file-org-apache-karaf-features-cfg-L52> >>> >>> 3. Created a Dockerfile adding to the official docker hub karaf 4.2.8 >>> image, copying in the two modified config files >>> >>> https://gist.github.com/steinarb/444ad82a63dcf156101a064666ed590c#file-dockerfile-L1 >>> >>> <https://gist.github.com/steinarb/444ad82a63dcf156101a064666ed590c#file-dockerfile-L1> >>> >>> 4. Built the image from the Dockerfile >>> docker build -t steinarb/ukelonn-demo:v2 . >>> >>> 5. Started the image >>> docker run -p 8101:8101 -p 8181:8181 -d steinarb/ukelonn-demo:v2 >>> >>> 6. The container took a while to start but eventually I could connect >>> to http://localhost:8181/ukelonn <http://localhost:8181/ukelonn> where I >>> found the demo version of >>> my application running >>> >>> The downsides of this approach, are: >>> 1. Container startup is slow since features and their dependencies must >>> be downloaded >>> >>> 2. The maven repons may not be reachable at startup time and container >>> startup will fail >>> >>> 3. What the maven repos serve may potensially not be the same on each >>> startup >>> >>> All of the above is, I guess, sort of contrary to docker philosophy, >>> which is to pack up everything the application needs to start, so that >>> the application can be started in a predictable and reproducable manner. >>> >>> However, for this particular application, this is actually what I want: >>> I can create a docker image and deploy to docker hub, and on any docker >>> installation that can pull from dockerhub and can reach internet, I can >>> spin up the latest snapshot with the two commands "docker pull" and >>> "docker run". >>> >> >
