Curso de DevOps: Automatización VIII. Componentes de una plataforma de automatización

Vamos a recordar los componentes de la plataforma de automatización, junto con las ventajas de utilizar una plataforma frente a un sistema de scripts aislados para tareas de administración del sistema. Hay diferentes enfoques que podemos adoptar para automatizar nuestros sistemas. Uno de ellos es adoptar la plataforma de automatización. El segundo es optar por el script de automatización. Intentemos comprender la arquitectura centrándonos en los componentes de esta.

 

Hay cuatro capas importantes. La primera capa es la base que proporciona la infraestructura. Puede ser NSX, vSphere o también puede ser vSAN. La segunda capa tiene que ver con operaciones en las que podemos utilizar componentes como vRealize Log Insight o incluso vRealize Operations Manager. Hay que seleccionar componentes que puedan gestionar las operaciones de nuestra plataforma de automatización. Después necesitamos una plataforma de gestión en la nube, que pueda funcionar con la automatización del orquestador. vRealize proporciona componentes como vRealize Orchestrator y vRealize Automation para administrar nuestra plataforma en la nube. Y, por último, es necesario identificar escenarios que representen qué modelos de negocio se pueden automatizar. Y eso se puede hacer utilizando vRealize Business o vRealize Hyperic. Existen varias herramientas externas diferentes que se pueden utilizar para crear escenarios.

 

Ahora, debemos centrarnos en utilizar un flujo de trabajo de automatización. Puede haber una desviación respecto a nuestro flujo de trabajo de automatización. Estamos adoptando un flujo de trabajo de automatización que se ha implementado prácticamente en varios escenarios. Para empezar, primero debemos utilizar un formato de diseño validado proporcionado por un proveedor. Por ejemplo, podemos tomar la base de VMware Validated Design. Esto nos ayudará a clasificar primero el tipo de implementación. Ahora hay tres posibilidades diferentes de tipo de implementación. La primera es una región única, la segunda es una región dual y la tercera es una región cruzada que utiliza UDLR. Necesitamos entender que una sola región siempre se preparará para una región particular, digamos, la región Y, como se indica en la ilustración. Podemos utilizar estas regiones para realizar la implementación de varios escenarios que están presentes en una región en particular. Podemos completar la región Z. Cuando tenemos una región dual, tenemos que realizar todas las tareas de una sola región y luego necesitaremos preparar la región X. En resumen, estamos preparando dos regiones diferentes y luego estas implementarán los escenarios. Cuando vayamos a una región cruzada con UDLR, realizaremos un escenario con UDLR. No realizaremos un escenario preparando un escenario explícito para regiones específicas.

 

Ahora bien, ¿cuales son las ventajas de utilizar una plataforma de automatización? En primer lugar, la alta disponibilidad de los componentes de gestión porque están debidamente probados. Proporciona copia de seguridad y restauración simplificada de los componentes de administración, monitoreo y alertas configurables y configuración basada en UI de recuperación ante desastres de los componentes de administración.

 

Finalmente, necesitamos clasificar los beneficios de la plataforma de scripts. El primer beneficio es la compatibilidad con el ritmo del ciclo de desarrollo. Costo de mantenimiento más económico y proporciona automatización de escala incorporada. También proporciona la capacidad de ampliar el alcance de la automatización. Y, por último, proporciona una adopción mejorada con automatización de pruebas sin código donde, en el caso de un script, es necesario escribir código. Depende de un intérprete particular para interpretar el código. También es necesario probarlo aplicando varios tipos diferentes de pruebas.

 

Curso de SQL. Filtrar resultados usando HAVING

A diferencia de la cláusula WHERE, HAVING se puede utilizar con funciones agregadas. Una función agregada es una función donde se agrupan los valores de varias filas juntos como información sobre ciertos criterios para formar un valor único de significado más significativo o medición.

Las funciones agregadas comunes incluyen COUNT(), SUM(), MIN() y MAX().

Este ejemplo utiliza la tabla Coches de una base de datos de ejemplo.

SELECT IdCliente, COUNT(Id) AS [Numero de Coches] FROM Coches

GROUP BY IdCliente HAVING COUNT(Id) > 1

Esta consulta devolverá el ID de cliente y el número de coches de cualquier 

cliente que tenga más de uno. En este caso, hay dos clientes que tienen 

más de uno, el 1 y el 4, el cliente 1 tiene 2 coches y el cliente 4 tiene 3 coches.

Los resultados se verán así:

Id. de cliente Número de Coches

stomerId ProductId Quantity Price

1                   2

4                   3

También se puede utilizar HAVING para comprobar si hay clientes que hayan pedido dos productos determinados. Por ejemplo en este caso se quiere saber los clientes que han pedido el producto con Id = 2 e Id = 3.

SELECT IdCliente FROM Pedidos WHERE IdProducto in (2,3)

GROUP by IdCliente HAVING count(distinct IdProducto) = 2

La consulta selecciona solo registros con los IdProducto 2 y 3 y con la cláusula

 HAVING busca solo los clientes que hayan pedido ambos IdProducto  

y no solo uno.

Otra posibilidad sería

SELECT IdCliente FROM orders GROUP BY IdCliente HAVING SUM(CASE WHEN IdProducto = 2 THEN 1 ELSE 0 END) > 0 AND SUM(CASE WHEN productID = 3 THEN 1 ELSE 0 END) > 0 

Esta consulta selecciona solo grupos que tengan al menos un registro con 

IdProducto =  2 y al menos uno con IdProducto = 3.

 

Curso de DevOps: Automatización VII. Atributos de los flujos de trabajo de automatización y DevOps

 La automatización es uno de los requisitos esenciales de la implementación de DevOps. Hay varias formas diferentes en las que podemos planificar el flujo de trabajo de automatización. Vamos a utilizar el marco de automatización API.

Hay tres unidades esenciales. Primero está el script de automatización, que puede contener archivos de características, datos de automatización o, a veces, repositorios de correo basura. Todo esto será utilizado por el marco de automatización API para automatizar la tarea. El marco de automatización API estará compuesto por un motor de ejecución de automatización, utilidades de automatización, utilidades de KPI para monitorear las tareas de automatización y ciertas utilidades comunes para integrar servicios externos al marco API existente. El resultado final serán informes y registros de automatización. Podemos utilizar varias herramientas diferentes en cada una de estas capas para asegurarnos de poder derivar un flujo de trabajo de automatización sólido para nuestro sistema existente utilizando marcos de automatización API.

El flujo de trabajo automatizado de DevOps también se basa en una canalización de componentes. La canalización de componentes comienza con la actividad de los desarrolladores de verificar la fuente. Una vez que se verifica la fuente y se compila, realizaremos pruebas de unidad y de sus componentes. En caso de que sea necesario revertir, revertiremos los cambios y una vez que estemos convencidos con el módulo probado, ensamblaremos los módulos. Cargaremos el módulo no controlado para su aprobación y finalmente, una vez aprobado, enviaremos una notificación. Las notificaciones pueden ser de dos tipos, puede ser una notificación de éxito o de error. Una vez que la carga de módulos no controlados se realice correctamente, el tipo de notificación será exitosa; de lo contrario, será una notificación de error.

Teniendo en cuenta el proceso de integración, comenzamos eligiendo la versión del componente. Una vez que hayamos seleccionado la versión del componente, debemos descargar todos los módulos dependientes. Después de descargar las dependencias, o módulos de los que depende nuestro componente, ensamblaremos y crearemos una unidad desplegable. Esas unidades desplegables se desplegarán utilizando varias estrategias de despliegue diferentes, como si se pudiera incrementar hasta la puesta en escena. Realizaremos una “prueba de humo” como resultado, podremos revertir la implementación y notificar la falla. Pero si la prueba  tiene éxito, comprobaremos el “sistema inmunológico”. Nuevamente, el resultado de la verificación, si no es satisfactorio, podemos revertir el despliegue, pero si tiene éxito, realizaremos la prueba de aceptación. Si la prueba de aceptación no tiene éxito, podemos revertir la implementación nuevamente. Pero si es así, si todo está bien, podemos retroceder la preparación, realizar una prueba de humo adecuada en la preparación, promocionar los módulos y luego desplegar la unidad. Y finalmente, una vez finalizada la implementación, notificar el éxito. Pero si la etapa de reversión no tiene éxito, notificaremos el error.

Finalmente, vemos el flujo de trabajo automatizado de DevOps, pero ahora desde la perspectiva de la implementación en producción. Planificaremos el incremento de implementación de lo que esté listo para la producción. Una vez que esté implementado, haremos una prueba y decidiremos si revertimos la implementación o no. Si seleccionamos la estrategia de implementación de reversión porque la prueba falle, debemos detectar una implementación incorrecta. Necesitamos notificar el fracaso. Pero sí, si pasa la prueba se realizará una prueba del sistema “inmunológico” y notificaremos el éxito.

 

Cláusulas EXPLAIN and DESCRIBE

 DESCRIBE nombre_tabla

DESCRIBE y EXPLAIN son sinónimos. DESCRIBE en un nombre de tabla devuelve la definición de las columnas.

DESCRIBE tablename;

 Ejemplo de resultado:

COLUMN_NAME COLUMN_TYPE IS_NULLABLE COLUMN_KEY COLUMN_DEFAULT EXTRA

id int(11) NO PRI 0

auto_increment

test varchar(255) YES (null)

Muestra los nombres de las columnas, seguidos del tipo de columna, si se permite nulo en la columna y si la columna utiliza un índice. También se muestra el valor predeterminado y si la tabla contiene algún comportamiento especial como un  auto_increment.

EXPLAIN Select query

Un EXPLAIN delante de una consulta de selección muestra cómo se ejecutará la consulta. De esta manera veremos si la consulta utiliza un índice o si podríamos optimizar la consulta agregando un índice. 

Ejemplo de query:

explain select * from usuarios join data on usuarios.test = data.fk_usuarios;

Ejemplo de resultado:

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE user index test test 5 (null) 1 Using where;

Usando índice

1 SIMPLE data ref fk_user fk_user 5 user.test 1 (null)

En el tipo se ve si se utilizó un índice. En la columna posible_keys podemos ver si el plan de ejecución puede elegir entre diferentes índices o si no existe ninguno.  La clave nos indica el índice real utilizado. Key_len muestra el tamaño en bytes de un elemento de índice. Cuanto menor sea este valor, más elementos del índice encajarán en el mismo tamaño de memoria y se pueden procesar más rápido. Rows muestra el número esperado de filas que la consulta debe escanear, cuanto más bajas, mejor.

Curso de DevOps: Automatización VI. Relaciones, dependencias y políticas

El objetivo de este post es identificar las relaciones, dependencias y las políticas de automatización que se utilizan para derivar un clúster de automatización de referencia, con componentes heterogéneos. Para crear una arquitectura de automatización de clústeres, debemos centrarnos en ciertos elementos esenciales.

La automatización de un clúster implica varios componentes diferentes, y cada componente tiene un papel esencial que desempeñar. El componente central es la sala de control, que asume la responsabilidad de la concesión de licencias y proporciona capacidades de visualización de conocimientos, almacenamiento en caché, mensajería, servicio de conocimientos y descubrimiento de servicios de conocimientos. Toda la configuración para la automatización del clúster se realiza en una base de datos persistente, que puede ser PostgreSQL o cualquier otra base de datos de nuestra elección, donde podremos almacenar la base de datos de metadatos del panel. La base de datos persistente puede funcionar con capacidades de Elasticsearch para proporcionar una búsqueda rápida que permita una mejor búsqueda. Podemos tener varios componentes conectados a la sala de control, que se gestionarán para la automatización del clúster. Uno de ellos es el servidor SQL, podemos optar por un servidor Oracle, que tendrá una base de datos de sala de control y una base de datos de análisis. Podremos tener un servidor de versiones, que será un componente opcional. Nuestra sala de control también deberá funcionar con archivos compartidos, que pueden ser SMB. Utilizando todos estos componentes, podemos crear capacidades de automatización de clústeres.

Ahora vamos a ver los componentes esenciales del clúster. El primer componente es el propio grupo de clústeres. Podemos considerar un grupo de clústeres como un grupo de servicios agrupados que conmutan juntos si hay un fallo en uno de ellos, pues estarán estrechamente acoplados entre sí. En segundo lugar está el host, es la máquina del clúster, que se requiere para alojar el servicio. El tercero es el nodo, es un término genérico que se usa para máquinas en un clúster. Los nodos pueden ser de dos tipos: nodo primario que contiene el servicio de base de datos activo y un nodo secundario que es el servicio duplicado pasivo o en espera. Y finalmente, tendremos un servidor, que se encarga de escuchar todas las solicitudes y gestionar y procesar las solicitudes.

Dentro de la tarea del clúster de automatización. Dependiendo de nuestras  necesidades, podemos configurar un clúster de automatización para brindarnos la posibilidad de administrar fallas de aplicaciones y servicios, administrar fallas de sitios en organizaciones de múltiples sitios y ocuparnos de fallas de sistemas y hardware. Aparte de eso, también debemos identificar las razones críticas por las que utilizar el clúster de automatización. La primera razón es que nos facilita la replicación. Esta replicación puede ser de varios tipos, puede ser replicación sincrónica o replicación asincrónica. El objetivo principal es garantizar que el nodo primario y el nodo secundario estén sincronizados. La segunda razón para utilizar un clúster de automatización es gestionar el tiempo de inactividad y la conmutación por recuperación. La recuperación por recuperación se considera un proceso de restauración de la aplicación en un estado de conmutación por error a su estado original, que es el que tenía antes del error. El tercer uso importante del clúster de automatización es gestionar de forma inteligente la conmutación por error. La conmutación por error en una arquitectura de alta disponibilidad,  significa la capacidad del sistema de cambiar servicios esenciales, como servicios de base de datos y servicios SVN, automáticamente a un servidor de base de datos en espera o, a veces, a un servidor SVN. Y, por último, se trata de gestionar la degradación y la redundancia elegantes. Cuando el proceso de degradación es elegante, permite que las dependencias del clúster funcionen correctamente en un nodo primario degradado, mientras que se utiliza la redundancia para evitar un punto único de falla.

Cláusulas EXCEPT y EXISTS en SQL

Claúsula EXCEPT

Devuelve cualquier valor distinto del conjunto de datos a la izquierda del operador EXCEPT que no sea también devuelto desde el conjunto de datos correcto.

Ejemplos

Selecciona el conjunto de datos excepto cuando los valores estén en este otro conjunto de datos

 --los esquemas del conjunto de datos deben de ser idénticos

 SELECT 'Conjunto1' as 'Columna' UNION ALL

SELECT 'Conjunto2 as 'Columna' UNION ALL

SELECT 'Conjunto3' as 'Columna' UNION ALL

SELECT 'Conjunto4' as 'Columna' UNION ALL

SELECT 'Conjunto5' as 'Columna'

EXCEPT

SELECT ' Conjunto3' as 'Columna'

--Devuelve Conjunto1, Conjunto2, Conjunto4, y Conjunto5

Bloques de ejecución

Utilizando BEGIN ... END

BEGIN

UPDATE Empleados SET Numero_telefono = '5551234567' WHERE Id = 1;

UPDATE Empleados SET Salario = 650 WHERE Id = 3;

END

Cláusula EXISTS 

Ejemplo

Tabla clientes

Id Nombre Apellido

1 Mariano García

2 José Pérez

3 Antonia López 

Tabla Pedidos

Id Cliente Id Cantidad

1 2 123.50

2 3 14.80

Devuelve todos los clientes que han realizado al menos una compra

SELECT * FROM Clientes WHERE EXISTS (

SELECT * FROM Pedido WHERE Pedidos_Cliente.IdCliente=Clientes.Id)

Resultadome

2 José Pérez

3 Antonia López

Obtener los clientes sin pedidos

SELECT * FROM Clientes WHERE NOT EXISTS (

SELECT * FROM Pedidos WHERE Pedidos.IdCliente = Clientes.Id)

 Resultadome

1 Mariano García

 EXISTS, IN y JOIN podrían usarse en algún momento para obtener el mismo resultado, sin embargo, no son iguales:

 EXISTS debe usarse para verificar si existe un valor en otra tabla

 IN debe usarse para una lista estática

 JOIN debe usarse para recuperar datos de otra(s) tabla(s)