[Container-tools] Fwd: Re: Container App Spec and Tooling

Mon Apr 13 14:57:07 UTC 2015

some good info.

-------- Forwarded Message --------
Subject: 	Re: Container App Spec and Tooling
Date: 	Mon, 13 Apr 2015 14:55:27 +0100
From: 	James Strachan <jstracha at redhat.com>
To: 	Aaron Weitekamp <aweiteka at redhat.com>
CC: 	cctrieloff at redhat.com, John Mark Walker <jowalker at redhat.com>,
Marek Goldmann <mgoldman at redhat.com>, James Rawlings
<jrawling at redhat.com>, Kevin Conner <kconner at redhat.com>, Carl Trieloff
<ctrielof at redhat.com>, Ian McLeod <imcleod at redhat.com>

> On 13 Apr 2015, at 13:53, Aaron Weitekamp <aweiteka at redhat.com> wrote:
> ----- Original Message -----
>> 
>>> On 10 Apr 2015, at 19:22, Carl Trieloff <cctrieloff at redhat.com> wrote:
>>> 
>>> On 04/10/2015 01:24 PM, James Strachan wrote:
>>>> sounds good; I can’t make Tuesday but can do wednesday though.
>>>> 
>>>> FWIW on the Java side of the house we’re using a maven plugin which
>>>> generates the kubernetes metadata for an application (WAR, executable
>>>> jar, Spring Boot, Camel Boot, micro service, OSGi etc); it creates the
>>>> Kubernetes Service & Replication Controller etc:
>>>> http://fabric8.io/guide/mavenPlugin.html#generating-the-json
>>> 
>>> 
>>> I would if we could also generate the container-app spec instance from
>>> the maven plugin?
>> 
>> we always welcome PRs :)
>> 
>> I don’t yet grok the value proposition for the Java person who’s got a
>> generated kubernetes JSON and an OpenShift Template - what extra value does
>> a generated container-app spec instance add? Mind you I confess to not
>> really grokking yet the difference between a container-app spec yet and the
>> existing Kubernetes JSON/YAML & OpenShift Template file.
> 
> The confusion is reasonable given the early stage of this and our struggle to communicate it concisely. The problem we are addressing is how an ISV or an internal dev-ops shop packages and distributes an entire application with all of its dependencies and configuration options so that it can be run reliably.

We tried this out in fabric8 using an ‘app zip’ as a single binary distro that can be run with 1 click on the fabric8 console etc
http://fabric8.io/guide/appzip.html

e.g. here’s all the app zips for the standard apps in fabric8 right now:
http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.0.41/
http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.0.41/apps-2.0.41-app.zip

and app zip is just a zip file of one or more folders of apps; which each app is a folder with kube json, icon, readme docs etc. Though we don’t put the docker images in the app zip; we assume they are out of bounds via docker registries to make use of docker’s layering &  caching. 

The fabric8 console then lets you drag and drop them from your desktop to the console or vice versa making it really easy to release them or share them etc.
http://fabric8.io/guide/console.html#library

Though we’re working on how to unify this with the OpenShift templates; so that the maven plugin that generates the kube json/app zip can just embed all the metadata inside an OpenShift template as well. See this issue for more detail:
https://github.com/openshift/origin/issues/1629

the remaining issue is how to install a group of templates atomically (where each template can then be run separately); as Clayton comments on the above issue, this could be a CLI command with a wildcard or directory:
https://github.com/openshift/origin/issues/1629#issuecomment-90982029

> We want to deal with containers, not configuration files. So any implementation of the spec results in a container, not a file or set of files that need to be managed. An ISV could hand you this container and it is all you need to run their application.

when you say container above do you mean it in the docker / LXC sense or as in a collection of things in some kind of packaging? If the former then its confusing ;) as kubernetes already deals with JSON/YAML and separate docker images in a docker registry. A single kube json / OpenShift template can map to many services and docker containers.  If its the latter then going forward maybe use the word “package” or some other word than container ;)

> The OpenShift template could be enough to describe a given application. We're taking those concepts and making the templating easier to develop, encourage composite or chaining of components and provide a standard for passing these things around (meta packaging).

OK. FWIW its pretty straightforward to take a number of OpenShift templates and generate a new OpenShift template composing them together (just concatenate the ‘items’ array in JSON); the main complexity is the parameter expansion; do you assume each parameter in each template is a separate value; or do you try to share parameter names/values across templates in the composite (which probably requires user configuration to differentiate).

Incidentally I’d like to see the Template extension from OpenShift to be pushed up to Kubernetes too so its available in all Kubernetes environments as its a powerful idea.

Looking forward to the meeting as we found manually creating kubernetes json / OpenShift templates to be surprisingly error prone (hence the maven plugin). Am sure we could use more tools to make them easier to create/maintain.

One idea thats on my TODO list to experiment with was using CoffeeScript as a DSL for generating kubernetes json / yaml / OpenShift Templates as it already looks like YAML but with functions and variable expansion; so its easy to reuse, for example, labels or objects of env vars etc. Kinda like the Saas / SCCS idea from CSS; adding variables/functions to a DSL helps make more DRY metadata files.

e.g. a k8s DSL file could be like:

#/bin/k8sdsl

labels = 
  x: "123"
  bar: "abc"

return service
  id: "James"
  selector: labels
  port: 3000

which then has a set of functions like ‘service’ to generate the service json which are implicitly included by the k8sdsl script:

# default api version...
apiVersion = "v1beta3"

# function to return a kubernetes Service
service = (x) => 
  x.apiVersion = apiVersion
  x.kind  = "Service"
  return x

.. ditto for all other k8s and openshift resource...

James
-------
Red Hat

Twitter: @jstrachan
Email: jstracha at redhat.com
Blog: http://macstrac.blogspot.com/

hawtio: http://hawt.io/
fabric8: http://fabric8.io/

Open Source Integration

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150413/2601d7b3/attachment.htm>