Hoje vamos nos concentrar nos aspectos GitOps do ACM e dividi-los usando a seguinte configuração de modelo:
Portanto, temos três clusters OpenShift aqui. ACM usa um modelo gerenciado por hub para gerenciar clusters, onde hub é o cluster que executa o ACM e gerenciado são os clusters que o ACM está gerenciando. O hub usa o seguinte software Red Hat:
| POR | Versão |
|---|---|
| Plataforma de contêiner Red Hat OpenShift | 4.5.7 |
| Red Hat Advanced Cluster Management | 2.0 Fix Pack 2.0.2 |
Observe que os clusters gerenciados têm rótulos diferentes, vamos usá-los ativamente ao colocar aplicativos em ambientes diferentes.
Conforme mostrado na figura, temos um cluster de desenvolvimento gerenciado chamado managed-cluster1-dev implantado na nuvem AWS na região da UE. E também há um cluster de produção gerenciado chamado managed-cluster2-prod, que também é implantado na AWS, na região dos EUA.
Ciclo de vida do aplicativo
ACM oferece recursos abrangentes de gerenciamento do ciclo de vida do aplicativo. Aqui, veremos aqueles que pertencem à categoria GitOps e serão úteis nos seguintes cenários:
- Implante seu aplicativo em vários ambientes.
- Implante Azul / Verde.
- Migração de aplicativos.
- Recuperação de desastre
Primeiro, vamos definir os termos e conceitos que operaremos neste artigo.
Canais Os
canais apontam para um local físico onde os recursos a serem implantados são armazenados. Aqui, usaremos tubos do tipo Git, embora existam outros tipos de tubos (Helm, Namespaces, etc.).
Saiba mais
PlacementRules
Ao criar e gerenciar regras de posicionamento, você define onde implantar suas assinaturas de recursos do Kubernetes e versões do Helm. Ao aplicar essas regras, você pode simplificar muito a implantação de recursos do Kubernetes em vários ambientes.
Saiba mais
assinaturas
As assinaturas são um conjunto de definições para selecionar recursos do Kubernetes em canais usando anotações, rótulos e versões. Os recursos de assinatura são configurados no hub e enviados para clusters gerenciados. O controlador de inscrição monitora o local de origem (canal) para recursos novos ou atualizados. Quando isso acontece, ele pode baixar o recurso correspondente diretamente do local de origem (canal) para o cluster gerenciado sem primeiro verificar o cluster do Hub (uma vez que a assinatura já foi enviada).
Uma assinatura pode filtrar as versões do Helm para selecionar a versão correta do gráfico. Nesse caso, o controlador de assinatura examina o parâmetro de versão para entender qual versão da versão do Helm (gráfico) deve ser usada para implantação.
Mais
aplicativos
O objeto Aplicativo pode ser considerado uma forma de agregar assinaturas em um grupo. Para isso, existem ferramentas adequadas e um console para agregar e visualizar todos os componentes do Aplicativo.
Mais detalhes
Repositório Git
Nossos aplicativos serão implantados de acordo com os modelos GitOps e, para diferentes ambientes, você precisará de diferentes manifestos que serão armazenados em um repositório Git, cuja estrutura é mostrada na tabela abaixo:
| Ramo | Descrição |
|---|---|
| Config | Armazena arquivos de base para aplicativos que são usados em todos os ambientes |
| Prod | Armazena arquivos de sobreposição para aplicativos usados em ambientes de produção |
| Etapa | Armazena arquivos de sobreposição para aplicativos que são usados em ambientes de teste |
Nota. O Red Hat ACM restringe como você estrutura seu repositório Git. Ele pode ser organizado não apenas conforme mostrado nesta tabela, mas também de qualquer outra forma conveniente para você.
Implementar o aplicativo em vários ambientes
Agora vamos ver como o ACM pode ajudá-lo a implantar seu aplicativo em vários ambientes usando um serviço da web simples que inverte palavras. Este serviço tem dois lançamentos: estágio (esta é a versão que os desenvolvedores estão testando atualmente) e produção (esta é a versão que os clientes estão usando).
ACM tem suporte para Kustomize , o que torna muito fácil personalizar aplicativos para o ambiente de implantação de destino.
Como já mencionado, em ambos os ambientes usamos o mesmo aplicativo, mas apenas em versões diferentes.
Para implantar o aplicativo, usaremos a ferramenta oc e um conjunto de yaml-manifestos com as configurações necessárias para ACM, que definem Channel, Subscription e PlacementRule. Tudo o que fazemos na linha de comando pode ser feito no console da web.
Na ferramenta oc, teremos três contextos configurados, um para cada ambiente:
| Contexto | Descrição |
|---|---|
| Cubo | Perfil CLI para o cluster HUB (onde ACM é implantado) |
| Dev | Perfil CLI para cluster de desenvolvimento gerenciado (managed-cluster1-dev) |
| Pró | Perfil CLI para cluster de produção gerenciado (managed-cluster2-prod) |
Você pode ler mais sobre os perfis CLI aqui .
Agora, vamos ver os recursos que serão usados em nosso exemplo:
Canal
apiVersion: apps.open-cluster-management.io/v1
kind: Channel
metadata:
name: acm-app-lifecycle-blog
namespace: open-cluster-management
spec:
type: Git
pathname: https://github.com/RHsyseng/acm-app-lifecycle-blog.git
Definimos Channel como um Git do tipo Channel, que nossas assinaturas usarão para obter recursos do Kubernetes para implantar nosso aplicativo.
Em nosso caso, o canal está configurado para receber recursos do Kubernetes do repositório Git github.com/RHsyseng/acm-app-lifecycle-blog.git.
Namespace
apiVersion: v1
kind: Namespace
metadata:
name: reverse-words-stage
Quando usamos a assinatura, o namespace que contém essa assinatura é passado para o cluster de implantação de destino. Portanto, aqui criamos um namespace chamado reverse-words-stage que será passado para nossos clusters dev por meio desta assinatura.
PlacementRule
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
name: development-clusters
namespace: reverse-words-stage
spec:
clusterConditions:
- type: "ManagedClusterConditionAvailable"
status: "True"
clusterSelector:
matchExpressions: []
matchLabels:
environment: "dev"
A lista de clusters onde as assinaturas são passadas é obtida do que o PlacementRule retorna. Em outras palavras, precisamos selecionar de alguma forma certos clusters de nossos ambientes e transferi-los para assinaturas diferentes, essa é exatamente a tarefa que PlacementRules resolve. Em
nosso exemplo, a PlacementRule chamada development-clusters retorna todos os clusters marcados como Disponíveis e com um rótulo que atende à condição do ambiente : dev. Ou seja, em nosso caso, a saída será um dev-cluster gerenciado denominado managed-cluster1-dev.
Inscrição
apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
name: reversewords-dev-app-subscription
namespace: reverse-words-stage
labels:
app: reversewords-dev-app
annotations:
apps.open-cluster-management.io/git-path: apps/reversewords/
apps.open-cluster-management.io/git-branch: stage
spec:
channel: open-cluster-management/acm-app-lifecycle-blog
placement:
placementRef:
kind: PlacementRule
name: development-clusters
No exemplo acima, Subscription é responsável por implantar uma lista de recursos do Kubernetes (tirada do Canal) para clusters da lista (tirada de PlacementRule). Além disso, você também pode especificar onde exatamente esses recursos do Kubernetes estão localizados no repositório Git (canal).
Nossa assinatura usa o canal que definimos acima e obtém recursos do Kubernetes do branch do estágio, onde os procura na pasta apps / reversewords /.
Inscrição
apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
name: reversewords-dev-app
namespace: reverse-words-stage
spec:
componentKinds:
- group: apps.open-cluster-management.io
kind: Subscription
descriptor: {}
selector:
matchExpressions:
- key: app
operator: In
values:
- reversewords-dev-app
O aplicativo ajuda a criar a topologia do nosso aplicativo em clusters gerenciados pelo ACM. Para fazer isso, o aplicativo seleciona uma ou mais assinaturas, que por fim criam recursos em vários clusters, para que possamos rastrear quem criou o quê e onde foi criado.
Nota. Aqui, cobrimos apenas os recursos que serão usados ao implementar um aplicativo em um ambiente de desenvolvimento. Recursos para outros ambientes podem ser encontrados no repositório GitHub e são bastante autoexplicativos e semelhantes aos que abordamos.
Implante o aplicativo em um ambiente de desenvolvimento
1. A primeira etapa é criar uma definição de canal.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/base/00_channel.yaml
2. Em seguida, criamos um namespace para armazenar os manifestos de nosso aplicativo.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/00_namespace.yaml
3. Agora criamos um PlacementRule que selecionará nossos clusters de desenvolvimento gerenciados.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/01_placement_rule.yaml
Veja o status da PlacementRule. Observe que esta regra selecionou o managed-cluster1-dev dev-cluster:
oc --context hub -n reverse-words-stage get placementrule development-clusters -o yaml
<OMITTED_OUTPUT>
status:
decisions:
- clusterName: managed-cluster1-dev
clusterNamespace: managed-cluster1-dev
4. Agora você pode criar uma assinatura e um aplicativo para direcionar o cluster dev usando PlacementRule.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/02_subscription-dev.yaml
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-stage/03_application-dev.yaml
Veja o status da assinatura. Preste atenção na palavra propagada, significa que a assinatura foi enviada ao cluster de destino:
oc --context hub -n reverse-words-stage get subscription reversewords-dev-app-subscription -o yaml
<OMITTED_OUTPUT>
status:
message: Active
phase: Propagated
5. Por fim, observamos o cluster dev e vemos que o aplicativo foi implantado e está funcionando.
oc --context dev -n reverse-words-stage get deployments,services,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/reverse-words 1/1 1 1 73s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/reverse-words LoadBalancer 172.30.217.208 a84668cb23acf4d109a78b119dfddbef-750551.eu-central-1.elb.amazonaws.com 8080:30053/TCP 73s
NAME READY STATUS RESTARTS AGE
pod/reverse-words-68b9b894dd-jfgpf 1/1 Running 0 73s
Se tentarmos executar solicitações para o cluster de produção, veremos que o aplicativo não está sendo executado lá.
oc --context pro -n reverse-words-stage get deployments,services,pods
No resources found in reverse-words-stage namespace.
6. Agora, vamos executar uma solicitação para nosso aplicativo e ter certeza de que implantamos a versão necessária, ou seja, teste:
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
Implantar o aplicativo em um ambiente de produção
1. Não há necessidade de criar um novo canal, já que usaremos o mesmo repositório Git do código-fonte, mas apenas um branch diferente.
2. Crie um namespace para armazenar os manifestos de nosso aplicativo.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/00_namespace.yaml
3. Agora criamos uma PlacementRule que seleciona os clusters de produção:
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/01_placement_rule.yaml
Veja o status da PlacementRule. Observe que esta regra selecionou o cluster de produção managed-cluster2-prod.
oc --context hub -n reverse-words-prod get placementrule production-clusters -o yaml
<OMITTED_OUTPUT>
status:
decisions:
- clusterName: managed-cluster2-prod
clusterNamespace: managed-cluster2-prod
4. Agora você pode criar uma assinatura e um aplicativo para definir o cluster de produção como o destino usando PlacementRule.
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/02_subscription-pro.yaml
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-prod/03_application-pro.yaml
Veja o status da assinatura. Preste atenção na palavra propagada, significa que a assinatura foi enviada ao cluster de destino:
oc --context hub -n reverse-words-prod get subscription reversewords-pro-app-subscription -o yaml
<OMITTED_OUTPUT>
status:
message: Active
phase: Propagated
5. E, finalmente, olhamos para o cluster de produção e vemos que o aplicativo foi implantado e está funcionando.
oc --context pro -n reverse-words-prod get deployments,services,pods
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/reverse-words 1/1 1 1 93s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/reverse-words LoadBalancer 172.30.100.0 a6067d9a2cd904003a1b53b65f9e1cb3-450574743.us-west-2.elb.amazonaws.com 8080:30293/TCP 96s
NAME READY STATUS RESTARTS AGE
pod/reverse-words-7dd94446c-vkzr8 1/1 Running 0 94s
6. Agora, vamos executar uma solicitação para nosso aplicativo e ter certeza de que implantamos a versão necessária, ou seja, produção:
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
7. Agora temos diferentes versões de nosso aplicativo para diferentes ambientes de implantação:
# Query development environment
curl http://$(oc --context dev -n reverse-words-stage get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
# Query production environment
curl http://$(oc --context pro -n reverse-words-prod get service reverse-words -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'):8080
# Dev Query
Reverse Words Release: Stage Release v0.0.3. App version: v0.0.3
# Pro Query
Reverse Words Release: Production release v0.0.2. App version: v0.0.2
Finalmente, vamos ver como fica no console da web:
Visão geral dos aplicativos ACM
Visualização do aplicativo de desenvolvimento ACM
Continua
No próximo post, mostraremos como usar o ACM para implantações Blue / Green, migração de aplicativos e recuperação de desastres.