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
