Visão geral do ambiente de execução de SaaS

O ambiente de execução de SaaS permite armazenar, hospedar, gerenciar e monitorar aplicativos de software como serviço (SaaS) no Google Cloud. O ambiente de execução de SaaS gerencia implantações do Terraform em escala, permitindo que você gerencie o aplicativo SaaS e a infraestrutura em que ele é executado.

O ambiente de execução de SaaS pode ser usado de várias maneiras por diferentes partes interessadas no pipeline de SaaS. Se o seu trabalho se identifica com alguma destas funções, talvez você tenha interesse em usar o ambiente de execução de SaaS:

  • Administrador da plataforma
  • Desenvolvedor de aplicativos
  • Arquiteto
  • Administrador de compliance
  • Engenheiro de plataforma
  • Operações financeiras

O ambiente de execução de SaaS oferece os seguintes benefícios:

  • Simplifique o gerenciamento de serviços em grande escala automatizando tarefas como implantação, lançamentos e gerenciamento de flag de recurso em locatários de SaaS.
  • Aumente a capacidade de observação e o controle ajustando atualizações e lançamentos em unidades configuráveis para gerenciar sua oferta de SaaS com precisão em grande escala.
  • Crie consistência em todo o seu Google Cloud ecossistema gerenciando serviços em vários Google Cloud produtos, incluindo Google Cloud, Google Distributed Cloud, faturamento, observabilidade e Resource Manager.
  • Use uma arquitetura flexível e com capacidade de modelos que promova atualizações e implantações de grupos baseadas em unidades para melhorar a eficiência e a reutilização.

Como funciona o ambiente de execução de SaaS?

O ambiente de execução do SaaS implanta artefatos que definem sua solução de SaaS. Esses artefatos precisam ter uma configuração do Terraform. A implantação é organizada em unidades distintas que podem ser atualizadas com versões que contêm mudanças na sua oferta por um processo de lançamento configurável.

Para mais informações sobre a nomenclatura do ambiente de execução de SaaS, consulte o Glossário.

Prepare sua carga de trabalho para o ambiente de execução de SaaS

Antes de implantar sua solução de SaaS, recomendamos que você determine a organização ideal dela no ecossistema do ambiente de execução de SaaS.

Organize as partes da sua oferta de SaaS que precisam ser atualizadas ou modificadas juntas em configurações distintas do Terraform. Ao planejar sua oferta de SaaS, use tipos de unidade para cada agrupamento.

Depois de definir a estrutura ideal para sua carga de trabalho no ambiente de execução de SaaS, crie sua oferta de SaaS, tipos de unidades e implante as unidades usando um lançamento.

Para ver um exemplo da configuração do ambiente de execução do SaaS, consulte o guia de início rápido.

Contas de serviço do ambiente de execução de SaaS

O ambiente de execução de SaaS usa uma combinação de contas de serviço gerenciadas pelo Google e pelo usuário:

  • Conta de serviço do ambiente de execução do SaaS (gerenciada pelo Google): essa conta é criada automaticamente após a criação do primeiro recurso de oferta de SaaS. Ele é gerenciado pelo Google. Ele realiza ações em seu nome, como interagir com outros serviços do Google Cloud durante o provisionamento de unidades.

  • Conta de serviço de ativação (gerenciada pelo usuário): você cria e gerencia essa conta de serviço. O ambiente de execução de SaaS (pelo Infrastructure Manager) usa essa conta para executar suas configurações do Terraform ao provisionar ou atualizar unidades. Essa conta atua como a identidade para criar e gerenciar os recursos definidos no Terraform. As permissões da conta de serviço de ação estão diretamente vinculadas aos recursos gerenciados pela configuração do Terraform.

    É possível ter várias contas de serviço de ativação. Recomendamos que você tenha uma conta de serviço de ativação para cada locatário.

  • Opcional: conta de serviço de criação de artefatos (gerenciada pelo usuário): essa conta de serviço é usada para criar e fazer upload do Terraform empacotado em artefatos OCI. Geralmente, é uma conta de serviço do Cloud Build, mas pode ser qualquer conta de serviço com as permissões adequadas para sua oferta de SaaS.

Conta de serviço do ambiente de execução de SaaS (gerenciada pelo Google)

A conta de serviço do ambiente de execução de SaaS é um agente de serviço gerenciado pelo Google usado pelo ambiente de execução de SaaS para realizar operações no seu projeto.

Essa conta de serviço é provisionada automaticamente quando você cria seu primeiro recurso do ambiente de execução do SaaS. A conta de serviço do ambiente de execução do SaaS é criada usando este formato:

  service-PROJECT_NUMBER@gcp-sa-saasservicemgmt.iam.gserviceaccount.com

Substitua:

  • PROJECT_NUMBER: o número do projeto.

Conta de serviço de acionamento (gerenciada pelo usuário)

A conta de serviço de ação é uma conta serviço gerenciado pelo usuário que você precisa criar. O ambiente de execução de SaaS (pelo Infra Manager) usa essa conta de serviço para executar suas configurações do Terraform. É a identidade que cria, modifica e exclui os recursos definidos no Terraform.

Você é responsável por criar essa conta de serviço no seu projeto ou no projeto do locatário.

Variáveis de entrada da conta de serviço de acionamento

Ao criar uma unidade, você precisa fornecer a conta de serviço de atuação como uma variável de entrada de par de chave-valor para a configuração do Terraform:

  • Nome: actuation_sa
  • Tipo de variável: String
  • Valor da variável: endereço de e-mail da conta de serviço de ativação:

    my-actuation-sa@my-identifier.iam.gserviceaccount.com
    

Permissões exigidas

A conta de serviço de ação precisa de permissões suficientes para gerenciar os recursos definidos na configuração do Terraform. No mínimo, ele precisa:

  • roles/iam.serviceAccountTokenCreator: permite que a conta de serviço gere tokens para autenticação.
  • roles/config.admin: concede controle total sobre os recursos do Infra Manager.
  • roles/storage.admin: concede controle total do Cloud Storage.

A conta de serviço de ativação também precisa de permissões para criar e gerenciar os recursos Google Cloud específicos usados pelo aplicativo.

Exemplo:

  • Se o Terraform criar clusters do Google Kubernetes Engine (GKE), a conta de serviço precisará das funções apropriadas do GKE (por exemplo, roles/container.admin).
  • Se o Terraform criar instâncias do Compute Engine, a conta de serviço precisará da função roles/compute.admin.
  • Se o Terraform criar instâncias do Cloud SQL, a conta de serviço precisará ter os papéis apropriados do Cloud SQL (roles/cloudsql.admin, por exemplo).

Consulte a documentação de cada recurso do Google Cloud usado no Terraform para determinar as permissões necessárias. Conceda o privilégio mínimo necessário para o funcionamento do aplicativo.

Conta de serviço de criação de artefatos (gerenciada pelo usuário)

A conta de serviço de criação de artefatos é uma conta serviço gerenciado pelo usuário que você cria para usar um sistema de build (como o Cloud Build) para empacotar e fazer upload dos seus artefatos do Terraform para o Artifact Registry.

Essa conta de serviço é separada das contas de serviço de execução e acionamento do SaaS, cria seu código do Terraform e envia o artefato resultante para o Artifact Registry. Muitas vezes, essa é a conta de serviço do Cloud Build.

Criação manual de artefatos

Se você criar e fazer upload manualmente dos seus artefatos do Terraform (usando Docker build e Docker push diretamente, por exemplo), não vai precisar de uma conta de serviço separada para criação de artefatos.

Em vez disso, autentique-se usando suas próprias credenciais ou uma conta de serviço com as permissões necessárias do Artifact Registry.

Permissões exigidas

Se você estiver usando o Cloud Build, a conta de serviço dele geralmente precisará dos seguintes papéis:

  • roles/artifactregistry.writer: para enviar artefatos ao Artifact Registry.
  • roles/artifactregistry.repoAdmin: para gerenciar o repositório do Artifact Registry.
  • roles/storage.admin: para gerenciar os buckets do Cloud Storage.
  • roles/developerconnect.admin: permissões para usar o Developer Connect.
  • roles/developerconnect.readTokenAccessor: permissões para receber o token de leitura do Developer Connect.
  • roles/logging.logWriter: permissões para gravar registros.
  • Se você estiver implantando a configuração do Terraform usando o Developer Connect: roles/cloudbuild.builds.builder: para executar builds.
  • Qualquer outra permissão exigida pelo processo de build (por exemplo, acesso a repositórios de código-fonte).

Estratégias de lançamento

O ambiente de execução de SaaS usa várias estratégias de lançamento para gerenciar como as unidades na oferta de SaaS são atualizadas. Essas estratégias de lançamento seguem a abordagem de mudança doGoogle Cloud (em inglês) ao aplicar abordagens consistentes à implantação de mudanças na sua oferta de SaaS.

Use estratégias de lançamento para minimizar os impactos negativos nos clientes e isolar problemas em domínios de falha lógica e física. Defina suas estratégias de lançamento criando um tipo de lançamento que especifique uma das seguintes estratégias:

  • Um local por vez (simples): um local é lançado por vez, sem espera entre eles. As unidades são selecionadas arbitrariamente em um local, com um máximo de 20% das unidades do local atualizadas por vez.

    Essa estratégia é recomendada para ambientes de desenvolvimento e situações de emergência.

  • Tudo de uma vez (simples): todos os locais começam a ser lançados ao mesmo tempo.

    Essa estratégia é recomendada para ambientes de desenvolvimento e situações de emergência.

  • Progressiva (gradual): em cada local, as unidades são lançadas em lotes estáticos com base em porcentagens (por exemplo, 1%, 10%, 20%, 30%, ~40%) com tempos de espera entre os lotes. Em todos os locais, o lançamento progride com um aumento exponencial no número de locais simultâneos (por exemplo, um local, depois dois, depois quatro) com tempos de espera (por exemplo, 18 horas) entre as ondas. As unidades em um local são selecionadas aleatoriamente.

    Essa estratégia foi criada para lançamentos seguros e previsíveis em vários locais. Ela começa com uma pequena área de cobertura e se expande gradualmente à medida que a confiança aumenta. Essa estratégia é recomendada em ambientes de produção com mais de um local.

  • Progressivo (local único): as unidades são atualizadas em lotes estáticos com base em porcentagens (por exemplo, 1%, 10%, 20%, 30%, ~40%) com tempos de imersão mais longos (18 horas, por exemplo) entre os lotes para permitir tempo suficiente para detecção de problemas e limitar o impacto negativo das mudanças de lançamento.

    Essa estratégia é adaptada a ofertas de SaaS que operam em um único local, priorizando a segurança e a cautela. Recomendamos essa estratégia em ambientes de produção com um local.

Para mais informações sobre como criar tipos de lançamento, consulte Criar um tipo de lançamento.

Regionalização do ambiente de execução de SaaS

Os recursos de oferta de SaaS definem onde as unidades do ambiente de execução de SaaS podem residir e como os lançamentos são gerenciados. Quando você cria uma oferta de SaaS, as regiões selecionadas servem como uma única fonte de verdade para as regiões compatíveis da sua oferta de SaaS. As regiões selecionadas são as regiões disponíveis que você definiu para sua oferta de SaaS.

Quando você usa o ambiente de execução de SaaS pelo console Google Cloud , ele automatiza a replicação dos recursos definidos na sua oferta de SaaS em todas as regiões. Isso garante a consistência e a disponibilidade dos recursos do ambiente de execução de SaaS em todas as regiões disponíveis que você definiu na sua oferta de SaaS.

O ambiente de execução de SaaS replica estes recursos:

  • Oferta de SaaS (Saas)
  • Tipo de unidade (UnitKind)
  • Versão (Release)

Usar global como uma região

Incluir global como uma região na sua oferta de SaaS geralmente não é recomendado para destinos de implantação. O ambiente de execução de SaaS usa a região global para propagar lançamentos regionais. Os lançamentos regionais não podem ser executados na região global.

Regionalização do lançamento

Os locais compatíveis para lançamentos são determinados pelas regiões de nível superior definidas nas regiões disponíveis da sua oferta de SaaS.

Os lançamentos leem a lista de regiões disponíveis da oferta de SaaS associada.

Replicação de recursos

O ambiente de execução de SaaS processa a criação e as atualizações de recursos em todas as regiões disponíveis da sua oferta de SaaS.

Quando você atualiza as regiões disponíveis da sua oferta de SaaS, o ambiente de execução de SaaS processa a replicação:

  • Locais adicionados:os recursos são replicados para os locais recém-adicionados.
  • Unidades com cópias antigas:o conteúdo é atualizado.

Locais do Artifact Registry e do Developer Connect

Os locais do repositório do Artifact Registry e da instância do Developer Connect têm requisitos específicos:

  • A região do repositório do Artifact Registry e da instância do Developer Connect pode ser qualquer região Google Cloud válida. Não é necessário incluir essas regiões na oferta de SaaS.

  • A região do repositório do Artifact Registry precisa corresponder à região da instância do Developer Connect.

    Isso exige a presença de recursos de tipo oferta, lançamento e unidade de SaaS em todas as regiões definidas na sua oferta de SaaS, mesmo que o Artifact Registry e o Developer Connect estejam em uma única região (potencialmente diferente).

  • As unidades só podem ser criadas nas regiões especificadas na sua oferta de SaaS.

Exemplo de configuração de regiões do ambiente de execução de SaaS

Fornecemos este exemplo para demonstrar como a regionalização funciona ao usar o SaaS Runtime com replicação de recursos gerenciados.

Por exemplo, se você quiser implantar sua oferta de SaaS em us-central1 e europe-west4, hospedando seu repositório do Artifact Registry e a instância do Developer Connect em us-east1, a infraestrutura de regiões do ambiente de execução de SaaS seria algo assim:

  • Regiões disponíveis para a oferta de SaaS:['us-central1', 'europe-west4']
  • Região do repositório do Artifact Registry: us-east1
  • Região da instância do Developer Connect: us-east1
  • Tipo de unidade e recursos de lançamento: o ambiente de execução de SaaS gerencia a criação e as atualizações desses recursos nas regiões global, us-central1 e europe-west4.
  • Unidades:as unidades podem ser criadas em us-central1 ou europe-west4

Essa configuração permite gerenciar implantações em duas regiões e manter o gerenciamento de artefatos centralizado em uma terceira região distinta com replicação automatizada de recursos. Considere cuidadosamente os requisitos de latência, compliance e residência de dados ao selecionar as regiões.

A seguir