Esta página foi traduzida pela API Cloud Translation.

Workshop de modernização de apps

1. Introdução

Última atualização: 01/11/2024

Como modernizar um aplicativo PHP antigo para o Google Cloud?

(📽️ assista a um vídeo introdutório de 7 minutos deste codelab)

É comum ter aplicativos legados em execução no local que precisam ser modernizados. Isso significa torná-los escalonáveis, seguros e implantáveis em diferentes ambientes.

Neste workshop, você aprenderá a:

Conteinerizar o aplicativo PHP.
Migrar para um serviço gerenciado de banco de dados ( Cloud SQL).
implantar no Cloud Run, que é uma alternativa sem operações ao GKE/Kubernetes;
Proteja o aplicativo com o Identity and Access Management (IAM) e o Secret Manager.
Defina um pipeline de CI/CD usando o Cloud Build. O Cloud Build pode ser conectado ao seu repositório Git hospedado em provedores de Git conhecidos, como GitHub ou GitLab, e ser acionado em qualquer push para o main, por exemplo.
Hospedar as imagens do aplicativo no Cloud Storage. Isso é feito pela montagem, e nenhum código é necessário para mudar o app.
Introdução à funcionalidade de IA generativa pelo Gemini, orquestrada pelo Cloud Functions (sem servidor).
Familiarize-se com os SLO e como operar seu app recém-atualizado.

Ao seguir estas etapas, você pode modernizar gradualmente seu aplicativo PHP, melhorando a escalabilidade, a segurança e a flexibilidade de implantação. Além disso, a migração para o Google Cloud permite aproveitar a infraestrutura e os serviços poderosos para garantir que o aplicativo seja executado sem problemas em um ambiente nativo da nuvem.

Acreditamos que o que você vai aprender seguindo estas etapas simples pode ser aplicado ao seu próprio aplicativo e organização com diferentes idiomas/pilhas e casos de uso.

Sobre o app

O aplicativo ( código, sob a licença MIT) que você bifurcar é um aplicativo PHP 5.7 básico com autenticação MySQL. A ideia principal do app é fornecer uma plataforma em que os usuários podem fazer upload de fotos e os administradores podem marcar imagens inadequadas. O aplicativo tem duas tabelas:

Usuários. Vem pré-compilado com administradores. Novas pessoas podem se registrar.
Images Vem com algumas imagens de exemplo. Usuários conectados podem carregar novas fotos. Vamos adicionar um pouco de mágica aqui.

Sua meta

Queremos modernizar o aplicativo antigo para que ele esteja no Google Cloud. Vamos aproveitar as ferramentas e os serviços para melhorar a escalabilidade, a segurança, a automação do gerenciamento de infraestrutura e a integração de recursos avançados, como processamento de imagens, monitoramento e armazenamento de dados, usando serviços como o Cloud SQL, o Cloud Run, o Cloud Build, o Secret Manager e outros.

Acima de tudo, queremos fazer isso passo a passo para que você possa aprender qual é o processo de pensamento por trás de cada etapa, e geralmente cada uma desbloqueia novas possibilidades para as próximas (por exemplo: módulos 2 -> 3 e 6 -> 7).

Ainda não está convencido? Confira este vídeo de 7 minutos no YouTube.

O que é necessário

Um computador com um navegador conectado à Internet.
Alguns créditos do GCP. Peça algumas informações ao seu fã local do Google ;)
O comando gcloud está funcionando.
Você trabalha localmente? Faça o download aqui. Você também precisará de um bom editor (por exemplo, vscode ou intellij).
Quer fazer tudo "na nuvem"? Nesse caso, use o Cloud Shell.
Usuário do GitHub. Você vai precisar disso para ramificar o código original 🧑🏻‍💻 gdgpescara/app-mod-workshop com seu próprio repositório do Git. Isso é necessário para ter seu próprio pipeline de CI/CD (confirmação automática -> build -> implantação)

Confira exemplos de soluções:

Repositório do autor: https://github.com/Friends-of-Ricc/app-mod-workshop
O repositório original do workshop,nas pastas .solutions/, por capítulo.

Este workshop pode ser consumido no seu computador local ou inteiramente em um navegador.

Observação: este treinamento é realizado para DUAS personas: "usuários avançados do GCP" (local) e "desenvolvedores normais" (Web).

Se você é um usuário avançado do GCP, vai gostar de programar localmente no vscode e instalar gcloud, mysql, php e assim por diante. É provável que você já tenha a maioria dos recursos instalados e, é claro, um Linux ou um Mac. Isso exige mais tempo e, inevitavelmente, mais atrito. Sugerimos que você comece com a opção segura (a segunda)
Se você não é um habituado com a CLI, se tem uma máquina Windows ou se quer ter segurança e pouco tempo para resolver conflitos locais, use o Cloud Shell. É muito fácil de usar, é um shell na nuvem com TODOS os códigos e scripts que você precisa pré-instalados (gcloud, skaffold, mysql, python, ruby, etc.); ele gerencia a autenticação no navegador e é incrível como ele é fácil de usar. A única desvantagem é o aumento da latência, já que o código não é local para sua máquina. No entanto, o aumento da velocidade nas configurações de desenvolvimento do "dia 0" e do "dia 1" é perceptível.

Se você não tiver certeza, comece pelo Cloud Shell. Você vai se surpreender com a facilidade.

2. Configuração de crédito e Fork

Resgatar o crédito do GCP e configurar seu ambiente do GCP [opcional]

Para realizar este workshop, você precisa de uma conta de faturamento com algum crédito. Se você já tem sua própria cobrança, pule esta etapa.

Crie uma conta do Gmail do Google (*) para vincular ao seu crédito do GCP. Peça ao professor o link para resgatar o crédito do GCP ou use os créditos aqui: bit.ly/PHP-Amarcord-credits.

Faça login com a conta recém-criada e siga as instruções.

()

) Por que preciso de uma conta do Gmail nova?*

Vimos pessoas que não conseguiram concluir o codelab porque a conta delas (principalmente e-mails de trabalho ou de estudantes) já tinha tido contato com o GCP e tinha políticas organizacionais que limitavam a capacidade de fazer isso. Recomendamos criar uma nova conta do Gmail ou usar uma conta do Gmail (gmail.com) sem exposição anterior ao GCP.

Clique no botão para resgatar o crédito.

Preencha o formulário a seguir com seu nome e sobrenome e aceite os Termos e Condições.

Talvez seja necessário aguardar alguns segundos para que a conta de faturamento apareça aqui: https://console.cloud.google.com/billing

Depois, abra o console do Google Cloud e crie um novo projeto clicando no seletor de projetos no menu suspenso no canto superior esquerdo, onde "Sem organização" é exibido. Consulte abaixo

Crie um projeto se você não tiver um, conforme mostrado na captura de tela abaixo. Há uma opção "NOVO PROJETO" no canto superior direito.

Vincule o novo projeto à conta de faturamento de teste do GCP da seguinte maneira:

Tudo pronto para usar a Google Cloud Platform. Se você for iniciante ou só quiser fazer tudo em um ambiente do Cloud, acesse o Cloud Shell e o editor dele usando o botão a seguir no canto superior esquerdo, conforme mostrado abaixo.

Verifique se o novo projeto está selecionado no canto superior esquerdo:

Não selecionado (ruim):

Selecionado (bom):

Ramificar o app do GitHub

Acesse o app de demonstração: https://github.com/gdgpescara/app-mod-workshop
Clique em 🍴 bifurcar.
Se você não tiver uma conta do GitHub, crie uma.
Edite o que quiser.

Clone o código do app usando git clone https://github.com/<YOUR-GITHUB-USER>/<YOUR-REPO-NAME>

Abra a pasta do projeto clonado com seu editor favorito. Se você escolher o Cloud Shell, clique em "Abrir editor", conforme mostrado abaixo.

Você tem tudo o que precisa no Google Cloud Shell Editor, como mostra a figura a seguir

3. Módulo 1: Criar uma instância do SQL

Crie a instância do Google Cloud SQL

O app PHP vai se conectar a um banco de dados MySQL e, portanto, precisamos replicar isso no Google Cloud para uma migração sem problemas. O Cloud SQL é a combinação perfeita, porque permite executar um banco de dados MySQL totalmente gerenciado na Nuvem. Siga estas etapas:

Acesse a página do Cloud SQL: https://console.cloud.google.com/sql/instances.
Clique em "Criar instância".
Ative a API (se necessário). Isso pode demorar alguns segundos…
Escolha MySQL.
Estamos tentando oferecer a versão mais barata para que ela dure mais:

Edição: Enterprise
Predefinição: desenvolvimento (testamos o sandbox e não funcionou para nós)
Mysql Ver: 5.7 (uau, um túnel do tempo!)

ID da instância: escolha appmod-phpapp. Se você mudar essa configuração, altere também os scripts e soluções futuros de maneira adequada.
Senha: o que você quiser, mas anote como CLOUDSQL_INSTANCE_PASSWORD
Região: mantenha a mesma escolha para o restante do app (por exemplo, Milão = europe-west8)
Disponibilidade zonal: zona única (estamos economizando dinheiro para a demonstração)

Clique no botão "Criar instância" para implantar o banco de dados do Cloud SQL. ⌛ A conclusão leva cerca de 10 minutos⌛. Enquanto isso, continue lendo a documentação. Você também pode começar a resolver o próximo módulo ("Containerize your PHP App"), que não tem dependências nesse módulo na primeira parte (até que você corrija a conexão do banco de dados).

Observação: Essa instância custará cerca de US$ 7/dia. Desligue-o após o workshop.

Criar o banco de dados image_catalog e o usuário no Cloud SQL

O projeto do app vem com uma pasta db/ que contém dois arquivos SQL:

01_schema.sql : contém o código SQL para criar duas tabelas com dados de usuários e imagens.
02_seed.sql: contém o código SQL para inserir dados nas tabelas criadas anteriormente.

Esses arquivos serão usados depois que o banco de dados image_catalog for criado. Para fazer isso, siga estas etapas:

Abra sua instância e clique na guia Bancos de dados:
clique em "Criar banco de dados"
Chame-o de image_catalog (como na configuração do app PHP).

Em seguida, criamos o usuário do banco de dados. Com isso, podemos fazer a autenticação no banco de dados image_catalog.

Agora clique na guia Usuários.
Clique em "Adicionar conta de usuário".
Usuário: vamos criar um:

Nome de usuário: appmod-phpapp-user
Senha: escolha algo que você possa lembrar ou clique em "Gerar"
Mantenha a opção Permitir qualquer host (%).

Clique em "ADICIONAR".

Abra o banco de dados para IPs conhecidos.

Todos os bancos de dados no Cloud SQL são "isolados". Você precisa configurar explicitamente uma rede para ser acessível.

Clique na sua instância.
Abra o menu "Conexões".
Clique na guia "Rede".
Clique em "Redes autorizadas". Agora adicione uma sub-rede.

Por enquanto, vamos deixar a opção como NÃO SEGURA para que o app funcione:
Nome: "Todos no mundo - NÃO SEGUE" (vamos lembrar que essa solução barata também não é segura).
Rede: "0.0.0.0/0" (observação: isso é INSEGURO!)

Clique em "Salvar".

Você verá algo como:

Observação: Essa solução é um bom compromisso para concluir o workshop em O(horas). No entanto, consulte o documento SEGURANÇA para ajudar a proteger sua solução para produção.

É hora de testar a conexão do banco de dados!

Vamos conferir se o usuário image_catalog que criamos antes funciona. Acesse o Cloud SQL Studio na instância e insira o banco de dados, o usuário e a senha para autenticação, conforme mostrado abaixo:

Agora que você está conectado, pode abrir o Editor SQL e passar para a próxima seção.

Importar o banco de dados da base de código

Use o editor SQL para importar as tabelas image_catalog com os dados. Pegue o código SQL dos arquivos SQL no repositório e execute-os um após o outro em ordem sequencial. 01_schema.sql e 02_seed.sql.

Depois disso, você vai ter duas tabelas no image_catalog, que são users e images, conforme mostrado abaixo:

Para testar, execute o seguinte no editor: select * from images;

Anote também o endereço IP público, porque você vai precisar dele mais tarde.

4. Módulo 2: conteinerizar seu app PHP

Queremos criar este app para a nuvem.

Isso significa empacotar o código em algum tipo de arquivo ZIP que contenha todas as informações para executá-lo na nuvem.

Há algumas maneiras de fazer isso:

Docker Muito popular, mas bastante complexo de configurar corretamente.
Buildpacks. Menos popular, mas tende a "adivinhar automaticamente" o que precisa ser criado e executado. Muitas vezes, funciona!

No contexto deste workshop, vamos presumir que você usa o Docker.

Docker

Se você quer ter controle, esta é a solução certa. Isso faz sentido quando você precisa configurar bibliotecas específicas e injetar determinados comportamentos não óbvios (um chmod em uploads, um executável não padrão no app etc.).

Como queremos implantar nosso aplicativo conteinerizado no Cloud Run, consulte a documentação a seguir e tente preencher os espaços em branco. Fornecemos apenas o essencial para facilitar as coisas no momento. O Dockerfile final vai ficar mais ou menos assim:

# Use an official PHP image with Apache
# Pull a suitable php image
FROM __________# Define the env variable for the Apache listening port 8080
ENV __________

# Set working directory inside the container
WORKDIR __________

# Install required PHP extensions: PDO, MySQL, and other dependencies
RUN __________

# Copy all application files into the container
COPY __________

# Configure Apache to listen on port 8080. Use ‘sed' command to change the default listening port.
RUN __________

# When in doubt, always expose to port 8080
EXPOSE __________

# Start Apache in the foreground
CMD __________

Além disso, para testar nosso aplicativo localmente, precisamos mudar o arquivo config.php de modo que o app PHP se conecte ao banco de dados MYSQL disponível no Google CloudSQL. Com base no que você configurou antes, preencha os espaços em branco.

O db_host é o endereço IP público do Cloud SQL. Ele pode ser encontrado no console:

O nome do banco de dados não deve ser alterado: image_catalog
Db_user precisa ser appmod-phpapp-user
Db_pass é algo que você escolheu. Configure-o com aspas simples e use o escape conforme necessário.

<?php
// Database configuration
$db_host = '____________';
$db_name = '____________';
$db_user = '____________';
$db_pass = '____________';

try {
    $pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    die("Errore di connessione: " . $e->getMessage());
}

session_start();
?>

Além disso, sinta-se à vontade para traduzir as poucas peças em italiano para o inglês com a ajuda do Gemini.

Ok, agora que você tem o Dockerfile e configurou o app PHP para se conectar ao banco de dados, vamos testar isso.

Instale o Docker, se ainda não tiver ( link). Você não precisa fazer isso se estiver usando o Cloud Shell.

Agora tente criar e executar seu app PHP conteinerizado com os comandos apropriados do Docker para build e execução.

docker build -t <IMAGE_TAG_NAME> .
docker run -it -p <PORTA DO CONTÊINER>:<LOCAL MACHINE PORT> <IMAGE_TAG_NAME>

Se tudo estiver funcionando, você vai conseguir acessar a página da Web a seguir quando estiver conectado ao host local.

Se você estiver no Cloud Shell, também poderá exportar a porta local (por exemplo, 8080) para o navegador, desta forma:

docker build -t my-php-app-docker app-mod-workshop/ -f Dockerfile

docker run -it -p 8080:8080 my-php-app-docker

Agora que você sabe que o app está sendo executado na porta 8080, clique no ícone "Visualização na Web" (um navegador com um olho) e em Visualizar na porta 8080 (ou "Mudar porta" para qualquer outra porta).

Como testar o resultado no navegador

Agora, seu aplicativo vai ficar assim:

Se você fizer login com Admin/admin123, verá algo como isto.

Ótimo!!! Está funcionando 🎉🎉🎉

Se a dockerização estiver correta, mas as credenciais do banco de dados estiverem incorretas, você vai receber uma mensagem como esta:

Tente de novo. Você está quase lá!

Buildpacks [opcional]

Com o Buildpacks, o app é criado automaticamente. Infelizmente, você não tem controle total, de modo que poderá receber uma configuração inesperada.

Confira os BuildPacks no GCP: https://cloud.google.com/docs/buildpacks/build-application e aqui
Instale pack: https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/
buildpacks em PHP: https://cloud.google.com/docs/buildpacks/php (onde informa como configurar a versão do PHP)
Tente algo como o seguinte para criar automaticamente a imagem do contêiner.
pack build --builder=gcr.io/buildpacks/builder my-app-with-buildpacks

Você terá uma nova imagem do Docker no seu ambiente local. Você pode tentar executar um contêiner para isso, mas, como não temos controle total sobre como a imagem foi criada, o app pode não funcionar. De qualquer forma, convidamos você a testar e, se for bem-sucedido, compartilhe sua opinião. Agradecemos!

Como salvar no Artifact Registry [opcional]

Agora você tem um aplicativo PHP conteinerizado funcional pronto para ser implantado na nuvem. Em seguida, precisamos de um lugar na nuvem para armazenar nossa imagem do Docker e torná-la acessível para implantação em serviços do Google Cloud, como o Cloud Run. Essa solução de armazenamento se chama Artifact Registry, um serviço do Google Cloud totalmente gerenciado projetado para armazenar artefatos de aplicativos, como imagens de contêiner do Docker, pacotes Maven, módulos npm e muito mais.

Vamos criar um repositório no Google Cloud Artifact Registry usando o botão apropriado.

Escolha um nome válido, o formato e a região adequada para armazenar os artefatos.

Volte para a tag do ambiente de desenvolvimento local e envie a imagem do contêiner do app para o repositório do Artifact Registry que você acabou de criar. Para isso, execute os comandos a seguir.

docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
docker push TARGET_IMAGE[:TAG]

O resultado será semelhante à captura de tela abaixo.

Oba 🎉🎉🎉, você pode passar para o próximo nível.

Nota. Tente também o endpoint /upload.php e faça o upload de uma imagem. Você pode receber uma mensagem "Permissão negada". Se for o caso, você precisa corrigir o chmod/chown no Dockerfile.

5. Módulo 3: implantar o app no Cloud Run

Por que usar o Cloud Run?

Boa pergunta! Há alguns anos, você certamente teria escolhido o Google App Engine.

Simplificando, hoje o Cloud Run tem um conjunto de tecnologias mais novo, é mais fácil de implantar, mais barato e reduz a escala vertical para 0 quando você não o usa. Com a flexibilidade de executar qualquer contêiner sem estado e a integração com vários serviços do Google Cloud, ele é ideal para implantar microsserviços e aplicativos modernos com o mínimo de sobrecarga e a máxima eficiência.

Mais especificamente, o Cloud Run é uma plataforma totalmente gerenciada pelo Google Cloud que permite executar aplicativos conteinerizados sem estado em um ambiente sem servidor. Ele processa toda a infraestrutura de forma automática, escalonando de zero para atender ao tráfego de entrada e diminuindo quando ocioso, o que torna o processo econômico e eficiente. O Cloud Run oferece suporte a qualquer linguagem ou biblioteca, desde que ela seja empacotada em um contêiner, permitindo uma grande flexibilidade no desenvolvimento. Ele se integra bem a outros serviços do Google Cloud e é adequado para criar microsserviços, APIs, sites e aplicativos orientados a eventos sem precisar gerenciar a infraestrutura do servidor.

Pré-requisitos

Para realizar essa tarefa, você precisa ter o gcloud instalado na sua máquina local. Caso contrário, consulte as instruções aqui. Se você estiver no Google Cloud Shell, não será necessário fazer nada.

Antes da implantação

Se você estiver trabalhando no ambiente local, faça a autenticação no Google Cloud com o seguinte:

$ gcloud auth login –update-adc # not needed in Cloud Shell

Isso vai autenticar você usando um login OAuth no navegador. Faça login no Chrome com o mesmo usuário (por exemplo, vattelapesca@gmail.com) que fez login no Google Cloud com o faturamento ativado.

Ative a API Cloud Run com o seguinte comando

$ gcloud services enable run.googleapis.com

Agora, tudo está pronto para ser implantado no Cloud Run.

Implantar seu app no Cloud Run usando o gcloud

O comando que permite implantar o app no Cloud Run é o gcloud run deploy. Há várias opções para definir e alcançar sua meta. O conjunto mínimo é o seguinte:

Nome do serviço do Cloud Run que você quer implantar no app. Um serviço do Cloud Run vai retornar um URL que fornece um endpoint para o app.
Região do Google Cloud em que o app será executado.
Imagem do contêiner que envolve seu app.
Variáveis de ambiente que o app precisa usar durante a execução.
A flag "allow-unauthenticated", que permite que todos acessem seu app sem mais autenticação.

Consulte a documentação para saber como aplicar essa opção ao comando. A implantação vai levar alguns minutos. Se tudo estiver correto, você verá algo como isto no console do Google Cloud.

Clique no URL fornecido pelo Cloud Run e teste seu aplicativo. Depois da autenticação, você vai ver algo como isso.

"gcloud run deploy" sem "perguntas"

Você pode ter notado que o gcloud run deploy faz as perguntas certas e preenche os espaços em branco que você deixou. Que máximo!

No entanto, em alguns módulos, vamos adicionar esse comando a um acionador do Cloud Build para não ter que fazer perguntas. Precisamos preencher todas as opções no comando. Você quer criar o gcloud run deploy --option1 blah --foo bar --region your-fav-region dourado. Como fazer isso?

Repita as etapas 2, 3 e 4 até que a gcloud pare de fazer perguntas:
[LOOP] gcloud run deploy com opções encontradas até o momento
[LOOP] Os sistemas solicitam a opção X
[LOOP] Pesquise nas documentações públicas como configurar X na CLI adicionando a opção --my-option [my-value].
Volte para a etapa 2, a menos que o gcloud conclua sem mais perguntas.
O gcloud run deploy BLAH BLAH BLAH é demais! Salve o comando em algum lugar, porque você vai precisar dele mais tarde para a etapa do Cloud Build.

Uma possível solução está aqui.

Oba! 🎉🎉🎉 Você implantou seu app no Google Cloud e chegou à primeira etapa da modernização.

6. Módulo 4: Limpar senhas com o Secret Manager

Na etapa anterior, conseguimos implantar e executar o app no Cloud Run. No entanto, fizemos isso com uma prática ruim de segurança: fornecer alguns secrets em texto não criptografado.

Primeira iteração: atualize o config.php para usar o ENV

Você pode ter notado que colocamos a senha do banco de dados diretamente no código no arquivo config.php. Isso é bom para fins de teste e para ver se o app funciona. Mas não é possível confirmar/usar esse código em um ambiente de produção. A senha (e outros parâmetros de conexão do banco de dados) precisa ser lida dinamicamente e fornecida ao app no momento da execução. Altere o arquivo config.php para que ele leia os parâmetros db das variáveis ENV. Se isso falhar, considere definir valores padrão. Isso é bom caso você não consiga carregar o ENV. Assim, a saída da página vai informar se ele está usando os valores padrão. Preencha os espaços em branco e substitua o código em config.php.

<?php
// Database configuration with ENV variables. Set default values as well 
$db_host = getenv('DB_HOST') ?: _______;
$db_name = getenv('DB_NAME') ?: 'image_catalog';
$db_user = getenv('DB_USER') ?: 'appmod-phpapp-user';
$db_pass = getenv('DB_PASS') ?: _______;
// Note getenv() is PHP 5.3 compatible
try {
    $pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    die("Errore di connessione: " . $e->getMessage());
}

session_start();
?>

Como seu app é conteinerizado, você precisa fornecer uma maneira de fornecer as variáveis ENV a ele. Isso pode ser feito de algumas maneiras:

No tempo de build, no Dockerfile. Adicione os quatro parâmetros ao Dockerfile anterior usando a sintaxe ENV DB_VAR=ENV_VAR_VALUE. Isso vai configurar valores padrão que podem ser substituídos no ambiente de execução. Por exemplo, "DB_NAME" e "DB_USER" podem ser definidos aqui e em nenhum outro lugar.
No ambiente de execução. É possível configurar essas variáveis para o Cloud Run, tanto na CLI quanto na interface. Este é o lugar certo para colocar todas as quatro variáveis, a menos que você queira manter os padrões definidos no Dockerfile.

No localhost, talvez seja melhor colocar as variáveis ENV em um arquivo .env (confira a pasta solutions).

Além disso, verifique se o .env foi adicionado ao .gitignore. Não envie seus segredos para o GitHub.

echo .env >> .gitignore

Depois disso, teste a instância localmente:

docker run -it -p 8080:8080 --env-file .env my-php-app-docker

Agora você conseguiu o seguinte:

O app vai ler a variável dinamicamente do ambiente
Você melhorou a segurança ao remover a senha do banco de dados do seu código)

Agora você pode implantar uma nova revisão no Cloud Run. Vamos acessar a interface e definir as variáveis de ambiente manualmente:

Acesse https://console.cloud.google.com/run.
Clique no seu app
Clique em "Editar e implantar uma nova revisão".
Na primeira guia "Contêineres", clique na guia inferior "Variáveis e secrets".
Clique em "+ Adicionar variável" e adicione todas as variáveis necessárias. O resultado será algo como:

Isso é perfeito? Não. Seu cartão ainda está visível para a maioria dos operadores. Isso pode ser mitigado com o Google Cloud Secret Manager.

Segunda iteração: Secret Manager

Suas senhas desapareceram do seu próprio código: vitória! Mas espere, já estamos a salvo?

Suas senhas ainda estão visíveis para qualquer pessoa com acesso ao Console do Google Cloud. Na verdade, se você acessar o arquivo de implantação YAML do Cloud Run, será possível recuperá-lo. Se você tentar editar ou implantar uma nova revisão do Cloud Run, a senha vai aparecer na seção "Variáveis e chaves secretas", conforme mostrado nas capturas de tela abaixo.

O Secret Manager do Google Cloud é um serviço seguro e centralizado para gerenciar informações sensíveis, como chaves de API, senhas, certificados e outros segredos.

Ele permite armazenar, gerenciar e acessar secrets com permissões detalhadas e criptografia robusta. Integrado ao Identity and Access Management (IAM) do Google Cloud, o Secret Manager permite controlar quem pode acessar segredos específicos, garantindo a segurança dos dados e a conformidade com as regulamentações.

Ele também oferece suporte à rotação e ao controle de versões automáticas de segredos, simplificando o gerenciamento do ciclo de vida de segredos e melhorando a segurança em aplicativos em todos os serviços do Google Cloud.

Para acessar o Secret Manager, navegue do menu de navegação para os serviços de segurança e encontre-o na seção Proteção de dados, conforme mostrado na captura de tela abaixo.

Ative a API Secret Manager conforme a imagem abaixo.

Agora, clique em "Create a secret": vamos chamá-lo de maneira racional:
Nome: php-amarcord-db-pass
Valor secreto: sua senha do DB (ignore a parte "upload file").
annotate this secret link, deverá ser semelhante a projects/123456789012/secrets/php-amarcord-db-pass. Este é o ponteiro exclusivo para seu secret (para Terraform, Cloud Run e outros). O número é exclusivo do seu projeto.

Dica: tente usar uma convenção de nomenclatura consistente para seus segredos, especializando-se da esquerda para a direita, por exemplo: cloud-devrel-phpamarcord-dbpass

Organização (com a empresa)
Equipe (dentro da organização)
Aplicativo (dentro da equipe)
Nome da variável (no app)

Assim, você terá regexes fáceis para encontrar todos os segredos em um único app.

Criar uma nova revisão do Cloud Run

Agora que temos um novo secret, precisamos nos livrar da variável de ambiente DB_PASS e substituí-la pelo novo secret. Então:

Acessar o Cloud Run usando o console do Google Cloud
Escolha o app.
Clique em "Editar e implantar uma nova revisão"
localize a guia "Variáveis e secrets".
Use o botão "+ Reference a Secret" para redefinir a variável de ambiente DB_PASS.
Use o mesmo "DB_PASS" para os segredos referenciados e use a versão mais recente.

Depois disso, você vai receber o seguinte erro:

Tente descobrir como corrigir o problema. Para resolver isso, acesse a seção IAM e administrador e mude as permissões de concessão. Boa depuração :-)

Depois de descobrir, volte ao Cloud Run e reimplante uma nova revisão. O resultado vai ficar assim:

Dica: o console do desenvolvedor (IU) é ótimo para apontar problemas de permissão. Navegue por todos os links das entidades do Cloud.

7. Módulo 5: configurar seu CI/CD com o Cloud Build

Por que usar um pipeline de CI/CD?

Até agora, você já deve ter digitado gcloud run deploy algumas vezes, talvez respondendo à mesma pergunta várias vezes.

Cansou de implantar o app manualmente com o gcloud run deploy? Não seria ótimo se o app pudesse ser implantado automaticamente sempre que você envia uma nova alteração para o repositório Git?

Para usar um pipeline de CI/CD, você precisa de duas coisas:

Um repositório pessoal do Git: felizmente, você já deve ter bifurcado o repositório do workshop na sua conta do GitHub na etapa 2. Caso contrário, volte e conclua essa etapa. O repositório bifurcado vai ficar assim: https://github.com/<YOUR_GITHUB_USER>/app-mod-workshop
Cloud Build. Esse serviço incrível e barato permite configurar a automação de build para quase tudo: Terraform, apps dockerizados etc.

Esta seção se concentra na configuração do Cloud Build.

Conheça o Cloud Build!

Vamos usar o Cloud Build para fazer o seguinte:

crie sua fonte (com o Dockerfile). Pense nisso como um "arquivo ZIP grande" que contém tudo o que você precisa para criar e executar (o "artefato de build").
Envie esse artefato para o Artifact Registry (AR).
Em seguida, faça uma implantação do AR para o Cloud Run para o app "php-amarcord".
Isso criará uma nova versão ("revisão") do app existente (pense em uma camada com o novo código) e a configuraremos de modo a desviar o tráfego para a nova versão se o envio for bem-sucedido.

Este é um exemplo de alguns builds para meu app php-amarcord:

Como fazemos tudo isso?

Ao criar um arquivo YAML perfeito: cloudbuild.yaml
Criando um gatilho do Cloud Build.
Conectando-se ao nosso repositório do GitHub pela interface do Cloud Build.

Criar gatilho (e conectar repositório)

Acesse https://console.cloud.google.com/cloud-build/triggers.
Clique em "Criar gatilho".
Compilar:
Nome: algo significativo, como on-git-commit-build-php-app
Evento: enviar por push para a ramificação
Origem: "Conectar novo repositório"
Isso vai abrir uma janela à direita: "Conectar repositório".
Provedor de origem: "Github" (primeiro)
"Continuar"
O "Authenticate" abrirá uma janela no GitHub para autenticação cruzada. Siga o fluxo e seja paciente. Se você tiver muitos repositórios, pode demorar um pouco.
"Select repo": selecione sua conta/repo e marque a parte "I understand...".
Se você recebeu a mensagem de erro: "O app GitHub não está instalado em nenhum dos seus repositórios", clique em "Instalar o Google Cloud Build" e siga as instruções.
Clique em "Conectar".
Bingo! Seu repositório está conectado.
Voltando à parte do acionador...
Configuração: Detectado automaticamente (*)
Avançado: selecione a conta de serviço "[PROJECT_NUMBER]- compute@developer.gserviceaccount.com"
xxxxx é o ID do projeto
A conta de serviço de computação padrão é adequada para uma abordagem de laboratório. Não a use em produção. Saiba mais.
Deixe tudo como está.
Clique no botão "Criar".

(*) Essa é a maneira mais simples, porque verifica o Dockerfile ou o cloudbuild.yaml. No entanto, o cloudbuild.yaml oferece a você poder real para decidir o que fazer em cada etapa.

Eu tenho o poder!

Agora, o acionador não vai funcionar a menos que você conceda à conta de serviço do Cloud Build (o que é uma conta de serviço? O e-mail de um "robô" que atua em seu nome para uma tarefa. Neste caso, criar coisas na nuvem.

O SA não vai conseguir criar e implantar se você não der a ele permissão para fazer isso. Felizmente, é fácil.

Acesse Cloud Build > Configurações.
Conta de serviço "[PROJECT_NUMBER]- compute@developer.gserviceaccount.com"
Marque estas caixas:
Cloud Run
Secret Manager
Contas de serviço
Cloud Build
Marque também a opção "Definir como conta de serviço preferencial".

Onde está o YAML do Cloud Build?

Recomendamos que você passe algum tempo criando seu próprio YAML do Cloud Build.

No entanto, se você não tiver tempo ou não quiser fazer isso, pode se inspirar nesta pasta de soluções: .solutions

Agora é possível enviar uma alteração ao GitHub e observar o Cloud Build.

Configurar o Cloud Build pode ser complicado. É possível que haja algumas idas e vindas:

Verifique os registros em https://console.cloud.google.com/cloud-build/builds;region=global
Encontrando o erro.
Correção no código e nova emissão de git commit / git push.
Às vezes, o erro não está no código, mas em alguma configuração. Nesse caso, é possível emitir um novo build na interface (build na nuvem > "Triggers" > Executar).

Se você usar essa solução, ainda vai precisar fazer alguns ajustes. Por exemplo, é necessário definir as variáveis de ambiente para os endpoints de desenvolvimento/produção recém-criados:

Faça isso de duas maneiras:

Pela interface, definindo as variáveis de ambiente novamente
Com a CLI, criando o script "perfeito" para você. Confira um exemplo aqui: gcloud-run-deploy.sh . Você precisa ajustar algumas coisas, por exemplo, o endpoint e o número do projeto. Você pode encontrar o número do projeto na Visão geral do Cloud.

Como faço para confirmar o código no GitHub?

Este workshop não ensina a melhor maneira de git push para o github. No entanto, se você estiver com problemas e estiver no Cloud Shell, há duas maneiras:

CLI. Adicione uma chave SSH localmente e adicione um controle remoto com git@github.com:YOUR_USER/app-mod-workshop.git (em vez de http)
VSCode. Se você usa o editor do Cloud Shell, pode usar a guia "Controle de origem" (Ctrl-Shift-G), clicar em "Sincronizar mudanças" e seguir as instruções. Você poderá autenticar sua conta do GitHub no VSCode, e o pull/push será muito fácil.

Não se esqueça de git add clodubuild.yaml entre outros arquivos, ou ele não vai funcionar.

"Paridade de desenvolvimento/produção" profunda x superficial [opcional]

Se você copiou a versão do modelo deste link, terá duas versões idênticas de DEV e PROD. Isso é legal e está de acordo com a regra 10 do app de 12 fatores.

No entanto, estamos usando dois endpoints da Web diferentes para que um app aponte para o mesmo banco de dados. Isso é bom o suficiente para um workshop. No entanto, na vida real, é necessário dedicar algum tempo para criar um ambiente de produção adequado. Isso significa ter dois bancos de dados (um para desenvolvimento e outro para produção) e também escolher onde colocá-los para recuperação de desastres / alta disponibilidade. Isso vai além do escopo deste workshop, mas é um pouco de reflexão.

Se você tiver tempo para fazer uma versão "profunda" da produção, tenha em mente todos os recursos que precisa duplicar, como:

Banco de dados do Cloud SQL (e provavelmente a instância do SQL).
Bucket do GCS
Função do Cloud.
Você pode usar o Gemini 1.5 Flash como um modelo em desenvolvimento (mais barato e rápido) e o Gemini 1.5 Pro (mais poderoso).

Em geral, sempre que você fizer algo relacionado ao app, pense criticamente: a produção precisa ter esse mesmo valor ou não? Caso contrário, duplique o esforço. Isso é muito mais fácil com o Terraform, que permite injetar seu ambiente (-dev, -prod) como um sufixo nos recursos.

8. Módulo 6: Migrar para o Google Cloud Storage

Armazenamento

Atualmente, o app armazena o estado em um contêiner do Docker. Se a máquina quebrar, o app explodir ou você enviar uma nova revisão, uma nova será programada, com um armazenamento redefinido (=>vazio). 🙈

Como corrigir isso? Há várias abordagens.

Armazenar imagens no banco de dados. Foi o que acabei fazendo com meu app PHP anterior. É a solução mais simples, porque não adiciona complexidade. Mas isso aumenta a latência e a carga no seu banco de dados.
Migrar seu app do Cloud Run para uma solução compatível com armazenamento: GCE + disco permanente? Talvez GKE + Storage?
Mover para o GCS. O Google Cloud Storage oferece o melhor armazenamento da categoria para todo o Google Cloud e é a solução mais idiomática do Cloud. No entanto, isso exige que você se suja com bibliotecas PHP. Temos bibliotecas do PHP 5.7 para o GCS? O PHP 5.7 oferece suporte a Composer? Parece que o PHP 5.3.2 é a versão mais antiga com suporte do Composer.
Talvez usar um sidecar do Docker?
Ou use as montagens de volume do Cloud Run do GCS. Isso é incrível.

🤔 Migrar armazenamento (aberto)

[Aberta] Neste exercício, queremos que você encontre uma solução para mover suas imagens de uma forma que seja mantida de alguma forma.

Teste de aceitação

Não quero dizer a solução, mas quero que isso aconteça:

Você faz o upload de newpic.jpg. Você vai encontrar essa informação no app.
Fazer upgrade do app para uma nova versão.
newpic.jpg ainda está lá, visível.

💡 Solução possível (montagens de volume do Cloud Run do GCS)

Essa é uma solução muito elegante que nos permite fazer uploads de arquivos com estado sem precisar tocar no código. Além de mostrar a descrição de uma imagem, o processo é simples e apenas para a satisfação dos olhos.

Isso permite que você monte uma pasta do Cloud Run para o GCS:

Todos os uploads para o GCS vão ficar visíveis no seu app.
Todos os uploads para seu app serão realmente enviados para o GCS
A mágica vai acontecer com os objetos enviados para o GCS (capítulo 7).

Observação: Leia os detalhes do FUSE. Isso NÃO é adequado se o desempenho for um problema.

Crie um bucket do GCS

O GCS é o serviço de armazenamento onipresente do Google Cloud. Ele foi testado e é usado por todos os serviços do GCP que precisam de armazenamento.

O Cloud Shell exporta PROJECT_ID como GOOGLE_CLOUD_PROJECT:

$ export PROJECT_ID=$GOOGLE_CLOUD_PROJECT

#!/bin/bash

set -euo pipefail

# Your Cloud Run Service Name, eg php-amarcord-dev
SERVICE_NAME='php-amarcord-dev'
BUCKET="${PROJECT_ID}-public-images"
GS_BUCKET="gs://${BUCKET}"

# Create bucket
gsutil mb -l "$GCP_REGION" -p "$PROJECT_ID" "$GS_BUCKET/"

# Copy original pictures there - better if you add an image of YOURS before.
gsutil cp ./uploads/*.png "$GS_BUCKET/"

Configure o Cloud Run para montar o bucket na pasta /uploads/

Agora vamos para a parte elegante. Criamos um volume php_uploads e instruímos o Cloud Run a fazer uma montagem FUSE em MOUNT_PATH (algo como /var/www/html/uploads/):

#!/bin/bash

set -euo pipefail

# .. keep variables from previous script..

# Uploads folder within your docker container.
# Tweak it for your app code.
MOUNT_PATH='/var/www/html/uploads/'

# Inject a volume mount to your GCS bucket in the right folder.
gcloud --project "$PROJECT_ID" beta run services update "$SERVICE_NAME" \
    --region $GCP_REGION \
    --execution-environment gen2 \
    --add-volume=name=php_uploads,type=cloud-storage,bucket="$BUCKET"  \
    --add-volume-mount=volume=php_uploads,mount-path="$MOUNT_PATH"

Agora, repita esta etapa para todos os endpoints que você quer apontar para o Cloud Storage.

Também é possível alcançar o mesmo na interface

Na guia "Volumes", crie um Volume Mounts que aponte para seu bucket, do tipo "bucket do Cloud Storage", por exemplo, com o nome "php_uploads".
Em "Container(s)> Volume Mounts", monte o volume que você acabou de criar no ponto de volume solicitado pelo app. Isso depende do dockerfile, mas pode ser semelhante a var/www/html/uploads/ .

De qualquer forma, se funcionar, a edição da nova revisão do Cloud Run vai mostrar algo assim:

Agora teste o novo aplicativo fazendo o upload de uma nova imagem para o endpoint /upload.php.

As imagens devem fluir perfeitamente no GCS sem escrever uma única linha de PHP:

O que aconteceu?

Algo muito mágico aconteceu.

Um aplicativo antigo com código antigo ainda está funcionando. Uma pilha nova e modernizada permite que todas as imagens do app fiquem confortavelmente em um bucket do Cloud com estado. Agora o céu é o limite:

Quer enviar um e-mail sempre que uma imagem com "perigoso" ou "nudo" for recebida? Isso pode ser feito sem tocar no código PHP.
Quer usar um modelo multimodal do Gemini sempre que uma imagem aparecer para descrevê-la e fazer upload do banco de dados com a descrição dela? É possível fazer isso sem tocar no código PHP. Você não acredita em mim? Continue lendo no capítulo 7.

Acabamos de abrir um grande espaço de oportunidades.

9. Módulo 7: Capacite seu app com o Google Gemini

Agora você tem um novo app PHP moderno e moderno (como um Fiat 126 2024) com armazenamento na nuvem.

O que você pode fazer com ele?

Pré-requisitos

No capítulo anterior, uma solução de modelo nos permitiu montar imagens /uploads/ no GCS, de fato separando a lógica do app do armazenamento de imagens.

Este exercício requer que você:

Ter concluído o exercício do capítulo 6 (armazenamento).
Tenha um bucket do GCS com os uploads de imagens, em que as pessoas fazem upload de fotos do app e as imagens fluem para o bucket.

Configurar uma função do Cloud (em Python)

Você já se perguntou como implementar um aplicativo orientado a eventos? Por exemplo:

quando <event> acontece => enviar um e-mail
quando <event> acontece => se <condition> for verdadeira, atualize o banco de dados.

O evento pode ser qualquer coisa, desde um novo registro disponível no BigQuery, um novo objeto alterado em uma pasta no GCS ou uma nova mensagem aguardando em uma fila no Pub/Sub.

O Google Cloud oferece suporte a vários paradigmas para isso. Em especial:

EventArc. Saiba como receber eventos do GCS. Ótimo para criar DAGs e orquestrar ações com base em se-então-senão no Cloud.
Cloud Scheduler. Ótimo para um job cron de meia-noite na nuvem, por exemplo.
Fluxos de trabalho do Cloud. Da mesma forma que o Event Arc, permite que você
Funções do Cloud Run (conhecido como lambdas).
Cloud Composer: Basicamente, a versão do Google do Apache Airflow, também é ótima para DAGs.

Neste exercício, vamos nos aprofundar na função do Cloud para alcançar um resultado bastante espetacular. E vamos oferecer exercícios opcionais para você.

O exemplo de código está disponível em .solutions/.

Configurar uma função do Cloud (🐍 Python)

Estamos tentando criar um GCF muito ambicioso.

Quando uma nova imagem é criada no GCS. (provavelmente porque alguém fez o upload no aplicativo, mas não apenas)
... chame o Gemini para descrevê-la e receber uma descrição textual da imagem... (é bom verificar o MIME e confirmar que é uma imagem e não um PDF, MP3 ou texto)
.. e atualize o banco de dados com essa descrição. Isso pode exigir a correção do banco de dados para adicionar uma coluna description à tabela images.

Corrija o banco de dados para adicionar `description` às imagens

Abra o Cloud SQL Studio:

Coloque seu usuário e senha para o banco de dados de imagens
Injete este SQL, que adiciona uma coluna para uma descrição de imagem:

ALTER TABLE images ADD COLUMN description TEXT;

E bingo! Tente agora para conferir se funcionou:

SELECT * FROM images;

A nova coluna de descrição vai aparecer:

Escreva a função f(x) do Gemini

Observação: Essa função foi criada com a ajuda do Gemini Code Assist.

Observação: Ao criar essa função, você pode incorrer em erros de permissão do IAM. Alguns deles estão documentados abaixo no parágrafo "Possíveis erros".

Ative as APIs
Acesse https://console.cloud.google.com/functions/list.
Clique em "Criar função".
Ative as APIs do assistente:

É possível criar o GCF na interface ou na linha de comando. Aqui vamos usar a linha de comando.

Um possível código pode ser encontrado em .solutions/

Crie uma pasta para hospedar seu código, por exemplo, "gcf/". Insira a pasta.
Crie um arquivo requirements.txt:

google-cloud-storage
google-cloud-aiplatform
pymysql

Crie uma função Python. Exemplo de código aqui: gcf/main.py.

#!/usr/bin/env python

"""Complete this"""

from google.cloud import storage
from google.cloud import aiplatform
import vertexai
from vertexai.generative_models import GenerativeModel, Part
import os
import pymysql
import pymysql.cursors

# Replace with your project ID
PROJECT_ID = "your-project-id"
GEMINI_MODEL = "gemini-1.5-pro-002"
DEFAULT_PROMPT = "Generate a caption for this image: "

def gemini_describe_image_from_gcs(gcs_url, image_prompt=DEFAULT_PROMPT):
    pass

def update_db_with_description(image_filename, caption, db_user, db_pass, db_host, db_name):
    pass

def generate_caption(event, context):
    """
    Cloud Function triggered by a GCS event.
    Args:
        event (dict): The dictionary with data specific to this type of event.
        context (google.cloud.functions.Context): The context parameter contains
                                                event metadata such as event ID
                                                and timestamp.
    """
    pass

Envie a função. Você pode usar um script semelhante a este: gcf/push-to-gcf.sh.

Observação 1. Use os valores corretos para os ambientes ou adicione-os na parte de cima (GS_BUCKET=blah, ..):

Observação 2. Isso vai enviar todo o código local (.). Portanto, inclua seu código em uma pasta específica e use .gcloudignore como um profissional para evitar enviar bibliotecas enormes. ( exemplo).

#!/bin/bash

set -euo pipefail

# add your logic here, for instance:
source .env || exit 2 

echo "Pushing ☁️ f(x)☁ to 🪣 $GS_BUCKET, along with DB config.. (DB_PASS=$DB_PASS)"

gcloud --project "$PROJECT_ID" functions deploy php_amarcord_generate_caption \
    --runtime python310 \
    --region "$GCP_REGION" \
    --trigger-event google.cloud.storage.object.v1.finalized \
    --trigger-resource "$BUCKET" \
    --set-env-vars "DB_HOST=$DB_HOST,DB_NAME=$DB_NAME,DB_PASS=$DB_PASS,DB_USER=$DB_USER" \
    --source . \
    --entry-point generate_caption \
    --gen2

Observação: neste exemplo, generate_caption será o método invocado, e a Função do Cloud vai transmitir o evento do GCS a ele com todas as informações relevantes (nome do bucket, nome do objeto etc.). Dedique algum tempo para depurar o dicionário Python do evento.

Como testar a função

Testes de unidade

A função tem muitas partes móveis. Talvez você queira testar todos os itens individuais.

Um exemplo está em gcf/test.py.

Interface do Cloud Functions

Também reserve um tempo para conferir sua função na interface. Vale a pena conferir todas as guias, principalmente Source (minha favorita), Variables, Trigger e Logs. Você vai passar muito tempo na Logs para resolver problemas (confira também os possíveis erros na parte de baixo desta página). Verifique também a Permissions.

Teste E2E

É hora de testar a função manualmente.

Acesse seu app e faça login
Faça upload de uma imagem (não muito grande, já tivemos problemas com imagens grandes)
verifique na interface se a imagem foi enviada.
Verifique no Cloud SQL Studio se a descrição foi atualizada. Faça login e execute esta consulta: SELECT * FROM images.

E funciona. Também podemos atualizar o front-end para mostrar essa descrição.

Atualizar o PHP para mostrar [opcional]

Provamos que o app funciona. No entanto, seria bom que os usuários também pudessem ver essa descrição.

Não precisamos ser especialistas em PHP para adicionar a descrição ao index.php. Este código deve funcionar (sim, o Gemini escreveu para mim também!):

<?php if (!empty($image['description'])): ?>
    <p class="font-bold">Gemini Caption:</p>
    <p class="italic"><?php echo $image['description']; ?></p>
<?php endif; ?>

Posicione esse código dentro de foreach como preferir.

Nas próximas etapas, também vamos conferir uma versão mais bonita da interface, graças ao Gemini Code Assist. Uma versão bonita pode ser assim:

Conclusões

Você gerou uma função do Cloud acionada por novos objetos que chegam ao GCS. Com ela, é possível anotar o conteúdo da imagem, como um ser humano, e atualizar o banco de dados automaticamente. Uau!

A seguir Você pode seguir o mesmo raciocínio para alcançar duas grandes funcionalidades.

[Opcional] Adicionar mais funções do Cloud [sem fim definido]

Alguns recursos adicionais vêm à mente.

📩 Acionar e-mail

Um gatilho de e-mail que envia um e-mail para você sempre que alguém envia uma foto.

Com muita frequência? Adicione mais uma restrição: uma imagem GRANDE ou que tenha as palavras "nudez/nudez/violento" no conteúdo do Gemini.
Verifique EventArc para isso.

🚫 Moderação automática de fotos inadequadas

No momento, um administrador humano está sinalizando imagens como "inadequadas". Que tal deixar o Gemini fazendo o trabalho pesado e moderando o espaço? Adicione um teste para sinalizar conteúdo inadequado do acionador e atualize o banco de dados, como aprendemos na função anterior. Isso significa basicamente pegar a função anterior, alterar o comando e atualizar o banco de dados com base na resposta.

Observação. A IA generativa tem saídas imprevisíveis. Confira se o "resultado do criativo" do Gemini está "nos trilhos". Você pode pedir uma resposta determinista, como uma pontuação de confiança de 0 a 1, um JSON, .... Você pode fazer isso de várias maneiras. Por exemplo: * Usando as bibliotecas Python pydantic, langchain. * Use Saída estruturada do Gemini.

Dica. Você pode ter VÁRIAS funções ou um único comando que exija uma resposta JSON (funciona muito bem com a "Saída estruturada do Gemini", conforme destacado acima), como:

Qual seria o comando para gerar isso?

{
    "description": "This is the picture of an arrosticino",
    "suitable": TRUE
}

Você pode adicionar outros campos no comando para receber insights como: algo de bom nisso? Você se sente mal por isso? Você reconhece o lugar? Há algum texto (o OCR nunca foi tão fácil):

goods: "It looks like yummie food"
bads: "Parece comida não saudável"
OCR: "Da consumare preferibilmente prima del 10 Novembre 2024"
location: "Pescara, Lungomare"

Embora normalmente seja melhor usar N função para N resultados, é muito gratificante fazer um que faça 10 coisas. Confira este artigo do Riccardo para saber como.

Possíveis erros (principalmente IAM / permissões)

Quando desenvolvi essa solução pela primeira vez, encontrei alguns problemas de permissão do IAM. Vou adicionar os problemas aqui para mostrar empatia e dar algumas ideias de como corrigi-los.

Erro: não há permissões suficientes para a conta de serviço

Para implantar uma função do GCF que escuta um bucket do GCS, é necessário configurar as permissões adequadas para a conta de serviço que você está usando para o job, como na figura:

Talvez você também precise ativar as APIs do Eventarc. Isso pode levar alguns minutos até que elas fiquem totalmente disponíveis.

Erro: invocador do Cloud Run ausente

Outro comentário da interface para a permissão do GCF é este ( papel de Invocador do Cloud Run):

Esse erro pode ser corrigido executando o comando na imagem, que é semelhante a fix-permissions.sh.

Esse problema é descrito aqui: https://cloud.google.com/functions/docs/securing/authenticating

Erro: limite de memória excedido

Na primeira vez que executei, os registros disseram: "O limite de memória de 244 MiB foi excedido com 270 MiB usados. Aumente o limite de memória. Consulte https://cloud.google.com/functions/docs/configuring/memory. Novamente, adicione RAM ao GCF. É muito fácil fazer isso na interface. Aqui está um possível aumento:

Como alternativa, você também pode corrigir o script de implantação do Cloud Run para aumentar a MEM/CPU. Isso leva um pouco mais de tempo.

Erro: PubSub publicado

A criação de um gatilho com o GCF v1 gerou o seguinte erro:

Novamente, é fácil corrigir isso acessando o IAM e atribuindo à sua conta de serviço o papel de "Editor do Pub/Sub".

Erro: a Vertex AI não foi usada

Se você receber esse erro:

Permissão negada: 403 a API Vertex AI não foi usada no projeto YOUR_PROJECT antes ou está desativada. Ative-a acessando https://console.developers.google.com/apis/api/aiplatform.googleapis.com/overview?project=YOR_PROJECT

Basta ativar as APIs Vertex AI. A maneira mais fácil de ativar TODAS as APIs necessárias é esta:

https://console.cloud.google.com/vertex-ai
Clique em "Ativar todas as APIs recomendadas".

Erro: o acionador do EventArc não foi encontrado.

Se isso acontecer, reimplante a função.

Erro: 400 agentes de serviço estão sendo provisionados

400 Os agentes de serviço estão sendo provisionados ( https://cloud.google.com/vertex-ai/docs/general/access-control#service-agents ). Os agentes de serviço são necessários para ler o arquivo do Cloud Storage fornecido. Tente novamente em alguns minutos.

Se isso acontecer, aguarde um pouco ou pergunte a um Googler.

10. Módulo 8: Criar SLOs de disponibilidade

Neste capítulo, tentamos alcançar o seguinte:

Como criar SLIs
Como criar SLOs com base nas SLIs
Como criar alertas com base em SLOs

Esse é um tema muito importante para o autor, já que Riccardo trabalha na área de SRE / DevOps do Google Cloud.

(sem resposta) Criar SLIs e SLOs para este app

Um app é bom se você não consegue saber quando ele está inativo?

O que é um SLO?

Ah! O Google inventou os SLOs. Para saber mais, sugiro:

Livro SRE: capítulo 2 - Como implementar SLOs. (👉 mais livros de SRE)
Art of SLOs ( vídeo incrível). É um treinamento fantástico para aprender a criar um SLO perfeito para seu serviço.
Curso de SRE no Coursera. Eu contribuí para isso!

Etapa 1: criar um SLI/SLO de disponibilidade

Vamos começar com o SLO de disponibilidade, porque é o mais fácil e possivelmente o mais importante a ser medido.

Felizmente, o Cloud Run tem suporte pré-criado para SLO, graças ao Istio.

https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring/ui/create-slo

Quando seu app estiver no Cloud Run, o processo é muito simples, preciso de 30 segundos.

Acesse a página do Cloud Run.
Clique/selecione o app.
Selecione a guia SLOs.
Clique em "+ Criar SLO".
Disponibilidade, com base na solicitação
Continuar
Mês no calendário / 99%.
Clique em "Criar SLO".

Etapa 2: configurar o alerta para este SLO

Sugiro criar dois alertas:

Um alerta com taxa de consumo baixo ("Slowburn") para alertar você por e-mail (simula um tíquete com preço baixo).
Um com uma taxa de queima alta ("queima rápida") para alertar você por SMS (simula um pager / ticket de alta prioridade)

Acesse sua SLO tab anterior.

Faça isso duas vezes:

Clique em "Criar alerta de SLO" (o botão 🔔 com um sinal de adição à direita).
Duração do lookback e limite do índice de desempenho de custo:
[RÁPIDO]. Primeiro: 60 min / 10 x
[LENTO]. Segundo: 720 min / 2 x
Canal de notificação: clique em "Gerenciar canais de notificação"
Primeiro, "E-mail" -> Adicionar novo -> ..
Em segundo lugar, "SMS" -> Adicionar novo -> Verificar no telefone.
Dica: eu gosto de usar emojis nos nomes. É divertido para demonstrações.
Quando terminar, clique no X grande no canto superior direito.
Selecione o telefone primeiro (rápido) e depois o e-mail (lento).
Adicione alguns exemplos de documentação, como:
[PHP Amarcord] Riccardo told me to type sudo reboot or to check documentation in http://example.com/playbooks/1.php but I guess he was joking.

Bingo!

Resultado final

Podemos considerar este exercício como concluído quando você tiver um SLO ativo + o dobro de alertas de disponibilidade, e ele estiver alertando para seu e-mail e seu telefone.

Se preferir, você pode adicionar uma Latência (recomendamos fazer isso) ou até mesmo uma mais complexa. Para latência, escolha uma latência que você considere razoável. Em caso de dúvida, escolha 200 ms.

11. Próximas etapas

Você concluiu TUDO. O que está faltando?

Algumas ideias para você pensar:

Jogar com o Gemini

Você pode usar o Gemini de duas maneiras:

Vertex AI. O "caminho empresarial", entrelaçado com o GCP, que abordamos no capítulo 7 (GCF+Gemini). Toda a autenticação funciona magicamente, e os serviços se interconectam perfeitamente.
IA do Google. A "maneira do consumidor". Você recebe uma chave de API do Gemini neste link e começa a criar pequenos scripts que podem ser vinculados a qualquer carga de trabalho que você já tenha (trabalho reservado, outras nuvens, localhost etc.). Basta substituir a chave de API, e o código começa a funcionar magicamente.

Incentivamos você a explorar a (2) com seus próprios projetos de pets.

Aumento da interface

Não sou boa em interfaces. Mas o Gemini é! Você pode usar uma única página PHP e dizer algo como:

I have a VERY old PHP application. I want to touch it as little as possible. Can you help me:

1. add some nice CSS to it, a single static include for tailwind or similar, whatever you prefer
2. Transform the image print with description into cards, which fit 4 per line in the canvas?

Here's the code:

-----------------------------------
[Paste your PHP page, for instance index.php - mind the token limit!]

Você pode fazer isso facilmente em menos de cinco minutos com o Cloud Build. :)

A resposta do Gemini foi perfeita, ou seja, eu não precisei mudar nada:

E este é o novo layout no app pessoal do autor:

Observação: o código é colado como imagem, porque não queremos incentivar você a pegar o código, mas sim para que o Gemini escreva o código para você, com suas próprias restrições de interface/front-end de criativos. Mas acredite, você ainda vai fazer pequenas mudanças depois.

Segurança

Proteger adequadamente esse app não é o objetivo deste workshop de quatro horas.

Para algumas ideias, confira o SECURITY doc.

12. Parabéns!

Parabéns 🎉🎉🎉 , você modernizou seu aplicativo PHP legado com o Google Cloud.

Resumindo, você aprendeu neste codelab:

Como implantar um banco de dados MYSQL no Google Cloud SQL e como migrar seu banco de dados atual para ele.
Como contêinerizar seu aplicativo PHP com o Docker e os Buildpacks e armazenar a imagem no Google Cloud Artifact Registry
Como implantar um app conteinerizado no Cloud Run e fazer com que ele seja executado com o Cloud SQL.
Como armazenar/usar secretamente parâmetros de configuração sensíveis (como a senha do banco de dados) usando o Google Secret Manager
Como configurar o pipeline de CI/CD com o Google Cloud Build para criar e implantar automaticamente seu app PHP em qualquer envio de código para o repositório do GitHub.
Como usar o Cloud Storage para "migrar para a nuvem" os recursos do app
Como aproveitar as tecnologias sem servidor para criar fluxos de trabalho incríveis no Google Cloud sem tocar no código do app.
Use os recursos multimodais do Gemini para um caso de uso adequado.

Esse é um ótimo começo para sua jornada de modernização de aplicativos com o Google Cloud.

🔁 Feedback

Se você quiser relatar sua experiência com o workshop, preencha este formulário de feedback.

Agradecemos seu feedback e RPs relacionados aos códigos dos quais você mais se orgulha.

🙌 Obrigada

O autor gostaria de agradecer a Mirko Gilioli e Maurizio Ipsale, da Datatonic, pela ajuda na redação e no teste da solução.

Workshop de modernização de apps

1. Introdução

Como modernizar um aplicativo PHP antigo para o Google Cloud?

Sobre o app

Sua meta

O que é necessário

2. Configuração de crédito e Fork

Resgatar o crédito do GCP e configurar seu ambiente do GCP [opcional]

Ramificar o app do GitHub

3. Módulo 1: Criar uma instância do SQL

Crie a instância do Google Cloud SQL

Criar o banco de dados image_catalog e o usuário no Cloud SQL

Abra o banco de dados para IPs conhecidos.

É hora de testar a conexão do banco de dados!

Importar o banco de dados da base de código

4. Módulo 2: conteinerizar seu app PHP

Docker

Como testar o resultado no navegador

Buildpacks [opcional]

Como salvar no Artifact Registry [opcional]

5. Módulo 3: implantar o app no Cloud Run

Por que usar o Cloud Run?

Pré-requisitos

Antes da implantação

Implantar seu app no Cloud Run usando o gcloud

"gcloud run deploy" sem "perguntas"

6. Módulo 4: Limpar senhas com o Secret Manager

Primeira iteração: atualize o config.php para usar o ENV

Segunda iteração: Secret Manager

Criar uma nova revisão do Cloud Run

7. Módulo 5: configurar seu CI/CD com o Cloud Build

Por que usar um pipeline de CI/CD?

Conheça o Cloud Build!

Criar gatilho (e conectar repositório)

Eu tenho o poder!

Onde está o YAML do Cloud Build?

Como faço para confirmar o código no GitHub?

"Paridade de desenvolvimento/produção" profunda x superficial [opcional]

8. Módulo 6: Migrar para o Google Cloud Storage

Armazenamento

🤔 Migrar armazenamento (aberto)

Teste de aceitação

💡 Solução possível (montagens de volume do Cloud Run do GCS)

Crie um bucket do GCS

Configure o Cloud Run para montar o bucket na pasta /uploads/

O que aconteceu?

9. Módulo 7: Capacite seu app com o Google Gemini

Pré-requisitos

Configurar uma função do Cloud (em Python)

Configurar uma função do Cloud (🐍 Python)

Corrija o banco de dados para adicionar description às imagens

Escreva a função f(x) do Gemini

Como testar a função

Testes de unidade

Interface do Cloud Functions

Teste E2E

Atualizar o PHP para mostrar [opcional]

Conclusões

[Opcional] Adicionar mais funções do Cloud [sem fim definido]

📩 Acionar e-mail

🚫 Moderação automática de fotos inadequadas

Possíveis erros (principalmente IAM / permissões)

Erro: não há permissões suficientes para a conta de serviço

Erro: invocador do Cloud Run ausente

Erro: limite de memória excedido

Erro: PubSub publicado

Erro: a Vertex AI não foi usada

Erro: o acionador do EventArc não foi encontrado.

Erro: 400 agentes de serviço estão sendo provisionados

10. Módulo 8: Criar SLOs de disponibilidade

(sem resposta) Criar SLIs e SLOs para este app

O que é um SLO?

Etapa 1: criar um SLI/SLO de disponibilidade

Etapa 2: configurar o alerta para este SLO

Resultado final

11. Próximas etapas

Jogar com o Gemini

Aumento da interface

Segurança

12. Parabéns!

Corrija o banco de dados para adicionar `description` às imagens