On Thu, Aug 28, 2014 at 12:50 PM, chris snow <chsnow...@gmail.com> wrote:

> On Thu, Aug 28, 2014 at 3:44 AM, Lakmal Warusawithana <lak...@wso2.com>
> wrote:
> > Hi devs,
> >
> > I did some research on $subject and IMO kurburnetes integration going to
> be
> > worthwhile thing. Below is the possible way of integration and some
> > benefits.
> >
> > Kuburnetes provide docker provisioning (orchestration), scheduling across
> > docker host cluster, Self-healing mechanisms, such as auto-restarting,
> > re-scheduling, and replicating containers. IMO we should used them
> without
> > inventing the wheel. I was there in Linixcon and google heavily use this
> in
> > large-scale. in current state they are creating 2 million new dockers
> weekly
> > using kuburnetes.
> >
> > So, with kurburnetes we can handover docker management scheduler to
> > kurburnetes without handling in autoscaler.  which mean we are not going
> to
> > have deployment policies and partitions docker in stratos. Only there is
> > auto scaling policy. But it will not change for VM based cartridges which
> > currently has.
> >
> > We can extend jclouds for support kurburnetes, mean we may no need to
> used
> > docker api, instead we need to have kurburnetes API.
> >
> > WIth docker, we are doing to have two mode, dockers top of VM and dockers
> > top of bare-metal.(its simple version is dev env)
> >
> > Below is the initial design we can consider.
> >
> > need to have global docker registry for a stratos deployment
> >
> > cartridge definition should have a docker file attached related to the
> > cartridge. e.g if PHP cartridge definition, should attached php docker
> file.
> > IMO we should used same for any other type, like puppet, it should
> attached
> > puppet module (location) and we can dynamically install this module into
> > puppet master, which Raj and Lasindu suggest in separate thread. So this
> > going to be generic, while deploying cartridge definition, we are
> expecting
> > related docker, puppet, .etc files for that cartridge and dynamically
> setup.
> > then we can build docker file and upload (push) image into global (for
> > stratos) docker registry.
>
> Will a Stratos docker images (e.g. php image) be immutable and not
> have puppet agent installed inside the image?
>

Good point. In that case, I think we can have both docker file and puppet
module bundle with the cartridge definition. (mean we should not
limited to one orchestration method attaching to cartridge definition.
should allowed multiple) Then puppet module will deploy to puppet master
and docker file build and create docker image for puppet based cartridge.



>
> > we can consider docker service is MT service in Stratos.
> > above docker cartridges available for application deployment only after
> > docker MT host cluster available in VM mode or generally after
> dynamically
> > registering kuburnetese endpoint.
> > In bare metal we can manually register kurburnetes end point.
> > So in the VM mode, we can have cartridge definition for docker host
> cluster
> > (IMO we can used coreOS+keburnetes) and can deploy as MT service. it can
> > have min, max and auto scaling, deployment polices.
> > With the MT service deployment, it will create docker host cluster. All
> > monitoring and scaling will happen normal way.
> > in MT docker host service up, it will dynamically  register kuburnetes
> > endpoint for docker deployment
> > After end point register, docker application deployment available for all
> > pushed docker cartridges which in the global docker registry.
> > In case of having multiple kuburnetes endpoint user can choose any
> available
> > docker cluster while deployment docker applications. also user can define
> > min max for his docker application while in the creation time and can
> change
> > any time. Also can attached the auto scaling policy
> > communicate to kuburnetes endpoint for orchestrate required dockers.
> > Kuburnetes will take care of rest.
> > update the topology with the member endpoints
> > individual docker application can scale depending on assign auto scaling
> > policy.
> > In the bare-metal mode, without MT mode, we can just register kuburnetes
> end
> > point and then same way to create dockers.
> >
> > This is initial though of design, please share your thought. Need to draw
> > some pictures, will work on that. and IMO we should have a hangout
> session,
> > badly need a white board for these kind of discussions
> >
> > thanks
> >
> >
> > --
> > Lakmal Warusawithana
> > Vice President, Apache Stratos
> > Director - Cloud Architecture; WSO2 Inc.
> > Mobile : +94714289692
> >
> > Blog : http://lakmalsview.blogspot.com/
> >
> >
>



-- 
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/

Reply via email to