sábado, 15 de febrero de 2025

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.

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

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.

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

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.

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

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.

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

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.

 

sábado, 1 de febrero de 2025

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)

Cláusulas EXPLAIN and DESCRIBE


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.

sábado, 18 de enero de 2025

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.

Curso de DevOps: Relaciones, dependencias y políticas

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.

Curso de DevOps: Relaciones, dependencias y políticas


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.

Curso de DevOps: Relaciones, dependencias y políticas


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.

sábado, 4 de enero de 2025

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

Cláusulas EXCEPT y EXISTS en SQL


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)

 

 

sábado, 14 de diciembre de 2024

Curso de DevOps: Automatización V. Sistemas de Automatización Multiplataforma

 Vamos a enumerar las características clave que deben tenerse en cuenta al configurar un sistema de automatización multiplataforma centrándonos en los componentes de gestión central y de extremo a extremo. Configurar la automatización en la que intervienen múltiples plataformas es un desafío. Necesitamos comprender ciertas características críticas de la automatización multiplataforma que nos ayudarán a adoptar el enfoque y el flujo de trabajo correctos para gestionarlo. La primera característica que obtenemos es la alta disponibilidad y el seguimiento de los recursos. En segundo lugar, deberíamos centrarnos en la automatización basada en políticas, porque tenemos múltiples sistemas cuyo impacto se reflejará en la automatización. También debemos planificar el reinicio automático de los recursos fallidos, porque cuando se tienen múltiples plataformas, monitorear y tomar medidas manualmente se vuelve difícil. Esta es la razón por la que necesitamos dotar a nuestro sistema de capacidad para proporcionar reinicio automático de recursos fallidos.

 

Sistemas de Automatización Multiplataforma

La automatización multiplataforma también proporciona la capacidad de gestionar la relación entre recursos en todo el clúster para ayudarnos a configurar la agrupación vertical y la agrupación horizontal para aprovechar los recursos disponibles. Y, por último, la automatización multiplataforma permite una verdadera automatización de aplicaciones empresariales.

 

Sistemas de Automatización Multiplataforma

Necesitamos un motor de automatización que interprete el script de automatización y lo ejecute en tiempo de ejecución. También necesitamos un administrador de automatización de un extremo a extremo para garantizar que se capture el estado de cada paso de la automatización. Una consola de operaciones para invocar la automatización o início rápido, que no están programadas pero necesitan ser disparadas. Necesitamos centrarnos en la automatización de la base de datos. También es necesario derivar una política adecuada para la automatización. Y, por último, es necesario tener un adaptador de automatización de un extremo a otro. Necesitamos un adaptador de automatización de un extremo a extremo para integrar dos plataformas diversificadas entre sí.

 

Sistemas de Automatización Multiplataforma

Vamos a ver la  arquitectura de automatización multiplataforma. Para ello tomaremos como ejemplo un servidor de aplicaciones que se utiliza para la implementación de aplicaciones. Tendremos un navegador cliente, este necesita una consola de solución integrada, que también se denomina consola de operaciones. Necesitamos un administrador de automatización, que asuma la responsabilidad de la automatización de un extremo a otro comunicándose con un adaptador de automatización de extremo a extremo, que ayuda a integrar todas las herramientas de terceros al servidor de aplicaciones existente, donde tenemos nuestra aplicación, que puede necesitar sistemas externos.

El servidor de aplicaciones se comunicará con el motor de automatización. Y el motor de automatización leerá la política de automatización y ejecutará el script de automatización para garantizar que cualquier tarea que se suponía automatizada lo esté. La base de datos capturará los detalles esenciales que se requieren para la automatización.

  

Sistemas de Automatización Multiplataforma

Finalmente, veremos el caso de automatización multiplataforma. El usuario utilizará la consola de operaciones para comunicarse con el dominio de automatización, que contiene componentes como el administrador de automatización de un extremo a otro, el motor de automatización y el adaptador de recursos. Tendremos políticas de automatización y pasos de automatización que también formarán parte del dominio de automatización. El uso del adaptador de recursos se comunicará con multiplataformas, que se representan en la exhibición en forma de Nodo A, Nodo B y Nodo N, donde cada nodo tendrá un adaptador de automatización de extremo a extremo para comunicarse con el adaptador de automatización que está presente en el dominio de automatización.  El nodo B también tendrá los mismos componentes que se encuentran en el nodo A. Pero sí, todos se comunicarán entre sí en forma de un clúster para brindar facilidad de conmutación por error y equilibrio de carga.

 

 

sábado, 7 de diciembre de 2024

Cláusula DELETE y DROP en SQL

Cláusula DELETE

La cláusula DELETE se utiliza para borrar filas de una tabla.

Syntaxis

DELETE FROM Nombre_Tabla [WHERE Condicion] [LIMIT cuenta]

Ejemplos

Borrar determinadas filas con WHERE

Esto eliminará todas las filas que coincidan con los criterios WHERE.

DELETE FROM Empleados WHERE FNombre = 'Juan';

Borrar todas las filas

Omitir la cláusula WHERE eliminará todas las filas de una tabla.
DELETE FROM Empleados;
Consultar la documentación de TRUNCATE para obtener detalles sobre cómo 
se puede mejorar el rendimiento de TRUNCATE. Porque esta cláusula 
ignora los triggers, los índices y los log para simplemente eliminar 
los datos.

Cláusula DELETE y DROP en SQL

Cláusula TRUNCATE

Utilízaremos TRUNCATE para restablecer la tabla a la condición en la que se creó. Esto elimina todas las filas y se restablecen los valores como el incremento automático. Tampoco registra en un log la eliminación de cada fila individual.

TRUNCATE TABLE Empleados;

Borrar determinados registros basándose en comparaciones con otras tablas

Es posible eliminar datos de una tabla si coinciden (o no coinciden) con ciertos datos de otras tablas. Supongamos que queremos eliminar datos del origen una vez cargados en el destino.

DELETE FROM Tabla_Origen WHERE EXISTS ( SELECT 1 --(no importa el valor específico en la query) FROM Tabla_Destino WHERE Tabla_Fuente.ID = Tabla_Destino.ID )

Permite que las tablas se unan durante la ejecución del DELETE, lo que permite una comparación más compleja en una sintaxis compacta. Para agregar complejidad al escenario original, supongamos que añadimos más registros a Tabla_Destino una vez al día y no contienen el mismo ID pero si contienen la misma fecha. Supongamos también que queremos eliminar los datos de la Tabla_Fuente solo después de que se complete el agregado del día:

DELETE FROM Tabla_Fuente WHERE Tabla_Fuente.ID = EsquemaDestino.Tabla_Destino.ID

AND EsquemaDestino.Tabla_Destino.Fecha = EsquemaAgregado.Tabla_Agregado.Fecha

Básicamente, esto da como resultado un INNER JOIN entre el origen y el destino añadido. La eliminación es realizada en el origen cuando existen los mismos ID en el destino Y la fecha presente en el destino para esos ID también existe en el destino agregado. También se puede escribir la misma consulta como:

DELETE Tabla_Fuente FROM Tabla_Fuente, EsquemaDestino.Tabla_Destino, EsquemaAgregado.Tabla_Agregado WHERE Tabla_Fuente.ID = EsquemaDestino.Tabla_Destino.ID AND EsquemaDestino.Tabla_Destino.Fecha = EsquemaAgregado.Tabla_Agregado.Fecha

Se pueden mencionar uniones explícitas en declaraciones de eliminación  y diseñar comparaciones para verificar escenarios que no coinciden en lugar de hacer coincidir aquellos con todos. (Ver el  NOT EXIST a continuación)

DELETE FROM Tabla_Fuente

WHERE NOT EXISTS ( SELECT 1 – el valos especifico en la SELECT no importa

FROM Tabla_Destino WHERE Tabla_Fuente.ID = Tabla_Destino.ID )

Es posible eliminar datos de una tabla si coinciden (o no coinciden) con ciertos datos de otras tablas. Supongamos que queremos eliminar datos del origen una vez cargados en el destino.

DELETE FROM Fuente WHERE EXIST (SELECT 1 FROM Destino WHERE 
Fuente.ID = Destino.ID) 
Las tablas se unirán durante el borrado, lo que permitirá una comparación
 más compleja en una sintaxis compacta.
Para agregar complejidad al escenario original, supongamos queremos 
añadir a la tabla Destino los registros de la Fuente de forma automática una
 vez al día mediante una tabla Agregado y no contiene el mismo ID pero 
contiene la misma fecha. Supongamos también que queremos eliminar los datos de la tabla 
Fuente solo después 
de que se complete el agregado del día;
Esto se puede hacer usando:
DELETE FROM Fuente WHERE Fuente.ID = EsquemaDestino.Destino.ID
AND EsquemaDestino.Destino.Fecha = EsquemaAgregado.Agregado.Fecha
Básicamente, esto da como resultado INNER JOINS entre Fuente, Destino y 
Agregado. La eliminación es realizada en el origen cuando existen
 los mismos ID en el destino y para la fecha actual en el destino para esos ID también existe en la
 tabla Agregado. También se puede escribir la misma consulta 
DELETE Tabla_Fuente
FROM  Tabla_Fuente, EsquemaDestino.Tabla_Destino, EsquemaAgradado.Tabla_Agregado
WHERE Tabla_Fuente.ID = EsquemaDestino.Tabla_Destinot.ID
AND EsquemaDestino.Tabla_Destino.Fecha = EsquemaAgregado.Tabla_Agregado.Fecha
Se pueden mencionar uniones explícitas en declaraciones de eliminación 
Se pueden diseñar comparaciones para verificar escenarios que no coinciden en lugar de hacer
coincidir aquellos con todos. (observar NOT EXIST a continuación)
DELETE FROM Tabla_Fuente
WHERE NOT EXIST (SELECT 1 --: el valor específico en SELECT no importa
FROM Tabla_Detino
WHERE Tabla_Fuente.ID = Tabla_Destino.ID)

 DROP o DELETE Database

DROP DATABASE [IF EXISTS] {nombre_basedatos| nombre_captura_basedatos } [ ,...n ] [;]

Comentarios

Se utiliza para eliminar una base de datos de SQL. Es necesario asegurarse de crear una copia de seguridad de la base de datos antes de eliminarla para evitar la pérdida accidental de información.

Ejemplos

DROP Database

Eliminar la base de datos es una simple declaración de una sola línea; eliminará la base de datos, por lo tanto, es necesario asegurarse siempre de tener una copia de seguridad de la base de datos si es necesario. A continuación se muestra el comando para eliminar la base de datos de empleados

DROP DATABASE dbo.Empleados

DROP Table

DROP TABLE elimina la definición de la tabla del esquema junto con las filas, índices, permisos y triggers.

Ejemplos

Drop Table Nombre_Tabla;

Chequea la existencia de claves foráneas antes del borrado, si encuentra alguna devolverá un error.