Prepare-se para a borda com o Sync Gateway

Introdução

Imagine que você está indo se encontrar com um cliente importante no centro de São Francisco, CA, e recebeu um e-mail com detalhes sobre para quem ligar quando chegar ao saguão do escritório. Você está no saguão, mas a recepção da rede móvel está totalmente inoperante. Você tenta abrir o cliente de e-mail, mas ele precisa de conexão de rede sempre que você inicia o aplicativo. Tenho certeza de que a incapacidade de ler o e-mail sem conectividade levará a uma experiência frustrante para o usuário.

Para evitar essas situações, os aplicativos agora são criados com o off-line primeiro paradigma. Isso significa simplesmente que a funcionalidade do aplicativo não é afetada pela falta intermitente de conectividade de rede. Além disso, o primeiro off-line geralmente implica a capacidade de sincronizar dados entre dispositivos de borda e o banco de dados de back-end.

Muitas soluções de banco de dados relacionais ou mesmo não relacionais tratam o celular e o backend como dois problemas separados, portanto, criar aplicativos off-line primeiro com essas soluções pontuais é praticamente impossível.

 

• 

 

O Couchbase, por outro lado, é o principal fornecedor de uma solução de borda para a nuvem totalmente integrada. Couchbase Lite product é o banco de dados incorporado para os dispositivos de borda (onde você pode executar consultas declarativas localmente no dispositivo), Gateway de sincronização é a tecnologia de gel que permite a sincronização de dados dos dispositivos de borda com o Cluster do Couchbase.

Neste artigo, vamos nos concentrar na implantação do Couchabse Cluster e do Sync Gateway na plataforma Kubernetes. O objetivo é que você obtenha experiência em primeira mão trabalhando com essas tecnologias e entenda a mecânica por trás de cada uma delas.

Mais uma lição que eu gostaria que você tirasse deste artigo são algumas das práticas recomendadas ao implementar essa solução em sua própria nuvem privada ou pública.

Práticas recomendadas

Como ouço essas perguntas de muitos dos meus clientes corporativos, decidi abordá-las primeiro falando sobre algumas das práticas recomendadas quando se trata de implementar o Couchbase na plataforma Kubernetes.

1. Sempre execute análise de dimensionamento do cluster do Couchbase primeiro, para planejar qual instância do EC2, tipos de dispositivos de armazenamento e espaço seriam necessários para o cluster. As estimativas de dimensionamento permanecem as mesmas para o cluster do Kubernetes, como seria feito para o cluster no local.
   No entanto, lembre-se de que, no K8s, estamos fazendo o dimensionamento dos nós do Kubernetes, onde os pods do Couchbase serão executados. É aí que a segunda prática recomendada entra em cena.
2. Uso spec.antiAffinity=true em couchbase-cluster.yaml durante a implantação do cluster na produção. Esse campo especifica se dois pods nesse cluster podem ou não ser implantados no mesmo nó do Kubernetes. Do ponto de vista da alta disponibilidade, não queremos colocar mais de um pod em cada um dos nós do K8s, de modo que a falha de um único nó derrube apenas um único pod.
3. No ambiente Kubernetes, é aconselhável gerenciar o posicionamento de pods em tipos de nós predefinidos (grande, xlarge, 4xlarge etc.), de modo que os recursos desejados possam ser garantidos no momento da implantação do cluster ou da recuperação automática. Você pode usar spec.servers[].pod.spec.nodeSelector (conforme mencionado em cluster couchbase.yaml), que especifica um mapa de valores-chave das restrições no posicionamento de nós para pods. Para que um pod seja elegível para execução em um nó, o nó deve ter cada um dos pares de valores-chave indicados como rótulos.
4. Uma última observação antes de começarmos a diversão: se o seu cluster K8s tiver nós homogêneos e você não quiser usar o seletor de nó para determinar o posicionamento do pod e, em seguida, use o método spec.servers[].resources para definir solicitações e limites. Novamente, isso ajudará a colocar pods com um pool predefinido de recursos.

OBSERVAÇÃO: No exemplo abaixo, usaremos nodeSelector para colocar os respectivos tipos de pod no grupos de nós para garantir os recursos desejados.

Pré-requisitos

Certifique-se de que você tenha uma conta AWS configurada (instruções fora do escopo deste blog) e que todas as ferramentas necessárias para experimentar essas instruções estejam prontas. Aqui está a lista de itens de que você precisa:

1. Faça o download da versão mais recente Operador autônomo do Couchbase e descompacte-o no computador local. O pacote Operator contém ferramentas de linha de comando que você usará para instalar o Operator.
2. Instalação e configuração kubectl em seu computador local - o kubectl é uma interface de linha de comando para executar comandos em clusters do Kubernetes.
3. Instale a versão mais recente CLI DO AWS - A CLI da AWS é uma ferramenta unificada que permite interagir com os serviços da AWS usando comandos em seu shell de linha de comando. Neste caso, usaremos a CLI da AWS para nos comunicarmos de forma segura com o cluster do Kubernetes em execução na AWS.

Quando você tiver cli do aws com as credenciais da sua conta, você pode passar para a seção de criação de um cluster do Kubernetes.

Etapa 1: criar um cluster K8s com vários nós

O Kubernetes (K8s) nos oferece a flexibilidade de provisionar máquinas de computação de tamanhos diferentes (vCPU, RAM, tamanho do disco) em um único cluster do Kubernetes para que os requisitos de recursos de vários serviços gerenciados possam ser atendidos em um único cluster do K8s.

Vamos aproveitar a mesma flexibilidade e oferecer três NodeGroupsque usaremos posteriormente para hospedar um conjunto específico de serviços do Couchbase.

1.1. Crie um cluster EKS na região de sua escolha

Primeiro, vamos implantar um cluster K8s em us-west-2 região e em duas zonas de disponibilidade us-west-2a/b. Você pode mencionar um vpc-cidr de acordo com suas necessidades, mas, neste exemplo, usaremos o bloco 172.16.0.0/20fornecendo-nos um intervalo de mais de 4K (2¹²) endereços IP, o que deve ser mais do que suficiente para nós.

1.2. Criar grupos de nós separados

Vamos criar nógrupo no cluster EKS para que possamos hospedar o Couchbase Dados instâncias de serviço. Neste exemplo, usaremos m5.large (2 vCPU e 8 GB de RAM) Máquinas EC2 como tipo de nómas o tamanho real do nó EC2 dependerá do planejamento da capacidade e do desempenho com base na sua carga de trabalho. Portanto, certifique-se de escolher o tipo certo de nós em sua implementação de produção.

Para hospedar Índice/Consulta criaremos um nodegroup separado com mais computação e RAM. Neste exemplo, usaremos r5.large (2 vCPUs e 16 GB de RAM) máquinas.

Por último, mas não menos importante, usaremos t2.xlarge (4 vCP e 16 GB de RAM) para hospedar Gateway de sincronização instância.

Quando os três grupos de nós estão prontos, podemos começar a rotular cada nó no nodegroup ou usar o rótulo pré-existente, mas primeiro confirme todos os grupos de nós estão prontos:

1.3. Rotular nós EKS

Escolhemos três tipos diferentes de máquinas EC2 para hospedar dados, Índice/Consultae gateway de sincronização máquinas apenas para dedicar os serviços do Couchbase a uma nógrupo tipo. Vamos usar um rótulo existente chamado beta.kubernetes.io/instance-type para a seleção de nós. Esse rótulo estará disponível por padrão para que não seja necessário criar um novo rótulo. Você pode simplesmente ver os rótulos dos nós executando este cmd:

Neste exemplo, estaremos hospedando dados serviço em m5.large máquinas, índice/consulta em r5.large máquinas e gateway de sincronização em t2.xlarge máquina.

Em um ambiente de produção real, entendemos que você pode ter um tipo diferente de máquina, mas não essencialmente um tipo dedicado a um tipo específico de serviço do Couchbase. Nesse caso, você pode criar rótulos mutuamente exclusivos para cada tipo de nó.

Você usaria rótulo do kubectl cmd para rotular todos os nós que você deseja usar somente para nós de dados desta forma:

Da mesma forma para rotular todos os nós de índice (consulta ou outro):

Depois de rotular todos os nós, você estará pronto para passar para a próxima seção.

OBSERVAÇÃO: Estamos usando beta.kubernetes.io/instance-type como rótulo, portanto, não precisamos criar nenhum novo rótulo para os nós.

Etapa 2: Instalar a definição de recurso personalizado

A primeira etapa da instalação do Operator é instalar a definição de recurso personalizado (CRD) que descreve o Couchbase tipos de recursos. Isso pode ser feito executando o comando abaixo no diretório do pacote Operator:

Etapa 3: Criar um espaço de nome

Os namespaces são uma forma de dividir os recursos do cluster entre vários usuários.

Os namespaces são uma forma de dividir os recursos do cluster entre vários usuários.

• Execute o seguinte comando para criar um namespace.

• Confirme se o Namespace foi criado com sucesso.

Etapa 4: Instalar o operador

O operador é composto de dois componentes: um controlador de admissão dinâmico por cluster (DAC) e um Operador por espaço de nome. Consulte a seção arquitetura da operadora para obter informações adicionais sobre o que é necessário e considerações de segurança.

4.1. Instalar o controlador de admissão dinâmico (DAC)

O DAC permite que os recursos personalizados sejam modificados e interrogados antes que um recurso seja aceito e confirmado no etcd. A execução do DAC nos permite adicionar padrões sensatos às configurações do cluster do Couchbase, minimizando assim o tamanho das especificações. Ele também nos permite manter a compatibilidade com versões anteriores quando novos atributos são adicionados e precisam ser preenchidos. Isso torna a experiência de uso dos recursos do Couchbase semelhante à dos tipos de recursos nativos.

Vamos agora instalar o Dynamic Admission Controller.

• Abra uma janela do Terminal e vá para o diretório em que você descompactou o pacote Operator. Execute o seguinte comando para instalar o DAC no diretório padrão namespace.

• Confirme se o controlador de admissão foi implantado com êxito.

4.2. Instalar o operador do Couchbase

Agora, vamos implementar o Operator no oficina executando o seguinte comando.

A execução do comando acima faz o download da imagem do Operator Docker e cria um arquivo implantaçãoque gerencia uma única instância do Operator. O Operator usa uma implantação para que possa reiniciar o pod se ele morrer.

Depois de executar o kubectl create geralmente leva menos de um minuto para o Kubernetes implantar o Operator e para que ele esteja pronto para ser executado.

4.3. Verificar o status da implantação

Você pode usar o seguinte comando para verificar o status da implantação:

4.4. Verificar o status do Operador

Execute o seguinte comando para verificar se o Operator foi iniciado com êxito:

Se o Operator estiver ativo e em execução, o comando retornará uma saída em que o PRONTO shows de campo 1/1como, por exemplo:

Etapa 5. Implantar o cluster do Couchbase

Em um ambiente de produção em que o desempenho e o SLA do sistema são mais importantes, devemos sempre planejar a implantação do cluster do Couchbase usando volumes persistentes, pois isso ajuda:

• Recuperação de dados: Os volumes persistentes permitem que os dados associados aos pods sejam recuperados no caso de um pod ser encerrado. Isso ajuda a evitar a perda de dados e a construção demorada de índices ao usar serviços de dados ou de índices.
• Realocação de cápsulas: O Kubernetes pode decidir expulsar pods que atingem limites de recursos, como limites de CPU e memória. Os pods que têm backup com Volumes persistentes podem ser encerrados e reiniciados em nós diferentes sem incorrer em tempo de inatividade ou perda de dados.
• Provisionamento dinâmico: O Operator criará Persistent Volumes sob demanda à medida que seu cluster for dimensionado, aliviando a necessidade de pré-provisionar o armazenamento do cluster antes da implementação.
• Integração com a nuvem: O Kubernetes se integra aos provisionadores de armazenamento nativos disponíveis nos principais fornecedores de nuvem, como AWS e GCE.

5.1. Criar segredo para o console de administração do Couchbase

A primeira coisa que precisamos fazer é criar uma credencial secreta que será usada pelo console administrativo da Web durante o login. Por conveniência, um exemplo de segredo é fornecido no pacote Operator. Quando você o envia para o cluster do Kubernetes, o segredo define o nome de usuário como Administrator e a senha como password.

Para empurrar o secret.yaml em seu cluster do Kubernetes, execute o seguinte comando:

5.2 Criar classe de armazenamento para o cluster k8s

Para usar o PersistentVolume nos serviços do Couchbase (dados, índice, pesquisa etc.), precisamos criar classes de armazenamento (sc-nas.yaml). Execute o kubectl para criar uma nova classe de armazenamento baseada em SSD:

5.3. Implantar o cluster do Couchbase

A especificação completa para implantar o cluster do Couchbase em 3 zonas diferentes usando volumes persistentes pode ser vista na seção couchbase-cluster.yaml . Esse arquivo, juntamente com outros arquivos YAML de amostra usados neste artigo, pode ser baixado deste repositório git.

Abra o arquivo YAML que você acabou de baixar e observe como estamos usando nodeSelector para colocar os pods nos nós que têm o valor específico de beta.kubernetes.io/instance-type etiqueta.

Agora use kubectl para implantar o cluster, mas certifique-se de que esteja usando couchbase-cluster.yaml do git, e não o arquivo de mesmo nome presente no diretório de trabalho atual.

Isso iniciará a implantação do cluster do Couchbase e, se tudo correr bem, teremos quatro pods do cluster do Couchbase hospedando os serviços de acordo com o arquivo de configuração acima. Para verificar o progresso, execute este comando, que observará (argumento -w) o progresso da criação dos pods:

Para visualizar qual pod está sendo executado em qual nó, você pode executar:

Você notaria que Índice/Consulta O serviço está sendo executado no pod cbdemo-0002 e cbdemo-0003 que é hospedado nos nós EKS com rótulo beta.kubernetes.io/instance-type: r5.large e dados pods de serviço (cbdemo-0000, cbdemo-0001) são colocados em nós EKS com rótulo beta.kubernetes.io/instance-type: m5.large. Isso significa que nodeSelector definido em couchbase-cluster.yaml aplicou com sucesso o posicionamento de pods nos nós com os recursos desejados.

Nesse ponto, você pode fazer o encaminhamento de porta da seguinte forma:

E acesse o console da Web digitando https://localhost:18091 no navegador.

Etapa 6. Implantação de um cluster do Sync Gateway

Grande progresso até agora na implantação de um cluster do Couchbase com várias zonas e altamente disponível usando volumes de armazenamento persistentes. Agora, antes de começarmos a implementar o Sync Gateway, precisamos nos certificar de mais duas coisas:

6.1 Pré-requisitos do Sync Gateway

• Temos um bucket disponível no qual o aplicativo cliente e o Sync Gateway gravarão os dados. Ainda não temos nenhum bucket disponível para gravação, portanto, vamos criar um bucket preparação do balde do Console da Web.

• 

Figura 2: Preparação bucket criado com 2 GB de espaço.

OBSERVAÇÃO: Usamos 2 GB de RAM para esse bucket, mas no ambiente de produção você atribuiria a RAM com base nas estimativas de dimensionamento que você ou o arquiteto de soluções do Couchbase fizeram para o seu caso de uso comercial.

• Temos um usuário RBAC em vigor com o nome Acesso a aplicativos no nível do balde.

Podemos simplesmente criar um Couchbase User como geralmente fazemos, mas para tornar isso um pouco mais interessante, vamos usar um externo (também conhecido como LDAP). Na seção couchbase-cluster.yaml você pode encontrar detalhes de um terceiro Servidor de teste LDAP que usamos neste exemplo.

Se você quiser se conectar a um servidor LDAP diferente, basta atualizar ldap detalhes do servidor no couchbase-cluster.yaml e aplicar as alterações. Voltemos à criação de um usuário e à atribuição do nível de bucket Acesso a aplicativos função.

• 

Figura 3: Usando newton como o usuário externo, que será automaticamente confirmado como existe.

• 

Figura 4: Detalhes do usuário após clicar no botão Adicionar usuário botão.

Até agora, tudo bem. O usuário do Bucket e do RBAC está pronto, portanto, podemos prosseguir com a configuração do Gateway de sincronização.

6.2 Configuração do gateway de sincronização

Para que Gateway de sincronização Para nos comunicarmos com o Couchbase Cluster, precisamos fornecer detalhes do banco de dados, do bucket e da credencial. Usaremos o banco de dados string de conexão como couchbase://cbdemo-srv.cbdb.svc.cluster.local como pode ser visto no trecho abaixo:

Uma coisa que eu gostaria de destacar é que, com Sync Gateway 2.7 (ou superior), os clientes corporativos agora podem designar vários nós do Sync Gateway como nós de importação (para lidar com as gravações do Couchbase Server), o que proporciona maior resiliência. Portanto, estamos usando import_docs: true no arquivo de configuração.

Você pode encontrar todos os outros atributos de configuração em sgw-config.yaml file. Usaremos esse arquivo para criar o segredo e salvar as configurações nele também.

Para visualizar sgw-config executar secretamente o cmd abaixo:

6.3 Controlador de implantação

Depois de definir o segredo e a configuração, estamos quase prontos para implantar Gateway de sincronização em nosso cluster Kubernetes. Ajuste o réplicas e GOMAXPROCS com base em seus requisitos de produção, mas, neste exemplo, vamos implantar duas réplicas com um máximo de uma única vCPU por réplica.

Implementar sgw-deployment.yaml arquivo via kubectl cmd:

Você pode visualizar o progresso da implantação executando:

Como pode ser visto acima, as duas instâncias de réplica estão em funcionamento e agora só precisamos colocar um balanceador de carga na frente.

6.4 Implantar um balanceador de carga

Em uma implementação de produção, você provavelmente terá um ou mais nós do Sync Gateway liderados por um balanceador de carga.

Você implantará o balanceador de carga usando o Balanceador de carga do Kubernetes serviço. O serviço de balanceador de carga fornece um endereço IP acessível externamente e roteia o tráfego para as portas corretas no cluster.

• Crie um novo arquivo chamado sgw-lb.yaml com os seguintes atributos. Observe que estamos encaminhando tanto a 4984 (porta de acesso público) quanto a 4985 (porta de administração)

Observação Estamos encaminhando a 4984 (porta de acesso público) e a 4985 (porta de administração) por meio do balanceador de carga.

• Implante o balanceador de carga usando sgw-lb.yaml arquivo.

• Verifique os pods que o balanceador de carga está direcionando.

Se tudo estiver implantado corretamente, você verá algo semelhante ao seguinte:

Anote os Ingresso do LoadBalancer valor.

6.5 Teste a instalação

Quando o Load Balancer estiver on-line, poderemos confirmar a acessibilidade do cluster do Sync Gateway por meio de Ingresso do LoadBalancer (conforme mencionado na saída acima). Basta usar enrolar cmd:

Ele deve retornar o seguinte.

Pronto! O Sync Gateway está totalmente funcional e pronto para assumir a carga de trabalho do aplicativo cliente (via Couchbase Lite).

6.5.1 Teste de leitura/escrita de documentos

Em um blog separado, discutirei como é possível desenvolver aplicativos para os dispositivos de borda usando Couchbase Lite mas para testar a sanidade de nossa configuração de ponta a ponta, podemos executar rapidamente operações simples de POST e GET usando Gateway de sincronização API REST pública.

Vamos usar o comando curl para inserir alguns documentos:

O primeiro documento foi inserido e a chave do documento foi gerada automaticamente como c4988cff19c632a724e13d4390b23b82.

O segundo documento também foi inserido com sucesso, usando credenciais de administrador e a chave de documento gerada automaticamente é 8f02cab34faa17d61ca89aa05ade372e.

Agora podemos obter o documento executando a operação GET usando o Sync Gateway API REST pública:

Conclusão

O Couchbase Sync Gateway é a tecnologia crítica de sincronização de dados que permite que os desenvolvedores de aplicativos criem soluções de borda para a nuvem. Neste artigo, usamos a versão mais recente do Couchbase Autonomous Operator para instalar o cluster do Couchbase e o Sync Gateway na plataforma Kubernetes da nuvem pública. Em artigos futuros, vou me basear neste artigo e mostrar como você pode fazer muitas outras coisas de nível empresarial (como criptografia, LDAP, desenvolvimento do Couchbase Lite e muito mais). Até lá, bom aprendizado.