Windows Server 2016 comes in three flavours:
- Full UI
- Server core
- Nano
Nano is an exciting change - a disk image is about 700mb, and it boots in a few seconds (IIS serving web requests).
However, it has some limitations. Things it can do:
- Run IIS, Nginx
- Run Node and some other platforms
- Join an AD domain
- Execute PowerShell
Things that it cannot do:
- Full .NET framework. Only .NET Core is supported.
- How does PowerShell work? It uses PowerShell Core, which is built on .NET Core
Also, in 2016, the IIS administration PowerShell modules have changed - on Nano Server, there is no WebAdministration module, which we currently rely on heavily in Calamari.
Some options:
- Port Tentacle to .NET Core. This is probably do-able.
- Port Tentacle to something else.
- Drop Tentacle completely, and just rely on PowerShell Remoting to do everything that we do. This has the attraction to IT/ops of being something they are used to administering/exposing.
The bigger question is, how will people use Nano Server?
- As bare-metal installs - these would be pets, appearing as machines in Octopus
- As Hyper-V guest images - again, probably as pets that appear as machines, since changing them/redeploying is clunky
- As containers. We have pretty good plans for Docker + Octopus (Octopus pushing container images around)
If we did go for PowerShell Remoting as our transport layer, we'd get one big advantage: someone could boot a Nano server, register it in Octopus, and Octopus could deploy entire apps to it - no extra installs needed.
I think the .NET Core/Nano Server combination is pretty incredible - IF you can compile your app with just .NET Core, then you can run it on an incredibly small, fast-booting VM.
Right now, we register a Windows Server instance as a machine in Octopus, and deploy lots of websites to it.
In future, what if we registered a Hyper-V server in Octopus, and then used it to deploy NanoServer instances?
Hyper-V could be an "account"; the individual NanoServer instances could be linked to the accounts.