karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dario Amiri <dariusham...@hotmail.com>
Subject Re: Levels of Containerization - focus on Docker and Karaf
Date Fri, 13 Jan 2017 21:53:25 GMT
The point is that Karaf does not read configuration from an environment variables; it reads
configuration from files. In Docker, you can pass environment variables in the arguments for
running a container; however, you can't pass configuration files in those argument.

Due to this limitation, rather than using a single Docker container for all possible configurations.
I have to create a separate Docker image for every possible configuration. If you're not familiar
with Docker, then an analogy would be if a Java application could only read it's configuration
from a classpath resource of the containing jar. Then, I would have to build a the jar every
time I wanted a different configuration. This is not the best way for doing things when building
cloud native applications.

There's a set of well-accepted patterns and anti-patterns for building cloud native applications.
Reading configuration from the environment instead of from the file system is one of them.
I highly recommend having a look at: https://12factor.net

D

On 01/13/2017 01:06 PM, David Jencks wrote:
I don’t really know anything about Docker.  It sounds like you can start Docker instances
so that each instance has different environment variables?  Otherwise it’s not clear to
me what the point of what you want is.

I would think it would be pretty easy to extend fileinstall (or whatever Karaf uses to move
the configuration from files to config admin) so it would do property substitution based on
environment variables.

david jencks

On Jan 13, 2017, at 12:21 PM, Dario Amiri <<mailto:dariushamiri@hotmail.com>dariushamiri@hotmail.com<mailto:dariushamiri@hotmail.com>>
wrote:


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.tar

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]
Sent: Friday, January 13, 2017 1:28 PM
To: <mailto:user@karaf.apache.org> 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 <mailto:gnodet@apache.org> <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 <<mailto:prasenjit@rogers.com>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>



--
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<http://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/







Mime
View raw message