Crie um novo projeto ASP.NET Core Web API
Nomeie o projeto e coloque-o dentro da pasta raiz do repositório do Github.
Selecione a versão do .net.
Aqui vale uma observação, a versão que você usar do .net vai influenciar como o arquivo dockerfile deverá ser configurado, se quiser escolher outra versão, fique à vontade, mas será necessário adaptar o dockerfile.
Selecione a opção webapi para execução.
Execute o projeto, faça um GET no /weatherforecast apenas para validar que está tudo funcionando.
Vamos às adaptações necessárias no Program.cs
Program.cs
Faça as alterações necessárias no seu Program.cs para ficar como o do código abaixo:
using System;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Hosting;
namespace webapi
{
public class Program
{
public static void Main(string[] args)
{
CreateHostBuilder(args).Build().Run();
}
public static IHostBuilder CreateHostBuilder(string[] args)
{
var port = Environment.GetEnvironmentVariable("PORT") ?? "8080";
var environment = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Development";
if (environment == "Development")
{
return Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); });
}
else
{
var url = new[]
{
string.Concat("http://0.0.0.0:", port)
};
return Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>().UseUrls(url); });
}
}
}
}
No código é importante notar o bloco do else, nele estamos dizendo que quando o ambiente não for "Development" a aplicação deverá subir usando o IP 0.0.0.0, isso é necessário para que a aplicação fique visível fora do container quando publicarmos no Cloud Run.
Dockerfile
Crie o Dockerfile na raiz do repositório. Verifique se o seu projeto também está na raiz do repositório, se não tiver, mude para a raiz.
Preencha seu dockerfile com o código abaixo:
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build-env
WORKDIR /app
COPY . ./
RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /app
COPY --from=build-env /app/out .
ENV ASPNETCORE_ENVIRONMENT Production
ENTRYPOINT ["dotnet", "webapi.dll"]
Importante alterar a última linha, o nome do arquivo .dll deve ser exatamente igual à DLL principal do seu projeto.
Se seu projeto tiver uma estrutura de pastas diferente do meu, talvez precise alterar outros pontos do dockerfile.
Salve tudo e faça commit.
Cloud Run no GCP
Se desejar, crie um projeto novo.
Pesquise por cloud run na barra de pesquisa no meio da barra do topo. Abra o produto Cloud Run. Crie um novo serviço.
Se você criou um projeto novo ou é a primeira vez que está usando o Cloud Build, talvez precise ativar o Cloud Build API.
Selecione Continuously deploy new revisions from a source repository e clique em Setup With Cluod Build
Importante: eu já tinha minha conta do Github conectada ao GCP, portanto, não consegui tirar prints dessa etapa, mas se for a primeira vez sua, você terá que vincular a sua conta do Github com o GCP.
Selecione o projeto que você quer publicar.
Avance para segunda etapa e marque a opção Dockerfile. No campo Branch deixe o valor padrão ^main$ para que o Cloud Build seja acionado apenas quando houver commit na branch main do seu repositório, se quiser outra branch, fique à vontade.
Preencha o Service name, eu deixei o valor padrão. Escolha uma região, para exemplo deixei a padrão.
Na opção de Autoscaling deixei a quantidade mínima de instâncias como zero, isso aumenta o tempo de resposta a um request, mas reduz custos, que no meu caso é mais importante. Se você quiser reduzir o tempo de resposta da sua aplicação deixe pelo menos 1 no mínimo e faça ajustes de acordo com a sua volumetria.
Assim como o mínimo, deixei o máximo em 1 instância, porque novamente o mais importante para mim não é performance e sim custo. Se quiser melhorar a performance avalie aumentar o limite máximo de instâncias, mas lembre-se que isso gerará custos.
Por último, é preciso selecionar as configurações de Ingress e Authentication, para fins educativos deixei aberto para Allow all traffic e Allow unauthenticated invocations. Para aplicações em produção considere buscar mais informações para restringir o tráfego e as requisições sem autenticação.
Opcional: Abra o menu Container, Connections, Security e faça ajustes no seu container em relação à memória, timeout, requests máximos por container.
Para o deploy automático essas configurações são irrelevantes e você poderá alterá-las no futuro.
Crie seu serviço e aguarde.
Quando estiver concluído se tudo deu certo ficará como o da imagem abaixo.
O quadro em destaque na imagem acima é a URL pública gerada pelo GCP, com ela é possível acessar nossa API no endpoint /weatherforecast.
URL: https://democsharpgcpcloudrun-lwy2plkqfa-uc.a.run.app/weatherforecast
Conclusão
A partir de agora todo novo commit na main do seu repositório Github será publicado no Cloud Run
O Cloud Run tem um recurso chamado Revisões, com ele é possível fazer rollback caso uma nova versão quebre algum aspecto da sua API.
Além de permitir que você gerencie o tráfego entre duas ou mais versões, podendo fazer deploy canário. Infelizmente, até o momento não consegui configurar um deploy canário automático, se você souber como faz, coloca nos comentário, por favor.
Obrigado por ter ficado até o fim.
Oldest comments (0)