En este artículo, me gustaría hablar sobre cómo usamos Puppet y Hiera para configurar servidores virtuales y de hierro. Básicamente, se tratará de la arquitectura y la jerarquía que inventamos, lo que facilita y sistematiza la configuración de los servidores.
Me incitaron a escribir este artículo por el hecho de que en Internet no encontré particularmente buenos ejemplos realmente buenos de cómo puede trabajar con hiera y para qué sirve. Básicamente, estos son tutoriales con ejemplos para ingresar al tema. Pero la aplicación práctica real de hiera no está escrita allí. Tal vez no me veía bien, pero aquí hay un ejemplo real que probablemente te ayudará a poner todos los puntos sobre i, como lo hice una vez.
Para quién sería útil este artículo
Si:
- Sabes lo que son Puppet y Hiera, pero realmente no los usas juntos, porque no está claro cómo hacerlo y por qué
- Tiene muchos equipos en su empresa y necesita diferenciar de alguna manera la configuración del servidor en el nivel de comando
- Usas un pappet y los archivos de nodo que has crecido a tamaños increíbles.
- ¿Te gusta leer la configuración del servidor en formato divino yaml :)
- Básicamente, le interesa el tema de la gestión de la configuración y la administración del sistema.
Este artículo es para ti.
Antes de empezar
Te advertiré de inmediato, el artículo resultó ser largo, pero espero que sea útil. Además, se entiende que ya ha conectado hiera a la marioneta, y que al menos de alguna manera está familiarizado con la marioneta. Si hiera no está conectado, no es difícil de hacer.
Datos de entrada
- Tenemos alrededor de 30 equipos de desarrollo en SEMrush, cada uno de los cuales tiene sus propios servidores
- Cada equipo trabaja con su propio conjunto de tecnologías (PL, DBMS, etc.)
- Los equipos pueden y deberían (idealmente) usar una configuración común para proyectos específicos (reutilización de código)
- Los equipos mismos administran la implementación de aplicaciones en sus servidores (esto no se hace a través del pappet)
Un poco de historia
Inicialmente, teníamos todo en el pappet de la versión 3, luego decidimos implementar el cuarto pappet, y todos los nuevos servidores comenzaron a colocarse en él, y los antiguos se transfirieron lentamente al cuarto.
En el tercer papel, solíamos usar el sistema clásico de módulos y archivos de nodos. Los módulos se crearon en un grupo especial de proyectos en Gitlab, se clonaron en un servidor de pappet (usando r10k ), luego los agentes de pappet acudieron al asistente y recibieron un directorio para aplicarlo al servidor.
Luego comenzaron a tratar de no hacer esto y no usar módulos locales, sino poner enlaces a los módulos necesarios y sus repositorios en el Puppetfile. Por qué Porque esos módulos son constantemente compatibles y mejorados (bueno, idealmente) por la comunidad y los desarrolladores, y nuestros locales no lo son. Más tarde, introdujeron hiera y lo cambiaron por completo, y los archivos de nodos (como node.pp) se han hundido en el olvido.
En el cuarto documento, intentamos abandonar completamente los módulos locales y usar solo módulos remotos. Desafortunadamente, una reserva debe insertarse aquí nuevamente, ya que "no funcionó por completo", a veces todavía tiene que inclinarse y terminar algo usted mismo. Por supuesto, solo hay hiera y no hay archivos de nodo.
Cuando tienes 30 equipos con un zoológico tecnológico, el problema de cómo mantener esta colección con> 1000 servidores se vuelve especialmente grave. Además, contaré cómo nos ayuda Hiera en esto.
Jerarquía
Hiera (de hecho, de donde obtuvo su nombre) establece una jerarquía. Con nosotros, se ve así:
--- :hierarchy: - "nodes/%{::fqdn}" - "teams/%{::team}_team/nodes/%{::fqdn}" - "teams/%{::team}_team/projects/%{::project}/tiers/%{::tier}" - "teams/%{::team}_team/projects/%{::project}/%{::role}" - "teams/%{::team}_team/projects/%{::project}" - "teams/%{::team}_team/roles/%{::role}" - "teams/%{::team}_team/%{::team}" - "projects/%{::project}/tiers/%{::tier}/%{::role}" - "projects/%{::project}/tiers/%{::tier}" - "projects/%{::project}/%{::role}" - "projects/%{::project}" - "tiers/%{::tier}" - "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common
Primero, tratemos con variables oscuras (hechos).
Idealmente, cada servidor en SEMrush debe tener 4 hechos especiales expuestos que describan su afiliación:
- hecho del
team - a qué equipo pertenece project hecho - con qué proyecto se relaciona- hecho de
role - qué rol tiene este proyecto - hecho de
tier : qué tipo de puesta en escena tiene (prod, test, dev)
Como funciona El agente de Pappet acude al maestro de Pappet y, basándose en estos hechos, busca archivos para sí mismo, revisando las carpetas de acuerdo con nuestra jerarquía. No es necesario indicar que los archivos de configuración pertenecen a los servidores. En cambio, los propios servidores saben qué archivos les pertenecen, solo mirando su ruta y sus hechos.
Durante la configuración del servidor, los administradores contactan a los desarrolladores y especifican estos parámetros (a menudo, por el contrario, las personas con conocimiento contactan a los administradores) para construir una jerarquía en hiera en el futuro, sobre la base de la cual luego se describe la configuración del servidor. Tal sistema ayuda a reutilizar el código y ser más flexible en términos de configuración del servidor.
Por ejemplo, tenemos un proyecto especial . En este proyecto, puede haber algún servidor frontend con nginx, un servidor back-end con python, un clúster db con mysql, un servidor redis para el almacenamiento en caché. Todos estos servidores deben colocarse en un proyecto llamado especial , y luego asignar roles a los servidores.
En el archivo del proyecto, describimos los parámetros comunes a todo el proyecto. Lo primero que viene a la mente es la creación en todos los servidores del usuario para su implementación con la cuestión de los derechos necesarios para él y el despliegue de sus claves ssh.
En el rol de cada servidor, el servicio generalmente se describe y personaliza, para lo que está destinado este servidor (nginx, python, mysql, etc.). En este caso, definitivamente necesitaremos si también necesitamos implementar una copia del entorno de producción en la plataforma de desarrollo, pero cambie algo en él (contraseñas, por ejemplo). En este caso, el servidor de desarrollo y el servidor de producción solo diferirán en el hecho de que el nivel se establece en la "posición" deseada (producción o desarrollo). Y luego un poco de magia y hiera harán el truco.
Si necesitamos implementar dos servidores idénticos en el mismo rol, pero algo en ellos debería diferir, por ejemplo, algunas líneas en la configuración, entonces otra parte de la jerarquía vendrá al rescate. Ponemos los archivos con el nombre del formato {fqdn }.yaml en el lugar correcto (por ejemplo, nodes/myserver.domain.net ), establecemos los valores necesarios de las variables al nivel de un servidor específico, y el pappet aplicará la misma configuración para ambos servidores para el rol, y único para cada uno. de los servidores
Ejemplo: dos backends con código php tienen el mismo rol y son completamente idénticos. Está claro que no queremos hacer una copia de seguridad de ambos servidores, no tiene sentido. Podemos crear una función para describir la misma configuración para ambos servidores, y luego crear otro archivo nodes/backend1.semrush.net en el que colocar la configuración para la copia de seguridad.
El archivo por lotes teams/team-name.yaml indica la configuración de todos los servidores que pertenecen al equipo. Muy a menudo, describe a los usuarios que pueden interactuar con estos servidores, así como sus derechos de acceso.
En base a estas variables, hemos construido esta jerarquía . Cuanto mayor sea el archivo encontrado en la jerarquía, mayor será la prioridad de la configuración especificada en él.
Se deduce que las variables pueden anularse en función de esta jerarquía. Es decir, la variable en el archivo de rol " projects/%{::project}/%{::role} " tiene prioridad sobre la variable en el archivo de proyecto " projects/%{::project} ". Las variables también pueden fusionarse en todos los niveles de la jerarquía si tiene un módulo y / o perfil / rol escrito de tal manera que le permita hacer esto. Al especificar la parte común de la configuración de mysql para todos los servidores de proyectos, puede agregar partes especiales que tengan peso para este rol a la misma variable en otros niveles de la jerarquía (habrá una sección adicional en la configuración para el esclavo).
Resulta que el archivo del nodo específico ubicado a lo largo de la ruta " hieradata/nodes/%{::fqdn} " tiene la más alta prioridad. Luego viene el archivo de nodo, pero ya en el nivel de comando. A continuación se muestra el bloque que describe otros hechos más generales:
- "virtual/%{::virtual}" - "os/%{::operatingsystem}/%{::operatingsystemmajrelease}" - "os/%{::operatingsystem}" - users - common
En consecuencia, en el archivo common.yaml tenemos una configuración que definitivamente debería llegar a todos los servidores, en el archivo users.yaml se describen todos los usuarios (pero no todos se crean en servidores, por supuesto), en os/%{::operatingsystem} configuración general típica para servidores con un sistema operativo específico ( ::operatingsystem fact ::operatingsystem ) y así sucesivamente.
Creo que, mirando esta jerarquía, todo se vuelve claro. A continuación consideraré un ejemplo del uso de dicha jerarquía. Pero primero debes hablar de perfiles.
Perfiles
Un punto importante en la configuración de servidores mediante módulos es el uso de perfiles. Están ubicados en el site/profiles ruta y son los puntos de entrada a los módulos. Gracias a ellos, puede configurar con mayor precisión los módulos colgantes en el servidor y crear los recursos necesarios.
Considere un ejemplo simple. Hay un módulo que instala y configura redis. Y también queremos establecer el parámetro sysctl vm.overcommit_memory en 1 al conectar este módulo, porque aquí . Luego escribimos un pequeño perfil que proporciona esta funcionalidad:
# standalone redis server class profiles::db::redis ( Hash $config = {}, String $output_buffer_limit_slave = '256mb 64mb 60', ) { # https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram sysctl { 'vm.overcommit_memory': ensure => present, value => '1', } class { '::redis': * => $config, } }
Como se mencionó anteriormente, los perfiles son una herramienta que le permite cambiar / mejorar el comportamiento del módulo, así como reducir el número de configuraciones en hiera. Si usa módulos remotos, a menudo puede encontrar el problema de que los módulos "aprobados" a menudo no tienen la funcionalidad que necesita, o tienen algún tipo de errores / fallas. Luego, en principio, puede clonar este módulo y corregir / agregar funcionalidad. Pero la decisión correcta sería, si es posible, escribir un buen perfil que pueda "preparar" el módulo de la manera que lo necesite. A continuación se presentan algunos ejemplos de perfiles, y puede comprender mejor por qué son necesarios.
Ocultando secretos en hiera
Una de las ventajas importantes de hiera en comparación con la pappet desnuda es su capacidad de almacenar datos confidenciales en archivos de configuración en forma cifrada en el repositorio. Tus contraseñas estarán a salvo.
En resumen, utiliza la clave pública para cifrar la información que necesita y colocarla con dicha línea en el archivo hiera. La parte privada de la clave se almacena en el maestro de pappet, que le permite descifrar estos datos. Se pueden encontrar más detalles en la página del proyecto .
En el cliente (computadora en funcionamiento), la herramienta se instala simplemente usando gem install hiera-eyaml . Además, utilizando un comando de la forma eyaml encrypt --pkcs7-public-key=/path/to/public_key.pkcs7.pem -s 'hello' puede cifrar datos y pegarlos en un archivo con la extensión eyaml o solo yaml, dependiendo de cómo configure, y luego el pappet lo resolverá. Obtienes algo como:
roles::postrgresql::password: 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y+VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTewqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UMm6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkvKqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAMblkKgBCR/f9KGXUgLh3/Ok60OIT5]'
O una cadena de varias líneas:
roles::postgresql::password: > ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEw DQYJKoZIhvcNAQEBBQAEggEAbIz1ihQlThMWa9T+Lq194Y6QdElMD1XTev5y +VPSHtkPTu6Al6TJaSrXF+7phJIjue+NF4ZVtJCLkHxUR6nJJqks0fcGS1vF 2+6mmM9cy69sIU1A3HqpOHZLuqHAc7jUqljYxpwWSIGOK6I2FygdAp5FfOTe wqfcVVmXj97EJdcv3DKrbAlSrIMO2iZRYwQvyv+qnptnZ7pilR2veOCPW2UM m6zagDLutX9Ft5vERbdaiCiEfTOpVa9Qx0GqveNRVJLV/5lfcL5ajdNBJXkv KqDbx8d3ZBtEVAAqeKlw0LqzScgmCbWQx2kUzukX5LSxbTpT0Th984Vp1sl7 iPk7UTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCp5GcwidcEMA+0wjAM blkKgBCR/f9KGXUgLh3/Ok60OIT5]
Parece que hemos terminado con la preparación, ahora podemos considerar un ejemplo.
Ejemplo de dedo
Spoiler : habrá muchas más configuraciones, por lo que aquellos que estén interesados en este artículo de interés puramente teórico pueden omitir esta sección e ir al final.
Veamos ahora un ejemplo de cómo configurar un servidor usando hiera en puppet4. No publicaré el código para todos los perfiles, porque de lo contrario la publicación será bastante grande. Me enfocaré en la jerarquía y configuración de hiera.
La tarea es esta: necesitamos implementar:
- Dos servidores db idénticos en los que se implementa postgresql
- Dos servidores más: interfaz con nginx
- Quinto y sexto servidor: backends de Python en Docker
- Todo es igual en el entorno de desarrollo, excepto algunas configuraciones de servidor
Crearemos nuestra jerarquía en orden y comenzaremos con el archivo del proyecto.
Proyecto
Cree el archivo de projects/kicker.yaml . Ponemos en él lo que es común a todos los servidores: necesitamos algunos repositorios y carpetas para la implementación, así como el propio usuario de implementación.
--- classes: - apt::debian::semrush files: "/srv/data": ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0755' '/srv/data/shared_temp': ensure: 'directory' owner: 'deploy' group: 'www-data' mode: '0775' user_management::present: - deploy
Rol db
Cree un archivo de roles para los servidores de bases de datos projects/kicker/db.yaml . Hasta ahora, lo haremos sin dividir los servidores en entornos:
--- classes: - profiles::db::postgresql profiles::db::postgresql::globals: manage_package_repo: true version: '10' profiles::db::postgresql::db_configs: 'listen_addresses': value: '*' profiles::db::postgresql::databases: kicker: {} profiles::db::postgresql::hba_rules: 'local connect to kicker': type: 'local' database: 'kicker' user: 'kicker' auth_method: 'md5' order: '001' 'allow connect from 192.168.1.100': type: 'host' database: 'kicker' user: 'kicker' auth_method: 'md5' address: '192.168.1.100/32' order: '002'
Aquí conectamos un perfil escrito para uso general de todos los que quieran instalar postgres en su servidor. El perfil es configurable y le permite configurar de manera flexible el módulo antes de aplicarlo.
Para los más curiosos, debajo del código cat para este perfil:
Perfil :: db :: postgresql class profiles::db::postgresql ( Hash $globals = {}, Hash $params = {}, Hash $recovery = {}, Hash[String, Hash[String, Variant[String, Boolean, Integer]]] $roles = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $db_configs = {}, Hash[String, Hash[String, Variant[String, Boolean]]] $databases = {}, Hash[String, String] $db_grants = {}, Hash[String, Hash[String, String]] $extensions = {}, Hash[String, String] $table_grants = {}, Hash[String, Hash[String, String]] $hba_rules = {}, Hash[String, String] $indent_rules = {}, Optional[String] $role = undef, # 'master', 'slave' Optional[String] $master_host = undef, Optional[String] $replication_password = undef, Integer $master_port = 5432, String $replication_user = 'repl', String $trigger_file = '/tmp/pg_trigger.file', ){ case $role { 'slave': { $_params = { manage_recovery_conf => true, } if $globals['datadir'] { file { "${globals['datadir']}/recovery.done": ensure => absent, } } $_recovery = { 'recovery config' => { standby_mode => 'on', primary_conninfo => "host=${master_host} port=${master_port} user=${replication_user} password=${replication_password}", trigger_file => $trigger_file, } } $_conf = { 'hot_standby' => { value => 'on', }, } file { $trigger_file: ensure => absent, } } 'master': { $_conf = { 'wal_level' => { value => 'replica', }, 'max_wal_senders' => { value => 5, }, 'wal_keep_segments' => { value => 32, }, } file { $trigger_file: ensure => present, } } default: { $_params = {} $_recovery = {} $_conf = {} } } class { '::postgresql::globals': * => $globals, } class { '::postgresql::server': * => deep_merge($_params, $params), } create_resources('::postgresql::server::config_entry', deep_merge($_conf, $db_configs)) create_resources('::postgresql::server::role', $roles) create_resources('::postgresql::server::database', $databases) create_resources('::postgresql::server::database_grant', $db_grants) create_resources('::postgresql::server::extension', $extensions) create_resources('::postgresql::server::table_grant', $table_grants) create_resources('::postgresql::server::pg_hba_rule', $hba_rules) create_resources('::postgresql::server::pg_indent_rule', $indent_rules) create_resources('::postgresql::server::recovery', deep_merge($_recovery, $recovery)) }
Por lo tanto, instalamos Postgresql 10 una sola vez, configuramos la configuración ( listen ), creamos la base de datos kicker y también escribimos dos reglas para acceder a esta base de datos en pg_hba.conf . Genial!
Rol frontend
Nos frontend la frontend . Cree el archivo projects/kicker/frontend.yaml con los siguientes contenidos:
--- classes: - profiles::webserver::nginx profiles::webserver::nginx::servers: 'kicker.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker.semrush.com' proxy: 'http://kicker-backend.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5'
Todo es simple aquí. Conectamos los profiles::webserver::nginx perfil profiles::webserver::nginx , que prepara la entrada en el módulo nginx, y también definimos las variables, específicamente el server y la location de este sitio.
Un lector atento notará que sería más apropiado colocar la descripción del sitio más arriba en la jerarquía, porque todavía tendremos un entorno de desarrollo, y allí se usarán otras variables ( server_name , proxy ), pero esto no es demasiado importante. Al describir el rol de esta manera, podemos ver cómo estas variables se redefinen solo por jerarquía.
Rol Docker
El papel de docker projects/kicker/docker.yaml :
--- classes: - profiles::docker profiles::docker::params: version: '17.05.0~ce-0~debian-stretch' packages: 'python3-pip': provider: apt 'Fabric3': provider: pip3 ensure: 1.12.post1 user_management::users: deploy: groups: - docker
El profiles/docker.pp muy simple y elegante. Le daré su código:
Perfil :: docker class profiles::docker ( Hash $params = {}, Boolean $install_kernel = false, ){ class { 'docker': * => $params, } if ($install_kernel) { include profiles::docker::kernel } }
Todo esta listo. Esto ya es suficiente para implementar el producto que necesitamos en muchos servidores, simplemente asignándoles un proyecto y una función específicos (por ejemplo, colocando el archivo en el formato deseado en el directorio facts.d, cuya ubicación depende del método de instalación de Puppet).
Ahora tenemos la siguiente estructura de archivos:
. ├── kicker │ ├── db.yaml │ ├── docker.yaml │ └── frontend.yaml └── kicker.yaml 1 directory, 4 files
Ahora nos ocuparemos de los entornos y la definición de una configuración única para un rol en un sitio en particular.
Medio ambiente y anulación
Creemos la configuración general para todas las ventas. El archivo projects/kicker/tiers/prod.yaml contiene una indicación de que necesitamos conectar una clase con un firewall a este entorno (bueno, prod lo mismo), así como una clase determinada que proporciona un mayor nivel de seguridad:
Para un entorno de desarrollo, si necesitamos describir algo específico, se crea el mismo archivo y se ingresa la configuración necesaria.
A continuación, aún necesita redefinir las variables para la configuración nginx de la función frontend en el entorno de desarrollo. Para hacer esto, debe crear el archivo projects/kicker/tiers/dev/frontend.yaml . Presta atención a un nuevo nivel de jerarquía.
--- profiles::webserver::nginx::servers: 'kicker-dev.semrush.com': use_default_location: false listen_port: 80 server_name: - 'kicker-dev.semrush.com' profiles::webserver::nginx::locations: 'kicker-root': location: '/' server: 'kicker-dev.semrush.com' proxy: 'http://kicker-backend-dev.semrush.com:8080' proxy_set_header: - 'X-Real-IP $remote_addr' - 'X-Forwarded-for $remote_addr' - 'Host kicker-dev.semrush.com' location_cfg_append: 'proxy_next_upstream': 'error timeout invalid_header http_500 http_502 http_503 http_504' proxy_connect_timeout: '5'
La clase ya no es necesaria; se hereda de los niveles anteriores de la jerarquía. Aquí hemos cambiado server_name y proxy_pass . Un servidor que tiene los hechos role = frontend y tier = dev primero encontrará el archivo projects/kicker/frontend.yaml por sí mismo, pero luego las variables de este archivo serán anuladas por el archivo projects/kicker/tiers/dev/frontend.yaml con mayor prioridad .
Contraseña oculta para PostgreSQL
Y así tenemos el último elemento en la agenda: establecer contraseñas para PostgreSQL.
Las contraseñas deben variar en los entornos. Usaremos eyaml para almacenar contraseñas de forma segura. Crea contraseñas:
eyaml encrypt -s 'verysecretpassword' eyaml encrypt -s 'testpassword'
Pegamos las líneas resultantes en los archivos **projects/kicker/tiers/prod/db.yaml** y **projects/kicker/tiers/dev/db.yaml** (o puede usar la extensión eyaml, esto es personalizable), respectivamente. Aquí hay un ejemplo:
--- profiles::db::postgresql::roles: 'kicker': password_hash: > 'ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAsdpb2P0axUJzyWr2duRKAjh0WooGYUmoQ5gw0nO9Ym5ftv6uZXv25DRMKh7vsbzrrOR5/lLesx/pAVmcs2qbhd/y0Vr1oc2ohHlZBBKtCSEYwem5VN+kTMhWPvlt93x/S9ERoBp8LrrsIvicSYZByNfpS2DXCFbogSXCfEPxTTmCOtlOnxdjidIc9Q1vfAXv7FRQanYIspr2UytScm56H/ueeAc/8RYK51/nXDMtdPOiAP5VARioUKyTDSk8FqNvdUZRqA3cl+hA+xD5PiBHn5T09pnH8HyE/39q09gE0pXRe5+mOnU/4qfqFPc/EvAgAq5mVawlCR6c/cCKln5wJTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDNKijGHBLPCth0sfwAjfl/gBAaPsfvzZQ/Umgjy1n+im0s]'
A continuación, la contraseña para el rol de kicker vendrá, se descifrará y se aplicará en el servidor de la base de datos en PostgreSQL.
Eso, de hecho, es todo. Sí, el ejemplo resultó ser masivo, pero, espero, funcional, sin dejar preguntas, claro y útil. La jerarquía resultante en hiera es esta:
. ├── db.yaml ├── docker.yaml ├── frontend.yaml └── tiers ├── dev │ ├── db.yaml │ └── frontend.yaml ├── prod │ └── db.yaml └── prod.yaml 3 directories, 7 files
Puede ver estos archivos en vivo clonando un repositorio especialmente creado
Conclusión
La marioneta es buena y fácil de usar con hiera. No lo llamaría una herramienta de configuración ideal en el mundo moderno, en absoluto, pero merece atención. Hace frente a algunas tareas muy bien, y su "filosofía" de mantener un estado de recursos y configuración constantemente idénticos puede desempeñar un papel importante para garantizar la seguridad y la uniformidad de las configuraciones.
El mundo moderno se está sinergizando y desarrollando gradualmente. Pocas personas ahora usan solo un sistema de configuración, a menudo en el arsenal de desarrolladores y administradores hay varios sistemas a la vez. Y esto es bueno, ya que hay mucho para elegir. Lo principal es que todo debe ser lógico y comprensible, cómo y dónde se puede configurar.
Como resultado, nuestro objetivo como administradores es no configurar nada nosotros mismos. Idealmente, todo esto debe ser realizado por los propios equipos. Y debemos darles una herramienta o producto que nos permita hacer esto de forma segura, fácil y, lo más importante, con un resultado preciso. Bueno, y ayuda a resolver problemas arquitectónicos y más serios que "Necesitas instalar PostgreSQL en el servidor y crear un usuario". ¡Camon, 2018 está en el patio! Así que arroja títeres y ansibles y pasa al futuro sin servidor.
Con el desarrollo de los sistemas de nubes, contenedorización y orquestación de contenedores, los sistemas de gestión de configuración están retrocediendo lentamente en segundo plano para usuarios y clientes. También puede generar un clúster de contenedores a prueba de fallas en la nube y mantener sus aplicaciones en contenedores con skeling automático, copia de seguridad, replicación, descubrimiento automático, etc., sin escribir una sola línea para ansible, puppet, chef, etc. No tienes que ocuparte de nada (bueno, casi). Por otro lado, hay menos servidores de hierro debido a las nubes. Es solo que ya no necesita configurarlos, esta acción es responsabilidad del proveedor de la nube. Pero es poco probable que usen los mismos sistemas que los mortales comunes.
Créditos
Gracias
- Dmitry Tupitsin, Dmitry Loginov, Stepan Fedorov y todo el equipo de administradores de sistemas por su ayuda en la preparación de este artículo.
- Vladimir Legkostupov para la foto
- Yana Tabakova por organizar todo esto y ayudar a pasar por todas las etapas previas a la publicación
- Nikita Zakharov por asistencia en asuntos de licencias