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? > 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/ > >
