> App2Container (A2C) currently supports the following application types:
> 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.
It offers a series of modules to make your application more cloud native and solves problems like service discovery, security, distri uted tracing, resilience with circuit breakers and external config using a config server.
Unless I'm mistaken, you should be able to get working Windows Authentcation if you have Kerberos libs installed, a valid krb5.conf and a keytab or service account credentials.
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.
Yeah, we investigated that route, but on stateless containers it seemed really cumbersome?
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.
I think it gets more complex if you need to do kerberos constrained delegation. It's been a while since I looked into it and threw my hands up, but essentially I think it's the ephemeral nature of containers that is the problem, as machines need to be registered in AD and have delegation rights assigned.
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.
Windows authentication absolutely uses Kerberos, NTLM is more used as a fallback. Kerberos is way more secure than ntlmv2 and is the favored authentication method.
> Do people actually run Windows containers successfully?
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.
The thing here is "Windows containers" -- ie, OS virtualisation of the NT kernel. Most software that uses classic .NET, COM, win32 etc APIs need to run on Windows. Stuff that runs on Linux typically gets run on Linux.
SSO on *nix is a non-starter and is a big (only?) argument to use a Windows box for Windows services. It used to also be a big argument for writing applications in .NET instead of, say, Java, but that got resolved with https://github.com/Waffle/waffle
You're both right, there is an incredible amount of licensing options that are insanely complex.
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.
If an organisation has decided to standardise around Kubernetes, OCI images and so on, then stuff like Jib or Buildpacks can make JVM-based software fit much more smoothly into that world.
But where that's not the operational setup, JARs on app servers are perfectly fine, IMO.
Can I ask, what is it really to "containerize" and why does it need a special tool?
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.
The main reason for specialisation is efficiency. The selection of the contents and ordering of layers has an effect on how quickly the can be rebuilt/updated, how big they need to be, how much deduplication you can get between images etc.
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.
I agree. I didn’t know anything about Docker - and I am still no expert. I put our entire CI/CD pipeline based on two or three easy to follow articles.
If you are using .NET Core, there are containers available for you that you just need to plug your application into. Just push those containers to any container runner you want.
As far as I can read it does not work with .NET Core.
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!
I know naming products is tough, but aws, are you try to confuse? "App2Container" is so ambiguous that it's guaranteed to be misunderstood. Was that a strategy to get more clicks or just reflective of the difficulty in succinct branding strategies?
While I agree it's very clear what "2" means in this context, it's off the pattern AWS has set with EC2 (Elastic Compute Cloud) and S3 (Simple Storage Service) where the numbers are part of an arithmetic expression (S* 3 and E + C * 2).
I’m not a .net or java user these days but I love the “guess what’s in a repo and try your best” strategy. I’ve been working on “deploy-node-app” for JavaScript applications that does similar: try to scan for dependencies, services, etc and “guess” as much of the Kubernetes configuration as a possible. It’s a fun project! Glad I don’t have to make it support .NET now ;)
You might be interested in Cloud Native Buildpacks, particularly the Paketo buildpacks: https://paketo.io/
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.
Cool! I plan on supporting BuildPacks eventually in my project - unfortunately the goal is teaching developers DevOps best practices and Kubernetes concepts - so build packs is a bit too down the rabbit hole compared to generating a Dockerfile. Eventually tho, buildpacks are exciting!
Yes, but buildpacks and Heroku have a similarity: incredibly simple to do the simple thing, incredibly opaque to do the complex thing. With a dockerfile, people can just install what they need. Sure - it could potentially be more efficient, but I like to focus on human efficiency rather than machine efficiency. Happy developers > fast CI systems :)
But Cloud Native Buildpacks are intended for the happiness of humans as well as machines. They can update an image faster than docker build can, because of careful selection of layers and by performing operations directly against a registry (rebasing). A developer can achieve some the same things with artfully-designed Dockerfiles, but then they're back to "what buildpacks can already do for me".
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.
Oh I agree with you - build packs are excellent! It's more about introducing one technology at a time. People who know about cloud native build packs typically don't need help writing dockerfiles or getting going on Kubernetes. On step at a time is all :)
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
42 comments
[ 3.1 ms ] story [ 104 ms ] thread> 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.
It offers a series of modules to make your application more cloud native and solves problems like service discovery, security, distri uted tracing, resilience with circuit breakers and external config using a config server.
I've never tried to use kebreros with containers though, so ymmv
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.
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.
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.
But where that's not the operational setup, JARs on app servers are perfectly fine, IMO.
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
https://aws.amazon.com/blogs/compute/hosting-asp-net-core-ap...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.
When you create your registry in ECR. It gives you the Docker commandsHere is the CF Template:
https://github.com/1Strategy/fargate-cloudformation-example
https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy...
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!
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