Todo comenzó con un simple mensaje: «Hola Geko, estamos recibiendo un timeout de conexión con la DB«. Nos llevó menos de 2 minutos descubrir qué estaba pasando: La base de datos se había borrado. Después de llevarnos las manos a la cabeza varias veces, la tarea principal era recuperar los datos (y el servicio). Afortunadamente, Google aplica políticas de copias de seguridad que guardan una copia cada día. En Geko todos estamos de acuerdo con esta política. La cosa es que fuimos a buscar las copias de seguridad, y la pesadilla comenzó. ¡No había copias de seguridad! ¡No había nada! Y entonces descubrimos que las copias de seguridad están estrechamente ligadas al propio recurso de la base de datos, de modo que si ésta se elimina las copias de seguridad también lo harán. Google lo deja bien claro en su documentación de Cloud SQL.

No vamos a profundizar más en el tema de cómo se borró la base de datos. Simplemente decir que fue un proceso automatizado que detectó un cambio en el tamaño de disco y, cuando trataba de reemplazar el valor con el anterior (que era un valor menor) se requirió un reemplazo completo de la base de datos. No hubo oportunidad para aceptarlo ni para pararlo, por lo que la situación era la que era:

• No hay base de datos == No hay datos
• No hay copias de seguridad

Qué hicimos para resolver la situación

Incluso cuando Google nos estaba diciendo que las copias de seguridad se borran cuando lo hace la base de datos, y que todos los hechos apuntaban a esta hipótesis, fuimos obstinados a pesar de todo ello. La interfaz web de GCP no nos ofreció forma alguna de recuperar nada, por lo que decidimos continuar investigando por línea de comandos (CLI gcloud). ¡Y ésta fue la clave de nuestro éxito!

Teníamos la teoría de que las copias de seguridad deberían estar todavía en alguna parte (aún cuando la documentación dice lo contrario), así que comprobamos diferentes tipos de lugares de almacenamiento hasta probar la sección de copias de seguridad de SQL. Resulta que fuimos lo suficientemente rápidos al comprobar esta sección, y también sabíamos el nombre de la base de datos borrada, por lo que fuimos capaces de ejecutar el siguiente comando.

$ gcloud sql backups list --instance=deleted-db-name --project our-project
ID             WINDOW_START_TIME              ERROR  STATUS
1614876500000  2021-03-04T04:00:00.000+00:00  -      SUCCESSFUL
1614765400000  2021-03-03T04:00:00.000+00:00  -      SUCCESSFUL
1614654300000  2021-03-02T04:00:00.000+00:00  -      SUCCESSFUL
1614543200000  2021-03-01T04:00:00.000+00:00  -      SUCCESSFUL
1614432100000  2021-02-28T04:00:00.000+00:00  -      SUCCESSFUL
1614321000000  2021-02-27T04:00:00.000+00:00  -      SUCCESSFUL
1614210000000  2021-02-26T04:00:00.000+00:00  -      SUCCESSFUL

Y ahí estaban! Después de recuperar el aliento y las sonrisas, el proceso de recuperación daba comienzo. Todavía no confiábamos plenamente en que esto fuese a funcionar, ya que quizás la lista de copias estaba ahí mientras que los datos ya no. Nos movimos rápido porque sabíamos que el tiempo jugaba en nuestra contra, así que inmediatamente creamos una nueva base de datos desde cero y, justo después, iniciamos el proceso de restauración.

$ gcloud sql backups restore 1614876500000 --restore-instance=new-db-from-scratch-name --project our-project --backup-instance=deleted-db-name
All current data on the instance will be lost when the backup is 
restored.

Do you want to continue (Y/n)?  

Restoring Cloud SQL instance...done.                                                                                                                                                                                                        
Restored [https://sqladmin.googleapis.com/sql/v1beta4/projects/our-project/instances/new-db-from-scratch-name]

Finalmente, incluso teniendo retroalimentación positiva por parte de GCP, todavía no nos creíamos que hubiera funcionado. Teníamos que verificar que los datos efectivamente estaba ahí, y así lo hicimos. Afortunadamente todo se había recuperado, por lo que nuestro siguiente y último paso fue realizar una extracción SQL de los datos, de modo que pudiéramos asegurar que teníamos una copia reciente en otra localización diferente.

Conclusión

Incluso después de buscar en Google con ahínco y no encontrar ningún resultado que sirviera de ayuda  — ya que todos dicen que no hay nada que hacer — nuestro conocimiento y pasión nos hizo continuar investigando acerca del tema hasta que encontramos la manera. Sabemos que fuimos afortunados al encontrar las copias de seguridad todavía ahí, pero también sabemos que fuimos rápidos, metódicos y obstinados al buscar y detectar una solución. Por otra parte, hemos aprendido que no nos podemos fiar de las copias de seguridad realizadas por el proveedor, por lo que estamos trabajando actualmente en procedimientos para tener copias en más sitios. Tenemos muy claro que esta es la primera y última vez que nos sucede esto.

Además, y al contrario que AWS, como mencionamos anteriormente, GCP relaciona fuertemente el recurso de la base de datos con sus copias de seguridad. Esto se ha demostrado que puede llegar a ser un gran problema cuando hay que gestionar un borrado accidental. Y a eso hay que sumarle que no es posible copiar o mover las copias de seguridad a otros tipos de almacenamiento. A pesar de lo anterior, hay soluciones personalizadas como extraer los datos SQL regularmente y almacenarlos en un bucket, pero no es algo oficial.

Por otra parte, recomendamos encarecidamente ser cautos cuando haya procesos automatizados alrededor. Hasta donde hemos visto, la única forma de proteger contra eliminación una base de datos en GCP, es limitar los permisos. Por ello, la forma de proceder es eliminar el permiso DELETE de las cuentas (de servicio) que estos procesos automatizados usen.

Afortunadamente siempre puedes contar con el equipo de Geko (un equipo de ingenieros altamente cualificados), quienes profundizarán en el tema hasta conseguir hacerlo sencillo o solucionarlo para ti. ¡No olvides volver por el blog de Geko para comprobar qué hay nuevo por aquí! El equipo de Geko siempre estará más que contento de verte por aquí, y por supuesto

¡Ponte en contacto con nosotros para más información!

La entrada GCP Cloud SQL – Recuperando una base de datos eliminada accidentalmente se publicó primero en Geko Cloud.

Es muy probable que tengas un clúster de GKE en la versión v1.15 y durante varios meses no hayas sufrido problemas cuando, de repente, los logs han dejado de recibirse. Estás usando el sistema de logging que provee el sistema por defecto, por lo que compruebas la página de status de GCP pero todo está funcionando correctamente. Además sabes que no has modificado nada en el clúster antes de que se detuviese la recepción de logs, pero al mismo tiempo sospechas que tiene que estás causado por algo en tu parte (en nuestro caso nos dimos cuenta de que no estaba sucediendo en otros clústeres que gestionamos).

Si la anterior historia te resulta familiar, continúa leyendo ya que este artículo cubrirá desde cómo detectarlo hasta la solución que hará que los logs del clúster se vuelvan a recibir.

1. Síntomas

1. 1. – El síntoma principal que verás es la repentina y completa ausencia de logs en Stackdriver, los cuales deberían estar recibiéndose -como de costumbre- desde los pods de tu clúster.

1. – Además del hecho anterior, podrás descubrir que ya no hay agentes de Fluentd en tu clúster.

   $ kubectl get daemonset -n kube-system | grep -i fluentd
   
   

2. – Por otra parte todos los nodos de tu clúster tienen la etiqueta («label») beta.kubernetes.io/fluentd-ds-ready=true, la cual es requerida por los agentes de Fluentd para saber en qué nodos deben desplegarse.

   $ kubectl get nodes
   NAME                           STATUS   ROLES    AGE     VERSION
   gke-cluster-node-93c020-7rjq   Ready    none     14h     v1.15.11-gke.15
   gke-cluster-node-93c020-9w22   Ready    none     23h     v1.15.11-gke.15
   gke-cluster-node-93c020-jdbt   Ready    none     47h     v1.15.11-gke.15
   gke-cluster-node-93c020-jvcl   Ready    none     3h17m   v1.15.11-gke.15
   
   $ kubectl describe node gke-cluster-node-93c020-7rjq | grep -i fluentd-ds-ready
          beta.kubernetes.io/fluentd-ds-ready=true
   
   $ # Haz lo mismo para los nodos restantes para asegurar que todos ellos están adecuadamente etiquetados

3. – Tu clúster de GKE está actualmente en la versión v1.15 o superior.

2. Diagnóstico

Lo que está sucediendo es que Google está descatalogando a marchas forzadas el antiguo sistema de monitorización/logging. El nuevo sistema que lo reemplaza se llama Cloud Operations for GKE que (para nuestro caso) hace básicamente lo mismo. Una vez dicho eso, cabe mencionar que hay algunas diferencias que deberás tener en cuenta cuando realices búsquedas (como por ejemplo cambios en los nombres de las métricas), y que todas ellas las encontrarás en la guía de migración.

3. Tratamiento

Etiquetar los nodos del clúster

Si te encontraste en pasos previos que uno o varios de los nodos de tu clúster no están etiquetados, ¡hazlo ahora!

$ kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true

Obtén el nombre de tu clúster

Lista los clústeres disponibles.

$ gcloud container clusters list
NAME        LOCATION        MASTER_VERSION  MASTER_IP    MACHINE_TYPE   NODE_VERSION    NUM_NODES  STATUS
my-cluster  europe-east1-a  1.15.12-gke.2   34.35.36.37  n1-standard-2  1.15.11-gke.15  4          RUNNING

Deshabilita el servicio de logging para tu clúster

Actualiza la configuración de tu clúster para establecer el servicio de logging al valor none.

$ gcloud container clusters update my-cluster --logging-service none

Habilita de nuevo el servicio de logging para tu clúster

Actualiza la configuración de tu clúster para volver a establecer el servicio de logging al que hay por defecto.

$ gcloud container clusters update my-cluster --logging-service logging.googleapis.com

ATENCIÓN: Obtendrás un mensaje de error informándote que no es posible habilitarlo debido a la descatalogación. Esta es la forma por la que finalmente nos dimos cuenta dónde estaba el problema. Simplemente sigue adelante, vas en la dirección correcta.

Verifica que el estado de la migración es el esperado

Abre la sección de monitorización (monitoring) de interfaz web de GCP y dirígete a la sub-sección de configuración (Settings). Encontrarás una pestaña llamada «Kubernetes Migration Status» que debería verse como a continuación.

Habilitar completamente el servicio de loggin y monitorización para tu clúster

Abre la lista de clústeres de GKE haz clic en el nombre del clúster donde quieres configurar el nuevo sistema de logging. Una vez veas la configuración del clúster, haz clic en el botón EDITAR como se muestra a continuación.

Desliza hacia abajo hasta encontrar el parámetro Kubernetes Engine Monitoring y, haciendo clic en el desplegable, selecciona la opción Almacenamiento de registros y supervisión del sistema y las cargas de trabajo (System and workload logging and monitoring).

IMPORTANTE: No olvides guardas los cambios usando el botón que hay al final.

Y ya está! Tu clúster volverá a recibir de nuevo los logs!

Conclusión

Como probablemente ya sabrás Google Cloud Platform está todavía en fase beta, por lo que habitualmente encontrarás algunos cambios que harán que fallen tus sistemas en funcionamiento. Tienes dos opciones en este punto: Por un lado puedes mantenerte actualizado acerca de todos los cambios y descatalogaciones futuras. Por otro, puedes limitarte a ir arreglar las cosas según vayan surgiendo, pero ten en cuenta que siempre estarás luchando contra los problemas a ciegas.

Hay una tercera opción (que podría ser la primera), que consiste en consultar regularmente el blog de Geko y verificar si ya nos hemos tratado con el problema que te estás encontrando. El equipo de Geko siempre estará contento de verte aquí

Contáctanos para más información!

La entrada GCP/GKE – Nuevo sistema de logging se publicó primero en Geko Cloud.

De vez en cuando, Google introduce nuevas características y cambios que a veces también obligan a los módulos de Terraform a actualizarse. En Geko, estábamos usando el módulo GKE para la implementación y administración de clústeres públicos en la versión 5.x. Hace unos días, cuando planeamos actualizar algunos parámetros, descubrimos que Google había eliminado la compatibilidad con el panel de control de Kubernetes. Estaba completamente en desuso y el módulo estaba fallando debido a ello, por lo que nos vimos obligados a actualizar el módulo para cumplir con las nuevas condiciones. Hubo hasta 3 actualizaciones de versiones principales disponibles, por lo que decidimos probarlo y usar la última. Sin embargo, no era una solución independiente, ya que requería gestionar las incoherencias del estado de Terraform.

El objetivo de este laboratorio es aprender cómo actualizar el módulo oficial Terraform destinado a implementar y administrar un clúster GKE público. Nos ocuparemos especialmente de los cambios de ruptura del módulo (kubernetes-engine.beta-public-cluster), y lograremos obtener el estado consistente que teníamos antes de la falla que precedió a la actualización.

Tiempo estimado para terminar este laboratorio: ~ 20 minutos

1. Eliminar los recursos anteriores

¡Se recomienda encarecidamente realizar una copia de seguridad de archivos tfstate antes de continuar!

Es especialmente importante eliminar todos los recursos conflictivos del tfstate de Terraform ya que están vinculados entre ellos como dependencias. El objetivo aquí es eliminar cualquier enlace obsoleto antes de importarlo nuevamente desde la «imagen» actual que ya se ha desplegado.

Los componentes principales en un clúster de Kubernetes son las redes (y subredes), el grupo de nodos y el clúster en sí. Centrémonos en ellos.

terraform state rm module.gke.google_container_cluster.primary
terraform state rm module.gke.google_container_node_pool.pools[0]
terraform state rm module.vpc.google_compute_network.network
terraform state rm module.vpc.google_compute_subnetwork.subnetwork[0]
terraform state rm module.vpc.google_compute_subnetwork.subnetwork[1]

2. Actualizar versiones

Una vez eliminados los estados anteriores, el siguiente paso es configurar la última versión los módulos requeridos. Para el módulo GKE, la última versión disponible a fecha de hoy es 8.1.0, pero se permite aplicar automáticamente actualizaciones menores («~>»).

Actualizar el módulo clúster GKE

 module "gke" {
   source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
-  version = "~> 5.0"
+  version = "~> 8.1"

Actualizar el módulo VPC

 module "vpc" {
-  source  = "github.com/terraform-google-modules/terraform-google-network?ref=v1.1.0"
+  source  = "github.com/terraform-google-modules/terraform-google-network?ref=v2.3.0"

Comprobar los nuevos recursos

Para saber si los nuevos recursos han experimentado un cambio de nombre (debido a la actualización de los módulos), se recomienda encarecidamente lanzar un plan de Terraform.

En este caso, se ha encontrado que la jerarquía interna de algunos módulos y también los índices de la lista han cambiado.

  module.gke.google_container_cluster.primary
  
- module.gke.google_container_node_pool.pools[0]
+ module.gke.google_container_node_pool.pools["default-node-pool"]

  module.vpc.google_compute_network.network
  
- module.vpc.google_compute_subnetwork.subnetwork[0]
+ module.vpc.module.subnets.google_compute_subnetwork.subnetwork["southamerica-east1/my-cluster-public"]

- module.vpc.google_compute_subnetwork.subnetwork[1]
+ module.vpc.module.subnets.google_compute_subnetwork.subnetwork["southamerica-east1/my-cluster-private"]

3. Importar los nuevos recursos

Ten en cuenta que la zona/región depende del tipo de clúster. Si es de zona, debe usar la zona maestra (por ejemplo, southamerica-east1-a). Por otro lado, si se trata de un clúster regional, debe usar la región (por ejemplo, southamerica-east1). El siguiente ejemplo supone un clúster regional ubicado en southamerica-east1, en el proyecto «my-project» y con el nombre de clúster «my-cluster». Los nombres de red se configuraron de acuerdo con el nombre del clúster, simplemente agregando los sufijos «private» y «public» a las subredes para diferenciarlos adecuadamente.

Ten en cuenta también la nueva jerarquía de módulos e indexación.

# Global vars
REGION="southamerica-east1"
PROJECT="my-project"
CLUSTER="my-cluster"

# Cluster
CLUSTER_LOCAL="module.gke.google_container_cluster.primary"
CLUSTER_REMOTE="${PROJECT}/${REGION}/${CLUSTER}"
terraform import $CLUSTER_LOCAL $CLUSTER_REMOTE

# Node pool
POOL_LOCAL="module.gke.google_container_node_pool.pools["default-node-pool"]"
POOL_REMOTE="${CLUSTER_REMOTE}/default-node-pool"
terraform import $POOL_LOCAL $POOL_REMOTE

# Subnetworks
BASE_SUBNET_LOCAL="module.vpc.module.subnets.google_compute_subnetwork.subnetwork"

## Public
PUBLIC_SUBNET_LOCAL="${BASE_SUBNET_LOCAL}["${REGION}/${CLUSTER}-public"]"
PUBLIC_SUBNET_REMOTE="${CLUSTER_REMOTE}-public"
terraform import $PUBLIC_SUBNET_LOCAL $PUBLIC_SUBNET_REMOTE

## Private
PRIVATE_SUBNET_LOCAL="${BASE_SUBNET_LOCAL}["${REGION}/${CLUSTER}-private"]"
PRIVATE_SUBNET_REMOTE="${CLUSTER_REMOTE}-private"
terraform import $PRIVATE_SUBNET_LOCAL $PRIVATE_SUBNET_REMOTE

# Network
NETWORK_LOCAL="module.vpc.module.vpc.google_compute_network.network"
NETWORK_REMOTE="${PROJECT}/${CLUSTER}"
terraform import $NETWORK_LOCAL $NETWORK_REMOTE

 4. Actualizar parámetros

Es muy probable que encuentres que, después de lanzar un plan de Terraform, el recurso google_container_cluster todavía necesite actualizarse debido a un cambio en el parámetro de subred. Las nuevas claves de subred han hecho que los índices cambien su orden. Simplemente edita el módulo GKE para reemplazar el parámetro subnetwork como se muestra a continuación.

- subnetwork = module.vpc.subnets_names[0]
+ subnetwork = module.vpc.subnets_names[1]

Conclusión

Como habrás visto anteriormente, a veces, al depender de terceros, puede suceder que se introduzca un cambio importante y tengas problemas para recuperar el servicio nuevamente. Además de esto, la solución podría introducir daños colaterales que requerirán subsoluciones adicionales. En este caso particular con respecto a Terraform, lidiar con estados inconsistentes no es realmente común ni recomendado, pero es el único método que tiene disponible para resolverlos en su conjunto de herramientas.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Actualización del módulo Terraform en los clústeres públicos de GKE se publicó primero en Geko Cloud.

En Geko decidimos implementar SSO en la mayoría de nuestros servicios internos, ya que ya trabajamos con cuentas Gsuite, por lo que era el camino obvio. De todos modos, puedes mantener funcional la administración de usuarios predeterminada si aún deseas usarla.

El uso de SSO también nos hace mucho más fácil las nuevas incorporaciones en nuestro equipo, ya que pueden registrarse directamente y solo tenemos que establecer roles para ellos. Incluso para nuestros clientes, y les podemos permitir que sus dominios establezcan cuentas para ellos, si es necesario.

Tiempo estimado para terminar este laboratorio: 20-30 minutos.

Setup Google Cloud account

Para configurar SSO, necesitamos crear algunas credenciales en Google Cloud. Si no tiene un proyecto creado en GCP, deberás crear uno: https://console.cloud.google.com

Pantalla de consentimiento Oauth

La pantalla de consentimiento es lo que los usuarios verán cuando intenten iniciar sesión en su aplicación (Grafana). Puedes usar este enlace para llegar a la configuración: https://console.cloud.google.com/apis/credentials/consent/edit?

Aquí podemos establecer algunos parámetros para personalizar la pantalla de consentimiento. Vamos a establecer los siguientes valores para este laboratorio:

• Application name: Grafana
• Support email: Tu correo electrónico o cualquier correo asociado a tu cuenta
• Authorized domains: Estos son los dominios contra los cuales los usuarios podrán autenticarse. Por lo general, se usará el nombre de dominio de la organización, pero es posible que también estés interesado en permitir otros.

Como puedes ver, la configuración es bastante sencilla. Si deseas establecer cualquier otro parámetro, siéntete libre, depende de como lo quieras configurar tu.

Crear credenciales

Ahora configuraremos las credenciales que se utilizarán en Grafana para autenticarse en nuestro proyecto Google Cloud: https://console.cloud.google.com/apis/credentials?

• Haz clic en «CREATE CREDENTIALS» y luego en «Oauth Client ID».
• Selecciona «Web application», establece el nombre en «Grafana» y haga clic en «Create»

A continuación aparece un popup con la información siguiente:

Warning! Guarda tu ID de cliente y el secret client en un lugar seguro.

Setup Grafana

Supongo que ya tienes el servicio de configuración docker en tu máquina local. Si no lo has hecho, empieza aquí: https://docs.docker.com/get-docker/

Persistent volume

Incluso si usamos Docker querremos tener datos persistentes para que cualquier modificación en la configuración o paneles no se pierda, incluso si eliminamos el contenedor. Esto hace que las actualizaciones a versiones más nuevas sean realmente fáciles y menos dolorosas. Así que adelante y crea un volume para Grafana:

docker volume create grafana-data

Prepara los argumentos para configurar Grafana

Vamos a darle una vuelta al contenedor de Grafana usando algunas variables de entorno para configurar Grafana. Aquí describiremos para qué es cada uno:

• GF_SECURITY_ADMIN_PASSWORD: Strong random password Contraseña aleatoria segura
• GF_SERVER_ROOT_URL:  Configura esto si deseas anular la raíz del servidor. De lo contrario, puedes eliminar este parámetro. Es útil si ejecutas Grafana detrás de un proxy inverso (por ejemplo, nginx) y necesita acceder a una url específica.
• GF_AUTH_GOOGLE_ENABLED:  Habilita el SSO de Google
• GF_AUTH_GOOGLE_AUTH_URL: Auto explicativo
• GF_AUTH_GOOGLE_TOKEN_URL: Auto explicativo
• GF_AUTH_GOOGLE_CLIENT_SECRET: Secret client que se obtiene cuando creamos las credenciales en GCP
• GF_AUTH_GOOGLE_CLIENT_ID: ID de cliente que se obtiene cuando creamos las credenciales en GCP
• GF_ALLOWED_DOMAINS:  El dominio de tu empresa y todos los demás dominios a los que quieres otorgar acceso (por ejemplo, tus clientes)

Por supuesto, podemos establecer todos estos parámetros en grafana.ini en lugar de usar variables de entorno, es de tu elección el método que quieres usar.

Inicia el contenedor Grafana con nuestros argumentos personalizados

Ahora podemos girar el contenedor. Ten en cuenta que estamos asignando el puerto Grafana a nuestro puerto host 8081:

docker run -d --rm -p 8081:3000 --name grafana 
    -e "GF_SECURITY_ADMIN_PASSWORD=<some_password>" 
    -e "GF_SERVER_ROOT_URL=http://" 
    -e "GF_AUTH_BASIC_ENABLED=<disable_default_auth>" 
    -e "GF_AUTH_GOOGLE_ENABLED=<enable_google_auth>" 
    -e "GF_AUTH_GOOGLE_AUTH_URL=https://accounts.google.com/o/oauth2/auth" 
    -e "GF_AUTH_GOOGLE_TOKEN_URL=https://accounts.google.com/o/oauth2/token" 
    -e "GF_AUTH_GOOGLE_CLIENT_SECRET=<your_client_secret>" 
    -e "GF_AUTH_GOOGLE_CLIENT_ID=<your_client_id>" 
    -e “GF_ALLOWED_DOMAINS=<your_company_domain>”
    -v grafana-storage:/var/lib/grafana 
grafana/grafana

Si todo está bien, deberías poder acceder a grafana en http: // localhost: 8081 y ver un botón para autenticarse con Google:

Si intentas iniciar sesión con una cuenta de gmail que pertenece a un dominio permitido, deberías poder acceder a Grafana fácilmente.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés, por ejemplo «Qué es Kubernetes?«. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Cómo ejecutar Grafana en Docker con Google SSO se publicó primero en Geko Cloud.

Pero a veces hay algunas situaciones en las que GCP Load Balancer no se ajusta a tus necesidades o, simplemente, no deseas usarlo … En esos casos, tenemos una configuración muy simple utilizando dos piezas de software bien conocidas: HAProxy y Keepalived.

Keepalived utiliza Virtual Router Redundancy Protocol (VRRP) y direcciones IP flotantes que pueden ‘moverse’ de una VM a otra en caso de que una de ellas no esté disponible. En un entorno clásico y local, esto es algo así:

En caso de un server failure, cuando el otro servidor toma las direcciones IP flotantes, agrega estas direcciones a tu interfaz de red. El servidor anuncia esta toma de control a otros dispositivos que utilizan la layer 2 mediante el envío de un marco de Protocolo de resolución de direcciones (ARP) gratuito. Google Compute Engine utiliza virtualized network stack y los mecanismos de implementación típicos no funcionan aquí. La red VPC maneja las solicitudes ARP basadas en la topología de enrutamiento configurada e ignora las tramas ARP gratuitas.

En primer lugar, debes instalar haproxy y keepalived en tu servidor. En este caso, usamos Ubuntu 18.04. Solo ejecuta:

sudo apt install haproxy 
sudo apt install keepalived

Para este tutorial configuraremos un load balancer interno, pero también puedes configurar un load balancer externo con algunas pequeñas modificaciones.

Utilizaremos este archivo /etc/haproxy/haproxy.cfg en ambos servidores. Ambos servidores (MASTER y BACKUP) deben tener exactamente la misma configuración de HAProxy.

global
        log /dev/log    local0 debug
        log /dev/log    local1 debug
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend service-1
  bind 192.168.240.140:443
  mode tcp
  option tcplog
  log global
  default_backend service-1-be
backend service-1-be
  mode tcp
  server service-1-server-1 10.152.0.220:443 check id 1
  server service-1-server-2 10.152.0.221:443 check id 2


frontend service-2
  bind 192.168.240.141:443
  mode tcp
  option tcplog
  log global
  default_backend service-2-be
backend service-2-be
  mode tcp
  server service-2-server-1 10.10.0.40:443 check id 1
  server service-2-server-2 10.10.0.41:443 check id 2

En este ejemplo, las dos IP flotantes serán: 192.168.240.140 y 192.168.240.141.

No olvides reiniciar el servicio haproxy (sudo systemctl restart haproxy) cada vez que cambies el archivo de configuración.

Para el archivo de configuración /etc/keepalived/keepalived.conf usaremos estos dos archivos de configuración en las VM masters y slaves:

MASTER

vrrp_instance floating_ip {
    state MASTER
    interface ens4
    unicast_src_ip 192.168.240.10
    unicast_peer {
        192.168.240.11
    }

    virtual_router_id 50
    priority 100
    authentication {
        auth_type PASS
        auth_pass your_passwd
    }
    notify_master /etc/keepalived/takeover.sh root
}

BACKUP

vrrp_instance floating_ip {
    state BACKUP
    interface ens4
    unicast_src_ip 192.168.240.11
    unicast_peer {
        192.168.240.10
    }

    virtual_router_id 50
    priority 50
    authentication {
        auth_type PASS
        auth_pass your_passwd
    }
    notify_master /etc/keepalived/takeover.sh root
}

No olvides reiniciar el servicio keepalived (sudo systemctl restart keepalived) cada vez que cambie el archivo de configuración.

Y ahora la parte que hace la ‘magia’: el script /etc/keepalived/takeover.sh. Básicamente, este script desasigna los alias de IP del par que está inactivo y se los asigna a sí mismo. Después de eso, el servicio haproxy se vuelve a cargar para permitir que el haproxy se una a las IP flotantes.

MASTER

# Unassign peer's IP aliases. Try it until it's possible.
until gcloud compute instances network-interfaces update haproxy-prod-backup --zone europe-west1-c --aliases "" > /etc/keepalived/takeover.log 2>&1; do
    echo "Instance not accessible during takeover. Retrying in 5 seconds..."
    sleep 5
done

# Assign IP aliases to me because now I am the MASTER!
gcloud compute instances network-interfaces update haproxy-prod 
    --zone europe-west1-b 
    --aliases "192.168.240.140/32;192.168.240.141/32" >> /etc/keepalived/takeover.log 2>&1
systemctl restart haproxy
echo "I became the MASTER at: $(date)" >> /etc/keepalived/takeover.log

BACKUP

# Unassign peer's IP aliases. Try it until it's possible.
until gcloud compute instances network-interfaces update haproxy-prod --zone europe-west1-b --aliases "" > /etc/keepalived/takeover.log 2>&1; do
    echo "Instance not accessible during takeover. Retrying in 5 seconds..."
    sleep 5
done

# Assign IP aliases to me because now I am the MASTER!
gcloud compute instances network-interfaces update haproxy-prod-backup 
    --zone europe-west1-c 
    --aliases "192.168.240.140/32;192.168.240.141/32" >> /etc/keepalived/takeover.log 2>&1
systemctl restart haproxy
echo "I became the MASTER at: $(date)" >> /etc/keepalived/takeover.log

De hecho, todo lo que hacemos es asignar / desasignar alias de IP dependiendo de qué VM sea el MAESTRO.

Fácil, ¿no?

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés, por ejemplo «Qué es el cloud?«.

Si tienes alguna duda, contáctanos and Feel the Geko Way!

La entrada Cómo configurar un HAProxy de alta disponibilidad en Google Cloud con Keepalived se publicó primero en Geko Cloud.

Introducción

En Geko trabajamos en un proyecto que requería un servidor nginx para poder incluir en la lista blanca algunas direcciones IP públicas mientras negaba todas las demás conexiones. Si bien esto puede abordarse utilizando las reglas de firewall de GCP, hubo otras razones por las cuales fue necesario hacerlo a través de la configuración de nginx en lugar de usar las reglas de GCP.

El problema es que nginx no mostraba la dirección IP real correcta de la solicitud en el encabezado REMOTE_ADDR.

130.211.0.230 - - [23/Jan/2020:09:44:51 +0000] "GET / HTTP/1.1" 404 "108.26.106.168, 36.129.221.25"

Escenario

Usaré un escenario muy simple:

• Instancia privada de Google Compute que ejecuta dos contenedores docker: nginx y una aplicación basada en php
• Public GCP Load Balancer dirigido al contenedor nginx.

Direcciones IP falsas utilizadas en esta publicación:

• Solicitudes de origen del usuario: 108.26.106.168
• IP pública de GCP Load Balancer: 36.129.221.25
• Rango privado de GCP Load Balancer: 130.211.0.0/22 and 35.191.0.0/16

Eso es.

El problema

Repasemos rápidamente cómo funciona un load balancer: cuando se recibe una solicitud de un cliente remoto, se finaliza y se emite una nueva solicitud desde el LB contra el backend, reenviando un conjunto de headers (haz clic en GCP y AWS para obtener detalles específicos) son atrapados por el servicio subyacente.

Cuando colocas un servidor nginx detrás del LB, recibe la IP privada del Load Balancer como dirección remota en lugar de la IP pública real del usuario.

Si echamos un vistazo a los registros de nginx, podemos ver esto:

130.211.0.130 - - [23/Jan/2020:09:02:51 +0000] "GET / HTTP/1.1" 200 "108.26.106.168, 36.129.221.25"

¡Espera! La dirección IP del usuario aparece en esa cadena al final del registro. ¿Por qué c*j***s está tomando nginx el rango privado de LB como la dirección IP de origen? Bueno, esto se debe a que el LB está haciendo una nueva solicitud.

¿Cómo resolvimos el problema?

La primera IP en el registro proviene del encabezado REMOTE_ADDR. Necesitamos reemplazar el valor de este header con la dirección IP real recibida en el header X-Fordered-For.

Pero hay algo más que debemos tratar con este segundo header: en realidad no solo viene con la IP real del usuario sino también con la dirección pública de Load Balancer.

Para resolver todo esto, utilizaremos el real_ip module. Vamos a aplicar la siguiente configuración en nginx.conf dentro del bloque «server»:

set_real_ip_from 36.129.221.25/32; // LB Public IP address
set_real_ip_from 130.211.0.0/22; // Private IP range for GCP Load Balancers
set_real_ip_from 35.191.0.0/16; //Private IP range for GCP Load Balancers
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Vamos a dividirlo:

• set_real_ip_from: Indicar a nginx que confíe en las IP públicas y privadas de GCP LB.
• real_ip_header: Reemplaza el encabezado REMOTE_ADDR con los valores de X-Fordered-For.
• real_ip_recursive on: Filtra las IPs confiables de la cadena, por lo tanto, la última dirección no confiable de la cadena se utilizará como la dirección remota.

Finalmente pruébalo:

108.26.106.168 - - [23/Jan/2020:09:44:51 +0000] "GET / HTTP/1.1" 200 "108.26.106.168, 36.129.221.25"

Conclusión

Como podemos ver, la solución fue bastante sencilla, pero aun así llevó un tiempo rebuscar en la documentación para comprender cómo Load Balancer reenviaba los encabezados y cómo podemos ajustar nginx para reescribir los encabezados para lograr el comportamiento esperado.

Sin embargo, fue una buena experiencia de aprendizaje.

Fuentes: https://nginx.org/en/docs/http/ngx_http_realip_module.html

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otros posts que puedan ser de tu interés, por ejemplo «Qué es el cloud?«. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Reenviar IP real a un NGINX detrás de un load balancer GCP se publicó primero en Geko Cloud.