Stockage

Les caches et les artefacts de run sont gardés dans un stockage objet : le stockage Cadence.CI, ou des buckets qui vous appartiennent, dans le compte cloud et la région que vous choisissez. Dans les deux cas, les workers et les navigateurs envoient et reçoivent les octets directement depuis le stockage, par des liens que Cadence.CI signe pour chaque transfert.

La page Stockage

Ouvrez Stockage, sous Ressources. De haut en bas :

1. Où sont gardés caches et artefacts, les stockages de l’organisation :
   • Ce qui va où trace le chemin de vos données : vos runs écrivent caches et artefacts dans le stockage principal, qui copie les artefacts vers les répliques. Tant que le stockage Cadence.CI garde des objets d’avant votre propre stockage, il l’indique, pendant qu’ils passent vers votre principal. La ligne en dessous résume le tout, et nomme les stockages qui ne reçoivent plus rien.
   • Utilisation de l’offre montre le stockage géré et le stockage Cadence.CI face aux limites de votre offre (voir Stockage géré).
   • Une tuile par stockage, comme les tuiles des comptes cloud : son nom, son rôle, son fournisseur, son bucket et sa région, si sa dernière vérification a réussi et quand, et les copies qu’il doit encore recevoir. Les administrateurs le Vérifient, le Modifient ou le Retirent depuis là. La tuile Stockage Cadence.CI est toujours là, avec ce qu’il contient.
2. Caches : chaque cache avec sa taille, quand il a été utilisé et écrit pour la dernière fois, et les portées de cache.
3. Artefacts : chaque artefact de l’organisation, avec des filtres (voir Artefacts de run).
4. Ajouter un stockage : une tuile par fournisseur, comme sur la page Clouds (voir Ajouter un stockage).

Les membres voient les caches, les artefacts et l’utilisation de l’offre ; les stockages sont montrés aux administrateurs. Obtenir un Jeton d’Artefacts, en haut, mène à la page Clés avec le formulaire d’un jeton d’artefacts ouvert.

Stockage géré

Tout ce dont Cadence.CI s’occupe pour l’organisation forme son stockage géré : les caches et les artefacts où qu’ils soient gardés, sur le stockage Cadence.CI ou sur vos propres buckets, et les rapports de ses runs (logs, événements de débogage et programmes). Chaque objet compte une fois, quel que soit le nombre de buckets qui en ont une copie, envois en cours compris.

Le stockage Cadence.CI est le stockage que Cadence.CI opère lui-même, utilisé par les organisations sans stockage à elles. Ce qui y est gardé fait partie du stockage géré, avec une limite à part, plus petite. Chaque plan fixe les deux, et le nombre de buckets à vous que l’organisation peut ajouter :

La page des tarifs montre ces limites telles que Cadence.CI les applique, et le panneau du plan de la page Organisation montre celles de votre organisation, avec ce qu’elle utilise.

Quand un envoi ne tient pas dans l’une des deux limites, les versions de cache les moins récemment utilisées sont évincées en premier, les versions remplacées avant les autres. Les artefacts restent jusqu’à leur expiration : quand évincer des caches ne suffit pas, l’envoi est refusé et le run l’indique. Quand un plan prend fin ou passe à un plan plus petit, des caches sont évincés jusqu’à ce que l’organisation tienne à nouveau ; les artefacts ne sont jamais évincés. La carte Utilisation de l’offre de la page Stockage montre le stockage géré et le stockage Cadence.CI par rapport à leurs limites ; le second seulement tant que le stockage Cadence.CI est utilisé. La page Organisation compare les quotas de chaque offre.

Votre propre stockage

Les administrateurs ajoutent un bucket depuis la page Stockage du tableau de bord, chez n’importe quel stockage objet compatible S3. Dès lors, les caches et les artefacts vont dans ce bucket : vous payez votre fournisseur pour ce que vous gardez, comme pour vos instances, et les artefacts sont conservés aussi longtemps que vos programmes le demandent. Ils comptent toujours dans le stockage géré, pas dans le stockage Cadence.CI. Le plan fixe combien de buckets l’organisation peut ajouter : en ajouter un de plus est refusé, et après un passage à un plan plus petit, les buckets déjà ajoutés continuent de fonctionner.

• Les clés sont propres au bucket : une clé d’accès et sa clé secrète pour ce bucket, jamais celles de votre compte cloud. Cadence.CI les garde chiffrées comme secret de plateforme, listé sur la page Secrets, que les runs ne lisent jamais et que personne ne relit. Utilisez des clés sans expiration : les liens que Cadence.CI signe avec elles durent jusqu’à 12 heures.
• Un préfixe de chemin permet à plusieurs organisations ou outils de partager un bucket : chaque clé que Cadence.CI écrit va sous ce préfixe. Les caches sont gardés sous des identifiants, jamais sous leur nom ; les artefacts sont gardés à côté des rapports de leur run, sous leur nom et les chemins de leurs fichiers (voir le manifeste).
• Votre stockage reste la référence : quand votre bucket principal est en échec, les restaurations de cache manquent et les enregistrements de cache sont ignorés, avec un avertissement sur le run, et les envois d’artefacts échouent, en nommant le bucket et l’erreur. Même alors, vos données ne vont que dans votre propre stockage.

Ajouter un stockage

1. Dans Ajouter un stockage, en bas de la page Stockage, cliquez sur Connecter sur la tuile de votre fournisseur : Scaleway, AWS, Clever Cloud Cellar, ou tout autre service compatible S3.
2. Remplissez le formulaire. Il remplit l’endpoint et la région pour les fournisseurs connus. À côté des champs, un guide donne les permissions dont la clé a besoin, les règles CORS et une règle de cycle de vie pour votre fournisseur (voir Préparer un bucket).
3. Choisissez son rôle : le premier stockage devient le principal.
4. Cliquez sur Vérifier et ajouter. Cadence.CI vérifie le bucket avec la clé avant de rien enregistrer. Une étape en échec nomme la permission qui manque à la clé ; des avertissements, comme des règles CORS absentes, laissent Ajouter quand même.

Quand l’offre ne permet plus de stockage, les boutons Connecter le disent et restent désactivés ; les stockages déjà ajoutés continuent de fonctionner.

Rôles

Ce qu’un bucket contient reste lisible, quel que soit son rôle. Faire d’un bucket le principal rend le précédent inutilisé, et les artefacts sont copiés vers le nouveau principal comme vers n’importe quelle réplique.

La vérification

Chaque bucket est vérifié avant d’être ajouté, quand un administrateur le demande, et toutes les heures, toutes les dix minutes tant qu’il est en échec. Avec des objets de test sous <préfixe>/cadence-ci-check/, supprimés ensuite, la vérification écrit et lit un objet, le télécharge comme le ferait un navigateur sur Cadence.CI, et comme le ferait un rendu là où les rendus sont disponibles, en envoie un en plusieurs parties, abandonne un envoi en plusieurs parties, et supprime un objet. Une étape en échec nomme la permission qui manque à la clé. Un bucket dont la vérification échoue apparaît en échec sur sa tuile, et redevient actif dès qu’une vérification réussit.

Les navigateurs sur Cadence.CI construisent les zips de plusieurs fichiers directement depuis le bucket, et les rendus y lisent, ce qui demande des règles CORS autorisant GET depuis les sites de Cadence.CI et depuis le domaine des rendus. Sans elles, la vérification donne un avertissement nommant chaque origine refusée, et le bucket peut quand même être ajouté. Cadence.CI définit ces règles lui-même quand vous le laissez faire et que la clé le permet, en conservant les autres règles CORS du bucket.

Préparer un bucket

Le formulaire de la page Stockage remplit le point d’accès et la région pour Scaleway, AWS et Clever Cloud Cellar, et affiche ces étapes à côté des champs.

Scaleway. Créez le bucket dans un projet dédié : les ensembles de permissions s’appliquent à tous les buckets d’un projet. Créez une application IAM avec une politique sur ce projet donnant ObjectStorageObjectsRead, ObjectStorageObjectsWrite, ObjectStorageObjectsDelete et ObjectStorageBucketsRead, plus ObjectStorageBucketsWrite pour que Cadence.CI définisse ses règles CORS. Créez ensuite une clé d’API pour l’application, avec le projet du bucket comme projet préféré. Le point d’accès est https://s3.<région>.scw.cloud, comme https://s3.fr-par.scw.cloud.

AWS. Créez un utilisateur IAM avec cette politique, limitée au bucket ; s3:GetBucketCORS et s3:PutBucketCORS permettent à Cadence.CI de définir ses règles CORS :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:AbortMultipartUpload"],
      "Resource": "arn:aws:s3:::BUCKET/*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket", "s3:GetBucketCORS", "s3:PutBucketCORS"],
      "Resource": "arn:aws:s3:::BUCKET"
    }
  ]
}

Créez ensuite une clé d’accès pour cet utilisateur. Le point d’accès est https://s3.<région>.amazonaws.com.

Clever Cloud Cellar. Créez un add-on Cellar pour ce seul bucket : un add-on a une seule clé, qui lit, écrit et définit les règles CORS de tous les buckets de l’add-on. Créez-y le bucket, et donnez la CELLAR_ADDON_KEY_ID de l’add-on comme clé d’accès et sa CELLAR_ADDON_KEY_SECRET comme clé secrète. Le point d’accès est https://cellar-c2.services.clever-cloud.com et la région default ; les noms de bucket contenant des points utilisent les adresses en chemin.

Autre stockage compatible S3, comme OVHcloud, Outscale, Cloud Temple ou MinIO : donnez le point d’accès et la région indiqués dans sa documentation, et cochez les adresses en chemin quand il sert les buckets sous la forme <point d'accès>/<bucket>. La clé doit pouvoir lire, écrire et supprimer les objets du bucket, abandonner ses envois en plusieurs parties et le lister, et lire et écrire ses règles CORS pour que Cadence.CI les définisse.

La règle pour les sites de Cadence.CI, à définir vous-même sinon, avec la ligne de commande S3 (aws s3api put-bucket-cors --bucket BUCKET --endpoint-url ENDPOINT --cors-configuration file://cors.json). La commande remplace toute la configuration CORS du bucket : mettez ses autres règles dans le même fichier. Les rendus demandent une seconde règle, autorisant les mêmes méthodes depuis le domaine des rendus : le guide à côté du formulaire de la page Stockage affiche les deux règles, exactement comme Cadence.CI les définit. Les services qui refusent les origines écrites https://*. prennent les trois autres seules, et les sous-domaines échouent alors :

{
  "CORSRules": [
    {
      "ID": "cadence-ci-downloads",
      "AllowedOrigins": [
        "https://cadence.ci", "https://*.cadence.ci",
        "https://compositeur.studio", "https://*.compositeur.studio",
        "https://melodium.tech", "https://*.melodium.tech"
      ],
      "AllowedMethods": ["GET", "HEAD"],
      "ExposeHeaders": ["ETag", "Content-Length", "Content-Type", "Content-Disposition"],
      "MaxAgeSeconds": 3600
    }
  ]
}

Les règles de cycle de vie vous appartiennent : une règle qui abandonne les envois inachevés après quelques jours est un bon filet de sécurité, même si Cadence.CI abandonne lui-même ceux qu’il laisse.

Réplication

Les artefacts sont copiés vers chaque bucket principal et réplique actif de l’organisation. Ils survivent à la perte d’un bucket, restent lisibles pendant la panne d’un fournisseur, et peuvent être gardés chez plusieurs fournisseurs ou dans plusieurs juridictions.

• Un worker envoie un artefact une seule fois, vers le principal, ou vers une réplique active quand le principal est en échec. Cadence.CI le copie ensuite vers les autres buckets, sous les mêmes clés, en faisant passer chaque fichier par la mémoire sans le stocker, et vérifie son SHA-256 avant de terminer la copie.
• Une copie qui échoue est retentée une minute plus tard, puis en doublant l’attente à chaque fois, jusqu’à une heure. Après 10 tentatives, elle attend qu’un administrateur vérifie à nouveau le bucket.
• Les téléchargements et les rendus lisent d’abord le principal, puis les répliques, en passant les buckets en échec.
• Un bucket qui devient réplique ou principal reçoit les artefacts qui n’ont pas expiré.
• Les caches restent sur le principal, car ils sont faciles à reconstruire.

La carte Ce qui va où trace ces copies, et la tuile de chaque bucket compte les copies encore à faire et celles en échec ; le détail d’un artefact montre chacune de ses copies.

Quitter le stockage Cadence.CI. Dès que l’organisation a un bucket actif à elle, ses artefacts sur le stockage Cadence.CI y sont copiés, puis supprimés du stockage Cadence.CI, et ses caches qui s’y trouvent sont abandonnés.

Retirer un bucket

Retirer un bucket n’y envoie plus rien, et ce qu’il contient reste lisible tant que sa clé fonctionne. L’oublier abandonne aussi ce que Cadence.CI sait de ses objets et efface ses clés, sans rien supprimer du bucket ; les artefacts qui se retrouvent sans aucune copie sont supprimés de Cadence.CI.

Avant l’un ou l’autre, la page Stockage liste les artefacts dont le bucket contient la seule copie, et demande d’accepter de les perdre. Les artefacts verrouillés qui n’ont pas expiré gardent leur bucket : il pourra être retiré quand ils auront expiré, ou une fois qu’ils auront une copie ailleurs.

Pour aller plus loin

• Caches et artefacts de run.
• Ce qui passe par Cadence.CI : où vont vos données.
• Secrets : les secrets de plateforme.