I'm migrating a Cloud Service application to a Service Fabric application.
I'm looking for a ServiceEnvironment equivalent to RoleEnvironment in order to get the service name from the environment variables.
https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-environment-variables-reference
Related
I'm trying to understand why and when to use Spring Cloud K8s Discovery Server when K8s has a Native Service Discovery which does:
Service discovery
Ensures compatibility with additional tooling (e.g. Istio)
Isn't it simpler if your app can simply rely/use a DNS name of a service it needs? On top that that it gets load balancing as well. Why should one even think about a Discovery Server?
I have a Service Fabric Application which consists of two services. Both are stateless services and have a single instance of the services.
In Service A, I would like to define a Endpoint in the Resources section of the ServiceManifest.xml. I don't care what port I get, I just need one and I'd like to get it from Service Fabric so it can ensure it's accessible between the vms managed by the Service Fabric cluster.
In Service B, I'd like to pass the port created for Service A so it can use it to interact with the Service A. I will be defining both services with Service Fabric DNS names, so Service B will know the host of Service A (regardless of where it's running). But Service B also needs to the port that was created for Service A (via it's Endpoint declaration). Is that information passed to the Services? Can it be passed as a parameter, or is there another mechanism.
Thanks for any help
You can discover information about the endpoints of the other service by using the QueryManager on the FabricClient. Example here.
Out of curiosity, can't you use SF remoting for this?
Context
I am deploying a set of services that are containerised using Docker into AWS. No matter which deployment solution is chosen (e.g. raw EC2/ECS/Elastic Beanstalk/Fargate) we will face the issue of "service discovery".
To name just a few of the options for service discovery that I've considered:
AWS Route 53 Service Registry
Kubernetes
Hashicorp Consul
Spring Cloud Netflix Eureka
Specifics Of My Stack
I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.
Given that my stack is Spring based, spring cloud eureka made sense to me while developing locally. It was easy to set up a single node, integrates well with the stack and ecosystem of choice and required very little set up.
Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.
However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.
My Own Assessment Of Pros/Cons
AWS Route 53 Service Registry
Requires us to couple code specifically to AWS services. Not a problem per se, we are quite tied in anyway on other parts of the stack (SNS/SQS).
Makes running the stack locally slightly more difficult as it relies on Route 53, I suppose we could open up a certain hosted zone for local development.
AWS native, no managing service registries or extra "moving parts".
Spring Cloud Eureka
Downside is that thus requires us to deploy and manage a high availability service registry cluster and requires more resources. Another "moving part" to manage.
Advantages are that it fits into our stack well (spring ecosystem, spring boot, spring cloud, feign and zuul work well with this). Also can be run locally trivially.
I presume we need to configure the networks and registry zone to ensure that that clients publish their host address rather and docker container internal IP address. e.g. if service A is on host A and wants to talk to service B on host B, service B needs to advertise its EC2 address rather than some internal docker IP.
Questions
If we use Kubernetes for orchestration, are there any disadvantages to using something like Spring Cloud Eureka over the built in service discovery options described here https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
Given Kube provides this, it seems suboptimal to then use eureka deployed using kube to perform discovery. I presume kube can make some optimisations that impact avaialbility and stability that might nit be possible using eureka. e.g kube would know when deploying a new service - eureka will have to rely on heartbeats/health checks and depending on how that is configured (e.g. frequency) this could result in stale records whereas i presume kube might not suffer from this for planned service shutdown/restarts. I guess it still does for unplanned failures such as a host failure or network partition.
Does anyone have any advice on this, do people use services like Kubernetes but use other mechanisms for service discovery rather than those provided by kube. Is there a good reason to do one or the other?
Possible Challenges I Anticipate
We could replace eureka, but relying on Kube to perform discovery will mean that we need to run kube locally to deploy whereas currently we have a simple tiny docker-compose file. Also, I'll have to look at how easy it'll be to ensure that ribbon, zuul and feign play nicely with this.
Currently we have ribbon configured with a eureka client so that service A can server to service B just as "service-b" for example and have ribbon resolve a healthy host via a eureka client. I guess we can configure ribbon to not use eureka and use an external Kube service name which will be resolved by Kube DNS at runtime...
Final Note
Thanks in advance for any contribution or advice. I know this might elicit a primarily opinion focused response. But I am hoping someone can provide objective guidance on when one solution might be preferable to another.
Service discovery is something you get out-of-the-box with Kubernetes. So having another external service in your platform will be another application to maintain, deploy and can be a point of failure. So I would stick with the the service discovery provided by Kubernetes.
We have a Service Fabric cluster on-premise and would like to deploy code to it from Visual Studio Team Services. We use this cluster for testing and it does not have an endpoint exposed to the outside world. It is only accessible internally from inside our network.
From inside Team Services the normal way to deploy a Service Fabric application is with the "Service Fabric Application Deployment" task. This task requires a "Cluster Connection" parameter, or link to the Service Fabric Service endpoint that Team Services can access. On this cluster I can't provide an endpoint to the outside world, so this method won't work.
Is there a good, accepted way of accomplishing this? I'm considering looking at having an Agent on one of the Service Fabric nodes that can run a PowerShell script as part of the build process. I can kick off a PowerShell script on the node as part of the build process. If I could retrieve the artifacts from Team Services with this script I believe the rest of the release would be relatively straightforward.
Is this a good line of thought, or is there a more straightforward way to deploy to Service Fabric from Team Services without exposing an endpoint?
We have the same set up and using VSTS. We set up a On-Prem agent pool where agent is within our network. The agent is hook with VSTS so build and release can be trigger from VSTS. Agent have access to the artifact on VSTS and can download it for deployment. The different might be we set up a service fabric end point instead of using powershell.
Its a very simple set up and works well for us.Good luck
I faced this term end-to-end service deployment what does it means in the area of cloud computing?
It may simply mean that all the elements of the service are deployed in the cloud - for example for a typical 3 tier web service, the web server, application servers and database would all be hosted on nodes in a 'cloud' offering.
It could also be taking about the actual action of deploying the service in the cloud - for example the above 3 tier web service might have a scripted deployment which allows you deploy the entire service end to send with a 'one button' click. Take a look at 'Puppet' (https://puppetlabs.com) or Amazon Cloud formation(http://aws.amazon.com/cloudformation/) for some examples.