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/ > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
