Cours Oracle Cloud Infrastructure (OCI) — tenancy, compartiments, IAM, Compute, Object Storage, VCN, facturation et OCI CLI en lecture

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. définir tenancy, compartiment, région d'origine (home region) et OCID ;
2. écrire et lire une politique IAM simple et appliquer le moindre privilège ;
3. situer une instance Compute, un bucket Object Storage et un VCN par rapport aux compartiments ;
4. décrire les composants d'un VCN (sous-réseaux, passerelles, tables de routage, règles de sécurité) ;
5. expliquer budgets et alertes, et leur limite (ils n'arrêtent pas la dépense) ;
6. lire l'état d'un environnement avec l'OCI CLI sans rien modifier ;
7. protéger la clé de signature d'API et le fichier de configuration.

Prérequis

• Notions de machine virtuelle, de stockage objet et de réseau IP (CIDR, sous-réseau, pare-feu).
• Lire une commande dans Terminal (cours Terminal macOS).
• Aucun compte Oracle Cloud n'est requis pour lire ce cours. Pour pratiquer : un compartiment de test, un budget d'alerte posé avant toute création, des ressources supprimées en fin d'exercice.

Parcours et chapitres

1. Tenancy et compartiments

D'après la présentation d'IAM : la tenancy est le compartiment racine qui contient toutes les ressources de l'organisation ; Oracle la crée à l'inscription. Les compartiments sont des regroupements logiques (pas des conteneurs physiques) pour organiser, isoler et contrôler l'accès aux ressources, et pour mesurer l'usage et la facturation. Ils peuvent être imbriqués. Bonne pratique citée : un compartiment par grande unité d'organisation. Les ressources d'un compartiment peuvent appartenir à des topologies réseau différentes (instances d'un compartiment placées dans un VCN partagé).

Les ressources IAM sont globales mais se gèrent depuis la région d'origine (home region) : les modifications y sont faites puis propagées aux autres régions. Presque toutes les ressources ont un OCID (identifiant unique attribué par Oracle).

2. IAM et politiques

La documentation décrit : utilisateurs, groupes, groupes dynamiques (ressources, par exemple des instances, qui correspondent à des règles), domaines d'identité (conteneurs d'utilisateurs, de fédération, d'authentification multifacteur et de SSO), fédération et région d'origine. Les politiques sont des documents précisant qui accède à quelles ressources, accordés au niveau d'un groupe et d'un compartiment ; une politique posée au niveau de la tenancy s'applique en cascade à tous les compartiments. Un court délai précède l'entrée en vigueur d'une politique.

Syntaxe de base lue dans la page :

Allow group <nom-du-groupe> to <verbe> <type-de-ressource> in compartment <nom-du-compartiment>

Verbes cités : inspect, use, manage (du plus faible au plus fort, ordre à confirmer dans la page des verbes). L'exemple de la documentation accorde à un groupe d'utilisateurs seulement use sur les instances et volumes de son compartiment, et laisse la gestion du réseau à un groupe d'administrateurs réseau : c'est le moindre privilège.

3. Compute

La page « Compute » décrit des instances de deux types : machines physiques (bare metal) et machines virtuelles. Les formes (shapes) déterminent processeurs et mémoire (standard, DenseIO, GPU, HPC, flexibles), les images définissent le système (images de plate-forme, de la place de marché, personnalisées). Le volume de démarrage est le disque système ; d'après la page, les changements sur les disques locaux sont perdus à la terminaison de l'instance, ceux des volumes attachés sont conservés. Les instances sont placées dans des domaines de disponibilité. En capacité à la demande, la page indique une facturation à la seconde pour une instance en fonctionnement, et que la facturation s'arrête à l'arrêt « selon la forme » : la règle exacte pour chaque forme, le sort du volume de démarrage et du stockage associé après arrêt ou terminaison sont non vérifiés.

4. Object Storage

D'après la page « Object Storage » : le namespace est le conteneur de plus haut niveau, unique et immuable pour un locataire ; les buckets sont des conteneurs logiques rattachés à un compartiment et créés dans une région (noms uniques dans le namespace) ; les objets (jusqu'à 10 Tio) comportent données et métadonnées. Le niveau par défaut est Standard (d'autres existent). L'accès est contrôlé par les politiques IAM et peut être restreint par adresse ; l'accès privé depuis un VCN passe par une passerelle de service. Les requêtes pré-authentifiées (PAR) donnent un accès sans identifiants IAM.

5. Réseau : VCN

D'après la présentation du réseau : un VCN est un réseau virtuel privé dans une région, avec un ou plusieurs blocs CIDR (de /16 à /30 ; plages RFC 1918 recommandées). Un VCN contient des sous-réseaux (recommandés régionaux ; ou propres à un domaine de disponibilité), publics ou privés. Tous les VNIC d'un sous-réseau partagent la table de routage, les listes de sécurité et les options DHCP. Oracle réserve les deux premières et la dernière adresse de chaque sous-réseau.

Pour qu'un sous-réseau soit joignable depuis internet, il faut à la fois : une passerelle internet activée, un sous-réseau public, une règle de routage vers cette passerelle, une règle de liste de sécurité (ou de groupe de sécurité réseau) qui l'autorise, et une adresse IP publique sur l'instance. Autres composants : passerelle NAT (sortie sans IP publique), passerelle de service (services Oracle), DRG, appairages (LPG, RPC). Règles de sécurité : listes de sécurité (par sous-réseau) ou groupes de sécurité réseau (par ressources).

6. Facturation, budgets et niveaux gratuits

Budgets. D'après la page « Budgets » : un budget est une limite souple ; il suit le coût et alerte, mais n'arrête ni ne limite la dépense. Il s'applique à un compartiment (y compris la racine) ou à des étiquettes (tags). Les règles d'alerte sont évaluées toutes les 24 heures, sur un pourcentage du budget ou un montant, avec notification par e-mail. Budgets mensuels récurrents (défaut) ou non récurrents (jusqu'à un an). Il faut des politiques usage-budgets pour les gérer.

Niveaux gratuits (état consulté le 2026-10-17, à ne pas promettre) : la page « Always Free resources » cite, par exemple, deux instances AMD VM.Standard.E2.1.Micro, des ressources Ampere A1 (équivalent de 2 OCPU et 12 Go), 200 Go de stockage bloc partagé, 20 Go de stockage objet, un nombre limité de VCN, à créer dans la région d'origine, avec une règle de récupération des instances inactives après sept jours sous des seuils d'utilisation, et un avertissement : si l'essai gratuit expire avec plus de 20 Go stockés, les objets peuvent être supprimés. Montant et durée de l'essai gratuit : non établis par la page lue. Tout ceci est à relire avant usage.

7. OCI CLI en lecture

La page de la CLI indique : outil en ligne de commande (oci --help), construit sur le SDK Python, disponible sur Mac, Windows et Linux, préinstallé dans Cloud Shell. La configuration standard est ~/.oci/config, qui repose sur une clé de signature d'API (paire de clés, la clé privée restant secrète), son empreinte et l'OCID de la tenancy ; l'utilisateur doit appartenir à un groupe disposant des politiques voulues. Une authentification par jeton existe (non lue : non vérifié).

oci --versionoci iam compartment list --compartment-id <OCID-TENANCY>oci iam policy list --compartment-id <OCID-COMPARTIMENT>

• Contexte : OCI CLI déjà installée et configurée par Stéphane sur un compte de test (installation non traitée ici ; oci setup config écrit un fichier de configuration et une clé sur le poste).
• Droits : inspect/read sur les compartiments et politiques concernés.
• Effet : affiche la version, les compartiments et les politiques.
• Vérification : les compartiments correspondent à la structure attendue ; repérer les politiques posées à la racine.
• Retour arrière : sans objet (lecture). La sortie contient des OCID : ne pas la copier dans un dépôt ni un prompt.

oci compute instance list --compartment-id <OCID-COMPARTIMENT>oci network vcn list --compartment-id <OCID-COMPARTIMENT>oci network subnet list --compartment-id <OCID-COMPARTIMENT>oci os ns getoci os bucket list --compartment-id <OCID-COMPARTIMENT>

• Contexte : compartiment de test dans la région configurée.
• Droits : lecture des instances, du réseau et des buckets.
• Effet : inventaire des instances, VCN, sous-réseaux, namespace et buckets.
• Vérification : toute ressource inconnue est à investiguer (coût possible).
• Retour arrière : sans objet.

8. Terminer une ressource de test (à effet et coût)

Pour créer une instance, passer par la console (choix de forme, d'image, de réseau) pour comprendre chaque paramètre ; la commande de création, longue, n'est pas reproduite ici. La suppression :

Attention, effet notable. Termine l'instance : disque local perdu, facturation à vérifier. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

oci compute instance terminate --instance-id <OCID-INSTANCE>

• Contexte : instance de test dans un compartiment de test.
• Droits : droit de gérer les instances du compartiment.
• Effet : termine l'instance ; d'après la page Compute, les changements des disques locaux sont perdus. Le sort du volume de démarrage (conservation ou suppression selon l'option choisie) est non vérifié : lire l'aide oci compute instance terminate --help avant.
• Vérification : oci compute instance list montre l'état « terminée » puis l'instance disparaît ; contrôler les volumes restants et la facturation.
• Retour arrière : aucun pour les données non sauvegardées.

Exercices et vérifications de fin de cours

Tous sont sur papier ou en lecture seule.

1. Compartiments. Placer sur le schéma : un VCN partagé, deux projets, un bucket de sauvegarde et trois politiques.
2. Politique. Écrire une politique de lecture seule pour un groupe sur un compartiment ; expliquer ce qui change si elle est posée à la racine.
3. Réseau. Lister les cinq conditions pour qu'une instance soit joignable depuis internet, puis proposer une architecture sans IP publique.
4. Budget. Définir un budget de test et ses seuils d'alerte, et lister ce qu'il n'empêche pas.
5. Secrets. Écrire la liste des précautions pour la clé de signature d'API et le fichier de configuration.
6. Nettoyage. Écrire la liste de fin d'exercice : instances, volumes, buckets, requêtes pré-authentifiées, clés d'API révoquées, budget conservé.

Critères de réussite

• Expliquer le rôle du compartiment pour les droits, les coûts et l'isolation.
• Lire une politique et dire ce qu'elle autorise.
• Rappeler qu'un budget n'arrête pas la dépense.
• Protéger les clés d'API et les liens d'accès.
• Dire ce qui n'est pas vérifié.