Przeglądaj Civo Object Storage przez S3 na macOS.

Ostatnia aktualizacja 18 października 2026Autor: Marcel R. G. Berger

Endpoint regionu, działająca konfiguracja dla s3cmd, rclone i AWS CLI, i co natywny klient robi inaczej.

Civo Object Storage mówi po S3, więc dogada się z niemal każdym klientem S3, gdy zgrają się dwie rzeczy: endpoint regionu, w którym store stoi, i poświadczenie utworzone w tym samym regionie. Dokumentacja Civo przeprowadza przez s3cmd, a resztę narzędzi zostawia tobie. Poniżej surowa konfiguracja dla s3cmd, rclone i AWS CLI, a potem ścieżka, którą idzie CivoCloudManager, czyli czytanie endpointu i kluczy dostępu wprost z Civo API, tak że nie ma czego konfigurować ręcznie.

Konfiguracja klienta S3 pod Civo

01

Znajdź endpoint swojego regionu.

Civo buduje endpointy Object Store jako https://objectstore.<region>.civo.com z kodem regionu małymi literami, więc store w Londynie odpowiada pod https://objectstore.lon1.civo.com, a we Frankfurcie pod https://objectstore.fra1.civo.com. Każdy store wypisuje też własny endpoint w dashboardzie Civo i zwraca go w polu objectstore_endpoint w REST API. Według przeglądu funkcji regionów Civo, Object Stores są dostępne w LON1, FRA1, NYC1 i MUM1.
02

Utwórz poświadczenie w tym samym regionie.

Każdy Civo Object Store jest prywatny i potrzebuje access key ID oraz klucza tajnego. Utwórz poświadczenie w dashboardzie Civo w sekcji Object Stores, mając selektor regionu ustawiony na region store'a, albo przez Civo CLI. Komenda civo objectstore credential export -a <access_key> wypisuje parę jako AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION i AWS_HOST, gotowe do wklejenia w powłoce.
03

s3cmd: host_base i host_bucket.

W ~/.s3cfg, w sekcji [default], ustaw host_base = objectstore.fra1.civo.com, host_bucket = objectstore.fra1.civo.com, bucket_location = fra1, use_https = True, signature_v2 = False, plus access_key i secret_key. Nadanie host_bucket tej samej nazwy hosta co host_base trzyma s3cmd przy adresowaniu path style, a tylko takie Civo obsługuje. Potem s3cmd ls wypisuje twoje store'y, s3cmd ls s3://STORENAME jeden z nich, s3cmd put file.tar s3://STORENAME/backups/ wysyła plik, a s3cmd get -r s3://STORENAME/backups/ ściąga cały prefiks. Bez pliku konfiguracyjnego te same dwie wartości idą w linii komend jako --host= i --host-bucket=.
04

rclone: remote typu s3, provider Other.

Uruchom rclone config i wybierz s3, albo wpisz blok wprost do ~/.config/rclone/rclone.conf: pod [civo] ustaw type = s3, provider = Other, env_auth = false, access_key_id i secret_access_key z poświadczenia, region = fra1, endpoint = https://objectstore.fra1.civo.com i acl = private. Potem rclone lsd civo: wypisuje store'y, rclone ls civo:STORENAME obiekty, rclone copy ./dir civo:STORENAME/dir -P wysyła folder z paskiem postępu, a rclone ncdu civo:STORENAME daje przeglądarkę w trybie tekstowym. Te same ustawienia działają jako flagi jednorazowe: --s3-provider Other --s3-endpoint https://objectstore.fra1.civo.com --s3-region fra1.
05

AWS CLI: --endpoint-url przy każdym wywołaniu.

AWS CLI nie potrzebuje żadnej wtyczki pod Civo, tylko endpointu przy każdej komendzie: aws s3 ls --endpoint-url https://objectstore.fra1.civo.com, potem aws s3 ls s3://STORENAME --endpoint-url ... i aws s3 cp file.tar s3://STORENAME/ --endpoint-url ... . Poświadczenia biorą się z AWS_ACCESS_KEY_ID i AWS_SECRET_ACCESS_KEY albo z nazwanego profilu, z AWS_DEFAULT_REGION ustawionym na kod regionu Civo, żeby zakres Signature V4 się zgadzał. Jeden przypis do nowszych wersji: AWS CLI 2.23 i nowsze domyślnie dokłada do wysyłek sumę kontrolną CRC64NVME, której nie każdy endpoint zgodny z S3 przyjmuje, więc jeśli put wysypie się na błędzie sumy kontrolnej, ustaw AWS_REQUEST_CHECKSUM_CALCULATION=when_required i AWS_RESPONSE_CHECKSUM_VALIDATION=when_required.

Pułapka, która kosztuje godzinę: klucze są przypisane do jednego regionu

Dokumentacja Civo mówi o tym wprost w dwóch zdaniach, które łatwo przewinąć: Object Stores są przypisane do regionu, a poświadczenia do zarządzania nimi i do dostępu są związane z regionem, w którym powstały. Klucz zrobiony, gdy dashboard stał na FRA1, nie uwierzytelni się w endpoincie LON1, mimo że to to samo konto i ten sam rachunek. Objawem jest błąd uwierzytelnienia albo podpisu, który wygląda jak literówka w kluczu tajnym, więc naturalnym odruchem jest regeneracja, a ta produkuje kolejny klucz w tym samym złym regionie. Najpierw sprawdź selektor regionu, utwórz poświadczenie obok store'a, a dopiero potem podejrzewaj konfigurację.

Czego linia komend nie obejmuje

Do skryptów, backupów i CI s3cmd, rclone i AWS CLI są właściwą odpowiedzią i nic tutaj ich nie zastępuje. Czego nie dają, to spojrzenia na store: drzewa folderów, rozmiarów na pierwszy rzut oka, zaznaczenia, które można wyciągnąć. Ogólne klienty S3 na Maca, jak Cyberduck albo Transmit, tę lukę wypełniają, tylko nie wiedzą nic o Civo, więc wpisujesz endpoint, wklejasz oba klucze per store i pilnujesz ich ręcznie przy każdej rotacji poświadczeń.

Ścieżka aplikacji: żadnego endpointu do wpisania

CivoCloudManager uwierzytelnia się raz twoim kluczem API Civo i czyta listę Object Stores z Civo REST API v2, które już niesie endpoint i podpięte poświadczenie dla każdego store'a. Z tego buduje klienta S3, więc nie ma pola na endpoint, nie ma wklejania kluczy i nie ma pliku konfiguracyjnego. Warstwa S3 to czysty Swift: AWS Signature V4 liczone przez CryptoKit HMAC-SHA256, bez SDK AWS i bez Electrona. Robi ListObjects v2 z tokenami kontynuacji, nawigację po okruszkach na wspólnych prefiksach, wielokrotne zaznaczenie i rekurencyjne pobieranie folderu z paskiem postępu. Uczciwie o kształcie tego: przeglądarka czyta i pobiera. Wysyłanie i kasowanie zostaje przy s3cmd albo rclone. Aplikacja wymaga macOS 15 lub nowszego.

Klucze dostępu za Touch ID zamiast w pliku konfiguracyjnym

To ta część, dla której instalacja ma sens nawet wtedy, gdy zostajesz przy CLI. Działający setup s3cmd oznacza, że klucz tajny leży w ~/.s3cfg czystym tekstem, i tak samo jest z rclone.conf oraz ~/.aws/credentials. Każdy proces działający na twoim użytkowniku przeczyta wszystkie trzy, i tak samo wszystko, co przejdzie przez katalog domowy. CivoCloudManager trzyma klucz API Civo w macOS Keychain, a odsłonięcie klucza tajnego do Object Store wymaga najpierw Touch ID albo hasła systemowego. Ograniczenie jest oczywiste i warto je powiedzieć: w chwili, gdy skopiujesz klucz do terminala, znów jest plikiem tekstowym.

Wstrzymaj i Wznów dla store'ów, których nie używasz

Nieaktywny store i tak płaci za przydzielony rozmiar. „Wstrzymaj” kopiuje każdy obiekt do centralnego Object Store o nazwie civo-cloud-manager, powiększając wcześniej ten vault, jeśli dane się nie mieszczą, porównuje skopiowane klucze i rozmiary ze źródłem i dopiero przy zgodności kasuje oryginalny store. Pozycja znika z rachunku Civo. „Wznów” tworzy store ponownie pod tą samą nazwą i z tym samym poświadczeniem, kopiuje obiekty z powrotem, znów weryfikuje klucze i rozmiary, a potem czyści vault. Jednocześnie idą maksymalnie cztery obiekty. Uczciwe ograniczenia: weryfikacja porównuje nazwy i rozmiary, a nie skróty zawartości, transfery buforują całe obiekty w pamięci, a zdalny manifest powstaje po skasowaniu źródła, z lokalnym manifestem jako zapasem.

Który klient do której roboty

Cała czwórka rozmawia z tym samym API S3 na tym samym endpoincie. Różnica jest w tym, gdzie leży konfiguracja, gdzie ląduje klucz tajny i co widzisz.

Zadanie	s3cmd	rclone	AWS CLI	CivoCloudManager
Konfiguracja endpointu	host_base i host_bucket w ~/.s3cfg	endpoint w remote	--endpoint-url przy każdym wywołaniu	czytany z Civo API
Gdzie ląduje klucz tajny	~/.s3cfg, czystym tekstem	rclone.conf, czystym tekstem	~/.aws/credentials, czystym tekstem	macOS Keychain, odsłonięcie przez Touch ID
Wizualne przeglądanie store'a	nie	rclone ncdu, tryb tekstowy	nie	tak, przeglądarka z okruszkami
Wysyłanie i kasowanie obiektów	tak	tak	tak	nie w przeglądarce
Rekurencyjne pobieranie folderu	s3cmd get -r	rclone copy	aws s3 cp --recursive	tak, z postępem
Wstrzymanie nieaktywnego store'a, żeby przestać płacić	nie	nie	nie	tak, vault z weryfikacją przed kasowaniem
Działa w CI	tak	tak	tak	nie, to aplikacja na Maca

Civo Object Storage przez S3, odpowiedzi

Jaki jest adres endpointu Civo Object Storage?

Endpointy Civo Object Store idą według wzoru https://objectstore.<region>.civo.com z kodem regionu małymi literami, na przykład https://objectstore.lon1.civo.com w Londynie albo https://objectstore.fra1.civo.com we Frankfurcie. Endpoint zależy od regionu, w którym store powstał. Każdy store pokazuje też własny endpoint w dashboardzie Civo i zwraca go w polu objectstore_endpoint w Civo REST API.

Czy mogę używać s3cmd albo rclone z Civo Object Storage?

Tak, oba działają, tak samo jak AWS CLI i każdy inny klient zgodny z S3. W s3cmd ustaw host_base i host_bucket w ~/.s3cfg na nazwę hosta regionu, na przykład objectstore.fra1.civo.com, i uzupełnij access_key oraz secret_key. W rclone utwórz remote z type = s3, provider = Other, endpoint = https://objectstore.fra1.civo.com i tą samą parą kluczy. W AWS CLI podawaj --endpoint-url https://objectstore.fra1.civo.com przy każdej komendzie.

Dlaczego mój klucz dostępu do Civo Object Storage nie działa?

Zwykle winny jest region. Civo pisze, że Object Stores są przypisane do regionu, a poświadczenia są związane z regionem, w którym powstały, więc klucz utworzony w FRA1 nie uwierzytelni się w endpoincie LON1, choć należy do tego samego konta. Utwórz poświadczenie, mając dashboard ustawiony na region store'a. Druga częsta przyczyna to klient, który nigdy nie dostał endpointu, albo host_bucket w s3cmd zostawiony na wartości domyślnej, przez co żądanie idzie do Amazona zamiast do Civo.

Czy jest GUI do Civo Object Storage na Maca?

CivoCloudManager to natywna aplikacja macOS, macOS 15 lub nowszy, z Mac App Store, i zna Civo: czyta endpoint i klucze dostępu każdego store'a z Civo API, więc nie ma czego konfigurować. Przegląda z okruszkami i pobiera pojedyncze pliki, wielokrotne zaznaczenie albo cały folder rekurencyjnie, a wysyłanie i kasowanie zostaje przy CLI. Ogólne klienty S3, jak Cyberduck albo Transmit, też połączą się z Civo, gdy wpiszesz endpoint i wkleisz oba klucze per store.

Co „Wstrzymaj” robi z moimi danymi w Civo Object Store?

„Wstrzymaj” kopiuje każdy obiekt do centralnego Object Store o nazwie civo-cloud-manager wewnątrz twojego własnego konta Civo, porównuje skopiowane klucze i rozmiary ze źródłem i dopiero potem kasuje oryginalny store, żeby przestał kosztować. „Wznów” tworzy store ponownie pod tą samą nazwą i z tym samym poświadczeniem, kopiuje obiekty z powrotem i znów weryfikuje klucze i rozmiary, zanim wyczyści vault. Dane nigdy nie opuszczają twojego konta Civo, a weryfikacja idzie po nazwie i rozmiarze, nie po skrócie zawartości.

Poradniki

Krok po kroku, i uczciwe porównania.

Pogłębione materiały

Osobny tekst dla każdego produktu Civo.

Każda powierzchnia Civo, której dotyka CivoCloudManager, ma własną stronę ze szczegółami, kompromisami i architekturą. Wybierz tę, która jest najbliżej twojej codziennej pracy.

Pomiń konfigurowanie endpointu.

CivoCloudManager czyta endpoint i klucze dostępu z twojego własnego konta Civo, więc store po prostu się otwiera, zamiast wymagać pliku konfiguracyjnego. Darmowa wersja w pasku menu, jednorazowy zakup pełnego dashboardu w Mac App Store.

Pobierz z Mac App Store

Wymaga macOS 15 (Sequoia) lub nowszego.

Powrót na stronę główną