Fazer upgrade das cargas de trabalho de contêiner para o ambiente de execução aprimorado

Se você tiver cargas de trabalho de contêiner atuais criadas usando as versões 1.7.x e 1.8 do Migrate to Containers, será possível convertê-las para usar o gerenciador de serviços simplificado do Linux. Com essa conversão, é possível executar esses contêineres em clusters do Autopilot do GKE.

Para realizar a conversão, edite o Dockerfile e o arquivo deployment_spec.yaml criado quando você realizou a migração original. Depois de editado, é possível implantar a carga de trabalho do contêiner em clusters do Autopilot.

Como converter cargas de trabalho de contêineres

O procedimento para converter cargas de trabalho atuais depende se você está convertendo uma carga de trabalho sem estado ou com estado.

Uma carga de trabalho com estado é aquela que mantém ou armazena informações de estado. Para cargas de trabalho com estado, você geralmente monta volumes adicionais usando StatefulSet em spec.containers.volumeMounts. Mantenha as definições de volumeMounts e remova-as para /sys/fs/cgroup. Saiba mais em Como montar volumes externos.

O processo geral de conversão de uma carga de trabalho atual exige que você edite o:

  • Dockerfile

    • Defina a versão do Migrate to Containers como 1.15.0.
    • Insira dois comandos ADD para copiar o arquivo logs.yaml para a imagem do contêiner.
    • Insira um comando RUN para o utilitário servicemanager_generate_config.

  • arquivo deployment_spec.yaml para:

    • Exclua as definições hostPath e volumeMounts para /sys/fs/cgroup.
    • Exclua a definição de securityContext.
    • Exclua a definição de readinessProbe.
    • É possível deixar as definições de mountPath e configMap para logs-config. No entanto, a geração de registros não funciona no momento com o gerenciador de serviços simplificado do Linux.

Para ver o processo de conversão específico, consulte as seções abaixo:

Converter uma carga de trabalho sem estado

No exemplo a seguir, veja como converter uma carga de trabalho de contêiner sem estado:

  1. Localize o diretório que contém os artefatos de migração existentes, incluindo o arquivo deployment_spec.yaml.

  2. Edite o Dockerfile para definir a versão do produto, copiar o arquivo logs.yaml e executar o utilitário servicemanager_generate_config:

    ...
# Set the product version to 1.15.0:
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime

...

ADD blocklist.yaml /.m4a/blocklist.yaml
# Insert the ADD commands to copy the `logs.yaml` file to the container image:
ADD logs.yaml /code/config/logs/logsArtifact.yaml
ADD logs.yaml /code/config/logs/logs.yaml

# Insert the RUN command for servicemanager_generate_config:
RUN /servicemanager_generate_config build-all -o /.m4a/

# Migrate to Containers image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

  3. Abra o arquivo deployment_spec.yaml em um editor. Por exemplo:

    vi  deployment_spec.yaml

  4. Localize a seguinte seção no arquivo e exclua as linhas indicadas:

    apiVersion: apps/v1 
kind: Deployment
metadata: 
  creationTimestamp: null 
  name: IMAGE_NAME  
     … 
    spec:
      containers:
      - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
        name: IMAGE_NAME
# Delete the following lines:
        readinessProbe:
          exec:
            command:
            - /code/ready.sh
        resources: {}
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /sys/fs/cgroup
          name: cgroups
        - mountPath: /code/config/logs
          name: logs-config
      volumes:
      - hostPath:
          path: /sys/fs/cgroup
          type: Directory
        name: cgroups
      - configMap:
          name: suitecrm-crddefault-logs
        name: logs-config
# Stop the delete here.

  5. Adicione as linhas abaixo para definir a variável de ambiente HC_V2K_SERVICE_MANAGER.

    spec:
  containers:
  - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
    name: IMAGE_NAME
# Add the following lines:
    env:
      - name: HC_V2K_SERVICE_MANAGER
        value: "true"

  6. Salve o arquivo.

  7. Verifique se o cluster de destino tem acesso de leitura ao registro de imagem do Docker, conforme descrito acima em Verificar se o cluster de destino tem acesso de leitura ao registro de imagem do Docker.

  8. Crie a imagem atualizada e envie-a para o Container Registry com uma tag de versão atualizada, garantindo que você tenha tempo suficiente para a criação ser concluída. No exemplo a seguir, a imagem está no diretório atual:

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

  9. Implantar o contêiner: 

    kubectl apply -f deployment_spec.yaml

    Se você aplicar a especificação de implantação a um cluster do Autopilot sem as alterações necessárias em deployment_spec.yaml, verá uma mensagem de erro no formulário:

    "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

  10. Visualize os pods que estão sendo implantados no cluster. 

    kubectl get pods

Converter uma carga de trabalho com estado

No exemplo a seguir, veja como converter uma carga de trabalho de contêiner com estado:

  1. Localize o diretório que contém os artefatos de migração existentes, incluindo o arquivo deployment_spec.yaml.

  2. Edite o Dockerfile para definir a versão do produto e executar o utilitário servicemanager_generate_config:

    ...
# Set the product version to 1.15.0:
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime

...

ADD blocklist.yaml /.m4a/blocklist.yaml
# Insert the ADD commands to copy the `logs.yaml` file to the container image:
ADD logs.yaml /code/config/logs/logsArtifact.yaml
ADD logs.yaml /code/config/logs/logs.yaml

# Insert the RUN command for servicemanager_generate_config:
RUN /servicemanager_generate_config build-all -o /.m4a/

# Migrate to Containers image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

  3. Abra o arquivo deployment_spec.yaml em um editor. Por exemplo: 

    vi  deployment_spec.yaml

  4. Localize as três seções a seguir no arquivo e exclua as linhas indicadas:

    apiVersion: apps/v1 
kind: StatefulSet  
... 
spec: 
  containers: 
  - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL 
    name: IMAGE_NAME 
# Delete the following lines:
    readinessProbe: 
      exec: 
        command: 
        - /code/ready.sh 
    resources: {} 
    securityContext: 
      privileged: true 
# Stop the delete here.
    volumeMounts: 
# Delete the following lines:
    - mountPath: /sys/fs/cgroup 
      name: cgroups 
# Stop the delete here.
    - mountPath: /opt/suitecrm-7.10.5-0/mysql/data 
      name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5 
      subPath: opt/suitecrm-7.10.5-0/mysql/data 
  volumes:
# Delete the following lines:
  - hostPath:
      path: /sys/fs/cgroup 
      type: Directory 
    name: cgroups 
# Stop the delete here.
  - name: data-pvc-2-d0af-48b3-9f5e09c25fa5 
    persistentVolumeClaim: 
      claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

    Remova apenas as definições volumeMounts e volumes para cgroups e deixe as definições restantes.

  5. Adicione as seguintes linhas para definir a variável de ambiente HC_V2K_SERVICE_MANAGER:

    spec: 
  containers: 
  - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
    name: IMAGE_NAME 
# Add the following lines:
    env:
    - name: HC_V2K_SERVICE_MANAGER 
      value: "true" 
# Stop the add here.
    volumeMounts: 
    - mountPath: /opt/suitecrm-7.10.5-0/mysql/data 
      name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5 
      subPath: opt/suitecrm-7.10.5-0/mysql/data 
  volumes:
  - name: data-pvc-2-d0af-48b3-9f5e09c25fa5 
    persistentVolumeClaim: 
      claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

  6. Salve o arquivo.

  7. Verifique se o cluster de destino tem acesso de leitura ao registro de imagem do Docker, conforme descrito acima em Verificar se o cluster de destino tem acesso de leitura ao registro de imagem do Docker.

  8. Crie a imagem atualizada e envie-a para o Container Registry com uma tag de versão atualizada, garantindo que você tenha tempo suficiente para a criação ser concluída. No exemplo a seguir, a imagem está no diretório atual:

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

  9. Implantar o contêiner:

    kubectl apply -f deployment_spec.yaml

    Se você aplicar a especificação de implantação a um cluster do Autopilot sem as alterações necessárias em deployment_spec.yaml, verá uma mensagem de erro no formulário:

    "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

  10. Visualize os pods que estão sendo implantados no cluster.

    kubectl get pods

Tarefas pós-conversão

Depois de converter uma migração atual para usar o gerenciador de serviços simplificado do Linux, modifique-o para:

  • Atualizar os serviços usados pela carga de trabalho migrada.
  • Adicionar novos serviços.

Nos dois cenários, é necessário editar o Dockerfile e recriar a imagem do contêiner.

Atualizar serviços

Nesta seção, você edita o Dockerfile para atualizar o arquivo services-config.yaml no contêiner com base nas alterações feitas em /etc/systemd na carga de trabalho migrada.

Para atualizar a imagem do contêiner para uma alteração em um serviço atual, siga estas etapas:

  1. Adicionar o comando servicemanager_generate_config no Dockerfile:

    ...
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime

...

ADD blocklist.yaml /.m4a/blocklist.yaml

# Use the update command for servicemanager_generate_config to update the configuration:
RUN /servicemanager_generate_config update -u /.m4a/

# Migrate to Containers image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

  2. Crie a imagem atualizada e envie-a para o Container Registry com uma tag de versão atualizada, garantindo que você tenha tempo suficiente para a criação ser concluída. No exemplo a seguir, a imagem está no diretório atual:

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

  3. Implante a imagem recém-criada:

    kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Adicionar serviços

Para adicionar um serviço à imagem do contêiner:

  1. Adicionar o comando servicemanager_generate_config no Dockerfile:

    ...
FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime

...

ADD blocklist.yaml /.m4a/blocklist.yaml

# This example adds the redis-server service.
# Add the following lines to install redis-server.
RUN apt-get update && apt-get -y install redis-server

# Use the servicemanager_generate_config add command to add
# redis-server to the configuration:
RUN /servicemanager_generate_config add redis-server -u /.m4a/

# Migrate to Containers image includes entrypoint
ENTRYPOINT [ "/.v2k.go" ]

  2. Crie a imagem atualizada e envie-a para o Container Registry com uma tag de versão atualizada, garantindo que você tenha tempo suficiente para a criação ser concluída. No exemplo a seguir, a imagem está no diretório atual:

    gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

  3. Implante a imagem recém-criada:

    kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Sintaxe servicemanager_generate_config

O utilitário servicemanager_generate_config usa as seguintes opções:

  • build-all -o /.m4a/: recria a migração e grava a configuração no diretório m4a. Não altere o nome do diretório.

    Use essa forma de comando quando você converter sua migração pela primeira vez para usar o gerenciador de serviços simplificado do Linux.

  • update -u /.m4a/: atualize a lista de serviços no diretório m4a. Não altere o nome do diretório.

  • add SERVICE_NAME -u /.m4a/: adiciona o nome do serviço à migração e grava a configuração no diretório m4a. Não altere o nome do diretório.

    Para adicionar vários serviços, adicione vários comandos RUN /servicemanager_generate_config, um por serviço.

A seguir