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 <nand...@wso2.com>
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 : 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
>
>


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

Reply via email to