{"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\/es\/testing-couchbase-applications-why-wait\/","title":{"rendered":"Probar aplicaciones Couchbase, \u00bfa qu\u00e9 espera?"},"content":{"rendered":"

In my previous blog, we discussed setting up a Couchbase cluster locally on your own hardware. The beauty of this was that it significantly reduces both the TCO of your testing infrastructure and the time needed to acquire new test infrastructure, which is especially important if you’re just starting your Couchbase journey.<\/p>\n

To bring everyone to the same starting point, here’s a link to my previous blog<\/a>, where we ran through how to quickly spin up a development cluster locally using the Couchbase Autonomous Operator for Kubernetes.<\/p>\n

So where could we possibly go from here? Establishing an easily deployed environment that would mimic your application deployment is the only natural path. This will be another important step in the right direction to allow you to both develop and test your deployments locally, with minimal effort.<\/p>\n

Even Simpler Deployment<\/h4>\n

We have simplified the deployment method discussed in my previous blog<\/a>, of course it is still important to understand the components of the Couchbase operator we will deploy, so if you haven’t already, please reference my previous blog.<\/p>\n

The new method of deployment is contained within the operator-gitops repo<\/a> maintained by Couchbase (and, more specifically, the fantastic Patrick Stephens). The only thing you now need to do to have a Couchbase cluster deployed locally is run the create-cluster.sh<\/em><\/a> script. Once this is complete, you can run your create-dev.sh<\/em><\/a> script. Just like that, you’ll have everything you need (infrastructure-wise) to test your Couchbase Application features.<\/p>\n

Development Deployment Breakdown<\/h4>\n

To help this be a practical technical guide for you, the following sections cover all the details of what we are doing in the create-dev.sh<\/a> script.<\/p>\n

Dockerfile<\/strong>
\nWhen I was a developer, I had to maintain my own development and test environments. Maintaining these environments was a nightmare as there wasn’t much in the way of automation. New releases naturally introduced breaking code changes. Thankfully, this has all changed, and we show a typical Node.js SDK example of automation in this Dockerfile<\/a> from the operator-gitops repo<\/em>. This blog post presents this so that you can replicate one in your environment.<\/p>\n

FROM node:16.9.1\r\n# Update the image to the latest packages & get some network test tools\r\n# Install VIM - change this to an editor of your choice - sorry I was raised by savages\r\nRUN apt-get update && \\\r\napt-get -y install git iputils-ping iproute2 vim && \\\r\nmkdir -p \/user\/app\r\n\r\n# Need to specify an existing directory so that all our other commands have a consistent working directory to run in\r\nWORKDIR \/usr\/app\r\n\r\n# Steps taken from install SDK guide\r\n# Follow the steps to get started with our SDK:\r\n# https:\/\/docs.couchbase.com\/nodejs-sdk\/current\/hello-world\/start-using-sdk.html\r\nRUN npm init -y && npm install couchbase --save\r\n\r\n# Hack to just sleep so we can attach\r\nCMD [\"sleep\",\"3600\"]<\/pre>\n
We’ll go through this line by line:<\/p>\n
    \n
  1. FROM node:16.9.1<\/strong> – this is the base image provided by Node.js so that we don’t have to worry about installing it (amongst other things).<\/li>\n
  2. RUN apt-get \u2026<\/strong> – this is a series of commands to install tools for testing connectivity between your development environment and Couchbase deployments.<\/li>\n
  3. WORKDIR \/usr\/app<\/strong> – here, we’re setting a directory which will always be used by the commands which follow in the dockerfile. It also sets an entry path so that you’ll land there when you shell into the container.<\/li>\n
  4. RUN npm init<\/strong> -y && npm install couchbase –save – this will install the Couchbase SDK as per the instructions in our docs.<\/li>\n
  5. CMD [“sleep”,”3600″]<\/strong> – this is a hack to keep the container alive so we can attach.<\/li>\n<\/ol>\n
    These shared concepts also apply to other Couchbase SDKs. Find a relevant default image, install the tools, set a workdir, install the Couchbase SDK, set something in place so we can attach in and test code.<\/p>\n
    docker build -t \"${DEV_IMAGE}\" .\r\nkind load docker-image \"${DEV_IMAGE}\" --name=\"${CLUSTER_NAME}\"<\/pre>\n
    The first thing that will happen in our automatic dev environment deployment will be to build the Docker image specified in the dockerfile and preload the image in KIND (Kubernetes in Docker).<\/p>\n
    Development Kubernetes Deployment<\/h4>\n
    # Create a deployment for our dev container image.\r\ncat << EOF | kubectl apply -f -\r\napiVersion: apps\/v1\r\nkind: Deployment\r\nmetadata:\r\nname: couchbase-sdk-dev\r\nnamespace: $NAMESPACE\r\nspec:\r\nselector:\r\nmatchLabels:\r\ncouchSdk: \"dev\"\r\ntemplate:\r\nmetadata:\r\nlabels:\r\ncouchSdk: \"dev\"\r\nenvironment: \"dev\"\r\nspec:\r\ncontainers:\r\n- name: dev-container\r\nimage: $DEV_IMAGE\r\nimagePullPolicy: Never\r\nenv:\r\n- name: CB_HOST\r\nvalue: $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\nname: $AUTHENTICATION_SECRET\r\nkey: username\r\n- name: CB_PSWD\r\nvalueFrom:\r\nsecretKeyRef:\r\nname: $AUTHENTICATION_SECRET\r\nkey: password\r\nEOF\r\n# Note that if you do not change anything then it will stay deployed from a previous run.<\/pre>\n
    Our newly created container image can now be utilized in a Kubernetes deployment where the container is deployed and scaled by the system. Should our container’s deployed pod fail, the Kubernetes Deployment Controller will notice this and fire up a new instance.<\/p>\n
    We have provided a nice and simple deployment definition within the create-dev.sh script that will use our Docker image and attach some simple labels to manage the deployment with kubectl.<\/p>\n
    Deployment Rollout<\/h4>\n
    echo \"Waiting for Dev Deployment to start up...\"\r\nuntil kubectl rollout status deployment\/couchbase-sdk-dev; do\r\necho -n '.'\r\nsleep 2\r\ndone\r\necho \"Dev Deployment configured and ready to go\"\r\n\r\n# Output the name of the development pod\r\nDEV_POD=$(kubectl get pods -l couchSdk=dev --output=jsonpath='{.items[*].metadata.name}')\r\necho \"Dev Pod Name: $DEV_POD\"<\/pre>\n
    Without rolling out the deployment definition, it will remain just a definition. The next step is to do a rollout and present our pod name so that we can push our code into it.<\/p>\n
    Running Code in the Container<\/h4>\n
    At this stage, we successfully ran the create-dev.sh script. We now have the task of getting our code into the container to test it. A few commands here will help us get code into the container and then open a shell.<\/p>\n
    kubectl cp \/Users\/samredman\/dev\/node-couchbaseproject $DEV_POD_NAME_OUTPUTTED:\/usr\/app<\/pre>\n
    This is just an example, but the concepts should remain the same. Here, we take our directory of Couchbase SDK code and copy it into the newly created development pod (remember to get the echo’d output of “Dev Pod Name: X”).<\/p>\n
    kubectl exec --stdin --tty couchbase-sdk-dev-6bfbf76b7-zxln2 -- \/bin\/bash<\/pre>\n
    This command will take us to the shell within the container. You should see the path change in the prompt. From here, you can run the code you copied across in the “kubectl cp” command.<\/p>\n
    Tasty Sample Code<\/h4>\n
    We have provided a small sample script that follows the same patterns as our SDK docs. The SDK docs do a fantastic job of explaining the Couchbase-isms of the building blocks of a Couchbase application.<\/p>\n
    Please note this documentation that helps determine the correct endpoint you should connect to. The key here is the cluster name defined in the cluster deployment and appending it with -srv. To quote the docs: “The service name is in the form <cluster-name>-srv.”<\/p>\n
    The few configurations available at the top of the script should remain the same for a default deployment in Helm. Check that the connection credentials used in the script match that of the output from the command: helm get all couchbase<\/p>\n
    In any case, you should check that the configuration options meet your expectations. Remember that the code doesn’t lie \u2013 if it can’t connect, it probably has not been told how to connect correctly. However, if you make changes that divert from the defaults, remember to change your cluster name, bucket, and authentication credentials.<\/p>\n
    Conclusion<\/h4>\n
    You should be coming away from this blog with a fully configured development environment, which will allow you to test your Couchbase SDK code against a real-life Couchbase cluster, no mocks! I hope the automation helps you have more time to write code instead of managing development environments as I had to during my time as a developer.<\/p>\n
    Here are the direct links to the resources used in this post:<\/span><\/p>\n