Als Devops engineer werk ik veel met terraform. Dit omdat het een standaard is bij DPG waar Competa IT mij gedetacheerd heeft. Ruim een jaar terug kreeg ik een uitdaging. Een multitenant infrastructuur welke per tenant ingesteld kon worden naar de opzet die die nodig had met terraform.
Hoewel de discussie gevoerd kan worden of terraform hier de geschikte tooling voor is stond dit al vast. Binnen DPG zijn standaarden een key en is een goede reden nodig om hier vanaf te wijken. Dit project zou voldoen aan de DPG standaarden. U kunt hier denken aan:
Als gevolg van deze klus was een hele afdeling opgezet. Initëel was ik geen onderdeel van deze afdeling. Met veel geluk bleek de Devops engineer die aangenomen was voor deze afdeling geen ervaring te hebben met terraform. Hoewel ik alleen kennis had van terrible maar wel wat van docker was er door gebrek aan beter voor mij gekozen.
Hier op volgend was een overleg was de initiële infra tekening opgezet. Deze tekening mag natuurlijk niet gedeeld worden maar het lijkt heel erg op: https://aws.amazon.com/blogs/storage/deploy-serverless-drupal-applications-using-aws-fargate-and-amazon-efs/.
Zodoende Allemaal dingen die logisch waren dat het in de opzet kwamen gezien dit leek te voldoen aan de standaarden van DPG. Samen met de architect stond ik achter dit idee en presenteerde het aan mijn manager. Hoewel het verhaal goed ging was ik zenuwachtiger dan ooit. Door gebrek aan beter is er gekozen voor mij en in mijn carrière heb ik hier nog niet mee hoeven te werken. Dit dankzei de DPG tool Terrible.
Na de opzet gezien te hebben komt natuurlijk de vraag. Hoe maak je dit dan multitenant ? Na de initiële opzet was dit ook de vraag voor ons. Na een onderzoek is de keuze uitgekomen op een settings bestand gebaseerd op een standaard config waar vervolgens tenant specifieke config gemaakt kon worden. Dit in combinatie met terraform workspaces werkte perfect in de situatie