[Container-tools] docker container based installers for Atomic / OpenShift V3 / GKE et al (was Re: Container App Spec and Tooling

Thu Apr 30 13:32:02 UTC 2015

> On 30 Apr 2015, at 12:41, Christoph Görn <goern at redhat.com> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hey all, James, thanks for the feedback. You touched a few aspects and
> first I will focus on the development and collaboration aspect with
> some inlined comments.
> 
> 	//G
> 
> [1] - https://github.com/projectatomic/nulecule/
> [2] - https://github.com/vpavlin/atomicapp-run
> [3] - https://github.com/goern/mongoDB-atomicapp/
> [4] - https://goern.github.io/mongoDB-atomicapp/
> [5] - https://trello.com/c/FfKIFdvV
> [6] - https://github.com/vpavlin/atomicapp-run/issues/new
> 
> On 04/30/2015 11:43 AM, James Strachan wrote:
>> I think having a docker container based installer of kubernetes
>> apps or OpenShift templates is going to be very useful.
> 
> The Atomicapp will not only create openshift templates but also route,
> service and all other kind of objects... So what you are referring to
> as an "OpenShift template" is what an Atomicapp would carry as "a
> openshift provider specific artifact”.

In our case; we’re curating our own OpenShift templates as are others (Cloud enablement folks, Management.Next folks); we just need a way to package them up and compose them together into bigger chunks so they can be easily installed on Atomic / OpenShift / Kubernetes. I’m hoping we can get the fabric8 maven plugin to auto-generate the wrapping Atomicapp file(s); maybe with a bit of extra custom metadata...

So in this particularly case; I don’t need any tooling to generate the OpenShift templates; but I do want to be able to nicely compose them into groups and have an installer (and am more than happy to generate/hand create whatever else metadata files are required). So I was hoping to just start using your atomicapp-run stuff...

> We have made good progress with the Nulecule Specification [1] itself,
> and we are working on the reference implementation named Atomicapp [2].
> 
>> 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).
> 
> Sounds like you are going to provide an Atomicapp with a kubernetes
> provider and an openshift provider that inherits some of the files
> from the kubernetes provider.

Yeah.  The only thing we don’t yet generate are the Routes which we’re hoping is done by the installer really (as there’s really little in the way of metadata in them other than a host name for each service; which usually is just a matter of appending some text to the service name).

>> 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?
> 
> Ja, sound like the way we are going to implement the openshift
> provider within the Atomicapp.

TBH I’m currently leaning towards using OpenShift Templates everywhere; so there’s only 1 provider; there’s less abstractions or providers; things are simpler and there’s less to do. That provider could include OpenShift extensions too (which are trivial to filter out if using raw kubernetes with no OpenShift).

e.g. given an OpenShift template we have to process it on the client side anyway to expand any parameters before applying it on OpenShift. So the REST calls on the back end are all 100% pure Kubernetes after a template has been instantiated/processed. i.e. the install tool can use OpenShift Templates whatever the kubernetes environment is - Atomic / OpenShift / GKE etc.

Then we just filter out any OpenShift specific parts of the model (e.g. Project / DeploymentConfig / Route) if using Atomic - which TBH are quite rare anyway.

Not a huge biggie; just trying to minimise levels of indirection and work.

> I am working on a mongoDB Atomicapp [3]
> with special focus on the openshift provider. That example may be a
> good one to collaborate on and get started with [4].

Cool. I tried to use it but couldn’t figure out the python ninja stuff ;) Has anyone managed to turn it into a docker image and put it somewhere I can try use? I raised this to track it…
https://github.com/vpavlin/atomicapp-run/issues/23 <https://github.com/vpavlin/atomicapp-run/issues/23>

its gonna be easier to collaborate if we can just reuse a base docker image and put files in different folders and try it out ;)

> 
>> 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.
> 
> This will be the Atomicapp Base Docker Image, providing generic parts,
> logic to talk to the providers and LABEL to get easily installed/run.
> This task is still open [5], join in :)

Will do ;)

>> Another thing we’d find really handy is ...
> 
> We are trying to catch all these RFE/requirements/... in the
> atomicapp-run repo on github, feel free to open up issues: [6].

I’ve just brain dumped everything I can think of into the issue tracker. Whenever I can run something I’ll try create an atomicapp-run docker image for fabric8 and will probably think of more then...

>> 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?
> 
> Ja, see [6] :)
> 
> Again, thanks for the feedback. Pls make a decision which of your top
> applications (not mongodb) shall be atomized, I will help you get there.

Great thanks!

So all of them :) They’re all here:
https://github.com/fabric8io/quickstarts/tree/master/apps <https://github.com/fabric8io/quickstarts/tree/master/apps>

They are all Kubernetes JSON files today; here’s a zip with them all in (a folder per app)
http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.0.47/ <http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/apps/2.0.47/>

e.g. here’s one of them, our HTML5 console…
http://central.maven.org/maven2/io/fabric8/jube/images/fabric8/console/2.0.47/console-2.0.47-kubernetes.json

if we can get a reusable docker base image I can get our build process to try create a docker image with all the kubernetes json / OpenShift templates inside and we can experiment more…

Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150430/4d78b171/attachment.htm>