Puppet en realidad se presta bastante bien a entornos multi-master, con advertencias. ¿El principal? A muchas partes de Puppet les gusta estar centralizadas. La autoridad de certificación, el inventario y los servicios de tablero / informe, el almacenamiento de archivos y las configuraciones almacenadas, todos ellos están en su mejor momento (o simplemente requieren) una configuración donde solo hay un lugar para que puedan hablar.
Sin embargo, es bastante factible hacer que muchas de esas piezas móviles funcionen en un entorno multimaestro, si está de acuerdo con la pérdida elegante de algunas de las funciones cuando ha perdido su sitio principal.
Comencemos con la funcionalidad base para obtener un nodo que informa a un maestro:
Módulos y Manifiestos
Esta parte es simple. La versión los controla. Si se trata de un sistema de control de versiones distribuido, simplemente centralice y sincronice, y modifique su flujo de inserción / extracción según sea necesario en el sitio de conmutación por error. Si se trata de Subversion, entonces probablemente querrá svnsyncel repositorio en su sitio de failover.
Autoridad certificada
Una opción aquí es simplemente sincronizar los archivos de autoridad de certificación entre los maestros, para que todos compartan el mismo certificado raíz y puedan firmar certificados. Esto siempre me ha parecido "hacerlo mal";
- ¿Debería un maestro realmente ver su propio certificado presentado en la autenticación del cliente para una conexión entrante de otro maestro como válida?
- ¿Funcionará de manera confiable para el servicio de inventario, el tablero, etc.?
- ¿Cómo agrega nombres alternativos de DNS válidos adicionales en el futuro?
Honestamente, no puedo decir que he hecho pruebas exhaustivas de esta opción, ya que parece horrible. Sin embargo, parece que Puppet Labs no está buscando alentar esta opción, según la nota aquí .
Entonces, lo que deja es tener un maestro de CA central. Todas las relaciones de confianza siguen funcionando cuando la CA está inactiva ya que todos los clientes y otros maestros almacenan en caché el certificado de la CA y la CRL (aunque no actualizan la CRL tan a menudo como deberían), pero no podrá firmar nuevos certificados hasta obtiene una copia de seguridad del sitio primario o restaura el maestro de CA a partir de copias de seguridad en el sitio de conmutación por error.
Escogerá un maestro para que actúe como CA y hará que todos los demás maestros lo deshabiliten:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Entonces, querrá que ese sistema central obtenga todo el tráfico relacionado con los certificados. Hay algunas opciones para esto;
- Utilice el nuevo
SRVsoporte de registros en 3.0 para apuntar todos los nodos de agente al lugar correcto para la CA:_x-puppet-ca._tcp.example.com
- Configure la
ca_serveropción de configuración en el puppet.confde todos los agentes
Proxy todo el tráfico para solicitudes relacionadas con CA de agentes en el maestro correcto. Por ejemplo, si está ejecutando todos sus maestros en Apache a través de Passenger, configúrelo en los no CA:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
Y eso debería hacerlo.
Antes de pasar a los servicios auxiliares, una nota al margen;
Nombres DNS para certificados maestros
Creo que esto es la razón más convincente para pasar a 3.0. Supongamos que desea apuntar un nodo a "cualquier antiguo maestro de trabajo".
Bajo 2.7, necesitaría un nombre DNS genérico como puppet.example.com, y todos los maestros lo necesitan en su certificado. Eso significa establecer dns_alt_namesen su configuración, volver a emitir el certificado que tenían antes de que se configuraran como maestro, volver a emitir el certificado nuevamente cuando necesite agregar un nuevo nombre DNS a la lista (como si quisiera tener varios nombres DNS para tienen agentes prefieren maestros en su sitio) .. feo.
Con 3.0, puede usar SRVregistros. Dale a todos tus clientes esto;
[main]
use_srv_records = true
srv_domain = example.com
Entonces, no se necesitan certificados especiales para los maestros: solo agregue un nuevo registro a su SRVRR en _x-puppet._tcp.example.comy listo, es un maestro en vivo en el grupo. Mejor aún, puede hacer que la lógica de selección maestra sea más sofisticada; "cualquier antiguo maestro que trabaje, pero prefiera el que está en su sitio" al configurar diferentes conjuntos de SRVregistros para diferentes sitios; no es dns_alt_namesnecesario
Informes / Panel de control
Este funciona mejor centralizado, pero si puedes vivir sin él cuando tu sitio principal está inactivo, entonces no hay problema. Simplemente configure todos sus maestros con el lugar correcto para colocar los informes.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
..y ya está todo listo. No cargar un informe no es fatal para la ejecución de la configuración; simplemente se perderá si las tostadas del servidor del tablero de instrumentos.
Inventario de hechos
Otra cosa buena que hayas pegado en tu tablero es el servicio de inventario. Con el facts_terminusconjunto restsegún lo recomendado en la documentación, esto realmente interrumpirá las ejecuciones de configuración cuando el servicio de inventario central esté inactivo. El truco aquí es usar el inventory_servicetérmino en los maestros no centrales, lo que permite una falla graciosa.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Tenga su servidor de inventario central configurado para almacenar los datos de inventario a través de ActiveRecord o PuppetDB, y debe mantenerse actualizado siempre que el servicio esté disponible.
Entonces, si está de acuerdo con tener un entorno de administración de configuración bastante básico donde ni siquiera puede usar la CA para firmar un nuevo certificado de nodo hasta que se restaure, entonces esto puede funcionar bien, aunque sería realmente bueno si algunos de estos componentes fueran un poco más amigables para ser distribuidos .