Em meu blog anterior, discutimos a configuração de um cluster do Couchbase localmente em seu próprio hardware. A vantagem disso é que reduz significativamente o TCO da sua infraestrutura de teste e o tempo necessário para adquirir uma nova infraestrutura de teste, o que é especialmente importante se você estiver apenas começando sua jornada no Couchbase.
Para levar todos ao mesmo ponto de partida, Aqui está um link para meu blog anterioronde explicamos como criar rapidamente um cluster de desenvolvimento localmente usando o Operador Autônomo do Couchbase para Kubernetes.
Então, para onde poderíamos ir a partir daqui? Estabelecer um ambiente de fácil implementação que imite a implementação de seu aplicativo é o único caminho natural. Esse será outro passo importante na direção certa para permitir que você desenvolva e teste suas implementações localmente, com o mínimo de esforço.
Implementação ainda mais simples
Simplificamos o método de implantação discutido em meu blog anteriorÉ claro que ainda é importante entender os componentes do operador do Couchbase que implantaremos, portanto, se ainda não o fez, consulte meu blog anterior.
O novo método de implantação está contido no repositório do operador-gitops mantido pelo Couchbase (e, mais especificamente, pelo fantástico Patrick Stephens). A única coisa que você precisa fazer agora para ter um cluster do Couchbase implantado localmente é executar o comando create-cluster.sh script. Quando isso for concluído, você poderá executar o script create-dev.sh script. Dessa forma, você terá tudo o que precisa (em termos de infraestrutura) para testar os recursos do aplicativo Couchbase.
Detalhamento da implantação do desenvolvimento
Para que este seja um guia técnico prático para você, as seções a seguir abordam todos os detalhes do que estamos fazendo no create-dev.sh roteiro.
Dockerfile
Quando eu era desenvolvedor, tinha que manter meus próprios ambientes de desenvolvimento e teste. A manutenção desses ambientes era um pesadelo, pois não havia muita automação. As novas versões naturalmente introduziam mudanças significativas no código. Felizmente, tudo isso mudou e, neste artigo, mostramos um exemplo típico de automação do SDK do Node.js Dockerfile do repositório do operador-gitops. Esta postagem do blog apresenta isso para que você possa replicar um em seu ambiente.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
DE nó:16.9.1 # Atualize a imagem para os pacotes mais recentes e obtenha algumas ferramentas de teste de rede # Instale o VIM - altere isso para um editor de sua escolha - desculpe, fui criado por selvagens CORRER apto-obter atualização &lificador;&lificador; \ apto-obter -y instalar git iputils-ping iproute2 vim &lificador;&lificador; \ mkdir -p /usuário/aplicativo # Necessidade de especificar um diretório existente para que todos os nossos outros comandos tenham um diretório de trabalho consistente para execução WORKDIR /usr/aplicativo # Etapas retiradas do guia de instalação do SDK # Siga as etapas para começar a usar nosso SDK: # https://docs.couchbase.com/nodejs-sdk/current/hello-world/start-using-sdk.html CORRER npm inicial -y &lificador;&lificador; npm instalar couchbase --salvar # Hack to just sleep para que possamos anexar CMD ["sleep" (dormir),"3600"] |
Vamos examinar isso linha por linha:
- DO nó:16.9.1 - essa é a imagem base fornecida pelo Node.js para que não precisemos nos preocupar em instalá-la (entre outras coisas).
- Execute o apt-get ... - esta é uma série de comandos para instalar ferramentas para testar a conectividade entre seu ambiente de desenvolvimento e as implantações do Couchbase.
- WORKDIR /usr/app - aqui, estamos definindo um diretório que sempre será usado pelos comandos que seguem no dockerfile. Ele também define um caminho de entrada para que você chegue lá quando entrar no contêiner.
- EXECUTAR o npm init -y && npm install couchbase -save - isso instalará o Couchbase SDK de acordo com as instruções em nossos documentos.
- CMD ["sleep", "3600″] - é um hack para manter o contêiner ativo para que possamos anexá-lo.
Esses conceitos compartilhados também se aplicam a outros SDKs do Couchbase. Encontre uma imagem padrão relevante, instale as ferramentas, defina um diretório de trabalho, instale o SDK do Couchbase, defina algo no lugar para que possamos anexar e testar o código.
|
1 2 |
doca construir -t "${DEV_IMAGE}" . gentil carregar doca-imagem "${DEV_IMAGE}" --nome="${CLUSTER_NAME}" |
A primeira coisa que acontecerá em nossa implantação automática do ambiente de desenvolvimento será criar a imagem do Docker especificada no dockerfile e pré-carregar a imagem no KIND (Kubernetes no Docker).
Desenvolvimento Implantação de Kubernetes
|
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 |
# Crie uma implementação para nossa imagem de contêiner de desenvolvimento. gato << EOF | kubectl aplicar -f - Versão da API: aplicativos/v1 gentil: Implantação metadados: nome: couchbase-sdk-dev espaço de nome: $NAMESPACE especificação: seletor: matchLabels: couchSdk: "dev" modelo: metadados: rótulos: couchSdk: "dev" ambiente: "dev" especificação: contêineres: - nome: dev-contêiner imagem: $DEV_IMAGEM imagePullPolicy: Nunca env: - nome: CB_HOST valor: $CB_SERVIÇO # https://kubernetes.io/docs/concepts/configuration/secret/#environment-variables-are-not-updated-after-a-secret-update - nome: CB_USUÁRIO valueFrom: secretKeyRef: nome: $AUTHENTICATION_SECRET chave: nome de usuário - nome: CB_PSWD valueFrom: secretKeyRef: nome: $AUTHENTICATION_SECRET chave: senha EOF # Observe que, se você não alterar nada, ele permanecerá implantado a partir de uma execução anterior. |
Nossa imagem de contêiner recém-criada agora pode ser utilizada em uma implantação do Kubernetes em que o contêiner é implantado e dimensionado pelo sistema. Se o pod implantado do nosso contêiner falhar, o controlador de implantação do Kubernetes perceberá isso e iniciará uma nova instância.
Fornecemos uma definição de implantação simples e agradável no script create-dev.sh que usará nossa imagem do Docker e anexará alguns rótulos simples para gerenciar a implantação com o kubectl.
Implantação Rollout
|
1 2 3 4 5 6 7 8 9 10 |
eco "Aguardando o início da implantação de desenvolvimento..." até que kubectl lançamento status implantação/couchbase-sdk-dev; fazer eco -n '.' dormir 2 feito eco "Implantação de desenvolvimento configurada e pronta para uso" # Emite o nome do pod de desenvolvimento DEV_POD=$(kubectl obter cápsulas -l couchSdk=dev --saída=jsonpath='{.items[*].metadata.name}') eco "Nome do pod de desenvolvimento: $DEV_POD" |
Sem a implementação da definição de implantação, ela continuará sendo apenas uma definição. A próxima etapa é fazer uma implementação e apresentar o nome do nosso pod para que possamos enviar nosso código para ele.
Execução de código no contêiner
Nesta etapa, executamos com êxito o script create-dev.sh. Agora temos a tarefa de colocar nosso código no contêiner para testá-lo. Alguns comandos aqui nos ajudarão a colocar o código no contêiner e, em seguida, abrir um shell.
|
1 |
kubectl cp /Usuários/samredman/dev/nó-projeto couchbase $DEV_POD_NAME_OUTPUTTED:/usr/aplicativo |
Este é apenas um exemplo, mas os conceitos devem permanecer os mesmos. Aqui, pegamos nosso diretório de código do SDK do Couchbase e o copiamos para o pod de desenvolvimento recém-criado (lembre-se de obter a saída de eco de "Dev Pod Name: X").
|
1 |
kubectl executar --stdin --tty couchbase-sdk-dev-6bfbf76b7-zxln2 -- /caixa/bash |
Esse comando nos levará ao shell dentro do contêiner. Você deverá ver a alteração do caminho no prompt. A partir daqui, você pode executar o código que copiou no comando "kubectl cp".
Código de amostra saboroso
Fornecemos um pequeno script de amostra que segue os mesmos padrões da nossa documentação do SDK. Os documentos do SDK fazem um trabalho fantástico ao explicar as características do Couchbase dos blocos de construção de um aplicativo Couchbase.
Observe esta documentação que ajuda a determinar o endpoint correto ao qual você deve se conectar. A chave aqui é o nome do cluster definido na implantação do cluster e anexado a -srv. Para citar a documentação: "O nome do serviço está no formato -srv."
As poucas configurações disponíveis na parte superior do script devem permanecer as mesmas para uma implementação padrão no Helm. Verifique se as credenciais de conexão usadas no script correspondem às da saída do comando: helm get all couchbase
De qualquer forma, você deve verificar se as opções de configuração atendem às suas expectativas. Lembre-se de que o código não mente - se ele não conseguir se conectar, provavelmente não foi informado sobre como se conectar corretamente. No entanto, se você fizer alterações que se desviem dos padrões, lembre-se de alterar o nome do cluster, o bucket e as credenciais de autenticação.
Conclusão
Você deve sair deste blog com um ambiente de desenvolvimento totalmente configurado, que lhe permitirá testar o código do Couchbase SDK em um cluster real do Couchbase, sem simulações! Espero que a automação ajude você a ter mais tempo para escrever código em vez de gerenciar ambientes de desenvolvimento, como eu tive que fazer durante meu tempo como desenvolvedor.
Aqui estão os links diretos para os recursos usados nesta postagem:
- Blog: Como criar uma prova de conceito de operador autônomo do Couchbase
- Ferramentas: Implementação do Couchbase Operator com Helm e KIND
- Repositório do operador-gitops do Couchbase
- create-cluster.sh e create-dev.sh roteiros
- Dockerfile para o SDK do Couchbase Node.js
- Exemplo de script do SDK do Couchbase Node.js
- Documentos: Instalar o SDK do Couchbase
Documentos: Localizando o ponto de extremidade do cluster para o DNS do Kubernetes
