Azure App Service Stack Settings (TS)

[rajeshmuraleedharan]

I am trying to create Azure App Service for .net core app (deploy as code). I wanted to specify Stack = .Net Core

Not sure how to set this property, looked at AppServiceSiteConfig. But couldn't find the property to manage this. Please let me know

[pgavlin]

cc @mikhailshilkov @stack72

[mikhailshilkov]

@rajeshmuraleedharan May I ask first why you need to set it? This example deploys a .NET core app to the App Service: https://github.com/pulumi/examples/blob/d158d0c5c205b5ead7992d1d6a19a71bdf149a22/azure-ts-appservice-devops/infra/index.ts

[rajeshmuraleedharan]

I see above example uses blob storage to store app publish zip file and host from there. We use azure devops task directly to deploy app, no need for storage account.

We use to create app service app manually where we have the option to select .net core stack. Was trying to reproduce the same. AppServiceSiteConfig object has the prop to mention "httpsOnly" thought there is a way to assign stack .netcore/ java/ php...

[mikhailshilkov]

Based on digging the generated ARM Template, I can see that they set it with

"siteConfig": {
       "appSettings": [],
        "metadata": [
        {
            "name": "CURRENT_STACK",
            "value": "[parameters('currentStack')]"
         }
    ]
 },

I fail to find any docs that would explain what this value does.

@rajeshmuraleedharan Do you have issues running your app without this config, or do you want to set it to match the portal?

[antunesl]

Hi! I'm facing the same problem here. I've a C# pulumi setup that configures several WebApps, and without setting these 'Stack Settings' the values in the Azure will become empty and the webapp don't run properly (I think the container used by WebApp don't start correctly). Right now, when it's a new setup (pulumi up with WebApp creations) I have to go to azure portal and set those settings manually.

It's something not available only in C# SDK, or maybe not supported at all yet? Is there some workaround to set these settings?

Thanks.

[mikhailshilkov]

@antunesl Could you share the code to repro your problem? I'm curious about how it's different from https://github.com/pulumi/examples/tree/master/azure-cs-appservice Thanks!

[antunesl]

I can't share the repo where this exists unfortunately, maybe I can create one for demonstrate the behavior later this week. But I created a sample resource in the same project just now to test.

This is the code to create the resource:

This is the WebApp just created in the Azure Portal:

The stack settings are empty after creation.

[mikhailshilkov]

Thanks for sharing!

Does the fact that they are empty break the App Service? In what way?

Have you tried applying SiteConfig.Metadata as I mentioned in https://github.com/pulumi/examples/issues/473#issuecomment-556368959 (I did not try it, honestly)?

[antunesl]

Does the fact that they are empty break the App Service? In what way?

After deployment was made to the WebApp, it always returned 403 Forbiden. By inspecting the Log Stream on Azure Portal I was seeing some errors in the internal container on the WebApp. Honestly I don't know the reason for the correlation between the two things. But after comparing with an WebApp created in the Portal I could see this difference, and after setting the configs it start working.

Have you tried applying SiteConfig.Metadata as I mentioned in #473 (comment) (I did not try it, honestly)?

I don't, and I don't see anything in the C# sdk to set metadata (that's what I'm using, I know this issues was created with the TS sdk context).

But after you mention the ARM template, I start looking to the template of a WebApp created in the Portal and I think I discovered the configuration to be set. The SiteConfig.LinuxFxVersion does the trick.

@rajeshmuraleedharan check if this setting works in the TS sdk also.

Thanks for the help @mikhailshilkov !

[mikhailshilkov]

@antunesl Interesting... Haven't you bumped into https://github.com/pulumi/pulumi-azure/issues/409 ?

[antunesl]

@antunesl Interesting... Haven't you bumped into pulumi/pulumi-azure#409 ?

No, but I only used the LinuxFxVersion config, maybe that issue just happens on some configs?

I just tested setting the Http2Enabled config and make a pulumi up, and everything went ok. I can see HTTP 2 in the WebApp configuration (was an update, not a creation).

[andrekiba]

Strange, I tried with

SiteConfig = new AppServiceSiteConfigArgs
{
	LinuxFxVersion = "DOTNETCORE|3.1",
	Use32BitWorkerProcess = aspConfig.Get("sizingSize") == "D1"
}

but for me it doesn't work, It says that the "DOTNETCORE|3.1"" value is not valid. I'm with a Windows D1 Shared app service

[andrekiba]

The event strange thing is that I think I have to set this value on "WindowsFxVersion", not "LinuxFxVersion" but I have the error on "LinuxFxVersion" even if I don't try to set it at all in the SiteConfig object!

[muralikrishna188]

We want to migrate our web apps to dotnet core 3.1 LTS with windows . Can you please suggest how to write ARM template to create Windows app service with dotnet core 3.1 LTS?

[Slowacki]

The workaround doesn't seem to work anymore. Is there any other way to set the CURRENT_STACK in metadata?

[flytzen]

Just run into this issue - it is definitely a problem. An additional complication now is that when "stack" is left blank, the Application Insights menu is now also disabled.

[mikhailshilkov]

The upstream issue for the Azure provider: https://github.com/terraform-providers/terraform-provider-azurerm/issues/5350

[khellang]

@mikhailshilkov What about the azure-native provider? Does it have a way to specify the stack?

[khellang]

Ah, just found this sample, which could be what I'm looking for 😄

[JontyMC]

For anyone trying to find answer to this, the correct way to do it is:

var webApp = new WebApp("MyWebapp",
    new()
    {
        ...
        Name = "my-web-app",
        SiteConfig = new SiteConfigArgs
        {
            ...
            NetFrameworkVersion = "v6.0"
        }
    });

var webAppMetadata = new WebAppMetadata("MyWebappMetadata", new()
{
    ...
    Name = "my-web-app",
    Properties = new()
    {
        { "CURRENT_STACK", "dotnetcore" }
    }
});

[lukehoban]

This is addressed now.

[mastoj]

@JontyMC should the above code set the settings in the picture:

Can't get it to work for me. I have the following code, which is roughly the same:

    const app = new azure.web.WebApp(
      name,
      {
        resourceGroupName: resourceGroupName,
        serverFarmId: servicePlanName,
        siteConfig: {
          netFrameworkVersion: "v8.0",
          appSettings: [
            {
              name: "CONNECTION_STRING",
              value: connectionString,
            },
          ],
        },
      },
      azureOptions
    );

    const meta = new WebAppMetadata(
      name + "-metadata",
      {
        resourceGroupName: resourceGroupName,
        name: app.name,
        properties: {
          CURRENT_STACK: "dotnetcore",
        },
      },
      azureOptions
    );

[JontyMC]

Looks good. Two things can think of that might impact it:

• v8 is early access - is this the right version string?
• We explicitly use DependsOn in the WebAppMetadata to depend on the WebApp

[mastoj]

Could be the version that is wrong. I tried using https://management.azure.com/providers/Microsoft.Web/availableStacks?api-version=2023-11-27&osTypeSelected=Linux (https://learn.microsoft.com/en-us/rest/api/appservice/provider/get-available-stacks?view=rest-appservice-2022-03-01#code-try-0). to see what it should be, but v8 is not in the response even though it is in the UI.

I don't need the DependsOn since I use the name from the resource so pulumi should figure out the dependency.

[mastoj]

I have also tried "v7.0" without success, so not sure how to get this to behave as expected.

[mastoj]

I think this siteConfig might do the work:

siteConfig: {
          netFrameworkVersion: "v8.0",
          linuxFxVersion: "DOTNETCORE|8.0",
          appSettings: [
            {
              name: "CONNECTION_STRING",
              value: connectionString,
            },
          ],
        },

[JontyMC]

Ah, our app service plan is windows, so maybe that's why it didn't work for you?

[mastoj]

I guess so… not very obvious though, glad ChatGPT figured it out 🤣

On Tue, 28 Nov 2023 at 09:47, Jonathan Curtis @.***> wrote:

Ah, our app service plan is windows, so maybe that's why it didn't work for you?

— Reply to this email directly, view it on GitHub https://github.com/pulumi/examples/issues/473#issuecomment-1829354770, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD2NMBGKB352PEO7YXZLZTYGWQKNAVCNFSM4JPVRG32U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSHEZTKNBXG4YA . You are receiving this because you commented.Message ID: @.***>