A operação de uma plataforma de desenvolvedor e aplicativos conteinerizados requer uma série de tarefas administrativas diferentes, que você precisa realizar continuamente. Essas tarefas incluem, por exemplo, criar aplicativos usando um modelo, autorizar novos grupos de desenvolvedores a usar a plataforma para desenvolvedores, planejar necessidades de capacidade e depurar problemas no ambiente de execução.
As operações podem ser automatizadas ou realizadas manualmente.
Operações automatizadas comuns
O blueprint fornece automação para algumas das tarefas mais comuns na forma de gatilhos de webhook, que são um tipo simples de API. Os gatilhos são conectados automaticamente a eventos de webhook que vêm de um dos repositórios de controle de origem. Os desenvolvedores da plataforma do desenvolvedor podem conectar os outros gatilhos. Normalmente, os desenvolvedores da plataforma do desenvolvedor escrevem um portal do desenvolvedor, que pode ser um formulário da Web simples que chama um gatilho de webhook quando um formulário é enviado.
Na tabela a seguir, descrevemos as tarefas comuns que o blueprint automatiza usando gatilhos de webhook. As frequências de tarefa são ilustrativas, porque essa frequência depende de muitos fatores. As tarefas não se repetem necessariamente em intervalos precisos.
| Tarefa | Usuário | Descrição | Frequência das tarefas |
|---|---|---|---|
Adicione um locatário. |
Administrador da plataforma do desenvolvedor |
O administrador envia um formulário no portal do desenvolvedor. Os campos do formulário de locatário incluem o nome do locatário e os membros da equipe. Um gatilho automatizado cria os recursos para o novo locatário. |
Algumas vezes por ano |
Adicione um aplicativo com base em um modelo de aplicativo. |
Desenvolvedor de aplicativos |
O desenvolvedor envia um formulário no portal. Os novos campos do formulário de aplicativo incluem o nome do locatário, o nome do aplicativo e o modelo base de aplicativo. Um gatilho automatizado cria recursos para um novo aplicativo. |
Algumas vezes por ano |
Criar e implantar alterações no código-fonte de um aplicativo no ambiente de desenvolvimento. |
Desenvolvedor de aplicativos |
O desenvolvedor edita o código-fonte, executa e testa o código localmente e o confirma. O blueprint não está envolvido nos fluxos de trabalho do desenvolvedor local, mas a ferramenta Skaffold é compatível com uma etapa de versões locais. |
Algumas vezes por dia para cada app |
Implantar as alterações de configuração do YAML de um aplicativo no ambiente de desenvolvimento. Um exemplo de alteração na configuração do YAML é aumentar a CPU de um recurso de implantação. |
Desenvolvedor de aplicativos |
O desenvolvedor edita a configuração do aplicativo e confirma a alteração. |
Algumas vezes por semana para cada app |
Implantar as alterações da infraestrutura de aplicativos no ambiente de desenvolvimento. A infraestrutura do aplicativo são os recursos da nuvem no projeto de um aplicativo. Um exemplo de alteração é um aumento na contagem de CPUs de uma instância do AlloyDB para PostgreSQL. |
Desenvolvedor de aplicativos |
O desenvolvedor edita o projeto do Terraform do recurso do aplicativo e confirma a alteração. O desenvolvedor envia um formulário no portal. Um gatilho automatizado inicia o pipeline de plano e aplicação. |
Muitas vezes por ano |
Promova mudanças de aplicativos de desenvolvimento para não produção (ou de não produção para produção). As mudanças no aplicativo podem incluir novas imagens ou alterações de configuração do YAML do aplicativo. |
Operador do aplicativo |
O operador mescla as alterações da ramificação de desenvolvimento com a de não produção (ou da ramificação de não produção para a de produção). O operador supervisiona o lançamento. |
Várias vezes por semana para cada inscrição |
Promova mudanças na infraestrutura aplicativos de desenvolvimento para não produção (ou de não produção para produção). |
Operador do aplicativo |
O operador mescla alterações selecionadas da ramificação de desenvolvimento para a ramificação de não produção (ou da ramificação de não produção para a de produção). O operador supervisiona o lançamento. |
Várias vezes a cada trimestre para cada app |
Operações manuais comuns
Algumas operações da plataforma do desenvolvedor são menos estruturadas e não usam automação com uma plataforma. É possível desenvolver seus próprios playbooks com base nesse blueprint e realizar essas tarefas no console do Google Cloud.
A tabela a seguir descreve essas tarefas não automatizadas. As frequências de tarefa são ilustrativas, porque essa frequência depende de muitos fatores. As tarefas não se repetem necessariamente em intervalos precisos.
| Tarefa | Usuário | Descrição | Frequência das tarefas |
|---|---|---|---|
Defina um novo modelo de aplicativo. |
Desenvolvedor da plataforma para desenvolvedores |
O desenvolvedor modifica um modelo de aplicativo baseado em um modelo de blueprint ou transfere um modelo para um novo idioma. |
Algumas vezes por ano |
Investigue erros de ambiente de execução do serviço no ambiente de desenvolvimento. |
Desenvolvedor de aplicativos |
O desenvolvedor usa a Análise de registros e o Metrics Explorer no console do Google Cloud para analisar registros de erros, métricas de monitoramento e dados de série temporal de locatários e aplicativos. |
Algumas vezes por mês |
Investigue erros de ambiente de execução do serviço em ambientes de produção ou não. |
Operador do aplicativo |
O operador usa a Análise de registros e o Metrics Explorer no console do Google Cloud para analisar registros de erros, métricas de monitoramento e dados de série temporal para locatários e aplicativos. |
Algumas vezes por mês |
Investigue erros de build. |
Os desenvolvedores de aplicativos |
O desenvolvedor vê o histórico do Cloud Build, incluindo o status e os registros da versão, no console do Google Cloud. |
Algumas vezes por semana |
Investigar erros de implantação no ambiente de desenvolvimento |
Os desenvolvedores de aplicativos |
O desenvolvedor vê o histórico de versões e lançamentos do Cloud Deploy no console do Google Cloud para ver o status e os registros de uma tentativa de implantação, incluindo erros. |
Algumas vezes por mês |
Investigue erros de implantação nos ambientes de não produção e produção |
Operadores de aplicativos |
O operador visualiza o histórico de versões e lançamentos do Cloud Deploy no console do Google Cloud para ver o status de sucesso e os registros de uma tentativa de implantação, incluindo registros de erros. |
Algumas vezes por mês |
Conecte-se a clusters para depurar problemas do GKE. |
Administrador da plataforma do desenvolvedor |
O administrador usa o gateway de conexão para se conectar a clusters particulares. Para problemas comuns, como pods não programados, o administrador pode analisar informações sobre problemas comuns (como pods não programados) no console do Google Cloud. |
Algumas vezes por mês |
Planejar a capacidade e otimizar os custos. |
Administrador da plataforma do desenvolvedor |
O administrador analisa a utilização de recursos do GKE, agregada por escopo ou namespace, no console do Google Cloud. |
Programado como uma tarefa recorrente mensal. |
Redimensione, adicione ou remova pools de nós. |
Administrador da plataforma do desenvolvedor |
O administrador edita a IaC conforme apropriado e reimplanta os aplicativos. |
Feito em resposta ao planejamento de capacidade. |
Verifique a postura de segurança. |
Administrador da plataforma do desenvolvedor |
O administrador verifica se há vulnerabilidades e a conformidade com os padrões usando o painel de postura de segurança do GKE. |
Programado como uma tarefa recorrente mensal. |
Faça upgrade das versões do software de sistema de clusters (por exemplo, a versão do Kubernetes). |
Administrador da plataforma do desenvolvedor |
O administrador usa as janelas de manutenção e exclusões do GKE para permitir upgrades apenas durante os horários planejados. O administrador usa a janela de upgrade aberta no ambiente de desenvolvimento primeiro. Depois de avaliar a integridade do upgrade, o administrador atualiza o ambiente de não produção e, em seguida, o de produção. |
Programado como uma tarefa trimestral recorrente. |
Instale atualizações críticas de segurança de cluster. |
Nenhum |
Automático, feito pelo GKE. |
Algumas vezes por ano |
Teste o failover regional. |
Administrador da plataforma do desenvolvedor e administrador de aplicativos |
Os administradores programam e iniciam manualmente um failover regional do ambiente, conforme apropriado. |
Anual como parte dos exercícios de recuperação de desastres |
Adicione uma região. |
Administrador da plataforma do desenvolvedor, desenvolvedor da plataforma do desenvolvedor e administrador de aplicativos |
O administrador da plataforma do desenvolvedor implanta outros clusters do GKE na nova região. O administrador atualiza o modelo do aplicativo para adicionar a nova etapa de implantação nos ambientes relevantes. Em seguida, o operador do aplicativo integra a mudança para adicionar a sequência de implantação para incluir a nova região. |
Quase nunca |
Mude para uma nova região. |
Administrador da plataforma do desenvolvedor, desenvolvedor da plataforma do desenvolvedor e administrador de aplicativos |
Os usuários adicionam a nova região conforme descrito em Adicionar uma região. Depois de testar a nova configuração, os usuários removem a região antiga. |
Quase nunca |
A seguir
- Leia sobre como gerenciar custos e atribuições para a plataforma do desenvolvedor (próximo documento desta série).