Het leek zo plotseling dat Alex me vroeg om JIRA op te zetten voor het Experience Lab. Wow. Een kans voor mij om deel uit te maken van de grondlegging van HET Experience Lab. Ik voelde me vereerd. Tijd om te laten zien wat ik kan!

Wat bleek nou; zoveel kon ik helemaal niet. Mijn eerste taak was om een fysieke schijf te mounten naar een logische schijf. Zoiets had ik eigenlijk nog nooit eerder gedaan, dus dit bleek mijn grootste leermogelijkheid. Alex en Ferry legde me met plezier de basisvaardigheden van hardeschijf management uit, terwijl Tony aanstoot gaf tot een discussie over de best practices omtrent storage. Hoe moest ik dit nu weer allemaal bevatten? Maar toen opeens, terwijl mijn collega’s me voorzagen van puzzelstukjes, begon ik langzaam het nut in te zien. Mijn doel van het opsplitsen van het volume was dat de door de applicatie gegenereerde data het OS en andere applicaties niet in de weg zit. Opeens was het grotere geheel me duidelijk. De volgende keer begin ik met te vragen “waarom?” in plaats van “hoe?”.

Nu ik het nut begreep van het volume dat aan mij was verstrekt, moest ik nog uitzoeken hoe ik het volume het beste kon opsplitsen. Na een kort onderzoek van de JIRA applicatie, besloot ik om de schijfruimte te verdelen over vier logische volumes. Respectievelijk voor de applicatie, bestanden, logging en de database. Voor Confluence was het een klein beetje anders. JIRA heeft z’n logfiles standaard in de applicatie directory, waar Confluence deze bestanden in de data directory zet. Dus in plaats van een specifiek logisch volume aan te maken voor logbestanden, zoals ik voor JIRA deed, besloot ik dat ik ze net zo goed bij de rest van de Confluence data kon plaatsen. Ik wilde heel graag werken conform basis structuren en methoden, maar ik ben inmiddels tot de conclusie gekomen dat er zowel geen incorrecte als een correcte manier is om logische volumes op te delen.

Na het hele hardeschijf debakel, viel de installatie reuze mee en heb ik er veel van geleerd.

Esther Wien
DevOps Developer