Onderwerp: Hoe doen jullie een update van jullie servers?

Wij beheren zo'n 70-80 servers voor klanten, maar doen het eerlijk gezegd nog handmatig bij dingen zoals de update die nodig was voor GHOST. Met 2 man zitten we dan een middagje updates te verwerken.

Dit heeft ermee te maken dat we simpelweg nog nooit tijd erin gestoken hebben om dit te automatiseren, maar ook omdat er toch wel veel handmatig werk aan te pas komt.
De meeste servers kunnen bijvoorbeeld wel herstart worden na een update, die 5-10 minuten downtime is niet zo'n probleem. Echter zijn er een hoop afwijkende zaken waarbij het beter is om eerst planning te doen, goedkeuring te vragen, of goed in de gaten te houden dat het fallback systeem eerst opstart.

Wij doen het nu nog handmatig maar zijn aan het kijken wat we hiervoor willen inzetten. Het valt me op dat er weinig partijen zijn die Spacewalk gebruiken? Voor ons zal het Puppet, Ansible of Spacewalk worden.

Oorspronkelijk geplaatst door Mark17

Via een eigen oplossing die we hebben ontwikkeld enkele jaren terug. Inmiddels zijn we aan het kijken naar enkele aanpassingen om het nog wat simpeler in gebruik te maken. Over 1 uur verdeeld starten alle updates, vervolgens krijgen we een terug koppeling en vinken we af wat er gestart is en af is. Wat na een bepaalde periode (afhankelijk van de update) na de start nog niet is afgerond loggen we even op in om de status te controleren. Dit systeem geeft ons ondanks veel maatwerk/verschillende configs toch de vrijheid en het gemak om bepaalde updates snel uit te rollen over meerdere systemen.

Via CLI of GUI? De rest kennen we wel, SCREENSHOTS! Hetzelfde geld voor @vDong .

Oorspronkelijk geplaatst door Domenico

Via CLI of GUI? De rest kennen we wel, SCREENSHOTS! Hetzelfde geld voor @vDong .

Nog CLI only. Bij de volgende update komt er een GUI, al is het maar omdat het makkelijker uit te leggen is aan derden en met een aantal aanpassingen het mogelijk wordt om het commercieel aantrekkelijker te maken.

Oorspronkelijk geplaatst door TotallyHosted

Wij beheren zo'n 70-80 servers voor klanten, maar doen het eerlijk gezegd nog handmatig bij dingen zoals de update die nodig was voor GHOST. Met 2 man zitten we dan een middagje updates te verwerken.

Op dat ene middagje heb je salt/ansible wel deployed op 70-80 servers, de laatste 10 minuten van die middag kan je dan afsluiten met de effectieve update...
Het mooie aan ansible is gewoon dat het met SSH keys werkt, geen agents die je op bakken van klanten moet installeren (tov salt).

Mogen bepaalde bakken niet herstart worden, steek je ze in een andere group en shedule je het in met de klant om dat op een later tijdstip te doen...

Oorspronkelijk geplaatst door Wynand

Op dat ene middagje heb je salt/ansible wel deployed op 70-80 servers...

Alhoewel dat technisch misschien best mogelijk is, is het advies om te veranderen van patch management systeem op het moment dat je hoognodig moet patchen natuurlijk niet echt goed advies.
Je gaat zoiets eerst bestuderen, daarna in een test op een klein aantal machines waarna je het uiteindelijk op een door jezelf gekozen moment in productie neemt.

Oorspronkelijk geplaatst door Domenico

Via CLI of GUI? De rest kennen we wel, SCREENSHOTS! Hetzelfde geld voor @vDong .

Komt zeker, echter beetje te druk gehad dit weekend.

Oorspronkelijk geplaatst door Wynand

Op dat ene middagje heb je salt/ansible wel deployed op 70-80 servers, de laatste 10 minuten van die middag kan je dan afsluiten met de effectieve update...
Het mooie aan ansible is gewoon dat het met SSH keys werkt, geen agents die je op bakken van klanten moet installeren (tov salt).

Mogen bepaalde bakken niet herstart worden, steek je ze in een andere group en shedule je het in met de klant om dat op een later tijdstip te doen...

Goede tip, en we zullen daar zeker in de nabije toekomst naar gaan kijken!

Maar wat doet iedereen als er iets mis gaat met een update? Hoe krijg je feedback van de tool die je gebruikt? Draait iedereen rapportage services van Puppet of gaat men handmatig door de output van Ansible om te kijken wat er wel of niet is gewijzigd?

Oorspronkelijk geplaatst door getUP

Maar wat doet iedereen als er iets mis gaat met een update? Hoe krijg je feedback van de tool die je gebruikt? Draait iedereen rapportage services van Puppet of gaat men handmatig door de output van Ansible om te kijken wat er wel of niet is gewijzigd?

Ben ik op zich ook wel benieuwd naar.

Ik moet zeggen (knock on wood) dat ik vrijwel nooit problemen heb dat een update fout loopt, maar mocht dat incidenteel wel gebeuren en dat er een service down gaat, dan klopt binnen een minuut meneer nagios wel aan of komt er een mail binnen dat de update niet gelukt is.
De meeste dingen die ik via scripts afvang is meestal puur gebaseerd op exitcodes.
Ik genereer wel eerst een lijst van dingen die geupdate moeten worden, knal de updates aan en genereer na afloop die lijst nogmaals. Als daar dan nog iets in staat dan kijk ik daar handmatig even naar.

Oorspronkelijk geplaatst door getUP

Maar wat doet iedereen als er iets mis gaat met een update? Hoe krijg je feedback van de tool die je gebruikt? Draait iedereen rapportage services van Puppet of gaat men handmatig door de output van Ansible om te kijken wat er wel of niet is gewijzigd?

Dit is een beetje afhankelijk van wat je update of patched, zelf checkte ik na het uitrollen van de glibc update bijvoorbeeld met de one-liners salt '*' cmd.run 'ldd --version' en salt '*' cmd.run 'rpm -q glibc' welke versies er geïnstalleerd zijn op alle servers, je krijgt dan netjes een lijst terug (alle servers onder elkaar) met de output, daar ging ik even handmatig doorheen om te verifiëren of de patch geïnstalleerd was.

Daarnaast is het inderdaad ook zo simpel als je Monitoring tools goed in de gaten houden of er iets onverhoopt down gaat, hier krijg je dan altijd binnen één minuut wel een melding van.

Is bij jullie iedere klant precies hetzelfde of heeft iedere klant een acceptatie omgeving waar de updates eerst worden getest? Ik weet niet hoeveel servers jullie beheren, maar afgaan op monitoring bij updates is niet echt schaalbaar, tenzij je veel dezelfde type servers hebt die volledig gelijk zijn aan elkaar en je dus goed kunt testen en ook echt alleen hoeft te reageren op incidenten.

Oorspronkelijk geplaatst door getUP

Is bij jullie iedere klant precies hetzelfde of heeft iedere klant een acceptatie omgeving waar de updates eerst worden getest? Ik weet niet hoeveel servers jullie beheren, maar afgaan op monitoring bij updates is niet echt schaalbaar, tenzij je veel dezelfde type servers hebt die volledig gelijk zijn aan elkaar en je dus goed kunt testen en ook echt alleen hoeft te reageren op incidenten.

Waarom moeten die volledig gelijk zijn aan elkaar? Je kunt (althans met nagios) toch elke server testen zoals je zelf wilt? Of je nu slechts een ping wilt doen of een complete testset op de server aantrappen, maakt geen verschil?
Je bepaalt natuurlijk zelf 'wat' een incident is. Voor sommige bakken is het doen gaan van apache pas een incident, voor een andere kan het dat al zijn als er notices op een website komen na bv. een php update. Of je nagios nu een 'ping' of een 'wget http://blal | grep NOTICE' voorschotelt zal hem om het even zijn.
Maar dat is dan de unattended versie, he. Zelf zit ik meestal toch met een bak koffie naar een paar ssh schermen te kijken en zie ik toch wel of iets mis gaat. Kan een middag duren, maar ja... kan me ergere middagen voorstellen

Wat ik bedoel is dat de meeste providers servers beheren voor allerlei verschillende klanten. Wanneer je 500 servers hebt is de kans groot dat veel iedere keer net iets anders werkt of dat de applicatie van de klant net iets anders in elkaar steekt. De kans dat er iets mis gaat neemt daardoor toe. Dat is anders als je een shared platform hebt met 250 directadmin servers. Dan kun je doortesten voor je de update los laat in het wild, maar vaak is die luxe er niet.

En samen met de klant bepaal je natuurlijk wat een incident is of niet, maar wat ik bedoel is dat je er niet altijd vanuit kunt gaan dat een update succesvol is. Wanneer je veel servers in beheer hebt is afgaan op incidenten - even in het midden gelaten wanneer iets een incident is - soms te reactief en wil je sneller feedback zodat je niet in een enkele batch 10% van je platform om zeep helpt. Dat is nog te behappen met 10 servers, maar bij 100 servers wordt het al wat vervelender, laat staan 1000 servers. Stiekem is dat wat je dus ook doet met SSH, maar ik vroeg me af of het ook slimmer kon :-)