En mi blog anterior, discutimos la creación de un clúster de Couchbase localmente en tu propio hardware. Lo bueno de esto es que reduce significativamente tanto el coste total de propiedad de tu infraestructura de pruebas como el tiempo necesario para adquirir una nueva infraestructura de pruebas, lo cual es especialmente importante si acabas de empezar tu andadura con Couchbase.
Para llevar a todos al mismo punto de partida, aquí hay un enlace a mi blog anteriordonde explicamos cómo crear rápidamente un clúster de desarrollo local utilizando Couchbase Autonomous Operator para Kubernetes.
Entonces, ¿a dónde podríamos ir desde aquí? Establecer un entorno de fácil despliegue que imite el despliegue de su aplicación es el único camino natural. Este será otro paso importante en la dirección correcta para permitirle desarrollar y probar sus despliegues localmente, con el mínimo esfuerzo.
Una implantación aún más sencilla
Hemos simplificado el método de despliegue comentado en mi blog anteriorPor supuesto, sigue siendo importante entender los componentes del operador Couchbase que vamos a desplegar, así que si aún no lo has hecho, consulta mi blog anterior.
El nuevo método de despliegue está contenido en el operador-gitops repo mantenido por Couchbase (y, más concretamente, por el fantástico Patrick Stephens). Lo único que tienes que hacer ahora para tener un cluster de Couchbase desplegado localmente es ejecutar el comando crear-cluster.sh script. Una vez completado esto, puede ejecutar su crear-dev.sh script. Así de fácil, tendrás todo lo que necesitas (en cuanto a infraestructura) para probar las características de tu Aplicación Couchbase.
Desarrollo Desglose
Para que ésta sea una guía técnica práctica para usted, las siguientes secciones cubren todos los detalles de lo que estamos haciendo en el crear-dev.sh guión.
Dockerfile
Cuando era desarrollador, tenía que mantener mis propios entornos de desarrollo y pruebas. Mantener estos entornos era una pesadilla, ya que no había mucha automatización. Las nuevas versiones naturalmente introducían cambios en el código. Afortunadamente, todo esto ha cambiado, y mostramos un ejemplo típico de automatización en el SDK de Node.js en este artículo Dockerfile del operador-gitops repo. Esta entrada del blog presenta esto para que pueda replicar uno en su entorno.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
FROM node:16.9.1 # Update the image to the latest packages & get some network test tools # Install VIM - change this to an editor of your choice - sorry I was raised by savages RUN apt-get update && \ apt-get -y install git iputils-ping iproute2 vim && \ mkdir -p /user/app # Need to specify an existing directory so that all our other commands have a consistent working directory to run in WORKDIR /usr/app # Steps taken from install SDK guide # Follow the steps to get started with our SDK: # https://docs.couchbase.com/nodejs-sdk/current/hello-world/start-using-sdk.html RUN npm init -y && npm install couchbase --save # Hack to just sleep so we can attach CMD ["sleep","3600"] |
Iremos línea por línea:
- DESDE nodo:16.9.1 - esta es la imagen base proporcionada por Node.js para que no tengamos que preocuparnos de instalarla (entre otras cosas).
- EJECUTAR apt-get ... - esta es una serie de comandos para instalar herramientas para probar la conectividad entre tu entorno de desarrollo y los despliegues de Couchbase.
- WORKDIR /usr/app - aquí, estamos estableciendo un directorio que siempre será utilizado por los comandos que siguen en el dockerfile. También se establece una ruta de entrada para que aterrice allí cuando shell en el contenedor.
- EJECUTAR npm init -y && npm install couchbase -save - esto instalará el SDK de Couchbase según las instrucciones de nuestra documentación.
- CMD ["dormir", "3600″] - este es un hack para mantener el contenedor vivo para que podamos adjuntar.
Estos conceptos compartidos también se aplican a otros SDKs de Couchbase. Encuentra una imagen predeterminada relevante, instala las herramientas, establece un directorio de trabajo, instala el SDK de Couchbase, establece algo en su lugar para que podamos adjuntar y probar el código.
|
1 2 |
docker build -t "${DEV_IMAGE}" . kind load docker-image "${DEV_IMAGE}" --name="${CLUSTER_NAME}" |
Lo primero que ocurrirá en nuestro despliegue automático del entorno de desarrollo será construir la imagen Docker especificada en el dockerfile y precargar la imagen en KIND (Kubernetes en Docker).
Desarrollo Implantación 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 |
# Create a deployment for our dev container image. cat << EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: couchbase-sdk-dev namespace: $NAMESPACE spec: selector: matchLabels: couchSdk: "dev" template: metadata: labels: couchSdk: "dev" environment: "dev" spec: containers: - name: dev-container image: $DEV_IMAGE imagePullPolicy: Never env: - name: CB_HOST value: $CB_SERVICE # https://kubernetes.io/docs/concepts/configuration/secret/#environment-variables-are-not-updated-after-a-secret-update - name: CB_USER valueFrom: secretKeyRef: name: $AUTHENTICATION_SECRET key: username - name: CB_PSWD valueFrom: secretKeyRef: name: $AUTHENTICATION_SECRET key: password EOF # Note that if you do not change anything then it will stay deployed from a previous run. |
Nuestra imagen de contenedor recién creada puede ahora ser utilizada en un despliegue Kubernetes donde el contenedor es desplegado y escalado por el sistema. Si el pod desplegado de nuestro contenedor falla, el controlador de despliegue de Kubernetes se dará cuenta y activará una nueva instancia.
Hemos proporcionado una definición de despliegue bonita y sencilla dentro del script create-dev.sh que utilizará nuestra imagen Docker y adjuntará algunas etiquetas sencillas para gestionar el despliegue con kubectl.
Despliegue
|
1 2 3 4 5 6 7 8 9 10 |
echo "Waiting for Dev Deployment to start up..." until kubectl rollout status deployment/couchbase-sdk-dev; do echo -n '.' sleep 2 done echo "Dev Deployment configured and ready to go" # Output the name of the development pod DEV_POD=$(kubectl get pods -l couchSdk=dev --output=jsonpath='{.items[*].metadata.name}') echo "Dev Pod Name: $DEV_POD" |
Si la definición de despliegue no se despliega, seguirá siendo sólo una definición. El siguiente paso es hacer un rollout y presentar nuestro nombre de pod para que podamos empujar nuestro código en él.
Ejecutar código en el contenedor
En este punto, hemos ejecutado con éxito el script create-dev.sh. Ahora tenemos la tarea de introducir nuestro código en el contenedor para probarlo. Algunos comandos aquí nos ayudarán a introducir el código en el contenedor y luego abrir una shell.
|
1 |
kubectl cp /Users/samredman/dev/node-couchbaseproject $DEV_POD_NAME_OUTPUTTED:/usr/app |
Esto es sólo un ejemplo, pero los conceptos deben seguir siendo los mismos. Aquí, tomamos nuestro directorio de código Couchbase SDK y lo copiamos en el pod de desarrollo recién creado (recuerde obtener la salida de eco de "Dev Pod Name: X").
|
1 |
kubectl exec --stdin --tty couchbase-sdk-dev-6bfbf76b7-zxln2 -- /bin/bash |
Este comando nos llevará al shell dentro del contenedor. Usted debe ver el cambio de ruta en el símbolo del sistema. Desde aquí, puedes ejecutar el código que copiaste en el comando "kubectl cp".
Sabroso código de muestra
Hemos proporcionado un pequeño script de ejemplo que sigue los mismos patrones que nuestros documentos SDK. El SDK docs hace un trabajo fantástico explicando los Couchbase-ismos de los bloques de construcción de una aplicación Couchbase.
Tenga en cuenta esta documentación que ayuda a determinar el punto final correcto al que debe conectarse. La clave aquí es el nombre del clúster definido en el despliegue del clúster y añadirle -srv. Citando la documentación "El nombre del servicio tiene la forma -srv".
Las pocas configuraciones disponibles en la parte superior del script deberían seguir siendo las mismas para un despliegue por defecto en Helm. Compruebe que las credenciales de conexión utilizadas en el script coinciden con la salida del comando: helm get all couchbase
En cualquier caso, debes comprobar que las opciones de configuración cumplen tus expectativas. Recuerda que el código no miente - si no puede conectarse, probablemente no se le ha dicho cómo conectarse correctamente. No obstante, si realiza cambios que se desvían de los valores predeterminados, recuerde cambiar el nombre del clúster, el bucket y las credenciales de autenticación.
Conclusión
Deberías salir de este blog con un entorno de desarrollo completamente configurado, que te permitirá probar tu código del SDK de Couchbase contra un cluster de Couchbase de la vida real, ¡sin mocks! Espero que la automatización te ayude a tener más tiempo para escribir código en lugar de gestionar entornos de desarrollo como tuve que hacer yo durante mi época de desarrollador.
Aquí están los enlaces directos a los recursos utilizados en este post:
- Blog: Cómo construir una prueba de concepto de operador autónomo Couchbase
- Herramientas: Despliegue de Couchbase Operator con Helm y KIND
- Repo operador-gitops de Couchbase
- crear-cluster.sh y crear-dev.sh guiones
- Dockerfile para Couchbase Node.js SDK
- Ejemplo de script Couchbase Node.js SDK
- Docs: Instalar el SDK de Couchbase
Docs: Encontrar el punto final del clúster para Kubernetes DNS
