Nesta página, apresentamos uma visão geral de como implantar apps .NET no Google Cloud e orientações sobre como escolher a abordagem de implantação correta para seu app.
Introdução
O Microsoft .NET Framework oferece um conjunto avançado de ferramentas e bibliotecas para desenvolvimento de aplicativos. Com o suporte para Docker no Windows e a capacidade de executar aplicativos .NET no Linux, os apps .NET agora também podem oferecer suporte a vários destinos de implantação.
Para que o desenvolvimento e os testes sejam eficientes, você precisa automatizar a implantação de aplicativos e torná-la parte de um pipeline de integração contínua e entrega contínua (CI/CD). Mas, para escolher as ferramentas certas e criar um canal de CI/CD, é necessário primeiro identificar como será executado o aplicativo em produção e qual abordagem de implantação será usada.
Não há uma única maneira que seja a melhor para implantar um aplicativo .NET no Google Cloud. As melhores opções de implantação dependem do app e das suas necessidades. Por exemplo, caso seu aplicativo exija o .NET Framework completo ou precisar ser executado no IIS, sua implantação será baseada no Windows. Por outro lado, se o aplicativo puder ser executado com a funcionalidade compatível com o .NET, você terá a opção de implantar no Linux.
Nesta página, analisamos as várias maneiras de executar apps .NET e implantá-los no Google Cloud, incluindo as condições em que cada opção se adequa melhor. No final, as opções de implantação são resumidas em uma árvore de decisão para ajudar você a definir quais componentes e abordagens do Google Cloud Google Cloud são mais apropriadas para seu app .NET.
Modelos de implantação
Há duas maneiras básicas de realizar a implantação automatizada de um app. O pacote de implantação pode ser enviado (push) para os servidores de apps ou os servidores podem extrair (pull) o pacote do aplicativo de um local conhecido. As próximas seções tratam das diferenças entre esses dois modelos.
Implantações baseadas em push
Em uma implantação baseada em push, o artefato de implantação, um arquivo zip, um pacote NuGet ou outro artefato, está disponível inicialmente apenas para um servidor de implantação. O servidor de implantação pode ser uma máquina dedicada ou uma função que o sistema de CI presume.
Para executar uma implantação, um processo no servidor de implantação se conecta a um servidor de aplicativos, copia o artefato e inicia a instalação. Se houver mais de um servidor de aplicativos, esse processo será repetido em paralelo ou, da maneira mais comum, em sequência, para que os artefatos sejam implantados em todos os servidores de aplicativos.
Veja esse fluxo no diagrama a seguir.
Há várias ferramentas de gerenciamento de configuração disponíveis que permitem automatizar implantações dessa maneira. Algumas dessas ferramentas seguem uma abordagem imperativa, em que a sequência de etapas de implantação é definida de maneira semelhante a um script. Essa abordagem é intuitiva, mas está propensa a desvios de configuração, ou seja, após um determinado período os estados de várias máquinas podem não ser idênticos nem refletir totalmente o estado pretendido. Por isso, muitas ferramentas permitem definir o estado que você quer. Dessa maneira, elas podem descobrir as etapas necessárias para alcançar esse estado.
No Windows, as ferramentas mais usadas para esse modelo de implantação incluem:
- Implantação na Web da Microsoft, ferramenta sem custo financeiro criada para implantar remotamente os aplicativos da Web em servidores IIS;
- Octopus Deploy, software comercial que permite a orquestração flexível de implantações entre as frotas de máquinas;
- Agentes do Microsoft Team Foundation Server ou do Azure Pipelines, que se integram diretamente com a funcionalidade de gerenciamento de versão do TFS ou do Azure Pipelines.
- Configuração de estado desejado (DSC, na sigla em inglês) do Windows PowerShell, um recurso integrado do Windows Server 2012 R2 e versões posteriores.
Algumas ferramentas conhecidas de código aberto são Ansible,