I have an app deployed to Cloudfoundry that I've exposed JMX MBeans interfaces for our logging levels. I'd like to connect to the cloudfoundry instances with jconsole. Is this possible? How do I make this happen? What if I'm running more than 1 instance of Tomcat, how do I connect to a specific instance? or does it matter?
There is currently no way to connect to once specific instance of an application or for that matter any port other than http port via the main Cloud Foundry router.
In the platform we use an app deployed alongside the Login and UAA components (https://github.com/cloudfoundry/identity-tools/tree/master/varz). It gives read-only access to selected MBeans through a CF-like REST interface. It is opinionated about the most important MBeans to expose and may break on complex object graphs, but you can adapt it if you want. You could rip out the controller and use it in your app or do the same as we do in the platform with a standalone app, deploying your own war and the varz in the same container.
Also see Jolokia for a generic JMX REST wrapper.
Related
I have an application deployed to google cloud app engine (flex environment).
The application consists of two parts: FrontEnd (Angular) and BackEnd(Spring boot).
Each one of these applications is deployed to a different service under the same app engine.
Is there any way to apply a firewall rule to the BackEnd service to deny all requests except the ones coming from the FrontEnd service?
Note: I have many services under the same app engine, so I need to apply the rule only to one service so that other services will not be affected.
There is no way to do that currently as the App Engine firewall will affect all your services, dispatch.yaml will not prevent clients from accessing your project using [project_name].appspot.com and adding network in app.yaml settings will only have effect in context of that network.
One workaround could be to set a different project and allowing access there only from another Google Cloud Project. Otherwise you can set checking authentication on the background instances using service accounts.
I have a web app and a web service (which will be uploaded to Azure as an web app). How can i make my web service private (not accessible to the public, only accessible by the web app). Apparently you're able to do it with an App Service Environment but there isn't much documentation on it.
Is it possible?
You can follow this article to set it up: https://azure.microsoft.com/en-us/documentation/articles/app-service-web-how-to-create-an-app-service-environment/
The main difference between App Service and App Service Environment (ASE) is that App Services run on a pre-built, shared tenant hyper scaled web farm, but ASEs are purpose built (on demand) web farms provisioned directly in your subscription that must be attached to a VNET. Because you can attach your ASE to a VNET, you can then apply Network Security Groups (NSG) to the VNET to prevent/allow traffic to flow to the ASE.
Here is the page describing how to add the layered security to your ASE once you've built it:
Layered Security Architecture with App Service Environments
So with ASE you get the deployment/monitoring/management features of App Services, but with the network layer control of a VM.
How can i make my web service private (not accessible to the public, only accessible by the web app).
Network Security Groups could be used to control network traffic rules at the networking level, we could apply Network security group to the subnet to let Network security group act as a firewall in the cloud. #Russell Young has shared us a good article about setting up Network security group, you could read it. And you could check this blog that explained securing network access using Network Security Groups.
Besides, it is easy to implement a custom authentication to prevent unauthenticated client from accessing to your Web service at application layer. For example, we could use SOAP headers for authentication. Web service client credentials would be passed within the SOAP header of the SOAP message when the client want to access to Web service, and then Web service will validate SOAP header, if it contains the authentication credentials, the client will be authorized to access to the Web service.
You could check Implement Custom Authentication Using SOAP Headers.
I know this kind of question is basic concept of bluemix but, I just worder if I develop an application on public bluemix using certain runtime, such as Node.js or Liberty, can this application run on my own Local server or AWS?
Is it depends on bluemix-provided services that I bind to application?
or If I install cloudfoundry on my local server or AWS cloud host, can the application run without any problem or issue?
thank you
You can try out Lattice. It will allow you to run your own local or AWS hosted minimal cloudfoundry runtime. This will allow you to run your applications. If the services you are talking to are publicly accessible ie. Have a publicly routable host and port, then you can expose them as environment variables in your CF app manifest and reach out to them from your own CF or you could look at user provided services. You will need to upload buildpacks to your lattice/cf installation that are not a part of the standard installation.
DISCLAIMER: Lattice is useful during development and NOT recommended for production use. You should setup the entire cloudfoundry for that.
I am trying to create a clustered cache service for Cloud Foundry. I understand that I need to implement Service Broker API. However, I want this service to be clustered, and in the Cloud Foundry environment. As you know, container to container connection (TCP) is not supported yet, I don't want to host my backend in another environment.
Basically my question is almost same as this one: http://grokbase.com/t/cloudfoundry.org/vcap-dev/142mvn6y2f/distributed-caches-how-to-make-it-work-multicast
And I am trying to achieve this solution he adviced:
B) is to create a CF Service by implementing the Service Broker API as
some of the examples show at the bottom of this doc page [1] .
services have no inherant network restrictions. so you could have a CF
Caching Service that uses multicast in the cluster, then you would
have local cache clients on your apps that could connect to this
cluster using outbound protocols like TCP.
First of all, where does this service live? In the DEA? Will backend implementation be in the broker itself? How can I implement the backend for scaling the cluster, start the same service broker over again?
Second and another really important question is, how do the other services work if TCP connection is not allowed for apps? For example, how does a MySQL service communicates with the app?
There are a few different ways to solve this, the more robust the solution, the more complicated.
The simplest solution is to have a fixed number of backend cache servers, each with their own distinct route, and let your client applications implement (HTTP) multicast to these routes at the application layer. If you want the backend cache servers to run as CF applications, then for now, all solutions will require something to perform the HTTP multicast logic at the application layer.
The next step would be to introduce an intermediate service broker, so that your client apps can all just bind to the one service to get the list of routes of the backend cache servers. So you would deploy the backends, then deploy your service broker API instances with the knowledge of the backends, and then when client apps bind they will get this information in the user-provided service metadata.
What happens when you want to scale the backends up or down? You can then get more sophisticated, where the backends are basically registering themselves with some sort of central metadata/config/discovery service, and your client apps bind to this service and can periodically query it for live updates of the cache server list.
You could alternatively move the multicast logic into a single (clustered) service, so:
backend caches register with the config/metadata/discovery service
multicaster periodically queries the discovery service for list of cache server routes
client apps make requests to the multicaster service
One difficulty is in implementing the metadata service if you're doing it yourself. If you want it clustered, you need to implement a highly-available-ish consistent-ish datastore, it's almost the original problem you're solving except the service handles replicating data to all nodes in the cluster, so you don't have to multicast.
You can look at https://github.com/cloudfoundry-samples/github-service-broker-ruby for an example service broker that runs as a CF application.
I'm planning to deploy geronimo based java app on CloudFoundry. I read the documentation that CloudFoundry assigns a port per application. Geronimo app have port numbers for app, admin and jmx monitoring.
is there any way we can request cloudfoundry to assign more than one port to each application and we can use these ports in different config in the codebase?
First just fyi, if you are deploying the app as a Java web app, CloudFoundry in the backend uses only Tomcat as the application server. Therefore for your case you need to deploy it as a standalone app with your own Geronimo runtime. http://blog.cloudfoundry.com/2012/05/11/running-standalone-web-applications-on-cloud-foundry/
CF apps get one IP and one port each, accessible via environment variables VCAP_APP_HOST and VCAP_APP_PORT. There isnt a way to assign explicitly. Ports an app listens to other than the port assigned will not be accessible through CF router.
If you are interested, my suggestion would be deploying multiple apps for each port(Geronimo function) you want to listen to. This would give you URL-based app, admin or jmx monitoring.