domingo, 28 de julio de 2019

Master en sintaxis de la configuración yaml en [Google Cloud Build]




La plataforma de automatización de Cloud Build de Google se basa en una serie de pasos de "constructores" en contenedores, especificados en un archivo de configuración YAML.

Para cada paso, GCB arranca un contenedor Docker y ejecuta un comando específico dentro del contexto de ese contenedor, como Gradle, gcloud o Wget. Puede pasar uno o más argumentos a ese comando usando el campo args en su archivo cloudbuild. yaml.

Esta sintaxis facilita la puesta en marcha de un proceso de compilación básico. Pero a medida que agrega complejidad a su proceso , puede encontrar que su YAML se vuelve difícil de analizar y mantener, o incluso que hay cosas que necesita hacer que simplemente no se pueden expresar. 

En esta publicación, mostraremos formas alternativas de escribir su configuración de creación en el Cloud de estos yaml. Al aplicar estas best practices, tendrá archivos de configuración más legibles y mantenibles. Aún mejor, puede aprovechar el poder oculto de Cloud Build para crear tus pipelines avanzadas con tus  CI / CD.


Como ejemplo, realizaremos un paso de compilación que recupera texto de una API remota y lo imprime en la consola. Empecemos con la versión más simple de la configuración:

Sintaxis simple


steps:
- name: 'gcr.io/cloud-builders/curl'
  args: ['https://pets.doingdevops.com/pet','-s','--max-time','10']

Esta es la sintaxis más común que se encuentra en la documentación, y suele ser el la forma correcta para comenzar.

Práctica recomendada: use esto para trabajos simples: es conciso y fácil de leer.

Sintaxis expandida (collection style)


También funciona si agregamos saltos de línea a la sintaxis simple:

steps:
- name: 'gcr.io/cloud-builders/curl'
  args:
    [
      'https://pets.doingdevops.com/pet',
      '-s',
      '--max-time', '10', # related args on one line
    ]

Al agregar saltos de línea, dejamos espacio para argumentos largos, y hacemos que sea más fácil ver dónde termina un argumento y comienza el siguiente. Esto es especialmente útil cuando se usan variables o estructuras de datos dentro de argumentos, que pueden ser difíciles de leer fácilmente.

Sin embargo, la regla de un argumento por línea no se aplica en realidad. Por lo tanto, si varios argumentos están relacionados, se pueden agrupar una línea. En este ejemplo, los argumentos --max-timeand 10 están en la misma línea, para hacer evidente que uno se refiere al otro.

Best practice: use esta sintaxis cuando la sintaxis básica se vuelva complicada: muchos argumentos, argumentos largos, complejidad dentro de los argumentos, etc. !Cuidado con la gestión de las comas finales¡

Sintaxis expandida (estilo de lista)

Alternativamente, podemos escribir el paso usando una lista YAML, con un argumento por línea, prefijado con guiones. Los argumentos pueden no estar citados, pero eso es una mala idea; es muy difícil leer un argumento como - -s: ¿ese guión-espacio-guión? o espacio-dash-dash? o…?
steps:
- name: 'gcr.io/cloud-builders/curl'
  args:
  - 'https://pets.doingdevops.com/pet'
  - '-s'
  - '--max-time'
  - '10'

Si bien esto es similar a la "sintaxis expandida (estilo de colección)", tiene algunas desventajas:

  1. Tener un guión por argumento reduce la legibilidad, especialmente porque muchos argumentos tendrán sus propios guiones;
  2. No puedes agrupar múltiples argumentos en una sola línea
  3. Es más difícil convertir desde la "sintaxis simple".

Mejores Prácticas: No usar. (Prefiere "estilo de colección".)


Breakout syntax

Cada constructor tiene un punto de entrada predeterminado, que generalmente se relaciona con el propósito de ese constructor. Por ejemplo, el punto de entrada del constructor Gradle es gradle. 

Cuando se invoca un paso de compilación de gradle, el comando de gradle se ejecuta en el contenedor, con todo en la matriz de argumentos que se pasa como argumentos a Gradle.

Pero no estamos limitados solo al comando predeterminado: podemos "romper" y ejecutar cualquier comando disponible en el contenedor, simplemente especificando un punto de entrada alternativo.

La mayoría de los constructores han instalado bash, lo que nos brinda la máxima flexibilidad para hacer todo lo que deseamos dentro de nuestro paso. Esta es la misma operación, pero invocando a bash directamente:
steps:
- name: 'gcr.io/cloud-builders/curl'
  entrypoint: 'bash'
  args:
  - '-c' # pass what follows as a command to bash
  - |
    curl -s 'https://pets.doingdevops.com/pet' --max-time 10

Aquí, se usa una sintaxis de bloque YAML (el argumento está precedido por "|"), por lo que podemos pasar una cadena multilínea sin comillas como el comando. ¿Y qué hemos logrado exactamente? ¡Nada! Esto sigue haciendo lo mismo que el ejemplo "simple". Pero ahora tenemos todo el poder para ejecutar comandos bash arbitrarios. Así que podemos hacer más. Mucho más…

Supongamos que la API remota es inestable; a veces falla En ese caso, queremos volver a intentarlo hasta que tenga éxito. Aquí hay un ejemplo que usa múltiples comandos y lógica condicional para asegurar que obtengamos una respuesta válida:
steps:
- name: 'gcr.io/cloud-builders/curl'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    PET="$$(curl -s https://pets.doingdevops.com/pet_flaky --max-time 10)"
    while [ "$$PET" == "ERROR" ] ; do
      echo "Error: API failed to respond with a pet! Try again..."
      PET="$$(curl -s https://pets.doingdevops.com/pet_flaky --max-time 10)"
  done
  echo "Success! $${PET}"

Tenga en cuenta el uso de signos de dólar dobles ($$) como caracteres de escape. Esto garantiza que Cloud Build los pasará al contenedor, en lugar de interpretarlos como sustituciones.

Al anular el punto de entrada y unir los comandos de bash, podemos hacer todo lo posible dentro de los límites de este contenedor . Y si necesita hacer algo que no esté disponible en un constructor existente, puede crear su propia imagen de constructor personalizada; asegúrese de incluir un shell (por ejemplo, bash) si planea usar la sintaxis de "breakout".

¿Qué es algo interesante que hayas hecho con Cloud Build? Deja una nota en los comentarios!

Los archivos de configuración de ejemplo, y la fuente de los servicios API remotos, se pueden encontrar en github.com/davidstanke/gcb-syntax-blog.

sábado, 20 de julio de 2019

Debug en producción usando los repositorios de Google Cloud

Google Cloud tiene herramientas geniales para desarrolladores de software. Los repositorios de Cloud Source y el debugger de  Stackdriver son utilizados diariamente por miles de desarrolladores que valoran la excelente búsqueda de códigos de Cloud Source Repositories y la capacidad del Debugger para encontrar errores de forma rápida y segura en los servicios de producción.

Pero Debugger no es un navegador de código completo, y no está estrechamente integrado con todos los entornos de desarrollador más comunes. ¡La buena noticia es que estas herramientas se están juntando! A partir de hoy, puede hacer debug sus servicios de producción directamente en los repositorios de origen del Cloud de Google , para cada servicio en el que esté habilitado el stackdriver Debugger activado.


Lo nuevo en los repositorios de Cloud Source

Esta integración aporta dos piezas de funcionalidad a los repositorios en el cloud: soporte para Snapshots  y logpoints.

Snapshots


Los snapshots son imágenes puntuales de las variables locales y del stack de su aplicación que se activan cuando se cumple una condición de código. Piense en los snapshots como puntos de interrupción que no detienen la ejecución.

Para crear uno, simplemente haga clic en un número de línea como lo haría con un debugger tradicional, y el snapshot se activará la próxima vez que una de sus instancias ejecute la línea seleccionada. Cuando esto suceda, verás las variables locales capturadas durante el snapshot y la pila de llamadas completa, ¡sin detener la aplicación ni afectar su estado y las operaciones en curso!

Puede navegar y ver las variables locales en esta instantánea desde cada stack, al igual que con cualquier otro debugger. También tiene acceso completo a las condiciones y expresiones, y existen medidas de seguridad para protegerse contra cambios accidentales en el estado de su aplicación.



Logpoints

Los puntos de registro  "logpoints" le permiten insertar dinámicamente las declaraciones de registro en sus servicios en ejecución sin volver a implementarlos. Cada punto de registro funciona como una declaración de registro que escribe normalmente en su código: puede agregar texto libre, variables de referencia y establecer las condiciones para que se guarde el registro. Los logpoints se escriben en su ruta de salida estándar, lo que significa que puede utilizarlos con cualquier backend de registro, no solo con el registro del controlador de pila.

Crear un punto de registro es muy parecido a crear un snapshots: simplemente haga clic en el número de línea de la línea en la que desea establecerlo y listo.

Al agregar un logpoint a su aplicación, se envía a todas las instancias del servicio seleccionado. Los puntos de registro duran 24 horas o hasta que el servicio se vuelve a implementar, lo que ocurra primero. Los logpoints tienen el mismo impacto en el rendimiento que cualquier otra declaración de registro que existe normalmente en su código fuente.


Por dónde empezar


Para usar las capacidades de debugger de producción de Cloud Source Repositories, primero debe habilitar en sus proyectos de Google Cloud Platform para el Debugger de Stackdriver. Puede obtener más información sobre estos pasos de configuración en la documentación del Depurador de Stackdriver.

Una vez que se haya completado, navegue hasta el código fuente que desea depurar en los repositorios de Cloud Source, luego seleccione ‘Depurar aplicación’. Hoy en día, esto funciona mejor con el código almacenado en los repositorios de origen del cloud o que se refleja en fuentes de terceros compatibles, como GitHub, Bitbucket y GitLab. Una vez que haya seleccionado su aplicación, puede comenzar a colocar snapshots y logpoints en su código haciendo clic en los números de línea en el margen izquierdo.






Debugger en la  producción.

Ser capaz de depurar el código que se está ejecutando en producción es una capacidad crítica, y poder hacerlo desde un navegador de código con todas las funciones es aún mejor. 

Ahora, al llevar la depuración de producción a los repositorios de origen del cloud, puedes rastrear problemas difíciles de encontrar en el fondo de su código, mientras puede hacer cosas como sincronizar continuamente el código de una variedad de fuentes diferentes, clases de referencias cruzadas, vea el historial de cambios y busque por nombre de clase, nombre de método, etc. Para obtener más información, consulte esta guía.

martes, 16 de julio de 2019

AI HUB despliega tu IA en tu empresa

AI Hub es una plataforma para descubrir e implementar productos que usan "Aprendizaje Automático", desde la experimentación hasta la producción.




AI Hub tu nuevo portal para todo lo que AI en su empresa, así como en general. Esta es una introducción a los diversos componentes que Google Cloud ofrece para que pueda escalar su implementación de IA.

Conozca cómo AI Hub fomenta la colaboración, el intercambio y la reutilización de los componentes de AI dentro de las empresas y sus colaboradores.

Experimente cómo puede aprovechar las mejores tecnologías y soluciones de inteligencia artificial de Google y desplegarlas en producción en GCP.

Empiza ahora mismo -> https://aihub.cloud.google.com/

martes, 2 de julio de 2019

Minikube vs Docker vs MicroK8s vs Minishift

 Certified Kubernetes  Resultado de imagen de kubernetes  Resultado de imagen de minikube

¿ Tenemos opciones para ejecutar Kubernetes en la nube y Kubernetes On-Prem?.
¿Qué hay de las opciones para ejecutar Kubernetes en el ordenador de escritorio y/o portátil?

Comparamos cuatro opciones que puedes elegir hoy. Minikube vs Docker Desktop vs MicroK8s vs Minishift.

Todas estas opciones están bastante diferenciadas. A diferencia de la variedad de soluciones de On-Prem Kubernetes, donde existen muchas sin ninguna razón, creo que hay un caso para la existencia de cada una de las opciones locales de Kubernetes que se están revisando.

Revisaremos cada uno de ellos y luego los resumiré con una tabla al final.

Minikube


Kubernetes fue construido por ingenieros de sistemas para ingenieros de sistemas. Minikube es la forma original de ejecutar Kubernetes localmente y, como puede imaginar, es la mejor opción actualmente para los ingenieros de sistemas. Si su compañía está ejecutando "Vanilla Kubernetes" ya sea en la versión local o a través de un servicio en la nube, y está en un rol de tipo SRE, entonces este es el recomendable..

Minikube funciona en todas las plataformas y te permite configurar muchas opciones. Si está ejecutando Linux, puedes desactivar la máquina virtual para que se ejecute de forma nativa.

La otra cosa interesante es que es compatible con todas las versiones de Kubernetes, por lo que puede hacer coincidir exactamente las versiones que está ejecutando en su ordenador portátil con la versión que está ejecutando en sus servidores.

Como perfil de tipo SRE, ejecuto Minikube localmente y también ejecutamos esto en CI build VM´s para pruebas de unidad en el trabajo.


Minikube
CompaniaCNCF
URLhttps://kubernetes.io/docs/setup/minikube/
Version KubernetesAny
Os soportadoOSX, Linux, Windows
Tipo contenedorLinux
VMNone, Virtualbox, VMWare fusion, KVM2, Hyperkit, xhyve, Hyper-V
Addonsaddon-manager, coredns, dashboard, default-storageclass, efk, freshpod, heapster, ingress, kube-dns, metrics-server, nvidia-driver-installer, nvidia-gpu-device-plugin, registry, registry-creds, storage-provisioner

Minikube
MejorLa mejor solución para los operadores de clústeres Kubernetes (DevOps / SRE) que desean practicar las tareas de administración de clústeres Kubernetes. Opciones de Kubernetes altamente configurables.
PeorVM separada en OSX y Windows. Más complejo que Docker Desktop para desarrolladores.

Docker Desktop

Este es el que recomendarás a tus equipos de desarrollo.
Todos los desarrolladores ya tendrán instalado Docker, por lo que habilitar a Kubernetes es tan simple como marcar una casilla de verificación.

 Kubernetes luego se ejecuta en la misma máquina virtual en Windows y OSX que Docker, lo que ahorra algunos recursos. Docker Desktop esconde gran parte de la complejidad de la administración de clústeres, lo cual es excelente si su objetivo es simplemente escribir aplicaciones y ejecutarlas.

El otro beneficio es que cuando ejecute Kubernetes en Docker Desktop, sus aplicaciones compartirán el mismo registro de imágenes entre Docker y Kubernetes.

Hay otra razón convincente para usar Docker Desktop. Si está utilizando Windows y desea utilizar contenedores de Windows, esta es la única opción que lo admite. Tenga en cuenta que esto no funciona bien con la virtualización no nativa. (Debes deshabilitar cualquier VirtualBox y usar solo HyperV.)



Docker Desktop
CompaniaDocker
URLhttps://www.docker.com/products/docker-desktop
Version KubernetesHardcoded to Docker
Os soportadoOSX, Windows
Tipo contenedorLinux (on OSX), Linux or Windows (on Windows)
VMHyperkit, Hyper-V
Addons-

Docker Desktop
MejorLa mejor solución para desarrolladores que quieran construir aplicaciones localmente. La única solución en Windows que ejecutará contenedores de Windows. Se ejecuta en la misma máquina virtual que Docker. Las imágenes comparten el mismo registro local.
PeorKubernetes no es tan configurable como las otras opciones. Si eres un SRE utiliza Minikube.
-->

MicroK8s

Esto es de Canonical, esperamos que esté realmente diseñado para la gente de Ubuntu.

Aunque, es compatible con cualquier sistema que pueda usar paquetes Snap. Hay algunos beneficios inherentes de usar una aplicación instalada de Snap relacionada con el sandboxing y la desinstalación limpia. MicroK8s realiza un seguimiento de Kubernetes en sentido ascendente y ofrece canales estables y beta.

Tampoco requiere ninguna máquina virtual, que es similar a la ejecución de Minikube en Linux con vm-driver = none. Como MicroK8s solo se ejecuta en Linux, tiene menos base de usuarios.

También es la menos madura de todas las opciones y solo se lanzó en mayo de 2018. Si ya está utilizando paquetes Snap, esta puede ser una buena opción.

Probablemente seguiría con Minikube o Docker Desktop dependiendo de mi función, pero es bueno que exista otra opción para competir.


Minishift
CompaniaRedhat
URLhttps://www.okd.io/minishift/
Version KubernetesHardcoded to OKD
Os soportadoOSX, Linux, Windows
Tipo contenedorLinux
VMVirtualbox, xhyve, KVM, Hyper-V
Addonsanyuid, admin-user, registry-route, htpasswd-identity-provider, xpaas, che, community addons

Minishift
MejorLa mejor solución para operadores y desarrolladores que utilizan OpenShift en su empresa.
PeorSi está ejecutando Kubernetes que no son OpenShift en su empresa, vaya con otra opción.
-->

MiniShift

Es la opción para las personas que trabajan para compañías que han comprado en OpenShift y, por lo tanto, usar Minishift localmente es la mejor opción.

Creo que tendría sentido utilizar Minishift independientemente de su función si ya está en esta plataforma en caso de que haya alguna diferencia.


Minishift
CompaniaRedhat
URLhttps://www.okd.io/minishift/
Version KubernetesHardcoded to OKD
Os soportadoOSX, Linux, Windows
Tipo contenedorLinux
VMVirtualbox, xhyve, KVM, Hyper-V
Addonsanyuid, admin-user, registry-route, htpasswd-identity-provider, xpaas, che, community addons

Minishift
MejorLa mejor solución para operadores y desarrolladores que utilizan OpenShift en su empresa.
PeorSi está ejecutando Kubernetes que no son OpenShift en su empresa, vaya con otra opción.