Ponte al límite con Sync Gateway

Introducción

Imagina que vas a reunirte con un cliente importante en el centro de San Francisco, California, y recibes un correo electrónico con los detalles de a quién tienes que llamar cuando llegues al vestíbulo de la oficina. Usted está en el vestíbulo, pero la recepción de la red móvil está completamente caída. Intentas abrir tu cliente de correo electrónico pero necesita conexión a la red cada vez que inicias la aplicación. Estoy seguro de que la imposibilidad de leer el correo electrónico sin conectividad dará lugar a una experiencia de usuario frustrante.

Para evitar estas situaciones, las aplicaciones se construyen ahora con la función primero offline paradigma. Esto significa simplemente que la funcionalidad de la aplicación no se ve afectada por la falta intermitente de conectividad a la red. Además, primero offline suele implicar la capacidad de sincronizar datos entre los dispositivos periféricos y la base de datos backend.

Muchas soluciones de bases de datos relacionales o incluso no relacionales tratan el móvil y el backend como dos problemas separados, por lo que construir aplicaciones offline-first con estas soluciones puntuales es casi imposible.

 

• 

 

Couchbase, por su parte, es el proveedor líder de una solución totalmente integrada de borde a la nube. Couchbase Lite product es la base de datos integrada para los dispositivos edge (donde se pueden ejecutar consultas declarativas localmente en el dispositivo), Pasarela de sincronización es la tecnología de gel que permite la sincronización de datos desde los dispositivos periféricos al Clúster Couchbase.

En este artículo, nos centraremos en el despliegue de Couchabse Cluster y Sync Gateway en la plataforma Kubernetes. El objetivo es que adquieras experiencia de primera mano trabajando con estas tecnologías y que entiendas la mecánica que hay detrás de cada una de ellas.

Otra cosa que me gustaría que se llevara de este artículo son algunas de las mejores prácticas a la hora de implementar esta solución en su propia nube privada o pública.

Buenas prácticas

Como escucho estas preguntas de muchos de mis clientes empresariales, decidí abordarlas primero hablando de algunas de las mejores prácticas cuando se trata de desplegar Couchbase en la plataforma Kubernetes.

1. Realice siempre análisis del tamaño del clúster Couchbase primero, para planificar qué instancia EC2, tipos de dispositivos de almacenamiento y espacio se necesitarían para el clúster. Las estimaciones de tamaño siguen siendo las mismas para el clúster Kubernetes que para el clúster local.
   Sin embargo, recuerda que en K8s estamos haciendo el dimensionamiento para los nodos de Kubernetes, donde se van a ejecutar los pods de Couchbase. Aquí es donde la segunda mejor práctica entra en escena.
2. Utilice spec.antiAffinity=true en couchbase-cluster.yaml durante el despliegue del clúster en producción. Este campo especifica si dos pods en este cluster pueden ser desplegados en el mismo nodo Kubernetes. Desde el punto de vista de la alta disponibilidad, no queremos colocar más de un pod en cada uno de los nodos K8s, de modo que el fallo de un único nodo solo provoque la caída de un único pod.
3. En el entorno Kubernetes, es aconsejable gestionar la colocación de pods en tipos de nodos predefinidos (large, xlarge, 4xlarge, etc.), de modo que se puedan garantizar los recursos deseados en el momento de la implementación del clúster o de la recuperación automática. Puede utilizar spec.servers[].pod.spec.nodeSelector (como se menciona en couchbase-cluster.yaml), que especifica un mapa clave-valor de las restricciones en la colocación de nodos para pods. Para que un pod pueda ejecutarse en un nodo, el nodo debe tener cada uno de los pares clave-valor indicados como etiquetas.
4. Una última antes de empezar la diversión: si tu cluster K8s tiene nodos homogéneos y no quieres usar selector de nodos para determinar la ubicación del pod y, a continuación, utilice spec.servidores[].recursos para definir solicita y límites. De nuevo, esto ayudará a colocar pods con un conjunto predefinido de recursos.

NOTA: En el siguiente ejemplo utilizaremos nodeSelector para colocar los respectivos tipos de cápsula en el nodegroups para garantizar los recursos deseados.

Requisitos previos

Asegúrate de que tienes una cuenta de AWS configurada (instrucciones fuera del alcance de este blog) y todas las herramientas que necesitarías para probar con éxito estas instrucciones están listas. Aquí está la lista de cosas que usted necesitaría:

1. Descargar la última Operador autónomo de Couchbase y descomprímalo en el equipo local. El paquete Operator contiene herramientas de línea de comandos que utilizará para instalar Operator.
2. Instalación y configuración kubectl kubectl es una interfaz de línea de comandos para ejecutar comandos en clústeres Kubernetes.
3. Instale la última CLI DE AWS - La CLI de AWS es una herramienta unificada que le permite interactuar con los servicios de AWS mediante comandos en su shell de línea de comandos. En este caso, utilizaremos la CLI de AWS para comunicarnos de forma segura con el clúster de Kubernetes que se ejecuta en AWS.

Una vez que haya aws cli con las credenciales de su cuenta, puede pasar a la sección de creación de un clúster Kubernetes.

Paso 1: Crear clúster K8s multinodal

Kubernetes (K8s) nos proporciona la flexibilidad para aprovisionar máquinas de computación de diferentes tamaños (vCPU, RAM, tamaño de disco) en un único clúster Kubernetes, de modo que los requisitos de recursos de varios servicios gestionados puedan satisfacerse desde un único clúster K8s.

Vamos a aprovechar la misma flexibilidad y disposición tres NodeGroupsque luego utilizaremos para alojar un conjunto específico de servicios Couchbase.

1.1. Cree un clúster EKS en la región de su elección

En primer lugar, despleguemos un clúster K8s en us-oeste-2 región y en dos zonas de disponibilidad us-oeste-2a/b. Puede mencionar un vpc-cidr según sus necesidades, pero en este ejemplo utilizaremos 172.16.0.0/20lo que nos proporciona un alcance de más de 4K (2¹²), lo que debería ser más que suficiente para nosotros.

$ eksctl crear clúster --nombre k8sEKS \ --versión 1.18 \ --región us-west-2 \ --zonas us-west-2a,us-west-2b \ --vpc-cidr 172.16.0.0/20 \ --sin grupo de nodos

1.2. Crear grupos de nodos separados

Creemos nodegroup dentro del clúster EKS para que podamos alojar Couchbase Datos instancias de servicio. En este ejemplo, utilizaremos m5.large (2 vCPU y 8 GB RAM) máquinas EC2 como tipo de nodopero el tamaño real del nodo EC2 dependerá de la planificación de la capacidad y el rendimiento en función de su carga de trabajo. Así que asegúrese de elegir el tipo correcto de nodos en su despliegue de producción.

$ eksctl crear nodegroup --cluster=k8sEKS \ --name=m5l-pool \ --node-type m5.large \ --region us-west-2 \
 --nodos 2 \ --nodos-mín 2 \ --nodos-máx 4 \ --nodo-ami automático

Para acoger Índice/Consulta crearemos un nodegroup separado con más computación y RAM. En este ejemplo usaremos r5.large (2 vCPU y 16 GB RAM) máquinas.

$ eksctl crear grupo de nodos --cluster=k8sEKS \ --nombre=r5l-pool \ --tipo de nodo r5.large \ --región us-west-2 \
 --nodos 2 \ --nodos-mín 2 \ --nodos-máx 4 \ --nodo-ami auto

Por último, utilizaremos t2.xlarge (4 vCP y 16 GB RAM) para acoger Sync-Gateway instancia.

$ eksctl create nodegroup --cluster=k8sEKS \ --name=t2xl-pool \ --node-type t2.xlarge \ --region us-west-2 \
 --nodos 1 \ --nodos-mínimo 1 \ --nodos-máximo 2 \ --nodo-ami automático

Una vez que los tres nodegroups podemos empezar a etiquetar cada nodo del nodegroup o utilizar una etiqueta preexistente, pero primero debemos confirmar que todos los nodos están etiquetados. nodegroups están listos:

$ eksctl obtener nodegroups --cluster=k8sEKS --region=us-west-2 LUSTER NODEGROUP CREADO TAMAÑO MÍNIMO TAMAÑO MÁXIMO CAPACIDAD DESEADA TIPO DE INSTANCIA ID DE IMAGEN
k8sEKS m5l-pool 2020-07-24T18:58:02Z 2 4 2 m5.largeami-04387c277e83865b2
k8sEKS r5l-pool 2020-07-24T18:58:09Z 2 4 2 r5.largeami-04387c277e83865b2
k8sEKS t2xl-pool 2020-07-24T19:09:09Z 1 2 1 t2.xlargeami-04387c277e83865b2

1.3. Etiquetar los nodos EKS

Hemos elegido tres tipos diferentes de máquinas EC2 para alojar datos, Índice/Consultay sync-gateway máquinas sólo para dedicar servicios Couchbase a un nodegroup tipo. Vamos a utilizar una etiqueta existente llamada beta.kubernetes.io/instance-type para la selección de nodos. Esta etiqueta va a estar disponible por defecto para que no tengamos que crear una nueva etiqueta. Simplemente puede ver las etiquetas de los nodos ejecutando este cmd:

$ kubectl obtener nodos --mostrar etiquetas NOMBRE ESTADO FUNCIONES ANTIGÜEDAD VERSIÓN ETIQUETAS
ip-172-16-0-12.us-west-2.compute.internal Listo  21 m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=t2.xlarge,...
ip-172-16-0-127.us-west-2.compute.internal Listo  32 m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=m5.large,...
ip-172-16-3-234.us-west-2.compute.internal Listo  32 m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=m5.large,...
ip-172-16-1-29.us-west-2.compute.internal Listo  32 m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=r5.large,...
ip-172-16-3-119.us-west-2.compute.internal Listo  32 m v1.14.9-eks-a0a484 ...,beta.kubernetes.io/instance-type=r5.large,...

En este ejemplo alojaremos datos servicio en m5.grande máquinas, índice/consulta en r5.grande máquinas y sync-gateway en t2.xlarge máquina.

En un entorno de producción real, entendemos que puedes tener diferentes tipos de máquinas pero no esencialmente un tipo dedicado a un tipo específico de servicio Couchbase. En ese caso, puedes crear etiquetas mutuamente excluyentes para cada tipo de nodo.

Utilizarías etiqueta kubectl cmd para etiquetar todos los nodos que desea utilizar sólo para los nodos de datos de esta manera:

$ kubectl etiqueta nodos 'ec2-node-ip' instanceType=data

De la misma manera para etiquetar todos los nodos de índice (consulta u otro):

$ kubectl etiquetar nodos 'ec2-node-ip' instanceType=index

Una vez que hayas etiquetado todos los nodos, estarás listo para pasar a la siguiente sección.

NOTA: Estamos utilizando beta.kubernetes.io/instance-type como etiqueta, por lo que no tenemos que crear ninguna etiqueta nueva para los nodos.

Paso 2: Instalar la definición personalizada de recursos

El primer paso en la instalación del Operador es instalar la definición de recurso personalizada (CRD) que describe el Couchbase tipos de recursos. Para ello, ejecute el siguiente comando desde el directorio del paquete Operator:

kubectl create -f crd.yaml

Paso 3: Crear un espacio de nombres

Los espacios de nombres son una forma de dividir los recursos del clúster entre varios usuarios.

Los espacios de nombres son una forma de dividir los recursos del clúster entre varios usuarios.

• Ejecute el siguiente comando para crear un espacio de nombres.

  $ kubectl crear espacio de nombres cbdb espacio de nombres/cbdb creado

• Confirme que el espacio de nombres se ha creado correctamente.

  $ kubectl obtener espacios de nombres NOMBRE ESTADO ANTIGÜEDAD cbdb Activo 34 s predeterminado Activo 5 h 20 m

Paso 4: Instalar el automatismo

El operador consta de dos componentes: un controlador de admisión dinámico por clúster (DAC) y un por espacio de nombres Operador. Consulte el arquitectura del operador para obtener información adicional sobre los requisitos y las consideraciones de seguridad.

4.1. Instalar el Controlador Dinámico de Admisión (DAC)

El DAC permite que los recursos personalizados sean modificados e interrogados antes de que un recurso sea aceptado y enviado a etcd. Ejecutar el DAC nos permite añadir valores por defecto sensibles a las configuraciones del cluster Couchbase minimizando así el tamaño de las especificaciones. También nos permite mantener la compatibilidad con versiones anteriores cuando se añaden nuevos atributos y deben ser rellenados. Esto hace que la experiencia de uso de los recursos Couchbase sea similar a la de los tipos de recursos nativos.

Instalemos ahora el Controlador Dinámico de Admisión.

• Abra una ventana de Terminal y vaya al directorio donde desempaquetó el paquete Operator. Ejecute el siguiente comando para instalar el DAC en el directorio por defecto espacio de nombres.

$ bin/cbopcfg generar admisión --namespace default | kubectl crear -f -


serviceaccount/couchbase-operator-admission creado clusterrole.rbac.authorization.k8s.io/couchbase-operator-admission creado clusterrolebinding.rbac.authorization.k8s.io/couchbase-operator-admission creado secret/couchbase-operator-admission creado
deployment.apps/couchbase-operator-admission creado service/couchbase-operator-admission creado mutatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission creado validatingwebhookconfiguration.admissionregistration.k8s.io/couchbase-operator-admission creado

• Confirme que el controlador de admisión se ha desplegado correctamente.

$ kubectl obtener implementaciones NOMBRE LISTO ACTUALIZADO DISPONIBLE ANTIGÜEDAD couchbase-operator-admission 1/1 1 1 48 s

4.2. Instalar el Operador Couchbase

Ahora vamos a desplegar el Operador en el taller ejecutando el siguiente comando.

$ bin/cbopcfg generar operador --namespace cbdb | kubectl crear -f -

serviceaccount/couchbase-operator creado role.rbac.authorization.k8s.io/couchbase-operator creado rolebinding.rbac.authorization.k8s.io/couchbase-operator creado deployment.apps/couchbase-operator creado service/couchbase-operator creado

Al ejecutar el comando anterior se descarga la imagen Docker Operator y se crea un archivo despliegueque gestiona una única instancia de Operator. El Operador utiliza un despliegue para poder reiniciar el pod si muere.

Después de ejecutar el kubectl create por lo general, Kubernetes tarda menos de un minuto en desplegar el operador y dejarlo listo para ejecutarse.

4.3. Comprobar el estado de la implantación

Puede utilizar el siguiente comando para comprobar el estado de la implantación:

$ kubectl obtener implementaciones -n cbdb NOMBRE LISTO ACTUALIZADO DISPONIBLE ANTIGÜEDAD couchbase-operator 1/1 1 1 73 s

4.4. Comprobar el estado del Operador

Ejecute el siguiente comando para verificar que el Operador se ha iniciado correctamente:

$ kubectl get pods -l app=couchbase-operator -n cbdb NOMBRE ESTADO LISTO RESTART EDAD couchbase-operator-558fd8486c-788jr 1/1 En ejecución 0 2m9s

Si el Operador está en funcionamiento, el comando devuelve una salida en la que el LISTO exposiciones sobre el terreno 1/1como:

Paso 5. Despliegue del clúster Couchbase

En un entorno de producción donde el rendimiento y el SLA del sistema es lo más importante, siempre debemos planificar el despliegue del clúster Couchbase utilizando volúmenes persistentes, ya que ayuda en:

• Recuperación de datos: Los Volúmenes Persistentes permiten recuperar los datos asociados a los Pods en el caso de que un Pod sea dado de baja. Esto ayuda a prevenir la pérdida de datos y evitar la lenta creación de índices cuando se utilizan servicios de datos o índices.
• Reubicación de la cápsula: Kubernetes puede decidir desalojar pods que alcancen umbrales de recursos como límites de CPU y memoria. Los pods respaldados con volúmenes persistentes pueden cerrarse y reiniciarse en nodos diferentes sin que se produzca ningún tiempo de inactividad o pérdida de datos.
• Aprovisionamiento dinámico: El Operador creará Volúmenes Persistentes bajo demanda a medida que su clúster escale, aliviando la necesidad de pre-aprovisionar el almacenamiento de su clúster antes del despliegue.
• Integración en la nube: Kubernetes se integra con los aprovisionadores de almacenamiento nativos disponibles en los principales proveedores de nube, como AWS y GCE.

5.1. Crear secreto para Couchbase Admin Console

Lo primero que tenemos que hacer es crear una credencial secreta que será utilizada por la consola web administrativa durante el inicio de sesión. Para mayor comodidad, se proporciona un secreto de muestra en el paquete Operator. Cuando lo empuja a su clúster Kubernetes, el secreto establece el nombre de usuario al Administrador y la contraseña a la contraseña.

Para empujar el secret.yaml en su clúster Kubernetes, ejecute el siguiente comando:

$ kubectl create -f secret.yaml -n cbdb Secret/cb-admin-auth creado

5.2 Crear clase de almacenamiento para el cluster k8s

Para utilizar PersistentVolume para servicios Couchbase (datos, índice, búsqueda, etc.), necesitamos crear Clases de Almacenamiento (sc-nas.yaml). Ejecute kubectl para crear una nueva clase de almacenamiento basada en SSD:

$ kubectl create -f sc-nas.yaml -n cbdb storageclass.storage.k8s.io/nas creado

5.3. Despliegue del cluster Couchbase

La especificación completa para desplegar el clúster Couchbase en 3 zonas diferentes utilizando volúmenes persistentes puede verse en el documento couchbase-cluster.yaml . Este archivo, junto con otros archivos YAML de ejemplo utilizados en este artículo, puede descargarse de este repositorio git.

Abra el archivo YAML que acaba de descargar y observe cómo estamos utilizando nodeSelector para colocar los pods en los nodos que tienen el valor específico de beta.kubernetes.io/instance-type etiqueta.

servidores: - nombre: servicio-de-datos-2a tamaño: 1 servicios: - volumen de datos: por defecto: pvc-default # /opt/couchbase/var/lib/couchbase datos: pvc-data # /mnt/data
    pod: especificaciones: selector de nodo: beta.kubernetes.io/tipo de instancia: m5.large - nombre: index-quer-service-2a tamaño: 1 servicios: - índice - consulta
    volumeMounts: predeterminado: pvc-predeterminado índice: pvc-índice pod: especificación: nodeSelector: beta.kubernetes.io/instance-type: r5.large

Ahora usa kubectl para desplegar el clúster, pero asegúrese de que está utilizando couchbase-cluster.yaml del git, no el archivo con el mismo nombre presente en el directorio de trabajo actual.

$ kubectl create -f couchbase-cluster.yaml -n cbdb --save-config couchbasecluster.couchbase.com/cbdemo creado

Esto iniciará el despliegue del cluster Couchbase y si todo va bien tendremos cuatro pods del cluster Couchbase alojando los servicios según el fichero de configuración anterior. Para comprobar el progreso ejecute este comando, que observará (argumento -w) el progreso de la creación de pods:

$ kubectl obtener pods -n cbdb -w NOMBRE LISTO ESTADO REINICIOS ANTIGÜEDAD cbdemo-0000 0/1 En ejecución 0 1m cbdemo-0001 0/1 En ejecución 0 53s
cbdemo-0002 0/1 En ejecución 0 20 s couchbase-operator-558fd8486c-788jr 1/1 En ejecución 0 21 m cbdemo-0003 0/1 En espera 0 3 s
cbdemo-0003 0/1 Pendiente 0 3 s cbdemo-0003 0/1 Creando contenedor 0 3 s cbdemo-0003 0/1 En ejecución 0 18 s
cbdemo-0001 1/1 En ejecución 0 2 m cbdemo-0000 1/1 En ejecución 0 2 m cbdemo-0002 1/1 En ejecución 0 1 m cbdemo-0003 1/1 En ejecución 0 1 m

Para ver qué pod se está ejecutando en qué nodo puede ejecutar:

$ kubectl obtener pods -owide -n cbdb NOMBRE ESTADO LISTO REINICIOS ANTIGÜEDAD IP NODO NODO NOMINADO PUERTAS DE PREPARACIÓN
cbdemo-0000 1/1 En ejecución 0 10 m 172.16.2.134 ip-172-16-3-234.us-west-2.compute.internal  
cbdemo-0001 1/1 En ejecución 0 10 m 172.16.1.116 ip-172-16-0-127.us-west-2.compute.internal  
cbdemo-0002 1/1 En ejecución 0 9 m 51 s 172.16.1.5 ip-172-16-1-29.us-west-2.compute.internal  
cbdemo-0003 1/1 En ejecución 0 9m3s 172.16.2.98 ip-172-16-3-119.us-west-2.compute.internal  
couchbase-operator-558fd8486c-r2tcc 1/1 En ejecución 0 31 m 172.16.1.230 ip-172-16-0-12.us-west-2.compute.internal

Notará que Índice/Consulta el servicio se está ejecutando en el pod cbdemo-0002 y cbdemo-0003 que se aloja en los nodos EKS con etiqueta beta.kubernetes.io/instance-type: r5.large y datos módulos de servicio (cbdemo-0000, cbdemo-0001) se colocan en nodos EKS con etiqueta beta.kubernetes.io/instance-type: m5.large. Es decir nodeSelector definido en couchbase-cluster.yaml ha aplicado con éxito la colocación de pods en los nodos con los recursos deseados.

En este punto puedes hacer el reenvío de puertos así:

$ kubectl port-forward cbdemo-0000 18091:18091 -n cbdb Reenvío desde 127.0.0.1:18091 -> 18091 Reenvío desde [::1]:18091 -> 18091

Y accede a la consola web escribiendo https://localhost:18091 en el navegador.

Paso 6. Despliegue de un clúster de Sync Gateway Despliegue de un clúster de Sync Gateway

Gran progreso hasta ahora desplegando cluster Couchbase multizona y de alta disponibilidad usando volúmenes de almacenamiento persistente. Ahora, antes de empezar a desplegar Sync Gateway, tenemos que asegurarnos de dos cosas más:

6.1 Requisitos previos de Sync Gateway

• Tenemos un bucket disponible donde tanto la aplicación cliente como Sync Gateway van a escribir los datos. Todavía no tenemos ningún bucket disponible para escribir, así que vamos a crear un bucket puesta en escena cubo del Consola web.

• 

Figura 2: Puesta en escena creado con 2 GB de espacio.

NOTA: Nosotros usamos 2GB de RAM para este bucket pero en el entorno de producción deberías asignar la RAM basándote en las estimaciones de tamaño que tú o el Arquitecto de Soluciones de Couchbase hayáis hecho para el caso de uso de tu negocio.

• Disponemos de un usuario RBAC con la etiqueta Acceso a la aplicación a nivel de cubo.

Podemos crear simplemente un Couchbase User como hacemos generalmente, pero para hacer esto un poco más interesante vamos a utilizar un externo (también conocido como LDAP). En el couchbase-cluster.yaml puede encontrar los datos de un tercero Servidor de prueba LDAP que hemos utilizado en este ejemplo.

seguridad: adminSecret: cb-admin-auth rbac: administrado: falso ldap: hosts: - ldap.forumsys.com puerto: 389
    bindDN: "cn=read-only-admin,dc=example,dc=com" bindSecret: cb-admin-auth authenticationEnabled: true userDNMapping: template: "uid=%u,dc=example,dc=com" authorizationEnabled: false

Si desea conectarse a un servidor LDAP diferente, sólo tiene que actualizar ldap detalles del servidor en el couchbase-cluster.yaml y aplicar los cambios. De vuelta a la creación de un usuario y la asignación del nivel de cubo Acceso a la aplicación papel.

• 

Figura 3: Utilización de newton como usuario externo que se confirmará automáticamente como existe.

• 

Figura 4: Datos del usuario tras pulsar el botón Añadir usuario botón.

Hasta aquí todo bien. Bucket y usuario RBAC está listo para que podamos seguir adelante con la configuración de la Pasarela de sincronización.

6.2 Configuración de la pasarela de sincronización

Para Pasarela de sincronización para comunicarnos con Couchbase Cluster, necesitamos proporcionar los detalles de la base de datos, el bucket y las credenciales. Utilizaremos base de datos cadena de conexión como couchbase://cbdemo-srv.cbdb.svc.cluster.local como puede verse en el siguiente fragmento:

... }, "bases de datos": { "cbdemo": { "servidor": "couchbase://cbdemo-srv.cbdb.svc.cluster.local", "depósito": "staging",
          "nombre de usuario": "newton", "contraseña": "contraseña", "permitir_conflictos": falso, "límite_de_revisiones": 20,
          "habilitar_acceso_compartido_al_depósito": verdadero, "importar_documentos": verdadero, "sincronizar": función(doc, doc_antiguo) { canal(doc.canales); },
        }
    ...

Una cosa que destacaría que con Sync Gateway 2.7 (o superior) los clientes empresariales pueden ahora designar múltiples nodos Sync Gateway como nodos de Importación (para manejar las escrituras de Couchbase Server), lo que proporciona una mayor resistencia. Por lo tanto, estamos utilizando importar_docs: true en el archivo de configuración.

Puede encontrar todos los demás atributos de configuración en sgw-config.yaml archivo. Utilizaremos este archivo para crear el secreto y guardar allí también las configuraciones.

$ kubectl create -f sgw-config.yaml -n cbdb --save-config secret/sync-gateway creado

Para ver sgw-config secreto ejecutar a continuación cmd:

$ kubectl obtener secreto -n cbdb NOMBRE TIPO DATOS ANTIGÜEDAD cb-admin-auth Opaco 2 4h
couchbase-operator-token-p4qzb kubernetes.io/service-account-token 3 4h token predeterminado-x7cvw kubernetes.io/service-account-token 3 4h sgw-config Opaco 1 30s

6.3 Controlador de despliegue

Después de establecer el secreto y la configuración, estamos casi listos para desplegar Pasarela de sincronización en nuestro clúster Kubernetes. Ajustar el réplicas y GOMAXPROCS en función de sus necesidades de producción, pero en este ejemplo, vamos a desplegar dos réplicas con un máximo de una vCPU por réplica.

apiVersion: apps/v1 kind: Deployment metadata: name: sync-gateway spec: replicas: 2 selector: matchLabels: app: sync-gateway template: metadata: labels: app: sync-gateway spec:
      contenedores: - nombre: sync-gateway imagen: couchbase/sync-gateway:2.7.3-enterprise montajes de volumen: - nombre: config ruta de montaje: /etc/sync_gateway solo lectura: true entorno: - nombre: GOMAXPROCS
          valor: "1" volúmenes: - nombre: config secreto: nombreSecreto: puerta-de-enlace-sincronización

Despliegue sgw-despliegue.yaml archivo vía kubectl cmd:

$ kubectl create -f sgw-deployment.yaml -n cbdb --save-config deployment.extensions/sync-gateway creado

Puede ver el progreso del despliegue ejecutando:

$ kubectl obtener implementaciones sync-gateway -n cbdb $ kubectl obtener implementaciones sync-gateway -n cbdb NOMBRE LISTO ACTUALIZADO DISPONIBLE ANTIGÜEDAD sync-gateway 2/2 2 2 98 s

Como se puede ver arriba, ambas instancias de réplica están funcionando y ahora sólo tenemos que poner un loadbalancer en la parte delantera.

6.4 Despliegue de un balanceador de carga

En un despliegue de producción, es probable que tenga uno o más nodos Sync Gateway dirigidos por un servidor equilibrador de carga.

Desplegará el equilibrador de carga utilizando el módulo Equilibrador de carga Kubernetes servicio. El servicio de equilibrador de carga proporciona una dirección IP accesible desde el exterior y dirige el tráfico a los puertos adecuados del clúster.

• Cree un nuevo archivo llamado sgw-lb.yaml con los siguientes atributos. Observe que estamos reenviando tanto el 4984 (puerto de acceso público) como el 4985 (puerto admin)

tipo: Servicio apiVersion: v1 metadatos: nombre: sgw-lb especificación: tipo: LoadBalancer selector: aplicación: sync-gateway puertos: - nombre: http protocolo: TCP puerto: 4984 puerto de destino: 4984
  - nombre: http2 protocolo: TCP puerto: 4985 puerto de destino: 4985

Nota estamos reenviando tanto el 4984 (puerto de acceso público) como el 4985 (puerto de administración) a través del equilibrador de carga.

• Despliegue el equilibrador de carga utilizando sgw-lb.yaml archivo.

$ kubectl create -f sgw-lb.yaml -n cbdb service/sgw-load-balancer creado

• Compruebe los pods a los que se dirige el equilibrador de carga.

Si todo se ha desplegado correctamente, debería ver algo similar a lo siguiente:

$ kubectl describe service sgw-load-balancer -n cbdb Nombre: sgw-load-balancer Espacio de nombres: cbdb Etiquetas:  Anotaciones: 
Selector: app=sync-gateway Tipo: LoadBalancer IP: 10.100.106.138 LoadBalancer Ingress: a8ce.us-west-2.elb.amazonaws.com Puerto:  4984/TCP Puerto de destino: 4984/TCP
NodePort:  31066/TCP Puntos finales: 172.16.11.2:4984, 172.16.11.3:4984 Afinidad de sesión: Ninguna Política de tráfico externo: Cluster Eventos: Tipo Motivo Antigüedad Desde Mensaje
  ---- ------ ---- ---- ------- Normal EnsuringLoadBalancer 3m service-controller Asegurando el equilibrador de carga Normal EnsuredLoadBalancer 3m service-controller Equilibrador de carga asegurado

Anote el Entrada del LoadBalancer valor.

6.5 Probar la instalación

Una vez que el equilibrador de carga está en línea, podemos confirmar la accesibilidad del clúster Sync Gateway mediante Entrada del LoadBalancer (como se menciona en la salida anterior). Sólo tiene que utilizar rizo cmd:

curl https://a8ce.us-west-2.elb.amazonaws.com:4984

Debería devolver lo siguiente.

{"couchdb":"Bienvenido","proveedor":{"nombre":"Couchbase Sync \ Gateway","versión":"2.7"},"versión":"Couchbase Sync Gateway/2.7.3(3;33d352f) EE"}

¡Listo! Sync Gateway es totalmente funcional y listo para tomar la carga de trabajo de la aplicación cliente (a través de Couchbase Lite).

6.5.1 Test Lectura/Escritura de documentos

En otro blog hablaré de cómo se pueden desarrollar aplicaciones para los dispositivos de borde utilizando Couchbase Lite pero para probar la sanidad de nuestra configuración de extremo a extremo podemos realizar rápidamente operaciones POST y GET simples utilizando Pasarela de sincronización API REST pública.

Utilicemos el comando curl para insertar un par de documentos:

$ curl -u admin:contraseña -X POST "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "aceptar: aplicación/json" -H "Tipo de contenido: aplicación/json" -d "{\"id\":\"doc3\",\"canales\":\"newton\"}" salida

{"id":"c4988cff19c632a724e13d4390b23b82","ok":true,"rev":"1-f99195111681fe7361b74eb5ebca23d4"}

Se insertó el primer documento y la clave del documento se generó automáticamente como c4988cff19c632a724e13d4390b23b82.

$ curl -u admin:contraseña -X POST "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "aceptar: aplicación/json" -H "Tipo de contenido: aplicación/json" -d "{\"id\":\"doc4\",\"canales\":\"newton\"}" salida

{"id":"8f02cab34faa17d61ca89aa05ade372e","ok":true,"rev":"1-68b03bf8df34c5854d852e3b549d0572"}

El segundo documento también se ha insertado correctamente, utilizando las credenciales de administrador y la clave del documento generada automáticamente es 8f02cab34faa17d61ca89aa05ade372e.

Ahora podemos obtener el documento realizando la operación GET mediante Sync Gateway API REST pública:

$ curl -u admin:contraseña -X GET "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/c4988cff19c632a724e13d4390b23b82" -H "aceptar: aplicación/json" -H "Content-Type: application/json" salida

{"_id":"c4988cff19c632a724e13d4390b23b82","_rev":"1-f99195111681fe7361b74eb5ebca23d4","channels":"foo","id":"doc3"}

Conclusión

Couchbase Sync Gateway es la tecnología crítica de sincronización de datos que permite a los desarrolladores de aplicaciones construir soluciones edge to the cloud. En este artículo, hemos utilizado la última versión de Couchbase Autonomous Operator para instalar el clúster de Couchbase y Sync Gateway en la plataforma de nube pública Kubernetes. En futuros artículos, me basaré en este artículo y te mostraré cómo puedes hacer muchas más cosas de clase empresarial (como el cifrado, LDAP, el desarrollo de Couchbase Lite, y muchos más). Hasta entonces feliz aprendizaje.