Perguntas[google-cloud-platform](server)

Estou implantando um webapp de painel simples em python. Tudo sobre a implantação é mais ou menos idêntico às implantações anteriores, que funcionaram. (Mesmo YAML, mesmo código de autenticação, etc.)

Entretanto, quando implanto este próximo aplicativo, o Google Cloud CLI gera o erro acima gcloud app create.

ERROR: (gcloud.app.create) INVALID_ARGUMENT: The project must have a billing account attached

Não consegui encontrar uma solução em vários fóruns, além de "esperar e tentar mais tarde". Supostamente isso funciona. Mas ainda estou curioso para saber por que esse erro ocorre / algum conselho mais experiente.

Estou passando pelo Security Command Center no Google Cloud e tenho a seguinte descoberta de segurança:

• Nome: ORG_POLICY_LOCATION_RESTRICTION
• Descrição: O recurso está fora dos locais definidos na política de Restrição de Localização de Recursos
• Nome de exibição do recurso: padrão
• Nome completo do recurso: //compute.googleapis.com/projects/MYPROJECT/regions/us-east5/subnetworks/default
• Tipo de recurso: google.compute.Subnetwork

Próximos passos

Visite esta página do Google Cloud Platform que ajudará você a resolver a violação de localização que está afetando o recurso padrão google.compute.Subnetwork.

Exclua este recurso para resolver a violação de recurso associada à política da organização 'gcp.resourceLocations'.

Eliminação

Quando vou lá VPC networksvejo muitas defaultredes, mas elas não podem ser excluídas.

Como posso excluí-los?

Estou implantando um contêiner em uma instância COS (Container OS). Muito simples.

Quero que ele reinicie diariamente. Qual é a melhor maneira de fazer isso? Uma simples aba CRON que eu poderia configurar na VM? O problema com isso é que precisará ser refeito sempre que a VM for reimplantada.

Seguindo os documentos disponíveis do GCP aqui: https://cloud.google.com/artifact-registry/docs/repositories/cleanup-policy

Configurei a política de limpeza no meu repositório de artefatos com a opção de execução a seco habilitada, mas não consegui gerar nenhum log de auditoria usando o comando.

gcloud logging read 'protoPayload.serviceName="artifactregistry.googleapis.com" AND protoPayload.request.parent:"projects/gift-service-app-jm/locations/australia-southeast1/repositories/gcf-artifacts" AND protoPayload.request.validateOnly=true' \
    --resource-names="projects/gift-service-app-jm" \
    --project=gift-service-app-jm

Consegui confirmar que a política foi definida e a opção de execução a seco está habilitada usando o gcloud artifacts repositories describe gcf-artifactscomando

{
  "cleanupPolicies": {
    "Delete Previous Versions": {
      "action": "DELETE",
      "condition": {
        "olderThan": "864000s",
        "tagState": "UNTAGGED"
      },
      "id": "Delete Previous Versions"
    }
  },
  "cleanupPolicyDryRun": true,
  "createTime": "2023-09-27T05:07:31.256470Z",
  "description": "This repository is created and used by Cloud Functions",
  "format": "DOCKER",
  "labels": {
    "goog-managed-by": "cloudfunctions"
  },
  "mode": "STANDARD_REPOSITORY",
  "name": "projects/gift-service-app-jm/locations/australia-southeast1/repositories/gcf-artifacts",
  "updateTime": "2024-07-10T05:39:56.088672Z"
}

Alguém já teve esse problema antes? Eu apliquei a função de proprietário ao meu principal do IAM, mas também tentei adicionar as funções de visualizador de logs e visualizador de logs privados explicitamente.

Eu tenho um modelo de instância do Google Cloud Compute Engine com um script de inicialização.

No script de inicialização o servidor gera um certificado. Após gerar o certificado ele envia uma mensagem para uma API para informar um sistema central sobre o certificado. A solicitação fica assim:

curl --location 'https://my-side.com/hello?hostname=$hostname' \
    --header 'Authorization: SUPER_SECRET_API_KEY'

A chave de API é armazenada como texto bruto no script de inicialização. Está tudo bem ou deveria ser movido para um armazenamento secreto de exemplo? Em caso afirmativo, como posso ler a chave da API no script de inicialização?

Meu cluster Kubernetes em execução no piloto automático do GKE tem um nó não íntegro. O nó tem um Readystatus, mas todos os pods em execução nele têm um CreateContainerErrorstatus e parecem estar travados na pesquisa de imagens de contêiner.

Exemplo:

(Normal puxado 101s (x1326 acima de 4h49m) imagem do contêiner kubelet "gke.gcr.io/cluster-proportional-autoscaler:v1.8.10-gke.3@sha256:274afbfd520aef0933f1fefabddbb33144700982965f9e3632caabb055e912c6" já presente na máquina).

Algo deu errado em uma atualização do Kubernetes porque minha conta ficou sem cota (aparentemente 1 TB de armazenamento computacional não é suficiente para um cluster pequeno). Consegui mais cota, mas o cluster do piloto automático não se repara sozinho.

Eu "cordonei" o nó para marcá-lo como não programável e excluí manualmente meus pods dele. Novos pods foram agendados em nós mais saudáveis, então não é tão ruim.

Agora quero fazer uma limpeza. Os pods antigos ficaram presos no Terminatingestado, mas a exclusão forçada deles os fez desaparecer.

Não posso fazer o mesmo nos namespaces kube-systemand gke-gmp-system. Vejo os pods "gerenciados" com um CreateContainerErrorstatus e eles estão extraindo imagens de contêiner em um loop. A pessoa também está presa a um Terminatingstatus.

Eu gostaria de remover esse nó, e aparentemente você precisa drenar o nó e ignorar os erros no kube-systemnamespace . Eu drenei o nó, mas ele ainda está lá.

Como eu poderia remover o nó não íntegro?

Estou clonando vários repositórios (usando git clone) dentro do meu trabalho do Google Cloud Run e um deles faz o Google Cloud encerrar o contêiner com a saída 1. Veja o log:

    {
      insertId: "xxx",
      labels: {
        instanceId: "xxx"
        run.googleapis.com/execution_name: "xxx",
        run.googleapis.com/task_attempt: "0",
        run.googleapis.com/task_index: "0"
      },
      logName: "xxx/run.googleapis.com%2Fstderr",
      receiveTimestamp: "2024-03-13T09:05:28.686787232Z",
      resource: {
        labels: {
          job_name: "xxx",
          location: "xxx",
          project_id: "xxx"
        },
        type: "cloud_run_job"
      },
      textPayload: "Killed",
      timestamp: "2024-03-13T09:05:28.685133Z"
    }

O repositório clonado possui 10.828 arquivos e seu tamanho é de 1,8 GB. O uso de memória e CPU não excedeu 50%. Acontece durante .git clone [email protected]:usr/bad_repo.git

Presumo que esteja relacionado a um limite, mas não encontrei nada.

Passos para reproduzir:

1. Crie um contêiner Docker com um script Bash que clone um repositório como este:

git clone -q --depth 1 --no-tags --filter=blob:limit=100k [email protected]:supabase/supabase.git

2. Execute este contêiner do Docker como um job do Cloud Run
3. O contêiner será encerrado com o código de status 1 acionado pelo Cloud Run

Todos os registros:

Esta é a primeira vez que estou implantando no Google App Engine [ou, pelo menos, tentando]. Eu construí um aplicativo Java Spring Boot, configurei app.yamle executei as outras etapas de preparação. Porém, quando executo gcloud app deploy, recebo a seguinte mensagem de erro:

ERROR: (gcloud.app.deploy) Error Response: [4] Timed out fetching pod.

Estou tentando implantar no ambiente padrão. O erro ocorre por volta dos 5 minutos da Updating service [default]etapa. Pelo que posso dizer pelos registros, a construção foi um sucesso. Não consegui encontrar muitas informações sobre esse erro específico na web.

app.yaml (/src/main/appengine/app.yaml)

runtime: java11

env: standard

instance_class: B1

basic_scaling:
  max_instances: 1

env_variables:
  PROFILE: "prod"
  TWILIO_SID: 0
  TWILIO_KEY: 0
  TWILIO_PHONE_FROM: 0
  TWILIO_PHONE_TO: 0

Estou esquecendo de algo? O que eu poderia verificar?

Eu tenho um aplicativo da web MVC .net core 6 que usa a autenticação OAuth2.0 do Google e não consigo publicá-lo com o Kubernetes.

Contexto do projeto:

Localmente ele compila e roda normalmente, inclusive criando uma imagem docker e executando um container, mas para rodar o container docker localmente e ter uma porta https com um certificado válido (preciso disso para o OAuth do Google funcionar) preciso executar o seguinte procedimento .

Sequência de comandos e procedimentos para tornar o certificado local confiável (você só precisa fazer isso para executar em um contêiner docker, não é necessário executar o projeto diretamente):

1. crie o certificado local pfx: dotnet dev-certs https -ep $env:USERPROFILE\.aspnet\https\Apresentacao.Web.pfx -p pa55w0rd!

2. Crie uma linha de configuração UserScretsId no .csproj do aplicativo: {SomeGuidIdHere}

3. Digite a senha do certificado no local user-secrets: dotnet user-secrets set "Kestrel:Certificates:Development:Password" "pa55w0rd!"

4. tornar o certificado 'confiável' dotnet dev-certs https --trust

5. Execute o contêiner docker, mas passando por alguns parâmetros necessários (execute no powershell ou bash fora da pasta do projeto):

docker run -p 8080:80 -p 8081:443 -e ASPNETCORE\_URLS="https://+;http://+" -e ASPNETCORE\_HTTPS\_PORT="8081" -e ASPNETCORE\_ENVIRONMENT=Development - v $env:APPDATA\microsoft\UserSecrets\\:/root/.microsoft/usersecrets -v $env:USERPROFILE\\.aspnet\https:/root/.aspnet/https/ admin

Se eu não realizar o procedimento acima, ou executar 'Docker run' sem passar os parâmetros necessários para utilizar a porta https e o certificado, recebo o seguinte retorno ao executar o container:

warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3] Failed to determine the https port for redirect.

Meu problema é: Localmente encontrei a solução para lidar com o contêiner docker, a porta https e o certificado SSL para localhost, porém estou publicando esta mesma aplicação no Google Cloud usando ações do Git Hub para executar meu pipeline de implantação e na nuvem eu estou salvando a janela de encaixe de imagens em um balde e criando um serviço com kubernetes. Já temos outras aplicações rodando nesta infraestrutura de nuvem do Google com Kubernetes e não tivemos problemas em expor as URLs com o Ingress e usar o certificado fornecido pelo Google.

Fiz vários testes publicando com configurações diferentes até suspeitar que poderia ser algo na aplicação, resolvi fazer um teste publicando sem a configuração de autenticação do Google e para minha surpresa a aplicação estava com status de saúde no Kubernetes e foi disponibilizada na URL com https corretamente. Quando incluo novamente a autenticação com Google no Startup.cs do projeto, meu problema retorna no container Kuberntes e ao acessar a URL o retorno que obtenho é um 502.

Veja como estou configurando a autenticação com o Google: Em Startup.cs

Método ConfigureServices:

public void ConfigureServices(IServiceCollection services)
        {
            //Auth config google
            services.AddAuthentication(options =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = GoogleDefaults.AuthenticationScheme;
            })
            .AddCookie()
            .AddGoogle(options =>
            {
                options.ClientId = "{my_ClientId}";
                options.ClientSecret = "{my_ClientSecret}";
            });
            ...
}

Método de configuração:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Home/PaginaNaoEncontrada");
                app.UseHsts();
            }
            app.Use(async (context, next) =>
            {
                await next();
                if (context.Response.StatusCode == 404)
                {
                    context.Request.Path = "/Home/PaginaNaoEncontrada";
                    await next();
                }
            });
            app.UseHttpsRedirection();

            app.UseStaticFiles(new StaticFileOptions
            {
                OnPrepareResponse = o => { o.Context.Response.Headers.Append("Cache-Control", $"public, max-age=10800"); }
            });
            app.UseUnobtrusiveAjax();
            app.UseRouting();
            app.UseAuthorization();
            app.UseAuthentication();            //Important  
}

No meu HomeController.cs (onde bate minha primeira requisição ao acessar a aplicação pela primeira vez e onde eu valido que o Usuário está autenticado) a anotação [Autorizar] acima do Controlador é estritamente necessária para que o que adicionei no Startup funcione .cs :

[Authorize]
public class HomeController : Controller
{ ...}

Minha ação para o índice inicial:

[HttpGet]
return View();

LoginGoogle chamado por Index:

public ActionResult LoginGoogle(){
    return Challenge(new AuthenticationProperties { RedirectUri = "/" }, "Google");}

Para publicar no Kubernetes tenho os seguintes arquivos (destaco três deles porque considero que neles estão as configurações mais importantes para o site):

Meu deploymet é assim:

apiVersion: apps/v1

Meu Ingress é assim:

apiVersion: networking.k8s.io/v1

E meu serviço é assim:

apiVersion: v1

Com as alterações recentes que fiz em meus arquivos .yaml para Kubernetes, comecei a receber mais logs do serviço, semelhante ao que receberia localmente se executasse o comando 'Docker run' sem parâmetros para usar o certificado local: Últimos logs do contêiner: https://drive.google.com/file/d/1VcmiBe0LBuMr5B0VC5YivrvZdygZtEf5/view?usp=drive_link

Antes dessas alterações (principalmente no arquivo de implantação) eu estava recebendo o seguinte retorno nos logs: Logs anteriores: https://drive.google.com/file/d/16NoN1fhhmoGk2bZRWTY0oxqFBY3xH4Kj/view?usp=drive_link

Abaixo dos logs ilustrados acima havia apenas um loop infinito de informações sobre ResponseCoockies e as informações sobre a porta https não eram repetidas até que uma nova implantação fosse feita.

Como o serviço responde ao acessar a URL quando publicamos COM autenticação Google configurada: https://drive.google.com/file/d/1jDCmZNFPvzRvnq2VeOr7yC79A9Cba1rf/view?usp=drive_link

Minha pergunta é se estou configurando o Kubernetes ou falta algo para que o certificado seja confiável? Por que a implantação acontece normalmente quando removo a configuração de autenticação do Google do meu aplicativo? (Eu removo a configuração de inicialização e a anotação do controlador)

É importante observar que minhas credenciais de ID do cliente OAuth estão corretas, pois pude testar adicionando a URL https localhost como autorizada, portanto, esse também não seria o problema. Adicionei a URL que estou provisionando no Kubernetes na lista de URLs autorizadas a usar o Client Id OAuth, conforme segue: https://drive.google.com/file/d/1Hzi74jJ6sZ7za5D3rFZcyDQRaIoW4jOS/view?usp=drive_link

Outra informação.

Uma captura de tela de quando publico o aplicativo sem configuração de autenticação do Google e ele permanece ATIVO e o certificado parece estar vinculado ao URL e seguro:

https://drive.google.com/file/d/1RLocACa-TaCsmZo1S74sQoKrzvFgcfyx/view?usp=drive_link

Ao implantar com Ingress.yaml, ele cria um equilíbrio de carga na infraestrutura e configura automaticamente um endpoint front-end vinculado a um IP estático:

https://drive.google.com/file/d/1f1LyIzcDqUbEUEpPTh6VQqdwyshMeUVA/view?usp=drive_link

Utilizamos o serviço AWS para adquirir e hospedar domínios e para que ao acessar a URL que configurei meu DNS fosse resolvido para o IP do meu front end, configurei um 'Nome do registro' para ser redirecionado para o IP. Isso já foi feito para outras aplicações e funcionou, funciona até quando publicamos essa aplicação sem autenticação...

Abaixo está o cadastro que fiz na zona de hospedagem AWS: https://drive.google.com/file/d/1y8BIeK7RYywP95jPzpCGYkgZ7Lv-w7KG/view?usp=drive_link

E os detalhes do certificado fornecido pelo Google e que só ficou ‘Ativo’ quando a comunicação com AWS foi estabelecida devido ao mapeamento que fiz com o IP, conforme mencionado acima. https://drive.google.com/file/d/1Y9wLH_DDX-93iMY5eNwBN0VcDFbId5I1/view?usp=drive_link

Agradeço antecipadamente por sua ajuda

Temos uma função Google Cloud implantada em europe-west6 (Zürich), que faz chamadas HTTP para uma API. Nos logs do nosso servidor, essas chamadas HTTP são originadas do endereço IP 35.203.247.36, que mostra os EUA como origem. Eu esperava um endereço IP de origem da Suíça. Isso causa alguns problemas com configurações de bloqueio geográfico.

Encontrei este tópico relacionado https://issuetracker.google.com/issues/72263361#comment91 , que afirma que isso deve funcionar conforme o esperado, mas os intervalos de IP vinculados parecem diferir de nossa observação:

  {
    "ipv4Prefix": "34.65.0.0/16",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv4Prefix": "34.104.110.0/23",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv4Prefix": "34.124.46.0/23",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv4Prefix": "35.216.128.0/17",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv4Prefix": "35.220.44.0/24",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv4Prefix": "35.235.216.0/21",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv4Prefix": "35.242.44.0/24",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }, {
    "ipv6Prefix": "2600:1900:4160::/44",
    "service": "Google Cloud",
    "scope": "europe-west6"
  }

Por que nossas chamadas de API não se originam de um desses intervalos de IP?