hogar › Consejos › Master of puppets: Instalación y configuración del sistema de gestión de configuración remota de Puppet. Master of Puppets: Instalación y configuración del sistema de gestión de configuración remota Puppet Instalación de Puppet

Master of puppets: Instalación y configuración del sistema de gestión de configuración remota de Puppet. Master of Puppets: Instalación y configuración del sistema de gestión de configuración remota Puppet Instalación de Puppet

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.
instalación del paquete servidor mysql, servidor mysql.
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á una prueba de prueba en la pantalla. página php con información sobre 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 en este momento el archivo está vacío. 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: ,
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 definitivamente parámetros dados, 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. certificado de 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 paquetes Puppet, mientras que el resto se extrae 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 obtener datos mediante llamada a función, Puppet extrae parámetros de clase predeterminados, lo cual 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 implementamos 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 especificar tanto al llamar 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 selecciones 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 controles dispositivos externos tipo de equipo 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 elementos de infraestructura críticos con acceso limitado y actualización manual y el segundo 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 el nodo de base de datos principal y de solo lectura, pero automatizando dicho 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 al menos en sistema de archivos junto con Puppet Server, pero es como escribir scripts en un servidor web de producción. 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
Instalar Configuración general acceso de administrador usando sugerencias 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 la configuración de su red, Protector contra sobretensiones y 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 línea de comando en el sistema de destino.
Esperamos el final de la ejecución y ejecutamos /opt/puppetlabs/bin/puppet agent --test . En 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 Bash para el script de inicialización 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 = "any" - 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.

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 tuvo éxito. Existen soluciones como kickstart que ayudan con la instalación inicial. Sistema operativo, pero un mayor perfeccionamiento 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 disponibilidad. GUI y solo se pueden comprar 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 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, 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. Así, 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, se puede forzar el administrador de paquetes.

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 fortalezas Marioneta. 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 cuando Configuración de VPN conexiones. 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, un enlace a un sitio externo. servidor NFS, en la segunda opción, se lanza 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"

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 recibe archivo nuevo, debes reiniciar el servicio.

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 personales 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

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 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 a crear uno nuevo. cuenta solo contacta a 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 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 permite 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, trabajar 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

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 (>= 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/cliente -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.

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 únicamente 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

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.

Marioneta es una estructura multiplataforma que permite administradores de sistemas Realizar tareas comunes usando código. El código le permite realizar diversas tareas, desde instalar nuevos programas hasta verificar los permisos de archivos o actualizar cuentas de usuario. Marioneta superior no sólo durante la instalación inicial del sistema, sino durante todo el ciclo de vida del sistema. En la mayoría de los casos marioneta utilizado en la configuración cliente/servidor.

Esta sección muestra la instalación y configuración. Marioneta en una configuración cliente/servidor. Este sencillo ejemplo demuestra cómo instalar apache usando Marioneta.

Instalación

Para instalacion Marioneta ingrese en la terminal:

Sudo apt-get install Puppetmaster

En la(s) máquina(s) cliente, ingrese:

Sudo apt-get instalar marioneta

Ajustes

Antes de configurar Puppet es posible que desees agregar una entrada. NOMBRE DNS Para títere.ejemplo.com, Dónde ejemplo.com- este es tu dominio. Clientes predeterminados Marioneta verifique el DNS de Puppet.example.com como nombre del servidor Puppet ( Titiritero). Consulte Servicio de nombres de dominio para obtener detalles adicionales sobre el uso de DNS.

Si no tiene intención de utilizar DNS, puede agregar entradas al archivo /etc/hosts en el servidor y el cliente. Por ejemplo, en el archivo /etc/hosts Marioneta agregar servidor:

127.0.0.1 localhost.localdomain localhost marioneta 192.168.1.17 meercat02.example.com meercat02

En cada Marioneta En el cliente, agregue una entrada para el servidor:

192.168.1.16 meercat.example.com marioneta meercat

Reemplace las direcciones IP y nombres de dominio desde el ejemplo hasta sus direcciones actuales y nombres del servidor y los clientes.

Ahora configuremos algunos recursos para apache2. Crear un archivo /etc/puppet/manifests/site.pp que contiene lo siguiente:

Paquete ( "apache2": asegurar => instalado) servicio ( "apache2": asegurar => verdadero, habilitar => verdadero, requerir => Paquete["apache2"])

Nodo "meercat02.example.com" (incluye apache2)

Reemplazar meercat02.ejemplo.com a tu nombre actual Marioneta cliente.

El último paso para este simple Marioneta El servidor debe reiniciar el servicio:

Sudo /etc/init.d/puppetmaster reiniciar

Ahora en Marioneta todo está configurado en el servidor y es hora de configurar el cliente.

Primero, configuremos el servicio. Marioneta agente para lanzar. Edite /etc/default/puppet, reemplazando el valor COMENZAR en Sí:

Sudo /etc/init.d/puppet inicio

volvamos a Marioneta servidor para firmar el certificado del cliente usando el comando:

Sudo puppetca --sign meercat02.example.com

Controlar /var/log/syslog por cualquier error de configuración. Si todo salió bien, el paquete apache2 y sus dependencias se instalarán en Marioneta cliente.

Este ejemplo es muy simple y no muestra muchas de las características y beneficios. Marioneta. Para información adicional mirar

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 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 se reconocerá automáticamente en función de la información sobre la versión de la distribución o del sistema, aunque, si es necesario, se puede configurar el administrador de paquetes 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 su mayoría sin problemas en cualquier otra red. 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"

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 personales 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

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 contacte 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

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/cliente -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 inicias 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 –