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 create cluster --name k8sEKS \
 --version 1.18 \
 --region us-west-2 \
 --zones us-west-2a,us-west-2b \
 --vpc-cidr 172.16.0.0/20 \
 --without-nodegroup

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 create nodegroup --cluster=k8sEKS \
 --name=m5l-pool \
 --node-type m5.large \
 --region us-west-2 \
 --nodes 2 \
 --nodes-min 2 \
 --nodes-max 4 \
 --node-ami auto

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 create nodegroup --cluster=k8sEKS \
 --name=r5l-pool \
 --node-type r5.large \
 --region us-west-2 \
 --nodes 2 \
 --nodes-min 2 \
 --nodes-max 4 \
 --node-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 \
 --nodes 1 \
 --nodes-min 1 \
 --nodes-max 2 \
 --node-ami auto

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 get nodegroups --cluster=k8sEKS --region=us-west-2

LUSTER    NODEGROUP   CREATED         MIN SIZE    MAX SIZE    DESIRED CAPACITY    INSTANCE TYPE   IMAGE ID
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 get nodes --show-labels

NAME                                         STATUS    ROLES     AGE       VERSION              LABELS
ip-172-16-0-12.us-west-2.compute.internal    Ready     <none>    21m       v1.14.9-eks-a0a484   ...,beta.kubernetes.io/instance-type=t2.xlarge,...
ip-172-16-0-127.us-west-2.compute.internal   Ready     <none>    32m       v1.14.9-eks-a0a484   ...,beta.kubernetes.io/instance-type=m5.large,...
ip-172-16-3-234.us-west-2.compute.internal   Ready     <none>    32m       v1.14.9-eks-a0a484   ...,beta.kubernetes.io/instance-type=m5.large,...
ip-172-16-1-29.us-west-2.compute.internal    Ready     <none>    32m       v1.14.9-eks-a0a484   ...,beta.kubernetes.io/instance-type=r5.large,...
ip-172-16-3-119.us-west-2.compute.internal   Ready     <none>    32m       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 label nodes 'ec2-node-ip'  instanceType=data

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

$ kubectl label nodes '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 create namespace cbdb

  namespace/cbdb created

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

  $ kubectl get namespaces

  NAME              STATUS    AGE
  cbdb              Active    34s
  default           Active    5h20m

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 generate admission --namespace default | kubectl create -f -


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

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

$ kubectl get deployments

NAME                           READY     UP-TO-DATE   AVAILABLE   AGE
couchbase-operator-admission   1/1       1            1           48s

4.2. Instalar el Operador Couchbase

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

$ bin/cbopcfg generate operator --namespace cbdb | kubectl create -f -

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

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 get deployments -n cbdb

NAME                 READY     UP-TO-DATE   AVAILABLE   AGE
couchbase-operator   1/1       1            1           73s

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

NAME                                  READY     STATUS    RESTARTS   AGE
couchbase-operator-558fd8486c-788jr   1/1       Running   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 created

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 created

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.

servers:
  - name: data-service-2a
    size: 1
    services:
      - data
    volumeMounts:
      default: pvc-default        # /opt/couchbase/var/lib/couchbase
      data: pvc-data               # /mnt/data
    pod:
      spec:
        nodeSelector:
          beta.kubernetes.io/instance-type: m5.large
  - name: index-quer-service-2a
    size: 1
    services:
      - index
      - query
    volumeMounts:
      default: pvc-default
      index: pvc-index
    pod:
      spec:
        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 created

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 get pods  -n cbdb -w

NAME                                  READY     STATUS    RESTARTS   AGE
cbdemo-0000                           0/1       Running   0          1m
cbdemo-0001                           0/1       Running   0          53s
cbdemo-0002                           0/1       Running   0          20s
couchbase-operator-558fd8486c-788jr   1/1       Running   0          21m
cbdemo-0003   0/1       Pending   0         3s
cbdemo-0003   0/1       Pending   0         3s
cbdemo-0003   0/1       ContainerCreating   0         3s
cbdemo-0003   0/1       Running   0         18s
cbdemo-0001   1/1       Running   0         2m
cbdemo-0000   1/1       Running   0         2m
cbdemo-0002   1/1       Running   0         1m
cbdemo-0003   1/1       Running   0         1m

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

$ kubectl get pods -owide -n cbdb

NAME                                  READY     STATUS    RESTARTS   AGE       IP             NODE                                         NOMINATED NODE   READINESS GATES
cbdemo-0000                           1/1       Running   0          10m       172.16.2.134   ip-172-16-3-234.us-west-2.compute.internal   <none>           <none>
cbdemo-0001                           1/1       Running   0          10m       172.16.1.116   ip-172-16-0-127.us-west-2.compute.internal   <none>           <none>
cbdemo-0002                           1/1       Running   0          9m51s     172.16.1.5     ip-172-16-1-29.us-west-2.compute.internal    <none>           <none>
cbdemo-0003                           1/1       Running   0          9m3s      172.16.2.98    ip-172-16-3-119.us-west-2.compute.internal   <none>           <none>
couchbase-operator-558fd8486c-r2tcc   1/1       Running   0          31m       172.16.1.230   ip-172-16-0-12.us-west-2.compute.internal    <none>           <none>

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

Forwarding from 127.0.0.1:18091 -> 18091
Forwarding from [::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.

security:
  adminSecret: cb-admin-auth
  rbac:
    managed: false
  ldap:
    hosts:
    - ldap.forumsys.com
    port: 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:

...
      },
      "databases": {
        "cbdemo": {
          "server": "couchbase://cbdemo-srv.cbdb.svc.cluster.local",
          "bucket": "staging",
          "username": "newton",
          "password": "password",
          "allow_conflicts": false,
          "revs_limit": 20,
          "enable_shared_bucket_access": true,
          "import_docs": true,
          "sync": function(doc, oldDoc) {
                      channel(doc.channels);
                  },
        }
    ...

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 created

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

$ kubectl get secret -n cbdb

NAME                             TYPE                                  DATA      AGE
cb-admin-auth                    Opaque                                2         4h
couchbase-operator-token-p4qzb   kubernetes.io/service-account-token   3         4h
default-token-x7cvw              kubernetes.io/service-account-token   3         4h
sgw-config                       Opaque                                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:
      containers:
      - name: sync-gateway
        image: couchbase/sync-gateway:2.7.3-enterprise
        volumeMounts:
        - name: config
          mountPath: /etc/sync_gateway
          readOnly: true
        env:
        - name: GOMAXPROCS
          value: "1"
      volumes:
      - name: config
        secret:
          secretName: sync-gateway

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

$ kubectl create -f sgw-deployment.yaml -n cbdb --save-config

deployment.extensions/sync-gateway created

Puede ver el progreso del despliegue ejecutando:

$ kubectl get deployments sync-gateway -n cbdb

$ kubectl get deployments sync-gateway -n cbdb
NAME           READY     UP-TO-DATE   AVAILABLE   AGE
sync-gateway   2/2       2            2           98s

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)

kind: Service
apiVersion: v1
metadata:
  name: sgw-lb
spec:
  type: LoadBalancer
  selector:
    app: sync-gateway
  ports:
  - name: http
    protocol: TCP
    port: 4984
    targetPort: 4984
  - name: http2
    protocol: TCP
    port: 4985
    targetPort: 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 created

• 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

Name:                     sgw-load-balancer
Namespace:                cbdb
Labels:                   <none>
Annotations:              <none>
Selector:                 app=sync-gateway
Type:                     LoadBalancer
IP:                       10.100.106.138
LoadBalancer Ingress:     a8ce.us-west-2.elb.amazonaws.com
Port:                     <unset>  4984/TCP
TargetPort:               4984/TCP
NodePort:                 <unset>  31066/TCP
Endpoints:                172.16.11.2:4984, 172.16.11.3:4984
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason                Age   From                Message
  ----    ------                ----  ----                -------
  Normal  EnsuringLoadBalancer  3m    service-controller  Ensuring load balancer
  Normal  EnsuredLoadBalancer   3m    service-controller  Ensured load balancer

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":"Welcome","vendor":{"name":"Couchbase Sync \
 Gateway","version":"2.7"},"version":"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:password -X POST "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"id\":\"doc3\",\"channels\":\"newton\"}"

output

{"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:password -X POST "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/" -H "accept: application/json" -H "Content-Type: application/json" -d "{\"id\":\"doc4\",\"channels\":\"newton\"}"

output

{"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:password -X GET "https://a8ce.us-west-2.elb.amazonaws.com:4984/cbdemo/c4988cff19c632a724e13d4390b23b82" -H "accept: application/json" -H "Content-Type: application/json"

output

{"_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.