My customer has 2 Windows Server 2019.
On both of them, an instance of a SOAP Web Service is running.
URLs:
https://host1.domainname.com/SOAPService
and
https://host2.domainname.com/SOAPService
Now, the requirement of the customer is to provide a single, unique URL that the clients can use to consume the SOAP WebService(s).
I read through several websites and if I got it right, I need a tool that is called "reserve proxy"... Using this tool, clients can access the webservice by using an URL such as https://host.domainname.com/SOAPService and the tool will automatically route the request to the available webservice.
Correct?
I also have an architectural question:
On which machine do I have to run such a Reserve Proxy?
Is it on host1 or host2 or do I need a dedicated machine (like a supervisor)?
If it is a dediciated machine, how can I apply high availability of this Reverse Proxy? E.g. is it possible to run 2 Reserve Proxies in parallel on different machines? Which tool could afford this?
Thanks
I'm currently deploying on cloud foundry, Now I have a frontend server and a backend server.
Both deployed as micro services with the Cloud Foundry nodejs build pack.
I would like to hide the backend server from the outside world, that only my frontend server can access it. How do I do that?
If I remove the route to the backend server the server is hidden from the outside but then I do not know how to access it from my frontend.
I'm new to Cloud Foundry maybe there is an easy way.
Thanks
Andreas
Thanks for the information so far.
I do however not understand how I could now hide my backend instance from being accessed from the outside, but allow for access of the frontrontend?
Basically what roule would I need to set in my space in order to allow only port 80 to be accessed of my frontend instance (lets say the frontend ip is 168.192.0.5).
could you make an example?
If you are using OSS Cloud Foundry, you can put the backend services into their own space, and then set the security group rules for that space so that they will not respond to outside IP addresses:
https://docs.pivotal.io/pivotalcf/adminguide/app-sec-groups.html
If you are using Pivotal Cloud Foundry, you can use Spring Cloud Service Discovery, as Amit said.
What about using "cf push myjavaapp --no-route"?
The no-route option tell Bluemix that your backend is not a web application.
Another solution to hide the back-end microservice from the public is to use containers (also available on Bluemix, based on Docker, see https://www.ng.bluemix.net/docs/containers/container_gettingstarted.html). Containers have a private IP by default and can access other containers in the same space. You can assign the front-end microservice a public IP using e.g. following command
cf ic ip bind {public_ip} {container_name}
but don't assign a public address to your back-end microservices.
(A few weeks ago I've created a simple example for a microservice in a container, you can find the code at
https://hub.jazz.net/project/matthiashub/bluemix-unistuttgart-container/overview I admit that this was done in Java and not in nodejs but I think you get the idea.)
I have deployed some proxy services in WSO2 ESB because I have to ask the endpoint for several responses (dataset), according to different soap action. Every response must be set in a file, so I set an appropriate sequence in the outSequence of the proxy service, and this sequence writes the soap answer into a file.
In this way i have to deploy a proxy service and a sequence for EVERY soapAction, so i ask: is there a way for deploying a single proxy service for a given web service and using it with several sequences according to the soapaction to perform?
My question was born by the need to implement several scheduled tasks that take a dataset from an endpoint (webService) and write it into a file, but i don't want to deploy so much proxy service for every kind of dataset I have to request to the web service!
I hope my question is clear.
You do not necessarily create a diffrent proxies for each and every soapAction. You can utilize the filter mediator in the OutSequence of single proxy and do the header base routing to relevant VFS endpoint.
After watching the BUILD conference videos for Azure Service Fabric, I'm left imagining how this might be a good fit for our current microservice-based architecture. There is one thing I'm not entirely sure how I would go about solving, however - the API gateway/proxy.
Consider a less-than-trivial microservice architecture where you have N number of services running within the Azure Service Fabric exposing REST endpoints. In many situations, you want to package these fragmented API endpoints up into a single-entry API for consumers to use, to avoid having them connecting to the service fabric-instances directly. The Azure Service Fabric solution seems so complete in every way that I'm sort of wondering if I missed something obvious when I don't see a way to trivially solve this within the capabilities mentioned during the BUILD talks.
Services like Vulcan aim to solve this problem by having the services register the paths they want routed to them in etcd. I'm guessing one way of solving this may be to create a separate stateful web service that other services can register themselves with, providing service name and the paths they need routed to them. The stateful web service can then route traffic to the correct instance based on its state. This doesn't seem entirely ideal, though, with stuff like removing routes when applications are removed and generally keeping the state in sync with the services deployed within the cluster. Has anybody given this any thought, or have any ideas how one might go about solving this within Azure Service Fabric?
The service registration/discoverability you need to do this is actually already there. There's a stateful system service called the Naming Service, which is basically a registrar of service instances and the endpoints they're listening on. So when you start up a service - either stateless or stateful - and open some listener on it, the address gets registered with the Naming Service.
Now the part you'd need to fill in is the "gateway" that users interact with. This doesn't have to be stateful because the Naming Service manages the stateful part. But you'd have to come up with an addressing scheme that works for you, and then it would just forward requests along to the right place. Basically something like this:
Receive request.
Use NS to find the service that can take the request.
Forward the request to it and the response back to the user.
If the service doesn't exist anymore, 404.
In general we don't like to dictate anything about how your services talk to each other, but we are thinking of ways to solve this problem for HTTP as a complete built-in solution.
We implemented a HTTP gateway service for this purpose as well. To make sure we can have one HTTP gateway for any internal protocol, we implemented the gateway for HTTP based internal services (like ASP.NET WebAPIs) using an ASP.NET 5 middleware. It routes requests from e.g /service to an internal Service Fabric address like fabric:/myapp/myservice by using the ServicePartitionClient and some retry logic from CommunicationClientFactoryBase.
We open-sourced this middleware and you can find it here:
https://github.com/c3-ls/ServiceFabric-HttpServiceGateway
There's also some more documentation in the wiki of the project.
This feature is build in for http endpoints, starting with release 5.0 of service fabric. The documentation is available at https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reverseproxy/
We have used an open source project called Traefik with amazing success. There is an Azure Service Fabric wrapper around it - it's essentially a GoLang exe that is deployed onto the cluster as Managed Executable.
It supports circuit breakers, weighted round robin LB, path & header version routing (this is awesome for hosting multiple API versions), the list goes on. And its got a handy portal to view the config and health stats.
The real power in it lies in how you configure it. It's done via the service itself in the ServiceManifest.xml. This allows you to deploy new services and have them immediately able to be routed to - no need to update a routing table etc.
Example
<StatelessServiceType ServiceTypeName="WebServiceType">
<Extensions>
<Extension Name="Traefik">
<Labels xmlns="http://schemas.microsoft.com/2015/03/fabact-no-schema">
<Label Key="traefik.frontend.rule.example">PathPrefixStrip: /a/path/to/service</Label>
<Label Key="traefik.enable">true</Label>
<Label Key="traefik.frontend.passHostHeader">true</Label>
</Labels>
</Extension>
</Extensions>
</StatelessServiceType>
Highly recommended!
Azure Service Fabric makes it easy to implement the standard architecture for this scenario: a gateway service as a frontend for the clients to connect to and all the N backend services communicating with the front end gateway. There are a few communication API stacks available as part of Service Fabric that make it easy to communicate from clients to services and within services themselves. The communication API stacks provided by Service Fabric hide the details of discovering, connecting and retrying connections so that you can focus on the actual exchange of information. When using the Service Fabric communication APIs the services do not have to implement the mechanism of registering their names and endpoints to a specific routing service except what are the usual steps as part of creating the service itself. The communication APIs take in the service URI and partition key and automatically resolve and connect to the right service instance. This article provides a good starting point to help make a decision with regards to which communication APIs will be best suited for your particular case depending on whether you are using Reliable Actors or Reliable Services, or protocols such as HTTP or WCF, or the choice of programming language that the services are written in. At the end of the article you will find links to more detailed articles and tutorials for different communication APIs. For a tutorial on communication in Web API services see this.
We are using SF with a gateway pattern and about 13 services behind the gateway. We use the built in DNS service that SF provides, see: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-dnsservice, this allows the internal service to service calls with known (internal to SF) DNS names, including gateway service to internal services. There are some well known asp.net core gateways (Ocelot, ProxyKit) to use, but we rolled our own. We have an external load balancer to route to multiple gateway instances in SF.
When a service is started, it registers it's endpoint with the fabric naming service. Using the Fabric client APIs you can then ask fabric for the registered endpoints, associated with the registered service name.
So yes, just as you described your case, you would have a gateway that would accept an incoming URI for connection, and then use that path information as the service name lookup, to then create a proxy connection between the incoming request and the actual internal endpoint location.
Looks like the team as posted one the samples that shows how to do this: https://github.com/Azure/servicefabric-samples/tree/master/samples/Services/VS2015/WordCount
Can someone explain to me how to setup a external end point for a fail over model in Windows Azure Traffic manager. I can add the end point to azure through powershell, for example www.mysite.com, but then the tutorials say I would need to change my DNS to point www.mysite.com to my.trafficmanager.net. But wouldnt this create a loop of sorts and never get to my actual server that is hosting the site?
In the scenario you describe you would first need to define a new hostname for your external endpoint in DNS (i.e. www-1.mysite.com) and configure your webserver to accept requests for that hostname. Once that is working you add the www-1.mysite.com to Traffic Manager as an external endpoint and the finally update DNS for www.mysite.com to point to Traffic Manager.