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 |
DESDE nodo:16.9.1 # Actualizar la imagen a los últimos paquetes y obtener algunas herramientas de prueba de red # Instalar VIM - cambiar esto a un editor de su elección - lo siento fui criado por salvajes RUN apt-consiga actualización && \ apt-consiga -y instale git iputils-ping ruta2 vim && \ mkdir -p /usuario/aplicación # Es necesario especificar un directorio existente para que todos los demás comandos tengan un directorio de trabajo coherente en el que ejecutarse. WORKDIR /usr/aplicación # Pasos tomados de la guía de instalación del SDK # Siga los pasos para empezar a utilizar nuestro SDK: # https://docs.couchbase.com/nodejs-sdk/current/hello-world/start-using-sdk.html RUN npm init -y && npm instale couchbase --guardar # Hack sólo dormir para que podamos adjuntar CMD ["dormir","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 construya -t "${DEV_IMAGE}" . amable carga docker-imagen "${DEV_IMAGE}" --nombre="${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 |
# Crear un despliegue para nuestra imagen de contenedor dev. cat << EOF | kubectl aplicar -f - apiVersion: aplicaciones/v1 amable: Despliegue metadatos: nombre: couchbase-sdk-dev espacio de nombres: $NAMESPACE spec: selector: matchLabels: couchSdk: "dev" plantilla: metadatos: etiquetas: couchSdk: "dev" medio ambiente: "dev" spec: contenedores: - nombre: dev-contenedor imagen: $DEV_IMAGE imagePullPolicy: Nunca env: - nombre: CB_HOST valor: $CB_SERVICIO # https://kubernetes.io/docs/concepts/configuration/secret/#environment-variables-are-not-updated-after-a-secret-update - nombre: CB_USUARIO valorDesde: secretKeyRef: nombre: $SECRETO_DE_AUTENTICACIÓN clave: nombre de usuario - nombre: CB_PSWD valorDesde: secretKeyRef: nombre: $SECRETO_DE_AUTENTICACIÓN clave: contraseña EOF # Tenga en cuenta que si no cambia nada, se mantendrá desplegado desde una ejecución anterior. |
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 "Esperando a que se inicie el Despliegue de Dispositivos..." hasta kubectl despliegue estado despliegue/couchbase-sdk-dev; do echo -n '.' dormir 2 hecho echo "Despliegue de dispositivos configurado y listo para funcionar" # Salida del nombre del pod de desarrollo DEV_POD=$(kubectl consiga vainas -l couchSdk=dev --salida=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 /Usuarios/samredman/dev/nodo-proyecto couchbase $DEV_POD_NAME_OUTPUTTED:/usr/aplicación |
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 -- /papelera/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
