Implementing a Service Broker spawning processes

[shol...@gmail.com]

Hello,
I want to create a service broker which starts separate Java application on every create-service request and have few questions.
As far as I understand there is nothing special with it - I just have to place my JAR files somewhere and run the service instance process. Is it correct?
Is there any special path on a local file system where should I install service instance files?

How is service broker supposed to handle full CloudFoundry restarts? E.g. electricity broken, maintenance restart etc. One possible way I see is looking through all created service instances during service broker initialization an re-spawning processes. Is it a good way to handle this case?

There is one more question which is a bit more theoretical than practical. As far as I understand it is possible to deploy CloudFoundry on a cluster where user applications may be deployed to different hosts. The same is for service instances. How would you implement a service broker which can distribute service instances it creates over all available nodes? Is it even possible?

[shol...@gmail.com]

Can anyone help me?

[jvhi...@gmail.com]

Hi,

>As far as I understand there is nothing special with it - I just have to place my JAR files somewhere and run the service instance process. Is it correct? 

So you want to place your Jar file CF or in a different context? In general you may just write a Broker, which then executes anything. What the broker does, depends on you. 

>How is service broker supposed to handle full CloudFoundry restarts?

This depends on your deployment. You have two different options for deploying your broker. The first is as a separate machine, the second as a user provided service broker running in the CF context. For the first scenario you should use something IaaS specific like HA etc. For the second kind, the service broker would be a normal user provided application. Restarts through service interruption of any kind are handled the same way they are handled for your apps.

>How would you implement a service broker which can distribute service instances it creates over all available nodes? Is it even possible?

I am not sure if I understand this question correctly. Could you give some more information here?

On Monday, July 14, 2014 5:12:19 AM UTC+2, shol...@gmail.com wrote:

Can anyone help me?

[shol...@gmail.com]

Thanks for your response!

> So you want to place your Jar file CF or in a different context? In general you may just write a Broker, which then executes anything. What the broker does, depends on you.

Here I incorrectly expressed my thoughts, sorry. Yes, I want to implement service broker which for every create-service request installs (just copies the JAR, I think) small java application somewhere, starts is in separate process, and then binds it to any client application. The client application interacts with service instance via HTTP. As far as I understand the idea is totally correct :)

> This depends on your deployment. You have two different options for deploying your broker. The first is as a separate machine, the second as a user provided service broker running in the CF context. For the first scenario you should use something IaaS specific like HA etc. For the second kind, the service broker would be a normal user provided application. Restarts through service interruption of any kind are handled the same way they are handled for your apps.

I see now. So, if I install the broker as CF application, it will be started automatically, which is good! But what about service instance processes it runs? Is there any way to deploy CF applications from Service Broker, so they would be restarted automatically as well?

> I am not sure if I understand this question correctly. Could you give some more information here?

Sure. I was thinking about the situation when CloudFoundry is getting scaled, e.g. for adding new nodes to run user-provided applications. But a service broker will only be able to run service instance applications only on a node where the broker installed. My understanding of this process is most likely not correct, but what I think is that the service broker must be able to distribute services over all available nodes. How can this be achieved?

понедельник, 14 июля 2014 г., 16:26:12 UTC+7 пользователь jvhi...@gmail.com написал:

[Daniel Mikusa]

On Mon, Jul 14, 2014 at 7:48 AM, <shol...@gmail.com> wrote:

Thanks for your response!
> So you want to place your Jar file CF or in a different context? In general you may just write a Broker, which then executes anything. What the broker does, depends on you.
Here I incorrectly expressed my thoughts, sorry. Yes, I want to implement service broker which for every create-service request installs (just copies the JAR, I think) small java application somewhere, starts is in separate process, and then binds it to any client application. The client application interacts with service instance via HTTP. As far as I understand the idea is totally correct :)

This is a bit off topic, but what's the rationale for starting multiple instances of the application?  Since it's a web app, could you just run the app once with multiple users?  

The advantages I would see doing this...

  - You could still create a broker, but instead of starting / managing processes it would just need to create a user account, which could be as easy as hitting a rest end point on your app or updating a DB.

  - You can manage the service app with cf, push and scale it as needed for all of your users.

  - Better reliability, since you don't need to worry about user x's application instance dying.  

 

> This depends on your deployment. You have two different options for deploying your broker. The first is as a separate machine, the second as a user provided service broker running in the CF context. For the first scenario you should use something IaaS specific like HA etc. For the second kind, the service broker would be a normal user provided application. Restarts through service interruption of any kind are handled the same way they are handled for your apps.
I see now. So, if I install the broker as CF application, it will be started automatically, which is good! But what about service instance processes it runs? Is there any way to deploy CF applications from Service Broker, so they would be restarted automatically as well?

You can push apps to CF in your code.  The CF Java Client [1] makes this easier or you can use the REST api [2] directly.

Dan

[1] - https://github.com/cloudfoundry/cf-java-client

[2] - http://apidocs.cloudfoundry.org/

 

> I am not sure if I understand this question correctly. Could you give some more information here?
Sure. I was thinking about the situation when CloudFoundry is getting scaled, e.g. for adding new nodes to run user-provided applications. But a service broker will only be able to run service instance applications only on a node where the broker installed. My understanding of this process is most likely not correct, but what I think is that the service broker must be able to distribute services over all available nodes. How can this be achieved?

понедельник, 14 июля 2014 г., 16:26:12 UTC+7 пользователь jvhi...@gmail.com написал:

Hi,

>As far as I understand there is nothing special with it - I just have to place my JAR files somewhere and run the service instance process. Is it correct? 

So you want to place your Jar file CF or in a different context? In general you may just write a Broker, which then executes anything. What the broker does, depends on you. 

>How is service broker supposed to handle full CloudFoundry restarts?

This depends on your deployment. You have two different options for deploying your broker. The first is as a separate machine, the second as a user provided service broker running in the CF context. For the first scenario you should use something IaaS specific like HA etc. For the second kind, the service broker would be a normal user provided application. Restarts through service interruption of any kind are handled the same way they are handled for your apps.

>How would you implement a service broker which can distribute service instances it creates over all available nodes? Is it even possible?

I am not sure if I understand this question correctly. Could you give some more information here?

On Monday, July 14, 2014 5:12:19 AM UTC+2, shol...@gmail.com wrote:

Can anyone help me?

--
You received this message because you are subscribed to the Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/5ef61cbb-60aa-4f62-b945-4b44a2954e1a%40cloudfoundry.org.

To unsubscribe from this group and stop receiving emails from it, send an email to vcap-dev+u...@cloudfoundry.org.

[shol...@gmail.com]

Thanks for response, Daniel.

> This is a bit off topic, but what's the rationale for starting multiple instances of the application? Since it's a web app, could you just run the app once with multiple users?

The service instances are supposed to store sensitive data for applications, encrypted. Like passwords, API tokens etc. I believe that having multiple independent databases is more safe, however I'm probably a bit of paranoid here :)

>  - You could still create a broker, but instead of starting / managing processes it would just need to create a user account, which could be as easy as hitting a rest end point on your app or updating a DB.

Do you mean that the service broker itself may serve service requests? E.g. instead of starting new app, it just creates new internal account and then client applications communicate directly to the broker (though they think it is a separate service app).

>  - You can manage the service app with cf, push and scale it as needed for all of your users.

Could you please add details here? I thought it is not possible to scale service brokers...

> You can push apps to CF in your code.  The CF Java Client [1] makes this easier or you can use the REST api [2] directly.

This is very nice! But it means that I have to keep my CloudFoundry credentials (or maybe credentials of a special account for this service) in the service broker app, right? I mean, that service brokers does not receive any special permissions to deploy new apps without authentication.

[Johannes Hiemer]

Hi,

>The service instances are supposed to store sensitive data for applications, encrypted. Like passwords, API tokens etc. I believe that having multiple independent databases is more safe, however I'm probably a bit >of paranoid here :)

You should not be, if you try to keep your stuff safe. Let's face reality. Every endpoint of a service broker (e.g. Postgres, MongoDB, RabbitMQ...etc.) stores sensitive information like username/password combinations or tokens. Do they have multiple databases? No! Why? Because keeping one database for credentials safe is an easier task to maintain, then keep track of x database. 

>Do you mean that the service broker itself may serve service requests? E.g. instead of starting new app, it just creates new internal account and then client applications communicate directly to the broker (though >they think it is a separate service app).

I think what Daniel means, is that you should have one backend for your system. This means, this backend for your system is multi-tenant enabled with dedicated user accounts for each one who registered the usage of the service through the service broker.

>Could you please add details here? I thought it is not possible to scale service brokers...

Just upload the service broker as a war/ruby whatever application and do a 'cf scale' afterwards. That's all!

>This is very nice! But it means that I have to keep my CloudFoundry credentials (or maybe credentials of a special account for this service) in the service broker app, right? I mean, that service brokers does not >receive any special permissions to deploy new apps without authentication

This is done in every service broker. Just think through the process of creating a database (service instance) in PostgreSQL. The broker needs to be aware of three important information: endpoint URL of the service it should connect to and the according username and password. In nearly _all_ cases this username/password combination needs to reflect the rights of a privileged user, which is allowed to create databases and users itself. SO this is no uncommon scenario.

[shol...@gmail.com]

Thank you, Johannes, Daniel! I think I now better understand how should my service broker work.

вторник, 15 июля 2014 г., 12:38:45 UTC+7 пользователь Johannes Hiemer написал: