Hi Nanduni, It's still not very clear to me, will you be able to draw a diagram to illustrate how message flow works including load balancing (inside CF)?
Thanks On Tue, Feb 23, 2016 at 4:10 AM, Nanduni Nimalsiri <[email protected]> wrote: > Hi, > > I suppose that it works the same for docker apps as it does for buildpack > apps. > When we push a docker image: *cf push docker-app -o > cloudfoundry/diego-docker-app,* this runs a single instance of the > diego-docker-app that's hosted on dockerhub. > > If we keep all of the defaults, this means the container port will be 8080 > unless the docker image specifies another port. Unless we push with > "--no-route" a default route at "diego-docker-app.DEFAULT_DOMAIN" will be > created for the application. > The default domain depends on the installation of cf. We can see this with > the "*cf domains*" command. The diego cell running the container will > advertise the IP:port of this container to the horizontally scalable > routing tier composed of multiple VMs of go router. The routing tier has a > routing table that references diego-docker-app.DEFAULT_DOMAIN to all of the > running containers for this app. > > If I explain what '*Horizontal scaling*' does is creating or destroying > instances of a particular application. Incoming requests to a certain > application are automatically load balanced across all instances of that > application, and each instance handles tasks in parallel with every other > instance. Adding more instances allows that application to handle increased > traffic and demand. > > When we scale up to 2 instances with: "*cf scale docker-app -i 2*", now > diego cells will run 2 instances of this docker image in separate > containers, now the routing table reflects both instances. If one app > instance crashes or is scaled down, diego cells will update the routing > tier with the change immediately. > > Cloud Foundry uses round-robin load balancing to distribute requests > across the running instances of an app. [1] provides a useful guide to use > our own load balancer and forward traffic to Elastic Runtime router IP > address. > > [1] > https://docs.pivotal.io/pivotalcf/customizing/custom-load-balancer.html > > Best regards, > Nanduni. > > > *Nanduni Nimalsiri* > Software Engineering Intern, WSO2 Inc. (http://wso2.com) > email : [email protected] > blog : http://nanduni.blogspot.com/ > mobile : +94714114256 > > > On Sat, Feb 20, 2016 at 11:51 PM, Imesh Gunaratne <[email protected]> wrote: > >> 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 <[email protected]> >> 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 : [email protected] >>> blog : http://nanduni.blogspot.com/ >>> mobile : +94714114256 >>> >>> >>> On Tue, Feb 16, 2016 at 7:20 AM, Lakmal Warusawithana <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 : [email protected] >>>>>> blog : http://nanduni.blogspot.com/ >>>>>> mobile : +94714114256 >>>>>> >>>>>> >>>>>> *Nanduni Nimalsiri* >>>>>> Software Engineering Intern, WSO2 Inc. (http://wso2.com) >>>>>> email : [email protected] >>>>>> blog : http://nanduni.blogspot.com/ >>>>>> mobile : +94714114256 >>>>>> >>>>>> >>>>>> On Tue, Feb 9, 2016 at 12:51 PM, Lakmal Warusawithana < >>>>>> [email protected]> 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 <[email protected] >>>>>>> > 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 : [email protected] >>>>>>>> blog : http://nanduni.blogspot.com/ >>>>>>>> mobile : +94714114256 >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 9, 2016 at 12:01 PM, Chamila De Alwis < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 : [email protected] >>>>>>>>>> blog : http://nanduni.blogspot.com/ >>>>>>>>>> mobile : +94714114256 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Sun, Feb 7, 2016 at 11:49 PM, Malmee Weerasinghe < >>>>>>>>>> [email protected]> 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 <[email protected] >>>>>>>>>>> > 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 : >>>>>>>>>>> <[email protected]>[email protected] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Dev mailing list >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>> [email protected] >>> 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 >> >> > -- *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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
