Contribuer aux scénarios

Le Cloud-Challenge est modulaire et peut accueillir autant de scénarios que possible ! Cependant les ressources d'un nouveau scénario doivent répondre à certains critères.

Chaque scenario est désigné par un sous-groupe sous GameDay et doit être appelé de la manière suivante : scenario-difficulty-XX-name

Pour le scenario easy 01 simple webapp on obtient le nom de groupe suivant : scenario-easy-01-simple-webapp
Pour le scénario easy 01 simple webapp d'Azure, on obtient le nom de groupe suivant : scenario-easy-01-simple-webapp-azure

Repo des étapes

Chaque scenario est découpé en plusieurs étapes, chaque étape dispose de son propre repository gitlab situé dans le sous-groupe du scenario et appelé de la manière suivante : scenario-stepXX-name

Pour la step 1 du scenario easy 01 simple webapp on obtient le nom de repo suivant : scenario-step01-asg

Arborescence des fichiers

Le repo doit contenir :

• Une description de la step dans la description du repo
• un dossier /init qui contient les modules terraform et fichier terragrunt pour initialiser l'architecture de la solution
• un dossier /solution (optionnel) qui contient les modules tf et terragrunt de la solution
• README.md: qui contient la marche à suivre pour setup, un schéma de l'architecture de la solution (archi.jpg) ainsi qu'une solution détaillée pour réussir le step.
• archi.jpg: schéma de l'architecture de la solution
• rules.md: qui contient les règles du jeu pour cette step avec les infos nécessaires aux joueurs.
• rules.json : qui contient les règles pour le moteur des règles et des bulletpoints. Le fichier doit suivre un certain template, décrit dans la documentation du moteur de règles : https://www.npmjs.com/package/json-rules-engine

Les nom des fichier README.md, archi.jpg et rules.md sont à respecter impérativement pour permettre au parser du server admin de récupérer leurs infos.

Structure des fichiers :

.
├── README.md
├── archi.jpg
├── rules.json
├── init
│   ├── live
│   │   └── eu-west-1
│   │       ├── env.hcl
│   │       └── stage
│   │           ├── template
│   │           │   └── terragrunt.hcl
│   │           └── terragrunt.hcl
│   └── modules
│       └── template
│           ├── main.tf
│           ├── outputs.tf
│           └── variables.tf
├── rules.md
└── solution
    ├── live
    │   └── eu-west-1
    │       ├── env.hcl
    │       └── stage
    │           ├── template
    │           │   └── terragrunt.hcl
    │           └── terragrunt.hcl
    └── modules
        └── template
            ├── main.tf
            ├── outputs.tf
            └── variables.tf

Terraform

La déclaration de toutes les ressources s'effectuent avec Terraform 0.13 ou supérieur.

Modules

Le dossier /modules implémente les différents modules terraform. Terragrunt (dossier /live) permet une abstraction supplémentaire et facilite la génération des buckets où sont stockés les tf.state.

Chaque nouveau module doit respecter le nom suivant : tf-provider-xxx (pour module Terraform - avec provider, le nom du provider (aws ou azure)), une documentation sur son utilisation est préférable.

Permissions

Il est important de vérifier que les comptes "joueurs" ont bien toutes les permissions requises pour compléter le scenario (en fonction de l'architecture multi-compte).

Règles

Chaque étape de scénario doit posséder des règles de jeu, définies dans rules.md, avec un schéma de l'architecture voulue.

Solution

Une solution pas à pas doit être documentée dans le README du repo associé.

Scoring

Les nouvelles ressources clés à créer (ex: base MySQL dans le scénario RDS) doivent être monitorées pour permettre de les scorer (cf scoring).