And as to the specific problem at hand: any help on how to create a Linux container app service would be appreciated.

Does this help? https://pumpingco.de/blog/deploy-an-azure-web-app-for-containers-with-terraform. The current

@pulumi/Azure

package projects the Terraform Azure Provider, so the core model is based on the design of that layer, not directly the ARM APIs. We’re exploring offering a direct projection of ARM into Pulumi as an alternative in the future.

Oh...

One thing to clarify. Pulumi itself is not built on Terraform in any way, but the Azure Resource Provider for Pulumi is (currently) built on the Azure provider for Terraform (that is, the resource CRUD operations). As a result, there are many benefits Pulumi can offer over Terraform. But the specific point of the shape of the Azure API is one where Pulumi is not (currently) different than Terraform. For kubernetes, Pulumi offers a native API to the raw Kubernetes object model - and we expect to do similar for Azure in the future. Definitely understand the concern with some limitations of the Terraform Azure API. This has in practice been much more of a problem for Azure than any other clouds (aws, gcp, etc). Though similar to the issues that were present for Kubernetes (which motivated us to build a native provider!).

Right, I get that.

Yes - definitely appreciate the concern and questions - in particular for the Azure provider. We generally update within a day or two of releases of the underlying provider.

@powerful-football-81694 I've had success deploying to app service for linux with both custom containers and builtin images + deploy-from-zip. That blog link had everything needed: app service plan has to have Linux and reserved set, apps with built in containers use the linux_fx_version and custom containers use the DOCKER_ app settings. Only other gotcha is that you can't mix windows / linux apps in the same resource group or plan. I'm also pretty on-the-edge and anything the provider hasn't been able to provide has been straight forward to do within the pulumi app using http api calls via the arm node sdk. The mixing of provider resources and my own calls/resources is what initially attracted me to pulumi and it has simplified our deployments significantly.

@adventurous-night-54654 That's really nice to hear. When you do your own HTTP calls using the ARM SDK for Node, are you able to hook that into the normal preview/update cycle of Pulumi? Or are you doing that sort of out-of-band?

I was initially doing everything out of band with a lot of isDryRun calls, but I recently stumbled across the dynamic provider in the pulumi-node runtime that lets you participate in the full lifecycle and preview. I honestly haven't found a lot of documentation on it, but it does work as mentioned in the apidocs. Reference: https://pulumi.io/reference/pkg/nodejs/@pulumi/pulumi/dynamic/#ResourceProvider node test as an example: https://github.com/pulumi/pulumi/blob/master/tests/integration/explicit_provider/index.ts

Yes - Dynamic Providers are a useful tool for providing fully customized resources that can participate in the Create/Read/Update/Delete lifecycle just like any native resource provider - but implemented in JavaScript. It's a low-level interface, but very expressive. We've used these with a couple of Azure customers tin particular to help them work with resources that were not yet mapped to Pulumi/Terraform (or even ARM in one case!).

Aha, ok, that's promising! At least then there's a fallback.