Feature Request: Windows container support

joelverhagen commented 2 years ago

Is your feature request related to a problem? Please describe.

Currently, Azure Container Apps only supports Linux x64 container images (source):

Azure Container Apps supports:

Any Linux-based x86-64 (linux/amd64) container image

It would be great if Windows container images were also supported. For comparison, AKS supports Windows images (source).

Describe the solution you'd like.

Enable Windows container images so that workloads requiring Windows can run on Azure Container Apps.

Describe alternatives you've considered.

Use an alternative compute environment entirely.
Decouple Windows workloads from platform-agnostic workloads and run the platform-agnostic ones on Linux.

Additional context.

My Windows-only workloads are:

PDB analysis which depends on some esoteric .NET dependencies that only work on Windows.
Use of Windows' crypto stack (P/Invoke from .NET) that of course only runs on Windows).

The project that I want to deploy is my team's NuGet/Insights.

DeBlackDragon commented 2 years ago

Additional Workloads could be the use as a dsc push server for Microsoft365DSC as it is currently only supported on windows.

Phiph commented 2 years ago

I'm also interested in this for strangling some .Net Framework projects to .Net Core.

patkoch commented 2 years ago

I'd also like to share some details why the support of Windows images for Azure Container Apps would help us with regard to different aspects.

Currently we are in some kind of "transition phase" - we deliver our software applications currently at Windows Container - as it is not possible to us to refactor and redesign our software application to make it compatible to Linux. Our Software Application serves for Data Post Processing in the Automotive Industry for ~ three decades - therefore the refactoring takes a lot of time, as our customer of course rely on our APIs for their calculations. In future, Linux Container are planned, but at the moment, the usage of Windows Container is our realistic option.
Despite from the well known customer, we have also a lot of smaller customer - IMHO they would prefer to use Azure Container Apps instead of a Kubernetes Service, as Azure Container Apps are "easier to use" from the customer perspective, who does not have the man power and/or knowledge to manage and maintain an AKS (including to write proper Workloads with the corresponding Deployment rules)
In general, IMHO Azure Container Apps is a great tool for deploying the Container in Azure and for scaling them, if you don't have an AKS already provisioned - with regard to the costs which will be allocated if an AKS is running for several days (of course it is not that much effort to create e.g. Terraform Config Files for provisioning an AKS, but probably not all of our customer will be able to do that). It would provide a "quick" deployment of the Container - on demand - without having a more "complex" infrastructure.

artisticcheese commented 2 years ago

Why would Microsoft ask customers why do they need to use windows containers? I thought that story shall be already known to Microsoft since windows containers has been there for last 7 years and Microsoft shall have all the info about how customers use it and why they use and all the pain points etc. I'm surprised that 7 years after introduction Microsoft still clueless enough to ask "why would you want windows containers"

joelverhagen commented 2 years ago

@artisticcheese I don't speak for Microsoft in this regard but, from my own experience planning and prioritizing tasks for NuGet.org, my guess is that this is not a question of "why would Container Apps ever support Windows?" and more "how should we prioritize this work compared to other feature work?"

On my team we use upvotes on GitHub issues as a proxy for the impact of the issue. More upvotes means it should probably happen sooner since more users want it. Of course, there are other considerations like a low upvote issues that's very easy to implement may be done before a high upvote issue that's extremely costly.

If I were to guess, Windows container support is probably a big engineering task and the team wants to make sure they're using their engineering resources well before committing to it. Just my two cents :)

Again, I'm not part of the Container Apps team but I do have some experience triaging and planning issues filed on GitHub.

artisticcheese commented 2 years ago

Yes, that's what I expected as well. Microsoft should have asked to upvote this feature but based on Twitter thread they asked for use case instead which got me confused since I assumed Microsoft already aware of what use case for windows containers are.

jonlanceley commented 2 years ago

I would like to see this support windows containers too then it gives us an alternative to AKS as we have a range of .net versions in use

artisticcheese commented 2 years ago

Here is straight up from Microsoft press. Forza game apparently running on Windows containers https://customers.microsoft.com/en-us/story/1498781140435260527-forza-horizon-5-crosses-finish-line-fueled-by-azure-kubernetes-service

w5m commented 2 years ago

We are in a similar situation to @patkoch ...

We have a number of Windows DLLs which house niche engineering calculations that are more than 30 years old and would take a huge effort to port across to Linux, so the realistic option for us is also to use Windows containers. We likely don't need the power of a Kubernetes service, so Azure Container Apps looked ideal until I discovered it was Linux-only!

Sadly, even using Azure Container Instances (ACI) is a non-starter due to Windows container limitations (multi-container groups & virtual network deployment) which make it impossible to build an app comprising a sidecar container e.g. for web server and SSL termination.

Thus far, Microsoft haven't been able to suggest a viable alternative: https://docs.microsoft.com/en-us/answers/questions/946492/enable-https-for-aci-windows-container.html

artisticcheese commented 2 years ago

Another big thing ACI on Windows containers is not supporting is volume mapping, which makes it impossible to use for any statefull workload.

jvano commented 2 years ago

One possibility is to run Windows Containers in Azure App Service that’s supports SMB persistent storage https://learn.microsoft.com/en-us/azure/app-service/configure-connect-to-azure-storage?tabs=portal&pivots=container-windows

Here you can follow the QuickStart to run a Windows Container in App Service: https://docs.microsoft.com/en-us/azure/app-service/quickstart-custom-container?tabs=dotnet&pivots=container-windows-azure-portal

paarfi commented 1 year ago

Similar to @w5m, we have a number of 3rd party unmanaged windows dlls that are necessary for our application, but the owners of those dlls have no interest in adding support for linux. We are interested in moving to containers but reluctant to climb the steep learning curve or live with some of the downsides of other options. Azure Container Apps looks very promising for our application, but we won't be able to use it without support for windows containers so that we can run those 3rd party windows dlls.

owingruters commented 1 year ago

SItecore still needs windows containers. Please make it possible for windows containers te be used

cveld commented 1 year ago

We have Windows self hosted agents for Azure Pipelines which run perfectly on Azure Kubernetes Service but would be great to shift to Container Apps. Mainly due to costs and isolation.

CamiloTerevinto commented 1 year ago

I currently have a workload split into ACI and ACA - due to the lack of support for Windows containers in ACA.

I need Windows containers for some python-based APIs that have dependencies on Windows-only libraries.

azaiets commented 1 year ago

We have a quite simple background processing scenario, but also we have a 3rd party SDK that runs only on Windows. Currently we handle this with VMSS.

jvano commented 1 year ago

As I mentioned earlier, you can use Windows Containers in Azure App Service. If you are interested in a background processing scenario, just don't expose ports in your dockerfile or add the appsetting in the portal PORT=0 and we will run your Windows Container in the background.

CamiloTerevinto commented 1 year ago

@jvano ACA supports auto scaling, scaling to zero, and it's extremely cheaper compared to App Service. Besides that, I want to deploy it all as a single platform because it's all part of a single system. In fact, I want the Windows Containers to be reachable only from the CAPP environment.

rdeveen commented 1 year ago

@jvano Would be great if this feature request can be implemented. We would also have Windows self-hosted Agents for Azure Pipelines running in ACA on a Windows image because with KEDA we can use the auto scaller functionality.

RemyRemRoyal commented 1 year ago

@jvano Would be great if this feature request can be implemented. We would also have Windows self-hosted Agents for Azure Pipelines running in ACA on a Windows image because with KEDA we can use the auto scaller functionality.

Seconded. I am also wanting to run Windows self hosted agents in ACA.

markgould commented 1 year ago

Another upvote for windows support. We have some legacy containers that use Crystal Reports where it's going to take a long time to migrate to another library. Currently running everything in AKS on a mix of Linux/Windows nodes. Would much rather use ACA for everything, vs having to put Windows containers in an App Service, ACI or back to VMs.

karthikgenius commented 1 year ago

I don't know the technical limitations of Microsoft Azure supporting windows containers in ACA. We do have an enterprise windows application to which we plan to containerize, It would be very helpful if ACA support windows containers.

robertburgh commented 11 months ago

We have an app that is running at several hundred sites. It was in VB6 and is now .net6 / vue. The last piece is Crystal Reports.

We've made an api that returns a PDF stream of the report. This works well in a Windows Container. Since SAP isn't going to make CR .net (their words), having Windows Container support would be a good use case for us.

markgould commented 10 months ago

Any updates on this?

mvromer commented 10 months ago

Our team could definitely benefit from this. The bulk of our existing platform and data processing code is a mix of C++ and C# that interops via in-proc COM. The code spans 25+ years, and the cost and risk to port even a usable chunk of that to run on Linux would be prohibitive. That said, we would like to leverage a lot of that code in new web-based services we are developing using ASP.NET Core.

While we could use Azure App Service, as @CamiloTerevinto previously mentioned, ACA has a number of advantages making it a more economical solution, especially for workloads that have spiky traffic or extended periods of low activity. Plus, I find the deployment experience of deploying new revisions to ACA and being able to do things like traffic splitting rules a much nicer experience than deploying container workloads to App Service.

robertburgh commented 10 months ago

The cost of running App Service for one VERY low power windows container is crazy. It is about 10% of each of the Azure Tenant's cost. This is real money being wasted.

lerzeel2 commented 9 months ago

We would like to have this as well. Our WMS service supports ecw and sid image files, and our software uses windows dlls to read them.

dandoj commented 8 months ago

+1

Gijsreyn commented 8 months ago

+1

gregnye2022 commented 8 months ago

+1

davet44 commented 7 months ago

+1

RuiEloiVisma commented 6 months ago

+1

In our Team we use overall the Linux machines. But some external tools like EvoToPDF or GroupDocs they need to run in a windows machine. Would be great to have this feature

rfcdejongblinqx commented 6 months ago

We have a component (TX Text Control) that can only run on as an Windows container, so this breaks it to currently deploy it to Container App.

AddEleven commented 3 months ago

1

Kevinf63 commented 2 months ago

I'm very disheartened to find after much investigation, proof of concept work and fanfare around deploying self-hosted CI/CD runners and agents with Azure Container Apps jobs, it must be a Linux container, cutting out the very OS that Microsoft build and support.

This throws a significant spanner in the works and maintenance overheads for one person or a small team to use AKS instead when it isn't needed in the first place if Windows containers were supported. I've learned a valuable lesson, don't make assumptions around support.

Please update the Azure Container Apps documentation to ensure this limitations section in the "Containers in Azure Container Apps" wiki page, is more visible and pronounced in other places using the Note markdown styling or similar warnings. I missed this and got burnt.

What a shame, it would have been the perfect fit for the Azure Pipelines KEDA scaler and a Windows pipeline agent!

EDIT: For others reading this, it appears Microsoft have yet another product cooking in the oven called Managed DevOps pools, given the date of the "first look" blog posts, it seems to be a new service and certain options are not yet generally available (GA?). Unfortunate timing!