Puppet: tokenización simple + necesidad de un agente

Puppet: tokenización simple + necesidad de un agente

Amigos

Actualmente tenemos una herramienta de implementación personalizada en funcionamiento y estamos evaluando reemplazarla con algo que no sea propietario, como Puppet.

Una de las principales cosas que hace por nosotros en este momento es la tokenización. Por ejemplo, en un archivo server.xml en una implementación de Tomcat, podríamos implementar un archivo llamado server.xml.tokenzenizedcon una línea como la siguiente

<Ajp12Connector port="@@TOMCAT.AJP.PORT@@" ajpidFile="conf/ajp12_2.id" />

y luego tener un tokens.xmlarchivo que tendría una línea como

<TOKEN NAME='TOMCAT.AJP.PORT' value = '8080/>

Luego, nuestro proceso de implementación escanea server.xml.tokenized y reemplaza los tokens, escribiendo el archivo en server.xml.

¿Puede Puppet hacer esto para un archivo arbitrario? O para algo como Tomcat, ¿tendría que descargar un complemento que entienda cómo funciona Tomcat?

En segundo lugar, según la lectura que he hecho hasta la fecha, parece que la mayoría de la gente usa el agente de Puppet para recuperar archivos del maestro. ¿Tiene que ser así? ¿Puede tener un script que utilice el modelado y la infraestructura de Puppet? ¿Luego inicia sesión en los hosts para implementar el software? - la razón es que, por diversas razones, tenemos un sesgo contra los agentes de nuestro entorno.

Salud

Respuesta1

A la primera pregunta: sí,puppetpuedo hacer eso usandoplantillasjunto conhieray/ofacter. Este proceso se abstrae absolutamente del software mediante el archivo de plantilla.

Por ejemplo, puedes tener una plantilla server.xmlcon una sección como esta:

<Connector address="<%= @ipaddress_eth0 %>"
           executor="tomcatThreadPool"
           port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           redirectPort="8443" />

La <%= @ipaddress_eth0 %>parte es lo que actualmente se llama un "token", y Puppet sabe cómo reemplazarla para cualquier host determinado usando facter:

# facter ipaddress_eth0
10.0.0.2

Tu puedes tenerhechos personalizadossi tú también los necesitas.

El tema de los datos jerárquicos es un poco más complejo y requeriría que lea cierta documentación para ver cómo puede ayudarle con sus implementaciones.EsteEs una muy buena presentación de sus posibilidades. Básicamente, su propósito es proporcionar los medios para separar el código y los datos (sus 'tokens') y almacenar esos datos en un formato familiar y fácil de mantener (YAML o JSON). El caso de uso que describe anteriormente (que define un puerto personalizado para tomcat) es el patrón de uso clásico de hiera:

En el tomcatmódulo tendrías algo como:

class tomcat (
    $port
    ){
    #rest of the module
}

En una plantilla (digamos, server.xml.erb):

<Ajp12Connector port="<%= port %>" ajpidFile="conf/ajp12_2.id" />

Y la parte de sus datos jerárquicos que coincida con ese código se vería así:

tomcat::port = 8080

A la segunda pregunta, la respuesta también es sí, hasta cierto punto. Puedes usarcolectivo de marionetas(de hecho, una parte de la oferta de puppetlabs), para impulsar cambios en una granja de servidores sin agentes. Sin embargo, necesitaría instalar los clientes (no exactamente lo mismo, ya que estos clientes son pasivos, a diferencia de los puppetagentes, que son proactivos al solicitar suscatálogoshacia puppetmaster). Nuevamente, se requiere que ustedlee la documentaciónpara comprender mejor los detalles de su funcionalidad.

información relacionada