[Container-tools] docker container based installers for Atomic / OpenShift V3 / GKE et al (was Re: Container App Spec and Tooling
Christoph Görn
goern at redhat.com
Thu Apr 30 11:41:20 UTC 2015
-----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".
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.
> 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. 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].
> 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 :)
> 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].
> 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.
//G
>> On 14 Apr 2015, at 15:14, Christoph Görn <goern at redhat.com
>> <mailto:goern at redhat.com>> wrote:
>>
> Hey James, just a few hrs ago Aaron merged a big bunch of changes I
> made to the Container Application Specification. So please have a
> look at
> https://github.com/aweiteka/containerapp-spec/tree/master/spec/0.0.1-a
lp
>
>
ha
>
> We have had a look at fabric8 app zip and tried to consider the
> problem space you are working in, so any feedback is very welcome!
>
> The idea in the end of you mail is pretty much the behavior we
> (Vasek) will implement in the Atomiapp Base Image we hope to have
> ready shortly.
>
> Please keep in mind that we are going to also deliver ISV
> applications as a container (using docker container image format),
> that container shall be deployable on a variety of platforms
> (openshift, atomicplatform, rhel7+docker).
>
> //G
>
> On 04/13/2015 04:57 PM, Carl Trieloff wrote:
>>>>
>>>>
>>>> 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-909820
29
>>>>
>>>>
>>>>
>>>>>
>>>>
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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Container-tools mailing list Container-tools at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/container-tools
>>>>
>
>
- --
Principal Software Engineer - Systems Design & Engineering
Mobile: +49 171 2801345
Follow Us: https://twitter.com/RedHatRefArch
Plus Us: https://plus.google.com/u/0/b/114152126783830728030/
Like Us: https://www.facebook.com/rhrefarch
Red Hat GmbH, http://www.de.redhat.com/ Sitz: Grasbrunn,
Handelsregister: Amtsgericht München, HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill,
Charles Peters
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVQhTgAAoJEKn71953Oyo0oNAQAKTVRdPl5LskEC4YOLkIs/Zu
7Wbzmr2Oa7A0HW0fBwX3Kz0/5D0cPGicYZmrjbqGxalPOLXop/KP6b/nQLRMzhlN
hOW2bcoiVtBAyZPrDq1oM65rRLj924zW03fiwpQaRqSZfuzDeJRimJHBrbL4X68K
jJGT3z53cIRITO4kA4eDCB0sRG90XiNnF5O2dRS5b956ClgJKBP8BpX631C9U/+D
9SJ0E6Z+flDsSC3akHeVeBkJKiWkFW0ONnysGsmpw+OJeSjD4zxxWa1zVPj9bGPr
wlonaXgC8h/jwmcKhLNkXD0mxn4L7vxVUQim0Inw2B6Y8sYvfLc8+Ki47OLlqBiE
ba3+ItIqgTKhSSDhczrebQdKX0aCnoFSyMiZ/SdQHfjND7scHNeI3Vl3z6IH2OmP
egIhEIB6Fb8kXbDStDw22UusoA9cEob92sk2Bbib+tX9rhADvYJRKvX/d3Zvu8/x
REG2lTKWR4TRI0+m8Pm14UOJ2mxf5XKMFhZYUQ7HeEFER9bGwKWGqR+kv3vrgwO/
nbPX0rJaqkQqlgbv3kIG2Kei1PzT5SlqSFLGXEjepMXcoX54eQDHCJ97FYRjYokM
l/az+S9g/LgRiq8XPUui6dlrm18YR7Le9yo+03i8QKFbBvAyFBh7nj4pmtm/96N5
A2OH3cpSiqfrB3f5y58k
=nLi0
-----END PGP SIGNATURE-----
More information about the Container-tools
mailing list