Hey Guys
Warm welcome!
Ignasi- long time no speak :-)
You raise some great questions. Forget about a docker standalone server for
now, although we do support that.
The idea is to see a cluster or a cloud of docker servers, you can say deploy x
image(s) and list running containers.
I've been speaking with some users of Docker at user groups and the interesting
use case is how do they develop a CI/CD process that can span across
Docker/Kubernetes (local private instance) and a public cloud?
Differently clouds approach that in different ways. Joyent for example wraps
the docker API and provides compat, Amazon ECS provides an API to list
containers across a group of docker nodes. Kubernetes and Google cloud are
similar. So we immediately have 4 different APIs for doing very similar tasks.
Docker is to these providers what Xen or KVM was. The only way they will
provide value is to wrap services around the docker ecosystem.
Also, Docker is not the only container spec, I don't know of any providers
running coreos yet but this is all moving so fast.
I classified the drivers into 2 types. Those that are for a single container
host and those that are for a cluster of container hosts. ECS, Kubernetes and
GCE are the latter.
With regards to deploying a graph of containers, each driver will have an
extension method for offering native actions, but I couldn't see any way of
doing that consistently yet. I would imagine defining a 'service' type with a
list of containers as an attribute and a simple reference to another service it
depends on would do the trick.
Anthony
Sent from Outlook Mobile
_____________________________
From: Andrew Phillips <andr...@apache.org>
Sent: Saturday, January 30, 2016 2:27 AM
Subject: Re: Hello from Apache Libcloud!
To: <dev@jclouds.apache.org>
> Thanks for starting this thread!
Big +1 to that - thanks, Anthony! What I'd be especially interested to
hear about are your thoughts on the feasibility of providing a level of
abstraction at this point.
The main questions for me would be:
* What is the right interface: something that can instantiate a single
image (e.g. Docker)? Or a graph of images (e.g. Kubernetes)? Or both?
* How much commonality is there across providers? At present, the
"single image providers" seem much closer to providing a standard than
the "image graph providers"...but is the single image use case really
that compelling?
* Given that the predominant paradigm for containers is "instantiate and
don't change" (vs. traditional compute, which is more like "instantiate
and modify"), what is the core value of an abstraction over multiple
providers - especially if they are largely all compatible with one API?
I.e. if all I'm trying to do is instantiate a known image, why not
simply use the Docker client or API directly?
Would be great to learn more about how you see this space!
Regards
ap
