{"id":12610,"date":"2021-12-20T08:00:59","date_gmt":"2021-12-20T16:00:59","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=12610"},"modified":"2025-06-13T21:33:21","modified_gmt":"2025-06-14T04:33:21","slug":"testing-couchbase-applications-why-wait","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/testing-couchbase-applications-why-wait\/","title":{"rendered":"Testando aplicativos do Couchbase, por que esperar?"},"content":{"rendered":"

Em meu blog anterior, discutimos a configura\u00e7\u00e3o de um cluster do Couchbase localmente em seu pr\u00f3prio hardware. A vantagem disso \u00e9 que reduz significativamente o TCO da sua infraestrutura de teste e o tempo necess\u00e1rio para adquirir uma nova infraestrutura de teste, o que \u00e9 especialmente importante se voc\u00ea estiver apenas come\u00e7ando sua jornada no Couchbase.<\/p>\n

Para levar todos ao mesmo ponto de partida, Aqui est\u00e1 um link para meu blog anterior<\/a>onde explicamos como criar rapidamente um cluster de desenvolvimento localmente usando o Operador Aut\u00f4nomo do Couchbase para Kubernetes.<\/p>\n

Ent\u00e3o, para onde poder\u00edamos ir a partir daqui? Estabelecer um ambiente de f\u00e1cil implementa\u00e7\u00e3o que imite a implementa\u00e7\u00e3o de seu aplicativo \u00e9 o \u00fanico caminho natural. Esse ser\u00e1 outro passo importante na dire\u00e7\u00e3o certa para permitir que voc\u00ea desenvolva e teste suas implementa\u00e7\u00f5es localmente, com o m\u00ednimo de esfor\u00e7o.<\/p>\n

Implementa\u00e7\u00e3o ainda mais simples<\/h4>\n

Simplificamos o m\u00e9todo de implanta\u00e7\u00e3o discutido em meu blog anterior<\/a>\u00c9 claro que ainda \u00e9 importante entender os componentes do operador do Couchbase que implantaremos, portanto, se ainda n\u00e3o o fez, consulte meu blog anterior.<\/p>\n

O novo m\u00e9todo de implanta\u00e7\u00e3o est\u00e1 contido no reposit\u00f3rio do operador-gitops<\/a> mantido pelo Couchbase (e, mais especificamente, pelo fant\u00e1stico Patrick Stephens). A \u00fanica coisa que voc\u00ea precisa fazer agora para ter um cluster do Couchbase implantado localmente \u00e9 executar o comando create-cluster.sh<\/em><\/a> script. Quando isso for conclu\u00eddo, voc\u00ea poder\u00e1 executar o script create-dev.sh<\/em><\/a> script. Dessa forma, voc\u00ea ter\u00e1 tudo o que precisa (em termos de infraestrutura) para testar os recursos do aplicativo Couchbase.<\/p>\n

Detalhamento da implanta\u00e7\u00e3o do desenvolvimento<\/h4>\n

Para que este seja um guia t\u00e9cnico pr\u00e1tico para voc\u00ea, as se\u00e7\u00f5es a seguir abordam todos os detalhes do que estamos fazendo no create-dev.sh<\/a> roteiro.<\/p>\n

Dockerfile<\/strong>
\nQuando eu era desenvolvedor, tinha que manter meus pr\u00f3prios ambientes de desenvolvimento e teste. A manuten\u00e7\u00e3o desses ambientes era um pesadelo, pois n\u00e3o havia muita automa\u00e7\u00e3o. As novas vers\u00f5es naturalmente introduziam mudan\u00e7as significativas no c\u00f3digo. Felizmente, tudo isso mudou e, neste artigo, mostramos um exemplo t\u00edpico de automa\u00e7\u00e3o do SDK do Node.js Dockerfile<\/a> do reposit\u00f3rio do operador-gitops<\/em>. Esta postagem do blog apresenta isso para que voc\u00ea possa replicar um em seu ambiente.<\/p>\n

DO NODO:16.9.1\r\n# Atualize a imagem para os pacotes mais recentes e obtenha algumas ferramentas de teste de rede\r\n# Instale o VIM - altere-o para um editor de sua escolha - desculpe, fui criado por selvagens\r\nExecute o apt-get update && \\\r\napt-get -y install git iputils-ping iproute2 vim && \\\r\nmkdir -p \/user\/app\r\n\r\n# \u00c9 necess\u00e1rio especificar um diret\u00f3rio existente para que todos os nossos outros comandos tenham um diret\u00f3rio de trabalho consistente para execu\u00e7\u00e3o\r\nWORKDIR \/usr\/app\r\n\r\n# Etapas retiradas do guia de instala\u00e7\u00e3o do SDK\r\n# Siga as etapas para come\u00e7ar a usar nosso SDK:\r\n# https:\/\/docs.couchbase.com\/nodejs-sdk\/current\/hello-world\/start-using-sdk.html\r\nEXECUTAR npm init -y && npm install couchbase --save\r\n\r\n# Fa\u00e7a o Hack to just sleep para podermos anexar\r\nCMD [\"sleep\", \"3600\"]<\/pre>\n
Vamos examinar isso linha por linha:<\/p>\n
    \n
  1. DO n\u00f3:16.9.1<\/strong> - essa \u00e9 a imagem base fornecida pelo Node.js para que n\u00e3o precisemos nos preocupar em instal\u00e1-la (entre outras coisas).<\/li>\n
  2. Execute o apt-get ...<\/strong> - esta \u00e9 uma s\u00e9rie de comandos para instalar ferramentas para testar a conectividade entre seu ambiente de desenvolvimento e as implanta\u00e7\u00f5es do Couchbase.<\/li>\n
  3. WORKDIR \/usr\/app<\/strong> - aqui, estamos definindo um diret\u00f3rio que sempre ser\u00e1 usado pelos comandos que seguem no dockerfile. Ele tamb\u00e9m define um caminho de entrada para que voc\u00ea chegue l\u00e1 quando entrar no cont\u00eainer.<\/li>\n
  4. EXECUTAR o npm init<\/strong> -y && npm install couchbase -save - isso instalar\u00e1 o Couchbase SDK de acordo com as instru\u00e7\u00f5es em nossos documentos.<\/li>\n
  5. CMD [\"sleep\", \"3600\u2033]<\/strong> - \u00e9 um hack para manter o cont\u00eainer ativo para que possamos anex\u00e1-lo.<\/li>\n<\/ol>\n
    Esses conceitos compartilhados tamb\u00e9m se aplicam a outros SDKs do Couchbase. Encontre uma imagem padr\u00e3o relevante, instale as ferramentas, defina um diret\u00f3rio de trabalho, instale o SDK do Couchbase, defina algo no lugar para que possamos anexar e testar o c\u00f3digo.<\/p>\n
    docker build -t \"${DEV_IMAGE}\" .\r\nkind load docker-image \"${DEV_IMAGE}\" --name=\"${CLUSTER_NAME}\"<\/pre>\n
    A primeira coisa que acontecer\u00e1 em nossa implanta\u00e7\u00e3o autom\u00e1tica do ambiente de desenvolvimento ser\u00e1 criar a imagem do Docker especificada no dockerfile e pr\u00e9-carregar a imagem no KIND (Kubernetes no Docker).<\/p>\n
    Desenvolvimento Implanta\u00e7\u00e3o de Kubernetes<\/h4>\n
    # Crie uma implanta\u00e7\u00e3o para nossa imagem de cont\u00eainer de desenvolvimento.\r\ncat << EOF | kubectl apply -f -\r\napiVersion: apps\/v1\r\nkind: Deployment\r\nmetadados:\r\nnome: couchbase-sdk-dev\r\nespa\u00e7o de nome: $NAMESPACE\r\nespecifica\u00e7\u00f5es:\r\nselector:\r\nmatchLabels:\r\ncouchSdk: "dev"\r\ntemplate:\r\nmetadata:\r\nlabels:\r\ncouchSdk: "dev"\r\nambiente: "dev"\r\nespecifica\u00e7\u00f5es:\r\ncontainers:\r\n- name: dev-container\r\nimage: $DEV_IMAGE\r\nimagePullPolicy: Never\r\nenv:\r\n- name: CB_HOST\r\nvalor: $CB_SERVICE\r\n# https:\/\/kubernetes.io\/docs\/concepts\/configuration\/secret\/#environment-variables-are-not-updated-after-a-secret-update\r\n- name: CB_USER\r\nvalueFrom:\r\nsecretKeyRef:\r\nnome: $AUTHENTICATION_SECRET\r\nchave: nome de usu\u00e1rio\r\n- nome: CB_PSWD\r\nvalueFrom:\r\nsecretKeyRef:\r\nnome: $AUTHENTICATION_SECRET\r\nchave: senha\r\nEOF\r\n# Observe que, se voc\u00ea n\u00e3o alterar nada, ele permanecer\u00e1 implantado a partir de uma execu\u00e7\u00e3o anterior.<\/pre>\n
    Nossa imagem de cont\u00eainer rec\u00e9m-criada agora pode ser utilizada em uma implanta\u00e7\u00e3o do Kubernetes em que o cont\u00eainer \u00e9 implantado e dimensionado pelo sistema. Se o pod implantado do nosso cont\u00eainer falhar, o controlador de implanta\u00e7\u00e3o do Kubernetes perceber\u00e1 isso e iniciar\u00e1 uma nova inst\u00e2ncia.<\/p>\n
    Fornecemos uma defini\u00e7\u00e3o de implanta\u00e7\u00e3o simples e agrad\u00e1vel no script create-dev.sh que usar\u00e1 nossa imagem do Docker e anexar\u00e1 alguns r\u00f3tulos simples para gerenciar a implanta\u00e7\u00e3o com o kubectl.<\/p>\n
    Implanta\u00e7\u00e3o Rollout<\/h4>\n
    echo \"Waiting for Dev Deployment to start up...\" (Aguardando o in\u00edcio da implanta\u00e7\u00e3o de desenvolvimento)\r\nuntil kubectl rollout status deployment\/couchbase-sdk-dev; do\r\necho -n '.'\r\nsleep 2\r\ndone\r\necho \"Implanta\u00e7\u00e3o de desenvolvimento configurada e pronta para funcionar\"\r\n\r\n# Emita o nome do pod de desenvolvimento\r\nDEV_POD=$(kubectl get pods -l couchSdk=dev --output=jsonpath='{.items[*].metadata.name}')\r\necho \"Nome do pod de desenvolvimento: $DEV_POD\"<\/pre>\n
    Sem a implementa\u00e7\u00e3o da defini\u00e7\u00e3o de implanta\u00e7\u00e3o, ela continuar\u00e1 sendo apenas uma defini\u00e7\u00e3o. A pr\u00f3xima etapa \u00e9 fazer uma implementa\u00e7\u00e3o e apresentar o nome do nosso pod para que possamos enviar nosso c\u00f3digo para ele.<\/p>\n
    Execu\u00e7\u00e3o de c\u00f3digo no cont\u00eainer<\/h4>\n
    Nesta etapa, executamos com \u00eaxito o script create-dev.sh. Agora temos a tarefa de colocar nosso c\u00f3digo no cont\u00eainer para test\u00e1-lo. Alguns comandos aqui nos ajudar\u00e3o a colocar o c\u00f3digo no cont\u00eainer e, em seguida, abrir um shell.<\/p>\n
    kubectl cp \/Users\/samredman\/dev\/node-couchbaseproject $DEV_POD_NAME_OUTPUTTED:\/usr\/app<\/pre>\n
    Este \u00e9 apenas um exemplo, mas os conceitos devem permanecer os mesmos. Aqui, pegamos nosso diret\u00f3rio de c\u00f3digo do SDK do Couchbase e o copiamos para o pod de desenvolvimento rec\u00e9m-criado (lembre-se de obter a sa\u00edda de eco de \"Dev Pod Name: X\").<\/p>\n
    kubectl exec --stdin --tty couchbase-sdk-dev-6bfbf76b7-zxln2 -- \/bin\/bash<\/pre>\n
    Esse comando nos levar\u00e1 ao shell dentro do cont\u00eainer. Voc\u00ea dever\u00e1 ver a altera\u00e7\u00e3o do caminho no prompt. A partir daqui, voc\u00ea pode executar o c\u00f3digo que copiou no comando \"kubectl cp\".<\/p>\n
    C\u00f3digo de amostra saboroso<\/h4>\n
    Fornecemos um pequeno script de amostra que segue os mesmos padr\u00f5es da nossa documenta\u00e7\u00e3o do SDK. Os documentos do SDK fazem um trabalho fant\u00e1stico ao explicar as caracter\u00edsticas do Couchbase dos blocos de constru\u00e7\u00e3o de um aplicativo Couchbase.<\/p>\n
    Observe esta documenta\u00e7\u00e3o que ajuda a determinar o endpoint correto ao qual voc\u00ea deve se conectar. A chave aqui \u00e9 o nome do cluster definido na implanta\u00e7\u00e3o do cluster e anexado a -srv. Para citar a documenta\u00e7\u00e3o: \"O nome do servi\u00e7o est\u00e1 no formato -srv.\"<\/p>\n
    As poucas configura\u00e7\u00f5es dispon\u00edveis na parte superior do script devem permanecer as mesmas para uma implementa\u00e7\u00e3o padr\u00e3o no Helm. Verifique se as credenciais de conex\u00e3o usadas no script correspondem \u00e0s da sa\u00edda do comando: helm get all couchbase<\/p>\n
    De qualquer forma, voc\u00ea deve verificar se as op\u00e7\u00f5es de configura\u00e7\u00e3o atendem \u00e0s suas expectativas. Lembre-se de que o c\u00f3digo n\u00e3o mente - se ele n\u00e3o conseguir se conectar, provavelmente n\u00e3o foi informado sobre como se conectar corretamente. No entanto, se voc\u00ea fizer altera\u00e7\u00f5es que se desviem dos padr\u00f5es, lembre-se de alterar o nome do cluster, o bucket e as credenciais de autentica\u00e7\u00e3o.<\/p>\n
    Conclus\u00e3o<\/h4>\n
    Voc\u00ea deve sair deste blog com um ambiente de desenvolvimento totalmente configurado, que lhe permitir\u00e1 testar o c\u00f3digo do Couchbase SDK em um cluster real do Couchbase, sem simula\u00e7\u00f5es! Espero que a automa\u00e7\u00e3o ajude voc\u00ea a ter mais tempo para escrever c\u00f3digo em vez de gerenciar ambientes de desenvolvimento, como eu tive que fazer durante meu tempo como desenvolvedor.<\/p>\n
    Aqui est\u00e3o os links diretos para os recursos usados nesta postagem:<\/span><\/p>\n