<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think having a docker container based installer of kubernetes apps or OpenShift templates is going to be very useful.<div class=""><br class=""></div><div class="">e.g. right now fabric8 creates a large number of apps; we’d like an easy way to install them (or a subset of them) on any kubernetes environment (e.g. Atomic / OpenShift / GKE) then have OpenShift specific extensions (routes and templates) so that when they are installed on OpenShift they can take advantage of the extensions (routes etc).</div><div class=""><br class=""></div><div class="">Its pretty trivial to take an OS template and expand it purely client side in the installer then turn it into normal kubernetes stuff; so am even tempted to just say everything’s an OpenShift Template (with some things not having any parameters) - then if not using OpenShift we’d expand the templates on the fly first before applying them?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Right now we’ve been using a bash script to install fabric8; but a more generic tool for installing M apps out of a possible N apps (with template parameterising) is going to be very useful I think.</div><div class=""><br class=""></div><div class="">The general idea of putting all the kubernetes / openshift json/yaml on disk some place; adding some extra ‘compose’ metadata on top (e.g. to group things into larger chunks) and then having reusable tools to install them sounds great.</div><div class=""> </div><div class=""><br class=""></div><div class="">Am sure lots of other parts of RHT are gonna be making kubernetes based apps with independent release cycles from the OpenShift project which may want to be consumed on any version of kubernetes / Atomic / OpenShift / GKE etc. (e.g. the cloud enablement folks are making apps for EAP and Fuse; the Management.Next folks already have apps for hawkular / cassandra / monitoring; we’ve loads of apps in fabric8 and then customers will have the same need for their apps).</div><div class=""><br class=""></div><div class="">So I like the idea of having a standard ‘installer’ docker container base we can add kubernetes & OpenShift metadata files into some folder and get an easy way to distribute and install things; either from the command line or via a nice little web app.</div><div class=""><br class=""></div><div class="">BTW we’d be happy to hack on a little HTML5 console for letting the user choose what apps to install and to create a little form to customise etc too. We’ve already a little UI for choosing apps to run in hawtio; so we’ve lots of the work done already.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Then the installation process would either use vanilla kubernetes REST APIs; optionally use OpenShift REST extensions and any extra Atomic stuff etc.</div><div class=""><br class=""></div><div class="">One key thing the installer needs to do is install all services first before any other resource (to fix any cyclical dependency issues; you need to pre-define the services to get them bound to IP addresses in kubernetes before starting any pods).</div><div class=""><br class=""></div><div class="">Another thing we’d find really handy is automatically creating OpenShift routes for all services given a configurable domain. e.g. service “foo” gets a route created at “<a href="http://foo.cheese.something.com" class="">foo.cheese.something.com</a>” if the DOMAIN=“<a href="http://cheese.something.com" class="">cheese.something.com</a>”. It doesn’t make sense to release OpenShift Routes metadata for each service; since they really just depend on the domain being used. (Though we maybe need to add annotations to services to customise the generation of them if a user wishes to add TLS termination stuff or maybe use a different host name other than ${serviceName}.${DOMAIN).</div><div class=""><br class=""></div><div class="">Another thing we’ve found handy with our current bash based installer is being able to run it purely in ‘download docker images first’ mode; together with an option to pull the latest images first before installing.</div><div class=""><br class=""></div><div class="">(More details on the bash script here:)</div><div class=""><a href="http://fabric8.io/guide/openShiftDocker.html#run-the-start-script" class="">http://fabric8.io/guide/openShiftDocker.html#run-the-start-script</a></div><div class=""><br class=""></div><div class="">Has work started on the installer? We kinda need one soon for fabric8; to more easily install it on OpenShift & on Atomic so we could maybe start hacking on the installer together? Is there an issue tracker we can start adding issues/ideas to?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 14 Apr 2015, at 15:14, Christoph Görn <<a href="mailto:goern@redhat.com" class="">goern@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">-----BEGIN PGP SIGNED MESSAGE-----<br class="">Hash: SHA1<br class=""><br class="">Hey James,<br class=""> just a few hrs ago Aaron merged a big bunch of changes I made to the<br class="">Container Application Specification. So please have a look at<br class=""><a href="https://github.com/aweiteka/containerapp-spec/tree/master/spec/0.0.1-alp" class="">https://github.com/aweiteka/containerapp-spec/tree/master/spec/0.0.1-alp</a><br class="">ha<br class=""><br class="">We have had a look at fabric8 app zip and tried to consider the<br class="">problem space you are working in, so any feedback is very welcome!<br class=""><br class="">The idea in the end of you mail is pretty much the behavior we (Vasek)<br class="">will implement in the Atomiapp Base Image we hope to have ready shortly.<br class=""><br class="">Please keep in mind that we are going to also deliver ISV applications<br class="">as a container (using docker container image format), that container<br class="">shall be deployable on a variety of platforms (openshift,<br class="">atomicplatform, rhel7+docker).<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>//G<br class=""><br class="">On 04/13/2015 04:57 PM, Carl Trieloff wrote:<br class=""><blockquote type="cite" class=""><br class=""><br class="">some good info.<br class=""><br class=""><br class="">-------- Forwarded Message -------- Subject: <span class="Apple-tab-span" style="white-space:pre"> </span>Re: Container App<br class="">Spec and Tooling Date: <span class="Apple-tab-span" style="white-space:pre"> </span>Mon, 13 Apr 2015 14:55:27 +0100 From:<br class="">James Strachan <jstracha@redhat.com> To: <span class="Apple-tab-span" style="white-space:pre"> </span>Aaron Weitekamp<br class=""><aweiteka@redhat.com> CC: <span class="Apple-tab-span" style="white-space:pre"> </span>cctrieloff@redhat.com, John Mark Walker<br class=""><jowalker@redhat.com>, Marek Goldmann <mgoldman@redhat.com>, James<br class="">Rawlings <jrawling@redhat.com>, Kevin Conner <kconner@redhat.com>,<br class="">Carl Trieloff <ctrielof@redhat.com>, Ian McLeod<br class=""><imcleod@redhat.com><br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On 13 Apr 2015, at 13:53, Aaron Weitekamp <aweiteka@redhat.com><br class="">wrote: ----- Original Message -----<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On 10 Apr 2015, at 19:22, Carl Trieloff<br class=""><cctrieloff@redhat.com> wrote:<br class=""><br class="">On 04/10/2015 01:24 PM, James Strachan wrote:<br class=""><blockquote type="cite" class="">sounds good; I can’t make Tuesday but can do wednesday<br class="">though.<br class=""><br class="">FWIW on the Java side of the house we’re using a maven<br class="">plugin which generates the kubernetes metadata for an<br class="">application (WAR, executable jar, Spring Boot, Camel Boot,<br class="">micro service, OSGi etc); it creates the Kubernetes Service<br class="">& Replication Controller etc: <br class="">http://fabric8.io/guide/mavenPlugin.html#generating-the-json<br class=""></blockquote><br class=""><blockquote type="cite" class=""><br class=""></blockquote><br class="">I would if we could also generate the container-app spec<br class="">instance from the maven plugin?<br class=""></blockquote><br class="">we always welcome PRs :)<br class=""><br class="">I don’t yet grok the value proposition for the Java person<br class="">who’s got a generated kubernetes JSON and an OpenShift Template<br class="">- what extra value does a generated container-app spec instance<br class="">add? Mind you I confess to not really grokking yet the<br class="">difference between a container-app spec yet and the existing<br class="">Kubernetes JSON/YAML & OpenShift Template file.<br class=""></blockquote><br class="">The confusion is reasonable given the early stage of this and our<br class="">struggle to communicate it concisely. The problem we are<br class="">addressing is how an ISV or an internal dev-ops shop packages and<br class="">distributes an entire application with all of its dependencies<br class="">and configuration options so that it can be run reliably.<br class=""></blockquote><br class="">We tried this out in fabric8 using an ‘app zip’ as a single binary<br class="">distro that can be run with 1 click on the fabric8 console etc <br class="">http://fabric8.io/guide/appzip.html<br class=""><br class="">e.g. here’s all the app zips for the standard apps in fabric8 right<br class="">now: <br class="">http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.<br class=""></blockquote>0.41/<br class=""><blockquote type="cite" class=""><br class=""><br class=""></blockquote>http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.0.<br class="">41/apps-2.0.41-app.zip<br class=""><blockquote type="cite" class=""><br class="">and app zip is just a zip file of one or more folders of apps;<br class="">which each app is a folder with kube json, icon, readme docs etc.<br class="">Though we don’t put the docker images in the app zip; we assume<br class="">they are out of bounds via docker registries to make use of<br class="">docker’s layering & caching.<br class=""><br class="">The fabric8 console then lets you drag and drop them from your<br class="">desktop to the console or vice versa making it really easy to<br class="">release them or share them etc. <br class="">http://fabric8.io/guide/console.html#library<br class=""><br class=""><br class="">Though we’re working on how to unify this with the OpenShift<br class="">templates; so that the maven plugin that generates the kube<br class="">json/app zip can just embed all the metadata inside an OpenShift<br class="">template as well. See this issue for more detail: <br class="">https://github.com/openshift/origin/issues/1629<br class=""><br class="">the remaining issue is how to install a group of templates<br class="">atomically (where each template can then be run separately); as<br class="">Clayton comments on the above issue, this could be a CLI command<br class="">with a wildcard or directory: <br class="">https://github.com/openshift/origin/issues/1629#issuecomment-90982029<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">We want to deal with containers, not configuration files. So any<br class="">implementation of the spec results in a container, not a file or<br class="">set of files that need to be managed. An ISV could hand you this<br class="">container and it is all you need to run their application.<br class=""></blockquote><br class="">when you say container above do you mean it in the docker / LXC<br class="">sense or as in a collection of things in some kind of packaging? If<br class="">the former then its confusing ;) as kubernetes already deals with<br class="">JSON/YAML and separate docker images in a docker registry. A single<br class="">kube json / OpenShift template can map to many services and docker<br class="">containers. If its the latter then going forward maybe use the<br class="">word “package” or some other word than container ;)<br class=""><br class=""><br class=""><blockquote type="cite" class="">The OpenShift template could be enough to describe a given<br class="">application. We're taking those concepts and making the<br class="">templating easier to develop, encourage composite or chaining of<br class="">components and provide a standard for passing these things around<br class="">(meta packaging).<br class=""></blockquote><br class="">OK. FWIW its pretty straightforward to take a number of OpenShift<br class="">templates and generate a new OpenShift template composing them<br class="">together (just concatenate the ‘items’ array in JSON); the main<br class="">complexity is the parameter expansion; do you assume each parameter<br class="">in each template is a separate value; or do you try to share<br class="">parameter names/values across templates in the composite (which<br class="">probably requires user configuration to differentiate).<br class=""><br class="">Incidentally I’d like to see the Template extension from OpenShift<br class="">to be pushed up to Kubernetes too so its available in all<br class="">Kubernetes environments as its a powerful idea.<br class=""><br class="">Looking forward to the meeting as we found manually creating<br class="">kubernetes json / OpenShift templates to be surprisingly error<br class="">prone (hence the maven plugin). Am sure we could use more tools to<br class="">make them easier to create/maintain.<br class=""><br class=""><br class="">One idea thats on my TODO list to experiment with was using<br class="">CoffeeScript as a DSL for generating kubernetes json / yaml /<br class="">OpenShift Templates as it already looks like YAML but with<br class="">functions and variable expansion; so its easy to reuse, for<br class="">example, labels or objects of env vars etc. Kinda like the Saas /<br class="">SCCS idea from CSS; adding variables/functions to a DSL helps make<br class="">more DRY metadata files.<br class=""><br class="">e.g. a k8s DSL file could be like:<br class=""><br class="">#/bin/k8sdsl<br class=""><br class="">labels = x: "123" bar: "abc"<br class=""><br class="">return service id: "James" selector: labels port: 3000<br class=""><br class=""><br class="">which then has a set of functions like ‘service’ to generate the<br class="">service json which are implicitly included by the k8sdsl script:<br class=""><br class=""># default api version... apiVersion = "v1beta3"<br class=""><br class=""># function to return a kubernetes Service service = (x) => <br class="">x.apiVersion = apiVersion x.kind = "Service" return x<br class=""><br class="">.. ditto for all other k8s and openshift resource...<br class=""><br class=""><br class="">James ------- Red Hat<br class=""><br class="">Twitter: @jstrachan Email: jstracha@redhat.com Blog:<br class="">http://macstrac.blogspot.com/<br class=""><br class="">hawtio: http://hawt.io/ fabric8: http://fabric8.io/<br class=""><br class="">Open Source Integration<br class=""><br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________ Container-tools<br class="">mailing list Container-tools@redhat.com <br class="">https://www.redhat.com/mailman/listinfo/container-tools<br class=""><br class=""></blockquote><br class="">- -- <br class="">Principal Software Engineer - Systems Design & Engineering<br class="">Mobile: +49 171 2801345<br class=""><br class="">Follow Us: https://twitter.com/RedHatRefArch<br class="">Plus Us: https://plus.google.com/u/0/b/114152126783830728030/<br class="">Like Us: https://www.facebook.com/rhrefarch<br class=""><br class="">Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,<br class="">Handelsregister: Amtsgericht München, HRB 153243<br class="">Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill,<br class="">Charles Peters<br class="">-----BEGIN PGP SIGNATURE-----<br class="">Version: GnuPG v2<br class=""><br class="">iQIcBAEBAgAGBQJVLSDcAAoJEKn71953Oyo0+A8P/iJ9jpRinUS8UcTxPMKTQGtp<br class="">1bpZfCkweKn6FDBpydjHAmql3Z/wTJIvW4ZGVfHmfk6XyskVMqyACH6cQ5KNuYQv<br class="">znFpS0srvHNWnrsjP2uHH3BDtlp84ffJi5Q/d+Uqr4vBMfVUAAVB87EWoStM9S+6<br class="">g9zv3pEUb3pQfRZnQtN/dHCinePSnv+WSo/eVyXeJwAwO6VpFHe9/cm2gJkGUP2t<br class="">XIm4jTU1ZFgBpE9IqJZeYmM+rtKcinGljGXJBtW/ty1JUk3rsiKpP5m0hCG66MtV<br class="">V54ZYcIKjvyhAk/3X80E6hUtWhcyaOqy6Ie7G+vfejfIis60l1tusssvCKu/3P+5<br class="">l0fyILY3At/3g7oRQl9wCMKqDqWo2Y7EHRHraXrJ07j7smE69DULiIZAS/vreQvy<br class="">pW0tcoRi04zXpKuFAtQwF6mwHcpqgH8j+WpOZOlCnAjvyM1oOKU8E+YChT7Ick5r<br class="">gQe4UMqXfcZ8VP9VsLsNjG4GGoYh8SORWpWNLqLB0JBLjjRY6qv25upWqCKQF7nZ<br class="">f/JcIWW7KvCPB9Wvh4t+J9G7zLIdNWwqrndrPaA5gZVQMFBsohXn+eo80+9ytlYI<br class="">ev24z+xKUw1JlLjsMwO6zUeEC+yibpU/j6HBODILjLwJZS1ikPqDh2FtqXolcBie<br class="">VzFRhfzT91QS2MZIEsAf<br class="">=HopR<br class="">-----END PGP SIGNATURE-----<br class=""></div></blockquote></div><br class=""></div></body></html>