Hogar › Servicios › Instalación y configuración de títeres. Master of puppets: Instalación y configuración del sistema de gestión de configuración remota de Puppet. Agregar nodos administrados

Instalación y configuración de títeres. Master of puppets: Instalación y configuración del sistema de gestión de configuración remota de Puppet. Agregar nodos administrados

No hace mucho, en las páginas de la revista, analizamos el sistema de gestión de configuración remota Cfengine para máquinas UNIX, que simplifica enormemente la vida de un administrador de sistemas al automatizar los pasos para configurar muchos nodos de red. Pero, por muy conveniente que sea Cfengine, tiene muchas desventajas que no tiene un sistema llamado Puppet.

Imagínese como un administrador de sistemas, responsable de mantener la funcionalidad de cientos de máquinas que ejecutan sistemas operativos tipo UNIX. Cada uno de ellos requiere configuración, actualización periódica y seguimiento, y se supone que muchos de ellos realizan funciones similares.

Dos tercios son estaciones de trabajo, algunos más son enrutadores y el resto son varios servidores web y almacenamiento de datos. Pregunta: ¿cómo gestionar todo este negocio? La respuesta más sencilla es simplemente conectarse a cada uno de ellos mediante SSH y realizar los cambios necesarios. Sin embargo, este método tiene dos problemas. En primer lugar, requiere mucha mano de obra. En segundo lugar, el administrador tendrá que realizar constantemente muchas acciones monótonas (por ejemplo, para actualizar OpenOffice.org en todas las estaciones de trabajo, deberá ejecutar los mismos comandos varias docenas de veces). Puede intentar evitar este problema escribiendo varios scripts que se conectarán a cada máquina y ejecutarán comandos preescritos. Pero aquí también te esperan problemas.

Los guiones habrá que modificarlos constantemente para adaptarlos a cada tarea; Los scripts deberán tener en cuenta las diferencias en los sistemas operativos y las versiones, y deberán depurarse durante mucho tiempo antes de aplicarse a las máquinas en ejecución. En general, no comme il faut. La respuesta correcta es utilizar los llamados sistemas de gestión de configuración remota, cuyos representantes más conocidos son los sistemas de código abierto Cfengine y Puppet. Dichos sistemas asumen todas las responsabilidades para llevar la configuración de la máquina a la forma deseada, requiriendo que el administrador solo describa el estado final del sistema en un lenguaje especial (por ejemplo, una descripción de qué paquetes deben instalarse en el sistema operativo, qué líneas deben agregarse a los archivos de configuración, qué comandos deben ejecutarse, etc.). Después de esto, todos los nodos recibirán información sobre el estado requerido del servidor y configurarán automáticamente el sistema. Gracias a este mecanismo, las máquinas nuevas se pueden configurar completamente sin intervención humana y las existentes se pueden reconfigurar agregando solo unas pocas líneas a la descripción del estado.

¿Marioneta?

Ya hemos dedicado un artículo completo al sistema Cfengine, por lo que hoy nos centraremos en el sistema Puppet, al que bien se puede llamar su seguidor ideológico. Puppet fue desarrollado por Luke Kanies, quien se cansó de las limitaciones de Cfengine y decidió crear una versión mejor desde cero. Si ya ha utilizado Cfenfine, probablemente encontrará que Puppet es un sistema más conveniente y potente. El lenguaje de estado de Puppet es más flexible y de alto nivel, por lo que los administradores no tienen que preocuparse por cosas como escribir reglas separadas para cada tipo de sistema operativo o detallar cómo realizar acciones triviales. Puppet permite que su maestro se concentre en lo que quiere hacer, en lugar de en cómo hacerlo (por ejemplo, para instalar un paquete específico en cualquiera de los sistemas operativos compatibles, solo necesita escribir literalmente unas pocas líneas que digan "Instalar este programa"). " en lugar de describir los comandos necesarios para su instalación). Puppet está escrito en un lenguaje Ruby simple, lo que facilita adaptarlo a una tarea específica y ampliar su funcionalidad (se proporciona un sistema flexible de complementos).

Además, a diferencia del modelo de desarrollo de Cfengine, que esencialmente gira en torno a una persona, Puppet tiene una gran comunidad de entusiastas que realizan mejoras en el código, comparten ejemplos de configuración y escriben documentación.

En general, Puppet parece un sistema más moderno y mejor diseñado. Al igual que Cfengine, es compatible con casi todos los sistemas operativos modernos tipo UNIX (incluido MacOS X) y también puede ejecutarse en el entorno Cygwin sobre Windows. Su lista de dependencias solo incluye el intérprete Ruby y la herramienta Factor, por lo que no debería haber problemas con la instalación (para ser justos, la lista de dependencias de Cfengine es aún más corta).

Instalación

Al igual que Cfengne, Puppet es un sistema cliente-servidor que consta de un servidor de control y nodos esclavos. El servidor almacena una descripción de los estados finales de los nodos (que en términos de Puppet se llama manifiesto) y espera a que se conecten. Cada media hora (por defecto), el cliente se conecta al servidor, recibe de él una descripción del estado final, lo compara con el actual y, si éste y/o el estado descrito ha cambiado, reconfigura el sistema y luego se va a dormir. La comunicación se realiza a través de un canal cifrado, por lo que los ataques basados en la sustitución de la descripción del estado están excluidos (pero si un atacante toma el control del servidor, todos los nodos estarán bajo su control).

Puppet está incluido en los repositorios de todas las distribuciones populares, por lo que instalarlo no debería ser difícil. Por ejemplo, en Debian/Ubuntu el cliente Puppet se puede instalar así:

$ sudo apt-get instalar marioneta

Y el servidor es así:

$ sudo apt-get instalar Puppet Puppetmaster

Los archivos de configuración del cliente y del servidor se almacenan en el directorio /etc/puppet. El más importante de ellos es el archivo /etc/puppet/manifests/site.pp, que contiene el manifiesto.

Almacena una descripción de los estados y solo debe existir en el servidor. Para facilitar la depuración, agreguemos una configuración simple:

contraseña de clase (
archivo("/etc/contraseña":
propietario => raíz,
grupo => raíz,
modo => 644,
}
}
valor predeterminado del nodo (
incluir contraseña
}

Estas líneas describen el estado en el que el propietario del archivo /etc/passwd debe ser root y sus permisos deben estar establecidos en 644. Examinaremos más de cerca el formato del archivo de manifiesto en la siguiente sección. El segundo archivo más importante es /etc/puppet/puppet.conf. Establece la configuración del servidor y de los clientes, por lo que debe estar presente en todas las máquinas organizadas en la red Puppet. En Ubuntu, este archivo contiene la configuración mínima necesaria y, en la mayoría de los casos, suficiente. A continuación se dan con comentarios:

# vi /etc/puppet/puppet.conf
# Rutas de directorio estándar
logdir=/var/log/títere
vardir=/var/lib/títere
ssldir=/var/lib/puppet/ssl
rundir=/var/run/títere
# Ubicación de la herramienta Factor,
# utilizado para obtener información sobre el sistema operativo
factpath=$vardir/lib/facter
# Sincronizar complementos
# (complementos instalados en el servidor; se copian a los clientes)
complementosync=verdadero
# Catálogo con plantillas (lea sobre ellas a continuación)
templatedir=$confdir/plantillas
# Sincronización con etckeeper
# (quién sabe, lo entenderá, otros no lo necesitan)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

El archivo de configuración puede incluir una gran cantidad de opciones diferentes, cuya información se puede obtener generando una configuración predeterminada:

$ sudo Puppetmasterd -genconfig > /etc/puppet/
Puppetd.conf.default

La configuración del cliente predeterminada se genera usando otro comando:

$ sudo Puppet -genconfig > /etc/puppet/puppetd.conf.default

Los archivos fileserver.conf y auth.conf se utilizan para configurar el servidor de archivos (lea sobre esto en la sección "Servidor de archivos") y la autenticación. No tiene sentido tocarlos todavía. Una vez completada la configuración, se debe reiniciar el servidor Puppet:

$ sudo /etc/init.d/puppetmaster reiniciar

Después de lo cual estará listo para aceptar las solicitudes de los clientes. Sin embargo, sin un certificado firmado, ningún cliente podrá recibir el manifiesto del servidor y configurar la máquina.

Por lo tanto, debemos ejecutar los clientes Puppet en modo de prueba para que puedan enviar sus certificados al servidor para su firma (por cierto, esto se puede hacer en todas las máquinas al mismo tiempo usando la herramienta shmux):

$ sudo Puppetd -servidor Puppet-server.com -verbose -test

Regresamos al servidor y recibimos una lista de certificados listos para firmar:

$ sudo puppetca --lista

Seleccione un host de la lista y firme su certificado:

$ sudo puppetca --sign nomad.grinder.com

O firmamos todo a la vez:

$ sudo puppetca --signo --todos

Ahora puedes iniciar clientes en modo combate. Pero primero debe ingresar el nombre del servidor Puppet en el archivo de configuración (por defecto su nombre es simplemente Puppet):

$sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "servidor=puppet-server.com" >> /etc/puppet/puppet.conf
# salida

Clientes de lanzamiento:

$ sudo /etc/init.d/puppet inicio

Lenguaje de descripción del estado

Como se mencionó anteriormente, Puppet utiliza su propio lenguaje para describir el estado final del sistema operativo, con la ayuda del cual el administrador del sistema especifica en qué forma deben adoptarse los componentes del sistema operativo para que alcance el estado deseado. Se trata de un lenguaje bastante complejo que, sin embargo, es mucho más sencillo que cualquier lenguaje de programación. Si está al menos superficialmente familiarizado con el lenguaje de scripting bash, comprenderá fácilmente el lenguaje Puppet. El elemento clave del lenguaje son los recursos que se utilizan para describir a qué forma se debe convertir uno de los componentes del sistema operativo. Por ejemplo, el siguiente recurso simple describe el estado deseado del archivo /etc/passwd:

# vi /etc/puppet/manifests/site.pp
archivo("/etc/contraseña":
propietario => "raíz"
}

Aquí el archivo es el tipo de recurso. Hay varias docenas de ellos en total, desde recursos que administran archivos, como en este ejemplo, hasta paquetes y servicios. La línea /etc/passwd es el nombre del recurso.

En el caso del tipo de archivo, el nombre es el mismo que la ruta al archivo, pero en algunos otros tipos el nombre puede ser arbitrario. La línea propietario => "root" describe establecer el atributo de propietario en root, es decir, dice que el propietario del archivo especificado debe ser un administrador.

Cada tipo de recurso tiene su propio conjunto de atributos disponibles para modificación, además hay metaatributos especiales que se pueden usar en cualquier recurso. Una de las cualidades importantes de los recursos es la capacidad de vincularse a ellos. Esto se puede utilizar para formar cadenas de dependencia. La siguiente entrada crea el recurso /etc/group, que depende del recurso /etc/passwd (las dependencias se especifican mediante el metaatributo require):

# vi /etc/puppet/manifests/site.pp
archivo("/etc/grupo":
requerir => Archivo["/etc/passwd"],
propietario => "raíz",
}

Esto significa que el recurso /etc/group se puede configurar (llevar al formulario descrito) solo cuando el recurso /etc/passwd está configurado. Los recursos se pueden agrupar en colecciones de recursos llamadas clases. Esto es necesario para combinar recursos similares en significado y tipo de tarea realizada en un recurso abstracto. Por ejemplo, por conveniencia, podríamos combinar la instalación y el lanzamiento del servidor web nginx en un recurso abstracto con el mismo nombre:

# vi /etc/puppet/manifests/site.pp
clase nginx(
paquete("nginx":
asegurar => instalado
}
servicio("nginx":
asegurar => corriendo,
requerir => Paquete["nginx"],
}
}

Aquí, el tipo de recurso del paquete se usa para instalar el paquete nginx en el sistema y el servicio se usa para iniciar el servicio del mismo nombre. Con require forzamos al sistema a iniciar el servicio sólo si el paquete se ha instalado correctamente. La conveniencia de las clases es que también se pueden incluir dependiendo de:

# vi /etc/puppet/manifests/site.pp
servicio("calamar":
asegurar => corriendo,
requerir => Clase["nginx"],
}

Como en los lenguajes OOP reales, las clases pueden heredar entre sí y anular atributos:

# vi /etc/puppet/manifests/site.pp
contraseña de clase (
archivo("/etc/contraseña":
propietario => "raíz",
grupo => "raíz",
}
}
la clase passwd-bsd hereda passwd (
Archivo["/etc/passwd"] (grupo => "rueda")
}

Aquí, la clase passwd-bsd hereda de passwd para anular el atributo de grupo del recurso /etc/passwd (en sistemas BSD, /etc/passwd pertenece al grupo wheel, por lo que creamos una clase separada para dichos sistemas). Más adelante veremos una forma más correcta y obvia de seleccionar valores de atributos alternativos utilizando condiciones.

Las variables son uno de los componentes esenciales de cualquier lenguaje de programación y Puppet también las tiene. Las variables comienzan con el signo $ y pueden contener cualquier número, cadena o valor booleano (verdadero, falso):

$quiero_apache = verdadero
$apache_version = "2.2.14"

Una de las características más poderosas de Puppet relacionadas con variables es su integración con la herramienta de información de la máquina facter. Esta utilidad devuelve toda la información específica de la máquina en forma de pares clave-valor, que Puppet convierte en variables del mismo nombre. Junto con las instrucciones condicionales en el lenguaje Puppet, se pueden utilizar para alterar los atributos de los recursos según las propiedades de la máquina.

Por ejemplo, la clase passwd descrita anteriormente se puede reescribir fácilmente para seleccionar automáticamente un atributo según el tipo de sistema operativo (y la clase en sí ya no es necesaria):

# vi /etc/puppet/manifests/site.pp
archivo("/etc/contraseña":
propietario => "raíz",
grupo => $núcleo? (
Linux => "raíz",
FreeBSD => "rueda",
},
}

Dependiendo del sistema operativo en el que se analizará este fragmento del manifiesto, el valor del atributo del grupo será root o wheel. Además del operador condicional, el lenguaje Puppet también admite el operador de selección de casos, que se puede utilizar para crear un recurso particular según el valor de una variable:

# vi /etc/puppet/manifests/site.pp
caso $sistema operativo (
redhat: (servicio("httpd": asegurar => ejecutando))
debian: (servicio("apache": asegurar => en ejecución))
predeterminado: ( servicio ( "apache2": asegurar =>
correr))
}

Este código define diferentes opciones para un recurso de tipo servicio dependiendo del sistema operativo (los nombres de los servicios pueden diferir entre las distribuciones de Linux, por lo que el servicio que Puppet debe ejecutar debe especificarse individualmente para cada uno).

La opción predeterminada se utiliza si el valor de la variable no coincide con ninguna de las opciones anteriores. Además de los tipos de recursos de archivos, paquetes y servicios mencionados anteriormente, Puppet admite una gran cantidad de otros tipos de recursos, incluidos los creados por desarrolladores externos. Su descripción detallada, incluidos ejemplos, atributos y características admitidos, se puede encontrar en la documentación oficial: http://docs.puppetlabs.com/references/stable/type.html. A continuación se muestra una lista y breve descripción de los más utilizados:

Tipos de recursos populares de Títeres

cron - gestionar trabajos cron
ejecutivo: ejecuta scripts y comandos
archivo - gestión de archivos
filebucket - copia de seguridad de archivos
grupo - gestión de grupo
host: gestiona las entradas en el archivo /etc/hosts
interfaz - configuración de interfaces de red
mount - montaje de sistemas de archivos
notificar: envía un mensaje al archivo de registro de Puppet
paquete - gestión de paquetes
servicio - gestión de servicios
sshkey - administrar claves SSH
ordenado: eliminar archivos según las condiciones
usuario - gestión de usuarios
zonas - Gestión de zonas Solaris

El segundo elemento más importante del lenguaje Puppet después de los recursos son los nodos. Con su ayuda, el administrador puede describir a qué máquinas se deben aplicar determinados recursos y clases. En otras palabras, es una forma de especificar una configuración individual para cada una de las máquinas que participan en la red Puppet. El ejemplo más simple de un nodo se da al principio del artículo en la sección "Instalación":

# vi /etc/puppet/manifests/site.pp
valor predeterminado del nodo (
incluir contraseña
}

Esta es la definición del nodo predeterminado, que incluye el recurso/clase passwd. El nombre predeterminado significa "todos los demás nodos", por lo que el recurso/clase de contraseña definido en algún lugar arriba se configurará en cada uno de ellos. La palabra clave include se utiliza aquí por conveniencia; de hecho, todas las clases y recursos se pueden describir directamente en la descripción del nodo, pero esto no se recomienda. Además del valor predeterminado, en el nombre del nodo puede especificar el nombre de red de la máquina (luego todos los recursos descritos en el nodo se configurarán solo en esta máquina), o un nombre arbitrario (luego este nodo puede ser heredado por otro nodo) . Para comprender cómo funciona todo esto junto con las clases y los recursos, veamos un ejemplo de un manifiesto Puppet listo para usar que se utiliza para configurar dos máquinas de red (un servidor web y un servidor NTP):

# vi /etc/puppet/manifests/site.pp
# Instalar y ejecutar un servidor SSH
clase sshd(
paquete (openssh-server: asegurar => instalado)
servicio(sshd:
nombre => $sistema operativo? (
fedora => "sshd",
debian => "ssh",
predeterminado => "sshd",
},
habilitar => verdadero,
asegurar => corriendo,
}
}
# Instalar y ejecutar Apache
clase httpd(
paquete (httpd: asegurar => instalado)
servicio(httpd:
habilitar => verdadero,
asegurar => corriendo,
}
}
# Instalar e iniciar un servidor NTP
clase ntpd(
paquete (servidor ntp: asegurar => instalado)
servicio (
servidor ntp:
habilitar => verdadero,
asegurar => corriendo,
}
}
# El nodo base, usado sólo como padre de todos los demás.
base del nodo (
incluir sshd
}
# El nodo donde se ubicará el servidor web
El nodo web.server.com hereda la base (
incluir httpd
}
# Nodo del servidor NTP
El nodo ntp.server.com hereda la base (
incluir ntpd
}

Esta configuración aparentemente simple hace mucho: instala y ejecuta Apache en la máquina en web.server.com y un servidor NTP instalado y ejecutándose en la máquina. ntp.servidor.com. Además, ambas máquinas instalan un servidor SSH. Es poco probable que esta configuración sea adecuada ni siquiera para un administrador; Tendrá que mejorarse seriamente para enseñar cómo configurar servidores correctamente, recibir configuraciones nuevas y otros archivos del servidor principal de Puppet.

Sin embargo, muestra claramente el poder de Puppet. Usando una configuración simple, hicimos que las máquinas instalaran y ejecutaran el software necesario por sí mismas y lo mantuvieran en funcionamiento (si el servidor falla, Puppet se reconfigurará para llevar los sistemas al estado requerido).

Servidor de archivos

Muchas tareas de administración remota no se pueden resolver sin copiar archivos adicionales a las máquinas. Pueden ser configuraciones preparadas previamente, páginas web para Apache, paquetes que no están en el repositorio oficial y mucho más. Para facilitar el proceso de transferencia de estos archivos a hosts remotos, Puppet incluye un servidor de archivos.

La configuración del servidor de archivos se almacena en el archivo /etc/puppet/fileserver.conf. Para obligar a Puppet a entregar el contenido de un directorio específico a los clientes, debe escribir algunas líneas en él:

# vi /etc/puppet/fileserver.conf
ruta = /var/títere/archivos
permitir *.server.com

Estas dos líneas indican que el directorio /var/puppet/files debe ser accesible para todos los hosts en el dominio server.com. Además, podemos especificar el nombre de dominio completo de una máquina permitida o su dirección IP, y también eliminar los no deseados mediante la directiva denegar. Cualquier archivo en ese directorio se puede mover al cliente utilizando el recurso de archivo. Por ejemplo:

# vi /etc/puppet/manifests/site.pp
archivo("/etc/httpd/conf/httpd.conf":
fuente => "títere://httpd/httpd.conf",
modo => 644,
}

El archivo httpd.conf, ubicado en el servidor en el directorio /var/puppet/files/httpd, se copiará a la máquina de destino a lo largo de la ruta especificada en el nombre del recurso.

Conclusiones

En este artículo, hemos cubierto una porción muy pequeña de las capacidades de Puppet. De hecho, se trata de un sistema complejo que sólo puede describirse en detalle en las páginas de un libro. Al mismo tiempo, Puppet es muy fácil de configurar y mantener, sobre todo porque puedes encontrar muchos ejemplos de su configuración en Internet.

Información

Puppet utiliza el protocolo HTTP, por lo que se puede ejecutar en un servidor web para mejorar el rendimiento.
Puppet se puede utilizar para configurar automáticamente y mantener una única máquina local.
Al combinar Puppet, instalación del sistema operativo en red (pxe-install) e imágenes de instalación de creación propia, puede crear una red de máquinas completamente autoconfigurable que se puede implementar con un solo comando.
Muchas grandes empresas utilizan Puppet en su trabajo, como Google, Fedora Project, la Universidad de Stanford, Red Hat, Siemens IT Solution y SugarCRM.

Campo de golf

http://docs.puppetlabs.com - Documentación de marionetas
http://docs.puppetlabs.com/guides/language_tutorial.html - Descripción completa del lenguaje Puppet
http://docs.puppetlabs.com/references/stable/type.html - Tipos de recursos

Serguéi Yaremchuk

Configuración centralizada de sistemas UNIX usando Puppet

No se puede considerar conveniente gestionar una gran cantidad de sistemas UNIX. Para cambiar un parámetro, el administrador debe comunicarse con cada máquina; los scripts solo pueden ayudar parcialmente y no en todas las situaciones.

Hay que reconocer que los administradores de red de Windows todavía se encuentran en una posición más ventajosa. Basta con cambiar la configuración de la política de grupo y, después de un tiempo, todas las computadoras de la red, incluidas aquellas con un sistema operativo instalado recientemente, "aprenderán" sobre la innovación, si les concierne, por supuesto. Mirando retrospectivamente el largo período de desarrollo de UNIX, se puede ver que nada como esto tuvo éxito. Existen soluciones como kickstart que ayudan con la instalación inicial del sistema operativo, pero un mayor desarrollo requerirá un esfuerzo significativo. Las soluciones comerciales como BladeLogic y OpsWare resuelven el problema de la automatización de la configuración sólo parcialmente; su principal ventaja es la presencia de una interfaz gráfica, y sólo las grandes organizaciones pueden permitirse el lujo de adquirirlas; Por supuesto, hay proyectos que ofrecen soluciones gratuitas, pero a lo largo de su existencia no han podido crear una gran comunidad. Por ejemplo, Cfengine no es muy popular entre los administradores, aunque, además de Linux, se puede utilizar en *BSD, Windows y Mac OS X. Esto puede deberse a la relativa complejidad de la creación de configuraciones. Al describir las tareas, es necesario tener en cuenta las características de cada sistema específico y controlar manualmente la secuencia de acciones al ejecutar comandos. Es decir, el administrador debe recordar que para algunos sistemas se debe escribir adduser, para otros, useradd, tener en cuenta la ubicación de los archivos en diferentes sistemas, etc. Esto complica en gran medida el proceso de escritura de comandos; es muy difícil crear la configuración correcta sobre la marcha y es casi imposible leer las configuraciones creadas después de un tiempo. A pesar de la licencia GPL, Cfengine es esencialmente un proyecto de una sola persona que controla todos los cambios y no está muy interesado en construir una sociedad abierta. Como resultado, las capacidades de Cfengine son bastante satisfactorias para el desarrollador, pero para otros administradores es más bien un dolor de cabeza adicional. Para mejorar Cfengine, desarrolladores externos crearon varios complementos, lo que a menudo solo empeoraba la situación. El autor de varios módulos de este tipo para Cfengine, Luke Kanies, finalmente decidió desarrollar una herramienta similar, pero sin muchas de las deficiencias de Cfengine.

Características de la marioneta

Puppet, como Cfengine, es un sistema cliente-servidor que utiliza un lenguaje declarativo para describir tareas y bibliotecas para implementarlas. Los clientes periódicamente (cada 30 minutos de forma predeterminada) se conectan al servidor central y reciben la configuración más reciente. Si las configuraciones recibidas no coinciden con el estado del sistema, se ejecutarán y, si es necesario, se enviará al servidor un informe sobre las operaciones realizadas. El servidor de mensajes puede guardarlo en syslog o en un archivo, crear un gráfico RRD y enviarlo al correo electrónico especificado. Las capas adicionales de abstracción de recursos y transacciones brindan máxima compatibilidad con configuraciones y aplicaciones existentes, lo que le permite concentrarse en los objetos del sistema sin preocuparse por las diferencias en la implementación y descripción de comandos detallados y formatos de archivos. El administrador opera sólo con el tipo de objeto, Puppet se encarga del resto. Por lo tanto, el tipo de paquetes conoce alrededor de 17 sistemas de paquetes; el requerido será reconocido automáticamente en función de la información sobre la versión de la distribución o del sistema, aunque, si es necesario, el administrador de paquetes se puede configurar a la fuerza.

A diferencia de los scripts, que a menudo son imposibles de usar en otros sistemas, las configuraciones de Puppet escritas por administradores externos funcionarán en cualquier otra red prácticamente sin problemas. Puppet CookBook ya tiene tres docenas de recetas preparadas. Actualmente, Puppet admite oficialmente los siguientes sistemas operativos y servicios: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo y MySQL, LDAP.

lenguaje de marionetas

Para avanzar, primero debes comprender los elementos y capacidades básicos del idioma. El lenguaje es uno de los puntos fuertes de Puppet. Describe los recursos que el administrador planea administrar y las acciones que realizan. A diferencia de la mayoría de soluciones similares, Puppet permite que el lenguaje simplifique el acceso a todos los recursos similares en cualquier sistema en un entorno heterogéneo. Una descripción de recurso normalmente consta de un nombre, tipo y atributos. Por ejemplo, señalemos el archivo /etc/passwd y establezcamos sus atributos:

archivo("/etc/contraseña":

Propietario => raíz,

Grupo => raíz,

Modo => 644,

Ahora los clientes que se conecten al servidor copiarán el archivo /etc/passwd y establecerán los atributos especificados. Puede definir varios recursos en una regla separándolos mediante un punto y coma. Pero, ¿qué pasa si el archivo de configuración utilizado en el servidor difiere de los del cliente o no se utiliza en absoluto? Por ejemplo, esta situación puede surgir al configurar conexiones VPN. En este caso, debes apuntar al archivo usando la directiva fuente. Aquí hay dos opciones; puede, como de costumbre, especificar la ruta a otro archivo y también utilizar los dos protocolos URI admitidos: archivo y marioneta. En el primer caso, se utiliza un enlace a un servidor NFS externo; en la segunda opción, se inicia un servicio similar a NFS en el servidor Puppet, que exporta recursos. En el último caso, la ruta predeterminada es relativa al directorio raíz de la marioneta: /etc/puppet. Es decir, el enlace puppet://server.domain.com/config/sshd_config corresponderá al archivo /etc/puppet/config/sshd_config. Puede anular este directorio usando la directiva filebucket, aunque es más correcto usar la sección del mismo nombre en el archivo /etc/puppet/fileserver.conf. En este caso, puede restringir el acceso al servicio sólo a determinadas direcciones. Por ejemplo, describamos la sección de configuración:

Ruta /var/puppet/config

Permitir *.dominio.com

Permitir 127.0.0.1

Permitir 192.168.0.*

Permitir 192.168.1.0/24

Denegar *.wireless.domain.com

Y luego nos referimos a esta sección al describir el recurso:

fuente => "puppet://server.domain.com/config/sshd_config"

Antes de los dos puntos está el nombre del recurso. En los casos más simples, simplemente puede especificar la ruta completa al archivo como nombre. En configuraciones más complejas es mejor utilizar un alias o variables. El alias se establece mediante la directiva alias:

archivo("/etc/contraseña":

Alias => contraseña

Otra opción para crear un alias es buena cuando tienes que trabajar con diferentes sistemas operativos. Por ejemplo, creemos un recurso que describa el archivo sshd_config:

archivo(sshdconfig:

Nombre => $sistema operativo? (

Solaris => "/usr/local/etc/ssh/sshd_config",

Predeterminado => "/etc/ssh/sshd_config"

En este ejemplo, nos enfrentamos a una elección. El archivo para Solaris se especifica por separado; para todos los demás se seleccionará el archivo /etc/ssh/sshd_config. Ahora se puede acceder a este recurso como sshdconfig, dependiendo del sistema operativo se seleccionará la ruta deseada. Por ejemplo, indicamos que si el demonio sshd se está ejecutando y se recibe un nuevo archivo se debe reiniciar el servicio:

servicio(sshd:

Asegurar => verdadero,

Suscríbete => Archivo

Las variables se utilizan a menudo cuando se trabaja con datos de usuario. Por ejemplo, describimos la ubicación de los directorios de inicio de los usuarios:

$homeroot = "/casa"

Ahora se puede acceder a los archivos de un usuario específico como:

$(homeroot)/$nombre

El parámetro $name se completará con el nombre de la cuenta del usuario. En algunos casos es conveniente definir un valor predeterminado para algún tipo. Por ejemplo, para el tipo exec es muy común especificar los directorios en los que se debe buscar el archivo ejecutable:

Ejecutivo (ruta => "/usr/bin:/bin:/usr/sbin:/sbin")

Si necesita apuntar a varios archivos y directorios anidados, puede utilizar el parámetro recursivo:

archivo("/etc/apache2/conf.d":

Fuente => "puppet:// puppet://server.domain.com/config/apache/conf.d",

Recurrencia => "verdadero"

Se pueden combinar varios recursos en clases o definiciones. Las clases son una descripción completa de un sistema o servicio y se utilizan por separado:

clase linux (

Archivo(

"/etc/passwd": propietario => raíz, grupo => raíz, modo => 644;

"/etc/shadow": propietario => raíz, grupo => raíz, modo => 440

Como en los lenguajes orientados a objetos, las clases se pueden anular. Por ejemplo, en FreeBSD el grupo propietario de estos archivos es wheel. Por lo tanto, para no reescribir completamente el recurso, creemos una nueva clase freebsd, que heredará la clase de Linux:

la clase freebsd hereda linux (

Archivo["/etc/passwd"] (grupo => rueda);

Archivo["/etc/shadow"] (grupo => rueda)

Para mayor comodidad, todas las clases se pueden colocar en un archivo separado, que debe incluirse mediante la directiva include. Las definiciones pueden tomar varios parámetros como argumentos, pero no admiten la herencia y se utilizan cuando es necesario describir objetos reutilizables. Por ejemplo, definamos el directorio de inicio del usuario y los comandos necesarios para crear una nueva cuenta:

definir user_homedir ($grupo, $nombre completo, $engrupos) (

Usuario("$nombre":

Asegurar => presente,

Comentario => "$nombre completo",

gid => "$grupo",

Grupos => $engrupos,

Membresía => mínimo,

Shell => "/bin/bash",

Inicio => "/casa/$nombre",

Requerir => Grupo[$grupo],

Exec("$nombre homedir":

Comando => "/bin/cp -R /etc/skel /home/$nombre; /bin/chown -R $nombre:$grupo /home/$nombre",

Crea => "/home/$nombre",

Requerir => Usuario[$nombre],

Ahora, para crear una nueva cuenta, simplemente acceda a user_homedir:

user_homedir("sergej":

Grupo => "sergej",

Nombre completo => "Sergej Jaremchuk",

Grupos internos => ["medios", " admin]

Hay descripciones separadas de los nodos que admiten la herencia, así como de las clases. Cuando un cliente se conecta al servidor Puppet, se buscará la sección del nodo correspondiente y se proporcionarán configuraciones específicas solo para esta computadora. Para describir todos los demás sistemas, puede utilizar el nodo predeterminado. Se proporciona una descripción de todos los tipos en el documento "Referencia de tipos", que debe leerse en cualquier caso, al menos para comprender todas las capacidades del lenguaje Puppet. Varios tipos le permiten ejecutar comandos específicos, incluso cuando se cumplen ciertas condiciones (por ejemplo, cambiar un archivo de configuración), trabajar con cron, credenciales y grupos de usuarios, computadoras, montar recursos, iniciar y detener servicios, instalar, actualizar y eliminar paquetes. , trabajando con claves SSH, zonas Solaris, etc. Así es como puedes forzar fácilmente que la lista de paquetes en distribuciones usando apt se actualice diariamente entre 2 y 4 horas:

horario (diario:

Periodo => diario,

Rango =>

exec("/usr/bin/apt-get update":

Horario => diario

La actualización para ese período la realizará cada sistema solo una vez, después de lo cual la tarea se considerará completada y se eliminará de la computadora cliente. El lenguaje Puppet admite otras estructuras familiares: condiciones, funciones, matrices, comentarios y similares.

Instalación de marionetas

Puppet requiere Ruby (versión 1.8.1 y superior) con soporte OpenSSL y bibliotecas XMLRPC, así como la biblioteca Faster. El repositorio de Ubuntu 7.04 que se utilizó para la instalación de prueba ya incluye el paquete cachorro:

$ sudo marioneta de búsqueda apt-cache

~$ ruby -rxmlrpc/client -e "pone:sí"

sí

Si no se reciben errores, entonces todo lo que necesita ya está incluido. Los archivos que describen la configuración deseada de los sistemas se denominan manifiestos en la terminología de Puppet. Cuando se inicia, el demonio intenta leer el archivo /etc/puppet/manifests/site.pp; si falta, muestra un mensaje de advertencia. Al realizar la prueba, puede indicarle al demonio que se ejecute en modo independiente, lo que no requiere un manifiesto:

$ sudo /usr/bin/puppetmasterd --nonodos

Si es necesario, puede conectar otros archivos a site.pp, por ejemplo, con descripciones de clases. Para una ejecución de prueba, puede ingresar las instrucciones más simples en este archivo.

clase sudo (

Archivo("/etc/sudoers":

Propietario => raíz,

Grupo => raíz,

Modo => 440,

valor predeterminado del nodo (

incluir sudo

Todos los archivos de configuración, tanto del servidor como del cliente, se encuentran en /etc/puppet. El archivo fileserver.conf, del que ya hablamos, es opcional y se usa sólo si Puppet también funcionará como servidor de archivos. En Ubuntu, este archivo exporta el subdirectorio /etc/puppet/files. El subdirectorio ssl contiene certificados y claves que se utilizarán para el cifrado al conectar clientes. Las claves se crean automáticamente la primera vez que ejecutas puppetmasterd; puedes crearlas manualmente con el comando:

$ sudo /usr/bin/puppetmasterd --mkusers

Los archivos Puppetd.conf y Puppetmasterd.conf son similares. Indican algunos parámetros para el funcionamiento de demonios en el sistema cliente y el servidor. El archivo del cliente se diferencia sólo por la presencia del parámetro del servidor, que apunta a la computadora en la que se ejecuta Puppetmasterd:

servidor = molinillo.com

logdir = /var/log/títere

vardir = /var/lib/títere

rundir = /var/ejecutar

# enviar un informe al servidor

informe = verdadero

Para evitar escribir todo manualmente, puedes crear una plantilla usando el propio Puppetd:

$ Puppetd --genconfig > /etc/puppet/puppetd.conf

De manera similar, puedes crear site.pp en el servidor:

$ títeres --genmanifest > /etc/puppet/manifests/site.pp

Otro archivo, tagmail.conf, le permite especificar direcciones de correo electrónico a las que se enviarán los informes. En el caso más simple, puedes usar una línea:

todo: [correo electrónico protegido]

Los archivos de configuración no son suficientes para que el cliente se conecte al servidor. Para ello, también es necesario firmar los certificados.

Primero, para informar al servidor sobre la nueva computadora, ingrese el comando en el sistema cliente:

$ sudo Puppetd --server Grinder.com --waitforcert 60 –prueba

El firewall debe permitir conexiones en el puerto 8140.

En el servidor obtenemos una lista de certificados que deben firmarse:

$ sudo puppetca –lista

nomad.grinder.com

Y firma el certificado de cliente:

$ sudo puppetca –firmar nomad.grinder.com

Ahora el cliente puede conectarse libremente al servidor y recibir la configuración.

Desafortunadamente, es imposible mostrar todas las capacidades de Puppet en el artículo. Pero, como puedes ver, esta es una herramienta funcional y flexible que te permite resolver la mayoría de los problemas de administración simultánea de una gran cantidad de sistemas. Y lo más importante, el proyecto logró reunir una comunidad pequeña pero en constante crecimiento. Por tanto, esperemos que no se permita que una buena idea muera o se quede a un lado.

¡Buena suerte!

Sitio web del proyecto BladeLogic: http://www.bladelogic.com.
El sitio web del proyecto OpsWare es http://www.opsware.com.
El sitio web del proyecto Cfengine es http://www.cfengine.org.
El sitio web del proyecto Puppet es http://receivedlabs.com/projects/puppet.
Libro de cocina de marionetas: http://www.receivedlabs.com/trac/puppet/tagspuppet%2Crecipe.
Biblioteca más rápida –

Administrar una gran cantidad de sistemas Unix no se puede considerar conveniente. Para cambiar un parámetro, el administrador debe comunicarse con cada máquina; los scripts solo pueden ayudar parcialmente y no en todas las situaciones.

Hay que reconocer que los administradores de red de Windows todavía se encuentran en una posición más ventajosa. Basta con cambiar la configuración de la política de grupo y después de un tiempo todos los ordenadores de la red, incluidos aquellos con un sistema operativo instalado recientemente, “aprenderán” sobre la innovación, si les concierne, por supuesto. Mirando hacia atrás, al largo período de desarrollo de Unix, notará que nada como esto nunca tuvo éxito. Existen soluciones como kickstart que ayudan con la instalación inicial del sistema operativo, pero un mayor desarrollo requerirá un esfuerzo significativo. Las soluciones comerciales como BladeLogic y OpsWare solo resuelven parcialmente el problema de la automatización de la configuración; su principal ventaja es la presencia de una interfaz gráfica y solo se pueden adquirir en grandes organizaciones. Por supuesto, hay proyectos que ofrecen soluciones gratuitas, pero a lo largo de su existencia nunca han podido crear una gran comunidad. Por ejemplo, Cfengine no es muy popular entre los administradores, aunque además de Linux, se puede utilizar en *BSD, Windows y Mac OS X. Esto puede deberse a la relativa complejidad de la creación de configuraciones. Al describir las tareas, es necesario tener en cuenta las características de cada sistema específico y controlar manualmente la secuencia de acciones al ejecutar comandos. Es decir, el administrador debe recordar que para algunos sistemas debe escribir adduser, para otros useradd, tener en cuenta la ubicación de los archivos en diferentes sistemas, etc. Esto complica en gran medida el proceso de escritura de comandos; es muy difícil crear la configuración correcta sobre la marcha y es casi imposible leer las configuraciones creadas después de un tiempo. A pesar de la licencia GPL, Cfengine es en realidad un proyecto de una sola persona que controla todos los cambios y no está muy interesado en construir una sociedad abierta. Como resultado, las capacidades de cfengine son bastante satisfactorias para el desarrollador, pero para otros administradores es más bien un dolor de cabeza adicional. Para mejorar cfengine, desarrolladores externos crearon varios complementos, lo que a menudo sólo empeoraba la situación. El autor de varios de estos módulos de cfengine, Luke Kanies, finalmente decidió desarrollar una herramienta similar, pero sin muchas de las deficiencias de cfengine.

Características de la marioneta

Puppet, como cfengine, es un sistema cliente-servidor que utiliza un lenguaje declarativo, es decir, obligatorio para describir tareas y bibliotecas para su implementación. Los clientes periódicamente (30 minutos de forma predeterminada) se conectan al servidor central y reciben la configuración más reciente. Si las configuraciones recibidas no coinciden con el estado del sistema, se ejecutarán y, si es necesario, se enviará al servidor un informe sobre las operaciones realizadas. El servidor puede guardar mensajes en syslog o en un archivo, crear un gráfico RRD y enviarlos a un correo electrónico específico. Las capas adicionales de abstracción de recursos y transacciones brindan máxima compatibilidad con configuraciones y aplicaciones existentes, lo que le permite concentrarse en los objetos del sistema sin preocuparse por las diferencias en la implementación y descripción de comandos detallados y formatos de archivo. El administrador opera sólo con el tipo de objeto, Puppet se encarga del resto. Por lo tanto, el tipo de paquete conoce alrededor de 17 sistemas de paquetes; el requerido será reconocido automáticamente en función de la información sobre la versión de la distribución o del sistema, aunque, si es necesario, el administrador de paquetes se puede configurar a la fuerza.

A diferencia de los scripts, que a menudo no se pueden utilizar en otros sistemas, las configuraciones de Puppet escritas por administradores externos funcionarán, en su mayor parte, sin problemas en cualquier otra red. En Libro de cocina de marionetas [ http://www.reductionlabs.com/trac/puppet/tags/puppet%2Crecipe] ya existen tres docenas de recetas preparadas. Actualmente, Puppet admite oficialmente los siguientes sistemas operativos y servicios: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo y MySQL, LDAP.

lenguaje de marionetas

Para avanzar, primero debes comprender los elementos y capacidades básicos del idioma. El lenguaje es uno de los puntos fuertes de Puppet. Con su ayuda se describen los recursos que el administrador planea gestionar y las acciones. A diferencia de la mayoría de soluciones similares, Puppet permite que el lenguaje simplifique el acceso a todos los recursos similares en cualquier sistema en un entorno heterogéneo. Una descripción de recurso normalmente consta de un nombre, tipo y atributos. Por ejemplo, señalemos el archivo /etc/passwd y establezcamos sus atributos:

archivo("/etc/contraseña":

propietario => raíz,

grupo => raíz,

Ahora los clientes, una vez conectados al servidor, copiarán el archivo /etc/passwd e instalarán los atributos especificados. Puede definir varios recursos en una regla separándolos mediante un punto y coma. ¿Qué hacer si el archivo de configuración utilizado en el servidor difiere de los del cliente o no se utiliza en absoluto? Por ejemplo, esta situación puede surgir al configurar conexiones VPN. En este caso, se puede señalar el archivo utilizando la directiva fuente. Aquí hay dos opciones, como es habitual, para especificar la ruta a otro archivo; también se admiten dos protocolos URI: archivo y marioneta. En el primer caso, se utiliza un enlace a un servidor NFS externo, en la segunda opción, se inicia un servicio similar a NFS en el servidor Puppet, que exporta recursos. En el último caso, la ruta predeterminada es relativa al directorio raíz del títere: /etc/puppet. Es decir, el enlace puppet://server.domain.com/config/sshd_config corresponderá al archivo /etc/puppet/config/sshd_config. Puede anular este directorio usando la directiva filebucket, aunque es más correcto usar la sección del mismo nombre en el archivo /etc/puppet/fileserver.conf. En este caso, podrá restringir el acceso al servicio sólo desde determinadas direcciones. Por ejemplo, describamos la sección de configuración.

ruta /var/puppet/config

permitir *.dominio.com

permitir 192.168.0.*

permitir 192.168.1.0/24

Denegar *.dominio.inalámbrico.com

Y luego pasamos a esta sección cuando describimos el recurso.

fuente => "puppet://server.domain.com/config/sshd_config"

Antes de los dos puntos está el nombre del recurso. En los casos más simples, simplemente puede especificar un alias o variables como nombre. El alias se establece mediante la directiva alias. ruta completa al archivo. En configuraciones más complejas

archivo("/etc/contraseña":

alias => contraseña

Otra opción para crear un alias es buena cuando tienes que trabajar con diferentes sistemas operativos. Por ejemplo, creemos un recurso que describa el archivo sshd_config:

archivo(sshdconfig:

nombre => $sistema operativo? (

solaris => "/usr/local/etc/ssh/sshd_config",

predeterminado => "/etc/ssh/sshd_config"

asegurar => verdadero,

suscribirse => Archivo

Las variables se utilizan a menudo cuando se trabaja con datos de usuario. Por ejemplo, describimos la ubicación de los directorios de inicio de los usuarios:

$homeroot = "/casa"

Ahora se puede acceder a los archivos de un usuario específico como

$(homeroot)/$nombre

El parámetro $name se completará con el nombre de la cuenta del usuario. En algunos casos es conveniente definir un valor predeterminado para algún tipo. Por ejemplo, para el tipo exec, suelen indicar los directorios en los que se debe buscar el archivo ejecutable:

Ejecutivo (ruta => "/usr/bin:/bin:/usr/sbin:/sbin")

Si necesita apuntar a varios archivos y directorios anidados, puede utilizar el parámetro recursivo.

archivo("/etc/apache2/conf.d":

fuente => “títere://títere://servidor.dominio.com/config/apache/conf.d”,

recursivo => "verdadero"

Se pueden combinar varios recursos en clases o definiciones. Las clases son una descripción completa de un sistema o servicio y se utilizan por separado.

"/etc/passwd": propietario => raíz, grupo => raíz, modo => 644;

"/etc/shadow": propietario => raíz, grupo => raíz, modo => 440

la clase freebsd hereda linux (

Archivo[“/etc/passwd”] (grupo => rueda);

Archivo[“/etc/shadow”] (grupo => rueda)

Para mayor comodidad, todas las clases se pueden colocar en un archivo separado, que se puede conectar mediante la directiva de inclusión. Las definiciones pueden tomar varios parámetros como argumentos, pero no admiten la herencia y se utilizan cuando es necesario describir objetos reutilizables. Por ejemplo, definamos el directorio de inicio de los usuarios y los comandos necesarios para crear una nueva cuenta.

definir user_homedir ($grupo, $nombre completo, $engrupos) (

usuario("$nombre":

asegurar => presente,

comentario => "$nombre completo",

gid => "$grupo",

grupos => $engrupos,

membresía => mínimo,

cáscara => "/bin/bash",

inicio => "/inicio/$nombre",

requerir => Grupo[$grupo],

exec("$nombre homedir":

comando => “/bin/cp -R /etc/skel /home/$nombre; /bin/chown -R $nombre:$grupo /home/$nombre",

crea => "/home/$nombre",

requerir => Usuario[$nombre],

Ahora, para crear una nueva cuenta, simplemente comuníquese con user_homedir.

user_homedir("sergej":

grupo => "sergej",

nombre completo => “Sergej Jaremchuk”,

grupos internos => ["medios", "admin]

Hay descripciones separadas de nodos que admiten clases tipo herencia. Cuando el cliente se conecta al servidor Puppet, se buscará la sección del nodo correspondiente y se proporcionarán configuraciones específicas solo para esta computadora. Para describir todos los demás sistemas, puede utilizar el nodo predeterminado. Se proporciona una descripción de todos los tipos en el documento "Referencia de tipos", que debe leerse en cualquier caso, al menos para comprender todas las capacidades del lenguaje Puppet. Varios tipos le permiten ejecutar comandos específicos, incluso cuando se cumplen ciertas condiciones (por ejemplo, cambiar un archivo de configuración), trabajar con cron, credenciales y grupos de usuarios, computadoras, montar recursos, iniciar y detener servicios, instalar, actualizar y eliminar paquetes. , trabajando con claves SSH, zonas Solaris, etc. Así de fácil es forzar que la lista de paquetes en distribuciones usando apt se actualice todos los días entre 2 y 4 horas.

horario (diario:

período => diario,

rango =>

exec("/usr/bin/apt-get update":

horario => diario

Instalación de marionetas

Puppet requiere Ruby (>= 1.8.1) con soporte OpenSSL y bibliotecas XMLRPC, así como la biblioteca Faster [ http://reductionlabs.com/projects/facter]. El repositorio de Ubuntu 7.04 que se utilizó para la instalación de prueba ya incluía el paquete cachorro.

$ sudo marioneta de búsqueda apt-cache

Puppet: gestión de configuración centralizada para redes.

Puppetmaster - demonio de control de gestión de configuración centralizada

Durante la instalación, se instalarán todos los paquetes de dependencia necesarios: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get instalar Puppet Puppetmaster

Puede comprobar la disponibilidad de las bibliotecas Ruby con el comando.

$ ruby -ropenssl -e "pone:si"

~$ ruby -rxmlrpc/client -e "pone:sí"

Si no se reciben errores, entonces todo lo que necesita ya está incluido. Los archivos que describen la configuración deseada de los sistemas se denominan manifiestos en la terminología de Puppet. Cuando se inicia, el demonio intenta leer el archivo /etc/puppet/manifests/site.pp; si falta, muestra un mensaje de advertencia. Al realizar la prueba, puede indicarle al demonio que funcione en modo fuera de línea, en cuyo caso no se requiere el manifiesto.

$ sudo /usr/bin/puppetmasterd --nonodos

Si es necesario, puede conectar otros archivos a site.pp, por ejemplo con descripciones de clases. Para una ejecución de prueba, puede ingresar las instrucciones más simples en este archivo.

archivo("/etc/sudoers":

propietario => raíz,

grupo => raíz,

Todos los archivos de configuración tanto para el servidor como para los clientes se encuentran en /etc/puppet. El archivo fileserver.conf del que hablamos anteriormente es opcional y se usa solo si Puppet también funcionará como servidor de archivos. En Ubuntu, este archivo exporta el subdirectorio /etc/puppet/files. El subdirectorio ssl contiene certificados y claves que se utilizarán para el cifrado al conectar clientes. Las claves se crean automáticamente la primera vez que inicias Puppetmasterd; puedes crearlas manualmente con el comando.

$ sudo /usr/bin/ puppetmasterd --mkusers.

servidor = molinillo.com

logdir = /var/log/títere

vardir = /var/lib/títere

rundir = /var/ejecutar

# enviar un informe al servidor

Para evitar escribir todo manualmente, puedes crear una plantilla usando el propio Puppetd.

$ Puppetd --genconfig > /etc/puppet/puppetd.conf

De manera similar, puede crear site.pp en el servidor.

$ títeres --genmanifest > /etc/puppet/manifests/site.pp

Otro archivo, tagmail.conf, le permite especificar las direcciones de correo electrónico a las que se enviarán los informes. En el caso más sencillo, puedes utilizar una línea.

todo: [correo electrónico protegido]

Los archivos de configuración no son suficientes para que el cliente se conecte al servidor. Para ello, también es necesario firmar los certificados. Primero, para informar al servidor sobre la nueva computadora en el sistema cliente, ingrese el comando:

$ sudo Puppetd --server Grinder.com --waitforcert 60 --test

información: Solicitando certificado

Advertencia: el certificado de pares no se verificará en esta sesión SSL

aviso: No recibí el certificado

Si se devuelve una línea diferente, debe verificar el funcionamiento del servidor.

$ ps auxiliar | marioneta grep

marioneta 5779 0,0 1,4 27764 15404 ? Ssl 21:49 0:00 rubí /usr/sbin/puppetmasterd

El firewall debe permitir conexiones en el puerto 8140.

En el servidor recibimos una lista de certificados que deben firmarse.

$ sudo puppetca --lista

nomad.grinder.com

Y firmamos el certificado de cliente.

$ sudo puppetca –firmar nomad.grinder.com

Ahora el cliente puede conectarse libremente al servidor y recibir la configuración.

Desafortunadamente, simplemente no es posible mostrar todas las capacidades de Puppet en el artículo. Pero como puedes ver, esta es una herramienta funcional y flexible que te permite resolver la mayoría de los problemas de administración simultánea de una gran cantidad de sistemas. Si su línea de trabajo requiere que configure varios sistemas. Y lo más importante, el proyecto logró reunir una comunidad pequeña pero en constante crecimiento. Por tanto, esperemos que no se permita que una buena idea muera o se quede a un lado.

Un poco de poesía. Parecería que este artículo debería ser el punto de partida de toda la serie, pero el público objetivo son aún los usuarios más experimentados de los productos Open Source Puppet Labs que no están satisfechos con los módulos individuales mal integrados con Puppet Forge. Como ocurre con cualquier caso de “biblioteca versus marco”, el precio a pagar es seguir la visión del mundo del autor de la solución integrada.

Un poco sobre cómo funciona Puppet

Puppet es principalmente un lenguaje específico para especificar declarativamente el estado final del sistema. A modo de comparación, es muy adecuado el GNU Makefile, donde, además de la descripción directa de las dependencias, es posible volverse extraño al máximo.

La abstracción de Puppet es algo como esto ( rompiendo patrones: ¡olvídate de todo lo que sabías sobre términos de programación!).

Nodo es un conjunto de configuraciones para un sistema de destino específico. De hecho, este es un caso especial de clase.
Clase es un conjunto de lógica declarativa que se incluye en la configuración del nodo u otras clases. La clase no tiene instancias ni métodos, pero tiene parámetros y variables definidos dentro de la lógica. De hecho, es más bien un procedimiento que puede heredar otro procedimiento simplemente agregando código y teniendo un alcance de variables no tan banal.
Tipo- pero esto se parece más a una clase clásica: asume instancias con un nombre y parámetros definitivamente especificados, pero nada más. Una implementación específica de un tipo se puede escribir como un script Puppet a través de define, que crea instancias de otros tipos, o como una extensión de Ruby con un toque de fantasía.
Recurso- en realidad se trata de instancias nombradas de tipos. Cada nombre de recurso es único dentro de un tipo específico dentro de la configuración del nodo (directorio).
variables- Bueno, en resumen, son constantes... Antes de Puppet 4, las cosas eran aún peores con su alcance. Ahora es adecuado: para uso desde fuera de la ubicación de la definición, se debe especificar un identificador completamente calificado, excepto en el caso de herencia de clases.

Puppet se puede utilizar para implementación local sin una red o infraestructura asociada. Esto se puede utilizar para crear imágenes de contenedor. Incluso existe todo un movimiento que aboga por el abandono de un servidor centralizado.

De una manera ideológicamente correcta, la infraestructura Puppet consta de un agente (un servicio privilegiado en el sistema de destino) y un servidor que distribuye instrucciones valiosas en forma de directorios de recursos declarativos a petición de los agentes. La seguridad se implementa a nivel de infraestructura de clave pública privada (X.509). En pocas palabras, los mismos mecanismos que en HTTPS, pero con su propia CA y verificación obligatoria del certificado del cliente.

De forma simplificada, el procedimiento de implementación se parece a este:

Procesamiento vía TLS y X.509 (establecimiento de conexión, actualización de CRL, verificación de restricciones de certificados, etc.)
El agente recibe generadores de datos del servidor con almacenamiento en caché y todo eso (más precisamente, todo se extrae de las carpetas lib/ en los módulos). No es difícil agregar su propio script Ruby para recopilar la información de interés.
El agente recopila datos sobre el sistema de destino y los envía al servidor. Todos los datos se pueden ver fácilmente de forma manual a través de la llamada de datos de títeres. Estos hechos están disponibles como variables globales.
El servidor compila un catálogo de recursos y lo envía al agente. Debajo de esto se esconde toda una capa de conceptos diferentes.
El agente extrae todo lo necesario del servidor y lleva el sistema al formato especificado. El agente en sí no sabe qué hacer con los recursos; depende de la implementación de proveedores (la traducción semántica será "implementador", no proveedor) de tipos específicos de recursos. Algunos proveedores son estándar y están incluidos en los paquetes Puppet. el resto se extraen de los módulos.

Para disfrutar de todas las delicias, existen bollos adicionales en forma de:

Módulo- una colección de scripts declarativos de Puppet, extensiones Ruby para Puppet, archivos, plantillas de archivos, datos de Hiera y mucho más. Un término más correcto sería "paquete".
Ambiente- un conjunto de scripts, módulos y datos de Hiera. A medida que la infraestructura se volvió más compleja, inevitablemente se hizo necesario dividir la configuración más allá de la división estándar por nodos. Básicamente, esto es necesario para innovaciones piloto y control de acceso banal (cuando no todos los administradores tienen acceso a todos los nodos de la infraestructura de TI).
hiera- base de datos jerárquica. Esta formulación puede resultar muy intimidante. Probablemente esta sea la razón por la que se cambió en la documentación de versiones posteriores. De hecho, este es un mecanismo extremadamente simple y conveniente para extraer la configuración de archivos YAML o JSON. La jerarquía es la capacidad de especificar el orden de lectura de múltiples archivos de configuración, es decir, jerarquía/prioridad de estos archivos.
- Además de extraer datos sobre llamadas a funciones, Puppet extrae parámetros de clase predeterminados, que es lo más destacado.
- Por supuesto, Hiera admite la interpolación de hechos e incluso la llamada a funciones especiales.
- En Puppet 4.3 implementaron nuevamente la misma funcionalidad para soportar no solo la base de datos global, sino también la local para el Entorno y el Módulo, aunque el autor ya ha encontrado varios problemas en su implementación (PUP-5983, PUP-5952 y PUP-5899), que fueron solucionados instantáneamente por Puppet Labs.
- Se admiten varias estrategias para extraer valores de todos los archivos de la jerarquía:
  - primero: se devuelve el primer valor encontrado por prioridad
  - único: recopila todos los valores en una matriz unidimensional y elimina duplicados
  - hash: combina todos los YAML Hash encontrados. Las claves duplicadas se seleccionan por prioridad.
  - deep es esencialmente una versión recursiva de hash
- Lo bueno es que la estrategia de muestreo se puede establecer llamando a la función lookup(), porque y en cualquier archivo de jerarquía a través de la clave especial lookup_options, que se utiliza activamente en el módulo cfnetwork.
PuppetDB- esencialmente una capa de lógica de negocios alrededor de una base de datos relacional (PostgreSQL), que le permite guardar informes sobre hechos e implementaciones realizadas y exportar recursos para su posterior importación a directorios en otros nodos o selección a través de funciones especiales. También hay una interfaz web en forma de Puppet Dashboard.
PKI X.509- la infraestructura de certificados ya mencionada, que es extremadamente cómoda de utilizar para otros servicios sin necesidad de gestionar una infraestructura independiente.
MColectivo- parece algo útil para el lanzamiento de tareas basadas en eventos en una granja de servidores, pero el autor tiene cierta desconfianza en la seguridad de una solución en particular.
Forja de marionetas- una plataforma abierta para publicar y descargar módulos.
algunas otras características en forma de administración de dispositivos externos, como equipos Cisco e implementación en bare metal, pero esa es una historia diferente

Notas sobre seguridad y accesibilidad

Debe comprender que Puppet Server se convierte en un punto vulnerable de toda la infraestructura de TI, porque... determina la configuración final de todos los sistemas. En casos especiales, tiene sentido hacer una separación: un servidor separado para los elementos críticos de la infraestructura con acceso extremadamente limitado y actualización manual, y un segundo servidor para todo lo demás.

La disponibilidad de Puppet Server determina la capacidad de gestionar toda la infraestructura. Tiene sentido alojar Puppet Server en una máquina virtual en una nube de terceros más confiable y rápidamente recuperable que sus propias capacidades. O deberías instalar varios servidores.

En cualquier caso, no debe instalar otros servicios en el sistema donde se implementará Puppet Server con campanas y silbidos. La virtualización y la contenedorización pueden ayudarle.

Multi-master (varios servidores Puppet separados)

En este caso, solo un servidor actúa como CA (Autoridad de certificación); su falta de disponibilidad significa que es imposible agregar nuevos nodos.
- Puppet le permite utilizar una infraestructura X.509 de terceros si la integrada no es satisfactoria.
Toda la configuración (Entorno) debe almacenarse en un sistema de control de versiones e implementarse en cada servidor simultáneamente.
Lo único en común es la base de datos PostgreSQL, cuya organización de alta disponibilidad está fuera del alcance de este artículo.
El módulo cfpuppetserver admite instalaciones como servidor primario (con CA) y secundario.

¿Qué ha cambiado significativamente desde las versiones anteriores?

El fabricante tiene una descripción completa.

Todos los servicios se han trasladado a JVM, JRuby y Jetty. A pesar de las ventajas obvias de la integración, también existen desventajas en términos de consumo de memoria.
Se han agregado funciones Lambda para procesar colecciones; ahora no es necesario cortar muletas en Ruby o pervertir mediante create_resources()
Ha aparecido una herramienta para procesar plantillas EPP, esencialmente el mismo ERB, pero con Puppet DSL en lugar de Ruby.
La estructura de directorios predeterminada de los archivos de configuración ha cambiado significativamente
Se agregó soporte para proveedores de datos para entornos y módulos (ya no se requieren hacks).
Minimizar el papel de la Hiera global. El comando nuevo y relacionado es la búsqueda de marionetas.

Instalación

Este proceso es bastante primitivo, pero requiere seguir una determinada secuencia de pasos. Dado que hacer esto manualmente es una tarea ingrata, el autor le enseñará algo malo: descargar scripts incomprensibles de Internet y ejecutarlos como root en su sistema.

Los tres componentes principales del servidor son el propio Puppet Server, PuppetDB y PostgreSQL. Todos ellos pueden agruparse en un nodo o dividirse en dos o tres sistemas. Puppet Server y Puppet DB se pueden ejecutar varias veces, pero PostgeSQL es un único punto de falla. Hay varios enfoques para la replicación y agrupación de PostgeSQL. Un enfoque conveniente en el caso de los servidores principal y secundario sería Maestro + Esclavo de solo lectura, que es compatible con PuppetDB como nodo de base de datos principal y de solo lectura, pero lo automatiza. una configuración lleva tiempo y por lo tanto aún no está disponible incluida en el módulo cfpuppetserver.

La configuración en sí puede simplemente almacenarse en el sistema de archivos junto con Puppet Server, pero esto es como escribir scripts en un servidor web de combate. La solución más adecuada es un repositorio git. La utilidad r10k puede extraer todas las ramas del repositorio e implementarlas en Puppet Server como entornos separados. r10k es bastante malo para extraer dependencias, por lo que se usa bibliotecario-puppet encima. Vale la pena señalar de inmediato que el principal entorno títere canónico es la "producción". Por lo tanto, el repositorio de configuración debería utilizar una rama llamada "producción" en lugar de "maestra".

Requisitos del sistema

El hardware lo describe el propio fabricante. El módulo cfpuppetserver actualmente solo es compatible con Debian Jessie+ y Ubuntu Trusty+.

Configuración en Git

Para el r10k en sí, la ubicación del repositorio no importa mucho; lo principal es su disponibilidad. Por ejemplo, para fines de prueba, el repositorio podría alojarse en el mismo sistema y accederse a él a través de file://. Un buen lugar para comenzar es el ejemplo de configuración codingfuture/puppet-exampleenv.

Clonación del repositorio: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Establecemos configuraciones generales para el acceso de administrador usando los consejos en los comentarios:
- $EDITOR datos/common.yaml
Creemos una configuración de nodo:
- $MY_DOMAIN: nombre de dominio raíz (por ejemplo, ejemplo.org)
- $HOST_NAME: nombre de host del cliente sin dominio
- datos mkdir/$MY_DOMAIN
- cp datos/ejemplo.com/puppet.yaml datos/$(MI_DOMINIO)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - configurar un nodo con Puppet Server según las sugerencias de los comentarios
- cp datos/ejemplo.com/host.yaml datos/$(MI_DOMINIO)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - configuración de un nodo arbitrario basado en sugerencias en los comentarios
Lo enviamos a nuestro propio servidor Git o lo hacemos disponible localmente en un nodo con Puppet Server a través de rsync o scp. Un repositorio local es conveniente como paso intermedio hasta que el servidor Git se implemente desde Puppet. En cierto sentido, esto recuerda a montar un compilador en varias etapas.

Instalación desde cero en un sistema limpio

El módulo cfpuppetserver le permite instalar todo usando Puppet, pero para la instalación inicial, las operaciones básicas se duplican mediante un script Bash.

En el sistema de destino:

Descargue el script de instalación: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Revisamos el script y fruncimos el ceño: menos setup_puppetserver.sh
Ejecutar: bash setup_puppetserver.sh
marioneta.$(MY_DOMAIN) .
- Ejemplo con un repositorio remoto: bash setup_puppetserver.sh ssh:// [correo electrónico protegido]/conf-títere
- Ejemplo con local: bash setup_puppetserver.sh file:///root/puppetconf/
Vemos como el sistema se hincha y no instala todo muy rápido.
Si el repositorio es remoto:
- Cree una clave SSH para root: ssh-keygen -t rsa -b 2048
- Registramos la clave pública /root/.ssh/id_rsa.pub en el servidor Git remoto...
- ... y allí configuramos un gancho Git llamando al siguiente comando: /usr/bin/ssh -T desplegarpuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Comenzamos a implementar la configuración manualmente: /etc/puppetlabs/deploy.sh
Probemos cómo funciona en el servidor: /opt/puppetlabs/bin/puppet agent --test
Verifique su red, filtro de red y configuración de acceso SSH

Agregar nodos administrados

El nombre completo del servidor Puppet debe estar disponible a través de DNS en el host administrado o codificado en /etc/hosts.
- Ejemplo: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
En el nodo con Puppet Server, ejecute el siguiente script /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Copie el resultado completo y péguelo en la línea de comando del sistema de destino.
Esperamos el final de la ejecución y ejecutamos /opt/puppetlabs/bin/puppet agent --test . Tras el primer lanzamiento, se generará una solicitud de firma de certificado.
Nos dirigimos al nodo Puppet Server para firmar el certificado.
- Lista de certificados de títeres: verificamos la firma del certificado para detectar paranoia adicional.
- signo de certificado de marioneta $(HOST_NAME).$(MY_DOMAIN) - en realidad, firmamos el certificado.
Regresamos al nodo administrado y ejecutamos: /opt/puppetlabs/bin/puppet agent --test` nuevamente. Esto forzará el inicio del procedimiento de implementación.
Estamos esperando que se complete la implementación a través de Puppet Agent.
Eso es todo, ¡tienes lista una infraestructura mínima de Puppet!

Ejemplo de salida de /root/genclientinit.sh

intento</etc/cflocation fi si prueba! -z ""; luego echo -n >/etc/cflocationpool fi si prueba! -z "\$http_proxy"; luego exporte http_proxy exporte https_proxy="\$http_proxy" exporte HTTP_PROXY="\$http_proxy" exporte HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname nombre de host host.example.com si! cual lsb-liberación | leer; luego apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; luego haga eco "Error al detectar el nombre en clave correcto" salida 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1-\$(codename) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<Puppet cert sign host.example.com" echo "Utilice CTRL+C para detener el ciclo, si falla por diferentes motivos" dormir 5 hecho EOT

Descripción del módulo

Lista completa de parámetros de Bash para el script de instalación inicial

~# ./setup_puppetserver.sh Uso: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - URI del repositorio de Git
certname: nombre de dominio completo del host
cflocation - inicialización del hecho cf_location
cflocationpool - inicialización del hecho cf_location_pool
http_proxy: servidor proxy para solicitudes HTTP y HTTPS

Lista completa de parámetros de Bash para el script de inicio del cliente Puppet

~# /root/genclientinit.sh Uso: ./genclientinit.sh [ [ []]]
El significado de los parámetros es el mismo que en el script anterior.

clase cfpuppetserver

implementaruser = "deploypuppet" - nombre de usuario para implementar automáticamente actualizaciones de configuración
desplegaruser_auth_keys = undef - lista de claves para $deployuser
repo_url = undef - URI del repositorio (ejemplo: ssh://user@host/repo o file:///some/path)
Puppetserver = true: si se debe instalar el componente Puppet Server en este nodo
Puppetdb = true: si se debe instalar el componente PuppetDB en este nodo
Puppetdb_port = 8081 - puerto para PuppetDB
setup_postgresql = true: si se debe instalar el componente PostgreSQL en este nodo (solo si la instalación de PuppetDB está habilitada)
service_face = "cualquiera" - nombre del recurso cfnetwork::iface para aceptar conexiones entrantes
Puppetserver_mem = auto - RAM para Puppet Server en megabytes (mínimo 192 MB)
puppetdb_mem = auto - RAM para PuppetDB en megabytes (mínimo 192 MB)
postgresql_mem = auto - RAM para PostgreSQL en megabytes (mínimo 128 MB)

clase cfpuppetserver::puppetdb

postgresql_host = "localhost" - dirección de la base de datos
postgresql_listen = $postgresql_host - el valor va directamente a la directiva de PostgreSQL listening_addresses
postgresql_port = 5432 - puerto de base de datos
postgresql_user = "puppetdb" - Usuario de PuppetDB en la base de datos
postgresql_pass = "puppetdb" - contraseña del usuario de PuppetDB en la base de datos
postgresql_ssl = false: habilita el cifrado de conexión basado en certificados Puppet PKI

clase cfpuppetserver::puppetserver

autosign = false - NO DEBE usarse en un entorno de combate, excepto quizás en la DMZ. Existe exclusivamente para la automatización de pruebas.
global_hiera_config = "cfpuppetserver/hiera.yaml" - la ruta al archivo de configuración predeterminado de Hiera según los cánones de Puppet (el primer componente es el nombre del módulo, el resto es la ruta debajo de los archivos/carpeta en el módulo)

Puedes ayudar y transferir algunos fondos para el desarrollo del sitio.

Para utilizar Puppet de forma más eficaz, es necesario comprender cómo se crean los módulos y manifiestos. Este tutorial le explicará cómo funcionan estos componentes de Puppet configurando una pila LAMP en un servidor Ubuntu 14.04.

Requisitos

Instalando Puppet (maestro y agente). Más sobre esto -.
La capacidad de crear al menos un servidor virtual Ubuntu 14.04 para servir al nodo del agente Puppet.

Conceptos básicos del código títere

Recursos

El código títere se compone principalmente de recursos. Un recurso es un fragmento de código que describe el estado del sistema y determina los cambios que necesita. Por ejemplo:

usuario("mitchell":
asegurar => presente,
uid => "1000",
gid => "1000",
cáscara => "/bin/bash",
casa => "/casa/mitchell"
}

La declaración de recursos tiene el siguiente formato:

tipo_recurso("nombre_recurso"
atributo => valor
...
}

Para ver todos los tipos de recursos de Puppet, emita el comando:

recurso de marionetas --tipos

Aprenderá más sobre los tipos de recursos en esta guía.

Manifiestos

Un manifiesto es un guión de orquestación. Los programas títeres con extensión .pp se denominan manifiestos. El manifiesto de Puppet predeterminado es /etc/puppet/manifests/site.pp.

Clases

Como en cualquier lenguaje de programación normal, las clases son responsables de organizar y reutilizar partes de la orquestación.

Dentro de una definición de clase hay un bloque de código que describe cómo funciona la clase. Una vez que define una clase, puede usarla en manifiestos.

La definición de clase tiene el siguiente formato:

clase ejemplo_clase(
...
código
...
}

Este código define la clase example_class. El código Puppet estará entre llaves.

Una declaración de clase es el lugar del código donde se llama a una clase particular. Con una declaración de clase, Puppet procesa su código.

La declaración de clase puede ser ordinaria y por tipo de recurso.

Se agrega una declaración de clase regular al código usando la palabra clave include.

incluir clase_ejemplo

Cuando se declara como tipo de recurso, la clase se declara en formato de recurso:

clase("ejemplo_clase":)

Esta declaración le permite agregar parámetros de clase a su código que anulan los valores predeterminados de los atributos de clase. Por ejemplo:

nodo "host2" (
clase ("apache": ) # usar el módulo apache
apache::vhost ( "ejemplo.com": # define el recurso vhost
puerto => "80",
docroot => "/var/www/html"
}
}

Módulos

Un módulo es un grupo de manifiestos y otros archivos organizados de una manera predefinida que facilita compartir y reutilizar partes individuales de la orquestación. Los módulos ayudan a organizar el código Puppet porque se pueden usar para separar el código en múltiples manifiestos.

Los módulos Puppet se almacenan en el directorio /etc/puppet/modules.

Escribiendo un manifiesto

Puede practicar la escritura de manifiestos, módulos y clases de Puppet usando el ejemplo de instalación de una pila LAMP en un servidor Ubuntu (el resultado será).

Entonces, para organizar un servidor Ubuntu 14.04 e instalar una pila LAMP en él, necesita recursos para las siguientes acciones:

instalando el paquete apache2.
iniciando el servicio apache2.
instalando el paquete del servidor MySQL, mysql-server.
iniciando el servicio mysql.
instalando el paquete php5
creando un script de prueba PHP, info.php.
actualizando el índice apt antes de instalar cada paquete.

A continuación encontrará tres ejemplos de código Puppet que se pueden utilizar para lograr dicha configuración de pila LAMP.

El primer ejemplo le enseñará cómo escribir manifiestos básicos en un archivo. El segundo ejemplo le ayudará a ensamblar y utilizar una clase y un módulo basados en manifiestos escritos previamente. El tercer ejemplo le mostrará cómo utilizar módulos públicos prediseñados para instalar una pila LAMP.

Nota: Para realizar pruebas, es mejor utilizar un servidor virtual nuevo.

Ejemplo 1: instalación de LAMP con un manifiesto

El manifiesto de Puppet se puede escribir en el nodo del agente y luego ejecutarse usando el comando de aplicación de Puppet (no es necesario tener una configuración maestra y de agente para hacer esto).

En esta sección, aprenderá a escribir manifiestos que utilizarán estos tipos de declaraciones de recursos:

exec: Ejecuta comandos.
paquete: instalar paquetes.
servicio: gestión de servicios.
archivo: gestión de archivos.

Creando un manifiesto

Crea un nuevo manifiesto:

sudo vi /etc/puppet/manifests/lamp.pp

Agregue el siguiente código para declarar los recursos necesarios.

# ejecuta el comando "apt-get update"
ejecutivo ("apt-update": # recurso ejecutivo "apt-update"
comando => "/usr/bin/apt-get update" # comando que ejecutará este recurso
}
# instalar el paquete apache2
paquete("apache2":
require => Exec["apt-update"], # solicita "apt-update" antes de instalar el paquete
asegurar => instalado,
}
# iniciar el servicio apache2
servicio("apache2":
asegurar => corriendo,
}
# instalar el servidor mysql
paquete("servidor-mysql":
require => Exec["apt-update"], # solicita "apt-update" reinstalando
asegurar => instalado,
}
# iniciar el servicio mysql
servicio("mysql":
asegurar => corriendo,
}
# instalar el paquete php5
paquete("php5":
require => Exec["apt-update"], # solicita "apt-update" antes de la instalación
asegurar => instalado,
}
# iniciar el servicio info.php
archivo("/var/www/html/info.php":
asegurar => archivo,
contenido => "", # código phpinfo
require => Paquete["apache2"], # solicitud del paquete "apache2"
}

Aplicando un manifiesto

Para usar el nuevo manifiesto, ingrese el comando:

aplicar sudo Puppet --prueba

Mostrará un resultado voluminoso que muestra todos los cambios en el estado del medio ambiente. Si no hay errores en el resultado, debería poder abrir su dirección IP externa o nombre de dominio en su navegador. Aparecerá en la pantalla una página de prueba de PHP con información de la pila. Esto significa que Apache y PHP están funcionando.

Ahora la pila LAMP está instalada en el servidor usando Puppet.

Este es un manifiesto bastante simple ya que se puede ejecutar en un agente. Si no tiene un Puppet master, otros nodos de agente no podrán usar este manifiesto.

El servidor Puppet Master comprueba los cambios de estado del servidor cada 30 minutos.

Ejemplo 2: instalación de una pila LAMP utilizando un módulo

Ahora intenta crear un módulo simple basado en el manifiesto LAMP que escribiste en la sección anterior.

Para crear un módulo, cree un nuevo directorio en el directorio de módulos (su nombre debe coincidir con el nombre del módulo). Este directorio debe contener un directorio de manifiestos y un archivo init.pp. El archivo init.pp especifica la clase Puppet (su nombre también debe coincidir con el nombre del módulo).

Creando un módulo

Vaya al servidor Puppet master y cree una estructura de directorio para el módulo:

cd /etc/títere/módulos
sudo mkdir -p lámpara/manifiestos

Cree y abra el archivo init.pp en el editor:

lámpara sudo vi/manifests/init.pp

Inserte la clase de lámpara en el archivo:

lámpara de clase (
}

Copie el contenido del manifiesto de la sección 1 y péguelo en el bloque de clase de lámpara. Ahora tiene una definición de clase de lámpara. Otros manifiestos podrán utilizar esta clase como módulo.

Guarde y cierre el archivo.

Usando un módulo en el manifiesto principal

Ahora puede configurar el manifiesto principal y usar el módulo de lámpara para instalar la pila LAMP en el servidor.

En el servidor Puppet master, edite el siguiente archivo:

sudo vi /etc/puppet/manifests/site.pp

Lo más probable es que el archivo esté vacío en este momento. Agregue las siguientes líneas:

valor predeterminado del nodo ( )
nodo "lámpara-1" (
}

Nota: Reemplace lamp-1 con el nombre de host de su agente Puppet en el que instalará la pila.

El bloque de nodos le permite especificar el código Puppet que solo se aplicará a algunos nodos.

El bloque predeterminado se aplica a todos los nodos del agente que no tienen un bloque individual (déjelo vacío). El bloque lámpara-1 se aplicará al nodo del agente lámpara-1.

Agregue la siguiente línea a este bloque, que utiliza el módulo de lámpara:

Guarde y cierre el archivo.

Ahora el nodo del agente Puppet podrá descargar la configuración del servidor maestro e instalar la pila LAMP. Si desea realizar cambios ahora mismo, ejecute el comando en el agente:

agente títere sudo --prueba

Los módulos son la forma más conveniente de reutilizar el código Puppet. Además, los módulos le ayudan a organizar lógicamente su código.

Ejemplo 3: instalación de LAMP utilizando módulos públicos

El módulo MySQL se utiliza de forma similar. Agregue las siguientes líneas al bloque de nodos:

clase("mysql::servidor":
root_password => "contraseña",
}

También puede pasar los parámetros del módulo MySQL.

Agregue un recurso que copiará info.php a la ubicación deseada. Utilice el parámetro de origen. Agregue las siguientes líneas al bloque de nodos:

file("info.php": # nombre del archivo de recursos
ruta => "/var/www/html/info.php", # ruta de destino
asegurar => archivo,
require => Clase["apache"], # clase de apache a usar
source => "puppet:///modules/apache/info.php", # ubicación para copiar el archivo
}

Esta declaración de clase utiliza el parámetro fuente en lugar del contenido. Esta opción no sólo utiliza el contenido del archivo, sino que también lo copia.

Puppet copiará el archivo puppet:///modules/apache/info.php a /etc/puppet/modules/apache/files/info.php.

Guarde y cierre el archivo.

Crea un archivo info.php.

sudo sh -c "eco""> /etc/puppet/modules/apache/files/info.php"

Ahora el nodo del agente Puppet podrá descargar la configuración del servidor maestro e instalar la pila LAMP. Si desea realizar cambios en el entorno del agente ahora mismo, ejecute el comando en este nodo:

agente títere sudo --prueba

Este comando descargará todas las actualizaciones para el nodo actual e instalará la pila en él. Para asegurarse de que Apache y PHP estén funcionando, abra la dirección IP o el dominio del nodo en un navegador:

http://lámpara_1_public_IP/info.php

Conclusión

Ahora tiene conocimientos básicos sobre cómo trabajar con módulos y manifiestos de Puppet. Intente crear usted mismo un manifiesto y un módulo sencillos.

Puppet es excelente para administrar archivos de configuración de aplicaciones.

Etiquetas: ,

Popular en la categoría: