Equation Chapter 1 Section 1
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Estandarización de Sistemas Operativos Linux:
Herramientas de Gestión y Ciclo de Vida
Autor: Miguel Ángel Romo Moruno
Tutor: Rafael María Estepa Alonso
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
3
Proyecto Fin de Carrera
Ingeniería de Telecomunicación
Estandarización de Sistemas Operativos Linux:
Herramientas de Gestión y Ciclo de Vida
Autor:
Miguel Ángel Romo Moruno
Tutor:
Rafael María Estepa Alonso
Profesor titular
Dep. Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 20185
Proyecto Fin de Carrera: Estandarización de Sistemas Operativos Linux: Herramientas de Gestión y Ciclo de Vida
Autor: Miguel Ángel Romo Moruno Tutor: Rafael María Estepa Alonso
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
6
7
9
Contenido
ÍNDICE DE FIGURAS ... 13
1 Introducción ... 17
2 Objetivos y Metodología ... 19
2.1 Estructura del Proyecto ... 20
3 Estado de la Tecnología ... 23
3.1 Necesidad de Estandarización ... 23
3.2 Pasos para definir un SOE ... 25
3.2.1 Definir un mapa físico y lógico de la infraestructura ... 25
3.2.2 Definir la Biblioteca de Medios Definitiva ... 25
3.2.3 Definir los Entornos del Ciclo de Vida ... 26
3.2.4 Definir el Core Build ... 26
3.2.5 Definir contenido de aplicaciones ... 26
3.2.6 Automatizar el aprovisionamiento ... 26
3.2.7 Definir roles del departamento de TI ... 27
3.2.8 Gestion Continua del Contenido del Ciclo de Vida... 27
3.2.9 Automatización, escalabilidad y mejora continua ... 27
3.3 Tareas a Gestionar ... 27
3.3.1 Gestión de la Biblioteca de Medios Definitiva ... 27
3.3.2 Gestión del Entorno del Ciclo de Vida ... 28
3.3.3 Gestión de la Configuración ... 28
3.3.4 Gestión del Aprovisionamiento ... 29
3.3.5 Gestión de Actualizaciones ... 30
3.3.6 Gestión de la Seguridad ... 30
4 Estandarización de Sistemas Linux con Red Hat Satellite ... 31
4.1 Descripción y alcance de la herramienta de gestión Red Hat Satellite ... 31
4.1.1 Componentes ... 31
4.1.2 Integración y automatización ... 32
4.1.3 Gestión centralizada ... 32
4.2 Entorno Operativo Estandar basado en Red Hat Satellite 6 ... 33
4.2.1 Repositorios de software ... 33
4.2.1.1 Almacenamiento de Repositorios ... 33
4.2.1.2 Sincronizador de Repositorios ... 33
4.2.1.3 Presentación de Repositorios ... 34
4.2.1.4 Registro de sistemas a Repositorios ... 36
4.2.1.5 Gestión de paquetes de Repositorios ... 36
4.2.2 Gestión de la Configuración ... 36
4.2.2.1 Sistemas de Repositorios de Objetos de Configuración ... 36
4.2.2.2 Categorizador de sistemas y Objetos de configuración ... 37
4.2.2.3 Sistema de envío de Objetos de configuración ... 38
4.2.2.4 Aplicación de configuración ... 38
4.2.2.5 Sistema de informes de ejecución de configuación ... 39
4.2.3 Relación entre componentes ... 40
4.2.4 Automatización de despliegue y aprovisionamiento ... 41
4.2.4.1 Métodos de aprovisionamiento ... 41
4.2.4.2 Proceso de aprovisionamiento y despliegue ... 42
4.2.5 Auditoría de Suscripciones, Inventario y Compliance ... 44
10
4.2.5.2 Inventario de sistemas ... 44
4.2.5.3 Gestión de la seguridad y compliance ... 45
4.2.6 Gestión de actualizaciones y erratas... 47
4.3 Versionado de Satellite y ciclo de actualizaciones ... 48
5 Estandarización de Sistemas Operativos con Herramientas de Software Libre ... 51
5.1 Gestión de sistemas con Foreman y Katello ... 52
5.1.1 Foreman ... 52
5.1.2 Katello ... 52
5.2 Gestión de la configuración con Puppet y Ansible ... 53
5.2.1 Puppet ... 53
5.2.2 Ansible ... 54
5.3 Gestión de la Seguridad con OWASP Zap, OpenVAS y Metasploit Framework Community ... 54
5.3.1 OWASP Zap ... 54
5.3.2 OpenVAS ... 55
5.3.3 Metasploit Framework Community ... 55
6 Elección de la Tecnología ... 57
7 Implantación de Red Hat Satellite ... 59
7.1 Preparación del servidor y configuración previa ... 59
7.1.1 Creación de una máquina virtual para Satellite ... 59
7.1.2 Instalación del Sistema Operativo ... 59
7.1.3 Configuración previa del servidor ... 60
7.1.3.1 Particionado ... 60
7.1.3.2 Configuración del firewall ... 62
7.1.3.3 Verificación de resolución DNS ... 63
7.1.3.4 Sincronización de hora ... 63
7.2 Instalación y configuración inicial de Satellite ... 63
7.2.1 Registro del servidor e instalación de paquetes ... 63
7.2.1.1 Registro del servidor con Subscription Manager ... 63
7.2.1.2 Instalación de paquetes de Satellite ... 64
7.2.2 Instalación de Satellite ... 64
7.2.3 Creación e instalación del Manifiesto ... 65
7.2.4 Envío de notificaciones por correo ... 65
7.3 Implementación del Core Build... 66
7.3.1 Activación y Sincronización de Respositorios ... 66
7.3.2 Creación de Content Views ... 68
7.3.3 Creación de Lifecycle Environments ... 71
7.3.4 Creación de Activation Keys ... 71
7.3.5 Creación de Host Groups ... 73
7.3.5.1 Nivel 1 (Entornos de Ciclo de Vida) ... 74
7.3.5.2 Nivel 2 (Versión de Sistema Operativo) ... 74
7.4 Registro de Servidores en Satellite ... 75
7.4.1 Registro de un servidor RHEL 7.2 x86_64 ... 75
7.5 Gestión de la configuración con Puppet ... 77
7.5.1 Creación de entornos de Puppet ... 77
7.5.2 Carga de módulos de Puppet en Satellite ... 78
7.5.3 Configuración de clases de Puppet ... 79
7.5.3.1 motd ... 79
7.5.3.2 resolv.conf ... 80
7.5.4 Aplicación de configuración a clientes ... 81
7.6 Aprovisionamiento de servidores con Satellite... 82
11
7.6.2 Creación de una subred ... 83
7.6.3 Creación de plantillas ... 84
7.6.3.1 Plantillas de particionado ... 84
7.6.3.2 Plantillas de aprovisionamiento ... 86
7.6.3.3 Configuración de parámetros globales para le Aprovisionamiento ... 87
7.6.4 Asignación de plantillas a Sistemas Operativos ... 88
7.6.5 Creación de Host Group para despliegues ... 88
7.6.6 Aprovisionamiento mediante Boot ISO ... 92
7.6.6.1 Creación del host ... 92
7.6.6.2 Generación de imagen de arranque ... 96
7.6.7 Aprovisionamiento mediante PXE-less Discovery ... 97
7.6.7.1 Instalación de paquetes y configuración de kexec ... 97
7.6.7.2 Arranque del Servidor y Configuración de Parámetros de Red ... 97
7.7 Informes de Seguridad SCAP ... 98
7.7.1 Instalación de paquetes OpenSCAP en Satellite ... 99
7.7.2 Carga del contenido OpenSCAP en Satellite ... 99
7.7.3 Importar módulos de Puppet de OpenSCAP en Satellite ... 100
7.7.4 Creación de una nueva política ... 100
7.7.5 Añadir una política a un host ... 101
7.7.6 Visualización de Informes de Seguridad ... 101
8 Conclusiones y líneas de avance ... 105
9 Bibliografía... 107
Documentos ... 107
13
Í
NDICE DE
F
IGURAS
Figura 3-1. Diagrama de bloques para el aprovisionamiento de sistemas 29 Figura 3-2. Objetivos adicionales en el aprovisionamiento de sistemas 30
Figura 4-1. Componenetes de Satellite 31
Figura 4-2. Gestión centralizada de Organizaciones y Localizaciones 33
Figura 4-3. Repositorios en Satellite 34
Figura 4-4. Versiones de Content Views 35
Figura 4-5. Tipos de Content Views 35
Figura 4-6. Entornos de Ciclo de Vida 35
Figura 4-7. Arquitectura de Puppet 39
Figura 4-8. Informe de Puppet 40
Figura 4-9. Mapa de la relación de componentes de Satellite 41
Figura 4-10. Procceso de aprovisionamiento 42
Figura 4-11. Flujo de aprovisionamiento en Satellite 43
Figura 4-12. Relación de bloques de Satellite para el aprovisionamiento 43
Figura 4-13. Dashboard de suscripciones 44
Figura 4-14. Dashboard de estado de los hosts 45
Figura 4-15. Contenido SCAP 45
Figura 4-16. Informes de cumplimiento de reglas SCAP 46
Figura 4-17. Detalle de informes SCAP 47
Figura 4-18. Gestión de actualizaciones 47
Figura 4-19. Visualización del número de actualizaciones en Content Views 48
Figura 4-20. Detalle de tarea de aplicación de actualizaciones 48
Figure 5-1. Componentes de OpenVAS 55
Figura 7-1. Carga de Manifiesto de Suscripciones en Satellite 65
Figura 7-2. Activación de Repositorios 67
Figura 7-3. Detalle del plan de sincronización 68
Figura 7-4. Productos asociados al plan de sincronización 68
14
Figura 7-6. Versionado de Conent Views 70
Figura 7-7. Promoción de un Content View a un Entorno 70
Figura 7-8. Ruta de Entonos de Ciclo de Vida 71
Figura 7-9. Parámetros de una Activation Key 72
Figura 7-10. Suscripciones asociadas a una Activation Key 72
Figura 7-11. Repositorios asociados a una Activation Key 73
Figura 7-12. Formas de organizar los host groups 73
Figura 7-13. Host Groups jerárquicos 74
Figura 7-14. Menú de acceso a Certificados de servidores 76
Figura 7-15. Firma del Certificado de un servidor 77
Figura 7-16. Detalle de parámetros de un host registrado en Satellite 77
Figura 7-17. Entornos de Puppet en Satellite 78
Figura 7-18. Carga de nuevos módulos a un entorno de puppet 79
Figura 7-19. Clases de puppet 79
Figura 7-20. Modificación del parámetro content de la clase motd 80
Figura 7-21. Modificación del parámetro nameservers de la clase resolv_conf 81 Figura 7-22. Modificación del parámetro searchpath de la clase resolv_conf 81
Figura 7-23. Aplicación de clases de puppet a un host 82
Figura 7-24. Creación de un Dominio en Satellite 82
Figura 7-25. Visualización del Dominio creado en Satellite 83
Figura 7-26. Creación de una subred en Satellite 84
Figura 7-27. Visualización de la subred creada en Satellite 84
Figura 7-28. Asociación de una plantilla de particionado a una Organización 86 Figura 7-29. Asociación de un sistema operativo a una plantilla de aprovisionamiento 87
Figura 7-30. Parámetro Global creado en Satellite 87
Figura 7-31. Selección de la plantilla de particiones en un sistema operativo 88 Figura 7-32. Selección de plantilla de aprovisionamiento en un sistema operativo 88
Figura 7-33. Creación de un nuevo host group 89
Figura 7-34. Selección de clases de puppet en un host group 89
Figura 7-35. Selección de red en un host group 90
Figura 7-36. Selección de sistema operativo en un host Group 90
Figura 7-37. Selección de parámetros en un host group 91
Figura 7-38. Selección de Localización en un host group 91
Figura 7-39. Selección de Organización en un host group 91
Figura 7-40. Selección de activation key en un host group 92
Figura 7-41. Creación de un nuevo host para aprovisionar 93
Figura 7-42. Selección de clases de puppet asociadas a un host 93
15
Figura 7-44. Interfaz de red de un nuevo host 94
Figura 7-45. Selección de sistema operativo en un nuevo host 95
Figura 7-46. Selección de parámetros de un nuevo host 95
Figura 7-47. Parámetros adicionales en un nuevo host 96
Figura 7-48. Generación de la imagen de aprovisionamiento de un host 96
Figura 7-49. Selección de kexec para PXE-less Discovery 97
Figura 7-50. Reglas de descubrimiento para aprovisionar un host 98
Figura 7-51. Menú de cumplimiento SCAP 99
Figura 7-52. Contenido SCAP disponible en Satellite 99
Figura 7-53. Clases de puppet de SCAP 100
Figura 7-54. Nueva política SCAP 101
Figura 7-55. Asignación de una política a un host 101
Figura 7-56. Informes de SCAP en Satellite 102
Figura 7-57. Detalle de informe SCAP de un servidor 102
17
1
I
NTRODUCCIÓN
oy en día, la evolución de la tecnología y los sistemas de información han dado lugar a la existencia de complejas infraestructuras y granjas de servidores de gran tamaño y capacidad, que almacenan datos de distinta naturaleza y ofrecen diversos tipos de servicios para su explotación por parte de empresas, organismos públicos o usuarios finales.
La administración manual e individualizada de una infraestructura que cuenta con un gran número de servidores, del orden de cientos o miles, tiene un elevado coste no sólo económico, sino de recursos técnicos y esfuerzo de profesionales que se dedican a su gestión. Este esfuerzo dedicado a tareas de gestión clásicas, impide utilizar el tiempo y personal necesarios para mejorar procedimientos y revisar indicadores, por lo cual no es posible acometer tareas de mejora continua que hacen que un departamento o equipo de personas evolucione, efectúe sus tareas y resuelva los problemas de forma cada vez más eficaz.
A la hora de administrar y gestionar estos sistemas, cada vez se hace más necesario el uso de metodologías eficientes y la aplicación de procedimientos adecuados por parte de los administradores y equipos de TI, que eviten la realización de tareas repetitivas, disminuyan la probabilidad de error en la administración de los sistemas debidas al factor humano y aumenten la seguridad y disponibilidad de la infraestructura.
Los equipos de TI que deben administrar centros de datos con gran número de servidores se enfrentan, entre otros, a dos problemas derivados de la gestión clásica de pequeñas infraestructuras, como son la escasa automatización y la ejecución de tareas repetitivas. Estos problemas provocan una falta evidente de eficiencia, un mal aprovechamiento de los recursos técnicos y humanos, ventanas de mantenimiento de larga duración, que en determinados entornos productivos puede llegar a no ser admisible, y una probabilidad de error en la ejecución de procedimientos y manuales de actuación innecesariamente alta.
Una gestión de sistemas moderna y actual debe enfocar los esfuerzos en conseguir un ecosistema lo más homogéneo posible, y disponer de un número no muy elevado de herramientas o consolas centralizadas desde las que acometer las distintas tareas de forma coordinada, controlada, automática y segura.
H
La enseñanza que deja huella no es la que se hace de cabeza a cabeza, sino de corazón a corazón.
19
2
O
BJETIVOS Y
M
ETODOLOGÍA
l presente Proyecto pretende mostrar distintas herramientas que nos ayudarán a gestionar el ciclo de vida completo de sistemas Linux.
En primer lugar, se añanizará la herramienta Red Hat Satellite, identificando los distintos proyectos que la conforman, y cómo se integran en una sola consola desde la que podemos realizar cualquier tarea de adiministración.
En segundo lugar, se describirán distintas herramientas open source con las que podemos realizar operaciones relacionadas con cada uno de los aspectos del ciclo de vida de servidores, dejando en manos de los administradores de sistemas la relación y compenetración entre ellas.
De este modo, abarcaremos la gestión de sistemas Linux, desde su creación hasta su etapa final, lo cual proporcionará un mejor aprovechamiento de los recursos técnicos y de personal, con el consiguiente ahorro económico, disminución de los tiempos de actuación y de respuesta ante incidencias, así como una mayor disponibilidad de los servicios que albergan los servidores.
Se va a definir una estrategia de gestión capaz de dar respuesta a las necesidades de unos centros de datos que cuentan cada vez más con un mayor número de servidores, diferenciando distintas etapas en el ciclo de vida de los sistemas, desde su aprovisionamiento, configuración, tiempo durante el que ofrece un determinado servicio, ya sea en el ámbito de desarrollo, pruebas o producción, y fase final o retirada del servidor.
Para conseguirlo, debemos centrar esfuerzos en la estandarización de los sistemas, mediante la creación de una línea base común sobre la que se implementarán y configurarán los distintos servicios, permitiendo una diversidad de configuraciones y posibilidades partiendo de un marco común.
Los objetivos que se pretenden conseguir con la estandarización son los siguientes:
Misma configuración base de los sistemas, obteniendo entornos más homogéneos y minimizando las paradas de servicio y errores derivados de la configuración inicial.
Optimización de los procesos de despliegue de nuevos servidores y gestión de la configuración.
Reducción de errores al implantar una gestión de cambios con control de versiones.
Simplificación de las tareas de administración de los sistemas.
Ahorro de tiempo y gestión de recursos más eficiente, obteniendo una mayor productividad del personal técnico.
20
Aplicación controlada de actualizaciones y parches de seguridad, evaluando el impacto y prioridad antes de su instalación.
2.1
Estructura del Proyecto
El trabajo está estructurado en una serie de apartados, donde se desarrollarán, en primer lugar, los conceptos teóricos esenciales que debemos tener en cuenta a la hora de gestionar de sistemas, tales como la necesidad de estandarización y cómo definir un Entorno Operativo Estándar (SOE), detallando los conceptos y alcance de los elementos involucrados.
Posteriormente, se describirán las tareas principales que debemos gestionar en cuanto a la administración de sistemas, donde podremos tener una visión general de las necesidades a cubrir.
A continuación, se estudiarán distintas herramientas para gestionar todos los elementos definidos. Se analizará una solución privativa como Satellite, que integra diferentes proyectos Open Source, disponible a través del modelo de suscripciones de la compañía Red Hat, así como distintas aplicaciones Open Source que pueden ser utilizadas de forma independiente, y cuya orquestación caerá bajo la responsabilidad del administrador. Con estas herramientas cubriremos las necesidades de gestión en cada una de las etapas del ciclo de vida de los sistemas.
Una vez analizadas las distintas herramientas, se justificará por cuál nos decantamos, destacando los puntos fuertes y débiles de cada uno de los casos dependiendo de la infraestructura y entorno donde se vaya a utilizar. Se detallará una implantación de la tecnología elegida, desde la implantación a la definición de todas las configuraciones y parámetros necesarios para sacar todo el provecho a la herramienta.
Para finalizar, describiremos las conclusiones y líneas de avance de proyecto. Pasamos a enumerar los apartados que conforman el Proyecto:
Estado de la tecnología
o Necesidad de estandarización
o Pasos para definicinir un SOE
o Tareas a Gestionar
Gestión de la Biblioteca de Medios Definitiva Gestión de los Entornos del Ciclo de Vida Gestión del Aprovisionamiento
Gestión de la Configuración Gestión de Actualizaciones Gestión de la Seguridad
Estandarización de Sistemas Linux con Red Hat Satellite
o Descripción y alcance de la herramienta de gestión Red Hat Satellite
o Entorno Operativo Estandar basado en Red Hat Satellite
o Repositorios de software
o Gestión de la Configuración
o Relación entre Componentes
o Automatización de Despliegue y Aprovisionamiento
o Auditoría de Suscripciones, Inventario y Compliance
21
Estandarización de Sistemas Linux con herramientas Open Source
o Gestión de sistemas con Foreman y Katello
o Gestión de la configuración con Puppet y Ansible
o Gestión de la Seguridad con OWASP Zap, OpenVAS y Metasploit Framework Community
Elección de la Tecnología
Implantación de Red Hat Satellite
o Preparación del servidor y configuración Previa
o Instalación y configuración inicial de Satellite
o Implementación del Core Build
o Registro de servidores en Satellite
o Gestión de la configuración con Puppet
o Aplicación de módulos de Puppet a clientes
o Informes de Seguridad SCAP
23
3
E
STADO DE LA
T
ECNOLOGÍA
ctualmente, ante la gran variedad de sistemas operativos y versiones, configuraciones hardware de los servidores y herramientas de gestión de software, la administración de los sistemas e infraestuctura se hace difícil en el mejor de los casos. Esta complejidad requiere un amplio departamento de TI con el personal y el nivel de experiencia adecuado en todas las áreas del entorno, lo cual implica un incremento en los costes.
Además, estos desafíos en la gestión suponen mayores tiempos de pérdida de servicio ante operaciones de mantenimiento, lo cual supone un menor control de los recursos disponibles y los servicios a controlar. Estos problemas también incrementan los riesgos a la hora de cumplir con la normativa y protocolos de seguridad. Cuando tenemos múltiples procedimientos para cada configuración o versión de sistema operativo, las tareas de aprovisionar nuevas herramientas, aplicaciones, máquinas virtuales y servidores se hacen lentas e impiden una operativa de TI ágil, afectando al negocio.
3.1
Necesidad de Estandarización
Podemos reducir toda esta problemática o incluso eliminarla disminuyendo la complejidad y estandarizando parte o todo el entorno de TI en un conjunto de procesos y procedimientos. Con un Entorno Operativo Estándar (SOE, Standard Operating Environment), aumentando la escalabilidad y productividad del personal de TI. Como el coste de cada tarea influye en el coste total de TI, aumentar la eficiencia y la productividad supondrá un ahorro y un TCO (total cost of ownership) más bajo. Un entorno operativo estándar (SOE) también mejorará la productividad en términos de una mayor disponibilidad de los servicios y menores tiempos de mantenimiento. Mediante procedimientos y procesos de operaciones estandarizados, las aplicaciones, máquinas virtuales y el hardware pueden será aprovisionados y configurados de forma rápida, aumentando la escalabilidad, flexibilidad, agilidad y productividad. Además, reducir la complejidad de la infraestructura nos permitirá tener un mayor control de los recursos de TI, aumentando la seguridad y reduciendo los riesgos.
La estandarización supone aumentar la consistencia y reducir la complejidad dentro de un entorno operativo. Un SOE ideal definiría una serie de componentes, interfaces y procesos que serían utilizados por toda la infraestructura de TI. Como es lógico, la estandarización no supone que todos los sistemas sean iguales, sino que los sistemas tendrán unos fundamentos definidos y conocidos a partir de los cuales se pueden instalar aplicaciones, crear máquinas virtuales o utilizar herramientas.
Por lo tanto, la estandarización se centra en tres áreas principales:
Simplificar la infraestructura de TI.
Automatización.
24
Optimización de la gestión y tareas de administración. Enumeramos las ventajas que supone la estandarización:
Infraestructura consistente y simplificada
El objetivo de la estandarización es aumentar la consistencia y reducir la complejidad. Definir los fundamentos de todos los sitemas y simplificar la infraestructura y operaciones.
Debemos tener cuidado de no aplicar esta regla al límite, lo cual nos puede llevar a tener procesos pobremente documentados que pueden caer en el olvido, e imposibles e llevar a cabo cuando surge algún problema.
Operaciones optimizadas
Cuando se utiliza un número reducido de versiones de sistema operativo en la infraestructura de TI, es posible definir un conjunto único de procesos y procedimiento de operación, con el fin de simplificar y aumentar la eficiencia de las operaciones.
Automatización
La automatización reduce el esfuerzo y el tiempo dedicado a aprovisionar nuevos servicios y recursos, aumenta la consistencia a lo largo de los entornos y permite que una plantilla con no más personal del necesario gestione las tareas del día a día.
Reducción del tiempo de parada
Tener un número reducido de Sistemas Operativos disminuye la probabilidad de incidencias debidas a operaciones y de seguridad que puedan causar paradas de servicio. Al tener una infraestructura consistente, la aplicación de buenas prácticas de gestión supone poder anticiparnos a las incidencias antes de que ocurran y ocasionen la caída de sistemas y aplicaciones.
La aplicación de actualizaciones y parches de seguridad de forma simplificada, al haber menos variedad de versiones, nos asegura que los sistemas siempre estarán actualizados y online de una forma más fácil y menos costosa.
Costes de operaciones más bajo
Cada tarea tiene un peso en el coste total de TI, por lo que al aumentar la eficiencia y productividad del personal supone un ahorro de costes y un TCO más bajo.
Aumentar la eficiencia de la plantilla de TI optimizando operacione y procesos permite que un menor número de personas administre un mayor número de sistemas físicos y virtuales de forma más fácil y eficiente.
Aumentar la productividad
Al poder encargarse cada administrador de un mayor número de servidores y usuarios, la infraestructura puede crecer y escalar sin aumentar el número de administradores más de lo necesario.
Reducir carga de trabajo a nivel de soporte
Al ofrecer mejores servicios el número de incidencias de soporte técnico se reduce, disminuyendo también el tiempo dedicado a ellas, por lo que de nuevo aumenta la productividad.
El tiempo de repuesta se ve reducido al automatizar procedimientos. Es posible aprovisionar aplicaciones en un mayor número de sistemas dedicando una fracción de tiempo del que se necista si se realizara de forma manual.
Incrementar la seguridad y control sobre la infraestructura
Una buena estrategia de seguridad va más allá de un simple sistema de autenticación centralizado en un sistema de gestión de identidades. La capa de seguridad debe extenderse en todos los aspectos de nuestra infraestructura para aumentar la resistencia a posibles ataques.
25
mucho más sencillo. Un número reducido de variantes de nuestro sistema base nos permite tener un mayor control sobre nuestro entorno y mantener los sistemas actualizados. Una mayor consistencia de nuestra infraestructura nos facilia la interoperatividad y la integración de medidas de seguridad a lo largo de toda la infraestructura.
Sin embargo, demasiada seguridad puede evitar que determinadas personas no tengan acceso a aplicaciones y datos que necesitan, por lo que se debe identificar quién debe tener acceso a qué, y evaluar aplicaciones y datos para controlar los efectos potenciales de un uso no autorizado. Únicamente entonces, podemos definir una política que proporcione un equilibrio entre riesgos y accesibilidad, con el objetivo de mantener la infraestructura segura sin afectar a la productividad del usuario.
Mayor escalabilidad bajo demanda
Los cambios son inevitables, especialmente en TI. A lo largo del ciclo de vida de un servicio, la demanda y carga del mismo puede fluctuar. Si nuestra infraestructura tiene una naturaleza estática y no está preparada para adaptarse, no podremos satisfacer una alta demanda de determinado servicio. Los métodos tradicionales de aprovisionamiento hacen que debamos utilizar numerosos recursos para satisfacer picos o niveles de demanda ocasionales.
Un Entorno Operativo Estándar nos permite escalar nuestra infraestructura y los recursos de forma dinámica. Si nuestros sistemas tienen una línea base común, podrán proporcionar una mayor variedad de servicios en lugar de dedicarse a una aplicación concreta. El mismo recurso podría proporcionar múltiples servicios en momentos diferentes según la demanda. De esta forma, podremos mantener una infraestructura más pequeña y de forma más eficiente, además de disminuir consumos, mejorar refrigeración y reducir costes de las instalaciones.
Mejor alineamiento con negocio y mayor agilidad
El ahorro de tiempo permite al personal de TI centrarse en tareas con el propósito de aumentar sus capacidades ofreciendo más servicios y de mejor calidad, alineándose con los objetivos de negocio de la empresa.
3.2
Pasos para definir un SOE
A continuación se describen los pasos necesarios para definir un Entorno Operativo Estándar.
3.2.1
Definir un mapa físico y lógico de la infraestructura
Debemos tener bien esquematizada la localización física de nuestra infraestructura, así como de la topología lógica de nuestro Datacenter.
Los esquemas deben detallar en la medida de lo possible los siguientes elementos:
Infraestructura física.
Infraestructura virtualizada.
Topología de red: identificar sistemas y direccionamiento de los diferentes segmentos de red.
o Zona LAN: Red de Área Local
o Zona DMZ: Zona Desmilitarizada
Equipos perimetrales.
Electrónica de red.
Dominios de red.
3.2.2
Definir la Biblioteca de Medios Definitiva
26
software del Sistema Operativo como las aplicaciones instaladas porteriormente. Por lo tanto, deben quedar definidos los siguientes puntos:
Paquetería que se va a instalar tanto en servidores como en estaciones de trabajo. Para ello, se definirán los repositorios de paquetes que se van a utilizar, que pueden estar basados en diferentes formatos (rpm, deb…)
Aplicaciones de terceros, o repositorios adicionales, para software específico no incluído en los repositorios base del Sistema.
Plan de sincronización y actualización de la Biblioteca.
Firma digital y cifrado de paquetes (GPG Keys).
3.2.3
Definir los Entornos del Ciclo de Vida
En este punto debemos definir los diferentes entornos que mejor encajen con nuestris sistemas, servicios, políticas... Se debe decider el camino que seguirán nuestros servidores definiendo entornos de Desarrollo, Calidad, Pruebas, Preproducción, Producción…
Teniendo en cuenta que no todos los servidores pasarán por los mismos entornos, se pueden crear distintos caminos con los entornos que más nos convengan para nuestros propósitos. Cada Sistema pertenecerá a un entorno en un momento determinado, no teniendo que pasar necesariamente por todos los entornos de un camino a lo largo de su ciclo de vida.
Cada entorno que definamos tendrá asociada en todo momento una determinada versión de Sistema Operativo y de las aplicaciones que utilizaremos. Las versiones podrán cambiar a lo largo del tiempo.
Esta estructura de caminos, entornos y versiones, nos permitirá dividir nuestras tareas en capas diferentes, por ejemplo, definiendo unos procesos para el Sistema Operativo y otros para las aplicaciones que se ejecutan en él.
3.2.4
Definir el Core Build
Mediante el Core Build definimos la línea base de Sistemas Operativos sobre los que se ejecutarán las aplicaciones.
Además, debemos definir la configuración inicial común que tendrán nuestros sistemas, o crear distintos grupos de configuración si tenemos un número suficiente de servidores con configuraciones communes.
Por lo tanto, la definición del Core Build engloba a los Sistemas Operativos, aplicaciones de terceros y configuración base de nuestros sistemas.
El Core Build no debe entrar en la configuración específica de los servicios de cada sistema, pero sí en los comunes a todos, como pueden ser los servidores DNS, servicio de sincronización de hora, o cualquiera que consideremos que debe entrar en esta categoría.
3.2.5
Definir contenido de aplicaciones
En este punto se definen las diferentes versiones en la capa de aplicación, así como las configuraciones y la forma de integrarlas con el Sistema Operativo. Debemos diferenciar diferentes roles y perfiles y separar responsabilidades entre Sistema Operativo y aplicaciones.
También podemos utilizar grupos de configuración que nos sirvan para organizar mejor los elementos que forman la capa de aplicación.
3.2.6
Automatizar el aprovisionamiento
Debemos configurar el aprovisionamiento automatizado de los Sistemas Operativos, configuraciones iniciales y aplicaciones de terceros definidas en los puntos anteriores.
Dependiendo de la finalidad de cada sistema, podemos agrupar los hosts, y mejorar el aprovisionamiento definiendo plantillas de instalación y tablas de particionado dinámico para cada scenario.
27
Para automatizar el aprovisionamiento podemos utilizar sistemas de arranque e instalación por red, plantillas predefinidas de aprovisionamiento, plantillas de particionado, herramientas de despligue de configuraciones…
3.2.7
Definir roles del departamento de TI
Debemos definir diferentes perfiles en base al modelo RBAC: role-based access control.
Cada rol tendrá una serie de permisos sobre la infraestructura según una matriz de reponsabilidad. El objetivo de esta matriz es reducir la complejidad de las entidades visibles por cada usuario en las herramientas de gestión. También podremos definir grupos de usuarios para perfiles que tengan los mismos permisos.
3.2.8
Gestion Continua del Contenido del Ciclo de Vida
Existen algunos aspectos como las actualizaciones y parches de seguridad, nuevas versiones de software y cambios en configuraciones que requieren de una revision continua.
Se debe definir con qué periodicidad se ejecutarán estas operaciones, ya que habrá entornos menos suscetibles a cambios y actualizaciones (entornos productivos) y otros donde se deberá actualizar con más frecuencia (entornos de pruebas).
3.2.9
Automatización, escalabilidad y mejora continua
Una vez definidos todos los elementos anteriores, nuestra infraestructura debe estar preparada para adaptarse de forma rápida y eficaz a posibles mejoras: inclusion de nuevos hosts, optimización de procesos de TI.
En definitiva, debemos estar siempre abiertos a nuevas ideas que mejoren nuestros procedimientos, y tener la infraestructura suficientemente estandarizada o organizada para adaptarse sin demasiado esfuerzo a cualquier mejora.
3.3
Tareas a Gestionar
A continuación se describe la forma en la que se dará sólución a cada una de las principales tareas en la gestión de los sistemas.
3.3.1
Gestión de la Biblioteca de Medios Definitiva
Los archivos necesarios para que un programa funcione se agrupan en paquetes instalables en el Sistema Operativo. En GNU/Linux estos paquetes son gestionados por terceras aplicaciones, con las cuales podremos realizar cualquier operación necesaria con los mismos. Un programa puede estar formado por uno o varios paquetes, donde residirán ejecutables, librerías, ficheros de configuracion necesarios para el software funcione. Existen normalmente tres formatos o tipos de paquetes en GNU/Linux:
rpm: utilizados en distribuciones basadas en Red Hat, como CentOS, Fedora, Scientific Linux… pueden contener tanto binarios como código fuente.
deb: empleados en distribuciones basadas en Debian, como Ubuntu
tar.gz: código fuente preparado para ser compilado e instalado directamente en el sistema.
Los paquetes se almacenan en repositorios ubicados en servidores accesibles a través de internet, de forma que podemos realizar distintas operaciones sobre ellos a través de los gestores de paquetes.
Cada distribución mantiene sus propios repositorios oficiales, con sus políticas particulares de versiones y actualizaciones, dependiendo de la criticidad de los programas. Por otro lado, existen repositorios no oficiales, que contienen aplicaciones no soportadas directamente por la distribución, pero que pueden funcionar bajo el soporte de los propios desarrolladores de los programas.
Para realizar operaciones con los paquetes almancenados en los repositorios, se utilian los gestores de paquetes. Existen distintos gestores de paquetes según el tipo de paquetes que gestiona. Para el formato deb,
28
principalmente se utiliza el gestor de paquetes apt (Advanced Packaging Tool), mientras que los paquetes rpm se gestionan con la herramienta yum (Yellowdog Updater Modifier).
Las principales operaciones que se pueden realizar con los gestores de paquetes son:
Instalar Desinstalar Actualizar Consultar Verificar Listar
Además de estas tareas, cada herramienta tiene sus opciones y comandos para realizar tareas más avanzadas sobre los paquetes.
Los paquetes tar.gz se descomprimen con la herramienta tar, y normalmente contienen en un directorio los archivos de código fuente, de documentación y scripts necesarios para el programa. A continuación se ejecutan los siguientes pasos:
1. ./configure: mediante este comando ejecutamos el script de configuración, donde se verifcan las dependencias y se preparan las variables del compilador.
2. make: en este paso se compila el código fuente y se convierte a binario.
3. make install: el programa se instalará en las rutas especificadas para que pueda ser ejecutado en el sistema.
3.3.2
Gestión del Entorno del Ciclo de Vida
El ciclo de vida de las aplicaciones y servidores se divide en entornos de ciclo de vida, que representan cada etapa por la que la aplicación o servidor puede pasar a lo largo de su existencia.
Los entornos de ciclo de vida pueden variar de una aplicación a otra, o de un servidor a otro. Normalmente, los entornos de Desarrollo, Pruebas y Producción están presentes en la mayoría de infraestructuras, aunque puede haber más o menos entornos según las necesidades y la naturaleza de las aplicaciones.
Las aplicaciones son desarrolladas en el entorno de Desarrollo, donde se crean nuevas versiones o se añaden nuevas funcionalidades.
Posteriormente se ponen a prueba en el entrono de Pruebas (testing o preproducción), para verificar el funcionamiento y detector posibles fallos.
Finalmente, una vez probada la aplicación, estaría preparada para su lanzamiento en Producción.
3.3.3
Gestión de la Configuración
La configuración de servidores es una tarea que suele realizarse después de la instalación de un Sistema Operativo, para habilitar o deshabilitar servicios, funcionalidades y parámetros según el propósito de cada servidor.
Aunque las configuraciones suelen ser muy variadas, normalmente existe un elenco de parámetros comunes a los servidores de una organización. Es en este punto donde podemos sacar provecho de la estandarización, y del uso de una herramienta que nos proporcione una forma automatizada de aplicar las diferentes configuraciones en distintos grupos de servidores.
Existen numerosas herramientas de despliegue de configuraciones tales como Puppet, Ansible, con las cuales podemos aumentar la eficiencia a la hora de realizar tareas repetitivas en distintos servidores.
29
3.3.4
Gestión del Aprovisionamiento
Uno de los objetivos que se persiguen tras la estandarización es ahorrar costes en tiempo de provisionamiento y automatización de los sistemas, reutilizando componentes, bloques o secciones de código común entre diferentes core-builds.
Figura 3-1. Diagrama de bloques para el aprovisionamiento de sistemas
Los principales objetivos a cubrir deberían ser, como mínimo:
1. Provisionar un servidor físico o virtual en cuestión de minutos.
2. Instalación de paquetería y software preparado para entornos de infraestructura (IaaS) o de aplicación (PaaS).
3. Evitar intervención manual antes y durante el despliegue.
4. Evitar, en la medida de lo posible, intervención manual post-despliegue.
5. Definición de perfiles para sistemas físicos y/o virtuales, independientes y optimizados para cada plataforma.
6. Integración con herramientas de inventariado o de control IT (ITSM).
7. Tras la fase de aprovisionamiento, disponer de un sistema preparado para ser productivo.
El esfuerzo de implementar y asegurar estos puntos anteriores puede resultar costoso en tiempo y esfuerzo al principio, pero rápidamente se obtienen mejoras en eficiencia operativa gracias a la gestión centralizada. Este mismo esquema puede adaptarse para otros objetivos que se consideren potencialmente optimizables, como:
1. Recuperación ante desastres 2. Clonado de sistemas
30
Figura 3-2. Objetivos adicionales en el aprovisionamiento de sistemas
3.3.5
Gestión de Actualizaciones
La aplicación de actualizaciones es otra de las tareas que deben realizarse de forma periodica en cualquier infraestructura, para mantener unos niveles de seguridad y corregir problemas de las aplicaciones y servicios que se ejecutan en nuestros servidores.
Normalmente, estas actualizaciones pueden ser de distintos tipos:
Actualizaciones de seguridad (muy recomendables)
Actualizaciones de corrección de errors (recomendables)
Actualizaciones de mejoras, que añaden nuevas funcionalidades.
Es altamente aconsejable mantener una política periódica de revision de actualizaciones e instalación de las mismas para tener nuestros servidores protegidos ante posibles ataques.
3.3.6
Gestión de la Seguridad
SCAP es una solución de verificación de cumplimiento para la estructura a nivel empresarial de Linux. Es una línea de especificaciones mantenida por el National Institute of Standards and Technology (NIST) para mantener la seguridad de sistemas en sistemas empresariales.
OpenSCAP es una herramienta de auditoría que utiliza el Formato de descripción de verificación de configuración extendible (XCCDF). XCCDF es una forma estándar de expresar el contenido de verificación y definir verificaciones de seguridad. También se combina con otras especificaciones tales como CPE, CCE, y OVAL, para crear una lista de verificación expressed que puede ser procesada por productos de SCAP-validated.
31
4
E
STANDARIZACIÓN DE
S
ISTEMAS
L
INUX CON
R
ED
H
AT
S
ATELLITE
4.1
Descripción y alcance de la herramienta de gestión Red Hat Satellite
ed Hat Satellite es un sistema escalable de gestión de servidores, que proporciona herramientas tanto de despliegue como gestión de subscripciones, ciclo de vida de software y de configuración orientado específicamente para la gestión centralizada de amplios parques de sistemas Red Hat Enterprise Linux. Recientemente, Red Hat Satellite también permite gestionar contenedores de manera integrada, para dar respuesta a una necesidad creciente de gestión de ciclo de vida de contenedores en un entorno empresarial.
4.1.1
Componentes
Satellite 6 incluye los siguientes componentes, cada uno con unas funcionalidades muy específicas e integrados en una solución de gestión de sistemas RHEL única:
Figura 4-1. Componenetes de Satellite
Puppet es una herramienta diseñada para administrar la configuración de sistemas Linux y Microsoft Windows de forma procedimental y posibilitar la gestión de infraestructura como código.
32
Foreman es una aplicación que se utiliza para el aprovisionamiento y el ciclo de vida de la gestión de sistemas físicos y virtuales. Foreman configura automáticamente estos sistemas utilizando diversos métodos, incluyendo Kickstart y módulos de Puppet. Foreman también proporciona datos históricos para presentación de informes, auditoría y resolución de problemas.
Katello es una aplicación de administración de suscripciones y repositorios. Proporciona un medio para suscribirse a los repositorios de Red Hat y descargar contenido. Con Katello se pueden crear y gestionar diferentes versiones de este contenido y aplicarlos a sistemas especificados por el usuario dentro de las etapas definidas del ciclo de vida de la aplicación.
Pulp es un servicio dentro de Katello que maneja repositorios y gestión de contenidos.
Candlepin es un servicio dentro de Katello que se encarga de la administración de suscripciones.
4.1.2
Integración y automatización
Red Hat Satellite 6 ofrece una interfaz accesible a través de un navegador web para una gestión cómoda, así como una CLI y un API REST para automatizar procesos:
Hammer es una herramienta CLI que ofrece la mayoría de las funciones de la interfaz de usuario Web a través de la línea de comandos.
Red Hat Satellite 6 incluye un servicio API REST que permite a los administradores de sistemas y los desarrolladores escribir scripts personalizados y aplicaciones de terceros que interactúan con Red Hat Satellite.
4.1.3
Gestión centralizada
Red Hat Satellite dispone de una arquitectura preparada para soportar múltiples organizaciones y localizaciones, de manera jerárquica:
33
Figura 4-2. Gestión centralizada de Organizaciones y Localizaciones
Red Hat Satellite Capsule Server actúa como proxy para algunas de las principales funciones de Satellite 6 incluyendo almacenamiento de repositorios, DNS, DHCP y configuración de Puppet Master. Cada servidor Satellite también contiene servicios integrados de Red Hat Capsule.
4.2
Entorno Operativo Estandar basado en Red Hat Satellite 6
4.2.1
Repositorios de software
4.2.1.1 Almacenamiento de Repositorios
Red Hat Satellite 6 proporciona un sistema para el almacenamiento de los repositorios basado en sistemas de ficheros locales para su presentación a los sistemas gestionados en forma de repositorios YUM.
Dicho sistema de ficheros locales evita la duplicidad de paquetes, es decir, si el mismo repositorio se presenta en varios Productos, Red Hat Satellite 6 creará una jerarquía de directorios que enlacen con la copia única descargada del repositorio elegido para evitar así duplicar paquetes existentes y ya descargados.
4.2.1.2 Sincronizador de Repositorios
34
manual o planificada periódicamente.
Las operaciones de configuración de repositorios externos y sincronización se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de la línea de comandos CLI (Hammer) o vía API REST.
Los repositorios susceptibles de ser sincronizados pueden ser proporcionados por Red Hat como base para el Sistema Operativo o de otros proveedores de software, incluido uno o varios orígenes de software personalizados o de terceros que presenten su información en forma de repositorio a través de http/https. Red Hat Satellite 6 permite que esta sincronización pueda suceder a través del proxy de la organización o con conexión directa a los repositorios YUM públicos a través de Internet (Red Hat Content Delivery Network o CDN).
4.2.1.3 Presentación de Repositorios
Pulp es la tecnología que proporciona los paquetes existentes en formato de repositorios YUM presentados a los clientes utilizando protocolo HTTPS, además Pulp permite el copiado de paquetes entre diferentes repositorios gestionados internamente.
Estas capacidades son utilizadas por Red Hat Satellite 6 para la creación de repositorios lógicos denominados Productos.
Figura 4-3. Repositorios en Satellite
Estos Productos se agrupan en Vistas de Contenido (Content Views), que no son más que una especie de instantáneas de los repositorios en un momento determinado:
35
Figura 4-4. Versiones de Content Views
Figura 4-5. Tipos de Content Views
Sobre estos Content Views se define un ciclo de vida en el que se representan los entornos definidos y sobre los cuales se asocian los equipos que van a ser gestionados por la plataforma.
36 Definiciones relacionadas:
Entorno de Ciclo de Vida: Un entorno define cada una de las fases del ciclo de vida de una Vista de Contenido.
o Por ejemplo, Integración, Pre-Producción y Producción.
o Se puede tener distintos Ciclos de Vida, con distintos Entornos.
Vista de Contenido: Es una agrupación de repositorios de Paquetes RPM/Módulos Puppet, en un momento determinado. Una Vista de Contenido tiene varias características principales:
o Sujeta bajo un número de versionado
o Una vez publicada, una versión es invariable
o El contenido publicado puede ser filtrado, de forma que no se tiene por qué incluir todo un repositorio entero sino solamente aquellos Paquetes RPM/Módulos Puppet relevantes.
o Una versión puede promocionar a lo largo de uno (o más de uno) ciclo de vida definido, pero no puede haber dos versiones de una Vista de Contenido en el mismo Entorno del Ciclo de Vida.
Todas las operaciones asociadas con la creación y mantenimiento de Productos, Vistas de Contenido, Ciclos de Vida y Sincronización, se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de línea de comandos o vía API REST.
4.2.1.4 Registro de sistemas a Repositorios
La asociación de Vistas de Contenido y sistemas gestionados es proporcionada por Red Hat Satellite 6. El registro de sistemas en Red Hat Satellite 6 se realiza desde los propios sistemas gestionados (de manera manual o automática).
La herramienta encargada del registro es subscription-manager la cual proporciona métodos, además, de gestión de repositorios.
Las operaciones de modificación de estas asignaciones se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de línea de comandos o vía API REST.
4.2.1.5 Gestión de paquetes de Repositorios
Yellow Dog Updater Modified (YUM) es la herramienta de gestión de paquetes RPM instalados o con posibilidad de ser instalados para Red Hat Enterprise Linux.
YUM se provee como parte de la instalación de Red Hat Enterprise Linux por defecto y se utilizará para el consumo de los repositorios ofrecidos ya sea por Red Hat Satellite 6 o de forma local en cada sistema gestionado. Sin embargo, la activación/desactivación de los repositorios se realiza a través de subscription-manager, el cual tiene visibilidad sobre los repositorios a los que tiene acceso un equipo.
4.2.2
Gestión de la Configuración
4.2.2.1 Sistemas de Repositorios de Objetos de Configuración
Red Hat Satellite 6 proporciona un sistema de gestión de repositorios de módulos Puppet. Los módulos Puppet actúan como contenedores de las clases Puppet, que se aplican a equipos y/o grupos de equipos.
Esta funcionalidad permite la creación de repositorios para almacenar los módulos, mantener los repositorios de forma manual y/o mantenerlos sincronizados con otros repositorios externos (PuppetForge, por ejemplo) de forma periódica o bajo demanda.
En Red Hat Satellite 6 los repositorios se agrupan en Productos, de forma que un Producto puede estar formado por varios repositorios, y cada repositorio tiene asociado su propio plan de sincronización (si fuera el caso).
37
Estas operaciones se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de la CLI o vía API REST.
4.2.2.2 Categorizador de sistemas y Objetos de configuración
Red Hat Satellite 6 actúa también como ENC (External Node Classifier) para Puppet Master, permitiendo: 1. Categorizar los sistemas gestionados en grupos de sistemas, denominados dentro de la herramienta por
su nombre en inglés “Host Groups”.
2. Asignar clases Puppet a diferentes grupos de sistemas de acuerdo a los requisitos de cada tipología de sistemas. Estos grupos de sistemas pueden ser anidados en una jerarquía de padres e hijos de forma que las clases aplicadas a un grupo padre son aplicadas también a sus grupos hijos.
3. Asignar valores a los parámetros de las clases a diferentes niveles: global, entorno, grupo de sistemas y/o sistema. Tiene mayor prioridad el valor definido en un nivel más cercano al sistema, de forma que un valor de parámetro definido en el sistema prevalece sobre un valor del mismo parámetro definido en el entorno.
Definiciones relacionadas:
Módulo Puppet: Es la unidad de empaquetado de clases Puppet.
o El formato de empaquetado que se va a usar es un formato conocido y definido, con una estructura de carpeta y metadatos concreto.
o Este formato específico es el que permite a Red Hat Satellite seleccionar los paquetes por su número de versión para cada caso.
Clase Puppet: Una clase Puppet define la configuración deseada para un elemento concreto del dispositivo (un fichero, un servicio, un paquete de software, etc.).
o Las Clases Puppet están escritas en Python, pueden tener parámetros de clase y soportan herencia de clases.
Parámetro de Clase: Las Clases Puppet pueden tener parámetros de clase en su definición, permitiendo comportamientos diferentes en función de estos parámetros.
o Por ejemplo, una misma Clase Puppet puede servir para configurar un servidor NTP diferente en función del Parámetro de Clase.
o Los valores de estos Parámetros de Clase pueden ser especificados desde el ENC integrado en Red Hat Satellite 6, prevaleciendo sobre los escritos en el código de la Clase Puppet.
Parámetro Global: Un tipo más general de Variable de Clase. Es un parámetro definido en el ENC integrado en Red Hat Satellite 6 que puede ser usado desde cualquier Clase Puppet.
Ámbito de una Variable/Parámetro:
o Los Parámetros Globales, Variables de Clase y Parámetros de Clase pueden definirse en el ENC a distintos niveles de la jerarquía de Sistemas Gestionados/Grupos de Sistemas y aplicando condiciones complejas.
o Esta granularidad permite reutilizar el código de las Clases Puppet y mantener distintos tipos de Sistemas Gestionados.
o En caso de asignar valores distintos a una misma Variable/Parámetro en distintos ámbitos, prevalece el valor en el ámbito más cercano al Sistema Gestionado.
Grupo de Sistemas:
o Para facilitar la administración, los Sistemas Gestionados se pueden agrupar, permitiendo actuar sobre el Grupo de Sistemas Gestionados para realizar cambios a más de un Sistema Gestionado al mismo tiempo.
38
o Los Grupos de Sistemas pueden anidarse, creándose una jerarquía entre ellos que facilita la herencia de Parámetros ya sean de Clase o Globales.
Organización y Localización: Red Hat Satellite 6 permite clasificar y agrupar los Sistemas Gestionados por organizaciones y localizaciones. Esta clasificación es útil en caso de que la administración de los equipos esté delegada a distintos grupos de forma que cada usuario únicamente pueda actuar sobre su Organización y/o Localización.
Todas las operaciones de gestión del ENC se pueden realizar desde la interfaz web de Red Hat Satellite 6, a través de la CLI o via API REST.
4.2.2.3 Sistema de envío de Objetos de configuración
Puppet Master es un componente embebido e integrado dentro de la solución de Red Hat Satellite 6 y se encarga de atender las solicitudes de los clientes (Puppet Client) instalados en los sistemas gestionados.
El servidor Puppet Master recibe las peticiones de configuración de los sistemas gestionados (a través de Puppet Client), compila y parametriza las clases de configuración asignadas para el sistema específico (de acuerdo a la asignación realizada en el ENC) y se las envía para que se apliquen en el sistema gestionado.
En la arquitectura de Red Hat Satellite 6 se contempla la opción de que los sistemas gestionados se conecten al servidor central o a una de las capsulas donde están replicados todos los módulos de Puppet necesarios. Esta característica proporciona a Red Hat Satellite 6 capacidad para distribuir la carga que supone atender solicitudes de más sistemas al mismo tiempo.
4.2.2.4 Aplicación de configuración
Puppet Client es un componente incluido dentro de Red Hat Enterprise Linux y se encarga de realizar solicitudes a un servicio (Puppet Master) instalado en un sistema remoto para obtener un conjunto de políticas de configuraciones (acorde con su clasificación en el ENC y su estado actual) y aplicarlas en el sistema gestionado.
39
Figura 4-7. Arquitectura de Puppet
Como parte de la ejecución de Puppet Client hay tres puntos claves:
Envío del estado actual:
o Puppet Client envía el estado actual del sistema Puppet Master para obtener las políticas de configuración a aplicar.
o Esta información incluye datos como servicios en marcha, procesos en ejecución, usuarios locales, números de serie de hardware, e incluso datos personalizados.
o El resultado es que se tiene información de los sistemas gestionados periódicamente que puede usarse para realizar estadísticas, consultas o inventariado.
Ejecución de la aplicación:
o Puppet Client realiza todas aquellas tareas necesarias para asegurar el estado del dispositivo acorde con la política de configuración recibida.
Envío del informe de resultados:
o Puppet Client envía el resultado de la ejecución de vuelta a Puppet Master para su análisis. La ejecución de Puppet Client puede ser ejecutada bajo demanda o periódicamente desde el sistema gestionado, así como solicitada bajo demanda desde la interfaz web de Red Hat Satellite 6, a través de la CLI o vía API REST.
4.2.2.5 Sistema de informes de ejecución de configuación
Una vez que Puppet Client ha terminado de aplicar las configuraciones pertinentes, envía el resultado de la ejecución de la configuración al Puppet Master.
Esta información es almacenada en Red Hat Satellite 6 que la presenta a través de su interfaz web para su visualización y explotación posterior.
40
Figura 4-8. Informe de Puppet
Se incluye en el resultado la siguiente información (puede variar según las necesidades):
Tiempo total de la ejecución, así como desglosado (obtener configuración, aplicar servicios, editar ficheros o instalar software).
Número de eventos de cada tipo (pendiente, reiniciado, omitido, aplicado, fallido).
Mensajes de diagnóstico que se envíen desde las clases Puppet (catalogados por criticidad: aviso, notificación, error, etc.).
En caso de modificar ficheros, se incluye un resumen de las diferencias entre el fichero original y el final.
4.2.3
Relación entre componentes
Todos los componentes (a excepción de los parámetros, variables y ámbitos) explicados anteriormente se agrupan/relacionan en el siguiente mapa:
41
Figura 4-9. Mapa de la relación de componentes de Satellite
4.2.4
Automatización de despliegue y aprovisionamiento
Red Hat Satellite 6 ofrece la posibilidad de gestionar de manera centralizada y ordenada las siguientes entidades:
Plantillas de provisionamiento (basadas en kickstart).
Parametrización constante y variable (en tiempo de despliegue).
Bloques de código reutilizables (snippets).
Agrupaciones de Hosts con perfiles de configuración diferentes (para diferentes perfiles de sistemas).
Core-build: Por defecto, Red Hat Satellite 6 ya ofrece un diseño para sistemas RHEL 6 y 7 basado en un core-build mínimo, que incluye “out-of-the-box” lo siguiente:
o Particionamiento de sistemas de ficheros.
o Instalación de software base (rpms) para el sistema operativo y gestión de configuración.
o Configuración de red estática o dinámica.
o Configuración básica de componentes core:
o NTP
o DNS
o Integración con proveedores de identidad (RHEL Identity Management, LDAP…).
o Integración de clientes de monitorización (Zabbix, Nagios…).
4.2.4.1 Métodos de aprovisionamiento
Red Hat Satellite 6 dispone de los siguientes métodos de aprovisionamiento y despliegue:
PXE:
42
o La cápsula de Satellite dispone de servicios TFTP y DHCP para gestionar el despliegue centralizado y local para cada organización/localización.
o Combinado con la automatización de la instalación basada en kickstart, esta aproximación permite automatizar por completo el proceso de despliegue.
Boot ISO:
o Método tradicional que requiere intervención manual para inyectar la imagen ISO a desplegar.
o Bajo grado de automatización.
Basado en imagen:
o Solo disponible para plataformas de virtualización tradicional (RHEV, vSphere) o Cloud (OpenStack, AWS, Azure).
o Método más rápido y efectivo para plataformas no bare-metal.
Satellite Discovery:
o Creación de una imagen ISO que contiene los elementos necesarios para dar de alta automáticamente un sistema físico o virtual.
o Pueden declararse reglas más o menos complejas para gestionar la automatización de despliegue por este método.
4.2.4.2 Proceso de aprovisionamiento y despliegue
Para asegurar un despliegue completo y automatizado, cada fase y aplicar los bloques lógicos en orden:
Figura 4-10. Procceso de aprovisionamiento
43
Figura 4-11. Flujo de aprovisionamiento en Satellite
44
Durante el proceso de análisis y diseño, todos estos bloques tienen que ser analizados con cuidado y determinar la manera más óptima de crearlos o reutilizar lo que ya dispone el entorno a analizar.
4.2.5
Auditoría de Suscripciones, Inventario y Compliance
4.2.5.1 Auditoría y control de Suscripciones
Red Hat Satellite 6 dispone de Candlepin como componente de gestión de subscripciones. A través de la GUI, CLI y API REST de Satellite, es posible obtener información actualizada en tiempo real del uso de subscripciones de Red Hat para todos nuestros entornos.
Figura 4-13. Dashboard de suscripciones
Al estar preparado para gestionar compañías multi-organización, este control es completamente aislado entre organizaciones, por lo que la privacidad está garantizada.
4.2.5.2 Inventario de sistemas
Red Hat Satellite 6 permite controlar de manera fácil y sencilla el inventario de los sistemas pertenecientes a una misma organización, indicando su nivel de reporting, estado actual, aplicación de configuración y eventos más importantes:
45
Figura 4-14. Dashboard de estado de los hosts
El agente de puppet en cada sistema es el encargado de reenviar periódicamente los “facts” de cada sistema, alimentando el servidor de Satellite 6 central y nutriendo de información muy valiosa para la explotación y correcta operación de los sistemas.
4.2.5.3 Gestión de la seguridad y compliance
Red Hat Satellite 6 permite gestionar reglas de compliance para todos nuestros sistemas, de manera fácil y centralizada. Para ello se apoya en OpenSCAP, integrado en RHEL 6 y RHEL 7.
Desde Red Hat Satellite, de manera centralizada se pueden crear test de compliance compatibles con el estándar SCAP, políticas de seguridad y asignarlas a grupos de hosts de manera fácil y sencilla (para sistemas RHEL 6 y RHEL 7):
Figura 4-15. Contenido SCAP
46
vulnerabilidades de seguridad y compliance/auditoría de todos aquellos sistemas administrados por Red Hat Satellite.
Figura 4-16. Informes de cumplimiento de reglas SCAP
OpenSCAP genera informes ARF (Asset Reporting Format) e incluso es capaz de aplicar remediación ante riesgos de manera automatizada, para asegurar que el conjunto de sistemas gestionados no es objeto de vulnerabilidades de sistema o seguridad.
47
Figura 4-17. Detalle de informes SCAP
4.2.6
Gestión de actualizaciones y erratas
Cualquier herramienta de gestión que pretenda servir como pieza central de un SOE, precisa de mecanismos para facilitar la actualización y ciclo de vida de software, pudiendo lanzar tareas de manera centralizada y actualizar/parchear un conjunto de sistemas por entornos, de acuerdo a las políticas establecidas por la organización y/o cliente.
Red Hat Satellite 6 permite realizar esta tarea gracias a los grupos de host y a Katello como herramienta principal de que permite lanzar operaciones de actualización de cualquiera de los productos incluidos en una vista de contenido:
Figura 4-18. Gestión de actualizaciones
Gracias a las vistas de contenido, se pueden publicar y manejar diferentes versiones y agrupaciones de paquetes con sus correspondientes niveles de parcheado:
48
Figura 4-19. Visualización del número de actualizaciones en Content Views
Además, podemos publicar vistas de contenido entre entornos, definiendo así el ciclo de vida de cada uno de los productos gestionados por Red Hat Satellite 6.
Así mismo, es posible revisar la aplicación correcta de los parches fácilmente via GUI:
Figura 4-20. Detalle de tarea de aplicación de actualizaciones
O también haciendo uso de Hammer como CLI o del API REST.
4.3
Versionado de Satellite y ciclo de actualizaciones
Actualmente Satellite se ecuentra en su versión 6 y mantiene un ciclo de actualizaciones y revisiones periódico, diferenciando versiones mayores y menores del producto.
49
funcionalidades de la herramienta, mientras que las versiones menores (6.1.x, 6.2.x, 6.3.x) están enfocadas a mejorar la integración de las herramientas, resolver problemas y pulir los procesos internos de funcionamiento. La última versión mayor, la 6.3, publicada recientemente, ha introducido una serie de nuevas características y mejoras, entre las que podemos destacar las siguientes:
Integración con Ansible Tower: con Ansible Tower podemos automatizar taras de gestión como aprovisionamiento cloud, configuración y despliegue de aplicaciones. Satellite proporciona un inventario dinámico y la capacidad de ejecutar playbooks después del aprovisionamiento.
Soporte EC2: Satellite puede funcionar en la nube de Amazon (Amazon Elastic Compute Cloud, EC2).
Utilidad de clonado: capacidad para restarurar Satellite en un entorno bare metal, clonando un backup de la versión 6.1 o 6.2, y actualizando el clon a la versión 6.3.
Selección de la política de sincronización de repositorios: bajo demanda, background, inmediato o heredado del repositorio.
Soporte para suscripciones futuras: podemos generar manifiestos que incluyen suscripciones con fecha futura.
Panel de notificaciones: esta versión añade un panel de notificaciones en la interfaz web de usuario, que informará de los eventos y cambios más importantes en el entorno (descubrimiento de hosts, borrado de hosts, aprovisonamiento exitoso de un sistema, host importado sin propietario asociado).
Soporte para Puppet 4
Soporte para Red Hat Virtualization 4