CloudTransform: Multi-Cloud Infrastructure as Code via MDE

🚀 Overview

CloudTransform is a Model-Driven Engineering (MDE) project designed to abstract the complexity of cloud infrastructure provisioning. By using a domain-specific abstraction (CloudDSL), architects can define infrastructure once and automatically transform it into provider-specific Terraform configurations for AWS and Azure.

This project leverages the power of the Eclipse Modeling Framework (EMF), Henshin for model-to-model transformations, and Acceleo for model-to-text generation.

---

🏗️ Architecture & Workflow

The pipeline follows a rigorous MDE approach, ensuring consistency and portability across cloud providers.

1. CloudDSL (Source Model): Definition of high-level concepts (Networks, VMs, Security Groups).
2. Henshin (M2M): Logic-based transformation rules that map CloudDSL abstractions to specific Azure/AWS metamodels.
3. Target Metamodels: Provider-specific XMI models (Azure Resource Manager or AWS Terraform).
4. Acceleo (M2T): Template-based generation of executable .tf files.
5. Output: Fully functional Terraform code ready for terraform apply.

---

📺 Demos & Recordings

Explore the project in action through our narrated demonstrations:

• Project Demos: Google Drive Folder

---

💎 Core Components

1. CloudDSL Metamodel

The heart of the project is a provider-agnostic metamodel that simplifies cloud terminology.

---

📝 CloudDSL Syntax & Grammar

The CloudDSL language provides a YAML-like textual syntax for defining infrastructure. It is implemented using Xtext, ensuring real-time validation and IDE support.

Language Structure

A CloudDSL file starts with a provider: block, followed by collections of resources:

provider:
  name: "MyCloud"
  region: "eu-west-1"

networks:
  - name: "MainVPC"
    cidr: "10.0.0.0/16"

subnets:
  - name: "PublicSubnet"
    cidr: "10.0.1.0/24"
    network: "MainVPC"
    isPublic: true

vms:
  - name: "WebServer"
    type: medium
    subnet: "PublicSubnet"
    os: "Ubuntu 22.04"
    securityGroup: "WebSG"

Grammar Reference

Element	Syntax	Attributes
Provider	provider:	name, region
Network	- name: ...	cidr
Subnet	- name: ...	cidr, network (ref), isPublic (bool)
Security Group	- name: ...	rules (list)
Rule	- name: ...	port, protocol (TCP/UDP), direction, action
VM	- name: ...	type, subnet (ref), os, securityGroup (ref)

Enumerations

• VM Types: small, medium, large, mem_small, mem_medium, mem_large.
• Protocols: TCP, UDP, ICMP.
• Direction: INBOUND, OUTBOUND.
• Action: ALLOW, DENY.

---

2. Multi-Target Transformations

The project provides specialized transformations for the two most popular cloud providers:

☁️ Azure Transformation

• Logic: Maps abstractions to ResourceGroups, VirtualNetworks, and LinuxVirtualMachines.
• Target Metamodel:

☁️ AWS Transformation

• Logic: Maps abstractions to VPCs, InternetGateways, ElasticIPs, and EC2 Instances.
• Target Metamodel:

---

🛠️ MDE Pipeline CLI:

I have completed the functional fixes for the Azure transformation and implemented a professional-grade CLI for the entire MDE pipeline.

🚀 Key Improvements

1. Fixed Azure Transformation Loop & Cardinality

• The Problem: A cardinality mismatch in the Azure_NSG.security_rules feature (defined as many in .ecore, but single in Java) caused Henshin to loop infinitely.
• The Fix: Manually synchronized the Java metamodel implementation (Azure_NSG, Azure_NSGImpl, and AzureMetaModelPackageImpl) to correctly handle containment collections.
• Result: Henshin now correctly generates multiple security rules.

2. Corrected Acceleo Template Iteration

• The Problem: The Azure Terraform template was incorrectly iterating over the security_rules collection, leading to AcceleoEvaluationException.
• The Fix: Updated generate.mtl to use a for loop for proper object iteration.
• Result: Valid Terraform blocks are generated for each security rule.

3. Professional CLI Experience

• Robustness: Added input file validation (checks for existence before starting).
• Usability: Added --help support and custom output directory specification.
• Visuals: Colorized shell output in run_pipeline.sh for clear success/failure visibility.
• Diagnostics: Built-in "ping" mechanism to verify critical EMF/Henshin classes at startup.
• Meta-Documentation: Added built-in help for DSL elements (VMs, Networks, etc.) via ./run_pipeline.sh --help-dsl.

---

🔄 Logic Flow

graph TD
    subgraph "Metamodels"
        M1[CloudDSL]
        M2[AWS Metamodel]
        M3[Azure Metamodel]
    end

    Input[sample.mydsl] -->|CLI Step 1| XMI[sample.xmi]
    XMI -->|CLI Step 2| Trans[sample_transformed.xmi]
    Trans -->|CLI Step 3| Output[Terraform Files in Root]

    M1 -.-> XMI
    M2 -.-> Trans
    M3 -.-> Trans

Loading

📂 Execution Overview

---

💻 How to Use

The pipeline supports both AWS and Azure targets on Linux, macOS, and Windows.

Linux / macOS:

# Standard Execution
./run_pipeline.sh <script.mydsl> <target> [out_dir]

# DSL Metamodel Help
./run_pipeline.sh --help-dsl

Windows:

# Standard Execution
run_pipeline.bat <script.mydsl> <target> [out_dir]

# DSL Metamodel Help
run_pipeline.bat --help-dsl

Examples:

• Linux: ./run_pipeline.sh samples/demo.mydsl azure
• Windows: run_pipeline.bat samples\demo.mydsl azure

---

✅ Verification Proof

Successful Run (Azure Task):

=================================================
          MDE PIPELINE SYSTEM RUNNER             
=================================================
  Input Script:  org.xtext.example.mydsl/sample.mydsl
  Target Cloud:  AZURE
  Output Folder: /.../final_output
-------------------------------------------------
[STEP 1] Converting DSL to XMI...
  SUCCESS: DSL Model parsed and saved to .../final_output/generated_dsl_model.xmi
[STEP 2] Running Henshin Model-to-Model (M2M) Transformation...
  Saved transformed model: .../final_output/azure_transformed.xmi
[STEP 3] Generating Terraform Provider Infrastructure (Acceleo)...
  Success: TF generated.
FINISHED: Pipeline execution complete.

Error Handling Proof:

[ERROR] Input DSL file not found: missing.mydsl
FAILED: Pipeline execution encountered errors.

---

📂 Project Structure

Project	Description
emfProject	Implementation of the CloudDSL source metamodel.
CloudDSL.transformations	Contains Henshin rules for M2M (CloudDSL ➔ Azure/AWS).
azureMetaModel / awsmetamodelTerraform	Target Ecore metamodels for specific providers.
azure.to.terraform / aws.to.terraform	Acceleo modules for generating Terraform code.
org.xtext.example.mydsl	Xtext-based textual editor for CloudDSL.

---

⚙️ Installation & Setup

1. Requirements

To work with this project, you need the following tools:

• Eclipse Modeling Tools: The specialized IDE for MDE. Download here.
• Java JDK (17 or higher): Required for Eclipse and EMF.
• Git: For version control.

2. Eclipse Plugin Installation

If they are not pre-installed in your Eclipse bundle, follow these steps:

• Henshin:
  1. Go to Help > Eclipse Marketplace...
  2. Search for "Henshin".
  3. Click Install and follow the wizard.
• Acceleo:
  1. Go to Help > Eclipse Marketplace...
  2. Search for "Acceleo".
  3. Click Install and follow the wizard.
• Xtext:
  1. Go to Help > Eclipse Marketplace...
  2. Search for "Xtext".
  3. Click Install and follow the wizard.

3. Cloning the Project

Open your terminal and run:

git clone https://github.com/m-elhamlaoui/Tranformers.git
cd Tranformers

4. Importing into Eclipse

1. Open Eclipse Modeling Tools.
2. Go to File > Import....
3. Select General > Existing Projects into Workspace.
4. Browse to the cloned Tranformers directory.
5. Select all projects and click Finish.

To run the project because you need depndencies you can use the docker image

docker compose build
docker compose run --rm cli test1.mydsl azure

place test1.mydsl with the name of your file and azure or aws is the name of the provider you want to transform to

---

🛠️ Getting Started

Prerequisites

• Plugins: EMF, Henshin, Acceleo, Xtext (Install via the Eclipse Marketplace if not present in your Modeling Tools bundle).

Execution Steps

1. Define Infrastructure: Use the Xtext editor in org.xtext.example.mydsl to create a sample.mydsl file.
2. Model Transformation:
   • Right-click the .henshin file in CloudDSL.transformations.
   • Apply the transformation using your DSL model as source.
   • Generate the intermediate XMI model (e.g., azure_output.xmi).
3. Code Generation:
   • Run the Acceleo application in azure.to.terraform or aws.to.terraform.
   • Point to the intermediate XMI model.
   • Output the main.tf file.

---

📜 Example Output (AWS)

# Auto-generated AWS Terraform Configuration
resource "aws_vpc" "testVpc" {
  cidr_block = "192.168.0.0/16"
  tags = { Name = "testVpc" }
}

resource "aws_instance" "appServer" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.medium"
  # ... associated subnet and security groups
}

---

🧩 Exemple de modèle XMI après transformation (M2M)

Cette figure illustre le résultat intermédiaire de la transformation Henshin, où le modèle CloudDSL est converti en un modèle XMI spécifique au provider (AWS ou Azure), avant la génération Terraform par Acceleo.

Ce modèle XMI constitue un artefact clé de la chaîne MDE :
il capture explicitement les ressources cloud (VPC, Subnets, NSG, VMs, etc.) conformément au métamodèle cible.

🎓 Academic Context

This project was developed as part of the Model-Driven Engineering (MDE) curriculum, demonstrating the practical application of:

• Metamodeling with Ecore.
• Graph Transformations with Henshin.
• Code Generation Patterns with Acceleo.
• DevOps Integration via Terraform.

---

Developed with ❤️ for Advanced Cloud Orchestration.

---

🔍 Retours d'utilisation

Zakaria Oumghar

Après avoir testé et utilisé ce projet, voici les points forts que j'ai observés :

• Abstraction multi-cloud : j'ai pu définir l'infrastructure une seule fois avec la CloudDSL et générer des configurations Terraform pour AWS et Azure sans modifier le modèle source.
• CLI multiplateforme et prête pour l'automatisation : l'outil en ligne de commande fonctionne sur Windows, macOS et Linux, ce qui facilite son intégration dans des pipelines CI/CD.
• DSL simple et expressif : la syntaxe CloudDSL permet de concevoir rapidement des scripts Terraform complets et puissants, tout en restant lisible et maintenable.
• Génération fiable et reproductible : la chaîne MDE (Henshin pour les transformations et Acceleo pour la génération) produit du code Terraform cohérent, prêt à être appliqué.
• Extensibilité et modularité : les métamodèles et règles de transformation sont conçus pour être étendus (ajout de ressources, adaptation à d'autres providers, etc.).
• Meilleure productivité et prototypage rapide : réduit significativement le temps de prototypage et facilite la standardisation des patterns d'infrastructure.
• Documentation et exemples fournis : démos, exemples et retours d'exécution aident à la prise en main et à l'intégration dans des projets réels.

Ces atouts m'ont permis d'accélérer le développement d'infrastructures en tant que code, d'améliorer la cohérence des déploiements et d'intégrer facilement le workflow dans des pipelines d'automatisation.

📸 Captures des tests et exécutions

• Génération Terraform AWS:

• Exécution du pipeline MDE:

• Résultat des ressources générées:

Hamza Souda

Input

Output

Après avoir testé, utilisé ce projet et exploré la logique du projet, voici mon retour d’expérience honnête et concret.

Impression générale

J’ai trouvé l’idée très intéressante : une chaîne MDE qui transforme un DSL métier en Terraform, c’est élégant et pédagogique. On voit clairement la réflexion derrière l’architecture (CloudDSL → XMI → Henshin → Acceleo → .tf).

On sent aussi que le projet n’est pas juste un proof‑of‑concept : il y a une CLI, des corrections de bugs, et même une option Docker.

Ce que j’ai aimé

• L’abstraction CloudDSL : pouvoir décrire l’infra au niveau métier (réseaux, subnets, VMs, SG) et générer pour plusieurs providers, c’est extrêmement pratique pour standardiser et prototyper rapidement.
• Les correctifs concrets (boucle NSG, itération Acceleo) montrent que l’auteur a testé sur des cas réels et qu’il corrige les problèmes qui gênent l’usage ça donne confiance.
• Le support Docker est un vrai plus : ça rend l’outil accessible sans se plonger tout de suite dans Eclipse + plugins.

L’expérience est globalement positive : le projet génère bien le code Terraform attendu à partir du modèle d’entrée, et s’il reste limité pour des infrastructures complexes nécessitant une structuration personnalisée adaptée à l’équipe et au projet, il est très efficace pour des infrastructures simples ou des usages rapides en solo.

Abderrahmane ESSAHIH

Test Azure using the CLI to generate Terraform from a DSL file:

Conclusion

Le projet est une base solide pour appliquer l’approche MDE à l’IaC : pertinent pour la recherche, l’enseignement et les équipes qui veulent standardiser des patterns d’infrastructure. Pour une adoption industrielle, il faudra compléter la documentation opérationnelle, ajouter des tests/CI et sécuriser la gestion des credentials et du state Terraform.