Docker pull და docker push ბრძანებების განხორციელება დოკერ კლიენტის გარეშე HTTP მოთხოვნების გამოყენებით

ჩვენ გვქონდა 2 ტომარა ბალახი, 75 მესკალინის ტაბლეტი unix გარემო, დოკერის საცავი და დოკერის ზიდვისა და დოკერ პუშის ბრძანებების განხორციელების დავალება დოკერ კლიენტის გარეშე.

UPD:
კითხვა: რისთვის არის ეს ყველაფერი?
პასუხი: პროდუქტის დატვირთვის ტესტირება (არ გამოიყენება bash, სკრიპტები მოწოდებულია საგანმანათლებლო მიზნებისთვის). გადაწყდა, რომ არ გამოეყენებინა დოკერ კლიენტი დამატებითი ფენების შესამცირებლად (გონივრული ლიმიტების ფარგლებში) და, შესაბამისად, უფრო მაღალი დატვირთვის ემულაცია. შედეგად, Docker კლიენტის სისტემის ყველა შეფერხება მოიხსნა. შედარებით სუფთა დატვირთვა მივიღეთ პირდაპირ პროდუქტზე.
სტატიაში გამოყენებული იყო ინსტრუმენტების GNU ვერსიები.

პირველი, მოდით გაერკვნენ, რას აკეთებენ ეს ბრძანებები.

მაშ, რისთვის გამოიყენება docker pull? Მიხედვით დოკუმენტაცია:

"გამოიღეთ სურათი ან საცავი რეესტრიდან".

იქ ჩვენ ასევე ვპოულობთ ბმულს სურათების, კონტეინერების და შენახვის დრაივერების გაგება.

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

მასში ნათქვამია შემდეგი:

"სურათი" არის JSON მანიფესტის და ცალკეული ფენის ფაილების კომბინაცია. > სურათის ამოღების პროცესი ორიენტირებულია ამ ორი კომპონენტის მოძიებაზე."

ასე რომ, პირველი ნაბიჯი დოკუმენტაციის მიხედვით არის ”გამოსახულების მანიფესტის გაყვანა".

რა თქმა უნდა, ჩვენ არ გადავიღებთ მას, მაგრამ ჩვენ გვჭირდება მონაცემები. შემდეგი არის მოთხოვნის მაგალითი: GET /v2/{name}/manifests/{reference}

"სახელი და მითითების პარამეტრი იდენტიფიცირებს სურათს და აუცილებელია. მითითება შეიძლება შეიცავდეს ტეგს ან დაიჯესტს."

ჩვენი დოკერის საცავი განლაგებულია ადგილობრივად, შევეცადოთ შეასრულოთ მოთხოვნა:

curl -s -X GET "http://localhost:8081/link/to/docker/registry/v2/centos-11-10/manifests/1.1.1" -H "header_if_needed"

ამის საპასუხოდ, ჩვენ ვიღებთ json-ს, საიდანაც ამჟამად მხოლოდ სიცოცხლის ხაზი გვაინტერესებს, უფრო სწორად მათი ჰეშები. მათი მიღების შემდეგ, ჩვენ შეგვიძლია გადავხედოთ თითოეულს და შევასრულოთ შემდეგი მოთხოვნა: "GET /v2/{name}/blobs/{digest}"

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

დაიჯესტი ამ შემთხვევაში არის ჰეში, რომელიც მივიღეთ.

ცდილობს

curl -s -X GET "http://localhost:8081/link/to/docker/registry/v2/centos-11-10/blobs/sha256:f972d139738dfcd1519fd2461815651336ee25a8b54c358834c50af094bb262f" -H "header_if_needed" --output firstLayer

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

file firstLayer

იმათ. რელსები არის ტარის არქივები, მათი შესაბამისი თანმიმდევრობით გახსნით მივიღებთ სურათის შინაარსს.

მოდით დავწეროთ პატარა ბაშის სკრიპტი, რათა ეს ყველაფერი ავტომატიზირებული იყოს

#!/bin/bash -eu

downloadDir=$1
# url as http://localhost:8081/link/to/docker/registry
url=$2
imageName=$3
tag=$4

# array of layers
layers=($(curl -s -X GET "$url/v2/$imageName/manifests/$tag" | grep -oP '(?<=blobSum" : ").+(?=")'))

# download each layer from array
for layer in "${layers[@]}"; do
    echo "Downloading ${layer}"
    curl -v -X GET "$url/v2/$imageName/blobs/$layer" --output "$downloadDir/$layer.tar"
done

# find all layers, untar them and remove source .tar files
cd "$downloadDir" && find . -name "sha256:*" -exec tar xvf {} ;
rm sha256:*.tar
exit 0

ახლა შეგვიძლია მისი გაშვება სასურველი პარამეტრებით და მივიღოთ საჭირო სურათის შინაარსი

./script.sh dirName “http://localhost:8081/link/to/docker/registry” myAwesomeImage 1.0

ნაწილი 2 - დოკერ ბიძგი

ეს ცოტა უფრო რთული იქნება.

დავიწყოთ თავიდან დოკუმენტაცია. ამიტომ, ჩვენ უნდა გადმოვწეროთ თითოეული ლიდერი, შევაგროვოთ შესაბამისი მანიფესტი და ისიც გადმოვწეროთ. როგორც ჩანს მარტივია.

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

• პროცესის ინიციალიზაცია - "POST /v2/{repoName}/blobs/uploads/"
• სამაშველო ხაზის ატვირთვა (ჩვენ გამოვიყენებთ მონოლითურ ატვირთვას, ანუ ვაგზავნით თითოეულ მაშველ ხაზს მთლიანად) - "PUT /v2/{repoName}/blobs/uploads/{uuid}?digest={digest}
  შინაარსი-სიგრძე: {ფენის ზომა}
  შინაარსი-ტიპი: აპლიკაცია/ოქტეტი-ნაკადი
  ფენის ორობითი მონაცემები".
• იტვირთება manifest - "PUT /v2/{repoName}/manifests/{reference}".

მაგრამ დოკუმენტაციას გამოტოვებს ერთი ნაბიჯი, რომლის გარეშეც არაფერი იმუშავებს. მონოლითური დატვირთვისთვის, ასევე ნაწილობრივი (დაქუცმაცებული), ლიანდაგის ჩატვირთვამდე, თქვენ უნდა შეასრულოთ PATCH მოთხოვნა:

"PATCH /v2/{repoName}/blobs/uploads/{uuid}
შინაარსი-სიგრძე: {ნაწილის ზომა}
შინაარსი-ტიპი: აპლიკაცია/ოქტეტი-ნაკადი
{Layer Chunk Binary Data}".

წინააღმდეგ შემთხვევაში, პირველ პუნქტს ვერ გადახვალთ, რადგან... მოსალოდნელი საპასუხო კოდი 202-ის ნაცვლად, თქვენ მიიღებთ 4xx-ს.

ახლა ალგორითმი ასე გამოიყურება:

• ინიციალიზაცია
• პატჩი სარკინიგზო
• მოაჯირის ჩატვირთვა
• მანიფესტის ჩატვირთვა
  2 და 3 პუნქტები, შესაბამისად, განმეორდება იმდენჯერ, რამდენჯერაც საჭიროა ხაზების ჩატვირთვა.

პირველ რიგში, ჩვენ გვჭირდება ნებისმიერი სურათი. მე გამოვიყენებ archlinux: უახლესი

docker pull archlinux

ახლა შევინახოთ იგი ადგილობრივად შემდგომი ანალიზისთვის

docker save c24fe13d37b9 -o savedArch

გახსენით მიღებული არქივი მიმდინარე დირექტორიაში

tar xvf savedArch

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

cat manifest.json | json_pp

Არც ისე ბევრი. ვნახოთ, რა მანიფესტია საჭირო ჩატვირთვის მიხედვით დოკუმენტაცია.

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

ჩვენ ყოველთვის გვექნება მინიმუმ ერთი კონფიგურაციის ფაილი და სიცოცხლის ხაზების მასივი. სქემის ვერსია 2 (მიმდინარეობს წერის დროს), mediaType უცვლელი დარჩება:

echo ‘{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "config": {
      "mediaType": "application/vnd.docker.container.image.v1+json",
      "size": config_size,
      "digest": "config_hash"
   },
   "layers": [
      ’ > manifest.json

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

{
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "size": ${layersSizes[$i]},
         "digest": "sha256:${layersNames[$i]}"
      },

ჩვენ მას დავამატებთ მანიფესტს თითოეული რელსისთვის.

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

sed -i "s/config_size/$configSize/g; s/config_hash/$configName/g" $manifestFile

ახლა თქვენ შეგიძლიათ დაიწყოთ ჩამოტვირთვის პროცესი და შეინახოთ uuid, რომელიც უნდა ახლდეს ყველა შემდგომ მოთხოვნას.

სრული სკრიპტი ასე გამოიყურება:

#!/bin/bash -eux

imageDir=$1
# url as http://localhost:8081/link/to/docker/registry
url=$2
repoName=$3
tag=$4
manifestFile=$(readlink -f ${imageDir}/manifestCopy)
configFile=$(readlink -f $(find $imageDir -name "*.json" ! -name "manifest.json"))

# calc layers sha 256 sum, rename them accordingly, and add info about each to manifest file
function prepareLayersForUpload() {
  info_file=$imageDir/info
  # lets calculate layers sha256 and use it as layers names further
  layersNames=($(find $imageDir -name "layer.tar" -exec shasum -a 256 {} ; | cut -d" " -f1))

  # rename layers according to shasums. !!!Set required amount of fields for cut command!!!
  # this part definitely can be done easier but i didn't found another way, sry
  find $imageDir -name "layer.tar" -exec bash -c 'mv {} "$(echo {} | cut -d"/" -f1,2)/$(shasum -a 256 {} | cut -d" " -f1)"' ;

  layersSizes=($(find $imageDir -name "*.tar" -exec ls -l {} ; | awk '{print $5}'))

  for i in "${!layersNames[@]}"; do
    echo "{
         "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
         "size": ${layersSizes[$i]},
         "digest": "sha256:${layersNames[$i]}"
      }," >> $manifestFile
  done
  # remove last ','
  truncate -s-2 $manifestFile
  # add closing brakets to keep json consistent
  printf "nt]n}" >> $manifestFile
}

# calc config sha 256 sum and add info about it to manifest
function setConfigProps() {
  configSize=$(ls -l $configFile | awk '{print $5}')
  configName=$(basename $configFile | cut -d"." -f1)

  sed -i "s/config_size/$configSize/g; s/config_hash/$configName/g" $manifestFile
}

#prepare manifest file
prepareLayersForUpload
setConfigProps
cat $manifestFile

# initiate upload and get uuid
uuid=$(curl -s -X POST -I "$url/v2/$repoName/blobs/uploads/" | grep -oP "(?<=Docker-Upload-Uuid: ).+")

# patch layers
# in data-binary we're getting absolute path to layer file
for l in "${!layersNames[@]}"; do
  pathToLayer=$(find $imageDir -name ${layersNames[$l]} -exec readlink -f {} ;)
    curl -v -X PATCH "$url/v2/$repoName/blobs/uploads/$uuid" 
  -H "Content-Length: ${layersSizes[$i]}" 
  -H "Content-Type: application/octet-stream" 
  --data-binary "@$pathToLayer"

# put layer
  curl -v -X PUT "$url/v2/$repoName/blobs/uploads/$uuid?digest=sha256:${layersNames[$i]}" 
  -H 'Content-Type: application/octet-stream' 
  -H "Content-Length: ${layersSizes[$i]}" 
  --data-binary "@$pathToLayer"
done

# patch and put config after all layers
curl -v -X PATCH "$url/v2/$repoName/blobs/uploads/$uuid" 
  -H "Content-Length: $configSize" 
  -H "Content-Type: application/octet-stream" 
  --data-binary "@$configFile"

  curl -v -X PUT "$url/v2/$repoName/blobs/uploads/$uuid?digest=sha256:$configName" 
  -H 'Content-Type: application/octet-stream' 
  -H "Content-Length: $configSize" 
  --data-binary "@$configFile"

# put manifest
curl -v -X PUT "$url/v2/$repoName/manifests/$tag" 
  -H 'Content-Type: application/vnd.docker.distribution.manifest.v2+json' 
  --data-binary "@$manifestFile"

exit 0

ჩვენ შეგვიძლია გამოვიყენოთ მზა სკრიპტი:

./uploadImage.sh "~/path/to/saved/image" "http://localhost:8081/link/to/docker/registry" myRepoName 1.0

UPD:
რა მივიღეთ შედეგად?
უპირველეს ყოვლისა, რეალური მონაცემები ანალიზისთვის, რადგან ტესტები ტარდება ბლაზემეტრში და მონაცემები დოკერის კლიენტის მოთხოვნებზე არ არის ძალიან ინფორმატიული, განსხვავებით სუფთა HTTP მოთხოვნებისგან.

მეორეც, გარდამავალმა საშუალება მოგვცა გავზარდოთ ვირტუალური მომხმარებლების რაოდენობა დოკერის ატვირთვისთვის დაახლოებით 150%-ით და მივიღოთ საშუალო პასუხის დრო 20-25%-ით უფრო სწრაფად. დოკერის ჩამოტვირთვისთვის ჩვენ შევძელით მომხმარებელთა რაოდენობის 500%-ით გაზრდა, ხოლო საშუალო პასუხის დრო დაახლოებით 60%-ით შემცირდა.

დიდი მადლობა ყურადღებისთვის.

წყარო: www.habr.com