This message was deleted.

And what exactly isn't working in this setup for you? How does your GHA workflow look like? Assuming that you're not seeing your app service pick up newly built containers: • Please note that App Service doesn't automatically pull & redeploy the newest manifest for a given container tag, unless you restart the app service, which of course isn't optimal. For that you have two options: ◦ Use the Azure/webapps-deploy action to trigger an update. Recommend going with the az login with a service principal example instead of using a publish-profile. ◦ Container Registry webhooks – which I would advise against (IMO deployments should happen within the CI/CD workflow where you see the deployment failing) And some feedback on the example you provided: • Disable registry admin credentials ◦

admin_user_enabled=False

◦ Enable managed identity on the App Service:

identity=web.ManagedServiceIdentityArgs(type=web.ManagedServiceIdentityType.SYSTEM_ASSIGNED),

◦ Assign the AcrPull role on the App Service. See this gist for how to do that in Pulumi/Python. ◦ Remove the docker login related ENV vars ◦ Set this option in site_config:

acr_use_managed_identity_creds=True

• Use OIDC credentials in your workflow instead of client credentials. I used this bash script in the past before migrating the provisioning of this Pulumi (can't share that right now). It will automatically create the service principal and store the credential as an environment secret in your GitHub repo if

gh

cli is present. Otherwise see GitHub and Azure docs. • Don't use

latest

tags for containers as it's an anti-pattern and can cause various problems and confusion ◦ Instead use the docker-metadata-action to automatically tag your images with branch name, github sha. Pull request builds will get a pr-number tag. Can even support semver tags if you implement that. ◦ This makes it much clearer what version of your container is actually deployed • For App Service production workloads which need zero-downtime: ◦ Go with the Premium tier app services ◦ Create deployment slots ◦ Have your CI/CD workflow deploy release candidates to a staging slot and then swap that into production ◦ I've used az cli in a workflow for doing that like so: ◦

az webapp deployment slot swap -s slot_name -n app_name -g resource_group

Thank you very much for the suggestions and sharing the best practices, I will consider them. The idea behind sharing this was to start from somewhere as an example rather than just a generic question. Here is an example of workflow; Is there anyway that I can execute this workflow after creating the resources via Pulumi but then the problem is I need to pass the right credentials and name of the azure resources before executing it. Maybe I am doing it all wrong?

name: Build and deploy - Test

on: 
 push:
    paths-ignore:
      - '**/README.md'
      - '**/.github/workflows/**.yml'
    branches:
      - develop
 workflow_dispatch:

jobs:
  lint:
    runs-on: ubuntu-latest
    environment: Testing
    steps:
      - uses: actions/checkout@v2
      - uses: psf/black@stable

  deploy:
    runs-on: ubuntu-latest
    environment: Testing

    steps:
    - uses: actions/checkout@v2

    - uses: azure/docker-login@v1
      with:
        login-server: ${{ secrets.ACR_DEV_SERVER }}
        username: ${{ secrets.ACR_DEV_USERNAME }}
        password: ${{ secrets.ACR_DEV_PASSWORD }}

    - run: |
        docker build -t ${{ secrets.ACR_DEV_SERVER }}/repo-name:${{ github.sha }} .
        docker push ${{ secrets.ACR_DEV_SERVER }}/repo-name:${{ github.sha }}
    - uses: azure/webapps-deploy@v2
      with:
        app-name: 'App Name'
        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
        images: '${{ secrets.ACR_DEV_SERVER}}/repo-name:${{ github.sha }}'

Sure, you could automate all of that in a single workflow... For doing Pulumi deployments from within GHA you can use the pulumi-cli-action • You'll need to create a Pulumi access token if you want to use Pulumi cloud to store the state • Set

work-dir

to where your Pulumi code lives •

command: up | preview

If you export outputs from the stack these can then be referenced in consecutive workflow steps - assuming your pulumi step has the

id: pulumi

and you have a stack output named

registry_endpoint

${{ steps.pulumi.outputs.registry_endpoint }}"

And if you install the Pulumi GitHub App you will get automatic comments on your pull requests with the results of a pulumi action.

Thanks alot I will try and get back to you when required