Visão geral do Cloud Build

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

O Cloud Build é um serviço que executa seus builds 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 ajudar a proteger sua cadeia de suprimentos de software. Os recursos do Cloud Build atendem aos requisitos de nível 3 da cadeia de suprimentos para artefatos de software (SLSA, na sigla em inglês). Para ver orientações sobre como proteger seus processos de compilação, consulte Proteger versões.

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 builds manualmente no Cloud Build usando a Google Cloud CLI ou a API Cloud Build

É 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 do build

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

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á executando o Docker Engine versão 20.10.17.

Interfaces do Cloud Build

É possível usar 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, é possível ver os resultados do build do Cloud Build na página Histórico do build e automatizar builds em Gatilhos de build.

Use a CLI gcloud para criar e gerenciar builds. Também é possível executar comandos para realizar tarefas como enviar um build, listar builds e cancelar um 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 pools particulares

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 o pool padrão e o pool privado, consulte Visão geral do pool privado.

Criar segurança

O Cloud Build oferece vários recursos para proteger suas versões, incluindo:

  • Compilações automáticas

    Uma versão automatizada ou com script define todas as etapas de compilação no script ou na 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 de executar o build. O Cloud Build usa um arquivo de configuração de build para fornecer etapas de build ao Cloud Build.

    Os builds automatizados oferecem consistência nas etapas de build. No entanto, também é importante executar versões em um ambiente consistente e confiável.

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

    • Permitir versões locais oferece uma maneira de um invasor com intenção maliciosa modificar o processo de compilação.
    • inconsistências nos ambientes e práticas locais do desenvolvedor dificultam a reprodução de builds e o diagnóstico de problemas de build.

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

  • Criar procedência

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

    Esses metadados incluem detalhes como os resumos das imagens criadas, os locais de origem de entrada, o conjunto de ferramentas de compilação e a duração da compilação.

    Gerar procedência do build ajuda você a:

    • Verificar se um artefato criado foi criado a partir de um local de origem confiável e por um sistema de compilação confiável.
    • Identifique o código injetado de um sistema de compilação ou local de origem não confiável.

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

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

  • Ambiente de compilação temporário

    Os ambientes efêmeros são temporários e precisam durar uma única invocação do build. Após a criação, o ambiente é excluído permanentemente ou excluído. As versões efêmeras garantem que o serviço de compilação e as etapas de compilação sejam executados 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 o destrói após a conclusão do processo.

    Ambientes efêmeros garantem builds limpos, já que não há arquivos residuais ou configurações de ambiente de builds anteriores que podem interferir no processo de build. Um ambiente não temporário oferece uma oportunidade para os invasores injetarem arquivos e conteúdos 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 um novo ambiente de máquina virtual para cada build, destruindo-o após a criação.

  • Políticas de implantação

    Você pode integrar o Cloud Build com autorização binária para verificar atestados de build e bloquear implantações de imagens não geradas pelo Cloud Build. Esse processo pode reduzir o risco de implantação de software não autorizado.

  • Chaves de criptografia gerenciadas pelo cliente

    O Cloud Build oferece conformidade com chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) por padrão. Os usuários não precisam configurar nada especificamente. O Cloud Build oferece conformidade com o CMEK criptografando o disco permanente (PD) por tempo de compilação com uma chave temporária gerada para cada build. A chave é gerada exclusivamente 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 pelos engenheiros ou equipe de suporte do Google e não pode ser restaurado. Os dados protegidos com essa chave ficam permanentemente inacessíveis. Para mais informações, consulte Compliance com CMEK no Cloud Build.

  • Painel de insights de segurança

    O Cloud Build inclui um painel Insights de segurança no Console do Google Cloud que exibe uma visão geral de alto nível de várias métricas de segurança. Use esse painel para identificar e reduzir riscos no seu processo de compilação.

    Esse painel mostra as seguintes informações:

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

    • Vulnerabilidades: uma visão geral de todas as vulnerabilidades encontradas nos seus artefatos e o nome da imagem que o Container Analysis verificou. Clique no nome da imagem para ver os detalhes da vulnerabilidade. Por exemplo, na captura de tela, clique em java-guestbook-backend.

    • Detalhes do build: detalhes do build, como o builder e o link para ver registros.

    • Procedência do build: destaque para o build.

  • Escudo de entrega de software

    O Cloud Build faz parte da solução Software Delivery Shield. O Software Delivery Shield é uma solução de segurança de cadeia de suprimentos de software totalmente gerenciada e completa que ajuda a melhorar a postura de segurança de fluxos de trabalho e ferramentas para 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 usar o Cloud Build com outros componentes do Software Delivery Shield (Escudo de entrega de software) para melhorar a postura de segurança da sua cadeia de suprimentos de software, consulte a Visão geral do Software Delivery Shield (link em inglês).

A seguir