karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david.a.jen...@gmail.com>
Subject Re: Levels of Containerization - focus on Docker and Karaf
Date Fri, 13 Jan 2017 22:20:53 GMT
I’m not sure you understand the difference between config admin and a management agent. 
IMO you are asking for a different management agent than the one Karaf usually uses.

So far I’ve proposed two sorts of environment-variable aware management agents: 

- property substation into something like property files.  This might be appropriate if the
configurations needed for OSGI have a lot of stuff that doesn’t need to be configured per-docker-instance

- interpreting environment keys into pid + configuration key.  This might be appropriate if
all the information needed for OSGI should be configured per-docker-instance

Obviously there are a lot of other possible approaches.  Figuring out how this might interact
with the configurator spec proposed for R7 might be a good idea too.

Once you’ve decided what you want the management agent to do, writing it and assembling
a karaf using it is pretty easy.  I’m assuming that whoever does this is going to contribute
it to Karaf and that since it’s obviously a good idea it will get included in some form.
 If I understand Elliot Metsger’s posts correctly karaf already supports the property substitution
approach.  What specifically do you want different from what’s already working?

david jencks


> On Jan 13, 2017, at 2:01 PM, Dario Amiri <dariushamiri@hotmail.com> wrote:
> 
> You should not have to build a new docker container image for every possible type of
configuration. Just look at any standard docker images in the public Docker registry. All
configuration is driven from the environment variables. There is a multitude of examples in
the public docker registry.
> 
> A new implementation of ConfigurationAdmin sounds like a good way to solve the problem.
However, I don't have the expertise to build and maintain that on my own. Nor should I because
this is an ubiquitous pattern for all Dockerized applications. Karaf should do this out of
the box if it wants to play well with Docker.
> 
> Zookeeper is great, but what about the coordinates to Zookeeper? Where do I configure
that? We're back to the same problem. Also, Zookeeper is likely too heavy a solution for some
people (me included).
> 
> D
> 
> On 01/13/2017 01:13 PM, Nick Baker 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 <dariushamiri@hotmail.com> <mailto:dariushamiri@hotmail.com>
>> Sent: Friday, January 13, 2017 3:21:17 PM
>> To: user@karaf.apache.org <mailto:user@karaf.apache.org>
>> 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:dariushamiri@hotmail.com <mailto:dariushamiri@hotmail.com>]

>>>> Sent: Friday, January 13, 2017 1:28 PM
>>>> To: user@karaf.apache.org <mailto:user@karaf.apache.org>
>>>> 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 <gnodet@apache.org> <mailto:gnodet@apache.org>
>>>> 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 <prasenjit@rogers.com <mailto:prasenjit@rogers.com>>:
>>>> 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
<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
<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:gnodet@redhat.com>gnodet@redhat.com <mailto:gnodet@redhat.com>
>>>> Web: http://fusesource.com <http://fusesource.com/>
>>>> Blog: http://gnodet.blogspot.com/ <http://gnodet.blogspot.com/>
>>>>  
>>>>  
>>> 
>> 
> 
> 


Mime
View raw message