RE:NODE

ექსპლუატაცია11 წუთის საკითხავი

S3-ის GUI კლიენტები: Cyberduck, WinSCP და S3 Browser

დააკავშირე Cyberduck, WinSCP და S3 Browser S3-თავსებად endpoint-თან: path-style პარამეტრები, HTTP თუ HTTPS, გასაღებები და შეცდომები, რომლებსაც თითოეული კლიენტი აჩვენებს.

0 მკითხველი

S3-თავსებადი bucket-ის მაუსით დასათვალიერებლად გამოიყენე Cyberduck Windows-ზე ან macOS-ზე, WinSCP ან S3 Browser Windows-ზე, და თითოეულს ერთი და იგივე ოთხი რამ მიეცი: endpoint-ის ჰოსტის სახელი, access key, secret key და path-style მისამართები. ბოლო არის ის, რაც ჩუმად მარცხდება. სამივე კლიენტი ნაგულისხმევად Amazon-ის virtual-hosted სტილს ვარაუდობს, bucket-ის სახელს ჰოსტის სახელში სვამს, შემდეგ კი ბუნდოვან კავშირის შეცდომას ან "cannot read container" შეტყობინებას აჩვენებს. Cyberduck-ში ამას "S3 (Deprecated path style requests)" კავშირის პროფილით ასწორებ; WinSCP-ში URL style-ის Path-ზე დაყენებით; S3 Browser-ში addressing model-ის path style-ზე დაყენებით. ეს პოსტი გაივლის თითოეული კლიენტის ზუსტ პარამეტრებს, რა უნდა გააკეთო ჩვეულებრივი HTTP-ისა და HTTPS-ის შემთხვევაში, და იმ განსხვავებებს, რითაც S3 SFTP-ის საქაღალდეებისგან განსხვავდება, რომლებისთვისაც ეს პროგრამები თავიდან შეიქმნა.

რომელი კლიენტი გამოვიყენო#

კლიენტიპლატფორმებიფასირაში არის კარგი
CyberduckWindows, macOSუფასო (შემოწირულობები)სუფთა ინტერფეისი, სანიშნეები, ბევრ backend-თან მუშაობს
WinSCPWindowsუფასო, ღია კოდითბევრს უკვე დაყენებული აქვს; სკრიპტები; სინქრონიზაცია
S3 BrowserWindowsუფასო პირადი გამოყენებისთვის, ფასიანი ProS3-ის სპეციფიკური ფუნქციები, დეტალური პარამეტრები
Mountain DuckWindows, macOSფასიანიbucket-ს დისკის ასოდ ან ტომად აერთებს
rclone mountWindows, macOS, Linuxუფასო, ღია კოდითდისკი ბრძანების ხაზიდან, სკრიპტები

თუ მხოლოდ დროდადრო გინდა ფაილების შეტანა და გამოტანა გადათრევით, Cyberduck ყველაზე ნაკლებ თავსატეხს გიჩენს და ორივე სისტემაზე ერთნაირად იქცევა. თუ SFTP-ისთვის უკვე WinSCP-ს იყენებ, მასში S3-ის საიტის დამატება ნიშნავს ერთ პროგრამას ყველაფრისთვის. S3 Browser თავის მენიუებში S3 API-ის უფრო მეტ ნაწილს აჩვენებს, ვიდრე დანარჩენი ორი, და Windows-ის მომხმარებლები სწორედ მას მიმართავენ, როცა ობიექტების header-ებისა და მეტამონაცემების შემოწმება სურთ. Mountain Duck (Cyberduck-ის შემქმნელებისგან) და rclone mount bucket-ს დისკის მსგავს რამედ აქცევს, რაც მოსახერხებელია და თან ახლავს შეზღუდვები, რომლებიც ქვემოთ არის განხილული.

პარამეტრები, რომლებიც ყველა კლიენტს სჭირდება#

ნებისმიერი პროგრამის გახსნამდე ეს შეაგროვე:

პარამეტრიმაგალითისაიდან მოდის
Endpoint-ის ჰოსტიs3.example.comჰოსტის სახელი, რომელსაც საცავზე მიმართავ, ან პირდაპირი მისამართი
პორტი443 HTTPS-ისთვისproxy სლოტი, ან ჩვეულებრივი HTTP პორტი პირდაპირი მისამართისთვის
Access key IDAKIA...სერვერისთვის გენერირებული, პანელში ჩანს
Secret access key40 სიმბოლოიმავე ადგილას; მოეპყარი როგორც პაროლს
მისამართებიPath-styleS3-თავსებადი endpoint-ების უმეტესობა ითხოვს
Regionus-east-1ნებისმიერი მნიშვნელობა, თუ პროვაიდერი ნებისმიერს იღებს

RE:NODE-ის S3 საცავზე access key, secret key და პირველი bucket სერვერთან ერთად იქმნება და პანელში ჩანს. endpoint საკუთარ პორტზე ჩვეულებრივ HTTP-ს პასუხობს, გეგმის proxy სლოტი კი HTTPS-ს გაძლევს: მიმართე ჰოსტის სახელი, მაგალითად s3.example.com, ნაჩვენებ მისამართზე, სერტიფიკატი შენთვის გაიცემა და განახლდება, კლიენტები კი 443 პორტზე უკავშირდებიან. ყველა GUI კლიენტში HTTPS-ის სახელი გამოიყენე. ჩვეულებრივი HTTP მუშაობს, მაგრამ შენს ფაილებს და ყველა მოთხოვნას დაუშიფრავად აგზავნის, ამიტომ ის სანდო ქსელში სწრაფი ტესტისთვის დაიტოვე. შენი დომენი და მისი სერტიფიკატი ჰოსტის სახელის მიმართვას განიხილავს.

Cyberduck#

Cyberduck-ს მოყვება "Amazon S3" კავშირის ტიპი, რომელიც AWS-ზეა მორგებული და virtual-hosted მოთხოვნებს იყენებს. path-style endpoint-ისთვის აყენებ კავშირის პროფილს - პატარა ფაილს, რომელიც Cyberduck-ს ეუბნება, როგორ ესაუბროს კონკრეტული ტიპის სერვერს.

  1. გახსენი Preferences, შემდეგ Profiles.
  2. მოძებნე "path style" და მონიშნე S3 (Deprecated path style requests). სიტყვა "deprecated" path-style-ზე Amazon-ის შეხედულებას ეხება; S3-თავსებადი endpoint-ისთვის ეს სწორი არჩევანია.
  3. თუ ტესტისთვის ჩვეულებრივი HTTP გჭირდება, ასევე მონიშნე S3 (HTTP). ნაგულისხმევ სიაში კომბინირებული plain-HTTP path-style პროფილი არ არის, რაც კიდევ ერთი მიზეზია HTTPS-ის ჰოსტის სახელის გამოსაყენებლად.
  4. დააჭირე Open Connection-ს (ან შექმენი სანიშნე) და პროტოკოლის ჩამოსაშლელი სიიდან path-style პროფილი აირჩიე.
  5. შეავსე Server s3.example.com, Port 443 და Access Key ID და Secret Access Key პანელიდან.
  6. დაუკავშირდი. შენი bucket-ები ზედა დონის საქაღალდეებად უნდა გამოჩნდეს.

Cyberduck-ს ასევე აქვს დამალული პარამეტრი, s3.bucket.virtualhost.disable, რომელიც true-ზე დაყენებისას virtual-hosted მოთხოვნებს გლობალურად თიშავს. პროფილი უფრო სუფთა გზაა, რადგან მხოლოდ იმ სანიშნეებზე მოქმედებს, რომლებიც მას იყენებს, ასე რომ შენი AWS-ის სანიშნეები მუშაობას აგრძელებს.

თუ მოცემულ გასაღებს მხოლოდ ერთი bucket-ის დანახვა შეუძლია და ყველას ჩამოთვლა არა, დაუკავშირდი path ველით (კავშირის დიალოგში More Options-ის ქვეშ), დაყენებული /bucket-name-ზე, და Cyberduck პირდაპირ bucket-ში გაიხსნება, ნაცვლად იმისა, რომ ჯერ ყველა bucket-ის ჩამოთვლა სცადოს.

Cyberduck-ის ორი პარამეტრის შეცვლა ღირს დიდი გადაცემებისთვის: Preferences-ში, Transfers-ში, ჩამოტვირთვებისა და ატვირთვებისთვის რამდენიმე კავშირის გამოყენება დააყენე, და თუ ხშირად ტვირთავ დიდ ფაილებს, multipart upload ჩართული დატოვე (ნაგულისხმევად ჩართულია), რომ გაწყვეტილმა კავშირმა ერთი ნაწილი განაგრძოს და არა თავიდან დაიწყოს.

WinSCP#

WinSCP-მ Amazon S3 ფაილის პროტოკოლად დაამატა SFTP-ის, FTP-ისა და WebDAV-ის გვერდით. მისი ნაგულისხმევი პარამეტრებიც virtual-hosted სტილს ვარაუდობს.

  1. Login დიალოგში აირჩიე New Site.
  2. File protocol დააყენე Amazon S3-ზე.
  3. Host name: s3.example.com. Port number: 443.
  4. Access key ID და Secret access key პანელიდან.
  5. დააჭირე Advanced-ს, გადადი Environment-ში, შემდეგ S3-ში, და URL style Virtual Host-იდან Path-ზე შეცვალე. იმავე გვერდზე შეგიძლია ნაგულისხმევი region დააყენო; დატოვე ცარიელი ან გამოიყენე us-east-1, თუ პროვაიდერი კონკრეტულ სახელს არ ითხოვს.
  6. შეინახე საიტი და შედი.

თუ მე-5 ნაბიჯს გამოტოვებ, WinSCP ცდილობს bucket-name.s3.example.com-ის გადაწყვეტას, და შეცდომა ეხება ჰოსტის სახელს, რომლის გადაწყვეტაც შეუძლებელია - რაც ხალხს DNS-ში აძებნინებს პრობლემას, რომელიც სინამდვილეში ერთი ჩამოსაშლელი სიაა.

WinSCP-ის ძლიერი მხარე ყველაფერია, რაც კავშირის გარშემოა. მისი სინქრონიზაციის ფუნქცია (Commands, Synchronize) ლოკალურ საქაღალდეს bucket-ის prefix-ს ადარებს და განსხვავებებს აკოპირებს, იმავე საიტის მართვა კი დაგეგმილი დავალებებისთვის სკრიპტიდანაც შეიძლება winscp.com /script=...-ით. მძიმე დაგეგმილი სამუშაოსთვის სპეციალური ხელსაწყო, მაგალითად rclone, მაინც უკეთესია - ნახე rclone S3 საცავთან - მაგრამ Windows-ის მომხმარებლისთვის, რომელსაც ყოველ ღამე საქაღალდის სკრიპტით ატვირთვა უნდა, WinSCP ხშირად უკვე დაყენებულია.

S3 Browser#

S3 Browser არის Windows-ის კლიენტი, შექმნილი მხოლოდ S3-ისთვის, ამიტომ მისი ანგარიშის დიალოგი უფრო მეტ S3-ის ტერმინს შეიცავს.

  1. Accounts, Add new account.
  2. Account type: S3 Compatible Storage.
  3. REST Endpoint: s3.example.com (:port დაამატე მხოლოდ მაშინ, თუ ის სქემის სტანდარტული პორტი არ არის).
  4. Access Key ID და Secret Access Key პანელიდან.
  5. HTTPS-ის ჰოსტის სახელისთვის მონიშნე Use secure transfer (SSL/TLS). მონიშვნა მოხსენი მხოლოდ პირდაპირი plain-HTTP პორტისთვის.
  6. გახსენი ანგარიშის დამატებითი პარამეტრები და addressing model დააყენე path style-ზე. ხელმოწერის ვერსია დატოვე შემოთავაზებულ უახლესზე (Signature V4).
  7. შეინახე და დაუკავშირდი.

უფასო ვერსია ლიცენზირებულია პირადი გამოყენებისთვის და ზოგ ფუნქციას ზღუდავს, მაგალითად ანგარიშების რაოდენობას; Pro ვერსია ამ შეზღუდვებს ხსნის და კომერციული გამოყენებისთვის აუცილებელია. პროგრამის ძლიერი მხარე ის არის, რომ გაჩვენებს, რას ინახავს S3 სინამდვილეში: თითოეული ობიექტის HTTP header-ებს, მის მეტამონაცემებს და, სადაც სერვერი ამას უჭერს მხარს, მისი წვდომის პარამეტრებს. როცა სურათი ჩვენების ნაცვლად ჩამოიტვირთება, რადგან binary/octet-stream-ად აიტვირთა, S3 Browser-ში ხედავ ამას და Content-Type-ს ასწორებ.

bucket-ის დისკად მიერთება#

Mountain Duck და rclone mount bucket-ს Windows-ზე დისკის ასოდ, macOS-სა და Linux-ზე კი ტომად აჩენს, ასე რომ ნებისმიერ პროგრამას შეუძლია მასში ფაილების გახსნა. ეს მოსახერხებელია დათვალიერებისა და იშვიათი რედაქტირებისთვის, და ცუდად ერგება ყველაფერს, რაც ბევრს წერს.

bash
$ rclone mount store:media X: --vfs-cache-mode writes

Windows-ზე rclone mount-ს დაყენებული WinFsp სჭირდება; macOS-ზე - macFUSE, ან ბოლო ვერსიებში NFS-ზე დაფუძნებულ მიერთებას იყენებს. --vfs-cache-mode writes ფაილებს ჩაწერის დროს ლოკალურად ინახავს ბუფერში და დახურვისას ტვირთავს, რასაც აპლიკაციების უმეტესობა ელის.

შეზღუდვა სტრუქტურულია. S3-ს ნაწილობრივი ჩაწერა არ აქვს: 2 GB-იანი ფაილის ერთი ბაიტის შეცვლა ნიშნავს მთელი 2 GB-ის თავიდან ატვირთვას. პროგრამა, რომელიც ხშირად ინახავს, ან მონაცემთა ბაზა, ან თამაშის სერვერი, რომელიც თავის სამყაროს წერს, უზარმაზარ ტრაფიკს გამოიწვევს და შეიძლება ფაილები არათანმიმდევრულ მდგომარეობაში დაინახოს. მიერთება გამოიყენე წასაკითხად და ფაილებისთვის, რომლებიც ერთხელ იწერება. დანარჩენისთვის ფაილები ცალსახად დააკოპირე.

რით განსხვავდება S3 იმ დისკისგან, რასაც მიჩვეული ხარ#

GUI კლიენტები კარგად ახერხებენ, რომ bucket საქაღალდეების ხედ აჩვენონ, მაგრამ ილუზია რამდენიმე პროგნოზირებად ადგილას ირღვევა.

საქაღალდეები რეალური არ არის. გასაღები ერთი სტრიქონია - photos/2026/october/cat.jpg - და კლიენტი საქაღალდეებს /-ით დაყოფით ხატავს. GUI კლიენტში ცარიელი საქაღალდის შექმნა ჩვეულებრივ ტვირთავს ცარიელ ჩანაცვლების ობიექტს სახელად photos/2026/, რომ საქაღალდეს რამე ჰქონდეს საჩვენებელი. სხვა ხელსაწყოებმა შეიძლება ასეთი ჩანაცვლებები არ შექმნან და არ ელოდნენ, ამიტომ ერთ კლიენტში შექმნილი საქაღალდე მეორეში შეიძლება სხვანაირად გამოიყურებოდეს, საქაღალდეში ბოლო ფაილის წაშლამ კი შეიძლება საქაღალდე გააქროს.

სახელის გადარქმევა კოპირებაა. S3-ს სახელის გადარქმევა არ აქვს. ფაილის სახელის გადარქმევა არის სერვერის მხარეს კოპირება ახალ გასაღებზე და ძველის წაშლა; საქაღალდის სახელის გადარქმევა კი ეს ოპერაციაა მის ქვეშ მყოფი ყველა ობიექტისთვის. ათი ათასი ფაილის მქონე საქაღალდისთვის "გადარქმევა" ოცი ათასი მოთხოვნაა და დროს მოითხოვს.

რედაქტირება ჩანაცვლებაა. ფაილის "ადგილზე" გახსნა მას დროებით ადგილას ჩამოტვირთავს; შენახვა კი მთლიანად ტვირთავს ახალ ობიექტად. ნაწილობრივი განახლება არ არსებობს, რის გამოც S3-ზე დიდი ფაილების რედაქტირება ნელია.

დროის ნიშნულები ატვირთვის დროებია. S3-ის Last-Modified არის დრო, როცა ობიექტი bucket-ში ჩაიწერა, და არა როცა ფაილი ბოლოს შეიცვალა შენს კომპიუტერზე. ზოგი კლიენტი ცვლილების თავდაპირველ დროს მეტამონაცემებში ინახავს და მას აჩვენებს; ზოგი - არა. GUI კლიენტის თარიღებით ნუ გადაწყვეტ, ფაილის რომელი ასლია უფრო ახალი.

გაუქმება არ არსებობს. ვერსიების გარეშე საცავს სანაგვე ყუთი არ აქვს. წაშლილი ობიექტი გაქრა. ამის დამახსოვრება ღირს, სანამ საქაღალდეს ფანჯრის არასწორ მხარეს გადაათრევ, და ეს არის მიზეზი, რის გამოც bucket, რომელსაც ხელით იყენებ, არაფრის ერთადერთი ასლი არ უნდა იყოს.

პრობლემების მოგვარება#

შეტყობინებაკლიენტიმიზეზიგამოსწორება
"Cannot read container configuration"Cyberduckvirtual-hosted პროფილი path-style endpoint-ზეგამოიყენე path-style პროფილი
ჰოსტის სახელი ვერ გადაწყდა, ნახსენებია bucket.s3...WinSCP, სხვებიvirtual-hosted URL სტილიURL style დააყენე Path-ზე
"The request signature we calculated does not match"ნებისმიერიარასწორი secret, ან proxy, რომელიც Host header-ს ცვლისთავიდან დააკოპირე secret; შეამოწმე proxy
"The AWS Access Key Id you provided does not exist"ნებისმიერიკლიენტი Amazon-ს ესაუბრება და არა შენს endpoint-სშეამოწმე server ველი
SSL handshake ან "wrong version number"ნებისმიერიHTTPS ჩვეულებრივ HTTP პორტზე, ან პირიქითსქემა პორტს შეუსაბამე
სერტიფიკატის სახელის შეუსაბამობანებისმიერიIP-ით დაკავშირება, ან virtual-hosted სტილიგამოიყენე ჰოსტის სახელი path-style-ით
bucket-ების ჩამოთვლაზე წვდომა აკრძალულიანებისმიერიგასაღები ერთ bucket-ზეა შეზღუდულიbucket-ის გზა პირდაპირ გახსენი

ბოლოსწინა წყვილის აღრევა ადვილია. "Wrong version number" ნიშნავს, რომ კლიენტი TLS-ით ესაუბრა პორტს, რომელიც ჩვეულებრივ HTTP-ს პასუხობს (ან პირიქით); სერტიფიკატის შეუსაბამობა ნიშნავს, რომ TLS იმუშავა, მაგრამ სერტიფიკატზე მითითებული სახელი არ ემთხვევა იმას, რაც კლიენტმა მოითხოვა. პირველი სქემისა და პორტის პრობლემაა, მეორე - ჰოსტის სახელის. Path-style და virtual-hosted URL-ები ხსნის, რატომ ამტვრევს სერტიფიკატებს bucket-ის სახელი ჰოსტის სახელში.

როცა არაფერს აქვს აზრი, იგივე გასაღებები AWS CLI-ით გამოსცადე. თუ aws s3 ls იმავე endpoint-ითა და გასაღებებით მუშაობს, სერვერი წესრიგშია და პრობლემა GUI კლიენტის პარამეტრებშია; S3 საცავი AWS CLI-ით დაყენებას შეიცავს.

გასაღებები საერთო ან სამსახურის კომპიუტერზე#

GUI კლიენტი secret key-ს ინახავს, რომ ყოველ ჯერზე აკრეფა არ მოგიწიოს. Cyberduck მას სისტემის keychain-ში ინახავს (macOS Keychain ან Windows Credential Manager), WinSCP - თავის კონფიგურაციაში, თუ master password-ს არ დააყენებ, S3 Browser კი - ანგარიშის პარამეტრებში. კომპიუტერზე, რომელსაც სხვებიც იყენებენ, დააყენე WinSCP-ის master password, საერთოდ ნუ შეინახავ secret-ს, ან გამოიყენე გასაღები, რომელიც გენერირებულია bucket-ისთვის, სადაც არაფერი მგრძნობიარე არ ინახება. თუ ლეპტოპი შენახული გასაღებებით დაიკარგა, იმავე დღეს პანელში გასაღებები თავიდან დააგენერირე - ეს ერთი ნაბიჯით აუქმებს ლეპტოპზე არსებულ ასლს და ყველა სხვა ასლს.

FAQ#

არსებობს S3-ის კლიენტი Linux-ისთვის GUI-ით?

Cyberduck-ს Linux-ის ვერსია არ აქვს. Linux-ზე ჩვეულებრივი არჩევანია ფაილების მენეჯერი rclone mount-ის თავზე, ან rclone-ის ექსპერიმენტული ვებ-ინტერფეისი, რომელიც rclone rcd --rc-web-gui-ით ეშვება. Linux-ის მომხმარებლების უმეტესობა საბოლოოდ ბრძანების ხაზზე rclone-ს ანიჭებს უპირატესობას.

შეიძლება FileZilla-ს გამოყენება S3-ისთვის?

S3-ს მხარს მხოლოდ FileZilla Pro, ფასიანი ვერსია, უჭერს; უფასო FileZilla კლიენტი - არა. თუ უკვე იხდი მასში, პროტოკოლი დააყენე S3-ზე, endpoint კი შენს ჰოსტის სახელზე, და S3-ის პარამეტრებში მოძებნე მისი path-style ვარიანტი.

რატომ ვხედავ საქაღალდეების მსგავსად დასახელებულ ცარიელ ფაილებს?

ეს საქაღალდეების ჩანაცვლებებია, რომლებსაც ზოგი კლიენტი ქმნის, რომ ცარიელი საქაღალდე იარსებოს საცავში, სადაც რეალური საქაღალდეები არ არის. ისინი უვნებელია, თითოეული ნული ბაიტია, და შეგიძლია უსაფრთხოდ დატოვო.

შეიძლება ფაილის საჯაროდ გახდომა GUI კლიენტიდან?

ზოგ კლიენტს აქვს "make public" ან უფლებების ვარიანტი, რომელიც ობიექტის ACL-ს აყენებს. აკეთებს თუ არა ეს რამეს, დამოკიდებულია იმაზე, რას უჭერს მხარს საცავის სერვერი, ამიტომ ნუ დაეყრდნობი. ფაილის გასაზიარებლად ამის ნაცვლად დროში შეზღუდული ბმული შექმენი - Cyberduck-საც და S3 Browser-საც შეუძლიათ presigned URL-ების შექმნა, presigned URL-ები კი ხსნის, როგორ მუშაობს ისინი.

რატომ არის ატვირთვა ნელი SFTP-სთან შედარებით?

ჩვეულებრივი მიზეზი ბევრი პატარა ფაილია: თითოეული ობიექტი ცალკე HTTP მოთხოვნაა საკუთარი ხელმოწერით და ორმხრივი გზით. კლიენტის პარამეტრებში პარალელური გადაცემების რაოდენობა გაზარდე, ან ატვირთვამდე პაწაწინა ფაილების საქაღალდეები zip-ში შეკუმშე.


კომენტარები

სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.

0/2000