https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
w
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.
p
Oh...
I think you may just have put an end to our entire proof-of-concept.
We've been exploring Terraform as an option a few times in the past, most recently this summer. We have many beefs with it, but one of the main ones is how bad the fidelity is with what the underlying resource manager can do, what types of resources are supported and the configuration options they have.
We got excited about Pulumi in hopes that it would give us better mapping to Azure's capabilities. To realize it's actually just built on Terraform... wow, that's a cold shower.
The blog post you linked to should definitely help with this specific issue though, so thanks for that.
w
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!).
p
Right, I get that.
And don't get me wrong - there are many other aspects of Pulumi that are just so superior, the Terraform-constrained Azure provider notwithstanding.
as-code rather than as-text... all the goodness of Typescript, the ability to decompose and treat things as packages in NPM, and the absolutely genial way you do dependency tracking using the Input/Output constructs... etc.
My only concern would be that the "terraformity" of the Azure provider would end up hindering us from deploying the things we want to deploy.
We are generally relatively "on-the-edge" in terms of adopting new types of resources and services in Azure, as opposed to, say, an enterprise IT department who just want to deploy IaaS resources and stay on what's been CIS benchmarked etc, and for whom this might not be a concern I guess.
What sort of cadence do you strive for in terms of keeping up with development of the underlying Terraform Azure provider?
w
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.
👍 1
a
@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.
p
@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?
a
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
w
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!).
p
Aha, ok, that's promising! At least then there's a fallback.
Open in Slack
PreviousNext
Powered by