configuración de puppet 3.7
43 views
Skip to first unread message
Arnau Bria
Apr 20, 2015, 5:19:17 AM4/20/15
to puppet-user...@googlegroups.com
Hola,
esto viene del hilo de la quedade, pero para no liarlo, abro otro:
On Thu, 16 Apr 2015 17:34:09 +0200
Matthias Saou wrote:
> modulepath = site:modules:$basemodulepath
>
> Todos los modulos publicos y/o que tienen ciclo de vida proprio acaban
> dentro de 'modules' (la mayoria del forge, otros desde git con tags),
> y los modulos 100% privados estan dentro de 'site' que esta entonces
> en el mismo repositorio git que 'hieradata' (con mucha conf) y
> 'manifests' (casi vacio, los stages, overrides de parametros globales
> y poco mas).
Podrías explicar con un pooc más de detalle? yo estaba poniendo los
módulo básico en /etc/puppet/modules (de tal modo que, y por ejemplo,
stdlib sólo está una vez en /etc/puppet/modules ) y luego, encada en
entonro lo que me interesa. Pero veo que tu haces distinciones y me
gustaría ver el porque.
[...]
> Y por supuesto, un hook desde el servidor GitLab donde se publican los
> branches del repo para que r10k vaya creando/borrando los environments
> de Puppet de forma automatica.
web hook? probaste reaktor? que ejecutas de r10k? vi que había hooks
que eran más eficaces que otros....
hay una cosa que dice el rn0lson ese de r10k y que me tiene mosqueado.
En:
http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/
el primer workflow que describe (con n-mil pasos) dice:
- Run r10k to deploy the new environment
- Test/fix/push/r10k loop till everything is okay
a mi (supongo que por lo simple de mi configuración actual) r10k no me
falla nuca... que problemas puede haber?
muchas gracias!
Arnau
esto viene del hilo de la quedade, pero para no liarlo, abro otro:
On Thu, 16 Apr 2015 17:34:09 +0200
Matthias Saou wrote:
> modulepath = site:modules:$basemodulepath
>
> Todos los modulos publicos y/o que tienen ciclo de vida proprio acaban
> dentro de 'modules' (la mayoria del forge, otros desde git con tags),
> y los modulos 100% privados estan dentro de 'site' que esta entonces
> en el mismo repositorio git que 'hieradata' (con mucha conf) y
> 'manifests' (casi vacio, los stages, overrides de parametros globales
> y poco mas).
Podrías explicar con un pooc más de detalle? yo estaba poniendo los
módulo básico en /etc/puppet/modules (de tal modo que, y por ejemplo,
stdlib sólo está una vez en /etc/puppet/modules ) y luego, encada en
entonro lo que me interesa. Pero veo que tu haces distinciones y me
gustaría ver el porque.
[...]
> Y por supuesto, un hook desde el servidor GitLab donde se publican los
> branches del repo para que r10k vaya creando/borrando los environments
> de Puppet de forma automatica.
web hook? probaste reaktor? que ejecutas de r10k? vi que había hooks
que eran más eficaces que otros....
hay una cosa que dice el rn0lson ese de r10k y que me tiene mosqueado.
En:
http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/
el primer workflow que describe (con n-mil pasos) dice:
- Run r10k to deploy the new environment
- Test/fix/push/r10k loop till everything is okay
a mi (supongo que por lo simple de mi configuración actual) r10k no me
falla nuca... que problemas puede haber?
muchas gracias!
Arnau
Matthias Saou
Apr 20, 2015, 5:46:47 AM4/20/15
to puppet-user...@googlegroups.com
On Mon, 20 Apr 2015 11:19:06 +0200
Arnau Bria <arnau...@gmail.com> wrote:
> > modulepath = site:modules:$basemodulepath
> >
> > Todos los modulos publicos y/o que tienen ciclo de vida proprio
> > acaban dentro de 'modules' (la mayoria del forge, otros desde git
> > con tags), y los modulos 100% privados estan dentro de 'site' que
> > esta entonces en el mismo repositorio git que 'hieradata' (con
> > mucha conf) y 'manifests' (casi vacio, los stages, overrides de
> > parametros globales y poco mas).
>
> Podrías explicar con un pooc más de detalle? yo estaba poniendo los
> módulo básico en /etc/puppet/modules (de tal modo que, y por ejemplo,
> stdlib sólo está una vez en /etc/puppet/modules ) y luego, encada en
> entonro lo que me interesa. Pero veo que tu haces distinciones y me
> gustaría ver el porque.
Si por ejemplo quieres probar alguna version nueva de un modulo del
Arnau Bria <arnau...@gmail.com> wrote:
> > modulepath = site:modules:$basemodulepath
> >
> > Todos los modulos publicos y/o que tienen ciclo de vida proprio
> > acaban dentro de 'modules' (la mayoria del forge, otros desde git
> > con tags), y los modulos 100% privados estan dentro de 'site' que
> > esta entonces en el mismo repositorio git que 'hieradata' (con
> > mucha conf) y 'manifests' (casi vacio, los stages, overrides de
> > parametros globales y poco mas).
>
> Podrías explicar con un pooc más de detalle? yo estaba poniendo los
> módulo básico en /etc/puppet/modules (de tal modo que, y por ejemplo,
> stdlib sólo está una vez en /etc/puppet/modules ) y luego, encada en
> entonro lo que me interesa. Pero veo que tu haces distinciones y me
> gustaría ver el porque.
forge, te creas un branch 'testing', actualizas tu Puppetfile, push
git... y ya esta (con el hook adecuado).
En tu puppet master tendras 'production/modules/' y 'testing/modules/'
con todo duplicado al identico menos ese modulo, mas nuevo en 'testing'.
Tiene sentido que los environments puppet no comparten nada para poder
probar cualquier cosa diferente entre uno e otro. Por ejemplo gracias
al environment.conf uno puede tener el future parser activado e otro no.
Lo otro que comentaba de 'site', es que ahi estan otros modulos que no
son publicos y que forman parte del mismo repositorio que el
Puppetfile. Basicamente una agrupacion en un repo unico de lo que se
suelen llamar el repo de 'control' y los repos de 'profiles', 'roles',
etc. Mi experiencia es que funciona bien asi si hay poca gente
manejando todo el codigo y si todo acaba rapido en el branch
'production'.
> [...]
> > Y por supuesto, un hook desde el servidor GitLab donde se publican
> > los branches del repo para que r10k vaya creando/borrando los
> > environments de Puppet de forma automatica.
>
> web hook? probaste reaktor? que ejecutas de r10k? vi que había hooks
> que eran más eficaces que otros....
Para un cliente mio, he creado un hook bastante mas complejo porque se
tratan de cienes de environments (entonces es async + usa hardlink
antes de rsync hacia los puppet masters para ahorrar espacio y tiempo).
> hay una cosa que dice el rn0lson ese de r10k y que me tiene mosqueado.
> En:
> http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/
> el primer workflow que describe (con n-mil pasos) dice:
>
> - Run r10k to deploy the new environment
> - Test/fix/push/r10k loop till everything is okay
>
> a mi (supongo que por lo simple de mi configuración actual) r10k no me
> falla nuca... que problemas puede haber?
codigo : Se prueba, se encuentran problemas, se corrigen en los
manifests y entonces se tiene que hacer otros commit+push de git con
ejecuccion de r10k para poder volver a probar.
A mi este ciclo no me ha convencido nunca, porque uno acaba con un
monton de commits feos e inutiles, y se pierde mucho tiempo.
Para entornos pequenyos (2-3 personas), se puede tener permisos de
escritura dentro de uno de los branches de prueba (feo pero
eficiente!). Para entornos mas grandes, no he encontrado nada mejor que
Vagrant con puppet+r10k todo preparado para functionar con 'puppet
apply', es lo ideal y menos frustrante. La unica pega es que no sirve
para exported resources.
Matthias
--
Matthias Saou ██ ██
██ ██
Web: http://matthias.saou.eu/ ██████████████
Mail/XMPP: matt...@saou.eu ████ ██████ ████
██████████████████████
GPG: 4096R/E755CC63 ██ ██████████████ ██
8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██
21A9 7A51 7B82 E755 CC63 ████ ████
Arnau Bria
Apr 20, 2015, 6:19:37 AM4/20/15
to puppet-user...@googlegroups.com
On Mon, 20 Apr 2015 11:46:43 +0200
Matthias Saou wrote:
Hola!
> On Mon, 20 Apr 2015 11:19:06 +0200
> Arnau Bria <arnau...@gmail.com> wrote:
>
> > > modulepath = site:modules:$basemodulepath
> > >
> > > Todos los modulos publicos y/o que tienen ciclo de vida proprio
> > > acaban dentro de 'modules' (la mayoria del forge, otros desde git
> > > con tags), y los modulos 100% privados estan dentro de 'site' que
> > > esta entonces en el mismo repositorio git que 'hieradata' (con
> > > mucha conf) y 'manifests' (casi vacio, los stages, overrides de
> > > parametros globales y poco mas).
> >
> > Podrías explicar con un pooc más de detalle? yo estaba poniendo los
> > módulo básico en /etc/puppet/modules (de tal modo que, y por
> > ejemplo, stdlib sólo está una vez en /etc/puppet/modules ) y luego,
> > encada en entonro lo que me interesa. Pero veo que tu haces
> > distinciones y me gustaría ver el porque.
>
> Si por ejemplo quieres probar alguna version nueva de un modulo del
> forge, te creas un branch 'testing', actualizas tu Puppetfile, push
> git... y ya esta (con el hook adecuado).
> En tu puppet master tendras 'production/modules/' y 'testing/modules/'
> con todo duplicado al identico menos ese modulo, mas nuevo en
> 'testing'.
Si, si, eso lo tengo claro y es lo que tengo actualmente.
> Tiene sentido que los environments puppet no comparten nada para poder
> probar cualquier cosa diferente entre uno e otro. Por ejemplo gracias
> al environment.conf uno puede tener el future parser activado e otro
> no.
Vale, entonces la idea de compartir algo básico entre entornos es mala.
Aunque siendo así, el precio de hacer un branch cuando tengas N módulos
es algo elevado, no? Yo me veía en un futuro tipo: voy a retocar este
módulo o incluir esto otro, hago brnach y empiezo a tocar código en mi
nuevo entonro. Claro, si es brnach va hacer copia de (no se) 30
módulos y sólo voy a trabajar con uno, no es un poco desperdiciar
recursos? (pregunto, eh!? que yo estoy teorizadno por ahora).
> Lo otro que comentaba de 'site', es que ahi estan otros modulos que no
> son publicos y que forman parte del mismo repositorio que el
> Puppetfile. Basicamente una agrupacion en un repo unico de lo que se
> suelen llamar el repo de 'control' y los repos de 'profiles', 'roles',
> etc. Mi experiencia es que funciona bien asi si hay poca gente
> manejando todo el codigo y si todo acaba rapido en el branch
> 'production'.
ah, bueno, yo en el repo de control no tengo apenas nada (hiera). Pero
(creo) entender tu estructura. Gracias.
[...]
> > hay una cosa que dice el rn0lson ese de r10k y que me tiene
> > mosqueado. En:
> > http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/
> > el primer workflow que describe (con n-mil pasos) dice:
> >
> > - Run r10k to deploy the new environment
> > - Test/fix/push/r10k loop till everything is okay
> >
> > a mi (supongo que por lo simple de mi configuración actual) r10k no
> > me falla nuca... que problemas puede haber?
>
> No creo que hable de fallos de r10k, si no de fallos en los cambios de
> codigo : Se prueba, se encuentran problemas, se corrigen en los
> manifests y entonces se tiene que hacer otros commit+push de git con
> ejecuccion de r10k para poder volver a probar.
vale, claro, así si tiene sentido...
> A mi este ciclo no me ha convencido nunca, porque uno acaba con un
> monton de commits feos e inutiles, y se pierde mucho tiempo.
> Para entornos pequenyos (2-3 personas), se puede tener permisos de
> escritura dentro de uno de los branches de prueba (feo pero
> eficiente!). Para entornos mas grandes, no he encontrado nada mejor
> que Vagrant con puppet+r10k todo preparado para functionar con 'puppet
> apply', es lo ideal y menos frustrante. La unica pega es que no sirve
> para exported resources.
muchas gracias!
> Matthias
salu2,
Arnau
Matthias Saou wrote:
Hola!
> On Mon, 20 Apr 2015 11:19:06 +0200
> Arnau Bria <arnau...@gmail.com> wrote:
>
> > > modulepath = site:modules:$basemodulepath
> > >
> > > Todos los modulos publicos y/o que tienen ciclo de vida proprio
> > > acaban dentro de 'modules' (la mayoria del forge, otros desde git
> > > con tags), y los modulos 100% privados estan dentro de 'site' que
> > > esta entonces en el mismo repositorio git que 'hieradata' (con
> > > mucha conf) y 'manifests' (casi vacio, los stages, overrides de
> > > parametros globales y poco mas).
> >
> > Podrías explicar con un pooc más de detalle? yo estaba poniendo los
> > módulo básico en /etc/puppet/modules (de tal modo que, y por
> > ejemplo, stdlib sólo está una vez en /etc/puppet/modules ) y luego,
> > encada en entonro lo que me interesa. Pero veo que tu haces
> > distinciones y me gustaría ver el porque.
>
> Si por ejemplo quieres probar alguna version nueva de un modulo del
> forge, te creas un branch 'testing', actualizas tu Puppetfile, push
> git... y ya esta (con el hook adecuado).
> En tu puppet master tendras 'production/modules/' y 'testing/modules/'
> con todo duplicado al identico menos ese modulo, mas nuevo en
> 'testing'.
> Tiene sentido que los environments puppet no comparten nada para poder
> probar cualquier cosa diferente entre uno e otro. Por ejemplo gracias
> al environment.conf uno puede tener el future parser activado e otro
> no.
Aunque siendo así, el precio de hacer un branch cuando tengas N módulos
es algo elevado, no? Yo me veía en un futuro tipo: voy a retocar este
módulo o incluir esto otro, hago brnach y empiezo a tocar código en mi
nuevo entonro. Claro, si es brnach va hacer copia de (no se) 30
módulos y sólo voy a trabajar con uno, no es un poco desperdiciar
recursos? (pregunto, eh!? que yo estoy teorizadno por ahora).
> Lo otro que comentaba de 'site', es que ahi estan otros modulos que no
> son publicos y que forman parte del mismo repositorio que el
> Puppetfile. Basicamente una agrupacion en un repo unico de lo que se
> suelen llamar el repo de 'control' y los repos de 'profiles', 'roles',
> etc. Mi experiencia es que funciona bien asi si hay poca gente
> manejando todo el codigo y si todo acaba rapido en el branch
> 'production'.
(creo) entender tu estructura. Gracias.
[...]
> > hay una cosa que dice el rn0lson ese de r10k y que me tiene
> > mosqueado. En:
> > http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/
> > el primer workflow que describe (con n-mil pasos) dice:
> >
> > - Run r10k to deploy the new environment
> > - Test/fix/push/r10k loop till everything is okay
> >
> > a mi (supongo que por lo simple de mi configuración actual) r10k no
> > me falla nuca... que problemas puede haber?
>
> No creo que hable de fallos de r10k, si no de fallos en los cambios de
> codigo : Se prueba, se encuentran problemas, se corrigen en los
> manifests y entonces se tiene que hacer otros commit+push de git con
> ejecuccion de r10k para poder volver a probar.
> A mi este ciclo no me ha convencido nunca, porque uno acaba con un
> monton de commits feos e inutiles, y se pierde mucho tiempo.
> Para entornos pequenyos (2-3 personas), se puede tener permisos de
> escritura dentro de uno de los branches de prueba (feo pero
> eficiente!). Para entornos mas grandes, no he encontrado nada mejor
> que Vagrant con puppet+r10k todo preparado para functionar con 'puppet
> apply', es lo ideal y menos frustrante. La unica pega es que no sirve
> para exported resources.
> Matthias
salu2,
Arnau
Alex Muntada
Apr 20, 2015, 6:38:37 AM4/20/15
to puppet-user...@googlegroups.com
Arnau Bria:
> Aunque siendo así, el precio de hacer un branch cuando tengas N módulos
> es algo elevado, no? Yo me veía en un futuro tipo: voy a retocar este
> módulo o incluir esto otro, hago brnach y empiezo a tocar código en mi
> nuevo entonro. Claro, si es brnach va hacer copia de (no se) 30
> módulos y sólo voy a trabajar con uno, no es un poco desperdiciar
> recursos? (pregunto, eh!? que yo estoy teorizadno por ahora).
Tendrías que medirlo para saber si son demasiados recursos. Si no recuerdo mal, r10k centraliza todos los git objects y éso ahora mucho espacio a coste zero. No te salvas de tener un checkout por branch, pero ¿cuántas ramas tienes abiertas a la vez?
No creo que merezca la pena intentar optimizar el espacio antes que el tiempo de desarrollo y test, que también son recursos y mucho más caros. Menos aún si no supone un problema medible.
Un saludo,
Alex
Matthias Saou
Apr 20, 2015, 6:54:50 AM4/20/15
to puppet-user...@googlegroups.com
asi que el tiempo que se tarda en crear un environment no depende
directamente de la cantidad de modulos.
En principio no se suelen poner datos "gordos" en Puppet por su
ineficiencia en desplegarlos, y entonces el espacio de disco no deberia
llegar a ser un problema aunque tengas docenas de branches/environments.
Si llega a serlo, como me ma pasado con cienes de environments :
* Correr r10k en una ubicacion central temporal e aislada
* Correr hardlink sobre todos los environments
* Excluir lo que se puede a la hora de enviar hacia los puppet masters
(/.git*, /tests, /rspec, /*.md ...)
* Formatear adecuadamente la particion donde se envian los
environments (no hace falta gastar 4kB por hardlink! ;-))
...pero espero que no te pase nunca!!
Arnau Bria
Apr 20, 2015, 8:45:53 AM4/20/15
to puppet-user...@googlegroups.com
Muchas gracias a los dos!
salu2,
Arnau
salu2,
Arnau
Reply all
Reply to author
Forward
0 new messages