Onderwerp: Puppet automatisering

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!

Bron van het afraden?

Wij gebruiken Ansible. Puur omdat het makkelijker is dat te integreren in bestaande omgevingen.

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.

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.

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.

Oorspronkelijk geplaatst door ju5t

Nu Ansible Tower beschikbaar is als AWX is er wel wat betere tooling.

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

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.

@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.

Oorspronkelijk geplaatst door ju5t

@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)

@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 en Ansible is wel dat als je een massa update uitvoert dat Ansible een bizar hoog CPU gebruik heeft.

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.

zou TS op vakantie zijn?

Oorspronkelijk geplaatst door ju5t

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 - - -

Oorspronkelijk geplaatst door Ramon Fincken

zou TS op vakantie zijn?

TS was gisteren in ieder geval nog online.

Oorspronkelijk geplaatst door Yourwebhoster

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.