I'm aware of this workaround. IIRC, you still need to include an additional
Java system property in your invocation of karaf. It's a viable workaround but
not the best situation.
On 01/13/2017 01:17 PM, Elliot Metsger wrote:
We found we were able to use a formulation of property values that allowed for
sensible defaults overridden by environment variables (e.g. [1]):
fcrepo.baseURI =
${env:FCREPO_BASEURI:-<http://localhost:8080/fcrepo/rest>http://localhost:8080/fcrepo/rest}
fcrepo.proxyURI =
${env:FCREPO_PROXYURI:-<http://localhost:8080/fcrepo>http://localhost:8080/fcrepo}
apix.host = ${env:APIX_HOST:-localhost}
apix.port = ${env:APIX_PORT:-80}
apix.interceptPath = ${env:APIX_INTERCEPT_PATH:-fcrepo/rest}
apix.proxyPath = ${env:APIX_PROXY_PATH:-fcrepo}
[1]
https://github.com/fcrepo4-labs/fcrepo-api-x-demo/blob/master/apix/0.1.0/cfg/org.fcrepo.apix.routing.cfg
On Fri, Jan 13, 2017 at 4:13 PM, Nick Baker
<[email protected]<mailto:[email protected]>> wrote:
Injecting configuration into a containerized app (docker) is considered
standard practice. The friction here is the level of sophistication in OSGI
Configuration.
It seems to me what you need isn't some hack to push configurations through
environment variables, but a new implementation of ConfigurationAdmin, or an
agent which interacts with CM mirroring configurations in from an external
system.
In our usage it's common to have a "tenant", think Walmart vs Target. Setting
the tenant ID as an environment variable then having the configurations loaded
from Zookeeper or whatever, injected into CM seems right.
-Nick
________________________________
From: Dario Amiri
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>
Sent: Friday, January 13, 2017 3:21:17 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: Levels of Containerization - focus on Docker and Karaf
Let me expand on why this is desirable. Without the ability to set
configuration through environment variables, I essentially have to create a
docker image for each deployment. I have a root Dockerfile which assembles the
main Karaf container image and brings in dependencies such as the JRE, then I
have a Dockerfile for each deployment environment which builds on top of the
root image by overriding deployment specific configuration. Automation reduces
this burden but it is not ideal.
If I could set the contents of a config file in an environment variable, I
could just pass the configuration directly to my root karaf docker image
without having to build on top of it.
Being able to start Karaf as "java -jar karaf.jar" is desirable because it
makes it easier to use a Karaf based application with PaaS such as Heroku and
Cloud Foundry.
D
On 01/13/2017 12:10 PM, Dario Amiri wrote:
Ideally, I want to be able to do:
java -jar my-karaf.jar
And I can override individual configuration files using some environment
variable convention.
D
On 01/13/2017 11:56 AM, Brad Johnson wrote:
Does it have to be an executable jar file or just a standalone executable? The
static profiles actually create and zip up a full
Karaf/felix/dependency/application implementation that when unzipped has all
the standard bin directory items.
Brad
From: Dario Amiri [mailto:[email protected]]
Sent: Friday, January 13, 2017 1:28 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: Levels of Containerization - focus on Docker and Karaf
I use Docker and Karaf. I've never had a problem creating a Docker image of my
Karaf container. What I gain is freedom from having to worry about dependency
related issues such as whether the right JRE is available.
That being said there are some challenges when using Karaf to build 12-factor
apps. FWIW here's my two item list of what would make Karaf a more attractive
platform from a 12-factor app perspective.
1. The ability to inject Karaf configuration through the environment (e.g.
environment variables). Not just a single property, but an entire config admin
managed configuration file if necessary. Even the existing support for reading
property values from the environment is cumbersome because it requires having
to setup that relationship as a Java system property as well.
2. The ability to package Karaf as a standalone runnable jar. Looks like Karaf
boot is addressing this. I hope it comes with tooling that makes it easy to
transition to this kind of model.
D
On 01/12/2017 04:44 AM, Nick Baker wrote:
Thanks Guillaume!
This is perfect for our microservice/containerized Karaf. I'll give this a try
and see if we can get our features in startup. We've had issues in the past
here.
-Nick Baker
________________________________
From: Guillaume Nodet <[email protected]><mailto:[email protected]>
Sent: Thursday, January 12, 2017 5:55:24 AM
To: user
Subject: Re: Levels of Containerization - focus on Docker and Karaf
Fwiw, starting with Karaf 4.x, you can build custom distributions which are
mostly static, and that more closely map to micro-services / docker images.
The "static" images are called this way because you they kinda remove all the
OSGi dynamism, i.e. no feature service, no deploy folder, read-only config
admin, all bundles being installed at startup time from etc/startup.properties.
This can be easily done by using the karaf maven plugin and configuring
startupFeatures and referencing the static kar, as shown in:
<https://github.com/apache/karaf/blob/master/demos/profiles/static/pom.xml>
https://github.com/apache/karaf/blob/master/demos/profiles/static/pom.xml
2017-01-11 21:07 GMT+01:00 CodeCola
<<mailto:[email protected]>[email protected]<mailto:[email protected]>>:
Not a question but a request for comments. With a focus on Java.
Container technology has traditionally been messy with dependencies and no
easy failsafe way until Docker came along to really pack ALL dependencies
(including the JVM) together in one ready-to-ship image that was faster,
more comfortable, and easier to understand than other container and code
shipping methods out there. The spectrum from (Classical) Java EE Containers
(e.g. Tomcat, Jetty) --> Java Application Servers that are containerized
(Karaf, Wildfly, etc), Application Delivery Containers (Docker) and
Virtualization (VMWare, Hyper-V) etc. offers a different level of isolation
with different goals (abstraction, isolation and delivery).
What are the choices, how should they play together, should they be used in
conjunction with each other as they offer different kinds of
Containerization?
<http://karaf.922171.n3.nabble.com/file/n4049162/Levels_of_Containerization.png>
--
View this message in context:
<http://karaf.922171.n3.nabble.com/Levels-of-Containerization-focus-on-Docker-and-Karaf-tp4049162.html>
http://karaf.922171.n3.nabble.com/Levels-of-Containerization-focus-on-Docker-and-Karaf-tp4049162.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: <mailto:[email protected]> [email protected]<mailto:[email protected]>
Web: http://fusesource.com<http://fusesource.com/>
Blog: <http://gnodet.blogspot.com/> http://gnodet.blogspot.com/
