Prepara-se para implantar a carga de trabalho de EDW (fluxo de trabalho controlado orientado a eventos) no Azure

O exemplo de carga de trabalho do AWS é implantado usando Bash, CloudFormation e CLI do AWS. O aplicativo consumidor em Python é implantado como um contêiner. As próximas seções descrevem como o fluxo de trabalho no Azure é diferente. Existem alterações nos scripts Bash usados para implantar o cluster do AKS (Serviço de Kubernetes do Azure) e a infraestrutura de apoio. Além disso, os manifestos de implantação do Kubernetes são modificados para configurar o KEDA e usar um escalador da Fila de Armazenamento do Microsoft Azure no lugar do escalador do SQS (Amazon Simple Queue Service).

O fluxo de trabalho do Azure utiliza o recurso de Autoprovisionamento de nós do AKS (NAP), que se baseia no Karpenter. Esse recurso simplifica muito a implantação e o uso do Karpenter no AKS, eliminando a necessidade de usar o Helm para implantar o Karpenter explicitamente. Contudo, se você precisar implantar o Karpenter diretamente, isso pode ser feito utilizando o provedor Karpenter do AKS no GitHub.

Configurar o manifesto de implantação do Kubernetes

O AWS usa um manifesto YAML de implantação do Kubernetes para implantar a carga de trabalho no EKS. O YAML de implantação do AWS contém referências ao SQS e DynamoDB para os escaladores do KEDA, então precisamos alterá-los para especificar valores equivalentes do KEDA para os escaladores do Azure se conectarem à infraestrutura do Azure. Para isso, configure o Escalador KEDA da Fila de Armazenamento do Microsoft Azure.

Os trechos de código a seguir mostram exemplos de manifestos YAML para as implementações do AWS e do Azure.

Implementação do AWS

    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: <sqs app name>
        image: <name of Python app container>
        imagePullPolicy: Always
        env:
        - name: SQS_QUEUE_URL
          value: https://<Url To SQS>/<region>/<QueueName>.fifo
        - name: DYNAMODB_TABLE
          value: <table name>
        - name: AWS_REGION
          value: <region>

Implementação no Azure

    spec:
      serviceAccountName: $SERVICE_ACCOUNT
      containers:
      - name: keda-queue-reader
        image: ${AZURE_CONTAINER_REGISTRY_NAME}.azurecr.io/aws2azure/aqs-consumer
        imagePullPolicy: Always
        env:
        - name: AZURE_QUEUE_NAME
          value: $AZURE_QUEUE_NAME
        - name: AZURE_STORAGE_ACCOUNT_NAME
          value: $AZURE_STORAGE_ACCOUNT_NAME
        - name: AZURE_TABLE_NAME
          value: $AZURE_TABLE_NAME

Definir variáveis de ambiente

Antes de executar qualquer uma das etapas de implantação, você precisa definir algumas informações de configuração usando as variáveis de ambiente a seguir:

• K8sversion: a versão do Kubernetes implantada no cluster do AKS.
• KARPENTER_VERSION: a versão do Karpenter implantada no cluster do AKS.
• SERVICE_ACCOUNT: o nome da conta de serviço associada à identidade gerenciada.
• AQS_TARGET_DEPLOYMENT: o nome da implantação do contêiner de aplicativo consumidor.
• AQS_TARGET_NAMESPACE: o namespace onde o aplicativo consumidor é implantado.
• AZURE_QUEUE_NAME: o nome da Fila de Armazenamento do Microsoft Azure.
• AZURE_TABLE_NAME: o nome da Tabela do Armazenamento do Microsoft Azure que armazena as mensagens processadas.
• LOCAL_NAME: uma raiz simples para os nomes de recursos construídos nos scripts de implantação.
• LOCATION: a região do Azure onde a implantação está localizada.
• TAGS: todas as marcas definidas pelo usuário e seus valores associados.
• STORAGE_ACCOUNT_SKU: o SKU da Conta de Armazenamento do Microsoft Azure.
• ACR_SKU: o SKU do Registro de Contêiner do Azure.
• AKS_NODE_COUNT: o número de nós.

Você pode revisar o script Bash environmentVariables.sh no diretório deployment do nosso repositório GitHub. Essas variáveis de ambiente possuem valores padrão definidos, então não é necessário atualizar o arquivo a menos que você deseje alterar os padrões. Os nomes dos recursos do Azure são criados dinamicamente no script deploy.she são salvos no arquivo deploy.state. Você pode usar o arquivo deploy.state para criar variáveis de ambiente para os nomes dos recursos do Azure.

Próximas etapas

Colaboradores

A Microsoft atualiza este artigo. Os seguintes colaboradores o escreveram originalmente:

• Ken Kilty | Principal TPM
• Russell de Pina | Diretor de TPM
• Jenny Hayes | Desenvolvedora sênior de conteúdo
• Carol Smith | Desenvolvedora sênior de conteúdo
• Erin Schaffer | Desenvolvedora de Conteúdo 2