TINA OS et la compatibilité API AWS d'OUTSCALE

OUTSCALE repose sur TINA OS, un orchestrateur cloud développé en France à partir de 2010, qui pilote l’ensemble de la plateforme. Au-dessus de TINA OS, deux interfaces API coexistent : OAPI, l’API native OUTSCALE, et un ensemble d’API compatibles AWS (FCU, LBU, EIM, OOS) qui acceptent les mêmes appels que les APIs EC2, ELB, IAM et S3 d’AWS. Cette double exposition est le vecteur de transférabilité des compétences entre les deux écosystèmes — un point central de la stratégie OUTSCALE.

Ce que vous allez apprendre

Ce qu’est TINA OS et sa place dans l’architecture OUTSCALE.
La distinction entre l’API OAPI native et les API compatibles AWS (FCU, LBU, EIM, OOS).
Comment configurer un client aws-cli ou un SDK AWS pour pointer sur OUTSCALE.
Les limites de la compatibilité AWS — ce qui est couvert, ce qui ne l’est pas.
Le bénéfice de transférabilité entre AWS et OUTSCALE pour les compétences et les outils.

Prérequis

Connaître les bases du cloud et le concept d’API REST.
Avoir lu le Vocabulaire OUTSCALE ↔ AWS pour la mise en correspondance des services.
Une familiarité avec AWS (EC2, S3, IAM) facilite la compréhension mais n’est pas obligatoire.

TINA OS — l’orchestrateur cloud souverain

TINA OS est l’orchestrateur cloud d’OUTSCALE, développé en France depuis la création de l’entreprise en 2010. Il joue, dans la stack OUTSCALE, le même rôle que OpenStack dans certains clouds privés : il abstrait l’infrastructure matérielle (hyperviseurs, stockage, réseau) et expose une API REST qui permet de piloter l’ensemble.

Quelques caractéristiques structurantes de TINA OS :

Développé en France par les équipes OUTSCALE, à partir de briques open source sélectionnées et intégrées.
Couche d’abstraction entre l’infrastructure physique et la couche IaaS exposée aux clients.
Infrastructure sous-jacente basée sur Cisco UCS sous KVM (hyperviseur open source), avec stockage NetApp et CPU Intel.
Exposition API unique : tous les services cloud OUTSCALE passent par TINA OS, qui les rend accessibles via OAPI ou via les API AWS-compatibles.

Le fait que TINA OS soit développé en France est un point structurant pour la souveraineté : la maîtrise du logiciel d’orchestration reste sous juridiction française, ce qui n’est pas le cas pour les clouds reposant sur des composants propriétaires non-européens.

Deux interfaces API au-dessus de TINA OS

Au-dessus de TINA OS, OUTSCALE expose deux jeux d’API que vous pouvez utiliser pour piloter votre infrastructure.

L’API native — OAPI

OAPI (OUTSCALE API) est l’API native d’OUTSCALE, conçue spécifiquement pour la plateforme. Elle expose l’intégralité des services et fonctionnalités, y compris ceux qui n’ont pas d’équivalent AWS (FlexibleGpu, VmGroup, VmTemplate, ApiAccessPolicy, CarbonFootprint, etc.).

Caractéristiques :

Endpoint unique par région : https://api.eu-west-2.outscale.com/api/v1 et https://api.cloudgouv-eu-west-1.outscale.com/api/v1.
Schéma cohérent : CreateXxx, ReadXxx, UpdateXxx, DeleteXxx (par exemple CreateVms, ReadVolumes, DeleteNet).
Authentification par signature des requêtes avec votre AK/SK.
Format JSON pour les requêtes et les réponses.

L’OAPI est l’API à privilégier pour un projet nouveau sur OUTSCALE qui veut exploiter au mieux la plateforme.

Les API compatibles AWS

OUTSCALE expose en parallèle quatre services qui acceptent les mêmes appels que les APIs AWS correspondantes. Cette compatibilité est mise en place depuis les débuts de la plateforme : OUTSCALE a fait le choix stratégique de suivre la grammaire AWS dès 2010, parce qu’aucun standard de marché n’existait et qu’AWS était (et reste) le leader.

Service OUTSCALE	API AWS compatible	Endpoint type
FCU (Flexible Compute Unit)	EC2	`fcu.eu-west-2.outscale.com`
LBU (Load Balancer Unit)	ELB Classic	`lbu.eu-west-2.outscale.com`
EIM (Elastic Identity Management)	IAM	`eim.eu-west-2.outscale.com`
OOS (OUTSCALE Object Storage)	S3	`oos.eu-west-2.outscale.com`

Concrètement, vous pouvez :

Utiliser aws-cli directement, en pointant sur les endpoints OUTSCALE.
Utiliser un SDK AWS (boto3, AWS SDK for Go, etc.) avec les mêmes appels.
Utiliser Terraform avec le provider aws (avec quelques limitations) ou avec le provider outscale dédié pour une couverture plus complète.
Utiliser des outils tiers conçus pour AWS (par exemple, des scanners de sécurité comme Prowler) qui peuvent fonctionner partiellement sur OUTSCALE via cette compatibilité.

Configurer `aws-cli` pour OUTSCALE

L’usage le plus simple consiste à pointer le client AWS sur les endpoints OUTSCALE. Voici un exemple pour aws-cli.

# Configuration des identifiants OUTSCALE
export AWS_ACCESS_KEY_ID="<votre AK OUTSCALE>"
export AWS_SECRET_ACCESS_KEY="<votre SK OUTSCALE>"
export AWS_DEFAULT_REGION="eu-west-2"

# Lister les instances via FCU (compatible EC2)
aws ec2 describe-instances \
  --endpoint-url https://fcu.eu-west-2.outscale.com

# Lister les buckets via OOS (compatible S3)
aws s3 ls \
  --endpoint-url https://oos.eu-west-2.outscale.com

# Créer un user via EIM (compatible IAM)
aws iam create-user \
  --user-name dev-team \
  --endpoint-url https://eim.eu-west-2.outscale.com

Pour rendre la configuration persistante, vous pouvez créer un fichier ~/.aws/config avec un profil dédié OUTSCALE :

[profile outscale]
region = eu-west-2
endpoint_url = https://fcu.eu-west-2.outscale.com

Compatibilité Terraform

Pour Terraform, deux approches sont possibles :

Provider `outscale` dédié (recommandé)

Le provider Terraform OUTSCALE officiel (publié par Outscale sur le registre HashiCorp) couvre les principales ressources OAPI — VMs, Nets, Subnets, Security Groups, EIM, BSU, OOS, Snapshots, Keypairs, Load Balancers, et depuis la version 1.4.0, l’API OKS pour gérer les clusters Kubernetes managés. Sa couverture évolue au fil des versions ; vérifier les release notes GitHub au moment de l’écriture pour la liste à jour. C’est l’approche recommandée pour un nouveau projet.

terraform {
  required_providers {
    outscale = {
      source  = "outscale/outscale"
      version = "~> 1.5"
    }
  }
}

provider "outscale" {
  access_key_id = var.osc_access_key_id
  secret_key_id = var.osc_secret_key_id
  region        = "eu-west-2"
}

Provider `aws` sur les API compatibles

Pour les équipes qui ont déjà une base de code Terraform AWS importante, le provider aws peut fonctionner partiellement en pointant sur les endpoints OUTSCALE. Cette approche permet de réutiliser les modules existants sans réécriture massive, au prix de quelques limitations (toutes les ressources AWS ne sont pas supportées).

provider "aws" {
  access_key                  = var.osc_access_key_id
  secret_key                  = var.osc_secret_key_id
  region                      = "eu-west-2"
  skip_credentials_validation = true
  skip_region_validation      = true
  skip_requesting_account_id  = true

  endpoints {
    ec2 = "https://fcu.eu-west-2.outscale.com"
    elb = "https://lbu.eu-west-2.outscale.com"
    iam = "https://eim.eu-west-2.outscale.com"
    s3  = "https://oos.eu-west-2.outscale.com"
  }
}

Cette double approche est traitée plus en détail dans le Volet 3 de la formation (Industrialiser avec l’IaC).

Limites de la compatibilité AWS

La compatibilité AWS n’est pas complète — il faut connaître ses limites pour ne pas être surpris.

Tous les appels AWS ne sont pas couverts

Les APIs FCU, LBU, EIM, OOS d’OUTSCALE couvrent une partie des appels AWS correspondants — généralement les plus utilisés en pratique. Mais certaines fonctionnalités AWS récentes ou de niche ne sont pas exposées dans les API compatibles. Si votre code AWS utilise un appel non couvert, il faudra l’adapter ou passer à l’OAPI native pour cette partie.

Les services Outscale-spécifiques ne sont pas accessibles via AWS

Les services qui n’ont pas d’équivalent AWS (FlexibleGpu, VmGroup, VmTemplate, ApiAccessPolicy, CarbonFootprint, OKS, etc.) sont uniquement accessibles via l’OAPI native ou les CLI dédiées (osc-cli, oks-cli). Un projet qui utilise massivement ces services tirera plus de valeur à passer à l’OAPI.

Certaines sémantiques diffèrent

Quelques différences subtiles existent dans le comportement des appels compatibles :

Les noms de ressources dans la réponse JSON peuvent légèrement différer (InstanceId vs VmId selon le contexte).
Les codes d’erreur sont mappés au plus proche mais peuvent ne pas couvrir tous les cas AWS.
Les quotas sont gérés indépendamment côté OUTSCALE — un quota AWS n’a pas d’équivalent direct.

S3 et OOS — compatibilité solide mais à tester

OOS expose une compatibilité S3 large qui couvre les opérations courantes (CRUD bucket et objet, ACL, lifecycle, versioning). Quelques fonctionnalités très récentes ou très spécifiques d’AWS (S3 Object Lambda, S3 Outposts, certaines politiques avancées) peuvent ne pas être disponibles. Toujours tester votre stack S3 sur OOS avant de migrer en production.

Le bénéfice de transférabilité

La compatibilité API AWS d’OUTSCALE crée une transférabilité forte des compétences et des outils, dans les deux sens :

Un développeur AWS qui découvre OUTSCALE retrouve la grammaire EC2/S3/IAM/ELB et peut être productif rapidement.
Un développeur OUTSCALE qui doit intervenir sur AWS retrouve les mêmes concepts (avec des noms différents) et peut transposer ses réflexes.

Cette transférabilité limite le lock-in sur l’un ou l’autre fournisseur : un projet bâti avec une discipline d’IaC sur OUTSCALE peut, moyennant adaptation, être déplacé vers AWS, et inversement. C’est un argument de réversibilité souvent évoqué pour la souveraineté technique.

Quand choisir OAPI vs API AWS-compatible ?

Le choix dépend du contexte de l’équipe et du projet.

Contexte	Approche recommandée
Nouveau projet, équipe sans bagage AWS	OAPI native — meilleure couverture, plus pérenne
Nouveau projet, équipe avec bagage AWS fort	OAPI native — la transférabilité reste là grâce au vocabulaire commun
Migration AWS → OUTSCALE avec base de code existante	API AWS-compatible d’abord, OAPI ensuite pour les services spécifiques
Outils tiers conçus pour AWS (Prowler, ScoutSuite, certains modules Terraform)	API AWS-compatible quand l’outil le supporte
Usage de FlexibleGpu, OKS, VmGroup, CarbonFootprint	OAPI native obligatoire

En pratique, beaucoup de projets utilisent les deux : OAPI pour les services Outscale-spécifiques et la couverture maximale, API AWS-compatible pour réutiliser des outils ou des compétences déjà en place. Les deux peuvent coexister sans difficulté.

À retenir

TINA OS est l’orchestrateur cloud d’OUTSCALE, développé en France à partir de briques open source depuis 2010, fonctionnant sur Cisco UCS sous KVM.
Au-dessus de TINA OS, OUTSCALE expose deux jeux d’API : OAPI native (couverture complète) et API AWS-compatibles (FCU, LBU, EIM, OOS).
La compatibilité AWS permet d’utiliser aws-cli, les SDK AWS et Terraform (provider aws) en pointant sur les endpoints OUTSCALE.
Tous les appels AWS ne sont pas couverts, et les services Outscale-spécifiques (FlexibleGpu, OKS, VmGroup) ne sont accessibles que via l’OAPI native.
La transférabilité des compétences entre AWS et OUTSCALE est un atout pour les équipes, mais ne se confond pas avec une portabilité parfaite des charges.
Recommandation : OAPI native pour un nouveau projet, API AWS-compatible pour une migration avec base de code AWS existante.

Prochaines étapes

Vocabulaire OUTSCALE ↔ AWS La table de correspondance complète à garder sous la main.

Régions et sous-régions OUTSCALE Endpoints par région européenne et stratégie multi-AZ.

La CLI oapi Pilote OUTSCALE en ligne de commande via l'OAPI native.

Découverte du Cockpit OUTSCALE L'interface graphique pour les premiers pas.