Hi Nanduni, Were you able to figure out how load balancing works on CF with Docker?
Thanks On Tue, Feb 16, 2016 at 12:23 PM, Nanduni Nimalsiri <nand...@wso2.com> wrote: > *@Lakmal* > Thank you for the information. I will try using that. > > *@Chamila* > Thank you for the details. > It seems that the choice of buildpacks or containers depends on the > application developer, operator, environment, requirements etc. If we > really want to get something really fast, Cloud Foundry recommends to build > a docker container and push it, so that we can use that container for local > testing as well. But the drawback that lies here is that the developers > have to know about Docker and other operations. (eg: how to write a > Dockerfile). They say that if the developer needs to set up the environment > instead of the operator, this approach would be perfect. > > Cloud Foundry suggests that buildpacks are suitable if we don't want to > use Ubuntu, Red Hat, Fedora, CentOS or different java versions that need to > be patched differently or else if we don't want to use different custom > things etc. Hence the developer can focus more on application logic and > business logic rather than running Dockerfiles. Any way, the buildpack > approach also ends up in a container(droplet) eventually. > > I suppose that low maintenance cost can be achieved with buildpacks > because this approach does not end up with very heterogenic container > cluster where every container is really different, then we have to come up > with different ways when we need to patch something. But with buildpacks, > we can patch up one buildpack so that we can deploy all applications and go > ahead. I suppose this might be a reason for mentioning it as low > maintenance cost. I have no deep thought on this. > > In case of port based health checks which I have mentioned, if the Docker > images we are pushing don't declare ports to expose, or the processes they > run don't listen for TCP connections on the ports they expose, then they > will fail the default 'port' health check when pushed as a CF app. If we > turn that port-based health-check off by changing it to 'none', though, the > image may run successfully. > > Hope this had been useful. > > Best regards, > Nanduni. > > > *Nanduni Nimalsiri* > Software Engineering Intern, WSO2 Inc. (http://wso2.com) > email : nand...@wso2.com > blog : http://nanduni.blogspot.com/ > mobile : +94714114256 > > > On Tue, Feb 16, 2016 at 7:20 AM, Lakmal Warusawithana <lak...@wso2.com> > wrote: > >> PS: Still private docker registry UI not configured. Currently this only >> work in docker client, using docker registry APIs. Which is docker >> login/push/pull >> >> On Tue, Feb 16, 2016 at 7:16 AM, Lakmal Warusawithana <lak...@wso2.com> >> wrote: >> >>> Awesome! great progress Nanduni. >>> >>> If you want to test with private docker registry, I have setup internal >>> private docker registry [1], you can use it for push/pull docker images. It >>> required authentication ( your WSO2 credentials - username : email, >>> Password: email password ). You need to do docker login first to pull/push >>> docker images. (please note currently this is only work inside the WSO2 >>> network) >>> >>> Lets try CF locally. >>> >>> >>> [1] https://dockerhub.private.wso2.com >>> >>> >>> On Mon, Feb 15, 2016 at 11:25 PM, Nanduni Nimalsiri <nand...@wso2.com> >>> wrote: >>> >>>> Hi, >>>> >>>> I was able to deploy Docker images in Cloud Foundry with Diego. Here I >>>> am going to clear several facts regarding that. >>>> >>>> There are several approaches of integrating Docker with Cloud Foundry. >>>> If I summarize them, they are are follows. Each of them possesses different >>>> limitations. >>>> >>>> >>>> *Integrating Docker with Cloud Foundry* >>>> >>>> *1. Docker Buildpack - *Provides framework and runtime support for the >>>> applications. When we push an application, Cloud Foundry automatically >>>> detects which buildpack is required and installs it on the Droplet >>>> Execution Agent (DEA) where the application needs to run. >>>> >>>> *2. Docker Service Provider - * A service provider to expose Docker >>>> containers as services. >>>> >>>> *3. Cloud Rocker *- A project carried out by a company called 'Cloud >>>> Credo' which builds docker images using Cloud Foundry buildpacks. If you >>>> don't want to use Cloud Foundry but you want to use its buildpack system, >>>> this is the best choice. >>>> >>>> *4. Diego - *Rewrite of DEA. In a Cloud Foundry deployment without >>>> Diego, the Cloud Controller schedules and manages applications on the DEA >>>> nodes. Diego replaces the DEAs and the Health Manager, and assumes >>>> application scheduling and management responsibility from the Cloud >>>> Controller. Diego is special because it provides built-in-support for >>>> Docker containers. >>>> >>>> *5. Lattice - *Lattice is a standalone scheduler extracted from Diego >>>> for Docker images. If Cloud Foundry is too much, Lattice might be a >>>> suitable project. Lattice tries to be little simpler and easier to set up >>>> with less features around it. The nice thing about this Lattice system is >>>> that it is super light weight. >>>> >>>> Out of the aforementioned approaches, I used 4th option - Diego in >>>> Cloud Foundry. As mentiond above, Diego builds out the new runtime >>>> architecture for Cloud Foundry, replacing the DEAs and Health Manager. In >>>> fact, *Cloud Foundry now encourages the use of Diego.* >>>> >>>> *Using Diego with Cloud Foundry* >>>> >>>> First I tried to use Diego with PWS (Pivotal Web Services). Then it >>>> gave me errors in enabling Diego feature due to conflicts in administrator >>>> privileges. In that case, I have been running the 60 days trial version of >>>> Pivotal.io and that's why I had no administrator control because PWS is a >>>> shared platform. >>>> >>>> So the next option was to run Diego locally in my machine so that I can >>>> then get admin control and do whatever I want with the system. So I used* >>>> Cloud >>>> Foundry Diego [BOSH release] *in [1] for that. With several >>>> modifications, I managed to deploy Docker containers eventually. Here are >>>> the steps I followed. >>>> >>>> 1. Uploaded the latest version of the Warden BOSH-Lite stemcell >>>> directly to BOSH-Lite >>>> 2. Used two releases to generate two manifests basically. They are >>>> cf-relaese and diego-release. >>>> 3. Generated CF manifest and Diego manifest. >>>> 4. Created, uploaded, and deployed the CF release. >>>> 5. Uploaded the latest garden-linux-release. >>>> 6. Uploaded the latest etcd-release. >>>> 7. Created, uploaded, and deployed the Diego release >>>> 8. Logged in to CF and enabled Docker support. >>>> 9. Deployed cloudfoundry/lattice-app docker image. >>>> 10. Scaled the number of instances and so on... >>>> >>>> [1] https://github.com/cloudfoundry-incubator/diego-release >>>> >>>> >>>> *Containers vs Buildpacks* >>>> >>>> If I move to the Docker buildpacks, I could not find any buildpack >>>> compatible for deploying Docker images yet. I am trying on it, but the >>>> problem seems that they require some external Docker host which I have no >>>> idea on how to set up. >>>> >>>> Meanwhile, I found several pros and cons with these two approaches: >>>> Buildpack mechanism and Container mechanism. I have summarized them as >>>> below. >>>> >>>> *Containers are better when*, >>>> - Developers require more control >>>> - Developers know Operations/Docker >>>> - Time to market is important >>>> >>>> *Buildpacks are better when*, >>>> - Operations require more control >>>> - Developers focus on application >>>> - Low maintenance cost is important >>>> >>>> Since we already have Docker images for WSO2 products (k8s artifacts) , >>>> I suggest that we can use Diego for deploying WSO2 products in Cloud >>>> Foundry. But the problem seems that they are private images and still I >>>> have no idea on how we should proceed with docker images that are not >>>> available in Docker Hub. I suppose that there is some mechanism with >>>> 'Private Docker Registry' in Diego. Meanwhile there are some other >>>> limitations of this approach such as port based health check etc. which >>>> blocks deploying some Docker images. >>>> >>>> Please add your comments on this. >>>> >>>> Best regards, >>>> Nanduni. >>>> >>>> *Nanduni Nimalsiri* >>>> Software Engineering Intern, WSO2 Inc. (http://wso2.com) >>>> email : nand...@wso2.com >>>> blog : http://nanduni.blogspot.com/ >>>> mobile : +94714114256 >>>> >>>> >>>> *Nanduni Nimalsiri* >>>> Software Engineering Intern, WSO2 Inc. (http://wso2.com) >>>> email : nand...@wso2.com >>>> blog : http://nanduni.blogspot.com/ >>>> mobile : +94714114256 >>>> >>>> >>>> On Tue, Feb 9, 2016 at 12:51 PM, Lakmal Warusawithana <lak...@wso2.com> >>>> wrote: >>>> >>>>> Initial stage, don't worry about to use public docker hub images. If >>>>> it working with docker hub, we can make it to work with private docker >>>>> registry >>>>> >>>>> On Tue, Feb 9, 2016 at 12:43 PM, Nanduni Nimalsiri <nand...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Chamila, >>>>>> >>>>>> Yes we can use custom buildpacks to deploy on Cloud Foundry. I am not >>>>>> familiar with all WSO2 products, but I suppose that we need to run shell >>>>>> files in most cases. So we can customize or build our own buildpack to >>>>>> detect those files. >>>>>> >>>>>> Diego is a separate approach. It is a new run time that replaces DEA >>>>>> in Cloud Foundry. With Diego, we can use Docker images to push >>>>>> applications >>>>>> to Cloud Foundry, But there are some limitations. We need the images to >>>>>> be >>>>>> available in Docker Hub publicly. But I found that there's something new >>>>>> called 'Private Docker Registry' in Diego that enables to use private >>>>>> Docker images where users are prompted for credentials during staging the >>>>>> app. I was unable to run Diego as it requires administrator privileges to >>>>>> enable docker support for me. >>>>>> >>>>>> Also there is a cf-docker buildpack that detects Docker images. It >>>>>> also has the above mentioned limitations. I am not sure if we can >>>>>> customize >>>>>> that buildpack to detect private images as well. They say that it is >>>>>> just a >>>>>> proof of concept. >>>>>> >>>>>> I have tried to get help from cf-dev mailing lists as well. They >>>>>> suggest that I need to have administrator privileges to resolve above >>>>>> scenarios. >>>>>> >>>>>> Best Regards, >>>>>> Nanduni >>>>>> >>>>>> >>>>>> >>>>>> *Nanduni Nimalsiri* >>>>>> Software Engineering Intern, WSO2 Inc. (http://wso2.com) >>>>>> email : nand...@wso2.com >>>>>> blog : http://nanduni.blogspot.com/ >>>>>> mobile : +94714114256 >>>>>> >>>>>> >>>>>> On Tue, Feb 9, 2016 at 12:01 PM, Chamila De Alwis <chami...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Nanduni, >>>>>>> >>>>>>> Wouldn't writing a custom buildpack (for each product) [1] allow us >>>>>>> to deploy a given artifact on CloudFoundry? We'd have to write the >>>>>>> detect, >>>>>>> compile, and release scripts separately. >>>>>>> >>>>>>> Is there any difference between that approach and using Docker >>>>>>> images? >>>>>>> >>>>>>> [1] - https://docs.cloudfoundry.org/buildpacks/custom.html >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Chamila de Alwis >>>>>>> Committer and PMC Member - Apache Stratos >>>>>>> Software Engineer | WSO2 | +94772207163 >>>>>>> Blog: code.chamiladealwis.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 8, 2016 at 9:00 AM, Nanduni Nimalsiri <nand...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> By now, I have managed to deploy applications in Cloud Foundry via, >>>>>>>> 1. bosh-lite ( a vagrant VM that comes with pre-installed BOSH >>>>>>>> server or Director) >>>>>>>> 2. Hosted solutions such as Pivotal web services (pivotal.io) >>>>>>>> >>>>>>>> I deployed Tomcat server in Cloud Foundry as well. But I was not >>>>>>>> able to deploy Docker in Cloud Foundry via Diego. It gives me some >>>>>>>> errors >>>>>>>> regarding admin permissions. >>>>>>>> I found that there are Heroku buildpacks on Docker and they are >>>>>>>> perfectly compatible with Cloud Foundry too. >>>>>>>> >>>>>>>> [1] https://github.com/duglin/cf-docker >>>>>>>> [1] is another buildpack that supports Docker, but there are >>>>>>>> several limitations as this buildpack requires that you have a Docker >>>>>>>> host >>>>>>>> available for it to access, and you need to also have a Docker >>>>>>>> container >>>>>>>> manager app (cf-docker) running that will sync the Cloud Foundry >>>>>>>> runtime >>>>>>>> with the Docker containers. >>>>>>>> >>>>>>>> My blog in the following link will be useful for any one to get an >>>>>>>> idea on deploying applications in Cloud Foundry. >>>>>>>> http://nanduni.blogspot.com/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Nanduni. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Nanduni Nimalsiri* >>>>>>>> Software Engineering Intern, WSO2 Inc. (http://wso2.com) >>>>>>>> email : nand...@wso2.com >>>>>>>> blog : http://nanduni.blogspot.com/ >>>>>>>> mobile : +94714114256 >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Feb 7, 2016 at 11:49 PM, Malmee Weerasinghe < >>>>>>>> mal...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi Imesh, >>>>>>>>> >>>>>>>>> I have done a background research on Cloud Foundry and the blog >>>>>>>>> under the following link contains the documentation of the research. >>>>>>>>> I will >>>>>>>>> include more posts on deploying Cloud Foundry with bosh lite and >>>>>>>>> running >>>>>>>>> simple applications on it, as I have studied so far. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://malmeeweerasinghe.blogspot.com/2016/02/introduction-to-cloud-foundry.html >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> On Fri, Feb 5, 2016 at 10:31 PM, Imesh Gunaratne <im...@wso2.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Shall we summarize the research work we have done so far and our >>>>>>>>>> approach towards $subject? >>>>>>>>>> >>>>>>>>>> I know some of us have already done below, it might be better to >>>>>>>>>> document this: >>>>>>>>>> >>>>>>>>>> - PaaS features of CF >>>>>>>>>> - Steps for setting up a local environment with Vagrant >>>>>>>>>> - Running a hello world sample >>>>>>>>>> - Running a JVM using a standalone framework >>>>>>>>>> >>>>>>>>>> Next we might need to check following: >>>>>>>>>> >>>>>>>>>> 1. The ability to use Docker on CF >>>>>>>>>> 2. The process of creating and managing Warden container images >>>>>>>>>> 3. Find a mechanism to discover the member list of a cluster and >>>>>>>>>> implement a Carbon membership scheme >>>>>>>>>> 4. Create standalone frameworks for Carbon products >>>>>>>>>> 5. Find a way to apply patches and software updates >>>>>>>>>> 6. Find a way to implement a centralized logging solution >>>>>>>>>> 7. Check whether there is a way to monitor the health of the >>>>>>>>>> containers (similar to cAdvisor and Cockpit UI in Kubernetes) >>>>>>>>>> 8. Create artifacts required for deploying a Carbon server on CF >>>>>>>>>> and prepare a guideline. >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://github.com/wso2/kubernetes-artifacts/tree/master/common/kubernetes-membership-scheme >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Imesh Gunaratne* >>>>>>>>>> Senior Technical Lead >>>>>>>>>> WSO2 Inc: http://wso2.com >>>>>>>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>>>>>>> W: http://imesh.io >>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Malmee Weerasinghe >>>>>>>>> WSO2 Intern >>>>>>>>> mobile : (+94)* 71 7601905* | email : >>>>>>>>> <dehan.vith...@aiesec.net>mal...@wso2.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Lakmal Warusawithana >>>>> Director - Cloud Architecture; WSO2 Inc. >>>>> Mobile : +94714289692 >>>>> Blog : http://lakmalsview.blogspot.com/ >>>>> >>>>> >>>> >>> >>> >>> -- >>> Lakmal Warusawithana >>> Director - Cloud Architecture; WSO2 Inc. >>> Mobile : +94714289692 >>> Blog : http://lakmalsview.blogspot.com/ >>> >>> >> >> >> -- >> Lakmal Warusawithana >> Director - Cloud Architecture; WSO2 Inc. >> Mobile : +94714289692 >> Blog : http://lakmalsview.blogspot.com/ >> >> > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Imesh Gunaratne* Senior Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.io Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
