IaaS, PaaS, serverless et la responsabilité partagée

Pourquoi

L'équipe de Signalements a son projet Scaleway, sa CLI configurée, et une question très concrète : sur quoi faire tourner l'application ? Le catalogue de Scaleway propose, rien que pour exécuter du code, des instances (machines virtuelles), des serveurs physiques Elastic Metal, des conteneurs serverless, des fonctions serverless et un Kubernetes managé. Pour la base de données, on peut installer PostgreSQL soi-même sur une instance, ou louer une base managée.

Le choix ne se fait pas sur le prix affiché, ni sur la mode. Il se fait sur une question que l'on oublie souvent de poser : qu'est-ce qui reste à notre charge ? Qui applique le correctif de sécurité du noyau Linux la nuit où une faille critique est publiée ? Qui vérifie que les sauvegardes de la base fonctionnent ? Qui redémarre l'application quand le serveur physique qui l'héberge tombe ? Selon le modèle choisi, la réponse est « nous » ou « le fournisseur », et une équipe qui se trompe de réponse découvre son erreur pendant un incident.

Les équipes se trompent dans les deux sens. Certaines choisissent des machines virtuelles « parce qu'on maîtrise », puis ne les mettent jamais à jour : elles ont pris la responsabilité du système d'exploitation sans en assumer le travail. D'autres choisissent un service managé en croyant que le fournisseur « s'occupe de tout », et laissent leur base ouverte à tout Internet parce que c'est la configuration par défaut. Cette leçon vous donne la grille pour ne faire ni l'un ni l'autre.

Les concepts

La pile des responsabilités

Pour faire tourner une application, il faut empiler des couches. Chacune doit être achetée, installée, surveillée, mise à jour et réparée par quelqu'un :

  Données et identités des utilisateurs
  Application (votre code)
  Environnement d'exécution (Python, dépendances)
  Système d'exploitation
  Virtualisation (hyperviseur)
  Serveurs physiques, stockage, réseau
  Centre de données (bâtiment, énergie, refroidissement, accès physique)

Dans votre propre salle serveur, vous gérez tout. Les modèles de service du cloud sont autant de façons de tracer une ligne dans cette pile : sous la ligne, le fournisseur ; au-dessus, vous.

IaaS, PaaS, SaaS : la définition du NIST

La définition du NIST, vue à la leçon 1, décrit trois modèles. Reformulés :

• IaaS : le fournisseur vous donne du calcul, du stockage et du réseau, sur lesquels vous déployez n'importe quel logiciel, système d'exploitation compris. Vous ne gérez pas l'infrastructure physique, mais vous gérez le système, le stockage que vous attachez, les applications, et une partie du réseau (par exemple un pare-feu). Chez Scaleway : les Instances. Ailleurs : Amazon EC2, Azure Virtual Machines, Google Compute Engine, les instances Public Cloud d'OVHcloud.
• PaaS : vous déployez votre application, écrite avec les langages, bibliothèques et outils que la plateforme prend en charge. Vous ne gérez ni les serveurs, ni le système, ni le stockage sous-jacent ; vous contrôlez l'application et la configuration de son environnement d'hébergement.
• SaaS : vous utilisez une application du fournisseur, par un navigateur ou une API. Vous ne gérez rien de l'infrastructure, au mieux quelques réglages propres à votre compte. Une messagerie en ligne, une forge Git hébergée ou une suite bureautique en ligne sont des SaaS.

Les variantes apparues depuis

La définition date de 2011. Depuis, les offres se sont multipliées entre l'IaaS et le PaaS, et le vocabulaire a suivi :

• Le CaaS (Containers as a Service) fournit de quoi exécuter des conteneurs, le plus souvent un Kubernetes managé : le fournisseur gère le plan de contrôle du cluster, vous gérez ce qui tourne dessus. Chez Scaleway : Kubernetes Kapsule. Ailleurs : Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine, OVHcloud Managed Kubernetes Service.
• Les services managés (base de données, cache, file de messages) sont des PaaS spécialisés : vous louez un PostgreSQL qui fonctionne, sans gérer la machine qui le porte. Une base de données managée est le cas le plus courant. Chez Scaleway : Managed Database for PostgreSQL and MySQL. Ailleurs : Amazon RDS, Azure Database for PostgreSQL, Google Cloud SQL, OVHcloud Public Cloud Databases.
• Le serverless (« sans serveur ») pousse le PaaS au bout de sa logique. Le livre blanc du groupe de travail Serverless de la CNCF (2018) le décrit comme la construction et l'exécution d'applications sans gestion de serveur, facturées à l'exécution, et capables de descendre à zéro quand rien ne les sollicite. Il y a évidemment des serveurs : vous ne les voyez simplement plus, ni ne les payez quand ils ne servent pas. Deux formes :
  • le FaaS (Functions as a Service) exécute une fonction en réponse à un événement (requête HTTP, message, horaire). Chez Scaleway : Serverless Functions. Ailleurs : AWS Lambda, Azure Functions, Google Cloud Run functions ;
  • les conteneurs serverless exécutent une image de conteneur qui répond à des requêtes HTTP, avec la même mise à l'échelle automatique jusqu'à zéro. Chez Scaleway : Serverless Containers. Ailleurs : Google Cloud Run, Azure Container Apps.

On peut ranger tout cela sur la pile :

Lisez ce tableau par sa première ligne : quel que soit le modèle, vos données, les identités qui y accèdent et la façon dont vous configurez le service restent votre affaire. Aucun fournisseur ne vous en décharge, même en SaaS.

Le modèle de responsabilité partagée

Tous les grands fournisseurs publient un modèle de responsabilité partagée (shared responsibility model). AWS l'a popularisé avec une formule devenue classique : le fournisseur est responsable de la sécurité du cloud (security of the cloud), le client de la sécurité dans le cloud (security in the cloud). Scaleway reprend la même distinction. Microsoft publie la version la plus détaillée, sous forme de matrice, et en tire une liste de responsabilités que le client conserve toujours, quel que soit le modèle :

• les données : leur classification, leur protection, les choix de chiffrement, le respect des règles qui s'y appliquent ;
• les postes qui accèdent aux services ;
• les comptes : créer, gérer et retirer les accès des utilisateurs ;
• la gestion des accès : rôles, authentification à facteurs multiples, règles d'accès.

Pour un service donné, la documentation du fournisseur précise la ligne. Deux exemples chez Scaleway :

• Pour les Instances, la documentation est explicite : le système d'exploitation, ses mises à jour, les sauvegardes et instantanés, les règles de pare-feu et groupes de sécurité, le chiffrement des volumes et les clés SSH sont à votre charge. Elle précise même qu'une fois la machine livrée, Scaleway n'y a pas accès et n'a donc aucun moyen d'en surveiller le fonctionnement.
• Pour Kapsule, Scaleway gère le plan de contrôle du cluster (etcd, serveur d'API, ordonnanceur, contrôleurs), les images des nœuds et le cycle de vie des groupes de nœuds managés, ainsi que les correctifs de ces composants. Vous gérez les objets Kubernetes, le RBAC, la taille et le type des groupes de nœuds, le moment où les mises à jour des nœuds sont déclenchées, la confiance dans les images que vous déployez, et les sauvegardes des données de vos applications.

Trois façons de faire tourner Signalements

Comparons concrètement trois options pour l'API Signalements, toutes disponibles chez Scaleway.

    flowchart TB
  subgraph A["1. Instances + Docker (IaaS)"]
    a1["Vous : système, Docker,<br/>mises à jour, redémarrages,<br/>répartition de charge"]
  end
  subgraph B["2. Serverless Containers"]
    b1["Vous : l'image, sa configuration.<br/>Scaleway : exécution, mise à l'échelle,<br/>point d'accès HTTPS"]
  end
  subgraph C["3. Kapsule (CaaS)"]
    c1["Vous : manifestes, nœuds,<br/>montées de version, outillage.<br/>Scaleway : plan de contrôle"]
  end
  

Aucune option ne gagne sur toutes les lignes. Pour une petite équipe sans compétence Kubernetes, une API sans état à trafic irrégulier est un très bon candidat au serverless. Pour une équipe qui exploite déjà dix applications sur Kubernetes, comme Lyneko sur son cluster Kapsule, ajouter une onzième application au cluster coûte presque rien. L'IaaS reste le choix par défaut quand l'application a des besoins particuliers (logiciel qui exige une machine entière, accès au système, licence liée à la machine).

Le choix retenu pour ce cours

Pour ce cours, Signalements tournera sur deux instances, avec une base PostgreSQL managée. Ce n'est pas forcément ce que vous choisiriez en production pour cette application : c'est le choix qui fait voir le plus de briques. Avec des instances, vous manipulerez les images, les volumes, les réseaux privés, les groupes de sécurité et le répartiteur de charge, que les modèles plus élevés cachent mais utilisent tous en dessous. Kubernetes a ses propres cours (Kubernetes : les fondamentaux, Kapsule : Kubernetes managé chez Scaleway).

Pour la base de données, en revanche, nous montons d'un cran et prenons un service managé. Exploiter soi-même un PostgreSQL de production (réplication, sauvegardes avec archivage des journaux, restauration testée, montées de version) est un métier, que le cours PostgreSQL pour les ingénieurs d'infrastructure traite à part. C'est l'arbitrage le plus fréquent dans les petites équipes : on garde la main sur le code et son exécution, on délègue l'état.

En pratique

Nous allons créer la base de données sig-db, la protéger, puis, à titre de comparaison, faire tourner Signalements quelques minutes sur Serverless Containers. Les ressources de cette leçon sont payantes tant qu'elles existent : la base coûte quelques centimes de l'heure dans sa plus petite taille. Le conteneur serverless est supprimé en fin de leçon ; la base, elle, sert jusqu'à la fin du cours. Si vous faites une longue pause, la leçon 8 montre comment tout supprimer et repartir.

Toutes les commandes s'exécutent dans le projet signalements, défini par défaut à la leçon 1. Vérifiez-le avec scw config info.

Explorer l'offre

Avant de créer une base, regardez ce qui existe dans la région :

$ scw rdb engine list
$ scw rdb node-type list

La première commande liste les moteurs disponibles et leurs versions ; le nom d'un moteur s'écrit sous la forme PostgreSQL-17. La seconde liste les types de nœuds (processeurs, mémoire, disponibilité). Choisissez la version de PostgreSQL la plus récente proposée, et le plus petit type de nœud : la CLI 2.62 utilise DB-DEV-S par défaut, une taille de développement suffisante pour le cours. La gamme évolue : si ce type n'apparaît plus dans la liste, prenez le plus petit affiché.

Créer la base sans exposer le mot de passe

La création demande un nom d'utilisateur et un mot de passe. Taper le mot de passe en argument (password=...) l'inscrirait dans l'historique du shell. La CLI propose mieux : l'argument generate-password, activé par défaut, génère un mot de passe de 21 caractères qui respecte les règles de complexité exigées par l'API (au moins une majuscule, une minuscule, un chiffre et un caractère spécial).

$ scw rdb instance create \
    name=sig-db \
    engine=PostgreSQL-17 \
    node-type=DB-DEV-S \
    user-name=signalements \
    high-availability-mode=disabled \
    tags.0=formation \
    --wait

• name=sig-db : le nom, qui servira à retrouver la base.
• engine=PostgreSQL-17 : le moteur et sa version majeure, tel qu'affiché par scw rdb engine list.
• user-name=signalements : le premier utilisateur, créé avec la base. Scaleway crée aussi une base de données nommée rdb.
• high-availability-mode=disabled : un seul nœud. Les autres valeurs, single_zone et multiple_zone, ajoutent un nœud de secours répliqué de façon synchrone, dans la même zone ou dans une autre ; elles doublent le prix, et la leçon 3 en discute. Une base peut passer en haute disponibilité après sa création, mais pas l'inverse.
• tags.0=formation : une étiquette, utile pour retrouver et nettoyer les ressources du cours. La syntaxe nom.index=valeur est celle de la CLI pour les listes.
• --wait : la CLI attend que la base soit prête (statut ready), ce qui prend plusieurs minutes. Sans cette option, la commande rend la main immédiatement, base encore en provisioning.

Le mot de passe généré s'affiche dans le terminal, une ligne Your generated password is ... au début, puis une section Password à la fin de la description de la base. C'est le seul moment où vous le verrez : copiez-le dans votre gestionnaire de mots de passe, puis effacez l'écran. Ne lancez pas cette commande dans un terminal enregistré ou partagé.

Récupérez ensuite l'identifiant de la base, dont toutes les commandes suivantes ont besoin :

$ SIG_DB_ID=$(scw rdb instance list name=sig-db -o json | jq -r '.[0].id')
$ scw rdb instance get "$SIG_DB_ID"

scw rdb instance get décrit la base : statut, moteur, type de nœud, volume, planification des sauvegardes, et points d'accès (endpoints). Notez celui qui est présent.

Ce que la base managée a fait, et ce qu'elle n'a pas fait

Lisez la description de la base avec la grille de responsabilité en tête :

• Les sauvegardes sont déjà planifiées. Les sauvegardes automatiques sont activées par défaut à la création, une par jour, conservées sept jours. La section BackupSchedule le montre. La fréquence (en heures) et la rétention (en jours) se modifient avec scw rdb instance update (backup-schedule-frequency, backup-schedule-retention). Il vous reste à décider si sept jours suffisent, et surtout à tester une restauration (cours Sauvegarde, restauration et PRA).
• Le système et le moteur sont gérés. Scaleway exploite l'image qui porte PostgreSQL, applique les correctifs du système et planifie des opérations de maintenance, visibles dans le champ maintenances de la base. La montée de version majeure de PostgreSQL reste une décision que vous prenez.
• Un point d'accès public a été créé. L'API de Scaleway le précise dans la description du paramètre init_endpoints : un point d'accès public, de type répartiteur de charge, est systématiquement créé avec la base. Elle a donc une adresse IP publique et un port.
• Elle accepte les connexions de partout. La documentation de Scaleway l'indique : la configuration initiale d'une base autorise l'accès réseau depuis n'importe où, avec une règle 0.0.0.0/0 dans sa liste de contrôle d'accès (ACL). Seuls le mot de passe et le chiffrement TLS la protègent.

Vérifiez ce dernier point :

$ scw rdb acl list instance-id="$SIG_DB_ID"

La liste contient une règle 0.0.0.0/0. C'est exactement le cas de l'encadré précédent : un service managé, exploité correctement par le fournisseur, et configuré par défaut d'une façon que vous ne voulez pas.

Restreindre l'accès réseau

En attendant de rattacher la base à un réseau privé et de supprimer son point d'accès public (leçon 6), remplacez la règle ouverte par votre seule adresse IP publique :

$ MON_IP=$(curl -s https://ifconfig.me)
$ echo "$MON_IP"
$ scw rdb acl set "$MON_IP/32" instance-id="$SIG_DB_ID" --wait
$ scw rdb acl list instance-id="$SIG_DB_ID"

• curl -s https://ifconfig.me interroge un service public qui renvoie l'adresse IP sous laquelle vous apparaissez sur Internet (celle de votre box ou du proxy de votre entreprise). Vérifiez qu'elle est plausible avant de l'utiliser.
• scw rdb acl set remplace toutes les règles par celles données (acl add en ajouterait une sans retirer les autres). Le suffixe /32 désigne une adresse unique.

Si vous avez psql installé, connectez-vous pour vérifier que la base répond :

$ scw rdb instance connect "$SIG_DB_ID" username=signalements

La CLI lance psql avec les paramètres du point d'accès, sur la base rdb par défaut, et vous demande le mot de passe. Elle suggère au passage d'utiliser un fichier ~/.pgpass pour éviter de le saisir. Quittez avec \q.

Essayer Serverless Containers

Faisons maintenant tourner l'image de Signalements sans aucune machine, pour voir de près ce que le serverless apporte et ce qu'il exige. Les conteneurs se rangent dans un espace de noms (namespace), qui regroupe des conteneurs et leurs variables d'environnement communes :

$ NS_ID=$(scw container namespace create name=sig-essai --wait -o json | jq -r .id)

Créez ensuite le conteneur. Nous ne lui donnons pas la base de données : Signalements fonctionne aussi sans DATABASE_URL, en gardant les signalements en mémoire, ce qui va servir la démonstration.

$ CT_ID=$(scw container container create \
    namespace-id="$NS_ID" \
    name=signalements \
    image=ghcr.io/lyneko-formation/signalements:1.2.0 \
    port=8000 \
    min-scale=0 \
    max-scale=2 \
    environment-variables.APP_VERSION=1.2.0 \
    --wait -o json | jq -r .id)

• image : la référence complète de l'image. Serverless Containers accepte le registre de conteneurs de Scaleway et les registres publics externes (Docker Hub, GitHub Container Registry), mais pas les registres externes privés. La documentation de Scaleway déconseille d'ailleurs les registres externes en production, à cause de leurs limites de débit, qui peuvent faire échouer un démarrage.
• port=8000 : le port sur lequel l'application écoute dans le conteneur. La valeur par défaut est 8080 ; Signalements écoute sur 8000, l'oublier donne un conteneur qui ne démarre jamais correctement.
• min-scale=0 et max-scale=2 : entre zéro et deux exemplaires du conteneur, selon le trafic. Avec zéro, plus rien ne tourne (ni ne se paie) quand personne n'appelle l'application.
• environment-variables.APP_VERSION=1.2.0 : une variable d'environnement. Les valeurs sensibles, comme une DATABASE_URL avec son mot de passe, se passent par secret-environment-variables.<NOM>, qui ne les réaffiche pas.
• --wait : attend la fin du déploiement. Avec la CLI 2.62 (API Serverless Containers v1), la création déploie le conteneur : il n'y a pas de commande de déploiement séparée, seulement redeploy pour forcer un nouveau déploiement.

Récupérez l'adresse publique attribuée et appelez l'application :

$ URL=$(scw container container get "$CT_ID" -o json | jq -r .public_endpoint)
$ echo "$URL"
$ curl -s "$URL/"
$ curl -s "$URL/sante"

Le champ public_endpoint est, selon le schéma de l'API, l'URL publique du conteneur, sur un nom de domaine généré par Scaleway et servi en HTTPS avec un certificat déjà en place (si echo n'affiche qu'un nom de domaine, sans https://, ajoutez le préfixe dans les commandes curl). Vous n'avez rien eu à faire pour le TLS, ni pour la répartition de charge, ni pour le système : c'est la promesse du serverless.

Par défaut, un conteneur est public (privacy=public) : n'importe qui connaissant l'adresse peut l'appeler. Un conteneur privacy=private exige une authentification, et répond 403 sans elle.

Ce que le serverless exige de l'application

Créez un signalement, puis listez-les plusieurs fois :

$ curl -s -X POST "$URL/signalements" \
    -H 'Content-Type: application/json' \
    -d '{"lieu": "Rue des Lilas", "description": "Lampadaire éteint"}'
$ for i in 1 2 3 4 5; do curl -s "$URL/signalements"; echo; done

Selon le nombre d'exemplaires du conteneur en service au moment de vos appels, et le nombre de processus de l'application dans chacun, vous pouvez voir le signalement dans certaines réponses et pas dans d'autres : chaque exemplaire garde sa propre liste en mémoire. Laissez ensuite l'application sans trafic un moment. Quand la plateforme l'a ramenée à zéro exemplaire, le premier appel suivant est plus lent (le démarrage à froid, cold start : télécharger l'image, démarrer le conteneur, attendre qu'il écoute), et la liste est vide. Les données ont disparu avec l'exemplaire qui les portait.

La documentation de Serverless Containers le dit sans détour : un conteneur ne conserve pas d'état entre deux exécutions, et les données persistantes vont dans un stockage objet ou une base de données. Le serverless n'est pas seulement une façon d'héberger : c'est un contrat avec l'application. Elle doit être sans état, démarrer vite, et tout ce qui doit survivre doit vivre ailleurs. Signalements le respecte dès qu'on lui donne une DATABASE_URL. La base sig-db serait alors la bonne destination, à une difficulté près, qui est un excellent exercice (exercice 3).

Nettoyer

Supprimez le conteneur et son espace de noms, qui ne servent plus :

$ scw container container delete "$CT_ID"
$ scw container namespace delete "$NS_ID"

Gardez sig-db : elle sert jusqu'à la fin du cours.

Sous le capot

Ce que « managé » recouvre pour PostgreSQL

Une base managée est, sous le capot, une ou plusieurs machines virtuelles que vous ne voyez pas, avec une image système et une configuration de PostgreSQL préparées par le fournisseur, et un agent qui les pilote. Ce que l'API vous expose (créer, redimensionner, sauvegarder, restaurer, ajouter un réplica) correspond à des procédures que l'agent exécute pour vous. Le schéma de l'API Managed Database montre les états qu'il traverse : provisioning, initializing, configuring, ready, mais aussi backuping, snapshotting, restarting, autohealing (réparation automatique), disk_full, locked. Chacun correspond à une opération qu'un administrateur de bases ferait à la main.

La haute disponibilité illustre bien la valeur ajoutée. En mode single_zone ou multiple_zone, la base a un nœud principal et un nœud de secours, que Scaleway alimente par réplication synchrone : une écriture n'est confirmée à l'application que lorsqu'elle est arrivée sur les deux nœuds, ce qui évite de perdre des transactions lors d'une bascule. La FAQ de Scaleway décrit ce qui se passe quand le nœud principal tombe : la bascule est automatique, le nœud de secours accepte les écritures en 30 à 60 secondes selon le type de panne, et l'adresse IP virtuelle du point d'accès est redirigée vers lui ; l'application n'a pas à changer d'adresse, seulement à savoir se reconnecter. Un nouveau nœud de secours est ensuite reconstruit automatiquement. Monter cela soi-même demande un gestionnaire de bascule, une adresse flottante, des tests de bascule réguliers : des semaines de travail et d'astreinte.

En contrepartie, vous perdez l'accès au système. Pas de ssh sur la machine, pas de postgresql.conf modifiable directement : seuls les réglages que l'API expose (settings, init-settings) sont modifiables, seules les extensions que le fournisseur a installées sont disponibles. C'est l'arbitrage de tout PaaS.

Comment un conteneur serverless descend à zéro

Une plateforme de conteneurs serverless place un intermédiaire devant vos conteneurs : un frontal HTTP qui reçoit toutes les requêtes adressées à votre domaine. Il mesure la charge (nombre de requêtes simultanées, ou consommation de processeur ou de mémoire, selon la règle de mise à l'échelle choisie) et décide du nombre d'exemplaires nécessaires, entre min-scale et max-scale. Quand une requête arrive alors qu'aucun exemplaire ne tourne, le frontal la retient, demande le démarrage d'un exemplaire, attend qu'il écoute sur son port, puis lui transmet la requête : c'est le démarrage à froid. Scaleway propose deux environnements d'exécution isolés, sandbox=v1 et sandbox=v2 ; le second, par défaut, démarre plus vite mais n'accepte pas tous les appels système de Linux, ce qui peut gêner certaines applications de bas niveau.

D'où les règles pratiques : une image légère démarre plus vite (cours Construire des images de conteneurs) ; une application qui met trente secondes à initialiser ses caches n'est pas faite pour descendre à zéro ; min-scale=1 supprime les démarrages à froid, au prix d'un exemplaire payé en permanence.

Pièges courants

« C'est managé, donc c'est sécurisé. » Voir la règle 0.0.0.0/0 de la base. Lisez la configuration par défaut de chaque service managé que vous créez, et posez-vous la question de la responsabilité partagée : qu'est-ce que le fournisseur n'a pas fait ?

« C'est de l'IaaS, donc le fournisseur sauvegarde. » Non : pour une instance, la documentation de Scaleway place les sauvegardes et les instantanés de votre côté. Une instance dont le stockage local est perdu avec la machine physique ne se récupère pas sans sauvegarde préalable.

Une application avec état sur une plateforme sans état. Sessions en mémoire, fichiers téléversés écrits sur le disque local, file de tâches dans un processus : tout cela disparaît au prochain redémarrage ou à la prochaine mise à l'échelle. Le symptôme typique est intermittent (« parfois je suis déconnecté », « parfois l'image n'apparaît pas »), parce qu'il dépend de l'exemplaire qui répond.

Le mauvais port. Une erreur de déploiement de Serverless Containers sur une application qui fonctionne en local vient très souvent d'un port différent de celui déclaré (8080 par défaut), ou d'une application qui écoute sur 127.0.0.1 au lieu de 0.0.0.0 : la plateforme ne la voit jamais devenir prête.

Le mot de passe de la base dans l'historique. password=... en argument, ou une DATABASE_URL complète passée en environment-variables plutôt qu'en secret-environment-variables : le secret se retrouve dans l'historique, dans la sortie des commandes get, et dans les journaux de quiconque relit votre terminal.

Choisir le modèle sur le prix unitaire. Une instance coûte moins cher à l'heure qu'un service managé de même taille, mais elle demande des heures de travail humain par mois (mises à jour, surveillance, sauvegardes, incidents). Comparez des coûts complets, travail compris (leçon 8).

Sécurité

• La surface d'attaque se déplace avec la ligne de responsabilité. En IaaS, vous défendez le système : correctifs, durcissement, ports ouverts (cours Durcissement Linux). En PaaS et en serverless, le système n'est plus votre affaire, mais la configuration du service et les identités qui y accèdent le deviennent entièrement. Une base managée ne se fait pas pirater par une faille du noyau que vous auriez oublié de corriger ; elle se fait vider parce qu'elle était ouverte à Internet avec un mot de passe faible.
• Ne laissez jamais une base sur 0.0.0.0/0. Même avec un mot de passe robuste, une base exposée subit en permanence des tentatives de connexion automatisées, et la moindre faille du protocole ou du moteur devient exploitable par tout Internet. Restreignez l'ACL dès la création, puis supprimez le point d'accès public au profit d'un réseau privé (leçon 6).
• Chiffrez le transport. Les bases managées de Scaleway acceptent les connexions TLS ; scw rdb instance get-certificate fournit le certificat de l'autorité qui a signé celui de la base. Côté application, exigez TLS dans la chaîne de connexion (sslmode=require au minimum, sslmode=verify-full avec le certificat pour vérifier l'identité du serveur).
• Un conteneur serverless public est public. L'adresse générée n'est pas un secret : elle peut fuiter dans un journal, un message, un historique de navigateur. Une API interne doit être privacy=private, ou protégée par sa propre authentification.
• La confiance dans l'image vous revient, quel que soit le modèle. La plateforme exécute ce que vous lui donnez : une image vulnérable reste vulnérable sur Serverless Containers comme sur Kapsule. Épinglez l'image par son empreinte, analysez-la et signez-la (cours Construire des images de conteneurs).

En production

• Combinez les modèles. La plupart des architectures réelles mélangent : des conteneurs sur Kubernetes ou serverless pour le code, des bases et des caches managés pour l'état, un stockage objet pour les fichiers, et parfois un SaaS pour l'authentification ou l'envoi de courriels. Le choix se fait composant par composant.
• Le verrouillage vient surtout du haut de la pile. Une instance Linux se déplace facilement d'un fournisseur à l'autre ; une image de conteneur aussi. Ce qui verrouille, ce sont les services PaaS dont l'interface est propre au fournisseur : un système de fonctions avec ses déclencheurs, une base de données propriétaire, des files de messages spécifiques. Un PostgreSQL managé reste un PostgreSQL : on en sort par pg_dump. Préférez les services managés qui exposent un protocole standard (PostgreSQL, S3, Kubernetes, OCI) ; la leçon 8 traite la réversibilité.
• Quand redescendre vers l'IaaS. Les équipes reviennent parfois d'un PaaS vers des instances, ou d'un service managé vers une installation propre, pour trois raisons fréquentes : un besoin que la plateforme n'expose pas (une extension PostgreSQL absente, un réglage du noyau), un coût devenu disproportionné à grande échelle, ou une exigence de conformité que l'offre managée ne remplit pas. Ce sont des raisons légitimes ; « on maîtrise mieux » n'en est généralement pas une si l'équipe n'a pas le temps d'exploiter ce qu'elle reprend.
• Lisez la responsabilité partagée de chaque service avant de l'adopter, et consignez ce qui reste à votre charge dans la documentation d'exploitation de l'application : sauvegardes à tester, montées de version à planifier, ACL à revoir. C'est cette liste que l'on cherche pendant un incident.
• Chez Lyneko, les applications tournent sur Kapsule et leurs secrets vivent dans Scaleway Secret Manager : le plan de contrôle de Kubernetes et le stockage des secrets sont délégués, le cycle de vie des applications et leurs droits restent à l'équipe.

Exercices

1. Qui s'en occupe ? (niveau 100). Pour chaque tâche, dites qui en est responsable si Signalements tourne (a) sur des instances avec Docker et PostgreSQL installé sur une instance, (b) sur Serverless Containers avec une base managée : appliquer un correctif de sécurité du noyau Linux ; mettre à jour Flask vers une version corrigée ; sauvegarder la base ; tester la restauration de la base ; décider qui peut se connecter à la base ; remplacer un disque physique défaillant.

2. Lire une documentation de responsabilité (niveau 100). Ouvrez la page Kubernetes shared responsibility model de la documentation de Scaleway. Relevez trois responsabilités que Scaleway prend pour Kapsule et trois qui restent au client. Laquelle de ces dernières vous semble la plus souvent oubliée, et pourquoi ?

3. Brancher le conteneur serverless sur la base (niveau 200). Vous voulez que le conteneur serverless de la leçon utilise sig-db. Écrivez la commande de création du conteneur avec la variable DATABASE_URL (base rdb, utilisateur signalements, TLS exigé), sans que le mot de passe apparaisse dans l'historique du shell. Le conteneur démarre, mais /sante signale que la base est injoignable. Pourquoi ? Quelles sont les deux solutions, et laquelle choisiriez-vous ?

$ read -rs SIG_DB_MDP
$ IP=$(scw rdb instance get "$SIG_DB_ID" -o json | jq -r '.endpoints[0].ip')
$ PORT=$(scw rdb instance get "$SIG_DB_ID" -o json | jq -r '.endpoints[0].port')
$ scw container container create namespace-id="$NS_ID" name=signalements \
    image=ghcr.io/lyneko-formation/signalements:1.2.0 port=8000 \
    min-scale=0 max-scale=2 \
    "secret-environment-variables.DATABASE_URL=postgresql://signalements:${SIG_DB_MDP}@${IP}:${PORT}/rdb?sslmode=require" \
    --wait

4. Choisir un modèle (niveau 100). Pour chacun de ces besoins, proposez un modèle de service et justifiez en une phrase : (a) un traitement nocturne qui redimensionne les photos jointes aux signalements, cinq minutes par nuit ; (b) un logiciel métier fourni par un éditeur, qui exige Windows Server et une licence liée à la machine ; (c) la messagerie de l'équipe ; (d) une API à trafic stable et élevé, exploitée par une équipe qui fait déjà tourner vingt services sur Kubernetes.

Récapitulatif

• Les modèles de service tracent une ligne dans la pile : sous la ligne, le fournisseur ; au-dessus, vous. IaaS (vous gérez le système), CaaS (vous gérez ce qui tourne sur le cluster), PaaS et services managés (vous gérez l'application et la configuration), serverless (sans serveur visible, mise à zéro, facturation à l'exécution), SaaS (vous utilisez une application).
• Le modèle de responsabilité partagée : sécurité du cloud pour le fournisseur, sécurité dans le cloud pour vous. Les données, les identités, les accès et la configuration restent toujours à votre charge.
• Managé ne veut pas dire sûr : la base managée de Scaleway est créée avec un point d'accès public et une ACL 0.0.0.0/0. Restreignez immédiatement, puis passez par un réseau privé.
• La base managée prend en charge sauvegardes quotidiennes (sept jours par défaut), correctifs, haute disponibilité si vous la demandez ; elle vous retire l'accès au système.
• Le serverless est un contrat : application sans état, qui démarre vite, données ailleurs. Le prix à payer est le démarrage à froid.
• Pour ce cours : instances pour l'application (pour voir les briques), base managée pour l'état.

Pour aller plus loin

• La page Shared responsibility in the cloud de Microsoft Learn, pour sa matrice détaillée par modèle.
• Les pages de responsabilité partagée de chaque produit Scaleway que vous utilisez (Instances, Kapsule, bases managées, stockage) : elles sont courtes et précises.
• Le CNCF Serverless Whitepaper, pour les cas d'usage et les limites du serverless, présentés sans parti pris de fournisseur.
• La leçon suivante, qui répartit les instances de Signalements entre plusieurs zones, et discute la haute disponibilité de la base.