Re: [Dev] Running WSO2 Products on Cloud Foundry

[Imesh Gunaratne]

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  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 : nand...@wso2.com
> blog : http://nanduni.blogspot.com/
> mobile : +94714114256
>
>
> On Sat, Feb 20, 2016 at 11:51 PM, Imesh Gunaratne  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 
>> 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 : +947141142

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Nanduni Nimalsiri]

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 : nand...@wso2.com
blog : http://nanduni.blogspot.com/
mobile : +94714114256


On Sat, Feb 20, 2016 at 11:51 PM, Imesh Gunaratne  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 
> 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 
>> 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 
>>> wrote:
>>>
 Awesome! great progress Nanduni.

 I

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Imesh Gunaratne]

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 
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 
> 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 
>> 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 
>>> 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 s

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Nanduni Nimalsiri]

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

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Lakmal Warusawithana]

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

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Lakmal Warusawithana]

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 
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 suppo

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Chamila De Alwis]

Hi Nanduni,

I suppose the need for an external Docker host is for the build-pack to
build the Docker images somehow, although it would be better to mention the
source of this information. Can you elaborate more why build-packs give
more control to ops and have low maintenance cost?

The Docker images for WSO2 products in Kubernetes Artifacts repository are
not private images. Rather, the repository contains the Dockerfiles that
can be used to build the images locally [1] and then uploaded to Docker Hub
or a private Docker registry. I guess a good option will be to build these
images and upload them to a personal Docker Hub account, for test purposes,
as it is better to verify open Docker registry work flow, before figuring
out the details on private Docker registry, as Lakmal mentions above.

Can you further elaborate how health checks happen in Diego and why some
Docker images cannot be run because of it?

Great work so far! :)

[1] -
http://code.chamiladealwis.com/blog/2016/02/09/running-wso2-products-on-kubernetes/



Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Mon, Feb 15, 2016 at 11:25 PM, Nanduni Nimalsiri 
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*,
>   

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Nanduni Nimalsiri]

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 
wrote:

> Initial stage, don't worry about to use public

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Lakmal Warusawithana]

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  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 
> 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 
>> 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 
>>> 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 
 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. 

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Chamila De Alwis]

Hi Nanduni,

If we can use the Docker images in CF (Diego), then we will be able to
reuse the existing Dockerfiles in WSO2 Kubernetes Artifacts repository [1].
It will just be the matter of modifying the Heroku (or any other) Docker
build pack to use a private Docker registry.

On Tue, Feb 9, 2016 at 12:43 PM, Nanduni Nimalsiri  wrote:

> 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.
>

When the Docker daemon connects to a private Docker registry, it will
record the token in the config file ~/.dockercfg. Is there any possibility
to provide this configuration to BOSH so that it will not prompt for the
authentication during runtime?

[1] - https://github.com/wso2/kubernetes-artifacts


Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Nanduni Nimalsiri]

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  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 
> 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 
>> 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  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/kubernet

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Gayan Gunarathne]

On Tue, Feb 9, 2016 at 12:01 PM, Chamila De Alwis  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?
>

Default that uses Warden for its container management. We can try with
heroka buildpack[1] to run the docker images.

[1] https://blog.docker.com/2013/05/heroku-buildpacks-on-docker/
[2] https://devcenter.heroku.com/articles/docker


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


-- 

Gayan Gunarathne
Technical Lead, WSO2 Inc. (http://wso2.com)
Committer & PMC Member, Apache Stratos
email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Chamila De Alwis]

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

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Gayan Gunarathne]

On Tue, Feb 9, 2016 at 9:55 AM, Malmee Weerasinghe  wrote:

> Hi All,
> As an initiative for the $subject I have deployed Cloud Foundry with BOSH
> Lite, have run some sample applications both in BOSH lite and Pivotal Cloud
> Foundry.
>
> BOSH Lite is a pre-built Vagrant box which includes the BOSH Director. BOSH
> Lite is used for developing and testing releases locally.
>
> Cloud Foundry is now owned by Pivotal software and Pivotal Cloud Foundry
> is a commercial implementation.
>
> I have written two blog posts as an introduction to Cloud Foundry [1] and
> Bosh and Bosh Lite in Cloud Foundry [2].
>
> As an approach to the $subject I am deploying tomcat server in Cloud
> Foundry and am expecting to replace the deployment with a WSO2 product
> (docker).
>

How do you going to deploy the server in Cloud foundry? Did you use
Buildpack? Also Did you check with Diego in the case of docker?

>
> Your suggestions on this subject are highly appreciated.
>
> [1]
> http://malmeeweerasinghe.blogspot.com/2016/02/introduction-to-cloud-foundry.html
> 
> [2]
> http://malmeeweerasinghe.blogspot.com/2016/02/bosh-and-bosh-lite-in-cloud-foundry.html
>
> Thanks
>
> --
> Malmee Weerasinghe
> WSO2 Intern
> mobile : (+94)* 71 7601905* |   email :   
> mal...@wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

Gayan Gunarathne
Technical Lead, WSO2 Inc. (http://wso2.com)
Committer & PMC Member, Apache Stratos
email : gay...@wso2.com  | mobile : +94 775030545 <%2B94%20766819985>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Nanduni Nimalsiri]

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

Re: [Dev] Running WSO2 Products on Cloud Foundry

[Malmee Weerasinghe]

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