Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
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.
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.
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.