O operador autônomo do Couchbase é um operador do Kubernetes que fornece integração nativa da nuvem com o Kubernetes de código aberto e o Red Hat Openshift. Ele permite que um usuário use a funcionalidade declarativa do Kubernetes para definir qual será o cluster do Couchbase Server e gerenciar os atributos desse cluster. Essa funcionalidade declarativa é útil, pois permite armazenar as definições do ambiente no controle de origem.
O objetivo do operador é gerenciar totalmente uma ou mais implantações do Couchbase Server. Ele gerencia o ciclo de vida do cluster (provisionamento, dimensionamento, upgrade, recuperação automática) e a configuração (volumes persistentes, grupos de servidores, XDCR, TLS, RBAC, backup/restauração). O operador é uma ferramenta potente no gerenciamento de um ambiente Couchbase em grande escala e é altamente recomendável que você leia o Documentação do operador do Couchbase.
Salvar e restaurar: Como migrar uma topologia não gerenciada
Adicionamos o Salvar e Restaurar recurso no Couchbase Autonomous Operator v2.3. Esse recurso permite que os usuários migrem um não gerenciado Couchbase Cluster e transformá-lo em um gerenciado cluster. Essa funcionalidade permite sondar um cluster do Couchbase criado pelo operador autônomo com topologia de dados não gerenciada e recuperar um arquivo YAML de topologia de dados que corresponda à topologia de dados atual do cluster do Couchbase. Um usuário pode pegar esse arquivo YAML de implantação e aplicá-lo ao cluster existente para bloquear a topologia ou aplicá-lo a um novo ambiente de cluster para migrar o ambiente.
Os casos de uso desse recurso são inúmeros! Ainda assim, o que vamos enfocar nesta postagem é a migração de um ambiente de uma topologia de dados gerenciada manualmente em um ambiente de R/D rápido/ágil para um ambiente de produção mais estável.
Quer você seja novo no Couchbase ou um profissional experiente, o novo Salvar e restaurar do Couchbase Autonomous Operator simplifica significativamente o seu pipeline de CI/CD. A possibilidade de fazer a transição fácil de um cluster não gerenciado para um cluster gerenciado permite que você continue o desenvolvimento em ritmo acelerado, mantendo o controle dos ambientes no pipeline.
Demonstração de uma migração de esquema de cluster do Couchbase
Para demonstrar essa funcionalidade, primeiro precisamos criar um cluster de servidor do Couchbase no Kubernetes em um estado não gerenciado. Usaremos este unmanaged.yaml file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
Versão da API: v1 gentil: Segredo metadados: nome: cb-example-auth tipo: Opaco dados: nome de usuário: QWRtaW5pc3RyYXRvcg== senha: cGFzc3dvcmQ= --- Versão da API: couchbase.com/v2 gentil: CouchbaseCluster metadados: nomecb-example-unmanaged especificação: imagem: couchbase/servidor:7.0.3 segurança: adminSecret: cb-example-auth rbac: gerenciado: falso baldes: gerenciado: falso servidores: - tamanho: 3 nome: all_services serviços: - dados - índice - consulta - pesquisa - eventos - análises |
Para criar esse cluster, use o comando: Isso cria um cluster simples não gerenciado com todos os serviços, mas desativa o gerenciamento de bucket e RBAC. Ele também inclui um segredo para acessar o cluster com um nome de usuário de Administrador e uma senha de senha.
|
1 |
kubectl criar -f ./não gerenciado.yaml |
Para acessar esse cluster, encaminhamos a porta 8091 para que possamos acessar a interface do usuário de administração do servidor Couchbase apenas para acesso rápido ao desenvolvimento. Se quiser acessar a porta de administração regularmente, consulte os documentos sobre a configuração de uma porta de balanceador de carga.
Para criar esse encaminhamento de porta, use o comando:
|
1 |
kubectl porto-avançar cb-exemplo-0000 8091 |
Agora podemos acessar a interface do usuário da Web na porta 8091 usando as credenciais de administrador e, em seguida, criar alguns buckets, escopos e coleções. Neste exemplo, criamos um BlogApp com um escopo para en-US e algumas coleções dentro desse escopo.
Em seguida, adicionamos o escopo para en-US.
Por fim, adicionamos o Blogs coleções.
Agora temos uma estrutura de árvore com a seguinte aparência:
|
1 2 3 4 |
Balde: BlogApp Escopo: en-EUA Coleção: Blogs Coleção: Receita |
Quando tivermos nossa topologia de dados, poderemos gerar um arquivo YAML usando o cao binário com o comando:
|
1 |
./cao salvar --couchbase-agrupamento cb-exemplo-não gerenciado --nome do arquivo ./topologia.yaml |
Isso produzirá nosso topology.yaml:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 |
--- Versão da API: couchbase.com/v2 gentil: CouchbaseBucket metadados: creationTimestamp: nulo nome: bucket-629f6ab0-d3ad-442e-b8e8-33e71412fae8 especificação: compressionMode: passivo Resolução de conflitos: seqno evictionPolicy (política de despejo): valueOnly ioPrioridade: baixo maxTTL: 0s memoryQuota: 256Mi minimumDurability (durabilidade mínima): nenhum nome: BlogApp réplicas: 1 escopos: gerenciado: verdadeiro recursos: - gentil: CouchbaseScope nome: scope-48d41118-fafd-48fa-a128-a539ffdb5efa - gentil: CouchbaseScope nome: scope-9807f3f5-f798-43f6-bab0-32c44fada0ef --- Versão da API: couchbase.com/v2 gentil: CouchbaseScope metadados: creationTimestamp: nulo nome: scope-48d41118-fafd-48fa-a128-a539ffdb5efa especificação: coleções: gerenciado: verdadeiro recursos: - gentil: CouchbaseCollection nome: collection-80bf5988-85ed-47b0-986b-44d52dca3389 - gentil: CouchbaseCollection nome: collection-6da06d0d-c07c-4847-b2b6-0c46f5fed67a nome: en-US --- Versão da API: couchbase.com/v2 gentil: CouchbaseCollection metadados: creationTimestamp: nulo nome: collection-80bf5988-85ed-47b0-986b-44d52dca3389 especificação: maxTTL: 0s nome: Receitas --- Versão da API: couchbase.com/v2 gentil: CouchbaseCollection metadados: creationTimestamp: nulo nome: collection-6da06d0d-c07c-4847-b2b6-0c46f5fed67a especificação: maxTTL: 0s nome: Blogs --- Versão da API: couchbase.com/v2 gentil: CouchbaseScope metadados: creationTimestamp: nulo nome: scope-9807f3f5-f798-43f6-bab0-32c44fada0ef especificação: coleções: gerenciado: verdadeiro preserveDefaultCollection: verdadeiro defaultScope: verdadeiro |
Clonagem de uma topologia de cluster
Com o arquivo de topologia, agora podemos restaurá-lo em outro cluster, clonando a estrutura em um novo ambiente. Para fazer isso, crie um arquivo managed.yaml com esse conteúdo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
Versão da API: couchbase.com/v2 gentil: CouchbaseCluster metadados: nome: cb-example-managed especificação: imagem: couchbase/servidor:7.0.3 segurança: adminSecret: cb-example-auth rbac: gerenciado: falso baldes: gerenciado: verdadeiro servidores: - tamanho: 3 nome: all_services serviços: - dados - índice - consulta - pesquisa - eventos - análises |
Em seguida, criamos o cluster gerenciado usando: Isso é semelhante ao nosso unmanaged.yamlmas, em vez disso, os compartimentos são gerenciado e reutilizamos nosso segredo do cluster não gerenciado.
|
1 |
kubectl criar -f gerenciado.yaml |
Restauração da topologia para o cluster gerenciado
Depois que o cluster for ativado, você poderá usar o cao binário para restaurar a topologia YAML para o cluster gerenciado recém-criado:
Por fim, para verificar, criaremos um encaminhamento de porta simples para o novo cluster gerenciado e verificaremos a topologia de dados. Use o seguinte comando para criar o encaminhamento de porta e abra o navegador para http://127.0.0.1:8091.
|
1 |
kubectl porto-avançar cb-exemplo-gerenciado-0000 8091 |
Você deve ser saudado com a topologia de dados apropriada.
Agora que migramos a topologia de dados, talvez queiramos migrar os dados de um ambiente para outro. Eu recomendo usar o Replicação entre centros de dados (XDCR) para facilitar a movimentação de dados de um cluster para outro. Você pode obter mais informações sobre a configuração do XDCR na seção Documentação do Couchbase Operator.
Próximas etapas e recursos
Alguns aspectos que devem ser levados em conta:
-
- Salvar não salva as funções/grupos RBAC. Você precisará migrá-los por conta própria.
- O cao o informará sobre todas as alterações a serem feitas no cluster de destino. Qualquer item marcado como excluir serão excluídos, o que pode resultar em perda de dados.
Esta postagem abordou os seguintes tópicos:
