Implementación y configuración de PostgreSQL con Puppet

Puppet es un software de código abierto para la administración y la implementación de la configuración. Fundado en 2005, es multiplataforma e incluso tiene su propio lenguaje declarativo para la configuración.

Las tareas relacionadas con la administración y mantenimiento de PostgreSQL (u otro software realmente) Consiste en procesos diarios y repetitivos que requieren monitoreo. Esto se aplica incluso a aquellas tareas operadas por scripts o comandos a través de una herramienta de programación. La complejidad de estas tareas aumenta exponencialmente cuando se ejecutan en una infraestructura masiva, sin embargo, usar Puppet para este tipo de tareas a menudo puede resolver este tipo de problemas a gran escala, ya que Puppet centraliza y automatiza el desempeño de estas operaciones de una manera muy ágil.

Puppet funciona dentro de la arquitectura a nivel de cliente/servidor donde se realiza la configuración; estas operaciones luego se difunden y ejecutan en todos los clientes (también conocidos como nodos).

Por lo general, ejecutándose cada 30 minutos, el nodo de agentes recopilará un conjunto de información (tipo de procesador, arquitectura, dirección IP, etc.), también denominada como hechos, y luego enviará la información al master que está esperando una respuesta para ver si hay nuevas configuraciones para aplicar.

Estos hechos permitirán que el maestro personalice la misma configuración para cada nodo.

De una manera muy simple, Puppet es una de las herramientas DevOps más importantes disponible hoy. En este blog vamos a echar un vistazo a lo siguiente...

El caso de uso de Puppet y PostgreSQL
Instalando Puppet
Configuración y programación de marionetas
Configuración de Puppet para PostgreSQL

La instalación y configuración de Puppet (versión 5.3.10) descrita a continuación se realizó en un conjunto de hosts que usaban CentOS 7.0 como sistema operativo.

El caso de uso de Puppet y PostgreSQL

Suponga que hay un problema en su firewall en las máquinas que alojan todos sus servidores PostgreSQL, entonces sería necesario denegar todas las conexiones salientes a PostgreSQL y hacerlo lo antes posible.

Puppet es la herramienta perfecta para esta situación, especialmente porque la velocidad y la eficiencia son básico. Hablaremos de este ejemplo presentado en la sección “Configuración de Puppet para PostgreSQL” administrando el parámetro listen_addresses.

Instalando Marioneta

Hay un conjunto de pasos comunes para realizar en hosts maestros o agentes:

Paso uno

Actualización del archivo /etc/hosts con nombres de host y su dirección IP

192.168.1.85 agent agent.severalnines.com

192.168.1.87 master master.severalnines.com puppet

Paso Dos

Agregar los repositorios de Puppet en el sistema

$ sudo rpm –Uvh https://yum.puppetlabs.com/puppet5/el/7/x86_64/puppet5-release-5.0.0-1-el7.noarch.rpm

Para otros sistemas operativos o versiones de CentOS, el repositorio más apropiado se puede encontrar en Puppet, Inc. Yum Repositories.

Paso tres

Configuración del servidor NTP (Network Time Protocol)

$ sudo yum -y install chrony

Cuarto Paso

El chrony se utiliza para sincronizar el reloj del sistema desde diferentes servidores NTP y, por lo tanto, mantiene la hora sincronizada entre el servidor maestro y el agente.

Una vez instalado chrony debe habilitarse y reiniciarse:

$ sudo systemctl enable chronyd.service

$ sudo systemctl restart chronyd.service

Paso cinco

Deshabilitar el parámetro SELinux

En el archivo /etc/sysconfig/selinux, el parámetro SELINUX (Security-Enhanced Linux) debe estar deshabilitado para no restringir el acceso en ambos hosts.

SELINUX=disabled

Paso Seis

Antes de la instalación de Puppet (ya sea maestro o agente), el firewall en estos hosts debe definirse en consecuencia:

$ sudo firewall-cmd -–add-service=ntp -–permanent 

$ sudo firewall-cmd –-reload

Instalación de Puppet Master

Una vez agregado al sistema el repositorio de paquetes puppet5-release-5.0.0-1-el7.noarch.rpm, se puede realizar la instalación del servidor de marionetas:

$ sudo yum install -y puppetserver

El parámetro de asignación máxima de memoria es una configuración importante para actualizar el archivo /etc/sysconfig/puppetserver a 2 GB (o a 1 GB si el servicio no se inicia):

JAVA_ARGS="-Xms2g –Xmx2g "

En el archivo de configuración /etc/puppetlabs/puppet/puppet.conf es necesario agregar la siguiente parametrización:

[master]

dns_alt_names=master.severalnines.com,puppet



[main]

certname = master.severalnines.com

server = master.severalnines.com

environment = production

runinterval = 1h

El servicio del servidor de marionetas utiliza el puerto 8140 para escuchar las solicitudes de los nodos, por lo que es necesario asegurarse de que este puerto esté habilitado:

$ sudo firewall-cmd --add-port=8140/tcp --permanent

$ sudo firewall-cmd --reload

Una vez que se hayan realizado todas las configuraciones en el maestro de marionetas, es hora de iniciar este servicio:

$ sudo systemctl start puppetserver

$ sudo systemctl enable puppetserver

Instalación del Agente Puppet

El agente Puppet en el repositorio de paquetes puppet5-release-5.0.0-1-el7.noarch.rpm también se agrega al sistema, la instalación del agente-puppet se puede realizar de inmediato:

$ sudo yum install -y puppet-agent

El archivo de configuración del agente de marionetas /etc/puppetlabs/puppet/puppet.conf también debe actualizarse agregando el siguiente parámetro:

[main]

certname = agent.severalnines.com

server = master.severalnines.com

environment = production

runinterval = 1h

El siguiente paso consiste en registrar el nodo agente en el host maestro ejecutando el siguiente comando:

$ sudo /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true

service { ‘puppet’:

ensure => ‘running’,

enable => ‘true’

  }

En este momento, en el host maestro, hay una solicitud pendiente del agente de marionetas para firmar un certificado:

Eso debe firmarse ejecutando uno de los siguientes comandos:

$ sudo /opt/puppetlabs/bin/puppet cert sign agent.severalnines.com

$ sudo /opt/puppetlabs/bin/puppet cert sign --all

Finalmente (y una vez que el titiritero haya firmado el certificado) es hora de aplicar las configuraciones al agente recuperando el catálogo del titiritero:

$ sudo /opt/puppetlabs/bin/puppet agent --test

En este comando, el parámetro --test no significa una prueba, la configuración recuperada del maestro se aplicará al agente local. Para probar/comprobar las configuraciones del maestro, se debe ejecutar el siguiente comando:

$ sudo /opt/puppetlabs/bin/puppet agent --noop

Configuración y programación de marionetas

Puppet utiliza un enfoque de programación declarativo en el que el propósito es especificar qué hacer y no importa la forma de lograrlo.

La pieza de código más elemental en Puppet es el recurso que especifica una propiedad del sistema como comando, servicio, archivo, directorio, usuario o paquete.

A continuación se presenta la sintaxis de un recurso para crear un usuario:

user { 'admin_postgresql':

  ensure     => present,

  uid        => '1000',

  gid        => '1000',

  home       => '/home/admin/postresql'

}

Diferentes recursos podrían unirse a la clase anterior (también conocida como manifiesto) de archivo con extensión “pp” (significa Puppet Program), sin embargo, varios manifiestos y datos (como hechos, archivos y plantillas) compondrán un módulo. Todas las reglas y jerarquías lógicas están representadas en el siguiente diagrama:

El propósito de cada módulo es contener todos los manifiestos necesarios para ejecutar tareas de forma modular. Por otro lado, el concepto de clase no es el mismo de los lenguajes de programación orientados a objetos, en Puppet funciona como un agregador de recursos.

La organización de estos archivos tiene una estructura de directorio específica a seguir:

En que el propósito de cada carpeta es el siguiente:

Carpeta	Descripción
manifiestos	Código de marioneta
archivos	Archivos estáticos para ser copiados a los nodos
plantillas	Archivos de plantilla para copiar a los nodos administrados (se puede personalizar con variables)
ejemplos	Manifiesto para mostrar cómo usar el módulo

Las clases (manifiestos) pueden ser utilizadas por otras clases, como se muestra en el siguiente ejemplo:el manifiesto init.pp en dev_accounts está utilizando los grupos de manifiesto del módulo de cuentas.

class dev_accounts {

  $rootgroup = $osfamily ? {

    'Debian'  => 'sudo',

    'RedHat'  => 'wheel',

    default   => warning('This distribution is not supported by the Accounts module'),

  }



  include accounts::groups



  user { 'username':

    ensure      => present,

    home        => '/home/admin/postresql',

    shell       => '/bin/bash',

    managehome  => true,

    gid         => 'admin_db',

    groups      => "$rootgroup",

    password    => '$1$7URTNNqb$65ca6wPFDvixURc/MMg7O1'

  }

}

En la siguiente sección, le mostraremos cómo generar el contenido de la carpeta de ejemplos, así como los comandos para probar y publicar cada módulo.

Configuración de Puppet para PostgreSQL

Antes de presentar los varios ejemplos de configuración para implementar y mantener una base de datos PostgreSQL, es necesario instalar el módulo de marionetas de PostgreSQL (en el host del servidor) para usar todas sus funcionalidades:

$ sudo /opt/puppetlabs/bin/puppet module install puppetlabs-postgresql

Actualmente, miles de módulos listos para usar en Puppet están disponibles en el repositorio de módulos públicos Puppet Forge.

Paso uno

Configure e implemente una nueva instancia de PostgreSQL. Aquí está toda la programación y configuración necesaria para instalar una nueva instancia de PostgreSQL en todos los nodos.

El primer paso es crear un nuevo directorio de estructura de módulo como se compartió anteriormente:

$ cd /etc/puppetlabs/code/environments/production/modules

$ mkdir db_postgresql_admin

$ cd db_postgresql_admin; mkdir{examples,files,manifests,templates}

Luego, en el archivo de manifiesto manifests/init.pp, debe incluir la clase postgresql::server proporcionada por el módulo instalado:

class db_postgresql_admin{

  include postgresql::server

}

Para verificar la sintaxis del manifiesto, es una buena práctica ejecutar el siguiente comando:

$ sudo /opt/puppetlabs/bin/puppet parser validate init.pp

Si no se devuelve nada, significa que la sintaxis es correcta

Para mostrarle cómo usar este módulo en la carpeta de ejemplo, es necesario crear un nuevo archivo de manifiesto init.pp con el siguiente contenido:

include db_postgresql_admin

La ubicación de ejemplo en el módulo debe probarse y aplicarse al catálogo maestro:

$ sudo /opt/puppetlabs/bin/puppet apply --modulepath=/etc/puppetlabs/code/environments/production/modules --noop init.pp

Finalmente, es necesario definir a qué módulo tiene acceso cada nodo en el archivo “/etc/puppetlabs/code/environments/production/manifests/site.pp”:

node ’agent.severalnines.com’,’agent2.severalnines.com’{

 include db_postgresql_admin

}

O una configuración predeterminada para todos los nodos:

node default {

 include db_postgresql_admin

}

Por lo general, cada 30 minutos, los nodos verifican el catálogo maestro, sin embargo, esta consulta se puede forzar en el lado del nodo con el siguiente comando:

$ /opt/puppetlabs/bin/puppet agent -t

O si el propósito es simular las diferencias entre la configuración maestra y la configuración actual del nodo, podría usarse el parámetro nopp (sin operación):

$ /opt/puppetlabs/bin/puppet agent -t --noop

Paso dos

Actualice la instancia de PostgreSQL para escuchar todas las interfaces. La instalación anterior define una configuración de instancia en un modo muy restrictivo:solo permite conexiones en localhost como pueden confirmar los hosts asociados para el puerto 5432 (definido para PostgreSQL):

$ sudo netstat -ntlp|grep 5432

tcp        0 0 127.0.0.1:5432          0.0.0.0:* LISTEN   3237/postgres       

tcp6       0 0 ::1:5432                :::* LISTEN   3237/postgres

Para permitir escuchar toda la interfaz, es necesario tener el siguiente contenido en el archivo /etc/puppetlabs/code/environments/production/modules/db_postgresql_admin/manifests/init.pp

class db_postgresql_admin{

  class{‘postgresql:server’:

        listen_addresses=>’*’ #listening all interfaces

       }

}

En el ejemplo anterior, se declara la clase postgresql::server y se establece el parámetro listen_addresses en "*", lo que significa todas las interfaces.

Ahora el puerto 5432 está asociado con todas las interfaces, se puede confirmar con la siguiente dirección IP/puerto:“0.0.0.0:5432”

$ sudo netstat -ntlp|grep 5432

tcp        0 0 0.0.0.0:5432            0.0.0.0:* LISTEN   1232/postgres       

tcp6       0 0 :::5432                 :::* LISTEN   1232/postgres

Para restablecer la configuración inicial:solo permita conexiones de base de datos desde localhost, el parámetro listen_addresses debe establecerse en "localhost" o especificar una lista de hosts, si lo desea:

listen_addresses = 'agent2.severalnines.com,agent3.severalnines.com,localhost'

Para recuperar la nueva configuración del host maestro, solo es necesario solicitarla en el nodo:

$ /opt/puppetlabs/bin/puppet agent -t

Paso tres

Cree una base de datos PostgreSQL. La instancia de PostgreSQL se puede crear con una nueva base de datos, así como con un nuevo usuario (con contraseña) para usar esta base de datos y una regla en el archivo pg_hab.conf para permitir la conexión de la base de datos para este nuevo usuario:

class db_postgresql_admin{

  class{‘postgresql:server’:

        listen_addresses=>’*’ #listening all interfaces

  }



   postgresql::server::db{‘nines_blog_db’:

     user => ‘severalnines’,          password=> postgresql_password(‘severalnines’,’passwd12’)

   }



   postgresql::server::pg_hba_rule{‘Authentication for severalnines’:

     Description =>’Open access to severalnines’,

     type => ‘local’,

database => ‘nines_blog_db’,

     user => ‘severalnines’,

address => ‘127.0.0.1/32’

         auth_method => ‘md5’

   }

}

Este último recurso tiene el nombre de “Autenticación para varios nueves” y el archivo pg_hba.conf tendrá una regla adicional más:

# Rule Name: Authentication for severalnines

# Description: Open access for severalnines

# Order: 150

local   nines_blog_db   severalnines 127.0.0.1/32    md5

Para recuperar la nueva configuración del host maestro, todo lo que se necesita es solicitarla en el nodo:

$ /opt/puppetlabs/bin/puppet agent -t

Cuarto Paso

Cree un usuario de solo lectura. Para crear un nuevo usuario, con privilegios de solo lectura, se deben agregar los siguientes recursos al manifiesto anterior:

postgresql::server::role{‘Creation of a new role nines_reader’:

createdb   => false,

createrole => false,

superuser => false,     password_hash=> postgresql_password(‘nines_reader’,’passwd13’)

}

postgresql::server::pg_hba_rule{‘Authentication for nines_reader’:

     description =>’Open access to nines_reader’,

     type => ‘host’,

database => ‘nines_blog_db’,

     user => ‘nines_reader’,

address => ‘192.168.1.10/32’,

         auth_method => ‘md5’

   }

Para recuperar la nueva configuración del host maestro, todo lo que se necesita es solicitarla en el nodo:

$ /opt/puppetlabs/bin/puppet agent -t

Conclusión

En esta publicación de blog, le mostramos los pasos básicos para implementar y comenzar a configurar su base de datos PostgreSQL de forma automática y personalizada en varios nodos (que incluso podrían ser máquinas virtuales).

Estos tipos de automatización pueden ayudarlo a ser más efectivo que hacerlo manualmente y la configuración de PostgreSQL se puede realizar fácilmente usando varias de las clases disponibles en el repositorio de puppetforge