Внедряване на команди за изтегляне и натискане на докер без докер клиент, използващ HTTP заявки

Имахме 2 торби с трева, 75 таблетки мескалин unix среда, хранилище за докери и задачата да внедрим командите за изтегляне и изтегляне на докер без докер клиент.

UPS:
Въпрос: За какво е всичко това?
Отговор: Заредете тестване на продукта (НЕ използвайки 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

тези. lifelines са tar архиви, като ги разопаковаме в съответния ред ще получим съдържанието на изображението.

Нека напишем малък bash скрипт, за да може всичко това да бъде автоматизирано

#!/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}
  Дължина на съдържанието: {размер на слоя}
  Content-Type: приложение/октет-поток
  Слой двоични данни".
• Зареждане на манифеста - "PUT /v2/{repoName}/manifests/{reference}".

Но документацията пропуска една стъпка, без която нищо няма да работи. За монолитно натоварване, както и за частично (на парчета), преди да заредите релсата, трябва да изпълните PATCH заявка:

"КОРЕКЦИЯ /v2/{repoName}/blobs/uploads/{uuid}
Дължина на съдържанието: {size of chunk}
Content-Type: приложение/октет-поток
{Layer Chunk Binary Data}".

В противен случай няма да можете да преминете отвъд първата точка, защото... Вместо очаквания код за отговор 202, ще получите 4xx.

Сега алгоритъмът изглежда така:

• Инициализация
• Релса за кръпка
• Зареждане на парапета
• Зареждане на манифеста
  Точки 2 и 3, съответно, ще бъдат повторени толкова пъти, колкото броя редове трябва да бъдат заредени.

Първо, имаме нужда от всяко изображение. Ще използвам archlinux:latest

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

UPS:
Какво получихме в резултат?
Първо, реални данни за анализ, тъй като тестовете се изпълняват в blazemeter и данните за клиентските заявки на докер не са много информативни, за разлика от чистите HTTP заявки.

Второ, преходът ни позволи да увеличим броя на виртуалните потребители за качване на докери с около 150% и да получим средно време за реакция с 20-25% по-бързо. За изтегляне на docker успяхме да увеличим броя на потребителите с 500%, докато средното време за реакция намаля с около 60%.

Благодаря ви за вниманието.

Източник: www.habr.com