*@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
