karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliot Metsger <emets...@gmail.com>
Subject Re: Levels of Containerization - focus on Docker and Karaf
Date Fri, 13 Jan 2017 21:17:13 GMT
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}
fcrepo.proxyURI = ${env:FCREPO_PROXYURI:-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 <nbaker@pentaho.com> 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>
> *Sent:* Friday, January 13, 2017 3:21:17 PM
>
> *To:* 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
> <dariushamiri@hotmail.com>]
> *Sent:* Friday, January 13, 2017 1:28 PM
> *To:* 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> <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
>
>
>
>
>
> 2017-01-11 21:07 GMT+01:00 CodeCola <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.
>
>
>
>
>
> --
>
> ------------------------
> Guillaume Nodet
> ------------------------
>
> Red Hat, Open Source Integration
>
>
>
> Email:  <gnodet@redhat.com>gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>
>
>
>
>
>
>

Mime
View raw message