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