 Hallo, mijn naam is Krasien Darnsen. Ik zal een presentatie geven over relaxer-recover en automatische testen. Dus, wie ben ik? Ik ben een van de meeste contributoren van relaxer-recover. En het is de eerste keer in mijn leven dat ik bijna niets had te zeggen over relaxer-recover. Ik heb andere mensen die dat doen voor mij, maar het is heel mooi. Dus, in deze taak, voor die die niet weten wat relaxer-recover is, is het een beermetel-disaster-recover tool. Het is in bas en het is open-sourced natuurlijk. Het is perfecte, integratabel met andere backup tools, open-sourced en commerciële ones. En het is able to-cloning, cloning to different kind of methodologies, like V2V, P2V enzo on. En het kan werken met heel complex systems en heel grote enterprise systems. Dus het is heel scalable ook. Het is gebruikt in heel grote bedrijven. Een van de bedrijven waar ik de consultie doe, die hebben, ik denk, meer dan 10.000 liningsystemen gebruikt. En het mooiste is dat de bedrijven-recoverie-image heel flexibel is, in het sens dat het van de netwerk kan voelen, van de ISO kan voelen, van de USB kan voelen en zelfs van de RAM. Dat is meer voor testen, maar oké, het is weg. Dus dat was de introductie van Rear, en dat is het effect voor mij. Wat ik wil concentreren in dit talk is testen, want Rear is nu 10 jaar, meer dan 10 jaar oud. En testen was altijd een bein, want het is zo heterogenisch. Het kan op, laten we zeggen, Linux distributions zoals Debian, Ubuntu, Redcat, Suzy, enzo on, enzo on. Het kan ook op verschillende hardwaars rennen. Je hebt ProLines, je hebt Dels, en alles heeft verschillende weken. En dat maakt testen heel moeilijk. Vooral, omdat het geïnteresseerd is, met verschillende back-up-metologies, testen alle deze dingen heel moeilijk. Vooral, zoals ik zei, we kunnen bood van verschillende metaties, ook dat geeft een extra laad van testen dat moet worden gedaan. Maar als we een nieuwe release maken, dat is het probleem, want het is niet mogelijk om alles te testen. En het zal nooit mogelijk zijn om alles te testen. Dat is waarom we een heel goede usercommunity hebben en als we iets brengen en dat brengt, dan weten we het heel snel. Dus, de bottom line is, testen is en we blijven altijd een bein. We proberen op de eerste niveel te overkomen, let's pray of speaking, en get some automated testing done. Dus het is altijd te vinden de juiste balans tussen continuus integratie, continuus ontwikkeling en continuus testen. We hebben al veel jaren, dankzij Susan en de open build services, dat de dagelijks effect, wanneer de steppels zijn gegeven, wanneer we er iets in gaan met het Hitchhub, automatisch zijn de nacht-builds en de nieuwe rpms available. Dat is er al veel jaren. Dus dat was de eerste stap. Wat we nu doen, is als er een nieuwe build is, kunnen we automatisch testen. Natuurlijk verblijven we niet onze contributoren, de active contributoren. We hebben veel, veel contributoren over de laatste 10 jaar, maar zoals in veel open-source projecten, ze doen iets en af en toe zijn ze gegaan, want ze hebben andere soorten interesse. Het is oké. En het is belangrijk dat we weten Hitchhub is onze vriend, onze mastercode is daar, zelfs onze website is daar, de issues zijn daar en ook de vrije support is daar, de issues van Hitchhub. En we hebben ook commerciële supporten nodig voor grote bedrijven die iets gebruiken. Oké. Waarom hebben we starten met automatisch testen? Omdat, met vrienden die een supportcontract hebben, de demand-kwaliteit testen. Dus dat was de eerste stap dat we deden, is om deze automatisch testen te introduceren om alweer een probleem niveau van contributoren en een probleem niveau van stabiliteit in onze software dat het niet brengt, of als het brengt, dat we weten, in effect, automatisch dat het brengt. Dus wat zal de automatisch testen effect doen? Het zal creëren in een disaster recovery image. Het zal creëren in een backup. Het zal ontdekken en ontdekken met een versenmachine over pixie-netwerkbooting. Het zal automatisch ontdekken en het zal starten. En na het starten, het ontdekken met een versenmachine is precies dezelfde van de klanten. We zien het in de volgende slide. Dit is een test-configuration. Dus wat zien we hier? We hebben de klanten, we hebben de server en de ontdekking-vm. Dit is al done via Vagrant. En je hebt de hike-adviseur op de top. We hebben twee netwerken in de HP-netwerk en een private netwerk. We gaan de private netwerk gebruiken. We gebruiken Vagrant. We hebben een Linux host-system nodig, want we zouden een Mac of Windows gebruiken. Maar voor het moment moet ik zeggen Linux. En we hebben Vagrant. En we hebben als hike-adviseur nodig. Je kunt de Oracle VirtualBox of Libvert gebruiken. Dit systeem is met Libvert. Ik heb mijn tweede PC met me met VirtualBox en het werkt ook goed. Dus wat doen we als we de script beginnen? We beginnen met twee vm's, de klanten en de server. De server effecteert wat het is zeggen. Het zal de backup containeren. Het zal ook de pixieboot environment containeren. En de klanten gaan gewoon start-up, installeren. De laatste versie natuurlijk. Start de backup. De backup gaat door de server. En het is done. Het zal automatisch de klanten sit-down. Start-up de recovery-vm. En dat begint de recover. En de recover completely automatically. Als de recover is complete, het zal sit-down en reboot en dan kan het start-up op zichzelf kunnen starten. Alstubel is dat de probleem natuurlijk. Ik heb dit al gezegd. Dit zijn de requirements wat we nodig hebben. Dus ook de automated testing is een simpel scripting. Het is ook available op HitCup. Je kunt het zien hier. Het is op m'n persoonlijke naam-account. Je kunt het ook zien op mijn achtergrond. Je moet het gewoon start-descript. En je kunt het loggen als vagrant. Je kunt het loggen als root. We hebben de password vagrant. En dat is het. Like I said, je kunt het loggen in verschillende manieren tot de vm's. Je kunt de vmc-viewer gebruiken. Je kunt de Oracle VirtualBox of de Libvert VirtualManager gebruiken. Je kunt gewoon de secure shell gebruiken of de vagrant-commands gebruiken. Als het nodig is. Dit is de vmc-viewer. Normaal gebruik ik de vmc-viewer met Libvert. Met VirtualBox gebruik ik normaal de vmc-viewer die door Oracle VirtualBox is. Oké. Loftalk. Let's do the demo. Hier kun je de script zien. Het is een simpele script effect. Het is een sequentieel script. Het heeft wat commands. Het is om de distributie te testen. Het is de ene distributie voor het moment die de Centro7 implementeert. Dat was dus nodig voor de customer. En we kunnen hebben bootmethods. De default bootmethod is pixiebooting. En de andere die ondersteund is iso. Het is ondersteund omdat ik ook een workshop heb met iso. Dus het is gewoon een probleem om het over hier te implementeren. Het is al half implementeerd, maar niet voldoende. De bootserver kan veranderd worden door default. Het is de server vm. Maar als je een andere requirement hebt, kan je het overrulen. Hetzelfde met de provider. Maar ik begin de script en dan kan je over het script praten. Want dit is lipvert. De minusp is de provider. De default is virtualbox. Want dit is lipvert. Ik moet zeggen, minusp lipvert. En dat is het. De rest kan ik als default blijven. Dus het begint. Wat is de script nu? Je kunt het op het bottom zien. Het begint op kant. Het begint op kant en de server vm Dus dit is een puur vakant werk. Vikant starte even voor twee vm's. Ik zou het geleid apologise en cells van op het eind sl templeen. Maar het is nietje veel klaar om een job te doen. Dus wanneer de twee deity slipen, Hopelijk snel, oké, de provisie, ik bedoel niet om een update te hebben voor het moment, dus we wachten voor vijf seconden, omdat je kunt interrompen, nu heb je de status, je hebt de twee klanten en de server-vm gaan rijden, we doen een test, als de network is oké, ja, we kunnen communiceren met de klanten en de server-vm en nu, of de klanten-vm, binnen de klanten-vm, we zullen de laatste reerstnapzot-image uit de OpenSuzi-bouw-servies doen, dat is wat je nu ziet, je ziet, hopelijk zal het werken, want ik heb het niet testen, het is een nieuw, dus dit is slijver, dus het kan niet vervallen, oké, wat je hier ziet, over daar, dat is de ETC Rear Local Configuration, dus wat je hier ziet, dat je gebruikt, pixiebooting, backup is gebruikt, we gebruiken de backup URL, het gaat naar de server, 15, naar de TFB boot-area, maar onder de TFB boot-area, er zal de server-area zijn om de backups te sturen, en je kunt hier zien dat de pixie-bouw-mode onintend is, dat betekent, dus continu, als je hier voor de kernel-kommand lijnt, gebruik ik net.ifnames equals 0, dat is niet nodig voor LiveVert, maar dat is nodig voor VirtualBox, anders zal het gebruiken, bias defnames voor hun network interfaces, en dan zal het brengen van je automatische recoverie, oké, het zal nu starten de live iso pixieboot image gemaakt, het is al gestorven, je kunt het hier zien, en nu is het bezig met de backup, dat zal een minitair doen, ik hoop, het is niet een dating zelf heel vaak, het is hier, maar oké, dat is niet te serieus, dat takes longer, backing up takes longer than recovery. In CentOS 7 omdat dat was de enige requirement, maar heb je dezelfde tool testen met andere distribution, CentOS 6 moet het meestal dezelfde zijn, het zal niet werken, het is gewoon een bedoel om het te implementeren, om het tijd te proberen om het uit te testen, en hoe oud is de automatie? Hoe oud? 1 of 2? Ja, het is heel nieuw, het is heel nieuw, ja, oké, eindelijk, de klanten schalten, we beginnen met de recoverie, het zal proberen met pixieboot, er zijn twee interfaces, de HCP interface, en daar is de private network, het eerst proberen de HCP interface, dat zal niet werken, dan proberen we de tweede interface, dit is Lipferd, als je een virtual box gebruikt, je kunt niet pixieboot van de servervm, je moet pixieboot van de host dat is de limitatie van een virtual box, maar oké, dat is waarom ik zei, je gebruikt Linux, oké, dat is de manier, het is al beginnend de ram image, het systeem is bijna aan het runnen, recoverie image, het is al gefilmd met de harddisk en het is al gestorgen de data, binnen, binnen een minuut of zo, het zal behoorlijk zijn, maar het zal doen dan, het zal de server de pixieboot configureren en zeggen oké, nu moet je de volgende keer van de default harddisk, niet van de network, niet van de ram image, het is al gedaan, met het gestorgen de data, het rebuildeert het beginnende ramdisk, omdat het een cloning was, het is niet exact dezelfde disk size, dus het was een cloning, dit was een v2v migraze dat we gedaan hebben, dus het was geen exacte kopie, het was een andere size van disk, want we zouden nooit rebuilden of het beginnende ramdisk, als het niet dezelfde is, als het dezelfde was, dat is langer dan de recovery van de data, oké, oké, wanneer dit stap is gedaan, dan zijn we klaar, gewoon installeren de grip, bootloader, dat is het stap waar we in de andere toekomst waren, dat ik uit de NBR was en hij zei dat de grap is aan dat stap, oké, 30 seconden, dat is normaal, als je wilt interacten en om iets te bekijken, dat is ook tunabel, maar oké, dat is nog wel fair, 30 seconden, wacht even, is het makkelijk om een paar filesystemen van de backup? Ja, dat is allemaal voorzien, meestal van deze variables, je moet kijken in de, slash user, slash share, slash rear, slash conf, default.conf file, alle gebruikte variables zijn er overgelegd met een paar descriptions, and Johan is very good in making good descriptions, long descriptions and good, mine are mostly some comments effect, smaller comments, but Johan prefers longer comments and a longer text effect and I do agree that it's as useful, oké, system is restarting, so the recovery VM is now completely restored and rebooted and we have our prompt, so the latest rear snapshot was oké, you should be able to log in, password is vagrant and if you do an IP minus A, the password should be 10 which was the client, so we are now exact copy of the client. And during the automated testing you do like any check on the recovered system like checking if a file is there or whatever. Oh well, this is not, I haven't not foreseen this in the talk, let's see, I will close this Q me and this will stop, if I do the help again you will see there is a minus T from test directory, the test directory is this here, these are the tests, they are not from me, they are coming from Red Hat, Red Hat is using these tests to validate rear, if they want to update something and that use beaker lip and it already works, but I probably don't have time to do something, wait a second, I will stop, I will cheat a bit, I will halt the recover, I will start up the client again because it's vagrant, even if the recovery is now declined it would still want to check the vagrant client, sorry about that, starting up this, then I go one back, I will use the smallest test which is a very simple one, let's just check out the layout of your system, it's something that has been modified, if you update the kernel or you modify or increase one of your volumes then it's required that you rebuild if you can do rear image, all right, so the test directory, so that's the check change disk layout, so here automated, I have to use the lipvert and the test, let's use this one, oops okay, let's invalidate the test, so now we can skip the bringing up the vagrant because they are already up and running, so that goes quicker, voila, it copies effect the complete test to the client and it already did the test, so the first test is done and what I do I copy the test back to my hosted system here, so every time I run a test I also have a copy of the logging, so that was a very quick demo of the tests that are possible, the other test we'll take this more time because it will also make ISO images, check the ISO images or even make them back up, but I don't have time for this to demonstrate, this demonstrates what the possibilities are of these test scripts prepared by Red Hat, this is written in BakerLip but yesterday I learned something new with Bats and I will use that in the future also, yes, everything is all Hitchhub, it's made available by Red Hat also, are there any questions whatsoever, was it clear enough, it was a nice talk for me, because I didn't have to say too much, system did it for me, a question, ok, the question was, do I have an estimation, how much time it will take to bring another system, distribution effect into the rear automated testing, if it's an RPM base it's rather quick, if it's for example in W1 it will take a bit more time, but I think normally a few days, a few days would be enough, because the methodology is exactly the same, it's maybe in the other packages and for the rest it's exactly the same, the framework is there so it's only just a matter of making the right moves in fact, any other questions, no, thank you very much for your time en please enjoy the rest of the day here or outside, thank you.