PDA

Bekijk Volledige Versie : Puppet automatisering



ronaldvanhoeven
22/02/18, 10:25
Hallo,

Ik ben erachter gekomen dat je met puppet de webservers automatisch kan laten updaten, echter wordt dit afgeraden.

Nu vroeg ik me af of iemand hier er al ervaring mee heeft en dit met mij zou kunnen delen.

Alle hulp is welkom!

Ramon Fincken
22/02/18, 10:35
Bron van het afraden?

Marin
22/02/18, 11:31
Wij gebruiken Ansible. Puur omdat het makkelijker is dat te integreren in bestaande omgevingen.

The-BosS
22/02/18, 13:06
Ben zelf ook al enige tijd overgestapt van puppet naar ansible, net om de redenen die Marin ook aanhaalt. Ik ben meer te vinden voor de push methode over ssh, waar je bvb eenmalig een playbook (script) kan loslaten op een server dan overal puppet client te moeten gaan installeren. Je kan ansible ook gebruiken op een user account om je favoriete instellingen overal automagic te deployen en te updaten, dat moet je met puppet dus niet proberen.

Wat het updaten van een OS betreft met spacewalk/satellite/puppet/ansible/chef/... zie ik niet veel problemen zolang je dit maar opvolgt, vergelijk het met een cron instellen op de server zelf die de updates doet en nooit controleren of ze wel goed gelukt zijn.

SF-Jeroen
22/02/18, 19:19
Wij gebruiken beide. Puppet voor onze eigen infrastructuur. Dit draait automatisch elke 30 minuten en trekt eventuele afwijkingen meteen recht. Het mooie van een dergelijk systeem is dat je met 1000+ servers heel makkelijk gefaseerd dingen kan uitrollen (e.g. nadat het gemerged is in master zal het na 30 minuten overal live staan). Het is inderdaad iets lastiger op te zetten, maar zitten wel minder bugs in dan Ansible.

Wat betreft Ansible, dat gebruiken we voor externe infra (Amazon enzo). Nadeel is dat als je een paar duizend VMs tegelijk wil updaten je zelf queuing moet regelen en dan nog heb je vrij zware servers nodig waarvandaan alles komt. Wel is het makkelijker op te zetten, want er is alleen SSH + Python nodig op de destination server. Ook is de syntax iets overzichtelijker en minder in elkaar verweven.

Secrets vind ik bij beiden eigenlijk wel prima werken (Hiera in Puppet en bijv Vault in Ansible). Qua support wisselt het, soms zijn er mooie Puppet modules voor bepaalde set-ups (e.g. ELK-stacks) en soms zijn er juist weer mooie Ansible modules voor switches beschikbaar.

ju5t
22/02/18, 22:56
Bij ons staat alles in Puppet maar updates doen we er niet mee.

Puppet is (of was) minder goed in het in serie volgen van vaste processen. Ansible is daar beter in bij o.a. een herstart uitvoeren na een kernel update. Ik heb nog te weinig met tasks in Puppet gedaan om te kunnen zeggen of dit het antwoord of de oplossing is. Ik vind Puppet wel sterker in configuratie management dan Ansible. Nu Ansible Tower beschikbaar is als AWX is er wel wat betere tooling.

Puppet gebruiken we dus voor het gelijk houden van configuraties. Ansible gebruiken we voor alle eenmalige of ongeplande maar periodieke taken. Alle updates doen we dus volledig met Ansible.

The-BosS
22/02/18, 23:10
Nu Ansible Tower beschikbaar is als AWX is er wel wat betere tooling.

Ik zou het eerder omdraaien, awx is ouder dan tower :p, maar awx is nu wel opensource en het testplatform voor nieuwe features die dan later in tower komen.

vDong
24/02/18, 11:08
Hier wordt puppet expliciet niet gebruikt voor updates. Wel voor alle andere configuratie.
Updates is een combinatie van jenkins,custom scripting en visuele controle(van de feedback van beide)

Ansible gebruik ik niet omdat het slecht (of niet) om kan gaan met ssh-forced-commands, wat een expliciet onderdeel van de security van het updateprocess is.

ju5t
24/02/18, 17:08
vDong hoe ziet je audit trail er uit? Kun je terughalen uit Jenkins wie wanneer welke update heeft geïnstalleerd of vang je dit af in je eigen scripts?

Mijn kennis van Jenkins is ongeveer 0.

vDong
24/02/18, 18:13
vDong hoe ziet je audit trail er uit? Kun je terughalen uit Jenkins wie wanneer welke update heeft geïnstalleerd of vang je dit af in je eigen scripts?

Mijn kennis van Jenkins is ongeveer 0.
Jenkins heeft fine grained user authenticatie (met bv AD, ldap, of zoals ik doe interne users). Dus elke job staat bij welke user het was, afhankelijk van hoe je scripts werken kan je dat bv ook meesturen naar logging bij het device in je cmdb (dat is hier nog een todo)

Yourwebhoster
26/02/18, 15:11
ronaldvanhoeven Met gebruik van de juiste scripts en kennis is het semi-geautomatiseerd maar gecontroleerd deployen van updates geen probleem. Als je kijkt naar automatische updates met CustomBuild van DirectAdmin dan heb je daar bijna geen feedback van en/of controle. Monitoring kan aangeven dat het plat is maar het is niet erg praktisch als je grotere aantallen met servers hebt.

Je kan ook naar Foreman kijken en deze koppelen met Ansible danwel Puppet. Hier gebruiken we Ansible omdat dit vaker out-of-the-box werkt. Hier en daar heb je soms een python package nodig maar that's it, geen aparte client. Voordeel van Foreman is dat het gratis is en een goed overzicht geeft van de status van de servers. Mocht er wat fout gaan bij het updaten dan kan je éénvoudig die servers terug vinden.

Nadeel van Foreman (https://www.theforeman.org) en Ansible is wel dat als je een massa update uitvoert dat Ansible een bizar hoog CPU gebruik heeft.

ju5t
27/02/18, 11:26
Wat voor feedback mis je in CustomBuild of zou je graag zien? Het is meestal wel de moeite waard om contact op te nemen met DirectAdmin erover.

Als je Ansible gebruikt kun je controleren of alles werkt of niet. We hebben bijvoorbeeld een eigen Ansible module voor de integratie met Zabbix die de status van triggers controleert. Is er iets mis dan wordt de update afgebroken of overgeslagen. Ook voordat de update start controleren we dit.

Foreman vind ik zelf niet zo geweldig maar dat komt o.a. door de (afwijkende) integratie met Puppet.

Ramon Fincken
27/02/18, 11:32
zou TS op vakantie zijn?

Yourwebhoster
27/02/18, 11:37
Wat voor feedback mis je in CustomBuild of zou je graag zien? Het is meestal wel de moeite waard om contact op te nemen met DirectAdmin erover.

Aangezien het echt om beheer van een groter aantal servers gaat wil je in één overzicht de status kunnen zien en niet van alle details een e-mail opzoeken met fouten. Automatisch updaten is leuk, maar voor het serieuze werk niet handig. Als je zelf de updates lanceert dan heb je nog controle en sta je (als het goed is) ook standby voor als het fout gaat. Dat heb je met het automatisch updaten met CustomBuild niet.

Wat gebruik je zelf als alternatief op Foreman (werkt overigens icm Ansible).

- - - Updated - - -


zou TS op vakantie zijn?

TS was gisteren in ieder geval nog online.

ju5t
27/02/18, 13:23
Aangezien het echt om beheer van een groter aantal servers gaat wil je in één overzicht de status kunnen zien en niet van alle details een e-mail opzoeken met fouten.

Ik denk dat ik je verkeerd begrepen heb.

We updaten ook semi-automatisch met Ansible. We hebben nergens automatische updates aan staan. Alles wordt geregeld door Ansible, ook de updates van CustomBuild (en controles, etc.). Theoretisch kunnen we Ansible wél automatisch starten maar dat doen we (nog) niet.

Puppet gebruiken we voor configuratie management. Alle rapportages zitten in PuppetDB. Een dashboard geeft het overzicht en status monitoring haalt gegevens uit PuppetDB om ons te informeren als Puppet fouten geeft. Voor Ansible gebruiken we ARA als dashboard en omdat bij de updates iemand aanwezig is geeft het daar ook nog directe feedback.

Foreman zou in ons geval alleen wat toevoegen bij de uitrol van nieuwe servers maar dat is bij ons beperkt. We kunnen dus prima zonder.

ronaldvanhoeven
27/02/18, 13:37
Ramon Die heb ik niet, ik was in gesprek met meerdere mensen van puppet in hun IRC chat. Hier werd het afgeraden, met de reden dat je met updates er eigenlijk een oog op moet houden, en dat hier makkelijkere manieren voor zijn. Heb jij hier zelf ervaring mee?

ronaldvanhoeven
27/02/18, 13:42
Marin bedankt voor je reactie, ik had hierover ook gelezen, alleen zou ik het graag met puppet willen doen. Heb je bewust voor Ansible gekozen of heb je na ervaring met Puppet gekozen voor Ansible?

ronaldvanhoeven
27/02/18, 13:49
Boss bedankt voor je reactie, echter zou ik het graag voor elkaar krijgen met Puppet dan met Ansible. Ik zie verder wel veel goede reacties over Ansible, dus ik zal het zeker meer onderzoeken. Bedankt voor de informatie. Mocht je enige ervaringen hebben met Puppet ( gezien je bent overgestapt ) hoor ik dat graag.

ronaldvanhoeven
27/02/18, 13:54
Jeroen Bedankt voor je reactie! Is er een mogelijkheid dat je het verder zou kunnen toelichten hoe je dit voor elkaar hebt gekregen?

ronaldvanhoeven
27/02/18, 13:59
ju5t Bedankt voor je reactie!

ronaldvanhoeven
27/02/18, 14:09
Yourwebhoster Bedankt voor je reactie. Zijn deze scripts net zoals de modules te vinden op het internet, of moeten deze zelf gemaakt worden? Ik ben nieuw met Puppet, dus ben nog niet zo bekend met de software. Ik zie vele reacties ook over Foreman en Ansible gaan, dus zal het zeker even bekijken. Het liefst zou ik het wel voor elkaar krijgen met Puppet. Bedankt voor de informatie.

Yourwebhoster
27/02/18, 14:41
Yourwebhoster Bedankt voor je reactie. Zijn deze scripts net zoals de modules te vinden op het internet, of moeten deze zelf gemaakt worden? Ik ben nieuw met Puppet, dus ben nog niet zo bekend met de software. Ik zie vele reacties ook over Foreman en Ansible gaan, dus zal het zeker even bekijken. Het liefst zou ik het wel voor elkaar krijgen met Puppet. Bedankt voor de informatie.

Aangezien wij actief Ansible gebruiken en niet Puppet, kan ik je alleen een antwoord geven voor Ansible. Je hebt daar scripts voor beschikbaar en soms moet je het zelf maken. Het is wat makkelijker aan te leren dan Puppet, al is dat laatste zeker geen verkeerde. Ik raad aan om eerst te testen.

Marin
27/02/18, 16:49
Marin bedankt voor je reactie, ik had hierover ook gelezen, alleen zou ik het graag met puppet willen doen. Heb je bewust voor Ansible gekozen of heb je na ervaring met Puppet gekozen voor Ansible?

We hebben wel naar Puppet gekeken. Echter was dat niet makkelijk te integreren in onze reeds bestaande omgeving. Daarnaast nemen wij ook veel bestaande omgevingen in beheer waar je dan makkelijker Ansible in kunt uitrollen dan Puppet.

Ik adviseer je om beiden eens te testen en dan te beslissen wat voor jouw situatie het beste is.

ju5t
27/02/18, 17:20
Je moet vooral kijken wat je goed ligt. Snel de verschillen die ik zo snel uit m'n vingers krijg.

Puppet heeft een agent. Dat kán voordelen hebben afhankelijk van hoe je firewall en platform is ingericht. Die agent is ook het grote nadeel. Zonder agent geen Puppet. Ansible draait bijna overal zonder aanpassingen, ook op netwerk apparatuur.

Het voordeel van de agent is dat het daar over het algemeen bij blijft. Ik werk nu een jaar of 6 met Puppet en ik heb nog nooit een Rubygem hoeven installeren om iets voor elkaar te krijgen op de clients. Bij Ansible heb ik wel al Python modules nodig gehad.

Puppet is geschreven in Ruby. Ansible in Python. Persoonlijk ligt Python mij 100 keer beter dan Ruby. Dat kan meewegen in je keuze.

Ik ben het met iedereen eens die iets zegt over de leercurve van Puppet. Die is absoluut lastiger dan die van Ansible. Puppet heeft daarentegen wat mij betreft wel een krachtiger test framework eromheen. Het testen van Ansible is iets beperkter maar wat er is voor Ansible is ook makkelijker te leren dan Puppet vind ik zelf. Molecule is leuk.

Ik denk dat als ik nu alles opnieuw zou doen ik waarschijnlijk wel voor Ansible zou kiezen. Dat komt dan vooral doordat het in Python is ontwikkelt. Dan wel in combinatie met AWX, want dat Puppet ieder half uur langs komt vind ik wél weer mooier dan standaard Ansible (zonder tooling eromheen).

Yourwebhoster
27/02/18, 21:05
Puppet is geschreven in Ruby. Ansible in Python. Persoonlijk ligt Python mij 100 keer beter dan Ruby. Dat kan meewegen in je keuze.


Als aanvulling: Hoewel een uitbreiding schrijven in Python kan, is het zeer zeker geen vereiste dat je Python kan voor Ansible. Je kan snel de YAML (http://docs.ansible.com/ansible/latest/YAMLSyntax.html) syntax leren en er is voldoende documentatie aanwezig.

SF-Jeroen
28/02/18, 09:20
Je moet vooral kijken wat je goed ligt. Snel de verschillen die ik zo snel uit m'n vingers krijg.

Puppet heeft een agent. Dat kán voordelen hebben afhankelijk van hoe je firewall en platform is ingericht. Die agent is ook het grote nadeel. Zonder agent geen Puppet.
.

Dat is niet helemaal waar. Je kan ook puppet apply doen zonder agent.

ju5t
28/02/18, 11:12
Daar heb je een punt. Dan mis je wel de kracht van Puppet denk ik maar het kan.

ronaldvanhoeven
01/03/18, 13:12
Yourwebhoster geen probleem, het blijft nuttige informatie, bedankt. Ik zal het zeker gaan testen.

- - - Updated - - -
Marin zal ik zeker doen, bedankt.

ronaldvanhoeven
01/03/18, 13:20
ju5t hele nuttige informatie, bedankt voor de post. Ik ga kijken hoe ver ik kom met Puppet, maar zal Ansible zeker in gedachte houden.