getporter / az-mixin Goto Github PK

https://github.com/deislabs/porter-az/blob/main/pkg/az/schema/schema.json

I just saw @squillace 's hack to ensure that a resource group exists. Let's improve the mixin so that this doesn't require dropping into the exec mixin.

It's important that mixins should gracefully handle resources that already exist (during install) or conversely resources that have already been deleted (during uninstall).

Ralph, can you provide the command that you wanted to run with the mixin and also the bash hack?

@mikkelhegn was trying to us a repeating flag for an az-mixin command and ran in to the problem of the corresponding az command not accepting multiple parameters of the same name (basically only taking the last into account).

Here’s his setup:

Porter.yaml snippet:

  - az:
      description: 'Deploy Web API configurations'
      arguments:
        - webapp
        - config
        - appsettings
        - set
      flags:
        ids: '{{ bundle.outputs.WEBAPI_ID }}'
        settings:
        - 'PGHOST={{ bundle.outputs.POSTGRES_HOST }}'
        - 'PGUSER={{ bundle.outputs.POSTGRES_USER }}'
        - 'PGPASSWORD={{ bundle.outputs.POSTGRES_PASSWORD }}'
        - 'PGDB={{ bundle.outputs.POSTGRES_DB }}'

The generated ‘az’ command – according to debug output:

az webapp config appsettings set --ids /subscriptions//resourceGroups/MyRG/providers/Microsoft.Web/sites/webapi-b2g2ndukr2eqy --output json --settings PGHOST= --settings PGUSER=******* --settings PGPASSWORD=******* --settings PGDB=*******

This results in only the last --settings argument is being stored by the RP. Now is it a “wrong” mixin or az implementation?

(For a second let’s disregard that the command takes a json-file as an input for a collection of settings as an alternative)

Reading through this, I tend to be of the opinion, that there could be a better az command implementation: https://github.com/Azure/azure-cli/blob/dev/doc/command_guidelines.md#collection-management-with-commands

e.g.

webapp config appsettings setting set --ids xxxxx --setting-name PSUSER --setting-value *****

webapp config appsettings setting set --ids xxxxx --file settings.json

The implementation which the mixin assumes, is not the recommended implementation, however it’s acceptable ☺: https://github.com/Azure/azure-cli/blob/dev/doc/command_guidelines.md#collection-management-with-actions

Two questions:

Do you agree it’s right to raise the issue towards the command owner to get the command fixed?
Should the az mixin support repeatable flags, if it’s an anti-pattern in az?

Bicep is not an extension to az but should be installed with az bicep install.

How can we configure the az mixin to have Bicep available?

In my example I was not specifying the jsonPath using correct case (I used jsonpath as opposed to jsonPath):

      outputs:
        - name: "WEBAPI_ID"
          jsonpath: "$.properties.outputs.webapi_id.value"

This resulted in the mixin to run without an error, but not picking up the output.

I think the desired outcome should be an error on parsing porter.yaml while running the mixin. Thoughts?

Logging in is a pain right now. You have to specify it for each action, and pass in a bunch of flags and remember to suppress output:

- az: 
      description: "Logging into Azure..."  
      arguments:
        - login
      flags:
        service-principal: ""
        username: "'{{bundle.credentials.AZURE_CLIENT_ID}}'"
        password: "'{{bundle.credentials.AZURE_CLIENT_SECRET}}'"
        tenant: "'{{bundle.credentials.AZURE_TENANT_ID}}'"
      suppress-output: true

We could add a custom login command to the mixin to simplify the default login, which assumes the default environment variable names:

install:
- az:
     login:

In addition, we could have the mixin detect if we are logged in (a file gets stored in ~/.azure after login) before running a command and then automatically logging in if needed.

I discovered (presumably) why my porter install was failing on my M1 Mac; it looks like the AZ CLI mixin Dockerfile scaffolding assumes an amd64 architecture. The bundle is successfully created, but then the az commands fail, being unable to find the amd64 Linux libraries it expects in the container.

az login --output table --output json --password ******* --service-principal --tenant ******* --username *******
/lib64/ld-linux-x86-64.so.2: No such file or directory
Error: error running command az login --output table --output json --password ******* --service-principal --tenant ******* --username *******: exit status 255

When a bundle includes the azure mixin, set the user agent environment variable AZURE_HTTP_USER_AGENT so that whether or not use you the az mixin to run a az command, the user agent reflects that it is az cli + porter.

This will enable us to understand how many people are using the az mixin in their bundles, even if they need to use plain bash scripts at times. It also helps us understand what version of porter and the mixin they are on.

Ref #13 for functionality and getporter/porter#963 for docs

We are using forks of the azure blob storage library because it didn't support tags. They have now released v0.11.0 that has what we need to work with tags. We should try it out and get off the fork.

We will need to keep the existing code that waits for the tag to be set and validate this with some manual tests against Azure.

It would really help us improve the az mixin if we can correlate logs in azure back to porter usage, i.e. we know that porter helped a user create a resource with the az cli. If we set the AZURE_HTTP_USER_AGENT environment variable in the az mixin then the az cli will use that for its user agent string.

See https://mikhail.io/2019/07/how-azure-cli-manages-access-tokens/ for where azure puts the goods after az login. We can make the ~/.azure/* dir one of the credentials, instead of passing in a service principal and then that inside the bundle to allow az to authenticate without requiring people to run az login manually in each action.

Note that the bundle consumer would need to run az login before executing the bundle. Long term plugins could have a hook before bundles run to help out with stuff like that.

It is up to the bundle author if they prefer that style of credential over service principals.

The mixin schema appears to be out-of-date, most noticeably see its lack of suppress-output field support: #17