AWS CLI-ის გამოყენება S3-თავსებად საცავთან

AWS CLI ნებისმიერ S3-თავსებად საცავთან მუშაობს, როგორც კი სამ რამეს გაიგებს, რასაც სხვა შემთხვევაში Amazon-ის მიხედვით ვარაუდობს: endpoint-ის URL-ს, რომ bucket გზაში იწერება და არა ჰოსტის სახელში, და რეგიონს, რომლითაც ხელს მოაწერს. ჩაწერე სამივე სახელიან პროფილში და ყოველი aws s3 ბრძანება უცვლელად იმუშავებს - aws s3 ls --profile renode შენს bucket-ებს ჩამოთვლის, aws s3 sync ./backups s3://my-bucket/backups --profile renode საქაღალდის სარკისებურ ასლს აკეთებს. CLI-ის ბოლო ვერსიები ბევრი არა-Amazon სერვერისთვის კიდევ ერთ მოთხოვნას ამატებს: პარამეტრს, რომელიც CLI-ს უკრძალავს checksum header-ების გაგზავნას, რომლებიც სერვერს არ ესმის. ეს პოსტი ყველაფერ ამას აწყობს და შემდეგ ფარავს ბრძანებებს, რომლებსაც რეალურად გამოიყენებ, მნიშვნელოვანი flag-ებით.

დააყენე CLI და შეამოწმე ვერსია#

გამოიყენე AWS CLI-ის მეორე ვერსია. ეს არის თვითკმარი ინსტალერი Windows-ის, macOS-ისა და Linux-ისთვის Amazon-ის დოკუმენტაციიდან და ის შენი სისტემის Python-ზე არ არის დამოკიდებული. Linux დისტრიბუციების პაკეტები ზოგჯერ წლების წინანდელია ან ჯერ კიდევ პირველი ვერსია, ამიტომ შეამოწმე:

$ aws --versionaws-cli/2.27.50 Python/3.13.4 Linux/6.8.0 exe/x86_64.ubuntu.24

2.13-დან მოყოლებული ნებისმიერი ვერსია კონფიგურაციის ფაილში endpoint_url-ს უჭერს მხარს, რაც საკუთარი endpoint-ისთვის პროფილს შესაძლებელს ხდის. მანამდე --endpoint-url ყოველ ბრძანებაზე უნდა გადაგეცა. პირველი ვერსიაც მუშაობს ამ flag-ით, მაგრამ ეს ძველი ხაზია; მასზე ახალი კონფიგურაციის დაწყების მიზეზი არ არსებობს.

Credential-ები, endpoint და path-style ერთ პროფილში#

CLI კითხულობს ორ ფაილს ~/.aws/-ში (Windows-ზე %USERPROFILE%\.aws\): credentials-ს key-ებისთვის და config-ს დანარჩენი ყველაფრისთვის. შექმენი სახელიანი პროფილი, რომ შენი S3-თავსებადი საცავი არასოდეს აირიოს Amazon-ის ანგარიშთან, რომელიც შეიძლება ასევე გქონდეს.

$ aws configure --profile renodeAWS Access Key ID [None]: RNAKEXAMPLE123AWS Secret Access Key [None]: ****************************************Default region name [None]: us-east-1Default output format [None]: json

ეს ჩაწერს key-ებსა და რეგიონს. Endpoint და მისამართის სტილი ~/.aws/config-ის რედაქტირებით დაამატე:

[profile renode]region = us-east-1output = jsonendpoint_url = https://s3.example.comrequest_checksum_calculation = when_requiredresponse_checksum_validation = when_requireds3 =  addressing_style = path

[renode]aws_access_key_id = RNAKEXAMPLE123aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

რისთვის არის თითოეული ხაზი:

• endpoint_url - საცავის საბაზისო URL. თუ HTTPS ჰოსტის სახელი გაქვს, ის გამოიყენე; უბრალო http://host:port endpoint-იც მუშაობს, მაგრამ შენს მონაცემებს დაუშიფრავად აგზავნის.
• region - ნებისმიერი სახელი, რომელსაც სერვერი იღებს. ის ყოველი მოთხოვნის ხელმოწერის ნაწილია, ამიტომ თანმიმდევრული უნდა იყოს. us-east-1 ჩვეული შემავსებელია და თავიდან გაცილებს იმას, რომ CLI bucket-ების შექმნისას location constraint-ს აგზავნიდეს.
• addressing_style = path - bucket-ს URL-ის გზაში სვამს (https://s3.example.com/bucket/key) ქვედომენის (https://bucket.s3.example.com/key) ნაცვლად, რომელსაც სჭირდება wildcard DNS და wildcard სერტიფიკატი, რაც endpoint-ს შეიძლება არ ჰქონდეს. ჩადგმული s3 = ბლოკი შეწეული პარამეტრებით CLI-ის სინტაქსია სერვისისთვის სპეციფიკური ოფციებისთვის.
• request_checksum_calculation და response_checksum_validation - ახსნილია შემდეგ განყოფილებაში.

ყურადღება მიაქციე ასიმეტრიას: config-ში განყოფილება არის [profile renode], credentials-ში კი [renode]. ამაში შეცდომა The config profile (renode) could not be found-ის ყველაზე ხშირი მიზეზია.

RE:NODE-ზე პანელი გაჩვენებს საცავის სერვერისთვის გენერირებულ access key-სა და secret key-ს, და პირველი bucket უკვე არსებობს. Endpoint არის გეგმის მისამართი და პორტი უბრალო HTTP-ით, ან შენი საკუთარი ჰოსტის სახელი HTTPS-ით, როგორც კი A ჩანაწერს გეგმის proxy slot-ზე მიმართავ, რომელიც სერტიფიკატს გასცემს და ანახლებს.

Checksum-ის ცვლილება CLI-ის ახალ ვერსიებში#

2025 წლის იანვარში AWS CLI 2.23.0-მა და იმავე დროს გამოშვებულმა AWS SDK-ებმა ნაგულისხმევი ქცევა შეცვალეს: ატვირთვები ახლა CRC checksum-ს ითვლის და ახალ header-ებში აგზავნის ყოველ მოთხოვნაზე, სადაც ოპერაცია ამას უჭერს მხარს, ხოლო ჩამოტვირთვები checksum-ებს ამოწმებს, როცა სერვერი მათ აბრუნებს. Amazon S3-ს ეს header-ები ესმის. ბევრ S3-თავსებად სერვერს არ ესმოდა, ყოველ შემთხვევაში თავიდან, და შედეგი იყო ჩავარდნილი ატვირთვები შეცდომებით, რომლებიც checksum-ებს საერთოდ არ ახსენებენ - SignatureDoesNotMatch, MissingContentLength, XAmzContentSHA256Mismatch ან ზოგადი InvalidArgument.

ზემოთ მოცემული პროფილის ორი პარამეტრი ძველ ქცევას აბრუნებს - checksum-ები მხოლოდ იქ, სადაც ოპერაცია მათ მოითხოვს:

$ aws configure set request_checksum_calculation when_required --profile renode$ aws configure set response_checksum_validation when_required --profile renode

ან გარემოს ცვლადებად, რომლებიც იმავე shell-ში ყველა SDK-ზე დაფუძნებულ ხელსაწყოზე მოქმედებს:

export AWS_REQUEST_CHECKSUM_CALCULATION=when_requiredexport AWS_RESPONSE_CHECKSUM_VALIDATION=when_required

თუ შენი სერვერი ახალ checksum-ებს სწორად ამუშავებს, ამათი დაყენებით მნიშვნელოვანს არაფერს კარგავ; მთლიანობას მაინც იცავს TLS და Content-MD5 ან payload-ის hash იქ, სადაც სავალდებულოა. თუ CLI-ზე, რომელიც შარშან მუშაობდა, ატვირთვები უცნაური ხელმოწერის შეცდომებით ვარდება, ეს პირველი შესამოწმებელია. იგივე პარამეტრები არსებობს boto3-სა და სხვა SDK-ებში, რომლებსაც ფარავს S3 Node-იდან და Python-იდან.

გარემოს ცვლადები ფაილების ნაცვლად#

კონტეინერებისთვის, CI job-ებისა და ერთჯერადი სკრიპტებისთვის გარემოს ცვლადები ხშირად კონფიგურაციის ფაილებზე მარტივია. CLI კითხულობს:

Path-style მისამართებს CLI-ში საკუთარი გარემოს ცვლადი არ აქვს, ამიტომ შეინახე მინიმალური კონფიგურაციის ფაილი s3 = addressing_style = path ბლოკით მაშინაც, როცა key-ები გარემოდან მოდის. AWS_CONFIG_FILE CLI-ს მიუთითებს კონფიგურაციის ფაილზე ~/.aws/config-ის გარდა სხვა ადგილას, რაც კონტეინერებში მოსახერხებელია.

სხვა endpoint-ზე ერთჯერადი ბრძანებისთვის ბრძანების ხაზზე --endpoint-url https://s3.example.com ყველაფერ დანარჩენს გადაფარავს. როგორ დაიცვა secret key shell-ის ისტორიისა და რეპოზიტორიებისგან, ფარავს გარემოს ცვლადები და საიდუმლოებები.

ყოველდღიური ბრძანებები#

მაღალი დონის aws s3 ბრძანებები multipart upload-ებს, ხელახალ ცდებსა და რეკურსიას შენ მაგივრად აგვარებს.

ზემოთ მოცემული პროფილით ყოველ ბრძანებას --profile renode ემატება, ან shell-ში ერთხელ აკეთებ export AWS_PROFILE=renode-ს.

$ export AWS_PROFILE=renode$ aws s3 ls2026-10-08 09:12:44 my-first-bucket$ aws s3 cp ./world-2026-10-08.tar.gz s3://my-first-bucket/minecraft/upload: ./world-2026-10-08.tar.gz to s3://my-first-bucket/minecraft/world-2026-10-08.tar.gz

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

შემოწმება, რომ ატვირთული ფაილი მართლა იქ არის

ბრძანება, რომელმაც upload: დაბეჭდა და 0 სტატუსით დასრულდა, მართლაც წარმატებული იყო, მაგრამ სკრიპტებმა უნდა გადაამოწმონ და არა ენდონ. ყველაზე იაფი შემოწმება ზომაა: aws s3api head-object აბრუნებს ContentLength-ს, და მისი ლოკალური ფაილის ზომასთან შედარება შეკვეცილ წყაროებს იჭერს - კლასიკური შემთხვევაა dump, რომელიც შუაში ჩავარდა და პატარა, მაგრამ ვალიდურად მოჩვენებითი ფაილი შექმნა. ერთნაწილიანი ატვირთვისთვის ETag ჩვეულებრივ კონტენტის MD5-ია, ამიტომ ლოკალურ ფაილზე md5sum უნდა დაემთხვეს; multipart upload-ისთვის ETag მთავრდება --ით და ნაწილების რაოდენობით და MD5-ს არასოდეს დაემთხვევა, ამიტომ ზომები შეადარე ან ობიექტის გვერდით .sha256 ფაილი შეინახე.

$ stat -c %s world-2026-10-08.tar.gz734003200$ aws s3api head-object --bucket my-first-bucket \    --key minecraft/world-2026-10-08.tar.gz --query ContentLength734003200

ნამდვილი ტესტი მისი სხვაგან ხელახლა ჩამოტვირთვა და გახსნაა - რამდენად ხშირად და როგორ, ფარავს აღდგენის გამოცდა, სანამ დაგჭირდება.

cp სტანდარტული შესასვლელიდან კითხულობს, როცა წყარო --ია, რაც backup-ის დროებითი ფაილის ჩაწერის გარეშე სტრიმინგის საშუალებას გაძლევს:

$ mysqldump --single-transaction app | gzip \    | aws s3 cp - s3://my-first-bucket/db/app-$(date +%F).sql.gz

დაახლოებით 50 GB-ზე დიდი ნაკადებისთვის დაამატე --expected-size ბაიტების მიახლოებითი რაოდენობით, რომ CLI-მ აირჩიოს ნაწილების ზომა, რომელიც 10,000-ნაწილიან ლიმიტში ჩაეტევა. ამის ირგვლივ სრულ job-ს აგებს ბაზის dump-ები S3-ზე განრიგით.

presign ქმნის URL-ს ხელმოწერით query სტრიქონში. ნაგულისხმევი სიცოცხლის ხანგრძლივობა 3,600 წამია, მაქსიმალური კი შვიდი დღე (604,800 წამი). ვისაც URL აქვს, შეუძლია ობიექტი ჩამოტვირთოს, სანამ ვადა არ გაუვა, ამიტომ მას ისე მოეპყარი, როგორც დროში შეზღუდულ პაროლს. ატვირთვის მხარეს, რომლის გენერირებაც CLI-ს არ შეუძლია, ფარავს S3 presigned URL-ები ატვირთვებისთვის.

sync: რას ადარებს და როგორ გავფილტროთ#

aws s3 sync წყაროდან დანიშნულებაზე აკოპირებს ყველაფერს, რაც ახალია ან შეცვლილი - ლოკალურიდან bucket-ში, bucket-იდან ლოკალურში, ან bucket-იდან bucket-ში.

$ aws s3 sync ./backups s3://my-first-bucket/backups --dryrun$ aws s3 sync ./backups s3://my-first-bucket/backups

ის თვლის, რომ ფაილი შეიცვალა, როცა ზომა განსხვავდება ან ლოკალური ცვლილების დრო უფრო ახალია, ვიდრე ობიექტის Last-Modified. შიგთავსს არ ადარებს. ამას ორი flag ცვლის:

• --size-only - ადარებს მხოლოდ ზომას. სასარგებლოა, როცა დროის ნიშნულები არასანდოა, მაგალითად, მას შემდეგ, რაც ფაილები დროის შენარჩუნების გარეშე დაკოპირდა. გამოტოვებს ცვლილებებს, რომლებიც ზომას არ ცვლის.
• --exact-timestamps - ჩამოტვირთვისას ერთნაირი ზომის ფაილებს დროის ნიშნულის ნებისმიერი განსხვავებით შეცვლილად თვლის.

ნაგულისხმევად sync არასოდეს შლის. --delete დანიშნულებიდან შლის ობიექტებს, რომლებიც წყაროში აღარ არსებობს - რაც წყაროზე დაშვებულ შეცდომას დანიშნულებაზე დაშვებულ შეცდომად აქცევს. Sync --delete-ით სარკეა და არა backup. ყოველთვის ჯერ ერთხელ --dryrun-ით გაუშვი და გამოსავალი წაიკითხე.

ფილტრები არის --exclude და --include შაბლონები, რომლებიც თანმიმდევრობით გამოიყენება და მოგვიანებითებს უპირატესობა აქვს:

# მხოლოდ .tar.gz ფაილები$ aws s3 sync ./backups s3://my-first-bucket/backups \    --exclude "*" --include "*.tar.gz"# ყველაფერი ლოგებისა და დროებითი ფაილების გარდა$ aws s3 sync ./site s3://my-first-bucket/site \    --exclude "*.log" --exclude "tmp/*"

Sync საპირისპირო მიმართულებითაც მუშაობს და ასე აღადგენ: aws s3 sync s3://my-first-bucket/backups ./restore ჩამოტვირთავს ყველაფერს, რაც ლოკალურად აკლია ან განსხვავდება. მიმართე ის ცარიელ დირექტორიაზე და არა ცოცხალზე, შეამოწმე, რა ჩამოვიდა, და მხოლოდ ამის შემდეგ გადაიტანე ადგილზე. Bucket-იდან bucket-ში sync იმავე endpoint-ზე (aws s3 sync s3://bucket-a s3://bucket-b) სერვერის მხარის კოპირებას იყენებს, ასე რომ შენს მანქანაზე არაფერი გადის.

შაბლონები წყაროს დირექტორიის მიმართ ფარდობით გზას ედარება. --exclude "*" --include "*.tar.gz" მუშაობს; საპირისპირო თანმიმდევრობა ყველაფერს გამორიცხავს, რადგან მოგვიანებითი --exclude "*" იმარჯვებს.

სიჩქარე, multipart და გამტარუნარიანობა#

CLI 8 MB-ზე დიდ ფაილებს 8 MB-იან ნაწილებად ტვირთავს, ერთდროულად ათი მოთხოვნით. დიდი ფაილებისთვის სწრაფ არხზე უფრო დიდი ნაწილები და მეტი პარალელიზმი გეხმარება; ნელ ან გაზიარებულ არხზე გამტარუნარიანობის ზღვარი ატვირთვას დანარჩენი ყველაფრის დახრჩობისგან იკავებს.

[profile renode]s3 =  addressing_style = path  max_concurrent_requests = 10  multipart_threshold = 64MB  multipart_chunksize = 64MB  max_bandwidth = 20MB/s

max_bandwidth იღებს ბაიტებს წამში სუფიქსით, ასე რომ 20MB/s არის 160 Mbit/s. max_concurrent_requests-ის 20-30-ზე მეტად გაზრდა ერთ პატარა endpoint-თან იშვიათად გეხმარება; ლიმიტი ხდება სერვერი და შენსა და მას შორის არსებული ქსელი. ძალიან დიდი ნაწილები ნიშნავს, რომ ჩავარდნილი ნაწილის ხელახლა ცდას მეტი დრო სჭირდება; 16-64 MB გონივრული დიაპაზონია.

დაბალი დონის ბრძანებები s3api-ით#

aws s3api API ოპერაციებს ერთი-ერთზე შეესაბამება. ის ვრცელია, მაგრამ ყველაფერს ხსნის:

# ერთი ობიექტის მეტამონაცემები: ზომა, ETag, კონტენტის ტიპი, მომხმარებლის მეტამონაცემები$ aws s3api head-object --bucket my-first-bucket --key db/app-2026-10-08.sql.gz# key-ები და ზომები პრეფიქსის ქვეშ, გაფილტრული JMESPath-ით$ aws s3api list-objects-v2 --bucket my-first-bucket --prefix db/ \    --query 'Contents[].[Key,Size]' --output text# მიტოვებული multipart upload-ების პოვნა და გაუქმება$ aws s3api list-multipart-uploads --bucket my-first-bucket$ aws s3api abort-multipart-upload --bucket my-first-bucket \    --key big.tar --upload-id 'EXAMPLEuploadID'

კონტენტის ტიპი ცალსახად დააყენე ფაილების ატვირთვისას, რომლებსაც ბრაუზერი მოითხოვს - aws s3 cp logo.svg s3://bucket/ --content-type image/svg+xml - რადგან გამოცნობილი binary/octet-stream ბრაუზერებს ჩვენების ნაცვლად ჩამოტვირთვას აიძულებს.

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

`Could not connect to the endpoint URL`. არასწორი ჰოსტი, პორტი ან სქემა endpoint_url-ში, ან firewall. სცადე curl -I endpoint-ზე; ნებისმიერი HTTP პასუხი, თუნდაც 403, ამტკიცებს, რომ ქსელის გზა მუშაობს.

`InvalidAccessKeyId`. Access key არასწორია, ან CLI სხვა პროფილს იყენებს, ვიდრე გგონია. aws configure list --profile renode გაჩვენებს, რომელი credential-ები და რეგიონი გამოიყენა და საიდან.

`SignatureDoesNotMatch`. Secret key არასწორია, რეგიონი განსხვავდება იმისგან, რასაც სერვერი ელის, სისტემის საათი წუთებით ცდება, ან - CLI 2.23-ზე და უფრო ახალზე - ზემოთ აღწერილი checksum header-ები. შეამოწმე საათი date-ით, შემდეგ checksum-ის პარამეტრები.

`RequestTimeTooSkewed`. მანქანის საათი სერვერისას ძალიან დაშორდა. გაასწორე დროის სინქრონიზაცია (timedatectl systemd Linux-ზე) და არა რამე CLI-ში.

`AccessDenied` ერთ bucket-ზე და არა მეორეზე. Key-ები სხვა სერვერს ან ანგარიშს ეკუთვნის, ვიდრე bucket, ან bucket-ის სახელი შეცდომით არის დაწერილი - ზოგი სერვერი bucket-ზე, რომელსაც ვერ ხედავ, "not found"-ის ნაცვლად access denied-ით პასუხობს.

`NoSuchBucket` ან DNS შეცდომები `bucket.s3.example.com`-ისთვის. CLI virtual-hosted მისამართებს იყენებს. დაამატე addressing_style = path.

`SSL: CERTIFICATE_VERIFY_FAILED`. იყენებ HTTPS endpoint-ს სერტიფიკატით, რომელსაც CLI არ ენდობა, ან IP მისამართს სერტიფიკატზე, რომელიც სახელისთვის გაიცა. გამოიყენე ჰოსტის სახელი, რომელიც სერტიფიკატზეა. --no-verify-ssl შეცდომას დაცვის მოხსნით აქრობს; სკრიპტებში ნუ დატოვებ.

ყველაფერ დანარჩენზე --debug ბეჭდავს ყოველი მოთხოვნისა და პასუხის header-ს, რაც ზუსტად გაჩვენებს, რას მოეწერა ხელი და რა თქვა სერვერმა.

FAQ#

მჭირდება AWS ანგარიში AWS CLI-ის გამოსაყენებლად?

არა. CLI უბრალოდ კლიენტია. მიმართე ის ნებისმიერ S3-თავსებად endpoint-ზე ამ endpoint-ის key-ებით და ის Amazon-ს არასოდეს დაუკავშირდება.

შემიძლია ერთი პროფილი გამოვიყენო Amazon S3-ისა და სხვა პროვაიდერისთვის?

გამოიყენე ცალკე პროფილები. თითოეულ პროფილს თავისი endpoint, key-ები და მისამართის სტილი აქვს, და --profile ან AWS_PROFILE ერთს ირჩევს. ერთ პროფილში მათი არევა სწორედ ის გზაა, რომლითაც backup-ები არასწორ ადგილას ხვდება.

რატომ ტვირთავს sync ხელახლა ფაილებს, რომლებიც არ შეცვლილა?

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

Sync --delete-ით backup არის?

არა. ის დანიშნულებას წყაროს ამსგავსებს, წაშლებისა და დაზიანების ჩათვლით. ისტორიიანი backup-ებისთვის გამოიყენე ხელსაწყო, რომელიც snapshot-ებს ინახავს, მაგალითად restic - იხილე restic backup-ები S3-ზე - ან rclone backup დირექტორიით შეცვლილი და წაშლილი ფაილებისთვის.

შემიძლია bucket-ებს შორის კოპირება ორ სხვადასხვა პროვაიდერზე?

ერთი ბრძანებით არა. aws s3 cp და sync ერთ გამოძახებაზე ერთ endpoint-ს იყენებს, ამიტომ ერთი პროვაიდერიდან მეორეზე კოპირება ნიშნავს ერთი პროფილით ლოკალურ დირექტორიაში ჩამოტვირთვას და მეორით ატვირთვას. rclone-ს ამის ერთ ნაბიჯში გაკეთება შეუძლია ორ remote-ს შორის სტრიმინგით.

როგორ დავგეგმო ატვირთვები cron-ით?

Cron მინიმალური გარემოთი მუშაობს, ამიტომ job-ს ყველაფერი ცალსახად მიეცი: aws-ის სრული გზა, AWS_PROFILE და HOME (რომ CLI-მ ~/.aws იპოვოს). გამოსავალი ლოგ ფაილში გადაამისამართე და შეამოწმე, რადგან cron job, რომელიც ჩუმად ვარდება, არის backup, რომელიც არ არსებობს.