Service-fabric: Azure clusters do not have .net core 2.0 installed

[mikkelhegn]

Creating new Service Fabric clusters in Azure gives you VMs without .net core 2.0 runtime installed.

[MedAnd]

As an interim workaround maybe an approach similar to this would work: Deploy a Service Fabric Cluster to Azure with .NET Framework 4.6 (ARM template)

[smartpcr]

is there ETA for this enhancement?

[mikkelhegn]

@ChackDan

[mikkelhegn]

I noticed this is now implemented for Linux clusters. @abhishekram do you know if it's also fixed for Windows clusters? Which version of dotnet runtime do we install?

[agronompele]

@MikkelHegn I've deployed my .NET Core app (target framework is netcoreapp2.0) to Windows based Azure Service Fabric cluster. And it works. But when I connect via RDP to one of my VMs and use dotnet --version - it seems that .NET Core runtime is not installed there. So I wonder how my .NET Core app works inside Windows based Azure Service Fabric cluster. Can you answer, please?

[juho-hanhimaki]

Status update/details about out of the box support for .NET Core based services on Azure clusters would be greatly appreciated. I suppose this is something that is being worked on if not supported yet?

[dcasati]

I have the exact same question as @agronompele

Would anyone be able to shed some light on this ?

[mikkelhegn]

If you used the Visual Studio templates, they build a self-contained executable, which does not require the runtime to run. https://docs.microsoft.com/en-us/dotnet/core/deploying/index - Let me follow-up on the progress on Windows servers in Azure. Current way of automating this would be to use a custom script extension on your scale set model to install dot net. https://azure.microsoft.com/en-us/resources/templates/201-vmss-custom-script-windows/

[mfmadsen]

In general it would be greatly appreciated if .net core 2 reliable services could (maybe optionally) deployed as NOT self-contained. We have a Service Fabric project with around 30 reliable services all of them .net core 2. As they are all self-contained (i.e. includes the runtime in the service code folder) this very quickly adds up to a very large application package. We have been struggling on how to solve this using a shared runtime, but so far have not been succesful in doing so.

[mikkelhegn]

@mfmadsen You should be able to do that by following directions herer: https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs. If you change to FDD, the you need to update the entrypoint in the servicemanifest file to run dotnet. This example uses a script file as the entrypoint: https://github.com/Azure-Samples/service-fabric-dotnet-core-getting-started/tree/master/Actors/VisualObjects/src/VisualObjects.WebService

@bigmorty

[mfmadsen]

@MikkelHegn Great to hear - I'm in the process of testing that way forward now and it actually seems to work. Thanks a lot for pointing me in the right direction!

[abatishchev]

Just want to highlight the problem: cmd that calls dotnet that calls application dll approach should work. But it's user's responsibility to bring .NET Core on the cluster first.

[blaur]

@abatishchev Is there anywhere you can how to bring the .NET Core onto the cluster? I'm struggling with figuring that out.

[abatishchev]

@blaur you have few options:

• bring .NET Core installer with your app as part of Data package, run a startup script
• download NET Core installer, run a startup script
• create a separate application which will do it (if you have a large number of applications on cluster that need .NET Core)

Here's some sample code for the script:

Service manifest:

<CodePackage Name="Code" Version="1.0.0">
    <SetupEntryPoint>
      <ExeHost>
        <Program>setup.cmd</Program>
        <Arguments></Arguments>
        <WorkingFolder>CodePackage</WorkingFolder>        
      </ExeHost>
    </SetupEntryPoint>
    <EntryPoint>
      <ExeHost>
        <Program>run.cmd</Program>
        <Arguments></Arguments>
        <WorkingFolder>CodeBase</WorkingFolder>
        <ConsoleRedirection FileRetentionCount="5" FileMaxSizeInKb="1024" />
      </ExeHost>
    </EntryPoint>
  </CodePackage>

setup.cmd:

pushd "%~dp0"

powershell.exe -NoProfile -ExecutionPolicy Unrestricted -Command "& .\setup.ps1"

popd
exit /B %ERRORLEVEL%

setup.ps1:

Write-Host "Current working directory = $(Get-Location)"
if (Test-Path "$env:ProgramFiles\dotnet\dotnet.exe")
{
    Write-Host ".NET Core runtime has already been installed. Exit the installation."
}
else
{
    Write-Host "Installing .NET Core runtime"

    $proc = (Start-Process "$installer" -PassThru "/quiet /install /log $env:TEMP\dotnet_core_installer.log")
    $proc | Wait-Process

    Write-Host ".NET Core runtime has been successfully installed."
}

run.cmd:

pushd "%~dp0"

call "c:\program files\dotnet\dotnet.exe" YourApp.dll

popd
exit /B %ERRORLEVEL%

[blaur]

@abatishchev Thanks a lot for your feedback. Really do appreciate the help! I was somehow moving in the right direction then. What I am experiencing is this:
'pushd' is not recognized as an internal or external command, operable program or batch file

So for some reason the cmd does not recognize any commands at all.

[abatishchev]

That's very strange. RDP to the node, run it manually and see what's wrong with the OS.

[kentcb]

Is there any reason SF doesn't support a more intelligent zip format that acknowledges the likelihood of many services having many files in common? After all, a microservices architecture implies you will have many, focused service implementations. Chances are extremely high that many of these services will use some common building blocks, like JSON.NET, Google Protocol Buffers, or even the runtime itself. At the moment, per the comment from @mfmadsen, the deployment package rapidly balloons to untenable sizes as you add more services _whether you bundle the runtime or not_, since the zip format does not have any duplicate detection and elimination built in.

For example, being able to place all shared files in a well-known root folder along with an index that tells SF where to distribute those files upon decompression. The package compression tool (which, as far as I can tell, doesn't do _anything_ that significantly reduces your package size) could take all files across all services, and de-duplicate by way of hashing, storing only one copy of duplicated files in the deployment zip.

An alternative might be to support 7z packages, since they do have some built-in de-duplication support. However, I'm not sure effective it would be or if there would be legal implications to such an approach.

[abatishchev]

@kentcb with .NET Core you have option to produce Framework-Dependend Executables (FDE), see https://docs.microsoft.com/en-us/dotnet/core/deploying/#framework-dependent-executables-fde
Then your application's package would contain only NuGet dependencies and no framework dependencies.
But then you have to install .NET Core on VM yourself. Options:

• VMSS extension
• VMSS DSC
• SF startup script
• Separate SF application

What I really would like to see is a regularly updated OS image which would already contain the necessary SDKs pre-installed so I won't need either of the above.

[kentcb]

@abatishchev You seemed to have answered a question I didn't ask, and not the one I did :)

I'm aware you can opt not to bundle the framework. What I'm proposing would allow you to continue to bundle the framework - indeed, _frameworks_ if you have services using different frameworks - without paying a high price for doing so. In addition, it would also solve the problem of many services using many of the same NuGets (e.g. JSON.NET, Cosmos DB client etc).

Effectively what I'm proposing is the best of both worlds: continue to keep your application package completely self-contained, but each new service would add only those binaries that aren't already in use by another service.

Why wouldn't such an approach work?

[qrli]

My feeling (as an outsider) is:
They are moving slowly toward docker for everything, to be on par with Kubernetes. With docker, you
can have the runtime, as well as common 3rd party dependencies, in the base image, so that they can
be shared, while still allowing different apps to target different versions of the runtimes.

I don't think that's the golden solution though, as docker itself introduces quite some complexity. In the end, what we want is to simply run our programs, without caring about the OS/scheduler/runtime. And for Windows, the compatibility story is much better than the fragmented Linux distros, at least for .NET apps. So, I do like SF as a docker-less orchestrator, which SF team may not agree.

That being said, I do understand the ecosystem thing. If SF were not to follow the docker trend, it could get alienated in the market, even if they provide a better alternative. So, I hope, they ride on __both docker and serverless__ waves.

By serverless, I mean something like AWS Lambda 2, which enables runtime/library sharing easily.

[abatishchev]

@kentcb

You seemed to have answered a question I didn't ask, and not the one I did :)

Right. Fair enough. But. I would there are two sides here:

• what you can do, what tools are available, what SF team can help you with today
• what Microsoft in general and SF team in particular could do tomorrow to relief the pain, address the issue, etc etc.

I commented on the former. You and @qril commented on the latter. And I share your sentiments and like your ideas. But I'm not on the SF team, can't speak for them, nor is authorized to speculate on any plans going forward :).

[mikkelhegn]

I'm not aware of immediate plans to support this for application type packages.

I would encourage to open a new issue as a feature request, to help keep the issue clean :-) Preferably in the main code repo: https://github.com/Microsoft/service-fabric - be happy to jump on a discussion there.