Cas d’usage
Des sauvegardes depuis la CI
Une archive nocturne vers votre bucket depuis un workflow, avec les secrets du runner et aucun fichier à versionner.
- run: tar cz ./data | npx @s3nd/cli put - --name backup.tar.gz --expires-in never
env:
S3ND_BUCKET: transfers
S3ND_PREFIX: backups
S3ND_ENDPOINT: https://${{ secrets.R2_ACCOUNT_ID }}.r2.cloudflarestorage.com
S3ND_REGION: auto
AWS_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}La situation
Ce qui se passe vraiment.
Le problème
Un workflow produit quelque chose qui vaut la peine d’être gardé : un dump de base de données, un build, un rapport généré. Il doit atterrir dans votre bucket chaque nuit, sans fichier de configuration dans le dépôt et sans bibliothèque cliente dans le workflow.
Ce que s3nd y fait
npx @s3nd/cli put, avec le bucket et les identifiants dans des variables d’environnement issues du coffre de secrets du runner. Deux flags transforment un transfert en sauvegarde : --expires-in never, et un préfixe à part pour que la règle de cycle de vie des transferts ne puisse pas l’atteindre.
À surveiller
Les choses faciles à rater.
--json pour les logs
Une sortie lisible par une machine, et s3nd doctor --json sort avec un code non nul quand une vérification échoue, donc il sert aussi de smoke test de déploiement.
Un préfixe par politique
Les transferts expirent, les sauvegardes non. Les garder sous des préfixes différents est ce qui permet à un seul bucket de contenir les deux.
Voir aussi
D’autres formes de la même primitive.
Déposez un fichier. Donnez le code.
Pointez-le sur le bucket que vous payez déjà. Rien à déployer, aucune inscription, personne au milieu.