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.
Related
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.
Due to the hardware requirements that each cluster must have a minimum of 3 servers I'd like to use that hardware to support multiple branches/environments. Specifically we generally have 3 Dev and 3 Test branches running simultaneously for an application to support multiple parallel development project. After we release to production the code gets merged back into the other braches.
I understand I can create multiple instances of an Application Type, but what I think I really need is to have multiple versions of an Application Type on the same cluster. Its very possible that development could be happening in the A and B branches at the same time. We would want to test and deploy both branches to the Dev Cluster.
Similarly I would like to use the same cluster to expose a test environment endpoint. So as the code gets promoted I could deploy a TestB version of the application, if bug fixes happen those would be fixed and deployed in the DevB Version of that Application Type.
To handle the WebAPI endpoints Port issues we are planning on having the build script chose the environment specific WEBAPI Service manifest because it contains the port number that exposes the Service Fabric application to calling applications. So i'll have a ServiceManifest-DevB.xml file that gets renamed as plain old ServiceManifest.xml and packaged up with the DevB build when it goes out. Then ServiceManifest-TestB.xml will do the same but have a different port. Another option here is Tokenizer.
But I'm struggling on how can I have different versions of the same Application Type running on the cluster? Can I override Application Type in the parameter files or something along those lines? I am really hoping I don't need to build 6 clusters for this? That's a ton of hardware which won't fly.
Please help and thanks in advance,
Greg
I had this question a year ago and had put this down. Now its back so this time I will document it!!!
I am using one cluster for both my Dev and Test environments and we use two branches for these. I needed to be able to deploy the application for these two branches under different application names.
To figure this out I followed the ps1 trail. First you look at Deploy-FabricApplication.ps1 which just passed the PublishProfile to Publish-NewServiceFabricApplication.ps1. This guy uses a method in the Utilities.ps1 called Get-ApplicationNameFromApplicationParameterFile. All this does is open the environment specific application parameter file and read it off the top:
Use this is my Dev Application Paramter file:
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/MyAppDEVA" xmlns="http://schemas.microsoft.com/2011/01/fabric">
Use this in my Test Application Paramter file"
<Application xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Name="fabric:/MyAppTEST" xmlns="http://schemas.microsoft.com/2011/01/fabric">
Easy breezy when you know, and knowing is half the battle.
You can pass the desired version of an application when you create the application instance via New-ServiceFabricApplication. Just copy, register, and then new-up the application types and versions you need.
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.
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
We have WCF services deployed in azure cloud and runnig. We have some changes in some dlls and want to update in VM but dont want to go through regular deployment/redeployment process.
We are thinking of manually coping dlls to approot and siteroot folders. Will it work?
Will it pick up new dlls when VM restart anytime in future?
To answer your questions
Will manually copying dlls to approot and sitesroot folders work: Yes (make sure you do this on each instance if you have multiple instances running)
Will these dlls survive a reboot: Yes (see Reboot Role Instance: ... Any data that is written to the local disk is persisted across reboots. ...)
But I would suggest to only do this if you're planning to test some things while developing your service.
Do NOT plan to use this for production deployments, because if something goes wrong with your instance, the Fabric Controller might decide to destroy that instance and deploy a new one (same could apply for Windows Updates). This new instance would go back to the initial state of your deployment (the content of the cspkg you deployed).
To make your development deployments even easier you could also activate WebDeploy on your Web Role to deploy from Visual Studio: Enabling Web Deploy for Windows Azure Web Roles with Visual Studio (again, do not use this for real deployments, this is only for when you're testing out some things).
Note: Web Deploy will not work with multiple instances.
No,
And this is not the way to go. If you want to be more dynamic, you have to take the approach of Windows Azure Accelerator for WebRoles. Although not anymore supported and developed project, it will give you a good foundation of dynamically loading assemblies (in this case entire sites) from Blob storage.