Aller au contenu
CivoCloudManager

Parcourez Civo Object Storage en S3 sur macOS.

L'endpoint régional, la configuration qui marche pour s3cmd, rclone et l'AWS CLI, et ce qu'un client natif fait autrement.

Civo Object Storage parle S3, donc presque tous les clients S3 savent lui parler dès que deux choses sont justes : l'endpoint de la région où vit le store, et un identifiant créé dans cette même région. La documentation de Civo déroule s3cmd et vous laisse le reste de l'outillage. Cette page donne la configuration brute pour s3cmd, rclone et l'AWS CLI, puis montre le chemin que prend CivoCloudManager, qui lit l'endpoint et les clés d'accès directement dans l'API Civo, donc sans rien à configurer à la main.

Configurer un client S3 pour Civo

  1. 01

    Trouvez l'endpoint de votre région.

    Civo construit les endpoints d'object store sous la forme https://objectstore.<region>.civo.com avec le code de région en minuscules, donc un store à Londres se joint sur https://objectstore.lon1.civo.com et un store à Francfort sur https://objectstore.fra1.civo.com. Chaque store affiche aussi son propre endpoint dans le tableau de bord Civo et le renvoie dans le champ objectstore_endpoint de l'API REST. D'après le récapitulatif des fonctionnalités par région de Civo, les object stores sont disponibles en LON1, FRA1, NYC1 et MUM1, et pas en PHX1.

  2. 02

    Créez un identifiant dans cette même région.

    Chaque object store Civo est privé et demande un access key ID et une clé secrète. Créez l'identifiant dans le tableau de bord Civo, section Object Stores, avec le sélecteur de région positionné sur celle du store, ou avec la CLI Civo. La commande civo objectstore credential export -a <access_key> imprime la paire sous AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION et AWS_HOST, prête à coller dans un shell.

  3. 03

    s3cmd : host_base et host_bucket.

    Dans ~/.s3cfg, sous [default], mettez host_base = objectstore.fra1.civo.com, host_bucket = objectstore.fra1.civo.com, bucket_location = fra1, use_https = True, signature_v2 = False, plus access_key et secret_key. Donner à host_bucket le même nom d'hôte qu'à host_base garde s3cmd en adressage par chemin, qui est ce à quoi Civo répond. Ensuite s3cmd ls liste vos stores, s3cmd ls s3://STORENAME en liste un, s3cmd put file.tar s3://STORENAME/backups/ envoie un fichier, et s3cmd get -r s3://STORENAME/backups/ rapatrie tout un préfixe. Sans fichier de configuration, les deux mêmes valeurs passent en ligne de commande via --host= et --host-bucket=.

  4. 04

    rclone : un remote de type s3, provider Other.

    Lancez rclone config et choisissez s3, ou écrivez le bloc directement dans ~/.config/rclone/rclone.conf : sous [civo], mettez type = s3, provider = Other, env_auth = false, access_key_id et secret_access_key de l'identifiant, region = fra1, endpoint = https://objectstore.fra1.civo.com et acl = private. Après quoi rclone lsd civo: liste les stores, rclone ls civo:STORENAME liste les objets, rclone copy ./dir civo:STORENAME/dir -P envoie un dossier avec la progression, et rclone ncdu civo:STORENAME donne un navigateur en mode texte. Les mêmes réglages marchent en drapeaux ponctuels : --s3-provider Other --s3-endpoint https://objectstore.fra1.civo.com --s3-region fra1.

  5. 05

    AWS CLI : --endpoint-url à chaque appel.

    L'AWS CLI n'a besoin d'aucun plugin propre à Civo, seulement de l'endpoint sur chaque commande : aws s3 ls --endpoint-url https://objectstore.fra1.civo.com, puis aws s3 ls s3://STORENAME --endpoint-url ... et aws s3 cp file.tar s3://STORENAME/ --endpoint-url ... . Les identifiants viennent de AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY ou d'un profil nommé, avec AWS_DEFAULT_REGION réglé sur le code de région Civo pour que la portée de la Signature V4 corresponde. Une note pour les versions récentes : l'AWS CLI 2.23 et suivantes ajoutent par défaut une somme de contrôle CRC64NVME aux envois, que tous les endpoints compatibles S3 n'acceptent pas, donc si un put échoue sur une erreur de checksum, mettez AWS_REQUEST_CHECKSUM_CALCULATION=when_required et AWS_RESPONSE_CHECKSUM_VALIDATION=when_required.

Le piège qui coûte une heure : les clés sont liées à une région

La documentation de Civo le dit en deux phrases faciles à survoler : les object stores sont propres à une région, et les identifiants qui servent à les gérer et à y accéder sont liés à la région où ils ont été créés. Une clé fabriquée alors que le tableau de bord était sur FRA1 ne s'authentifiera pas contre l'endpoint LON1, même compte et même facturation pourtant. Le symptôme est une erreur d'authentification ou de signature qui ressemble à une faute de frappe dans le secret, donc le réflexe naturel est de régénérer la clé, ce qui produit une autre clé dans la même mauvaise région. Vérifiez d'abord le sélecteur de région, créez l'identifiant à côté du store, et suspectez la configuration seulement après.

Ce que la ligne de commande ne couvre pas

Pour les scripts, les sauvegardes et la CI, s3cmd, rclone et l'AWS CLI sont la bonne réponse et rien ici ne les remplace. Ce qu'ils ne donnent pas, c'est un regard sur un store : une arborescence de dossiers, des tailles d'un coup d'œil, une sélection qu'on fait glisser dehors. Des clients S3 génériques pour Mac comme Cyberduck ou Transmit comblent ce manque, mais ils ne connaissent rien à Civo, donc vous saisissez l'endpoint, collez les deux clés pour chaque store et tenez tout à jour à la main à chaque rotation d'identifiant.

La voie de l'app : aucun endpoint à saisir

CivoCloudManager s'authentifie une fois avec votre clé API Civo et lit la liste des object stores depuis l'API REST Civo v2, qui porte déjà l'endpoint et l'identifiant lié à chaque store. Il construit le client S3 à partir de là, donc pas de champ endpoint, pas de clé à coller, pas de fichier de configuration. La couche S3 est du Swift pur : AWS Signature V4 calculée avec HMAC-SHA256 de CryptoKit, sans SDK AWS et sans Electron. Elle fait du ListObjects v2 avec jetons de continuation, une navigation en fil d'Ariane sur les préfixes communs, la sélection multiple et le téléchargement récursif de dossiers avec une ligne de progression. Soyons clairs sur sa forme : le navigateur lit et télécharge. Les envois et les suppressions restent l'affaire de s3cmd ou de rclone. L'app demande macOS 15 ou plus récent.

Des clés d'accès derrière Touch ID plutôt que dans un dotfile

C'est la partie qui vaut l'installation même si vous gardez la CLI. Une configuration s3cmd qui marche, cela veut dire que la clé secrète est en clair dans ~/.s3cfg, et c'est pareil pour rclone.conf et ~/.aws/credentials. N'importe quel processus lancé sous votre utilisateur peut lire les trois, et tout ce qui parcourt votre répertoire personnel aussi. CivoCloudManager garde la clé API Civo dans le Keychain macOS, et révéler la secret access key d'un object store dans l'interface demande d'abord Touch ID ou le mot de passe système. La limite est évidente et mérite d'être dite : dès que vous copiez une clé dans un terminal, elle redevient un fichier en clair.

Pause et Resume pour les stores dont vous ne vous servez pas

Un store inactif est quand même facturé sur sa taille allouée. Pause copie chaque objet dans un object store central nommé civo-cloud-manager, en agrandissant d'abord ce vault si les données ne tiennent pas, compare les clés et les tailles copiées à la source, et ne supprime le store d'origine que si tout correspond. La ligne disparaît de la facture Civo. Resume recrée le store sous le même nom avec le même identifiant, recopie les objets, revérifie clés et tailles, puis vide le vault. Jusqu'à quatre objets se déplacent en parallèle. Les limites honnêtes : la vérification compare les noms et les tailles plutôt que le contenu haché, les transferts mettent chaque objet entier en mémoire tampon, et le manifest distant est écrit après la suppression de la source, avec un manifest local en repli.

Quel client pour quel travail

Les quatre parlent à la même API S3 sur le même endpoint. La différence est ailleurs : où vit la configuration, où finit le secret, et ce que vous pouvez voir.

Tâche s3cmdrcloneAWS CLICivoCloudManager
Configuration de l'endpoint host_base et host_bucket dans ~/.s3cfgendpoint dans le remote--endpoint-url à chaque appellu depuis l'API Civo
Où finit la clé secrète ~/.s3cfg, en clairrclone.conf, en clair~/.aws/credentials, en clairKeychain macOS, Touch ID pour révéler
Parcourir un store visuellement nonrclone ncdu, en mode textenonoui, navigateur avec fil d'Ariane
Envoyer et supprimer des objets ouiouiouipas dans le navigateur
Téléchargement récursif de dossiers s3cmd get -rrclone copyaws s3 cp --recursiveoui, avec progression
Mettre en pause un store inactif pour arrêter de payer nonnonnonoui, vault avec vérification avant suppression
Tourne en CI ouiouiouinon, c'est une app Mac

Civo Object Storage en S3, les réponses

Quelle est l'URL d'endpoint de Civo Object Storage ?
Les endpoints d'object store Civo suivent le modèle https://objectstore.<region>.civo.com avec le code de région en minuscules, par exemple https://objectstore.lon1.civo.com à Londres ou https://objectstore.fra1.civo.com à Francfort. L'endpoint dépend de la région où le store a été créé. Chaque store affiche aussi son propre endpoint dans le tableau de bord Civo et le renvoie dans le champ objectstore_endpoint de l'API REST Civo.
Puis-je utiliser s3cmd ou rclone avec Civo Object Storage ?
Oui, les deux marchent, et l'AWS CLI aussi, comme tout autre client compatible S3. Pour s3cmd, mettez host_base et host_bucket dans ~/.s3cfg au nom d'hôte régional, par exemple objectstore.fra1.civo.com, et renseignez access_key et secret_key. Pour rclone, créez un remote avec type = s3, provider = Other, endpoint = https://objectstore.fra1.civo.com et la même paire de clés. Pour l'AWS CLI, passez --endpoint-url https://objectstore.fra1.civo.com à chaque commande.
Pourquoi ma clé d'accès Civo Object Storage ne fonctionne-t-elle pas ?
La cause habituelle est la région. Civo indique que les object stores sont propres à une région et que les identifiants sont liés à la région où ils ont été créés, donc une clé créée en FRA1 ne s'authentifiera pas contre l'endpoint LON1 même si elle appartient au même compte. Créez l'identifiant pendant que le tableau de bord est réglé sur la région du store. La deuxième cause fréquente est un client qui n'a jamais reçu l'endpoint, ou un host_bucket s3cmd laissé à sa valeur par défaut, et la requête part alors chez Amazon au lieu de Civo.
Existe-t-il une interface graphique pour Civo Object Storage sur Mac ?
CivoCloudManager est une app macOS native, macOS 15 ou plus récent, sur le Mac App Store, et elle connaît Civo : elle lit l'endpoint et les clés d'accès de chaque store dans l'API Civo, il n'y a donc rien à configurer. Elle parcourt les stores avec un fil d'Ariane et télécharge un fichier, une sélection multiple ou un dossier entier en récursif, tandis que les envois et les suppressions restent du ressort de la CLI. Des clients S3 génériques comme Cyberduck ou Transmit se connectent aussi à Civo une fois l'endpoint saisi et les deux clés collées pour chaque store.
Que fait Pause à mes données dans un object store Civo ?
Pause copie chaque objet dans un object store central nommé civo-cloud-manager, à l'intérieur de votre propre compte Civo, compare les clés et les tailles copiées à la source, et ne supprime qu'ensuite le store d'origine, pour qu'il cesse de coûter. Resume recrée le store sous le même nom avec le même identifiant, recopie les objets et revérifie clés et tailles avant de vider le vault. Les données ne quittent jamais votre compte Civo, et la vérification se fait sur les noms et les tailles plutôt que sur un hachage du contenu.

Passez-vous de la configuration d'endpoint.

CivoCloudManager lit l'endpoint et les clés d'accès dans votre propre compte Civo, donc le store s'ouvre au lieu de réclamer un fichier de configuration. Offre barre de menus gratuite, achat unique pour le tableau de bord complet sur le Mac App Store.

Télécharger sur le Mac App Store

Nécessite macOS 15 (Sequoia) ou plus récent.

Retour à l'accueil