Se necesitan diferentes pilares
Los pilares son un almacén de datos seguro dentro de Salt. Por tanto, en primer lugar, se utilizan para delimitar el acceso a datos críticos (certificados, inicios de sesión, contraseñas).
Además de los pilares predeterminados, Salt también tiene el módulo ext_pillar , que proporciona una interfaz para conectarse a fuentes de datos externas y genera pilares a partir de estas fuentes en un diccionario común.
Por ejemplo, puede tomar datos de mysql, postgres, redis, mongo, git o incluso de la salida de un script / comando: cmd_json , cmd_yaml .
Una lista completa de módulos se publica en el sitio web oficial de SaltStack .
Si tiene una situación no estándar y los módulos disponibles no le convienen, puede escribir el suyo y ponerlo en / usr / lib / python3 / dist-packages / salt / pillar / , luego de lo cual debe reiniciar el asistente.
Un ejemplo de un módulo de este tipo:
#/etc/salt/master/conf.d/pillar.conf
ext_pillar:
- dummy: dummy
#/usr/lib/python3/dist-packages/salt/pillar/dummy.py
def ext_pillar(minion_id, pillar, *args, **kwargs):
dummy = {'dummy': 'what u want mann?'}
return dummy
De todos los módulos disponibles, pillarstack resultó ser el más interesante y relevante para nuestro equipo. Ahora te diremos por qué.
Presentamos PillarStack
Stack o pillarstack es "un pilar YAML simple y flexible que puede leer pilares de pilares", según la documentación oficial del sitio .
Le permite utilizar los pilares leídos anteriormente dentro de los pilares. Esto significa que podemos usar el pilar de la configuración anterior. ¡Y es muy conveniente! Demostremos cómo funciona:
, :
#/etc/salt/conf.d/pillarstack.conf
ext_pillar:
- stack:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
- /srv/pillar/stack3.cfg
#/srv/pillar/stack1.cfg
# stack "" ,
# 2 yml ,
core.yml
common/*.yml
osarchs/{{ __grains__['osarch'] }}.yml
oscodenames/{{ __grains__['oscodename'] }}.yml
hosts/{{ minion_id }}/roles.yml
#/srv/pillar/stack2.cfg
# stack stack1.cfg
# , , roles
# stack yml
{% for role in stack.roles %}
roles/{{ role }}/*.yml
{% endfor %}
#/srv/pillar/stack3.cfg
# stack "" stack1.cfg stack2.cfg
#
creds/{{ stack.db.host }}/*.yml
Cada configuración se puede representar como una capa. En cada una de estas capas, podemos usar datos de las capas anteriores.
Las siguientes variables están disponibles al configurar pilares:
- granos : configuraciones de orientación por granos
- opts : configuración de destino por opciones en la configuración
- pilar : pilares que se formaron antes de procesar el ext_pillar actual : pila
# , stack
# stack grains pillar
# stack.cfg , pillar
ext_pillar:
- stack:
grains:cpuarch:
x86_64:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
pillar:environment:
dev: /srv/pillar/dev/stack.cfg
prod: /srv/pillar/prod/stack.cfg
# stack: grains, pillar
# pillar stack1.cfg, stack2.cfg
# 'environment', stack.cfg
ext_pillar:
- stack:
grains:custom:grain:
value:
- /srv/pillar/stack1.cfg
- /srv/pillar/stack2.cfg
- stack:
pillar:environment:
dev: /srv/pillar/dev/stack.cfg
prod: /srv/pillar/prod/stack.cfg
En archivos yml puede usar:
- __opts__: opciones de configuración
- __grains__: granos de minion
- pilar: pilares de otros ext_pillar o de pilares predeterminados (los de top.sls)
- pila: pila de pilares acumulada, incluida la configuración actual.
Si solo va a cambiar a pillarstack, a continuación se muestran algunos puntos a los que vale la pena prestar atención:
1. La inclusión recursiva solo funciona en pilar. La pila no incluye directorios, solo archivos.
# pillar
# top.sls
base:
'*':
- dir1.* # /dir1/dir2/dir3/*
# stack
# stack.cfg
/dir1/*
/dir1/dir2/*
/dir1/dir2/dir3/*
2. Comportamiento predeterminado al fusionar listas:
- pilar: las listas se sobrescriben
- stack: se utiliza la estrategia merge-last (se agregan las listas).
Las estrategias de fusión de pilares permiten una personalización muy flexible de los pilares.
En la documentación se incluye una descripción detallada con ejemplos.
Para describir brevemente cada una de las estrategias:
- merge-last (predeterminado): combinación recursiva, el último diccionario / lista tiene prioridad
- merge-first: fusión recursiva, se da prioridad al primer diccionario / lista
- eliminar: elimina los elementos especificados
- sobrescribir: anulación de diccionario / lista.
Explicación: en cada fusión intervienen dos diccionarios / listas, llamémosles el primero y el último La
estrategia se indica como el primer elemento del diccionario / lista al que se debe aplicar.
Lo principal es no dejarse llevar por el uso excesivo de estrategias, ya que esto complicará la configuración. Quizás, en este caso, valga la pena reconsiderar la organización de los pilares.
Conclusión
Los pilares le permiten restringir el acceso a datos confidenciales. Con cada vez más datos y escenarios más sofisticados para su uso, es importante utilizar una herramienta conveniente para organizarlo. En este momento para nuestro equipo esto es pillarstack, en el futuro planeamos implementar Vault.
Nos parece sorprendente por qué pillarstack aún no ha suplantado al pilar predeterminado, porque es mucho más conveniente y flexible, y las estrategias son muy útiles cuando es necesario cambiar el comportamiento de la variable de pila puntualmente. ¿Qué piensas? ¿Utiliza pillarstack en su trabajo?