Implantar um blueprint de zona de destino

Use o Config Controller para implantar e gerenciar de maneira declarativa uma zona de destino no Google Cloud.

Este tutorial ajuda os administradores da organização a configurar o Google Cloud para cargas de trabalho empresariais escalonáveis e prontas para produção implantando um blueprint de zona de destino, que inclui práticas recomendadas para rede, segurança e gerenciamento de recursos.

Objetivos

No processo de implantação da zona de destino, você irá:

  1. Configurar o Config Controller e configurá-lo para sincronizar os recursos em um repositório Git com o ambiente do Google Cloud.
  2. Descobrir blueprints que capturam padrões de design comuns para o Google Cloud, como a implantação de uma VPC compartilhada.
  3. Criar um pipeline de implantação opinativo (com base no Cloud Build) que permite personalizar blueprints, transformá-los com funções kpt e implantar recursos usando o Config Connector.

Esses componentes são combinados no fluxo de trabalho representado no diagrama a seguir:

Um administrador da plataforma que implanta blueprints com o Config Controller

Custos

Antes de começar

Antes de configurar a zona de destino, você precisará preparar alguns detalhes.

  1. Faça login na sua Conta do Google.

    Se você ainda não tiver uma, inscreva-se agora.

  2. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  3. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  4. Instale e inicialize o SDK do Cloud..
  5. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  6. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  7. Instale e inicialize o SDK do Cloud..
  8. Crie Grupos do Google que serão usados para conceder acesso à sua organização. Especificamente, é necessário ter um grupo para administradores da organização e outro para administradores de faturamento.
  9. Instale as ferramentas do Kubernetes (nomos, kubectl, e kpt) usadas para este tutorial. Você também pode instalar os componentes diretamente nas respectivas páginas.
    gcloud components install pkg

Como preparar o ambiente

Antes de implantar o blueprint da zona de destino, você precisa definir algumas variáveis de ambiente:

export PROJECT_ID=PROJECT_ID
export CONFIG_CONTROLLER_NAME=config-controller-1
export BILLING_ACCOUNT=$(gcloud alpha billing projects describe $PROJECT_ID \
  '--format=value(billingAccountName)' | sed 's/.*\///')
export ORG_ID=$(gcloud projects get-ancestors ${PROJECT_ID} --format='get(id)' | tail -1)
gcloud config set project ${PROJECT_ID}

Substitua:

  • PROJECT_ID: o ID do projeto em que o Config Controller será hospedado

Como configurar o Config Controller

O Config Controller fornece um plano de controle gerenciado, baseado no Kubernetes, para configurar os recursos de nuvem. Ele vem pré-instalado com o Policy Controller, o Config Sync e o Config Connector.

  1. No projeto, ative a API Config Controller e a API GKE de que o Config Controller depende:
     gcloud services enable krmapihosting.googleapis.com container.googleapis.com
    
  2. Crie seu controlador de configuração. Essa operação pode levar mais de 15 minutos.
    gcloud alpha anthos config controller create ${CONFIG_CONTROLLER_NAME} \
      --location=us-central1
  3. Verifique se o Config Controller foi criado com sucesso:
    gcloud alpha anthos config controller list --location=us-central1
  4. Autentique-se no Config Controller para começar a aplicar a configuração:
    gcloud alpha anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \
      --location us-central1
  5. Conceda permissão ao Config Controller para gerenciar o recurso do Google Cloud no projeto de gerenciamento:
    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
      -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${SA_EMAIL}" \
      --role "roles/owner" \
      --project "${PROJECT_ID}"
  6. Conceda permissão ao Config Controller para gerenciar recursos no nível da organização a fim de implantar o blueprint da zona de destino:
    gcloud organizations add-iam-policy-binding $ORG_ID \
      --role=roles/resourcemanager.organizationAdmin \
      --condition=None \
      --member="serviceAccount:${SA_EMAIL}"

Como criar um pipeline do GitOps

Ao configurar o Config Controller para sincronizar com um repositório Git, você colabora com as alterações na zona de destino e mantém uma trilha de auditoria eficiente.

Nesta etapa, você implantará seu primeiro blueprint. Esse blueprint inclui:

  • Dois repositórios de origem do Cloud: um repositório "de origem" em que você confirmará as alterações e um repositório de "implantação" que contém uma cópia da configuração final aplicada ao Config Controller.
  • Um gatilho do Cloud Build que detecta alterações no repositório de origem, executa todas as funções kpt incluídas e confirma a saída final para o repositório de implantação.
  • Uma configuração do Config Sync que conecta o Config Controller ao repositório de implantação.

Implantar o blueprint

  1. Ative o serviço do Resource Manager no projeto:
    gcloud services enable cloudresourcemanager.googleapis.com
  2. Faça o download do blueprint do GitOps do GitHub na máquina local usando o kpt:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gitops@main gitops
  3. Esse blueprint pode ser personalizado usando vários setters. Abra o arquivo gitops/setters.yaml para modificá-los:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
      annotations:
        config.kubernetes.io/local-config: "true"
    data:
      # This should be the project where you deployed Config Controller
      project-id: project-id
      project-number: "1234567890123"
      # This should be the name of your Config Controller instance
      cluster-name: cluster-name
      # You can leave these defaults
      namespace: config-control
      deployment-repo: deployment-repo
      source-repo: source-repo
    
  4. Personalize esse blueprint substituindo os seguintes setters no arquivo anterior:
    • cluster-name: o nome escolhido para o Config Controller. Isso pode ser recuperado com este comando:
      echo ${CONFIG_CONTROLLER_NAME}
    • project-id: o ID do projeto em que o Config Controller está implantado
    • project-number: o número do projeto em que o Config Controller está implantado. Isso pode ser recuperado com este comando:
      gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)'
  5. Renderize o blueprint para propagar as personalizações em todos os recursos:
    kpt fn render gitops/
  6. Inicialize o blueprint para prepará-lo para o cluster do Config Controller:
    kubectl apply --wait -f gitops/ --recursive
  7. Aguarde até que os repositórios sejam criados pelo blueprint:
    kubectl wait --for=condition=READY -f gitops/source-repositories.yaml

Salve o blueprint no Git

Agora salve o blueprint no repositório Git criado. Com isso, você poderá salvar suas personalizações e rastrear alterações futuras.

  1. Confira o repositório Git criado pelo blueprint:
    gcloud source repos clone source-repo
  2. Mova o blueprint do GitOps para o repositório Git:
    mv gitops source-repo/
  3. Abra o repositório Git:
    cd source-repo/
  4. Confirme o blueprint para o Git e envie as alterações:
    git add gitops/
    git commit -m "Add GitOps blueprint"
    git push

Verificar o sucesso

Para verificar se o processo de inicialização acima foi concluído:

  • Verifique se o Config Connector foi instalado:
    kubectl wait -n cnrm-system --for=condition=Ready pod --all
  • Confirme se os repositórios de origem do Cloud foram criados:
    gcloud source repos list
  • Verifique se os recursos necessários foram criados no Config Controller:
    kubectl get gcp -n config-control -o yaml \
      | grep "^    name: \\|message"
    A saída será semelhante a esta:
        name: source-repo-cicd-trigger
          message: The resource is up to date
        name: allow-configsync-sa-read-csr
          message: The resource is up to date
        name: configsync-sa-workload-identity-binding
          message: The resource is up to date
        name: deployment-repo-cloudbuild-write
          message: The resource is up to date
        name: source-repo-cloudbuild-read
          message: The resource is up to date
        name: config-sync-sa
          message: The resource is up to date
        name: cloudbuild.googleapis.com
          message: The resource is up to date
        name: sourcerepo.googleapis.com
          message: The resource is up to date
        name: deployment-repo
          message: The resource is up to date
        name: source-repo
          message: The resource is up to date
    
  • Confirme se a versão foi bem-sucedida:
    gcloud builds list --project=${PROJECT_ID} \
      --filter="source.repo_source.commit_sha=$(git rev-parse HEAD)"
  • Confirme se os manifestos hidratados foram enviados para o repositório de implantação:
    BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter="source.repo_source.commit_sha=$(git rev-parse HEAD)" --format="value(id)")
    gcloud builds log --project=${PROJECT_ID} ${BUILD_ID}
    Exemplo de saída:
    ...
    Step #2 - "Push Changes To Deployment Repo":  7 files changed, 297 insertions(+)
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/.gitkeep
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/cloudbuild-iam.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/configsync/config-management.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/configsync/configsync-iam.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/hydration-trigger.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/services.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/source-repositories.yaml
    Step #2 - "Push Changes To Deployment Repo": To https://source.developers.google.com/p/$PROJECT_ID/r/deployment-repo
    Step #2 - "Push Changes To Deployment Repo":  * [new branch]      main -> main
    Step #2 - "Push Changes To Deployment Repo":
    Step #2 - "Push Changes To Deployment Repo":
    Step #2 - "Push Changes To Deployment Repo": Latest deployment repo commit SHA: $SHA
    Finished Step #2 - "Push Changes To Deployment Repo"
    PUSH
    DONE
    

Como inicializar a zona de destino

Agora que o Config Controller está conectado ao Git, é hora de inicializar o blueprint da zona de destino.

Este blueprint preparará a zona de destino configurando a estrutura geral da organização, incluindo:

  • A criação de namespaces separados no Config Controller para gerenciar hierarchy, logging, networking, projects e policies. Cada namespace recebe uma conta de serviço de privilégio mínimo diferente do Google Cloud.
  • A atribuição do papel de Administrador de faturamento ao grupo de administradores do faturamento e o papel de Administrador da organização ao grupo de administradores da organização.
  • A ativação políticas da organização de práticas recomendadas na organização.

Implantar o blueprint

No repositório de origem clonado acima, implante a zona de destino:

  1. Faça o download do blueprint da zona de destino de base e adicione-o ao repositório
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/landing-zone@main ./landing-zone
    git add landing-zone/
    git commit -m "Add landing zone"
  2. Esse blueprint inclui vários setters para configurar a zona de destino. Abra o arquivo landing-zone/setters.yaml para modificá-los:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Organization ID and billing account
      org-id: "123456789012"
      billing-account-id: AAAAAA-BBBBBB-CCCCCC
      # Groups to use for org-level roles
      group-org-admins: gcp-organization-admins@example.com
      group-billing-admins: gcp-billing-admins@example.com
      # The project where Config Controller is deployed
      management-project-id: management-project-id
      # This default is safe to keep
      management-namespace: config-control
    
  3. Personalize esse blueprint substituindo os seguintes setters no arquivo anterior:
    • org-id: o ID da organização da zona de destino
    • billing-account-id: a conta de faturamento padrão que você quer usar para novos projetos
    • management-project-id: o ID do projeto em que o Config Controller está implantado
    • group-org-admins: o e-mail do Grupo do Google do administrador da organização. Por exemplo, gcp-organization-admins@example.com
    • group-billing-admins: o e-mail do Grupo do Google dos administradores de faturamento. Por exemplo, gcp-billing-admins@example.com
  4. Revise as personalizações feitas no blueprint:
    git diff
  5. Envie suas alterações para o repositório, onde elas serão sincronizadas automaticamente com o Config Controller e aplicadas:
    git commit -a -m "Customize landing zone blueprint"
    git push
    

Gerenciar políticas da organização

O blueprint da zona de destino inclui várias restrições de políticas da organização que representam as práticas recomendadas para aumentar a segurança dos seus ambientes.

Restrição Descrição
compute.disableNestedVirtualization Desativa a virtualização aninhada acelerada por hardware de todas as VMs do Compute Engine.
compute.disableSerialPortAccess Desativa o acesso à porta serial para VMs do Compute Engine.
compute.disableGuestAttributesAccess Desativa o acesso da API Compute Engine aos atributos de convidado das VMs.
compute.vmExternalIpAccess Limita o conjunto de instâncias de VM do Compute Engine que podem usar endereços IP externos.
compute.skipDefaultNetworkCreation Faz com que o Google Cloud ignore a criação da rede padrão e dos recursos relacionados durante a criação do projeto.
compute.restrictXpnProjectLienRemoval Restringe o conjunto de usuários que podem remover uma garantia do projeto da VPC compartilhada.
sql.restrictPublicIp Restringe endereços IP públicos em instâncias do Cloud SQL.
iam.disableServiceAccountKeyCreation Desativa a criação de chaves de conta de serviço para download.
storage.uniformBucketLevelAccess Requer buckets para usar o acesso uniforme no nível do bucket baseado em IAM.

Como remover restrições

Se alguma das restrições padrão representar problemas para a organização, basta excluir o arquivo YAML associado do repositório de origem para restaurar o comportamento padrão.

Por exemplo, para remover a restrição que impede o acesso à porta serial, siga estas etapas:

  1. Exclua o arquivo:
    git rm ./landing-zone/policies/disable-serial-port.yaml
  2. Confirme e envie a alteração.
    git commit -m "Remove serial port org policy"
    git push
    

Verificar o sucesso

Para verificar se a zona de destino foi inicializada:

  • Verifique o status do pipeline de execução do Cloud Build.
  • Verifique se o repositório Git está sincronizado com o Config Controller:
    nomos status
  • Confirme a existência dos namespaces hierarchy, projects, policies, logging e networking:
    kubectl get ns
  • Verifique se os recursos necessários foram criados no Config Controller:
    kubectl get gcp --all-namespaces -o yaml \
      | grep "^    name: \|message"
  • Liste as políticas da organização pela CLI:
    gcloud resource-manager org-policies list --organization=$ORG_ID

Como configurar a hierarquia de recursos

No Google Cloud, os recursos são organizados em pastas e projetos:

  • Os projetos contêm os recursos de nuvem, como máquinas virtuais, bancos de dados e buckets de armazenamento.
  • As pastas são usadas para agrupar projetos e facilitar o gerenciamento de políticas, incluindo o IAM. Por exemplo, elas podem representar os principais departamentos da sua organização, como finanças ou varejo, ou ambientes como produção versus não produção. É possível aninhar as pastas umas nas outras para formar uma hierarquia de recursos.

Fornecemos quatro blueprints de hierarquia de recursos diferentes para diferentes estruturas organizacionais:

  • Simples: este é um blueprint simples com uma única camada de pastas que representa environments.
  • Equipe: este blueprint tem duas camadas de pastas: teams -> environments
  • Unidades comerciais: este blueprint divide a organização em três níveis de pastas com foco em unidades de negócios autônomas: divisions -> teams -> environments
  • Ambientes: este blueprint tem três níveis de pastas, com foco em políticas focadas em ambiente: environments -> divisions -> teams

Implantar o blueprint

Depois de escolher a hierarquia preferida, siga as instruções apropriadas para implantá-la.

Simples

Este blueprint é adequado para organizações planas em que é necessário um conjunto simples de políticas para cada ambiente para gerenciar a nuvem, mas todas as equipes são tratadas de maneira uniforme.

  1. Faça o download do blueprint:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/simple@main ./landing-zone/hierarchy/
  2. Edite o arquivo landing-zone/hierarchy/hierarchy.yaml para refletir a estrutura organizacional pretendida.
    spec:
      config:
        - shared
        - dev
        - prod
        - qa
      parentRef:
        # This should match your organization ID
        external: '123456789012'

    Estes valores precisam ser atualizados no hierarchy.yaml:

    • spec.config: os ambientes pretendidos, que se tornarão pastas de nível superior
    • spec.parentRef.external: atualizar este valor para corresponder ao ID da organização
  3. Edite a restrição de política de nomenclatura incluída no landing-zone/hierarchy/policies/naming-constraint.yaml para refletir o esquema de nomenclatura das pastas que você preferir. O esquema de nomenclatura é definido como uma expressão regular. Em particular, é necessário ajustar essa expressão para incluir quaisquer ambientes extras definidos.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Adicione a hierarquia e envie por push ao repositório git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Equipe

Este modelo é adequado para organizações mais simples, em que cada equipe é responsável pelas próprias operações na nuvem e pode definir políticas personalizadas de acordo com o uso delas.

  1. Faça o download do blueprint:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/team@main ./landing-zone/hierarchy/
  2. Edite o arquivo landing-zone/hierarchy/hierarchy.yaml para refletir a estrutura organizacional pretendida.
    spec:
      config:
        - retail:
            $subtree: environments
        - finance:
            $subtree: environments
      parentRef:
        # This should match your organization ID
        external: '123456789012'
      subtrees:
        environments:
          - dev
          - prod
          - qa

    Estes valores precisam ser atualizados no hierarchy.yaml:

    • spec.config: as equipes pretendidas, que se tornarão pastas de nível superior
    • spec.subtrees.environments: os ambientes pretendidos, que se tornarão subpastas em cada equipe.
    • spec.parentRef.external: atualizar este valor para corresponder ao ID da organização.
  3. Edite a restrição de política de nomenclatura incluída no landing-zone/hierarchy/policies/naming-constraint.yaml para refletir o esquema de nomenclatura das pastas que você preferir. O esquema de nomenclatura é definido como uma expressão regular. Em particular, é necessário ajustar essa expressão para incluir quaisquer ambientes extras definidos.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Adicione a hierarquia e envie por push ao repositório git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Unidades empresariais

Este blueprint é adequado para organizações grandes e complexas, em que cada unidade de negócios ou divisão é responsável pelas próprias operações na nuvem. Ele permite que cada unidade empresarial defina facilmente as políticas que se aplicam a todas as equipes, enquanto as equipes individuais são responsáveis pelos próprios ambientes (dentro dessas restrições de nível superior).

  1. Faça o download do blueprint:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/bu@main ./landing-zone/hierarchy/
  2. Edite o arquivo landing-zone/hierarchy/hierarchy.yaml para refletir a estrutura organizacional pretendida.
    spec:
      config:
        - retail:
            - apps:
                $subtree: environments
            - data:
                $subtree: environments
        - finance:
            - commercial:
                $subtree: environments
      parentRef:
        # This should match your organization ID
        external: '123456789012'
      subtrees:
        environments:
          - dev
          - prod

    Estes valores precisam ser atualizados no hierarchy.yaml:

    • spec.config: a estrutura organizacional pretendida, que pode incluir equipes aninhadas na divisão. Por exemplo, o blueprint começa com uma divisão de varejo que tem as subpastas appse dados.
    • spec.subtrees.environments: os ambientes pretendidos, que se tornarão subpastas em cada equipe.
    • spec.parentRef.external: atualizar este valor para corresponder ao ID da organização.
  3. Edite a restrição de política de nomenclatura incluída no landing-zone/hierarchy/policies/naming-constraint.yaml para refletir o esquema de nomenclatura das pastas que você preferir. O esquema de nomenclatura é definido como uma expressão regular. Em particular, é necessário ajustar essa expressão para incluir quaisquer ambientes extras definidos.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Adicione a hierarquia e envie por push ao repositório git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Ambientes

Este blueprint é adequado para organizações maiores que precisam assegurar políticas sólidas e consistentes sobre políticas do ambiente (por exemplo, restringir o acesso a recursos de produção), além de oferecer flexibilidade para políticas granulares de divisão e para equipes.

  1. Faça o download do blueprint:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/env-bu@main ./landing-zone/hierarchy/
  2. Edite o arquivo landing-zone/hierarchy/hierarchy.yaml para refletir a estrutura organizacional pretendida.
    spec:
      config:
        - dev:
            $subtree: environment
        - prod:
            $subtree: environment
      parentRef:
        # This should match your organization ID
        external: '123456789012'
      subtrees:
        environment:
          - retail:
              - apps
              - data
          - finance:
              - commercial

    Estes valores precisam ser atualizados no hierarchy.yaml:

    • spec.config: as pastas de ambiente de nível superior pretendidas, cada uma com uma cópia completa da subárvore de ambiente
    • spec.subtrees.environment: a hierarquia de divisões e equipes pretendida que será espelhada em cada ambiente. Por exemplo, o blueprint começa com uma divisão de varejo que tem subpastas de appse de dados
    • spec.parentRef.external: atualize este valor para corresponder ao ID da organização
  3. Adicione a hierarquia e envie por push ao repositório git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Verificar o sucesso

Verifique se a hierarquia de recursos foi criada com sucesso:

  • Como listar as pastas na sua organização:
    gcloud resource-manager folders list --organization=$ORG_ID
  • Como recuperar o status das pastas diretamente do namespace da hierarquia no cluster:
    kubectl get folders -n hierarchy -o yaml \
      | grep "^    name: \|message"

Como estabelecer conectividade de rede

Como parte da zona de destino, recomendamos a implantação de uma arquitetura de rede VPC compartilhada. O blueprint de rede fornecido configura uma rede e estabelece um Cloud VPN para conectividade híbrida.

Criar um projeto host

Antes de implantar uma rede, é necessário criar um projeto para hospedá-la. Isso deve ser feito uma vez para cada ambiente usando o blueprint de fábrica do projeto incluído.

  1. Faça o download do blueprint do projeto na zona de destino para criar um projeto host.
    export NET_PROJECT_ID="NETWORK_PROJECT_ID"
    export ENVIRONMENT="ENVIRONMENT"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@main \
      ./landing-zone/projects/${NET_PROJECT_ID}
    

    Substitua:

    • ENVIRONMENT: o ambiente para o qual você está configurando uma VPC compartilhada, por exemplo, dev.
    • NETWORK_PROJECT_ID: o ID que você quer atribuir ao seu projeto de rede.
  2. Abra o arquivo landing-zone/projects/NETWORK_PROJECT_ID/setters.yaml. Personalize esse blueprint substituindo os seguintes setters em:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    Defina os seguintes valores:
    • project-id: o ID que você escolheu
    • folder-name: o ID da pasta que precisa conter o projeto de rede. As pastas são prefixadas com o nome da pasta pai. Por exemplo, a pasta shared dentro do ambiente dev teria o ID dev.shared.
  3. Adicione um blueprint extra a um projeto host da VPC compartilhada:
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/shared-vpc@main \
      ./landing-zone/projects/${NET_PROJECT_ID}/host-project
    
  4. Confirme as mudanças para acionar a criação do projeto:
    git add ./landing-zone/projects/${NET_PROJECT_ID}/
    git commit -m "Add networking host project"
    git push
    

Criar a rede

Agora que você tem um projeto host, é possível criar uma VPC compartilhada usando o blueprint de rede:

  1. Adicione o blueprint da rede à zona de destino:
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network@main \
      ./landing-zone/network/${ENVIRONMENT}/
    
  2. Abra o arquivo landing-zone/network/ENVIRONMENT/setters.yaml. Personalize esse blueprint substituindo os seguintes setters:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Required setters
      network-name: network-name
      project-id: project-id
      region: us-central1
      vpn-tunnel-peer-ip-01: "15.1.0.120"
      vpn-tunnel-peer-ip-02: "15.1.1.120"
      # Optional setters
      namespace: networking
      vpn-secret-key: vpn-shared-secret
      vpn-secret-name: vpn-shared-secret
      prefix: ""
    
    Defina os seguintes valores:
    • network-name: o nome que você quer usar para sua rede, por exemplo, dev-network-shared
    • region: a região em que a primeira sub-rede será implantada, por exemplo, us-east4
    • project-id: o ID do projeto em que a rede será hospedada. (NETWORK_PROJECT_ID)
  3. Crie um secret para a chave pré-compartilhada usada pelo Cloud VPN. Esse valor é confidencial e não pode ser confirmado no repositório Git. Em vez disso, envie-o diretamente para o Config Controller:
    kubectl create secret generic vpn-shared-secret \
      --from-literal=vpn-shared-secret="SECRET_VALUE" \
      -n networking
  4. Confirme o blueprint personalizado para implantar a rede:
    git add ./landing-zone/network/
    git commit -m "Add network setup"
    git push
    

Verificar a implantação da rede

Para verificar se a rede foi criada com sucesso:

  • Confirme se o projeto foi criado com sucesso:
    kubectl describe project ${NET_PROJECT_ID} -n projects
  • Como recuperar o status da rede diretamente do namespace de rede no cluster:
    kubectl get gcp \
      -n networking -o yaml \
      | grep "^    name: \|message"
  • Como inspecionar a rede pelo Console do Cloud.

Como exportar dados de geração de registros

Uma das práticas recomendadas do Google Cloud para organizações empresariais é monitorar e reter de perto os registros de auditoria.

Os blueprints da zona de destino incluem várias opções para gerenciar a exportação e a retenção de registros.

Siga as etapas abaixo para implantar um blueprint, que exportará todos os registros da organização para o BigQuery para retenção e análise de longo prazo.

Criar um projeto host

Se você quiser exportar registros para o BigQuery, precisará de um projeto para hospedá-los. Como você irá exportar registros para toda a organização, coloque este projeto no ambiente de produção. Ele pode ser criado usando um blueprint.

  1. Faça o download do blueprint do projeto na zona de destino para criar um projeto host.
    export LOGGING_PROJECT_ID="LOGGING_PROJECT_ID"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@main \
      ./landing-zone/projects/${LOGGING_PROJECT_ID}
    

    Substitua:

    • LOGGING_PROJECT_ID: o ID que você quer atribuir ao seu projeto de rede.
  2. Abra o arquivo landing-zone/projects/LOGGING_PROJECT_ID/setters.yaml. Personalize esse blueprint substituindo os seguintes setters:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    Defina os seguintes valores:
    • project-id: o ID do projeto que você escolheu para armazenar as exportações de registros (LOGGING_PROJECT_ID)
    • folder-name: o ID da pasta que precisa conter o projeto de geração de registros. As pastas são prefixadas com o nome da pasta pai. Por exemplo, a pasta shared dentro do ambiente dev teria o ID dev.shared.
  3. Confirme as mudanças para acionar a criação do projeto:
    git add ./landing-zone/projects/${LOGGING_PROJECT_ID}/
    git commit -m "Add logging project"
    git push
    

exportar registros para o BigQuery;

Ao exportar registros para o BigQuery, é possível retê-los para análise posterior. Este blueprint inclui a criação de um conjunto de dados do BigQuery para armazenar os registros e a configuração da exportação para esse conjunto de dados.

  1. Adicione o blueprint de geração de registros à zona de destino:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/log-export/org/bigquery-export@main ./landing-zone/logging/bigquery-export
  2. Abra o arquivo landing-zone/logging/bigquery-export/setters.yaml. Personalize esse blueprint substituindo o ID do projeto:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # This is required
      project-id: my-project-id
      # These defaults can be left unchanged
      namespace: logging
      dataset-description: BigQuery audit logs for organization
      dataset-location: US
      dataset-name: audit-logs
      default-table-expiration-ms: "3600000"
      delete-contents-on-destroy: "false"
      filter: ""
    
    Defina os seguintes valores:
    • project-id: o ID do projeto que você escolheu para armazenar os registros (LOGGING_PROJECT_ID)
  3. Confirme o blueprint para criar a exportação de registros.
    git add ./landing-zone/logging/
    git commit -m "Add log export to BigQuery"
    git push

Verificar a exportação de registros

Para verificar se a exportação de registros foi configurada com sucesso, faça o seguinte:

  • Confirme se o projeto foi criado com sucesso:
    kubectl describe project ${LOGGING_PROJECT} -n projects
    gcloud projects describe ${LOGGING_PROJECT_ID}
    
  • Recupere o status de recursos no namespace logging:
    kubectl get bigquerydatasets,iampolicymembers,logginglogsinks -n logging -o yaml \
      | grep "^    name: \|message"
  • Recupere o status da exportação de registro pela CLI gcloud (o novo coletor aparecerá na lista):
    gcloud logging sinks list --organization=${ORG_ID}
  • Após configurar o coletor por um tempo, verifique se os registros estão fluindo para o BigQuery:

    # List tables
    bq ls --project_id ${LOGGING_PROJECT_ID} bqlogexportdataset
    
    # Query a table
    # Change this to a result of "bq ls" above so that the name matches one of your tables
    TABLE_OF_INTEREST=git_sync_20201130
    bq query --project_id ${LOGGING_PROJECT_ID} "SELECT * FROM bqlogexportdataset.${TABLE_OF_INTEREST} LIMIT 2"
    

Solução de problemas

Rede padrão

Ao criar o controlador de configuração, você pode receber um erro sobre a indisponibilidade da rede padrão:

Error 400: Project "" has no network named "default"., badRequest\n\n  on main.tf line 35, in resource "google_container_cluster" "acp_cluster"

Esse erro ocorre porque o Config Controller depende da rede padrão. Para resolver isso, crie uma nova rede padrão:

gcloud compute networks create default --subnet-mode=auto

Hidratação e Cloud Build

Como parte do blueprint do GitOps, você criou um gatilho do Cloud Build que monitora o repositório de origem quanto a alterações e:

  1. Valida o conteúdo dessas alterações usando funções kpt
  2. Gera a configuração final "hidratada", que é salva em um repositório de implantação e aplicada ao cluster pelo Config Sync.

Esse pipeline do Cloud Build pode ser monitorado no console ou no gcloud. Este comando gcloud pode ser usado para recuperar o status mais recente da criação:

FILTER="source.repo_source.commit_sha=$(git rev-parse HEAD)"
# You can poll on this command until status is either SUCCESS or FAILURE
gcloud builds list --project=${PROJECT_ID} --filter=${FILTER}

BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter=${FILTER} --format='get(id)' | head -n 1)
# View logs for your run. You can use this to debug errors
gcloud builds log --project=${PROJECT_ID} $BUILD_ID

Execução local

Se você quiser um feedback mais rápido sobre os problemas do que o fornecido pelo pipeline do Cloud Build, use o kpt para executar o pipeline localmente com esse comando (executado na raiz do repositório de origem):

kpt fn render ./landing-zone/

Campos e recursos imutáveis

Alguns campos nos recursos subjacentes do Google Cloud são imutáveis, como IDs do projeto ou o nome da rede VPC. O Config Connector bloqueará edições nesses campos e não poderá acionar as alterações. Se quiser editar um desses campos imutáveis, primeiro exclua o recurso original (pelo Git) antes de adicioná-lo novamente com os novos valores preferidos.

Implantação e Config Sync

O repositório de "implantação" contém recursos totalmente hidratados que definem a zona de destino. Esses recursos são sincronizados com o Config Controller usando o Config Sync. É possível verificar erros neste processo de sincronização usando o comando nomos:

nomos status

Faturamento

O blueprint da zona de destino configurará automaticamente as permissões de faturamento corretas para gerenciar o faturamento na organização. Se os projetos não puderem ser anexados à conta de faturamento, talvez ela exista fora da organização. Portanto, você precisará conceder diretamente as permissões da conta de serviço projects para gerenciar a conta de faturamento:

export PROJECTS_SA="$(kubectl get ConfigConnectorContext -n projects -o jsonpath='{.items[0].spec.googleServiceAccount}')"
gcloud alpha billing accounts add-iam-policy-binding $BILLING_ACCOUNT \
  --role=roles/billing.admin \
  --member="serviceAccount:${PROJECTS_SA}"

Limpeza

Se você decidir parar de usar a zona de destino, limpe todos os recursos criados. Primeiro, você precisa remover os recursos do Config Controller antes de excluí-lo.

Como alternativa, se você quiser manter os recursos da zona de destino ao abandonar o fluxo de trabalho declarativo, poderá pular essa etapa e excluir o Config Controller, embora isso não seja recomendado.

Como excluir recursos

Para excluir os recursos, basta remover os arquivos associados do repositório Git das zonas de destino. Isso funciona para recursos individuais ou para pacotes inteiros.

No entanto, não é possível excluir toda a zona de destino de uma só vez para evitar exclusões acidentais. Em vez disso, será necessário separar os recursos da zona de destino em algumas etapas:

# Delete downstream resources
git rm -rf ./landing-zone/logging/
git rm -rf ./landing-zone/network/
git commit -m "Delete downstream resources"
git push
# Confirm Config Sync successfully applies

# Delete projects
git rm -rf ./landing-zone/projects/
git commit -m "Delete projects"
git push
# Confirm Config Sync successfully applies

# Delete folders and organization policies, but leave the policy template (see below for why)
git rm -rf ./landing-zone/hierarchy/
find ./landing-zone/policies/ -type f -not \( -name 'folder-naming-constraint-template.yaml' \) -delete
git add ./landing-zone/
git commit -m "Delete hierarchy and organization policies"
git push
# Confirm Config Sync successfully applies

# Delete landing zone except for 1 cluster-scoped resource
# (folder-naming-constraint-template.yaml) and 1 empty namespace (projects.yaml).
# See /anthos-config-management/docs/reference/errors#knv2006
find ./landing-zone/ -type f -not \( -name 'folder-naming-constraint-template.yaml' -or -name 'projects.yaml' \) -delete
cat <<EOF > ./landing-zone/namespaces/projects.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: projects
EOF
git add ./landing-zone/
git commit -m "Delete all landing zone resources except 1 cluster-scoped resource and 1 namespace"
git push
# Confirm Config Sync successfully applies

# Delete remaining resources
git rm -rf ./landing-zone/
git commit -m "Delete remaining resources"
git push

Como excluir o Config Controller

gcloud alpha anthos config controller delete --location=us-central1 ${CONFIG_CONTROLLER_NAME}