Visão geral do Cloud Build

O Cloud Build é um serviço que executa suas versões no Google Cloud.

O Cloud Build pode importar o código-fonte de uma variedade de repositórios ou espaços do Cloud Storage, executar uma versão para suas especificações e produzir artefatos como contêineres Docker ou arquivos Java.

Também é possível usar o Cloud Build para proteger a cadeia de suprimentos de software. Os recursos do Cloud Build atendem aos requisitos dos níveis da cadeia de suprimentos para artefatos de software (SLSA) de nível 3. Para conferir orientações sobre como proteger seus processos de build, consulte Proteger builds.

Configuração da compilação e etapas de compilação

Você pode gravar uma configuração da versão para fornecer instruções ao Cloud Build sobre quais tarefas executar. Você pode configurar versões para buscar dependências, executar testes de unidade, análises estáticas e testes de integração e criar artefatos com ferramentas de versão, como docker, gradle, maven, bazel e gulp.

O Cloud Build executa sua versão como uma série de etapas de versão, em que cada uma delas é executada em um contêiner do Docker. Executar etapas de versão é análogo à execução de comandos em um script.

É possível usar as etapas de versão fornecidas pelo Cloud Build e pela comunidade dele ou gravar suas próprias etapas de versão personalizadas:

Cada etapa de criação é executada com o respectivo contêiner anexado a uma rede local do Docker chamada cloudbuild. Isso permite que as etapas de versão se comuniquem entre si e compartilhem dados. Para mais informações sobre a rede cloudbuild, consulte Rede do Cloud Build.

É possível usar imagens Docker Hub padrão no Cloud Build, como Ubuntu e Gradle.

Como iniciar versões

É possível iniciar manualmente build no o Cloud Build usando a Google Cloud CLI ou O Cloud Build API ou usar o modelo de build do Cloud Build gatilhos para Criar um fluxo de trabalho automatizado de integração/entrega contínua (CI/CD) que inicia novos builds em resposta a mudanças no código.

É possível integrar acionadores de versão com muitos repositórios de código, incluindo Cloud Source Repositories, GitHub e Bitbucket.

Como ver os resultados da compilação

É possível ver os resultados do build usando a CLI gcloud, a Cloud Build API ou use a página Histórico de builds na seção do Cloud Build do Console do Google Cloud, que exibe detalhes e registros de cada build O Cloud Build é executado. Para instruções, consulte Como visualizar builds Resultados.

Como funciona a versão

Nas etapas a seguir, descrevemos, de modo geral, o ciclo de vida de uma versão do Cloud Build:

  1. Prepare o código do seu aplicativo e os recursos necessários.
  2. Crie um arquivo de solicitação de versão, no formato YAML ou JSON, que contenha instruções para o Cloud Build.
  3. Envie a versão para o Cloud Build.
  4. O Cloud Build executa sua versão com base na solicitação de versão que você forneceu.
  5. Se aplicável, todos os artefatos criados são enviados para o Artifact Registry.

Docker

O Cloud Build usa o Docker para executar builds. Para cada etapa da criação, o Cloud Build executa um contêiner de Docker como uma instância de docker run. No momento, o Cloud Build está em execução o mecanismo do Docker versão 20.10.24.

Interfaces do Cloud Build

Use o Cloud Build com o Console do Google Cloud, a ferramenta de linha de comando gcloud ou a API REST do Cloud Build.

No console do Google Cloud, confira os resultados do build do Cloud Build na página Histórico do build e automatize os builds em Gatilhos de build.

Use a CLI gcloud para criar e gerenciar versões. Também é possível executar comandos para realizar tarefas como enviar uma build, listar builds e cancelar uma build.

Você pode solicitar versões usando a API REST Cloud Build.

Igual a outras APIs do Cloud Platform, você precisa autorizar o acesso usando OAuth2. Depois de autorizar o acesso, você pode usar a API para iniciar novas versões, ver o status e os detalhes da versão, listar versões por projeto e cancelar versões em execução.

Para saber mais informações, consulte a documentação da API.

Pools padrão e privados

Por padrão, quando você executa uma versão no Cloud Build, ela é executada em um ambiente hospedado e seguro com acesso à Internet pública. Cada versão é executada no próprio worker e está isolada de outras cargas de trabalho. É possível personalizar seu build de várias maneiras, incluindo aumentando o tamanho do tipo de máquina ou alocando mais espaço em disco. O pool padrão tem limites de personalização do ambiente, especialmente em torno do acesso à rede privada.

Pools particulares são pools particulares e dedicados de workers que oferecem maior personalização no ambiente de criação, incluindo a capacidade de acessar recursos em uma rede particular. Os pools particulares, semelhantes aos pools padrão, são hospedados e totalmente gerenciados pelo Cloud Build e escalonados para cima e para baixo até zero, sem infraestrutura para configurar, fazer upgrade ou escalonar. Como os pools privados são recursos específicos do cliente, é possível configurá-los de outras maneiras.

Para saber mais sobre pools particulares e a diferença de recursos entre e particular, consulte Visão geral do pool privado.

Criar segurança

O Cloud Build tem vários recursos para proteger builds, incluindo:

  • Compilações automatizadas

    Um build automatizado ou com script define todas as etapas no script de build. ou configuração do build, incluindo etapas para recuperar o código-fonte e etapas para criar o código. O único comando manual, se houver, é o para executar o build. O Cloud Build usa um arquivo de configuração do build para fornecer etapas de build ao Cloud Build.

    Builds automatizados proporcionam consistência nas etapas de build. No entanto, também é para executar builds em um ambiente consistente e confiável.

    Embora builds locais possam ser úteis para fins de depuração, o lançamento de softwares de builds locais pode introduzir muitas preocupações de segurança, inconsistências e e ineficiências no processo de criação.

    • Permitir builds locais oferece uma maneira de um invasor com intenção maliciosa modificar o processo de build.
    • Inconsistências nos ambientes locais e nas práticas de desenvolvimento dificultam a reprodução de builds e o diagnóstico de problemas.

    Nos requisitos do framework SLSA, os builds automatizados são um requisito para o nível 1 do SLSA, e o uso de um serviço de build em vez de ambientes de desenvolvedor para builds é um requisito para o nível 2 do SLSA.

  • Procedência do build

    A procedência do build é uma coleção de dados verificáveis sobre um build.

    Os metadados de procedência incluem detalhes como os resumos das imagens criadas, os locais de origem de entrada, o conjunto de ferramentas e a duração do build.

    A geração da procedência do build ajuda você a:

    • Verifique se um artefato construído foi criado a partir de um local de origem confiável e um sistema de build confiável.
    • Identifique o código injetado de um local de origem ou sistema de build não confiável.

    É possível usar mecanismos de alerta e política para usar proativamente a procedência do build dados. Por exemplo, é possível criar políticas que permitam apenas implantações de código criados a partir de fontes verificadas.

    O Cloud Build pode gerar procedência do build para imagens de contêiner que oferecem garantia de nível 3 da SLSA. Para mais informações, consulte Como visualizar a procedência do build.

  • Ambiente de build temporário

    Ambientes temporários são ambientes temporários que duram uma única invocação de build. Após a criação, o ambiente é excluído permanentemente ou excluído. Builds efêmeros garantem que o serviço e as etapas de build em um ambiente temporário, como um contêiner ou uma VM. Em vez de reutilizar um ambiente de build existente, o serviço de build provisiona um novo ambiente para cada build e depois a destrói após a conclusão do processo de compilação.

    Ambientes temporários garantem builds limpos porque não há arquivos residuais ou do ambiente de builds anteriores que possam interferir no build de desenvolvimento de software. Um ambiente não temporário oferece uma oportunidade para que invasores injetem arquivos e conteúdo maliciosos. Um ambiente temporário também reduz a sobrecarga de manutenção e reduz inconsistências no ambiente de build.

    O Cloud Build configura uma nova máquina virtual para cada build e o destrói depois da criação.

  • Políticas de implantação

    É possível integrar o Cloud Build com autorização binária para verificar atestados de versão e bloquear implantações de imagens que não são geradas pelo Cloud Build. Esse processo pode reduzir o risco para implantar softwares não autorizados.

  • Chaves de criptografia gerenciadas pelo cliente

    O Cloud Build fornece chaves de criptografia gerenciadas pelo cliente (CMEK) a conformidade por padrão. Os usuários não precisam configurar nada especificamente. O Cloud Build oferece conformidade com a CMEK criptografando o disco permanente (DP) com tempo de build com uma chave temporária que é gerada para cada build. A chave é exclusivamente gerados para cada build.

    Assim que o build é concluído, a chave é apagada da memória e destruída. Ele não é armazenado em nenhum lugar, não pode ser acessado por engenheiros do Google nem pela equipe de suporte e não pode ser restaurado. Os dados protegidos com essa chave ficam permanentemente inacessível. Para mais informações, consulte Conformidade com CMEK no Cloud Build.

  • Painel de insights de segurança

    O Cloud Build inclui um painel Insights de segurança na console do Google Cloud que mostra os aspectos gerais de várias métricas de segurança. Você pode usar esse painel para identificar e mitigar riscos em o processo de build.

    Esse painel exibe as seguintes informações:

    • Nível da cadeia de suprimentos para artefatos de software (SLSA): identifica o nível de maturidade do seu processo de criação de software de acordo com a especificação SLSA).

    • Vulnerabilidades: informações gerais das vulnerabilidades encontradas nos artefatos e o nome da imagem que Análise de artefatos verificado. Clique no nome da imagem para conferir os detalhes da vulnerabilidade. Por exemplo, na captura de tela, você pode clicar em java-guestbook-backend.

    • Detalhes da versão: detalhes da versão, como o builder e o link para e conferir os registros.

    • Procedência do build: procedência do build.

  • Software Delivery Shield (link em inglês)

    O Cloud Build faz parte da solução Software Delivery Shield. O Software Delivery Shield é uma solução de segurança da cadeia de suprimentos de software completa e totalmente gerenciada que ajuda você a melhorar a postura de segurança dos fluxos de trabalho e ferramentas de desenvolvedores, dependências de software, sistemas de CI/CD usados para criar e implantar seu software e ambientes de execução, como o Google Kubernetes Engine e o Cloud Run. Para saber como é possível usar o Cloud Build com outros componentes do Software Delivery Shield para melhorar a postura de segurança da cadeia de suprimentos de software, consulte Visão geral do Software Delivery Shield.

A seguir