Partilhar via


Implantando eShopOnContainers no Azure

Sugestão

Este conteúdo é um excerto do eBook Architecting Cloud Native .NET Applications for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.

miniatura da capa dos aplicativos .NET nativos da nuvem para eBook do Azure.

O aplicativo eShopOnContainers pode ser implantado em várias plataformas do Azure. A abordagem recomendada é implantar o aplicativo no Azure Kubernetes Services (AKS). O Helm, uma ferramenta de implantação do Kubernetes, está disponível para reduzir a complexidade da implantação. Opcionalmente, os desenvolvedores podem implementar o Azure Dev Spaces for Kubernetes para simplificar seu processo de desenvolvimento.

Serviço Kubernetes do Azure

Para hospedar a eShop no AKS, o primeiro passo é criar um cluster AKS. Para fazer isso, você pode usar o portal do Azure, que o orientará pelas etapas necessárias. Você também pode criar um cluster a partir da CLI do Azure, tomando cuidado para habilitar o RBAC (Controle de Acesso Role-Based) e o roteamento de aplicativos. A documentação do eShopOnContainers detalha as etapas para criar seu próprio cluster AKS. Uma vez criado, você pode acessar e gerenciar o cluster a partir do painel do Kubernetes.

Agora você pode implantar o aplicativo eShop no cluster usando o Helm.

Implantando no Serviço Kubernetes do Azure usando o Helm

Helm é uma ferramenta de gerenciamento de pacotes de aplicativos que trabalha diretamente com o Kubernetes. Ele ajuda você a definir, instalar e atualizar aplicativos Kubernetes. Enquanto aplicativos simples podem ser implantados no AKS com scripts CLI personalizados ou arquivos de implantação simples, aplicativos complexos podem conter muitos objetos Kubernetes e se beneficiar do Helm.

Usando o Helm, os aplicativos incluem arquivos de configuração baseados em texto, chamados gráficos Helm, que descrevem declarativamente o aplicativo e a configuração nos pacotes Helm. Os gráficos usam arquivos padrão formatados em YAML para descrever um conjunto relacionado de recursos do Kubernetes. Eles são versionados juntamente com o código da aplicação que descrevem. Os Helm Charts variam de simples a complexos, dependendo dos requisitos da instalação descritos.

O Helm é composto por uma ferramenta de linha de comando de cliente, que consome charts do Helm e inicia comandos para um componente de servidor chamado Tiller. O Tiller se comunica com a API do Kubernetes para garantir o provisionamento correto de suas cargas de trabalho conteinerizadas. O Helm é mantido pela Cloud-native Computing Foundation.

O seguinte arquivo yaml apresenta um modelo Helm:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.app.svc.marketing }}
  labels:
    app: {{ template "marketing-api.name" . }}
    chart: {{ template "marketing-api.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app: {{ template "marketing-api.name" . }}
    release: {{ .Release.Name }}

Observe como o modelo descreve um conjunto dinâmico de pares chave/valor. Quando o modelo é invocado, os valores incluídos em chaves são retirados de outros arquivos de configuração baseados em YAML.

Você encontrará os gráficos de leme eShopOnContainers na pasta /k8s/helm. A Figura 2-6 mostra como os diferentes componentes da aplicação são organizados em uma estrutura de diretórios usada pelo helm para definir e gerir implementações.

A pasta de leme eShopOnContainers Figura 2-6. A pasta Helm do eShopOnContainers.

Cada componente individual é instalado usando um helm install comando. O eShop inclui um script "deploy all" que percorre e instala os componentes usando os seus respetivos Helm charts. O resultado é um processo repetível, versionado com o aplicativo no controle do código-fonte, que qualquer pessoa da equipe pode implantar em um cluster AKS com um comando de script de uma linha.

Observação

A versão 3 do Helm elimina oficialmente a necessidade do componente de servidor Tiller. Para obter mais informações sobre esta melhoria, consulte Por que o Tiller está faltando no Helm 3?.

Azure Functions e Logic Apps (sem servidor)

O exemplo eShopOnContainers inclui suporte para rastrear campanhas de marketing on-line. Uma Função do Azure é usada para rastrear detalhes da campanha de marketing para uma determinada ID de campanha. Em vez de criar um microsserviço completo, uma única Função do Azure é mais simples e suficiente. O Azure Functions tem um modelo de compilação e implantação simples, especialmente quando configurado para ser executado no Kubernetes. A implantação da função é executada por script usando modelos do Azure Resource Manager (ARM) e a CLI do Azure. Este serviço de campanha não é voltado para o cliente e invoca uma única operação, tornando-o um ótimo candidato para o Azure Functions. A função requer configuração mínima, incluindo dados de cadeia de conexão de banco de dados e configurações de URI de base de imagem. Você configura o Azure Functions no portal do Azure.