systemadmin.es > Gestión de cofiguración > Guía de supervivencia con puppet

Guía de supervivencia con puppet

Al empezar a usar puppet puede costar al principio debido al cambio de mentalidad que debemos hacer, si lo combinamos con un puppetmaster que no hemos instalado nosotros se puede complicar aún más la cosa. Vamos a ver una guía de supervivencia con puppet, en concreto, la configuración de los nodos en el puppet master:

Guía de supervivencia con puppet

Guía de supervivencia con puppet

Vamos a suponer una instalación sin environments, la configuración la encontraremos en /etc/puppet

Cuando lanzamos por primera vez un agente contra el servidor deberemos firmar las claves:

(...)
info: Creating a new SSL key for inf1180
info: Caching certificate for ca
info: Creating a new SSL certificate request for inf1180
info: Certificate Request fingerprint (md5): B6:01:F7:78:3B:95:22:C7:F9:A8:9F:E6:39:F9:A9:73

En el servidor veremos la petición de firmado:

# puppet cert --list
  "inf1180" (SHA256) A3:CD:3E:92:B8:4A:0F:D7:3B:3F:72:75:46:76:87:94:69:20:08:01:7D:99:B1:DA:E0:28:F1:85:E0:F8:8D:87

Una vez verificado del fingerprint lo firmaremos:

# puppet cert --sign inf1180
Notice: Signed certificate request for inf0301180
Notice: Removing file Puppet::SSL::CertificateRequest inf0301180 at '/var/lib/puppet/ssl/ca/requests/inf1180.pem'

En caso que necesitemos dar de alta muchas máquinas nos puede interesar habilitar el autofirmado en el puppet.conf para no tener que hacerlo manualmente:

(...)
[master]

autosign = true
(...)

Los modulos de puppet deberíamos instalarlos mediante puppet module install:

# puppet module install /home/jordi/jordiprats-systemadmin/pkg/jordiprats-systemadmin-0.1.0.tar.gz
Notice: Preparing to install into /etc/puppet/modules ...
Notice: Downloading from https://forgeapi.puppetlabs.com ...
Notice: Installing -- do not interrupt ...
/etc/puppet/modules
└─┬ jordiprats-systemadmin (v0.1.0)
  ├── puppetlabs-concat (v1.2.0)
  └── puppetlabs-stdlib (v4.5.1)

Se copiaran en /etc/puppet/modules/ dónde también podríamos instalar a mano (o incluso modificar directamente) pero no deberíamos.

La configuración de los hosts la encontraremos en el fichero /etc/puppet/manifests/site.pp, por ejemplo:

node 'dns'
{
	class { 'named': }

	named::zone { 'systemadmin.es':
		zonename => "systemadmin.es",
		zonemaster => '192.168.56.14',
	}
}

Pero también puede ser que la configuración este en hiera, en cuyo caso deberemos mirar primero en el /etc/puppet/hiera.yaml para ver con que estructura se parametrizan los hosts:

---
:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hieradata
:hierarchy:
  - "node/%{::fqdn}"
  - "type/%{::stripped_hostname}"
  - common

Dónde indiquemos con datadir encontraremos los ficheros, mientras que con hierarchy indicamos de más concreta a más general la configuración del host. En este caso en “common” (por lo tanto /etc/puppet/hieradata/common.yaml) encontraremos la configuración general, para luego ir concretando primero con el fact stripped_hostname (que elimina los números del final del nombre del host, por ejemplo si el hostname es dns1, el stripped_hostname sería simplemente dns) En este caso además, se usa el nombre del host (fqdn) para acabar de concretar la configuración.

Evidentemente, podemos sobreescribir el valor de una variable definida en un fichero con menor prioridad en dicha jerarquía.

Los tipos de datos que tenemos en yaml son:

  • Variables simples:
    variable: valor
    
  • Arrays:
    variable:
      - valor1
      - valor2
    
  • Hashes:
    variable: 
      key1: valor1
      key2: valor2
    

Para incluir classes deberemos modificar el site.pp para definirlas como include:

hiera_include('classes')

En el fichero de hiera simplemente deberemos indicar una lista:

---
classes:
  - sysctl
  - logrotate
  - postfix
  - puppetclient
  - network
  - sudoers

También podemos usar listas de paquetes:

paquetscomuns:
  - libreadline-dev
  - libncurses5-dev
  - libpcre3-dev
  - libssl-dev
  - perl
  - make
  - git
  - software-properties-common

Para luego en el site.pp pasarlos a una variable mediante la función hiera() e instalarlos tradicionalmente mediante un tipo:

$common_packages = hiera('paquetscomuns', [])

package { $common_packages:
	ensure => 'installed',
}

La función hiera() tiene dos parametros, el primero la variable a buscar y el segundo (opcional) qué devolver si no encuentra la variable. En el caso anterior devuelve un array vacío.

En el caso que tengamos definies como por ejemplo:

network::route { 'eth0':
  ipaddress => [ '192.168.1.0', ],
  netmask   => [ '255.255.255.0', ],
  gateway   => [ '192.168.1.250', ],
}

Lo traduciríamos en el hiera a partir de una variable como un hash:

routes:
  eth1:
    ipaddress: 
      - 62.97.117.216
    netmask: 
      - 255.255.255.248
    gateway: 
      - 192.168.40.254

Para a continuación en el site.pp crear el recurso mediante la función create_resources() a la cual indicaremos el tipo a crear con el hash:

$routes = hiera('routes', {})
create_resources(network::route, $routes)

Lo mismo aplicaría para tipos simples:

$sshkeys= hiera('sshkeys', {})
create_resources(ssh_authorized_key, $sshkeys)

El yaml sería:

---
sshkeys:
  user_key1:
    user: root
    type: rsa
    key: AAAAB3N...
  user_key2:
    user: root
    type: rsa
    key: AAAAB3Nza...

Algunas classes nos van a permitir publicar ficheros directamente mediante el formato:

(...)
zonefile => 'puppet:///zonasdns/systemadmin.es',
(...)

En el fichero /etc/puppet/fileserver.conf vamos a encontrar dónde esta dicho recurso:

(...)

[zonasdns]
path /etc/puppet/solr
allow *

(...)

Con estas pinceladas ya nos podremos empezar a pelear con puppet más fácilmente.

Deja un comentario:

XHTML - Tags permitidos:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>