[Proposal] Host Identity Server using Kestrel directly instead of behind IIS

[anarsen]

Proposal

PR #226

We've had luck with avoiding IIS altogether for the Identity Server Docker image. As you know, Identity Server is built on Sitecore Host which in turn is built on ASP.NET Core.

Setting ENTRYPOINT ["dotnet.exe", "c:\inetpub\wwwroot\Sitecore.IdentityServer.Host.dll"] directly instead of using IIS as a reverse proxy simplified logging to stdout as well, since Sitecore Host does that out of the box through Microsoft.Extensions.Logging.Console.

If you still need to provide a TLS certificate for SIS, which previously was attached to the IIS binding, just set that using https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1#endpoint-configuration-2.

I'll be happy to contribute if you're interested in adopting this approach.

Unfortunately I didn't succeed in basing this on a Nano Server image since SIS still uses the Certificate Manager internally. However, a clean Windows Server Core image with ASP.NET Core 2.1 Runtime installed was sufficient.

Caveats

Watch-Directory.ps1 might not work. I'd expect dotnet.exe would have to be restarted in order to pick up changed binaries/configs.

[pbering]

Sounds like a good change and using Kestrel directly makes more sense. Why would Watch-Directory.ps1 not work?

@bplasmeijer do you see any problems doing this?

[anarsen]

@pbering I was thinking if binaries or configs change, then Kestrel wouldn't know about it whereas the IIS would restart dotnet.exe underneath. At least in the out-of-process model used in ASP.NET Core 2.1.

It's speculation so I'd have to check it out. I'll get around to doing that soon.

[pbering]

Ah yes that would be a problem. I wounder if we could use dotnet watch run in a development entrypoint so Watch-Directory.ps1 would still work?

[anarsen]

dotnet watch expects an MSBuild project file sadly. I can imagine FileSystemWatcher working in the Kestrel approach too though.

The execution could look like this:

1. Start a FileSystemWatcher
2. Register event handler which terminates any dotnet processes
3. Loop forever: 3.1. Execute dotnet Sitecore.IdentityServer.Host.dll 3.2. Write to stdout files x, y, z changed

Edit It's important that any SIGKILL or <C-c>s are propagated to the dotnet process to allow for a graceful shutdown.

[pbering]

mmm damn it does required that. FileSystemWatcher are not really good, always hit or miss and they are not much better inside a container :) - I'm thinking that we should just not support using Watch-Directory.ps1 and use a standard dotnet run Sitecore.IdentityServer.Host.dll entrypoint and people that needs to configure it should use it as a base image and add their own stuff on top. Either that or leave it on IIS as today. I can't decide this alone since I'm not using it currently.

Anyone that is using it have any comments?

[bplasmeijer]

I will do Sitecore review.

[joostmeijles]

mmm damn it does required that. FileSystemWatcher are not really good, always hit or miss and they are not much better inside a container :) - I'm thinking that we should just not support using Watch-Directory.ps1 and use a standard dotnet run Sitecore.IdentityServer.Host.dll entrypoint and people that needs to configure it should use it as a base image and add their own stuff on top. Either that or leave it on IIS as today. I can't decide this alone since I'm not using it currently.

Anyone that is using it have any comments?

I am in favor of using standard dotnet run ... and custom scripts on top of that.

[jballe]

Hmm for production images I would definitely prefer dotnet run.

For local development it is really nice to have the fast feedback cycle. However, even though I have made some customization to Sitecore Identity Server, it is very rare and not a big loss for me that I would have to rebuild the container. Actually in that project we already have to rebuild the container to get any new file updates (as that was the easiest way to get started). So I think it is a fair trade-off that those images are optimized for production performance and you can extend if you have special needs.

[anarsen]

Thanks for all the feedback.

In the meantime, I’ve managed to run Identity Server in a Nano Server container too. The HTTPS certificate and the Identity Server certificate can both be read from files, and not only the certificate store as the example configs indicate.

That makes it even more interesting in my opinion. I’ll submit a PR on this in the coming days.

[anarsen]

@pbering @bplasmeijer @joostmeijles In case you didn't notice, I opened PR #226

It might not fit perfectly into the XM, XC, XP topology groupings. Let me know what I can do to make that happen, if that's the case.

[joostmeijles]

See my comments in #226 .