In the docker scenario, we can have either docker image name or docker file in the cartridge definition, if docker file provided, we should build and push to docker registry and if docker image name provided, can assume, docker image manually build and already in the docker registry. Main reason, some cases, we may not have internet access for build docker images dynamically.
On Thu, Aug 28, 2014 at 10:18 PM, Lakmal Warusawithana <lak...@wso2.com> wrote: > > > > 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/ > > -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
