martes, 27 de marzo de 2018

Google Cloud Summit Madrid 2018

Hoy nos anuncia en España Madrid un Google Cloud Summit Madrid. Si el 10 de Mayo estas en Madrid no dudes en registrarte en el Summit de Google Cloud.


 Registrate en el Summit

10 de mayo de 2018    Kinepolis, Ciudad de la Imagen


A partir del 10 de mayo en Madrid en Kinepolis tienes una agenda publicada de un evento de un día entero sobre Google Cloud con distintos tracks e información de evento. 
Regístrate ya y bloquea tu agenda para este día nos vemos en Madrid.

lunes, 19 de marzo de 2018

Herramientas básicas para administrar Kubernetes desde el terminal



Actualmente el auge de Kubernetes ha hecho present la necesidad de facilitar su administración, dado que la orquestación es distribuida y en la mayoría de los casos se dispone de varios clusters, además de varios namespace, es necesario conocer cuales son las mejores herramientas de que disponemos para facilitar y agilizar el uso de Kubernetes.

Es importante remarcar también que existe una componente de seguridad, no tanto en cuanto a las medidas de seguridad que aplica Kubernetes o las aplicaciones que desplegamos, sino seguridad de que lo que estamos haciendo lo hacemos en el lugar correcto. Este problema es antiguo ya que en el terminal de Linux siempre ha existido ese miedo de "estoy donde toca", eso los más antiguos del lugar lo recordarán bien, es un miedo que nunca te quitas del todo, pero solo con la práctica y el tiempo consigues dominarlo.


kubectl

Esta herramienta es la base de la administración de un cluster en Kubernetes, nos permite conectarnos al cluster para realizar todas las tareas que necesitemos, tanto de lectura de estados, como de creación de nuevos recursos o modificación de los ya existentes.


Primeramente debes instalarte esta herramienta y como siempre existen muchas formas de hacerlo dependiendo del sistema operativo que uses. La referencia principal para instalar kubectl es la propia página del proyecto kubernetes, en ella encontraremos las intrucciones para los distintos sistemas operativos, solo hay que elegir una opción y listo, aunque para mi la más recomendada es la de instalar con el SDK de Google Cloud Platform, basta con tener previamente instalada la SDK, puede consultarse aquí y ejecutar el siguiente comando:

gcloud components install kubectl
Lo primero que deberíamos hacer una vez instalado es activar el autocompletado de la terminal, esto es fundamental debido a la gran cantidad de opciones que tiene, para ellos también en la página del proyecto Kubernetes tenemos las instrucciones para activar en distintas shells aquí, en mi caso como uso zsh sería sencillo, bastaría con añadir los siguiente a mi fichero ~/.zshrc:


if [ $commands[kubectl] ]; then
  source <(kubectl completion zsh)
fi

Como indicaba antes este comando es la base de la administración de Kubernetes, una vez lo tengamos instalado lo primero que deberemos hacer es conectarlo con nuestro cluster, para ello debemos seguir las instrucciones según donde tengamos instalado el cluster, en mi caso al estar en Google Cloud Platform es tan sencillo como ir a la consola y seleccionar el botón conectar del cluster que queremos.



Nos mostrará una linea que podemos copiar y pegar en nuestro terminal para tener conectado el cluster y empezar a trabajar.

Hasta aquí lo básico que todo administrador o desarrollador que quiere usar Kubernetes necesita, pero tal como decía al principio es difícil saber sin más con que cluster estás conectado y en que namespace, esto además hace que si se tiene varios clusters con varios namespace, pero que tienen los mismos despliegues y servicios, puede ser peligroso ejecutar una orden de escalado donde no toca. Por ejemplo si tenemos un cluster de QA, uno de pre-producción y otro de producción, los tres van a tener los mismos servicios, despliegues y nombres de los ingress por ejemplo, si nos equivocamos y escalamos producción pensando que es QA tensmos un problema.

Como podemos mitigar esto? existen un par de herramientas que nos pueden ayudar de forma visiual ha estar seguros de en que entorno estamos, son kubectx, kubens y kube-ps1.


kubectx

Básicamente se trata de una herramienta escrita en bash que nos permite saber cuantos contextos tenemos configurados y cambiar rápidamente entre ellos, de forma que podamos conectarnos a cada cluster sin necesidad de acordarnos de todos los párametros necesarios cada vez.

Podemos instalarlo siguiendo las instrucciones en su repositorio de github.

https://github.com/ahmetb/kubectx



Para todos aquellos que tienen que administrar varios clusters, este comando les va ha facilitar muchísimo las distintas tareas en los distintos contextos, ya que sin necesidad de acordarse de toda la sintaxis puede conectar con todos los clusters o simplemente saber que clusters hay configurados en la sesión.

kubens

Conjuntamente con kubectx también se instalará kubens, también escrita en bash, esta nos permitirá cambiar entre los distintos namespaces disponibles en el contexto actual.


Con esta herramienta el cambio entre los distintos nasmespaces, así como el listado de los mismos se vuelve un juego de niños, permitiendo hacer un cambio rápido y repetir comandos entre namespaces de forma ágil.

kube-ps1

Este último, pese a no ser una herramienta como tal, he querido añadirlo ya que es la perfecta combinación con los anteriores, permitiendo saber en to momento tanto el cluster en el que estamos como namespaces activo, mostrando en el PROMPT toda la información del contexto actual que necesitamos para tener la seguridad de que vamos a ejecutar los distintos comandos en el cluster y namespace correcto.

https://github.com/jonmosco/kube-ps1


viernes, 16 de marzo de 2018

Integración continua y serverless en google cloud



Siempre hay temas punteros en Google Cloud Español hoy os hablaremos de serverless con integración continua usando google cloud. Existen muchas razones para automatizar las implementaciones: consistencia, seguridad y puntualidad.

Estos aumentan en valor a medida que su software se vuelve más crítico para su negocio. En esta publicación, demostraré lo fácil que es comenzar a automatizar las implementaciones con las herramientas de Google Cloud Platform (GCP) y derivarlo a recursos adicionales para ayudar a que su proceso de implementación sea más robusto.

Supongamos que tiene una aplicación de Google Cloud Functions, Firebase o Google App Engine. En la actualidad, probablemente implemente su función o aplicación a través de comandos de gcloud desde su estación de trabajo local. Veamos un flujo de trabajo ligero que aprovecha dos productos de Google Cloud: Cloud Source Repositories y Cloud Container Builder.


Esta simple pipeline utiliza triggers de compilación en Cloud Container Builder para implementar una función en Cloud Funtions cuando el código fuente se envía "push2 a una rama "prod".

El primer paso es poner tu código bajo control. Si ya está usando un proveedor como GitHub o Bitbucket, es trivial duplicar su código a un repositorio de fuentes de Cloud. Cloud Source Repositories se ofrece sin cargo para hasta cinco usuarios del proyecto, por lo que es perfecto para equipos pequeños.

Los comandos para la línea de comandos se capturan a continuación, pero puede encontrar guías más detalladas en la documentación.

Crea y clona tu repositorio:

$ gcloud source repos create my-function
Created [my-function].

$ gcloud source repos clone my-function
Cloning into 'my-function'...

Ahora, cree una función simple (incluya un paquete.json si tiene dependencias de terceros):
index.js

index.js
exports.f = function(req, res) {
  res.send("hello, gcf!");
};

Luego, crea una definición de compilación Container Builder:

deploy.yaml
steps:
- name: gcr.io/cloud-builders/gcloud
  args:
  - beta
  - functions
  - deploy
  - --trigger-http
  - --source=.
  - --entry-point=f
  - hello-gcf # Function name

Esto es equivalente a ejecutar el comando:

gcloud beta functions deploy --trigger-http --source=. --entry-point=f hello-gcf

Antes de comenzar la primera compilación, configure su proyecto para Container Builder. Primero, habilite dos API: la API de Container Builder y la API de Cloud Functions. Para permitir que Container Builder se implemente, debe darle acceso a su proyecto.

El proceso de compilación usa las credenciales de una cuenta de servicio asociada con esas compilaciones. La dirección de esa cuenta de servicio es:

{numerical-project-id}@cloudbuild.gserviceaccount.com

Deberás agregar un rol de IAM a esa cuenta de servicio: Editor de proyectos. Si usa este proceso para implementar otros recursos, es posible que necesite agregar otros roles de IAM.





Ahora, prueba la configuración de implementación y sus permisos ejecutando:


gcloud container builds submit --config deploy.yaml


Su función ahora se implementa mediante Cloud Container Builder.

Crear un trigger de compilación es fácil: elija su repositorio, la condición de desencadenante (en este caso, empujando hacia la rama "prod") y la compilación para ejecutar (en este caso, la compilación especificada en "deploy.yaml").


Ahora, actualice la rama "prod", actualícela con "master", empújela a los repositorios de Cloud Source y su función se desplegará.


$ git checkout prod
$ git pull origin prod
$ git merge master
$ git push origin prod


Si la implementación falla, se mostrará como una compilación fallida en la pantalla de historial de compilación. Verifique los registros para investigar qué salió mal. También puede configurar el correo electrónico u otras notificaciones utilizando Pub / Sub y Cloud Functions.

Esta es una canalización de implementación simplificada, lo suficiente como para demostrar el poder de la automatización de implementación. En algún momento, probablemente encontrará que este proceso no es todo lo potente que necesita. Por ejemplo, es posible que desee obtener una aprobación manual antes de actualizar la producción. Si eso sucede, consulte Spinnaker, un sistema de automatización de implementación de código abierto que puede manejar flujos de trabajo más complejos.

A medida que avanzas e hacia la automatización de tus implementaciones, estas son algunas otras herramientas y técnicas para que pruebes:




Mejore en los procesos de CD/CI de las implementaciones de software.

jueves, 15 de marzo de 2018

SELinux y DOCKER all rock


 Resultado de imagen de selinux

En google cloud español nos tomamos la seguridad como un punto importante, y he localizado estos apuntes que se aplican en los contenedores y me ha parecido importantes por la utilidad que tienen. Viene de una adaptacion de la web de danwash https://danwalsh.livejournal.com/78312.html

SELinux esta antes de que aparecieran los contenedores por eso cuando nos cambiamos  a trabajar con contenedores hace varios años, pero una de las primeras cosas hay que con los contenedores es agregar el soporte de SELinux. Todos los proyectos de contenedores , incluyendo CRI-O, Podman, Buildah, así como Docker, Moby, Rocket, runc, systemd-nspawn, lxc ... todos tienen soporte SELinux. También  el paquete de políticas container-selinux del que dependen todos estos tiempos de ejecución de contenedores.

Cualquier forma en que los tiempos de ejecución de los contenedores comenzaron a agregar las capacidades de no-nuevos privilegios hace un par de años.

no_new_privs

La característica del kernel no_new_privs funciona de la siguiente manera:


  • Los procesos establecen un bit no_new_privs en el kernel que persiste en fork, clone, y exec.
  • El bit no_new_privs asegura que los procesos / procesos secundarios no obtengan ningún privilegio adicional.
  • El proceso no permite desarmar ningún bit no_new_privs una vez establecido.
  • Los procesos no_new_privs no pueden cambiar uid / gid u obtener otras capacidades, incluso si el proceso ejecuta archivos binarios o ejecutables setuid con bits de capacidad de archivo establecidos.
  • no_new_privs impide que los módulos de seguridad de Linux (LSM) como SELinux pasen a procesar etiquetas que no tienen acceso al proceso actual. Esto significa que un proceso de SELinux solo puede pasar a un tipo de proceso con menos privilegios.

Vaya, esa última bandera es un problema para contenedores y SELinux. Si estoy ejecutando un comando como

 
# podman run -ti --security-opt no-new-privileges fedora sh
 

En el sistema SELinux y, por lo general, el comando podman se ejecuta como unconfined_t, y normalmente podman solicita que el proceso del contenedor se inicie como container_t.

o

docker run -ti --security-opt no-new-privileges fedora sh

En el caso de Docker, el daemon docker generalmente se ejecuta como container_runtime_t. E intentará iniciar el contenedor como container_t.

Pero el usuario también pidió nuevos privilegios. Si se establecen ambos indicadores, el kernel no permitirá que el proceso pase de unconfined_t -> container_t. Y en el caso de Docker, el kernel no permitiría una transición de container_runtime_t -> container_t.

Bueno, puedes decir que es bastante obvio no_new_privileges se supone que es una medida de seguridad que impide que un proceso obtenga más privilegios, pero en este caso, en realidad nos impide disminuir su acceso a SELinux.

En el kernel y la política de SELinux tenían el concepto de "typebounds", donde un escritor de políticas podía escribir que un tipo de tipo tenía otro tipo. Por ejemplo

typebounds container_runtime_t container_t, y el kernel se aseguraría entonces de que container_t no tenga más reglas de permiso que container_runtime_t. Este concepto demostró ser problemático por dos razones.

Typebounds

La política de escritura para los typebounds fue muy difícil y en algunos casos tendríamos que agregar acceso adicional al tipo delimitador.

Un ejemplo de esto es SELinux puede controlar el `entrypoint` de un proceso. Por ejemplo, escribimos una política que dice que httpd_t solo se puede ingresar mediante ejecutables etiquetados con el tipo de punto de entrada httpd_exec_t.

También teníamos una regla de que container_runtime_t solo se puede ingresar a través del tipo de entrpoint de container_runtime_exec_t. Pero queríamos permitir que cualquier proceso se ejecutara dentro de un contenedor, escribimos una reglas que todos los tipos de ejecutables podrían usarse como puntos de entrada para container_t.

Con typebounds, necesitamos agregar todas estas reglas a container_runtime_t, lo que significa que deberíamos permitir que todos los ejecutables se ejecuten como container_runtime_t. y no es lo mas recomendable.

El segundo problema con typebounds y kernel y política solo permitía un único tipo de typebounds. Entonces, si quisiéramos permitir procesos unconfined_t para lanzar procesos container_t, terminaríamos escribiendo reglas como

typebounds unconfined_t container_runtime_t
typebounds container_runtime_t container_t.

Ahora unconfined_t necesitaría hacer crecer todas las reglas allow de container_runtime_t y container_t.

nnp_transitions

Bueno, me estaba quejando de esto a Lucas Vrabec, el tipo que se hizo cargo de la política de selinux, y él me cuenta acerca de esta nueva regla de permiso llamada nnp_transitions. El autor de la política podría escribir una regla en la política para decir que un proceso podría nnp_transition de un dominio a otro.

allow container_runtime_t confined_t: process2 nnp_transition;
allow unconfined_t confined_t: process2 nnp_transition;

Con un kernel bastante reciente, SELinux permitiría la transición incluso si se estableció el indicador de kernel no_new_privs, y las reglas de typebounds NO estaban en su lugar.

ME siento como un SELINux NEWBIE. Agregué las reglas sobre Fedora 27 y de repente todo comenzó a funcionar. A partir de RHEL7.5, esta función se transferirá nuevamente al kernel RHEL7.5 Increíble.

nosuid_transition

Mientras miraba las reglas nnp_transition, noté que también había un permiso nosuid_transition.

Con nosuid permite a las personas montar un sistema de archivos con el tag marcaco  nosuid, esto le dice al kernel que incluso si existe una aplicación setuid en este sistema de archivos, el kernel debería ignorarla y no permitir que un proceso gane privilegios a través del archivo.

Siempre quiere que los sistemas de archivos no confiables, como los dispositivos USB, se monten con esta bandera.

Bien, los sistemas SELinux ignoran de manera similar las reglas de transición en las etiquetas basadas en un sistema de archivos nosuid. Similar a nnp_transition, esto bloquea un proceso de transición de un dominio privilegiado a un dominio menos privilegiado. Pero el indicador nosuid_transtion nos permite decirle al kernel que permita transiciones de un dominio a otro, incluso si el sistema de archivos está marcado como nosuid.

allow container_runtime_t confined_t:process2 nosuid_transition;
allow unconfined_t container_t:process2 nosuid_transition;

Esto significa que incluso si un usuario usara podman para ejecutar un archivo en un sistema de archivos nosuid, se le permitiría la transición de unconfined_t a container_t.

Bueno, es bueno saber que todavía hay cosas que puedo aprender sobre SELinux.

martes, 13 de marzo de 2018

OpenCensus framework de métricas.

OpenCensus hoy en Google cloud español hablamos de una Framework de gestión de métricas y trazabilidad.


OpenCensus, una biblioteca de código abierto de para cualquier proveedor  para la recopilación y el seguimiento de métricas. OpenCensus está diseñado para agregar una sobrecarga mínima y desplegarse en toda la plataforma, especialmente para arquitecturas basadas en micro servicios.


La necesidad de instrumentación y observabilidad

A menudo el objetivo es sacar una versión inicial del producto, prototipar rápidamente e iterar con los clientes. La mayoría de las startups comienzan con aplicaciones monolíticas como una simple aplicación web modelo-view-controller (MVC). A medida que la base de clientes, el código y el número de ingenieros aumentan, migran de una arquitectura monolítica a una arquitectura de microservicios.

Una arquitectura de microservicios tiene sus ventajas, pero a menudo hace que la depuración sea más desafiante ya que las herramientas tradicionales de depuración y monitoreo no siempre funcionan en estos entornos o están diseñadas para casos de uso monolítico. Al operar múltiples microservicios con estrictos objetivos de nivel de servicio (SLO), necesita información sobre la causa raíz de la fiabilidad y los problemas de rendimiento.

El hecho de no tener la instrumentación y la observabilidad adecuadas puede ocasionar la pérdida de horas de ingeniería, la violación de los SLO y la frustración de los clientes. En cambio, los datos de diagnóstico se deben recopilar a través de la pila. Estos datos se pueden usar para la administración de incidentes para identificar y eliminar posibles cuellos de botella o para el ajuste del sistema y la mejora del rendimiento.

OpenCensus

En la escala de Google, una capa de instrumentación con una sobrecarga mínima es un requisito. A medida que Google creció, se dieron cuenta de la importancia de contar con una biblioteca de instrumentación de estadísticas y rastreo altamente eficiente que podría implementarse en toda la estructura.



OpenCensus es la versión de código abierto de la biblioteca del Census de Google, escrita en base a años de experiencia en optimización. Su objetivo es facilitar la recopilación y el envío de métricas y rastreos de aplicaciones para los desarrolladores.

Es una distribución única y neutral del vendedor de bibliotecas que recopila automáticamente las huellas y métricas de su aplicación, las muestra localmente y las envía a las herramientas de análisis. OpenCensus actualmente es compatible con Prometheus, SignalFx, Stackdriver y Zipkin.

Los desarrolladores pueden usar esta poderosa biblioteca lista para usar para instrumentar microservicios y enviar datos a cualquier back-end compatible. Para un proveedor de Application Performance Management (APM), OpenCensus proporciona cobertura de instrumentación gratuita con un trabajo mínimo, y ofrece a los clientes una experiencia de configuración sencilla.

A continuación, se muestran las capturas de pantalla de Stackdriver Trace and Monitor que muestran los rastros generados a partir de una aplicación de demostración, que llama a la API Cloud Bigtable de Google y utiliza OpenCensus.





Esperamos que encuentre esto tan útil como nosotros. Visite opencensus.io para obtener más información.

lunes, 12 de marzo de 2018

El CLI ahora en interactivo en google cloud

Hoy en google cloud en español os presentamos una nueva capacidad del entorno CLI de Google cloud.



Si creas aplicaciones en Google Cloud Platform (GCP), a línea de comando de GCP tiene que ser tu amiga. Pero a medida que crecemos nuestros servicios de BPC, la cantidad de comandos  crece a pasos agigantados. Pero hay nueva interfaz de línea de comandos (CLI) que le permite descubrir y usar todos estos comandos de manera más eficiente: gcloud interactive.

Google Cloud SDK ofrece una variedad de herramientas de línea de comandos para interactuar con google cloud platform:

  • gcloud: CLI principal de GCP
  • gsutil - CLI para interactuar con Google Cloud Storage
  • bq - CLI para interactuar con Google BigQuery
  • kubectl - CLI de Kubernetes Engine


Actualmente en alfa pública, el nuevo entorno CLI interactivo proporciona indicaciones automáticas y ayuda en línea para los comandos gcloud, gsutil, bq y kubectl. Ya nos podemos ahorrar, ya  medida que busca nombres de comando, indicadores necesarios o tipos de argumentos en las páginas de ayuda. ¡Ahora toda esta información se incluye como parte del entorno interactivo mientras escribe!


El entorno interactivo también admite funciones bash estándar como:
  • Entremezclando gcloud y comandos bash estándar
  • Ejecutar comandos como cd y pwd, y establecer / usar variables de shell en ejecuciones de comandos
  • Ejecutando y controlando procesos en segundo plano
  • TAB-completar variables de shell, y mucho más!


Por ejemplo, puede asignar el resultado del comando a una variable y luego llamar a esta variable como una entrada a un comando diferente:


$ active_vms=$(gcloud compute instances list --format="value(NAME)" --filter="STATUS=RUNNING")
$ echo $active_vms



También puede crear y ejecutar scripts bash mientras se encuentra en el entorno interactivo.


Por ejemplo, la siguiente secuencia de comandos itera todas las instancias de cálculo y reinicia las que han sido TERMINADAS.


#!/bin/bash
terminated_vms=$(gcloud compute instances list --format="value(NAME)" --filter="STATUS=terminated")
for name in $terminated_vms
do
  echo "Instance $name will restart."
  zone=$(gcloud compute instances list --format="value(ZONE)" --filter="NAME=$name")
  gcloud compute instances start $name --zone $zone 
done







Comenzando con gcloud interactivo

Una vez que haya instalado Google Cloud SDK, siga adelante y pruebe gcloud interactive: (si aún no lo ha instalado, puede ver las instrucciones en este enlace)

1. Asegúrese de que los componentes de su SDK estén actualizados.

$ gcloud components update


2. Instala el componente alpha de gcloud.

$ gcloud components install alpha



3. Comience gcloud interactivo

$ gcloud alpha interactive



[Opcional] Habilite el modo interactivo para gsutil, bq y kubectl (está habilitado para gcloud de manera predeterminada.) Tenga en cuenta que esto puede tardar unos minutos en completarse, pero solo necesita ejecutar este comando una vez.

$ gcloud alpha interactive --update-cli-trees


Trucos:


  • Cuando desee obtener más información sobre el comando actual que escribió, presione F8 para abrir la página de referencia en el navegador.
  • Puede establecer el contexto de solicitud en cualquier grupo de comandos. Esto es útil si trabaja principalmente con ciertos grupos de comandos y le ahorra tener que escribir el comando completo cada vez. Puede hacer esto escribiendo el grupo de comando y presionando F7.
  • Active y desactive el área de ayuda interactiva con la tecla F2.

  • Use la tecla F3 para alternar el modo de edición de línea de comando entre emacs y vi.

Haga clic aquí para obtener más información acerca de gcloud interactive, y comente qué piensa utilizando el comando gcloud feedback.

miércoles, 7 de marzo de 2018

Google usa OpenCensus ¿Y para que?


Hoy en google cloud español hoy hablamos de una herramienta que usa Google para medir métricas, hoy os contamos todo.



OpenCensus, es un conjunto de bibliotecas de instrumentación de open-source  que se usa dentro de Google. OpenCensus presenta una ventaja para desarrolladores  el interés de Google en herramientas de instrumentación open-source.

Obteniendo información en los sistemas a Escala de Planeta

Google adoptó o creo tecnologías, para tener trazas  y obtener procesamiento de métricas, (Dapper) con el fin de operar algunos de los servicios web más grandes del mundo. Sin embargo, la construcción de sistemas de análisis no resolvió el difícil problema de instrumentar y extraer datos de los servicios de producción. Esto es para lo que se creó Census.

El proyecto Census proporciona instrumentos uniformes en la mayoría de los servicios de Google, capturando trazas, métricas a nivel de aplicación y otros metadatos, como correlaciones de registro de aplicaciones de producción. Uno de los mayores beneficios de la instrumentación uniforme para los desarrolladores dentro de Google es que es casi completamente automática: cualquier servicio que use el sistema RPC interno de Google (que se ha abierto como gRPC) recopila y exporta automáticamente las trazas y métricas básicas.

OpenCensus ofrece estas capacidades a los desarrolladores de todo el mundo. Hoy hablamos cómo utilizan el seguimiento distribuido y las métricas dentro de Google.

Administracion de incidentes.

Cuando surgen problemas de latencia o nuevos errores en un entorno altamente distribuido, la visibilidad de lo que está sucediendo es fundamental. Por ejemplo, cuando la latencia de un servicio cruza los límites esperados, podemos ver los rastros distribuidos en Dapper para encontrar dónde se ralentizan las cosas. O cuando una solicitud devuelve un error, podemos observar la cadena de llamadas que condujeron al error y examinar los metadatos capturados durante un seguimiento (por lo general, registros o anotaciones de rastreo). Este es efectivamente un rastro de pila más grande. En casos excepcionales, se habilitan el muestreo personalizado basado en disparadores que nos permite enfocar en tipos específicos de solicitudes.

Una vez que sabemos que hay un problema de producción, podemos usar los datos del Census para determinar las regiones, los servicios y el alcance (un cliente frente a muchos) de un problema determinado. Puede usar páginas de diagnóstico específicas del servicio, denominadas "páginas z", para supervisar los problemas y los resultados de las soluciones que implementa. Estas páginas se alojan localmente en cada servicio y proporcionan una vista corta de solicitudes recientes, estadísticas y otra información relacionada con el rendimiento.

Optimización del rendimiento

En la escala de Google, se  puede instrumentar y atribuir los costos de los servicios. Usamos el Census para ayudarnos a responder preguntas como:
  • ¿Cuánto tiempo de CPU consume mi consulta?
  • ¿Mi función consume más recursos de almacenamiento que antes?
  • ¿Cuál es el costo de una operación de usuario particular en una capa particular de la pila?
  • ¿Cuál es el costo total de una operación de usuario particular en todas las capas de la pila?

Para dar con la reducción de la latencia de cola de todos los servicios, se ha creado sofisticados sistemas de análisis que procesan trazas y métricas capturadas por el Census para identificar regresiones y otras anomalías.

Calidad de servicio

Google también mejora el rendimiento dinámicamente según la fuente y el tipo de tráfico. Al usar las etiquetas del Census, el tráfico puede dirigirse a zonas más apropiados, o se puede hacer cosas como la eliminación de carga y la limitación de velocidad.

lunes, 5 de marzo de 2018

Google cloud y La "Zona Andrómeda" O como controlar un ataque DDOS

Hoy  en google cloud español nos hemos preguntado como estamos de protegidos en Google Cloud ante un ataque DDOS.


Esta semana hemos sido informados toda la comunidad de como GitHub ha sufrido uno delos últimos ataques de DDOS, que por otro parte han sabido gestionar. Tienes mas información aquí o aquí. El ataque brutal de 1,35Tbs que fue repelido por  GitHub.



Por este motivo me pregunto como estamos ante ataques de este tipo si estamos con google cloud, y la respuesta es: Entramos en la Zona Andrómeda.

Dentro zona de Andrómeda: la última pila de redes de Google Cloud Platform.
La última tecnología de red que impulsa nuestros servicios internos a disposición de los usuarios de Cloud Platform en todo el mundo.

Andromeda, el nombre clave de la pila de virtualización de red de Google, ahora activa dos zonas de Google Compute Engine. Los clientes  verán automáticamente un mayor rendimiento en el rendimiento a través de nuestras conexiones de red rápidas.

Los desafíos de redes introducidos por la virtualización. Ofrecer el más alto nivel de rendimiento, disponibilidad y seguridad requiere la organización a través de máquinas virtuales, hipervisores, sistemas operativos, tarjetas de interfaz de red, conmutadores de rack, switches de fabric, enrutadores fronterizos e incluso nuestro extremo de peering de red.

En google cloud tienen   una posición única para aprovechar el control y la experiencia de Google sobre todo el hardware, el software, la LAN y la WAN para ofrecer una experiencia perfecta para los clientes de Cloud Platform.

En Googlec loud , nos beneficiamos de tener acceso programable a toda la pila de red, desde el hardware de nivel más bajo hasta los elementos de software de más alto nivel. En lugar de forzarnos a crear soluciones comprometidas basadas en los puntos de inserción disponibles, podemos diseñar soluciones integrales seguras y eficaces mediante la coordinación en toda la pila.

Andromeda es un sustrato basado en Software Defined Networking (SDN) para nuestros esfuerzos de virtualización de red. Es el punto de orquestación para el aprovisionamiento, la configuración y la administración de redes virtuales y el procesamiento de paquetes dentro de la red. La siguiente figura de mi presentación muestra la arquitectura de alto nivel de Andrómeda:

El objetivo de Andromeda es exponer el rendimiento sin procesar de la red subyacente a la vez que se expone la virtualización de funciones de red (NFV). Exponemos el mismo procesamiento dentro de la red que permite que nuestros servicios internos se escalen y permanezcan extensibles y aislados para los usuarios finales. Esta funcionalidad incluye protección de denegación de servicio (DDoS) distribuida, equilibrio de carga de servicio transparente, listas de control de acceso y firewalls.

Hacemos esto al mismo tiempo que mejoramos el rendimiento, con más mejoras por venir.
Por lo tanto, Andrómeda en sí no es un producto de red de Cloud Platform; más bien, es la base para brindar servicios de red de Cloud Platform con alto rendimiento, disponibilidad, aislamiento y seguridad. Por ejemplo, las reglas de cortafuegos, enrutamiento y enrutamiento de Cloud Platform aprovechan todas las API internas y la infraestructura de Andromeda.


Presenta  varios escenarios, como la publicación de equilibrio de carga de Google Compute Engine 1M RPS previamente descrita. También presenta mejoras en el rendimiento de transmisión TCP en Google Compute Engine (GCE), la más notable de las cuales fue una mejora significativa de la latencia, el rendimiento y la sobrecarga de la CPU a nivel de red. Si bien estas mejoras conducirán a algunos de los mejores rendimientos de red disponibles en la industria,.

Andromeda permite Cloud Platform exponer cada vez más el rendimiento de la infraestructura de red sin procesar de Google a todas las máquinas virtuales (VM) de GCE.

Algunas de las mejoras más valiosas permiten que las máquinas virtuales incorporadas al soporte de kernels de Linux exploten las capacidades de descarga / multi-cola.

Animo a los clientes interesados ​​a crear nuevas máquinas virtuales GCE utilizando la imagen de backports de Debian. Esta imagen tiene los últimos controladores necesarios para lograr el mejor rendimiento.
Para mostrar la magnitud del despliegue de mejoras, el equipo de Cloud Platform realizó una serie de experimentos de rendimiento. Un benchmark evaluó el rendimiento utilizando netperf TCP_STREAM en la misma zona GCE. Al comparar el rendimiento de línea base (antes de Andrómeda) con Andrómeda, podemos destacar los beneficios de la arquitectura de Andrómeda.


Andromeda es una nueva versión de la arquitectura de virtualización de red subyacente, y su núcleo SDN permite iterar rápidamente y ofrecer nuevas funcionalidades. Esto asegura que la red de Cloud Platform continuará siendo un agente de interrupción de la computación en nube en el futuro.