Para ser claros, no estoy preguntando cuál es la "mejor manera" de utilizar saltstack. Entiendo que hay muchas formas de usar saltstack y lo que funciona para usted, funciona. Mi pregunta es específicamente sobre la página de documentación de mejores prácticas encontrada.aquí.
Primero les mostraré cómo es mi entorno actual.
(Esto no es específico de mi entorno. He visto esta pregunta antes, pero nunca en stackexchange.com, normalmente en elpila de sal irc)
Después de leer la documentación de saltstack por primera vez, intenté implementar mi propio entorno, pero no sabía cómo lograr lo que quería con múltiples proyectos, todos implementados con diferentes paquetes. Así es como se ve mi primer intento.
Tengo tres proyectos diferentes que deben implementarse llamados
Proyecto 1,proyecto2, yproyecto3.
/etc/sal/master
file_roots:
base:
- /srv/salt
project1:
- /srv/salt/project1
project2:
- /srv/salt/project2
project3:
- /srv/salt/project3
#I have three projects that I need to deploy to, and each has a dev, qa, and prod machine.
nodegroups:
group-project1: 'L@dev-project1,qa-project1,prod-project1'
group-project2: 'L@dev-project2,qa-project2,prod-project2'
group-project3: 'L@dev-project3,qa-project3,prod-project3'
/srv/salt/top.sls
project1:
'group-project1':
- match: nodegroup
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
project2:
'group-project2':
- snort
- pulledpork
- barnyard
- snorby
- apache
- mysql
project3:
'group-project3':
- match: nodegroup
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
Estructura de archivos dentro de /srv/salt
contenido de /srv/salt
/srv/salt/project1, project2, project3, top.sls
Contenido de /srv/salt/project1
/srv/salt/project1/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache
Contenido de /srv/salt/project2
/srv/salt/project2/snort, pulledpork, barnyard, snorby, apache, mysql
Contenido de /srv/salt/project3
/srv/salt/project3/oraclejava, tomcat, iptables-persistent, postgresql, ges, apache
Lo que no me gusta de esta configuración
- archivos duplicados
Si tengo proyectos que tienen paquetes en común, por ejemplo, los tres proyectos tienen Apache, entonces tengo que tener un directorio de Apache para cada proyecto dentro de su carpeta. Eso no es terrible ya que Apache no está configurado igual, pero no creo que esté aprovechando la organización que permite saltstack.
- no es fácilmente legible
Como puede ver, esta configuración es algo difícil de leer. Tengo que editar mi grupo-proyectox en los grupos de nodos del /etc/salt/masterarchivo cada vez que quiero agregar un minion asociado con un proyecto específico.
Mejores prácticas de Saltstack
Mi pregunta es, ¿cómo implementaría las políticas de mejores prácticas mencionadas?aquí, en un entorno especificado anteriormente. Sé que hay muchas maneras de hacerlo, pero realmente quiero hacerlo de una manera que sea más fácil de entender y que no implique crear un nuevo directorio de Apache cada vez que tenga un servidor con Apache.
Se agradece cualquier ayuda.
EDITAR 1
Un par de sugerencias que recibí, que no fueron a través de superuser.com, fueron deshacerme de los grupos de nodos por completo y simplemente especificar en el archivo top.sls qué minions van con cada estado, usando el mismo formato que usé en el archivo /etc/salt/master (L@dev-project1,qa-project1,prod-project1).
Además, me sugirieron que tal vez debería usar un salt-master diferente para cada proyecto. Eso tiene sentido y me gusta esa respuesta, pero creo que para las personas que no tienen mucho espacio para máquinas virtuales o físicas, podría resultar difícil.
Respuesta1
Estoy tratando con diferentes configuraciones de aplicaciones por tipo de servidor directamente en el archivo superior.
# per server hostname : ie.
base:
'websrv*':
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
'monsrv*':
- snort
- pulledpork
- barnyard
- snorby
- apache
- mysql
Si el nombre de tus minions no te permite clasificarlos según la expresión regular, puedes hacer lo mismo con los granos.
# per server grains : ie.
base:
'G@role:websrv': # or even a custom grain like 'G@project:1'
- oraclejava
- tomcat
- iptables-persistent
- postgresql
- apache
'G@role:monitoring': # or even a custom grain like 'G@project:1'
- snort
- pulledpork
- barnyard
- snorby
- apache
- mysql
Luego hago lo mismo con los datos de mis pilares, permitiéndome asignar diferentes pilares a algunos hosts para que sean los únicos datos duplicados que tengo en Salt, con las mismas claves de pilares pero diferentes valores para configurar mi entorno según lo necesito. Entonces tengo, digamos, un estado de Apache y todo lo que sea específico del entorno se representa con el valor en mi pilar.
En su pilar, podría tener, por ejemplo:
/top.sls
/apache /
| init.sls
| project1.sls
| project2.sls
| project3.sls