Docs

Workloads

Un workload est une application web que Dormeto met en veille. C'est un target group applicatif d'un équilibreur de charge, et les backends derrière lui. Les opérateurs l'intègrent depuis Discovery, puis le gèrent depuis sa page, sous Workloads.

23 min de lectureManager 0.21.0

shop-stagingweb-alb · eu-west-1en veille

• EC2à l’arrêt
• Auroraà l’arrêt

délai d’inactivité 15 minla prochaine requête le réveille

L'intégration

Dans Discovery, sélectionnez un candidat To onboard, puis Onboard…. Les opérateurs et les administrateurs peuvent le faire. Le compte a besoin du rôle de commande (Accès à l'organisation).

Ce que change l'intégration

• Le routeur du compte et de la région est d'abord installé, si besoin.
• Il tague les backends dormeto:workload : instances, groupes Auto Scaling, services ECS, bases de données associées.
• Il ajoute sa propre règle, avec le waker, devant chaque règle qui transfère vers le target group. Votre règle reste telle quelle. Une règle qu'il ne peut pas couvrir ainsi reçoit elle-même le waker et le tag. C'est celle qui agit avant son transfert (une connexion, par exemple), qui a des transformations, ou qui n'a plus de priorité libre devant elle. Les étapes de l'opération nomment ces règles. Le trafic ne change pas.
• Dès lors, il met le workload en veille quand celui-ci est inactif.
• Une intégration qui échoue est annulée.
• Si Terraform écrit l'une de ces ressources, il doit ignorer ce qui change.

Les workloads Kubernetes sur EKS s'intègrent aussi. Le waker se place devant eux de trois façons : les règles de l'équilibreur de charge, l'Ingress de Dormeto, ou une modification de l'Ingress du workload. La fenêtre Onboard indique laquelle. Le point de terminaison de l'API du cluster doit être public pour toutes les adresses, ou son accès privé doit être activé. Avec l'accès privé, une petite fonction proxy dans son VPC le joint, à partir du routeur 0.33.0. Le cluster doit d'abord accorder ses droits à Dormeto (Accès à l'organisation).

Si Terraform écrit ces ressources

Terraform ignore ce que l'intégration a ajouté : chaque plan propose donc de le retirer. Si vous appliquez ce plan, le routeur rétablit le tout, environ une minute plus tard dans nos tests. Il consigne chaque correction sur la page du workload. Pendant cette minute, une règle modifiée va directement à l'application. Les visiteurs d'un workload en veille reçoivent l'erreur de l'équilibreur de charge. Ces quelques lignes gardent vos plans propres.

Pour les tags de tous les backends, dans le provider AWS :

provider "aws" {
  ignore_tags {
    key_prefixes = ["dormeto:"]
  }
}

Puis, sur les ressources que vous avez écrites, lifecycle { ignore_changes = [...] } avec ces champs :

Les bases de données n'ont besoin que du bloc provider. Avec action ignoré, Terraform n'applique plus vos propres modifications des actions de cette règle. Retirez l'ignore le temps de cet apply, et le routeur remet le waker.

Le bloc provider couvre tout ce que ce provider écrit. Ne l'utilisez pas si le provider déclare aussi des tags dormeto:, comme pour un workload écrit avec le module workload. Un tel workload n'est pas corrigé non plus : votre configuration déclare le waker et le tag de sa règle, et ignore action. Pour les workloads Kubernetes, la boîte de dialogue Onboard donne ce qu'un outil GitOps doit ignorer.

Les réglages

La fenêtre Onboard les demande. Seuls le nom, les tags et Hibernate se modifient ensuite.

Après l'intégration

La page du workload, sous Workloads, propose un menu Actions. Les opérateurs et les administrateurs voient toutes les actions. Les membres voient celles que leurs groupes accordent sur les tags du workload.

• Wake ou Nap immédiatement. Nap est indisponible tant que le workload est en pause.
• Pause suspend les mises en veille. Les requêtes le réveillent toujours. Donnez un motif et, si vous voulez, une reprise automatique. Elle peut intervenir dans 1 heure, 4 heures, 1 jour, 7 jours, ou à une date, 366 jours au plus. La pause réveille un workload en veille, sauf si vous choisissez de l'y laisser. Resume y met fin.
• Rename change le nom affiché.
• Exclude écarte de Dormeto son target group, son équilibreur de charge ou son compte, avec un motif et une échéance facultative. Le workload n'est plus jamais mis en veille et attend son retrait.
• Offboard réveille le workload, puis retire uniquement ce que l'intégration a ajouté : le waker, les règles de Dormeto, les tags posés, la configuration.

Edit tags, à côté des tags, est réservé aux administrateurs. La carte Schedule définit des plages hebdomadaires d'éveil et de veille (Horaires). Un routeur entier se met en pause depuis Routers.

Le délai d'inactivité, le mode de réveil, les bases de données et les types de repli ne se modifient pas sur place. Retirez le workload, puis intégrez-le à nouveau. Un workload écrit avec le module Terraform workload se modifie dans Terraform. Le tableau de bord ne le renomme pas, ne le tague pas et ne le retire pas.

Descriptions

Un routeur et un workload peuvent chacun porter une description. Elle dit en quelques mots son rôle, son responsable ou ce qu'il faut savoir avant d'y toucher. Elle est facultative, de 4 000 caractères au plus, écrite en Markdown. Elle demande un manager 0.19.0 et, pour la CLI, 0.7.0.

• Où elle s'affiche. Dans la page du workload et celle du routeur, dans une carte Description, avec l'auteur et la date. Les listes Workloads et Routers en montrent la première ligne sous le nom.
• Qui l'écrit. Les opérateurs et les administrateurs pour un workload, les administrateurs pour un routeur. Toute personne qui voit le workload ou le routeur la lit. Dans le tableau de bord : carte Description, puis Edit (Add a description quand il n'y en a pas). Dans la CLI : dormeto aws workloads description <router>/<workload> [--set <text> | --file <path or -> | --clear] et dormeto aws routers description <router> [--set <text> | --file <path or -> | --clear] (workloads, routeurs).
• Où elle est conservée. Dans le manager, pas dans le routeur ni dans Terraform. Elle fonctionne pour tout routeur et tout workload, que leur configuration vienne de Terraform ou du manager. Elle reste quand un workload est retiré et revient s'il est intégré de nouveau. Celle d'un routeur reste quand le routeur est désinstallé. L'effacer est une action explicite.

Le Markdown pris en charge : titres, paragraphes, listes à puces et numérotées, citations, blocs de code délimités par ```. Aussi code, gras, italique et liens vers des adresses https:// uniquement. Tout le reste, HTML brut compris, s'affiche comme du texte.

Hibernation

Avec hibernation

1. En marche Ses processus sont en mémoire.
2. Mise en veille Elle enregistre sa mémoire sur le volume racine chiffré.
3. En veille Le calcul s'arrête. Seul le stockage du volume reste payé. Hiberner ne coûte rien de plus.
4. Réveil La prochaine requête la réveille. Elle reprend avec sa mémoire : processus là où ils étaient, caches chauds. Plus vite.

Un arrêt simple

1. Mise en veille L'instance s'arrête net. Sa mémoire n'est pas enregistrée.
2. En veille Le calcul s'arrête. Seul le stockage du volume reste payé.
3. Réveil La prochaine requête la réveille. Elle redémarre de zéro, caches froids.

Activée par défaut : à la mise en veille, l'hibernation enregistre la mémoire d'une instance EC2 autonome sur son volume racine chiffré. L'instance n'est pas arrêtée net. Le réveil reprend ses processus là où ils étaient : plus vite, avec des caches déjà chauds. Cela ne coûte rien de plus : la place de la mémoire sur le volume est réservée au lancement de l'instance. Elle concerne les instances EC2 autonomes que Dormeto arrête lui-même, pas les groupes Auto Scaling, ECS, Kubernetes ni les bases de données. La vue du workload affiche « ne s'applique pas » pour un workload qui n'en a pas. Elle demande un routeur 0.32.0, un manager 0.19.0 et, pour la CLI, la version 0.7.0.

• Une instance lancée avec l'hibernation, et en cours d'exécution, est mise en hibernation à la mise en veille. Toute autre instance est arrêtée, comme avant.
• Une hibernation qu'AWS refuse devient un arrêt : une mise en veille n'échoue jamais pour cela.
• Dormeto ne lance ni ne reconfigure jamais une instance. Qu'une instance puisse hiberner se décide à son lancement.
• Rien à appliquer de nouveau dans vos comptes : les routeurs ont déjà les droits nécessaires.
• L'hibernation est activée tant que vous ne la coupez pas. Des instances lancées avec l'hibernation doivent continuer à s'arrêter ? Désactivez Hibernate dans Routers, puis Workload defaults, avant de mettre à jour les routeurs.

Ce qu'il faut à une instance

AWS vérifie ces points au lancement de l'instance, et l'hibernation ne peut pas être ajoutée à une instance existante :

• L'hibernation activée au lancement.
• Une famille d'instances prise en charge.
• Un volume racine EBS chiffré, assez grand pour la mémoire.
• Une mémoire de moins de 150 GiB sous Linux, de moins de 16 GiB sous Windows.

Où la régler

Trois niveaux, vrai ou faux, et une règle pour les types de repli. Le plus précis de ceux qui sont définis l'emporte :

1. Le workload. En Terraform, hibernate du module workload. Pour un workload intégré par le manager, la fenêtre Onboard, puis Hibernate dans la page du workload. Inherit ne définit rien. Les opérateurs et les administrateurs la changent, dans la CLI avec dormeto aws workloads settings ou, à l'intégration, dormeto aws workloads onboard --hibernate.
2. La règle des types de repli. Quand le workload ne définit rien et a des types d'instance de repli (fallback), il n'hiberne pas. Une instance hibernée ne peut pas changer de type. Mettez hibernate à true sur le workload pour accepter ce compromis. Ses instances hibernées se réveillent alors sur leur seul type. Une instance qui tourne déjà sur un type de repli est arrêtée, pas hibernée.
3. Le routeur. Routers, puis la vue du routeur, ou dormeto aws routers settings. Les administrateurs la changent.
4. La valeur par défaut du manager. Routers, puis Workload defaults, ou dormeto aws settings set --hibernate. Les administrateurs la changent. Activée tant qu'elle n'a pas été définie. Un routeur écrit en Terraform sans ip_lists_catalog l'active (la valeur par défaut intégrée) et ignore la valeur par défaut du manager. Définissez plutôt son niveau routeur. Un routeur peut lire les réglages du manager sans les avoir encore lus (tout juste mis à jour), ou ses lectures peuvent échouer sans cesse. Quand la valeur par défaut du manager déciderait, ce routeur s'arrête sans hiberner, et sa santé avertit.

Les routeurs lisent la valeur par défaut du manager à leur vérification suivante, dans les 5 minutes.

dormeto aws settings set --hibernate false
dormeto aws routers settings prod-eu --hibernate inherit
dormeto aws workloads settings --tag env=dev --hibernate true --yes

Limites

• 60 jours. AWS ne prend pas en charge une instance hibernée plus de 60 jours. Après 59 jours d'hibernation, Dormeto réveille le workload pour une maintenance. Une pause qui le laisse endormi retient aussi ce réveil. Ensuite, la mise en veille suivante arrête ses instances au lieu de les mettre en hibernation. Elles démarrent alors à neuf au réveil suivant.
• Jamais mis en hibernation : les instances d'un groupe Auto Scaling, ECS, Kubernetes et les bases de données. Ils se mettent en veille comme avant.
• Hiberner écrit la mémoire sur le volume : la mise en veille est plus longue quand la mémoire est grande.

Page d'attente

Pendant le réveil d'un workload, ses visiteurs voient une page d'attente. Par défaut, c'est celle de Dormeto : un point, une phrase sur ce qui se passe et un compteur. Vous pouvez y mettre votre nom, votre icône et vos mots, ou la remplacer par votre propre page HTML. Elle s'applique aux workloads AWS. La page d'attente de Google Cloud reste pour l'instant telle qu'elle est. Elle demande un routeur 0.35.0, un manager 0.20.0 et, pour la CLI, la version 0.8.0. Rien à appliquer de nouveau dans vos comptes.

• Modèle (template). Une icône, un titre et une description, sans code. La page garde les couleurs et la mise en page de Dormeto, en clair et en sombre. La phrase d'état (réveil en cours, échec et sa cause, veille programmée jusqu'à quand) reste celle de Dormeto et ne peut pas être changée. Un modèle ne cache jamais ce qui est vrai.
• Page personnalisée (custom). Votre propre page HTML complète, téléversée. Elle réveille toujours le workload (Page personnalisée).

Les limites :

• Un titre : 80 caractères au plus, sur une ligne.
• Une description : 500 caractères au plus.
• Une icône téléversée : 64 KiB au plus, en PNG, JPEG, WebP, SVG ou ICO.
• Une page personnalisée : 256 KiB au plus.

Le type de l'icône est lu dans ses octets, pas dans son nom.

Depuis le routeur 0.36.0, les deux prennent du Markdown : **gras**, *italique*, `code` et liens vers des adresses https://. La description prend aussi des titres, listes, citations et blocs de code. Les sauts de ligne sont conservés. Le HTML brut s'affiche comme du texte.

Où la régler

Trois niveaux. Le niveau le plus précis qui a une page décide de son mode. Pour un modèle, l'icône, le titre et la description viennent chacun du modèle le plus précis qui l'a. Un workload peut donc changer son titre et garder l'icône de l'entreprise. Une page personnalisée d'un niveau au-dessus est ignorée quand on cherche les champs d'un modèle. Une limite : un niveau inférieur peut remplacer un titre ou une description hérités, mais pas les vider. Un champ vide est refusé et un champ absent hérite. Un workload qui ne veut aucune description sous une organisation qui en définit une doit donc écrire un autre texte. Seule l'icône peut valoir None. Sans rien de défini nulle part, la page est un modèle avec l'icône automatique.

1. Le workload. En Terraform, waiting_page du module workload (Configuration). Pour un workload intégré par le manager, la carte Waiting page de la page du workload, ou dormeto aws workloads waiting-page. Les opérateurs et les administrateurs définissent un modèle. Seuls les administrateurs définissent une page personnalisée.
2. Le routeur. La carte Waiting page de la page du routeur, ou dormeto aws routers waiting-page. Les administrateurs.
3. L'organisation. Routers, puis Workload defaults, la carte Organization, ou dormeto aws settings waiting-page. Les administrateurs. Elle s'applique à tout routeur qui lit les réglages du manager.

Les lecteurs voient la page et sa carte sans rien changer. Un workload écrit par Terraform refuse les changements du manager : définissez waiting_page dans son module. Un changement, à n'importe quel niveau, celui de l'organisation compris, atteint les visiteurs en une minute environ. La fenêtre de modification du tableau de bord prévisualise la page dans chaque état : réveil, réveil plus long que d'habitude, échec, plage de veille. L'aperçu existe en anglais ou en français, en clair ou en sombre. Dans cet aperçu, les scripts d'une page personnalisée ne s'exécutent pas et ses images et polices distantes ne s'affichent pas.

L'icône

L'icône d'un modèle est Automatic (par défaut), Upload ou None.

• Automatic est le favicon de l'application elle-même. Le routeur le lit pendant que le workload est éveillé, juste avant une mise en veille. Un workload a donc son icône dès sa première veille. Il le lit au plus une fois par jour et par workload, que la lecture ait réussi ou non. Cela ajoute au plus environ 3 secondes au début de cette mise en veille. Une lecture qui échoue n'empêche jamais une mise en veille. Le routeur demande à l'application sa page d'accueil et y cherche l'icône de la page (icon, shortcut icon, puis apple-touch-icon). Sinon, il demande /favicon.ico. Cela fait une requête pour la page et une pour l'image, au plus une fois par jour. Elles sont visibles dans les journaux de l'application. L'icône peut peser 32 KiB au plus. Une plus grande peut être téléversée à la place.
• Upload prend une image de 64 KiB au plus.
• None affiche le point de Dormeto et coupe la lecture du favicon pour le périmètre du niveau. Ce périmètre est tous les workloads à l'organisation, ceux d'un routeur, ou un seul workload. Un niveau inférieur qui indique Automatic la rétablit pour les siens.

La carte du workload montre le favicon en cache avec sa date, ou pourquoi il n'y en a pas. Elle indique not read yet avant sa première veille. Elle indique not read quand la page est personnalisée, que l'icône vaut None ou qu'une image est téléversée. Sinon, elle donne la raison de l'échec de la lecture. Il n'y en a pas, et le téléversement est la réponse, quand :

• le workload est derrière un équilibreur de charge interne, que le routeur ne peut pas joindre.
• ses règles n'ont aucun nom d'hôte qui lui soit propre : un hôte avec joker, ou une règle qui teste aussi un chemin ou un en-tête. Une requête sur / pourrait appartenir à un autre workload.
• son listener est en http: seulement.
• l'application cache son favicon derrière une connexion.

La langue du visiteur

Les phrases de Dormeto existent en anglais et en français, choisies d'après l'en-tête Accept-Language du visiteur. La première langue prise en charge l'emporte (fr-CA est du français). Sans en-tête, ou sans langue prise en charge, la page est en anglais. Votre titre et votre description s'affichent tels que vous les avez écrits. Les clients d'API reçoivent le même JSON, en anglais. Derrière CloudFront, transmettez l'en-tête Accept-Language à l'équilibreur de charge (la politique de requête d'origine gérée Managed-AllViewer le fait).

La barre de progression

Le routeur garde la durée des 10 derniers réveils terminés du workload et en utilise la médiane. Pendant le réveil, la page montre une barre qui se remplit vers ce temps habituel, sans dépasser 95 %. Elle montre aussi les secondes écoulées depuis le début du réveil. Quand le réveil dure plus longtemps que d'habitude, la page le dit. Sans réveil enregistré, il n'y a pas de barre, seulement les secondes. Un réveil en échec ou une plage de veille n'affiche pas de barre. Une page qui montre une barre la garde à 100 % le temps que la route soit prête.

Page personnalisée

Une page personnalisée est votre propre HTML, servie avec le même code de statut et les mêmes en-têtes que la page de Dormeto. Elle n'a pas la politique de sécurité du contenu de Dormeto, qui la casserait. C'est un fichier de texte UTF-8, non vide, de 256 KiB au plus. Mettez les images en ligne ou à vos propres adresses.

Elle réveille toujours le workload. Dormeto ajoute un rafraîchissement dans <noscript> et son script tout au début du document. Ils viennent après un éventuel BOM, des espaces, des commentaires, une déclaration XML et le doctype quand ils sont en premier. Le script lance le réveil tout de suite, quoi que contienne votre page. Il recharge la page dans l'application quand elle est prête. Votre doctype reste en premier : le navigateur garde le mode standard. L'analyseur du navigateur place ce bloc dans l'en-tête qu'il construit, puis lit vos balises <html> et <head>. Les attributs de votre <html> sont conservés. Ceux de votre <head> sont perdus, car le document a déjà son en-tête. Mettez-les sur <html> ou <body>. Pour montrer l'état, marquez des éléments avec ces repères. Le script les cherche à chaque mise à jour : un élément que votre propre JavaScript affiche plus tard fonctionne aussi :

Dans votre HTML	Ce que fait le script
data-dormeto="status"	Son texte devient la phrase d'état, dans la langue du visiteur. Le texte est réécrit à chaque mise à jour : n'y mettez rien que vous voulez garder.
data-dormeto="elapsed"	Son texte devient les secondes écoulées depuis le début du réveil ou l'ouverture de la page, avec leur unité : 3 s. N'écrivez pas l'unité vous-même.
data-dormeto="progress"	Son style.width devient le pourcentage de la barre, et son attribut hidden est retiré dès qu'une barre s'applique.
l'événement dormeto:state	Émis sur document à chaque sondage, avec detail : state, failure, retryAt, napUntil, elapsedMs et typicalMs.

Une page sans repère status réveille quand même le workload, mais n'affiche aucun état. La fenêtre de modification et la CLI vous en avertissent, ainsi que d'une balise meta Content-Security-Policy dans votre page. Le script de Dormeto vient en premier : un script-src ne l'arrête donc pas. Mais un connect-src (ou un default-src) qui n'autorise pas votre propre adresse bloque ses requêtes. Le workload peut se réveiller sans que la page l'apprenne, et les visiteurs restent bloqués dessus. Un avertissement ne refuse pas la page.

<!doctype html>
<html lang="fr">
<head>
  <meta charset="utf-8">
  <title>Acme recette</title>
  <style>
    body { font-family: sans-serif; text-align: center; padding-top: 20vh; }
    .bar { width: 16rem; height: 6px; margin: 1rem auto; background: #ddd; }
    .bar div { height: 100%; background: #4589ca; }
  </style>
</head>
<body>
  <h1>Acme recette démarre</h1>
  <p data-dormeto="status">Démarrage de l'application…</p>
  <p><span data-dormeto="elapsed">0 s</span></p>
  <div class="bar"><div data-dormeto="progress" hidden></div></div>
  <script>
    document.addEventListener('dormeto:state', (e) => {
      if (e.detail.state === 'FAILED') document.title = 'Acme recette : problème';
    });
  </script>
</body>
</html>

Sécurité

Une page personnalisée s'exécute à l'adresse même de l'application. Ses scripts peuvent lire les cookies de ce site et appeler son API comme le visiteur. C'est pourquoi, dans le tableau de bord, seuls les administrateurs peuvent définir, remplacer ou effacer une page personnalisée, à chaque niveau. Un opérateur qui peut modifier un workload ne le peut pas. La CLI et l'API ne font pas cette vérification elles-mêmes. Un appelant des routes /iam/ du manager compte comme administrateur. Un principal IAM autorisé à les appeler peut donc définir une page personnalisée. N'accordez ces routes qu'à des personnes à qui vous confieriez les sessions des utilisateurs de votre application. Retirer un workload supprime sa page d'attente avec lui, page personnalisée comprise, quel que soit celui qui le retire. Le journal d'audit de Dormeto enregistre un changement avec la taille et l'empreinte de la page, jamais son contenu. Il fait de même pour une page personnalisée qu'un changement remplace ou supprime. Un modèle n'exécute jamais votre code. Le titre et la description sont du texte échappé. L'icône ne s'affiche que dans une image.

Dans Terraform

waiting_page du module workload écrit la page sans passer par le manager. null (la valeur par défaut) n'écrit rien, et le retirer supprime la page qu'il a créée.

module "shop" {
  source = "…/workload"
  # …
  waiting_page = {
    mode        = "template"
    icon        = "data:image/png;base64,${filebase64("${path.module}/logo.png")}"
    title       = "Boutique Acme (recette)"
    description = "Cet environnement dort la nuit.\nLa première visite le réveille."
  }
}

# ou une page personnalisée :
#   waiting_page = { mode = "custom", html = file("${path.module}/waiting.html") }

Si vous passez un workload sous Terraform alors qu'une page définie depuis le manager s'y trouve, effacez d'abord cette page depuis le manager. Le workload refuse ensuite ses changements. La page de Terraform la remplace alors.

Valeurs non configurables

Elles valent pour chaque workload que le manager intègre. Elles ne sont pas encore des réglages du manager (À venir).

Délais

• Pendant un réveil, les requêtes sont retenues jusqu'à 60 secondes. Elles reçoivent ensuite la page d'attente, qui se recharge d'elle-même.
• Un réveil échoue au bout de 10 minutes. Avec une base de données associée, au bout de 30 minutes. Pour un workload Kubernetes, au bout de 5 minutes.
• La vérification d'inactivité a lieu toutes les 5 minutes, aux repères de 5 minutes de l'horloge.

Quand un réveil échoue

• Un échec dit pourquoi : capacity, quota, permission, configuration, unhealthy, throttled, timeout, cluster (Kubernetes) ou unknown. La page du workload et la page d'attente l'affichent, avec la prochaine tentative.
• Un démarrage EC2 ou RDS refusé faute de capacité est retenté pendant le réveil. Les nouveaux essais ont lieu après 30 secondes, 60 secondes, puis toutes les 120 secondes. Auto Scaling et ECS réessaient d'eux-mêmes.
• Après un réveil en échec, la requête suivante réessaie au bout de 60 secondes. Le délai double à chaque échec consécutif, jusqu'à 30 minutes. En Terraform, failed_retry_seconds règle le premier délai, de 10 à 600 secondes.
• Un workload en échec dont les backends tournent sans cible saine est arrêté à l'issue de son délai d'inactivité, sauf s'il est en pause. Un réveil en échec ne coûte donc jamais indéfiniment.

Exemples

Chaque exemple donne les valeurs à saisir dans la fenêtre Onboard.

Un site web avec sa base Aurora

Pourquoi : la base coûte autant que l'application, et dort tout aussi bien.

• Companion databases : cluster:shop-aurora.

Une mise en veille arrête l'application, puis le cluster Aurora, sans l'attendre. Un réveil démarre le cluster, attend qu'il soit disponible, puis démarre l'application. Comptez quelques minutes : le réveil dispose de 30 minutes avant d'échouer.

AWS redémarre une base arrêtée au bout de 7 jours. Tant que le workload dort, le routeur l'arrête à nouveau. Pour une instance RDS, donnez son seul identifiant, par exemple shop-db. Les réplicas en lecture et Aurora Serverless v1 sont laissés de côté.

Une API réveillée seulement par les navigateurs

Pourquoi : robots et scanners appellent l'adresse publique de l'API toute la nuit, et la réveillent. Les vrais utilisateurs passent par l'application web, dans un navigateur.

• Wake mode : Browser.

Une requête ordinaire reçoit aussitôt la page d'attente, ou une réponse JSON qui nomme l'en-tête de réveil. Rien ne démarre. Un navigateur exécute le script de la page d'attente, qui réveille le workload. Scripts et clients d'API le réveillent avec l'en-tête :

curl -H 'x-dormeto-wake: 1' https://api.example.com/health

Une requête qui arrive pendant un réveil est retenue, comme en mode Any. Les robots qui n'exécutent pas de JavaScript ne le réveillent jamais.

Des types d'instance rares

Pourquoi : à 08:00, de nombreuses équipes démarrent le même type d'instance. Il arrive qu'AWS n'en ait plus dans la zone.

• Fallback instance types : m6i.large, m5.large, t3a.large.

Un démarrage refusé faute de capacité est retenté pendant le réveil. L'instance peut alors démarrer avec le type suivant de la liste, dans l'ordre. À sa mise en veille suivante, elle reprend son type d'origine.

En attendant, la page du workload indique On fallback instance types. Seul le type d'instance change. En Terraform, la même liste est la variable fallback_instance_types du module workload.

Un long délai d'inactivité pour un back-office

Pourquoi : l'équipe utilise le back-office par à-coups dans la journée. Avec 15 minutes, elle attendrait un réveil plusieurs fois par jour.

• Idle window : 120 minutes.

Le workload ne se met en veille qu'après 2 heures sans requête : moins d'attente, un peu moins d'économies. Sa carte Idle window rejoue ses 14 derniers jours de requêtes avec des délais de 5 à 120 minutes. Elle montre ce que chacun économiserait par mois, et à quelle fréquence les visiteurs attendraient.

Pour changer le délai plus tard, retirez le workload puis intégrez-le à nouveau. Pour qu'il dorme aussi la nuit, ajoutez un horaire (Horaires).