Com o Cloud Deploy, é possível transmitir parâmetros para a versão, e esses
valores são fornecidos ao manifesto antes de serem
aplicados aos respectivos destinos. Essa substituição é feita depois dos manifestos
são renderizados, como a etapa final da
Operação de renderização do Cloud Deploy. Os valores são fornecidos a todos os manifestos
identificados no arquivo skaffold.yaml
que contêm os marcadores de posição
correspondentes.
Tudo o que você precisa fazer é incluir marcadores no manifesto e definir os valores para os marcadores de posição no pipeline de entrega do Cloud Deploy de destino ou quando você cria uma versão.
Este artigo descreve como fazer isso.
Por que usar parâmetros de implantação?
Um uso típico para isso seria aplicar valores diferentes a manifestos de destinos diferentes em uma implantação paralela. Mas você pode use parâmetros de implantação para qualquer tarefa que exija um par de chave-valor pós-renderização. no manifesto.
Como funciona
As etapas a seguir descrevem o processo geral para configurar parâmetros de implantação e fornecer valores:
Você configura a parametrização de implantação, conforme descrito aqui.
Isso inclui o seguinte:
Adicione os marcadores de posição ao manifesto.
Adicione valores para esses marcadores de posição.
Há três maneiras de fazer isso, descritas aqui.
Quando você cria uma versão, o manifesto é renderizado.
Se você começar com um manifesto baseado em modelo, os valores serão aplicados agora ao modelo variáveis. Se você começar com um manifesto bruto, ele vai permanecer inalterado. Isso a renderização é feita pelo Skaffold.
No entanto, é possível ter outras variáveis no manifesto para valores que não são aplicados no momento da renderização. Estes são os parâmetros de implantação descritos neste documento.
Na criação da versão, todos os parâmetros de implantação são compilados em um dicionário, que é usado para substituir valores antes que os manifestos sejam aplicados.
Após a renderização, o Cloud Deploy substitui os valores dos parâmetros de implantação.
Esses são os valores que você configurou na primeira etapa.
O processo de renderização já aplicou valores aos modelos de manifesto, substituindo alguns valores e adicionando rótulos específicos ao Cloud Deploy. No entanto, os valores desses parâmetros de implantação são substituídos após a renderização. As diferenças entre modelos de manifesto e parâmetros de implantação são descritos aqui.
O manifesto é aplicado ao ambiente de execução de destino para implantar seu aplicativo.
Isso inclui os valores substituídos no momento da renderização e os valores para quaisquer parâmetros de implantação
Diferentes maneiras de transmitir valores
É possível fornecer parâmetros e valores para esses parâmetros de três maneiras:
Na definição do pipeline de entrega
Você fornece o parâmetro e o valor dele na definição de uma etapa na progressão do pipeline de entrega. O parâmetro é transmitido para o destino representado por essa etapa. Se essa etapa referenciar vários destinos, os valores definidos aqui serão usados para todos os destinos filhos.
Esse método permite substituir um valor para todas as versões em um determinado pipeline, para todos os destinos afetados. Os parâmetros definidos para um estágio identificam um rótulo, e o destino correspondente a esse estágio precisa ter um rótulo correspondente.
-
Você configura o parâmetro e o valor dele na definição do valor desejado por conta própria. Esse método permite substituir um valor para esse destino em todas as versões.
Na linha de comando, ao criar uma versão
Inclua o parâmetro e o valor dele usando a flag
--deploy-parameters
no comandogcloud deploy releases create
.Esse método permite substituir um valor no momento da criação da versão, aplicando esse valor aos manifestos de todas as metas afetadas.
A configuração desses recursos é explicada com mais detalhes aqui.
Posso usar mais de um desses métodos?
Sim, é possível incluir parâmetros de implantação no estágio de pipeline, no
config e na linha de comando. O resultado é que todos os parâmetros são
aceitos e adicionados ao dicionário. No entanto, se um parâmetro específico for passado
em mais de um lugar, mas com valores diferentes, o comando gcloud deploy releases
create
falha com um erro.
Qual é a diferença entre isso e os modelos de manifesto?
Os parâmetros de implantação, conforme descrito neste artigo, são diferenciados dos marcadores de posição em um manifesto de modelo pela sintaxe. No entanto, se você está se perguntando por que precisa implantar parâmetros em vez de usar as técnicas padrão para manifestos de modelo, a tabela a seguir mostra os diferentes propósitos:
Técnica | Tempo de substituição | Aplicável a |
---|---|---|
Modelo de manifesto | Fase de renderização | Versão específica; destino específico |
Na linha de comando | Pós-renderização | Versão específica; todas as metas |
No pipeline de entrega | Pós-renderização | Todas as versões; metas específicas (por rótulo) |
Dentro da meta | Pós-renderização | Todas as versões destino específico |
Este documento é apenas sobre parâmetros de implantação (na linha de comando, pipeline e alvo), e não de manifestos modelados.
Limitações
Para cada tipo de parâmetro, é possível criar até 25 parâmetros.
Um destino filho também pode herdar até 25 parâmetros do pai. segmentação múltipla, até um máximo de 100 parâmetros nos destinos, incluindo aqueles definida no estágio do pipeline.
O nome da chave é limitado a um máximo de 63 caracteres, e os seguintes expressão regular:
^[a-zA-Z0-9]([-A-Za-z0-9_.]{0,61}[a-zA-Z0-9])?$
Uma exceção é quando você usa um parâmetro de implantação como um variável de ambiente em um destino personalizado, use uma barra entre as palavra-chave
customTarget
e o nome da variável (customTarget/VAR_NAME
). Consulte Entradas e saídas necessárias para a sintaxe compatível.O prefixo
CLOUD_DEPLOY_
está reservado e não pode ser usado para um nome de chave.Não é possível ter duas chaves com o mesmo nome aplicadas ao mesmo destino.
O valor pode estar vazio, mas ter no máximo 512 caracteres.
Os marcadores de posição dos parâmetros de implantação não podem ser usados para Valores de configuração do Helm, mas precisam ser aprovados por convenção.
Configurar parâmetros de implantação
Esta seção descreve como configurar valores de parâmetros de implantação que serão aplicadas ao manifesto do Kubernetes, ao serviço do Cloud Run, ou o modelo do Helm.
Além de configurar esses pares de chave-valor, você precisa adicionar o marcador de posição ou marcadores de posição ao manifesto, conforme descrito nesta seção.
Adicionar marcadores de posição ao manifesto
No manifesto do Kubernetes (para GKE) ou no YAML de serviço (no Cloud Run), adicione marcadores de posição para os valores que quiser. para substituir após a renderização.
Sintaxe
Para versões que não usam o renderizador Helm com Skaffold, use a seguinte sintaxe para os espaços reservados:
[PROPERTY]: [DEFAULT_VALUE] # from-param: ${VAR_NAME}
Nesta linha...
PROPERTY:
É a propriedade de configuração no manifesto do Kubernetes ou no YAML do serviço do Cloud Run.
DEFAULT_VALUE
É um valor a ser usado se não houver valores fornecidos para essa propriedade na linha de comando ou no pipeline ou na configuração de destino.
# from-param:
Usa um caractere de comentário para definir a diretiva
deploy-parameters
do Cloud Deploy, efrom-param:
informa ao Cloud Deploy que um marcador de posiçãodeploy-parameters
é exibido em seguida.${VAR_NAME}
É o marcador de posição a ser substituído. Ele precisa corresponder à chave de um par de chave-valor fornecido no pipeline de envio ou na configuração de destino ou na criação da versão.
Parâmetros para valores de gráfico do Helm
Se você estiver renderizando um gráfico do Helm que aceita
valores de configuração,
e você quiser definir esses valores usando parâmetros de implantação, os parâmetros de implantação
precisam ter nomes que correspondam aos valores de configuração do Helm que você quer definir.
Todos os parâmetros de implantação são transmitidos para o Helm como argumentos --set
no momento da renderização,
sem a necessidade de modificar skaffold.yaml
.
Por exemplo, se o skaffold.yaml
estiver instalando um gráfico do Helm que usa um parâmetro de configuração de webserver.port
para especificar em qual porta o servidor da Web será iniciado e você quiser definir isso dinamicamente usando um parâmetro de implantação, crie um parâmetro de implantação com o nome webserver.port
e o valor que você quer para a porta do servidor da Web.
Portanto, se você não estiver fazendo referência apenas a modelos do Helm no skaffold.yaml
,
e também na sua autoria, é possível usar
sintaxe de variáveis padrão do Helm
de {{ .Values.VAR_NAME }}
nos modelos do Helm.
Por exemplo, se tivermos um parâmetro de implantação de webserver.port
configurado,
poderemos usá-lo assim:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webserver
spec:
replicas: 3
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: webserver
image: gcr.io/example/webserver:latest
ports:
- containerPort: {{ .Values.webserver.port }} # replaced by deploy parameter `webserver.port`.
name: web
env:
- name: WEBSERVER_PORT
value: {{ .Values.webserver.port }} # replaced by deploy parameter `webserver.port`.
Adicionar um parâmetro ao estágio do pipeline
É possível adicionar pares de chave-valor a um estágio na progressão do pipeline de entrega. Isso é útil em implantações paralelas, para distinguir entre destinos filhos.
Adicione os marcadores de posição ao manifesto do Kubernetes ou ao serviço do Cloud Run, conforme descrito aqui.
Veja um exemplo:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 1 # from-param: ${deploy_replicas} selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
Configure o pipeline de entrega para incluir
deployParameters
no de pipeline aplicável.O YAML a seguir é a configuração de um estágio do pipeline cujo destino é um destino múltiplo, que, neste caso, tem dois destinos filhos:
serialPipeline: stages: - targetId: dev profiles: [] - targetId: prod # multi-target profiles: [] deployParameters: - values: deploy_replicas: 1 log_level: "NOTICE" matchTargetLabels: # optional, applies to all resources if unspecified; AND'd my-app: "post-render-config-1" - values: deploy_replicas: 2 log_level: "WARNING" matchTargetLabels: # optional, applies to all resources if unspecified; AND'd my-app: "post-render-config-2"
Nesta configuração do pipeline de entrega, a estrofe
deployParameters
inclui doisvalues
, cada um com o seguinte:O nome da variável, que é igual ao da variável definida no manifesto
Um valor para essa variável
Um ou mais rótulos (opcional) para corresponder a rótulos específicos do destino
Se você não especificar um rótulo, em uma estrofe
matchTargetLabels
, esse valor é usado para todos os destinos no cenário.
Se você incluiu
matchTargetLabels
, também precisa inclua rótulos nos destinos para fazer a correspondência com eles. Dessa forma, você identifica qual valor atribuir a qual segmentação filha.O destino precisa corresponder a todos os rótulos definidos na stanza
values
.Se você omitir
matchTargetLabels
, ovalues
definido no pipeline será aplicado a todas as metas filhas. No entanto, se você definir mais de um valor para o mesmo a versão vai falhar.
Depois que cada manifesto é renderizado, o Cloud Deploy adiciona o valor de cada variável no manifesto renderizado.
Adicionar um parâmetro à configuração de destino
É possível adicionar pares de chave-valor a um destino. Se você usa parâmetros de implantação para distinguir entre vários destinos filhos, configurá-los nesses destinos filhos não em múltiplos destinos.
Configure seu manifesto do Kubernetes ou a definição do serviço do Cloud Run usando um parâmetro no lugar do valor que você quer definir no momento da implantação.
Veja um exemplo:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 env: - name: envvar1 value: example1 # from-param: ${application_env1} - name: envvar2 value: example2 # from-param: ${application_env2}
Nesse manifesto, o parâmetro
envvar1
é definido comoexample1
por padrão, eenvvar2
é definido comoexample2
por padrão.Configure seus destinos para incluir
deployParameters
Para cada parâmetro que você incluir, identifique o seguinte:
O nome da chave, que é o mesmo que a chave (variável) definida no manifesto.
Um valor para a chave. Se você não fornecer um valor, o valor padrão definido no manifesto será usado.
O YAML a seguir é a configuração de dois destinos. Cada destino inclui uma estrofe
deployParameters
que define um valor. Cada destino também inclui um rótulo, para corresponder aos parâmetros de implantação configurados em um estágio de pipeline.apiVersion: deploy.cloud.google.com/v1beta1 kind: Target metadata: name: prod1 labels: my-app: "post-render-config-1" description: development cluster deployParameters: application_env1: "newValue1" --- apiVersion: deploy.cloud.google.com/v1beta1 kind: target metadata: name: prod2 labels: my-app: "post-render-config-2" description: development cluster deployParameters: application_env1: "newValue2"
Quando a versão é criada, mas depois que os manifestos são renderizados, o Cloud Deploy adiciona esses valores aos manifestos renderizados se eles incluírem as chaves associadas.
Transmitir um parâmetro na criação da versão
Siga estas etapas para transmitir parâmetros e valores para a versão:
Configure o manifesto do Kubernetes ou Definição do serviço do Cloud Run usando um parâmetro no lugar do que você quer definir no momento da implantação.
Veja um exemplo:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx template: metadata: labels: app: nginx annotations: commit: defaultShaValue # from-param: ${git-sha} spec: containers: - name: nginx image: nginx:1.14.2
Neste exemplo, o SHA de confirmação é definido como uma variável chamada
${git-sha}
. Um valor para isso é transmitido na criação da versão, usando o método--deploy-parameters=
, conforme mostrado na próxima etapa.A sintaxe desta variável é
$
mais o nome da variável entre chaves. Neste por exemplo,${git-sha}
.Ao criar uma versão, inclua a opção
--deploy-parameters
no comandogcloud deploy releases create
.--deploy-parameters
recebe uma lista de pares de chave-valor separados por vírgulas, em que a chave é o marcador de posição que você adicionou ao manifesto.O comando vai ser parecido com este:
gcloud deploy releases create test-release-001 \ --project=my-example-project \ --region=us-central1 \ --delivery-pipeline=my-params-demo-app-1 \ --images=my-app-image=gcr.io/google-containers/nginx@sha256:f49a843c290594dcf4d193535d1f4ba8af7d56cea2cf79d1e9554f077f1e7aaa \ --deploy-parameters="git-sha=f787cac"
Quando a versão é criada, mas após a renderização do manifesto, o Cloud Deploy fornece os valores aos manifestos renderizados se eles incluírem as chaves associadas.
Implantar parâmetros com alvos personalizados
É possível usar qualquer parâmetro de implantação como uma variável de ambiente em alvos personalizados. Ao fazer isso, use o método syntax especificada para segmentações personalizadas.
Os parâmetros de implantação destinados como entradas para destinos personalizados podem começar com
customTarget/
, por exemplo, customTarget/vertexAIModel
. Se você usar esse
prefixo, use a seguinte sintaxe ao fazer referência a um parâmetro de implantação como uma
variável de ambiente:
CLOUD_DEPLOY_customTarget_[VAR_NAME]
Em que VAR_NAME
é o nome após a barra na
nome do parâmetro de implantação. Por exemplo, se você definir
parâmetro de implantação chamado customTarget/vertexAIModel
, faça referência a ele como
CLOUD_DEPLOY_customTarget_vertexAIModel
.
Implantar parâmetros com hooks de implantação
É possível usar qualquer parâmetro de implantação como uma variável de ambiente em hooks de implantação.
Implantar parâmetros com a verificação de implantação
É possível usar qualquer parâmetro de implantação como uma variável de ambiente na verificação de implantação.
Ver todos os parâmetros de uma versão
É possível conferir os parâmetros definidos para uma determinada versão. São
exibido em uma tabela na página Detalhes da versão e na linha de comando
(gcloud deploy releases describe
).
Na página principal do Cloud Deploy, clique no pipeline de entrega que inclui a versão que você quer consultar.
Na página Detalhes da versão, selecione a guia Artefatos.
Todos os parâmetros de implantação definidos para essa versão são mostrados em uma tabela, com o nome e o valor da variável em uma coluna e o destino ou os destinos afetados na outra coluna.
A seguir
Confira o guia de início rápido: usar parâmetros de implantação.
Saiba mais sobre o uso de implantações paralelas.