Vraag Waarom Chef / Puppet gebruiken via shell-scripts?


Nieuw bij Puppet- en Chef-tools. Het lijkt erop dat de taak die ze doen kan worden gedaan met shell-scripting. Misschien was het in shellscripts gedaan totdat deze bij elkaar kwamen.

Ik ben het ermee eens dat ze leesbaarder zijn. Maar zijn er nog andere voordelen ten opzichte van shell-scripts dan alleen leesbaar zijn?


78
2018-05-01 10:13


oorsprong




antwoorden:


Een domeinspecifieke taal maakt een groot verschil in de hoeveelheid code die u schrijft. Je zou bijvoorbeeld kunnen stellen dat er niet veel verschil is tussen:

chmod 640 /my/file

en

file { "/my/file":
    mode => 640,
}

maar er is een groot verschil tussen deze:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

en

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

Wat gebeurt er als de wget faalt? Hoe gaat je script hiermee om? En wat gebeurt er als er iets daarna in uw script staat waarvoor $ FILE nodig is om de juiste inhoud te hebben?

Je zou kunnen beweren dat je het gewoon zou kunnen zetten echo "Hello world" > $FILE in het script, behalve dat in het eerste voorbeeld het script op de client moet worden uitgevoerd, marionet compileert dit allemaal op de server. Dus als u de inhoud wijzigt, hoeft u deze alleen op de server te wijzigen en wordt deze voor zoveel systemen gewijzigd als u hem wilt inschakelen. En marionet maakt afhankelijkheden en overdrachtsproblemen automatisch voor u af.

Er is gewoon geen vergelijking: met de juiste configuratiebeheertools bespaart u tijd en complexiteit. Hoe meer je probeert te doen, hoe meer shell-scripts ontoereikend lijken, en hoe meer moeite je bespaart door het met poppen te doen.


55
2018-05-01 11:14



@Paul Gear, het is een te grote vereenvoudiging om te zeggen dat hulpmiddelen voor configuratiebeheer op de lange termijn de beste keuze zijn. Als u bijvoorbeeld AWS gebruikt, kan een shellscript de server helemaal opnieuw bouwen, enkele tests uitvoeren en als u zeker weet dat de AWS-instances in orde zijn, een afbeelding maken. Vervolgens kunt u deze afbeelding in een voorbeeld- of verzamelomgeving implementeren voor verdere tests, nadat u hebt gecontroleerd dat de afbeelding goed is voor uw doeleinden, drukt u vervolgens op productie. Hulpprogramma's voor configuratiebeheer helpen helemaal niet in dit scenario. - Derek Litz
Als u nu 100's dedicated servers wilt beheren die mensen dagelijks gebruiken (en u hebt weinig controle over wat ze doen, ten onrechte of niet), dan moeten hulpmiddelen voor configuratiebeheer worden gebruikt. - Derek Litz
Dit is geen erg overtuigend voorbeeld. Ik zou kunnen beginnen met wat en dan zou ik niet in een vreemde toestand belanden. Is bestand als een transactie die wordt teruggedraaid als een van de stappen niet slaagt? - PSkocik


Dit zal een impopulaire mening zijn, maar configuratiebeheersystemen zijn niet noodzakelijkerwijs beter. Soms is simpel het beste.

Er is een duidelijke leercurve en administratieve overhead gekoppeld aan het configuratiesysteem dat u kiest. Je introduceert immers een afhankelijkheid. Zoals met elke automatisering, moet u er ook op letten dat de beveiliging wordt gehandhaafd in geïmplementeerde configuraties.

Ik heb maar een paar keer gevallen waarin we configuratiebeheer hebben geïmplementeerd en het is vastgelopen. Het was altijd wanneer er een groot aantal systemen was met repetitieve configuratie en de behoefte om configureerbare cookiesnijderimplementaties uit te voeren.


31
2018-05-01 14:58



Wanneer de kosten voor het beheer van de omgeving zo groot zijn dat het beheer van de automatisering echt goedkoper is. Als het eenvoudiger is om in Git beheerde scripts te scripten of dingen in een ssh-multiplexer in te stellen, doen we dat. Het belangrijkste voor mij is dat ik de systemen bewaak en verifieer dat alles functioneert zoals verwacht. Zolang ik een waarschuwing krijg wanneer iets verkeerd is geconfigureerd, is het niet zo belangrijk hoe het wordt geconfigureerd. - kenchilada
@ewwhite "wanneer besluit u te automatiseren versus niet" xkcd.com/1205 - MikeyB
Meer moderne tools zoals Ansible hebben aanzienlijk minder inzet / managementoverhead dan Chef of Puppet, en vereisen weinig tot geen afhankelijkheden (vooral Ansible is agentloos). Dit verlaagt echt de lat voor acceptatie. - GomoX
@ewwhite U automatiseert wanneer u dat wilt voor persoonlijke productiviteit. Je leert door te automatiseren, je leert niet door alledaagse taken te doen. Leren = productiviteitsstijging en iteratieve verbetering. De automatisering combineert dit om meer positieve resultaten te produceren. Het is een positieve sneeuwbal in plaats van een negatieve. Technische vooruitgang versus technische schuld. - Derek Litz
@ A-B-B Nee, dat is niet impliciet. Ik noem niet eens shellscripts, ik noem automatisering als een algemene praktijk. Je kunt dingen automatiseren met shell-scripts en de scripting abstractie leren in plaats van dingen handmatig te doen, wat je niet alleen de tijd zal besparen om die taak opnieuw te doen, het zal fouten voorkomen. Ook zou je je volgende script iets beter moeten kunnen schrijven dan het vorige. Een positieve sneeuwbal ... Als je echter een expert bent in het schrijven van scripts en je scripte niets dat je ooit nog een keer zult gebruiken, het helpt je niet om op een of andere manier tijd te leren of te behouden. - Derek Litz


Je hebt je eigen vraag beantwoord ...

Automatisering wordt steeds schaalbaarder en geformaliseerd. Puppet en Chef worden tegenwoordig beschouwd als standaard (controleer de vacatures).

In elkaar geschoven shell-scripts hebben hun plaats, maar dat zijn ze niet schaalbaar in de context van de DevOps-beweging. Leesbaarheid maakt daar deel van uit.


23
2018-05-01 10:40



Zijn shellscripts op een of andere manier minder geformaliseerd? Maakt het citeren van functie-advertenties een argument overtuigend? En een duvel is nogal een schande, want hij / zij is onderontwikkeld als ontwikkelaar. De link zegt eigenlijk niets over schaalbaarheid. Is de claim dat shellscripts niet schaalbaar zijn? Ik vind Puppet interessant, maar niet noodzakelijk om de redenen in het antwoord. - A-B-B
Vacatures weerspiegelen de echte markt voor specifieke vaardigheden. Ja, het gebruik van configuratiebeheer voor het beoogde doel is meer schaalbaar, robuuster en gemakkelijker te documenteren dan shellscripts. Ik ben in veel omgevingen geweest, en de meeste scripts die ik zie, zijn niet zo geconstrueerd dat men 'productiekwaliteit' zou vinden en georganiseerd om uitzonderingen te verwerken. Zie het geaccepteerde antwoord om te begrijpen waarom. - ewwhite
"En een duvel is nogal een schande, want hij / zij is onderontwikkeld als ontwikkelaar." Dit is gewoon niet waar. DevOps is een ontwikkelingsspecialisatie, net als Web Development. De patronen en werkwijzen van software-ontwikkeling zijn nog steeds van toepassing. Je moet over DevOps lezen. - Chaim Eliyah


Chef maakt het een stuk eenvoudiger om te beheren en versie het opzetten van een complexe infrastructuur, met name in elk type cloudomgeving versus het handmatig ftp- of scp-uitvoeren van een aantal shell-scripts die op een niet-gestandaardiseerde manier zijn georganiseerd. Afhankelijk van het aantal afhankelijkheden dat u moet beheren, kan de omvang van deze winst aanzienlijk variëren, waardoor het besluit om over te schakelen naar een CM-oplossing voor veel mensen niet voor de hand ligt.

Het echte (vaak onbezongen) voordeel van Chef is idempotentie. In staat zijn om zeker te zijn van de status van een resource, ongeacht de combinatie van recepten die worden uitgevoerd met overlappende interesses, is een enorm voordeel ten opzichte van shell-scriptconfiguratie. Als u nu shell-scripts voor configuratie heeft, vraagt ​​u zich dan af hoeveel van deze programma's meerdere keren kunnen worden uitgevoerd zonder onbedoelde / ongewenste gevolgen?

Een goede CM-oplossing helpt om succes op schaal te garanderen door cross-platformautomatisering en teamsamenwerking te vereenvoudigen. Hoewel het mogelijk is om dit allemaal te bereiken met een goed georganiseerde, correct onderhouden, versie-groep van shell-scripts; je moet jezelf afvragen "waarom". Chef / Puppet en soortgelijke technologieën kwamen tot stand omdat een groep getalenteerde SysOps het zat was om steeds weer dezelfde problemen op te lossen en op weg was om ons een betere optie te geven.

Sleutel stukken:

  • idempotentie
  • Ease of Dependency Management (versiebeheer)
  • Gestandaardiseerde organisatie (geaccepteerd op sectorniveau)
  • Abstractie om serverconfiguratietaken te scheiden van systeemniveau-details
  • Mogelijkheid om kennis van de gemeenschap te benutten (die gegarandeerd alle bovenstaande principes omvat)

13
2018-05-03 19:11



Idempotence is met ss nauwelijks onmogelijk. Afhankelijkheden worden goed beheerd door yum / apt, etc. Acceptatie is niet relevant. Er bestaat community-kennis voor ss. Ik accepteer echter dat het niet alleen nodig is om een ​​aantal scripts te kopiëren en ook om systemen centraal te configureren. Ik hoor dat poppenspeler een agent aan de kant van de klant nodig heeft. - A-B-B


Met moderne hulpmiddelen voor configuratiebeheer, zoals Puppet en Chef, kunt u de staat van een systeem in plaats van zorgen te maken over activiteiten nodig om een ​​geconfigureerde server te realiseren.

Uw chmod-opdracht gaat er bijvoorbeeld van uit dat het bestand bestaat, de gebruiker die het bestand bezit, bestaat, dat de mappen zijn gemaakt, enzovoort. Uw script moet daarom rekening houden met al deze vereisten.

Staatsgebaseerde configuratiebeheertools zijn eenvoudiger: u geeft er alleen maar om dat het bestand de juiste machtigingen heeft. Hoe dat wordt bereikt, is het probleem van de tool.


10
2018-05-20 02:19



Eigenlijk mijn chmod gaat er niet van uit dat het bestand bestaat omdat het bestand door het script is gemaakt of door het systeem is getest. - A-B-B


Als servers voor u wegwerpbaar zijn of als u reden hebt om meer dan een paar tegelijk op te staan, voldoet een volledig CM-systeem veel beter aan uw behoeften dan een reeks shell-scripts.

Als uw bouwbehoeften bescheiden zijn (of als ambachtelijke, ambachtelijke, biologische fairtrade-servers met vrije uitloop zijn), houd het dan eenvoudig.

Persoonlijk heb ik, na uitgebreid gebruik te hebben gemaakt van Chef bij een vorig optreden, ik geprobeerd het 'simpel te houden' tijdens dit optreden, maar ik miste echt de primitieven, abstracties en macht die Chef voorzag. Zelfs als je in een situatie komt waarin je kunt krijgen wat je nodig hebt van een paar shell-commando's, kun je gewoon die gebruiken met een 'command'-blok, je shell-commando's precies invoeren zoals je ze in shell zou schrijven.

Met dat gezegd, kun je Chef zonder server (chef-solo) draaien, en ik ben er vrij zeker van dat Puppet een analoog heeft, waar je nog steeds de kookboeken en recepten van anderen kunt gebruiken zonder een centrale server te draaien.

Een ander voordeel is de gemeenschap: er zijn veel mensen (veel daarvan zullen slimmer en / of meer ervaren zijn dan u). Persoonlijk vind ik het geweldig als iemand anders mijn werk voor mij heeft gedaan, vaak meer uitgebreid dan ik zou hebben gedaan.


9
2018-05-01 22:32





Ik heb een op shell-script gebaseerd serverautomatiseringsraamwerk gemaakt: https://github.com/myplaceonline/posixcube

Ik ben er zeker van dat ik niet de eerste ben die dit soort projecten doet, maar ik kon zoiets niet vinden dat paste bij mijn behoeften, dus ik dacht dat anderen dit nuttig zouden vinden. Ik had alleen ervaring met Chef, maar toen ik begon rond te kijken naar Ansible en anderen, wilde ik shellscripts een kans geven, en ik vind het resultaat tot nu toe leuk.


1
2017-12-25 01:15