AWS App2Container
aws.amazon.com
aws.amazon.com
> 1) ASP.NET (.NET 3.5+) web applications running in IIS 7.5+ on Windows. A2C packages these applications with Windows containers.
Do people actually run Windows containers successfully?
Right now I'm working with get ASP.NET apps into containers, by first getting them ported to ASP.NET Core and then into Linux containers. The decision to skip Windows all-together was made before I joined, but I'm a nix guy so I don't complain.
One of the hiccups I've encountered on Linux is the lack of support for Windows Authentication. It gives you AD backed SSO basically for free (as a developer) - you just need one line of config to turn it on and the magic of IIS solves it for you.
We moved to ADFS instead, which worked well. But I'm guessing there are many of these deeply integrated services that make Windows containers attractive.
Yes, it's been done. Cloud Foundry has done it for a while and Kubernetes can do it as well.
It's not easy. Earlier versions of Windows didn't expose APIs suitable for partitioning resources and information in the sense that we think of as containers, so a great deal of hackery was needed to sorta-kinda-but-not-really recreate the experience. Later versions were better, but still lots of hackery was required. In my understanding it's only the latest versions of Windows that make it possible to "containerise" on par with Linux.
Part of the difficulty has been that there's a very long lag between "we need Windows to do X", to "Windows version 4000 now achieves X", to discovering that actually it doesn't really do X, to "Windows 5000 now achieves Y", to "and customers have actually installed it and retired Windows 3000 and 4000". That loop can be more than a decade and it imposes enormous overheads onto anyone proposing to support Windows containerisation as a platform capability.
Meanwhile in Linux-land, stuff lands in the kernel much sooner and arrives in release-ready form much sooner. What I've seen (anecdotally) is that there is a sudden step change in Microsoft platforms from .NET to .NET Core. Folks want containers, badly, and Core gets them there with much less fuss.
It was suprisingly easy to get working.
What Windows containers offers are Group Managed Service Accounts which reduces the administrative overhead managing service accounts for Linux containers and makes them completely transparent to the container.
I don't remember exactly why now, but isn't there some problem with the ephemeral nature of the container? Like that each instance of the container needs their own service account or something?
> What Windows containers offers are Group Managed Service Accounts which reduces the administrative overhead managing service accounts for Linux containers and makes them completely transparent to the container.
Aah, yeah, that seems nice.
I agree, it could be cumbersome without something to manage the secrets. I use OpenShift / k8s at work so injecting these secrets is trivial.
Windows authentication uses NTLM, if it’s backed by a directory such as an AD it’s then can be used by the server to authenticate or authorize the user.
The Kerberos support in Active Directory is somewhat there due to legacy reasons when there were a lot of directory products on the market that spoke Kerberos and it’s was added to support applications that did not shoot NTLM.
For the most part most Microsoft products don’t use it, and those which do don’t expose it to the users (SSO, tho there is now SSO with Windows principles too).
To put it more simply if you login to the server directly using a username and password (For a Windows Principle) it’s never Kerberos, for Kerberos authentication you need to go to a Kerberos server and get a TGT then use that TGT to get a service ticket for a specific resource which again is done against the Kerberos server directly that service ticket is then presented to the resource you are trying to access.
I've never tried to use kebreros with containers though, so ymmv
That's more of a problem to use Windows authentication capabilities for external public users. Usually it's used internally for employees, for whom the company has appropriate licenses and computers and stuff.
From what I can tell "containerization" is mostly just starting up a Docker image, running apt-get or equivalent to install tools (in this case, a JVM), and specifying a launch script or entry point. You might give it some arguments for what ports and volumes to mount.
Is there more to it? Because that kind of thing doesn't seem to require more than a simple script or two, and I have a hard time understanding why you need dedicated tools for this.
A few years ago I wrote up a scheme (which wasn't pursued) for automatic image construction[0]. The first half of the writeup enumerated a bunch of problems with relying purely on Dockerfiles.
[0] https://docs.google.com/document/d/1M2PJ_h6GzviUNHMPt7x-5POU...
After you run
dotnet publish
I never bothered to go through the manually steps. I used the CF template above.
Here is the complete Docker file for containerizing an ASP.Net Core API.
FROM microsoft/aspnetcore:2.0
WORKDIR /mymvcweb
COPY bin/Release/netcoreapp2.0/publish .
ENV ASPNETCORE_URLS http://+:5000
EXPOSE 5000
ENTRYPOINT ["dotnet", "mymvcweb.dll"]
Here is the CF Template:
But where that's not the operational setup, JARs on app servers are perfectly fine, IMO.
They do the "read the repo" thing in a uniform, composable way. So you don't need Java-but-also-some-special-case-for-front-end code. It's just buildpacks. Mix and match however makes sense.
Disclosure: I worked on CNBs for a while, as well as the ancestors of Paketo buildpacks.
Generating good Dockerfiles is harder than it looks and, in my experience, folks more or less wind up reimplementing Buildpack-like logic anyhow.
All you need to do is type `pack build` and someone else solves it. I've always liked that experience, going back to `cf push` and Heroku.
CNBs are a ground-up redesign of buildpacks, taking advantage of new foundations, with specific efforts to remedy the things that used to suck. They're composible instead of being giant monoliths, they update super fast and then you still get all the other niceties you used to have. Plus someone else maintains them and you'll never need to run a zillion rebuilds for every CVE that affects your OS, it's a simple rebase operation.
In my wildly biased opinion, I think they are worth another look, once you find time.
Vaguely relatedly, MS seems to be making another little push into Windows Containers after seemingly forgetting about them. 29 days ago a new Github issue tracker! https://github.com/microsoft/Windows-Containers
But a "simple" ASP.NET Core app (i.e not dependent on Windows specific features) is really is to get running on Linux, and it's not tricky to write a Dockerfile for that. Probably not hard to get running on a Windows container either, but I have not tried that.
If you are running Visual Studio I can recommend their Dockerfile-generator as a starting point, it have worked surpassingly well for me!
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy...