From the documentation and examples I've seen it seems that the preferred way to deploy Service Fabric services is to package them all up into an application package.
If I have 30 services and I make a change to one of them I'm not interested in having my CI server pull down the entire repository, build the solution, package it and then have Service Fabric decide that only one service changed and so only one should be updated.
Is there a way to create an application package with just one service?
You want to perform a partial upgrade (Differential Packaging). See here. Differential packaging
Related
There are web applications - WebAppA and WebAppB. Each web application depend on a Postgres database. We want to ship these applications to a customer who will deploy the applications on its own k8s cluster.
We want to create three packages - "WebappA", "WebAppB" and "Datastore". The webapp itself made of multiple services, not mentioning for the sake of simplicity.
We want to provide apt-get/brew/yum kind of experience, so that customer can deploy one or both the applications like al-carte. Most importantly while deploying, it should identify if the common package "DataStore" is running and not spin off yet another Postgres instance.
Is there any to package applications as packages for Kubernetes which can make installation easy with dependency handling?
Of course! One way to start would be using Helm charts. You can read more about them here.
Helm defines dependency relationships declaratively using charts, allows you to manipulate/maintain dependencies simply by managing some YAML manifests. It also allows you to have personalised repositories where you can put your images to be fetched from. It's really nice.
I am not clear enough yet how Service Fabric allows deployment.
From the applications being created in a single VS solution, let me try to ask with file formats for better understanding.
In a single Visual Studio solution, there are
a single .sln
a single .sfproj
multiple .csproj(s)
As I see these files, multiple services (.csproj files) are bound to a single Service Fabric application (.sfproj file), which is under single solution file (.sln file).
Can I individually deploy a .csproj project to the Service Fabric cluster, or are these now bound to a .sfproj so that I have to deploy multiple services (each created with .csproj and bound to .sfproj) together?
The answer to your question is yes and no at the same time. Let me explain it in detail.
Can I individually deploy .csproj project to the Service Fabric cluster
The answer is no you can't deploy a service - in term of Service Fabric the minimal unit of deployment is the application (the .sfproj one). So no matter what changes you have you still need to deploy the application.
But as we all understand performing a full deployment of all application services is very hard, consumes lots of time and causes lots of disturbance to the cluster. To avoid this massive update, all Service Fabric components have their own versions (you can take a closer look at ServiceManifest.xml and ApplicationManifest.xml). So each time application is deployed to the cluster, Service Fabric goes through all services included in the application and updates only components that have been changed (i.e. have different version).
This approach allows you to perform updates of very high granularity i.e. you can update only <Config /> package of the single service.
I have stateless .net core 2 Fabric Service Web Application creating using one of the templates that comes with Service Fabric SDK. It is a real pain to develop since I have to do a full deploy before I can see any changes to code/html/script. In my case that operation takes more than 5 minutes.
I have looked at this article that states how it can be done by running the web app from the commandline.
That article is based on Net Core RC2. Does anyone has an updated example on how to do this?
https://dzone.com/articles/aspnet-core-with-kestrel-and-service-fabric
Together with Azure Developer Support i found a solution to speed up the development process
I Fabric Explorer you need to find the node where you Web Application is running. I my case that is _Node_0
By SF SDK design, local SF published file is under C:\SfDevCluster\Data_App\ this folder. In my environment, the website file path is C:\SfDevCluster\Data_App_Node_0\Application1Type_App1\Web1Pkg.Code.1.0.0\wwwroot\lib\bootstrap\dist
So you can also find your HTML, CSS, JS and other static resources under below path:
C:\SfDevCluster\Data_App[node_id][application_type_and_instance_name][service_type_and_version]\
You can just modify the files in this folder, then the change will immediately apply to your local test web browser. Please notice if your service is hosted by micro-service running in several nodes, you may need to modify all nodes files because load balancer may access any folder files randomly.
Is there a possibility to deploy only Application Parameters (cloud.xml) somehow without having to redeploy the code or upgrade the application version? For example after deploying the Application on Service fabric cluster, there could be a minor thing I might need to change in one of the parameters in cloud.xml. And it won't make sense to upgrade the version of the Application for this minor change.
I have combed through various sites but did not find anything suitable.
I'd say - no, you can't do this. Here is what Service Fabric application upgrade says on this -
During an upgrade, Service Fabric compares the new application manifest with the previous version and determines which services in the application require updates. Service Fabric compares the version numbers in the service manifests with the version numbers in the previous version. If a service has not changed, that service is not upgraded.
I want the ability for clients to create their own stateless services and be able to upload/publish it to join an existing cluster. Is this doable? I understand that I need to update the application manifests dynamically but not sure how or if this is possible programmatically without side effects of the service fabric runtime processes.
The workflow is to upload the code (zipped file maybe or whatever) via an API gateway.
The first thing to keep in mind is that you do not deploy individual services to a Service Fabric cluster. You deploy applications, which can contain one or more services.
So the key question to ask is whether you need the new code to be integrated with an existing application type or not. It sounds like what you're trying to do is just enable multiple clients to deploy independent applications on a shared Service Fabric cluster, in which case you would not be modifying existing application types, but deploying entirely new ones.
Thus, you would need your API gateway to dynamically generate application and service manifests, combine them with the client-provided code to create an application package, then copy, register, and create those applications in the cluster. As far as the Service Fabric runtime is concerned, this looks no different than if you had deployed an application type built and packaged in Visual Studio. Processes running existing applications are not impacted.