Изпълнение на командите docker pull и docker push без docker клиент чрез HTTP заявки

Имахме 2 чувала трева, 75 хапчета мескалин в unix среда, docker репозиторий и задача да реализираме команди docker pull и docker push без docker клиент.

UPD:
Въпрос: За какво е всичко това?
Отговор: Натоварващо тестване на продукта (НЕ с помощта на bash, скриптовете са представени за образователни цели). Решихме да не използваме docker клиент, за да намалим допълнителните слоеве (в разумни граници) и съответно да емулираме по-високо натоварване. В резултат на това премахнахме всички системни забавяния на docker клиента. Получихме сравнително чисто натоварване директно на продукта.
В статията бяха използвани инструменти от версиите на GNU.

Първо, нека разберем какво правят тези команди.

И така, за какво се използва docker pull? Според документацията:

"Pull an image or a repository from a registry".

Там намираме и линк към understand images, containers, and storage drivers.

Оттук можем да разберем, че docker image е набор от слоеве, които съдържат информация за последните изменения в имиджа, които очевидно са ни нужни. Разглеждаме registry API.

Тук се казва следното:

"An “image” is a combination of a JSON manifest and individual layer files. The process of pulling an > image centers around retrieving these two components."

И така, първата стъпка според документацията е “Pulling an Image Manifest".

Разбира се, няма да го пулнем, но данните от него са ни нужни. По-долу даваме пример на заявка: GET /v2/{name}/manifests/{reference}

"The name and reference parameter identify the image and are required. The reference may include a tag or digest."

Нашият docker репозиторий е разположен локално, да опитаме да изпълним заявката:

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}"

“Access to a layer will be gated by the name of the repository but is identified uniquely in the registry by digest.”

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

т.е. слоевете представляват 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 — docker push

Тук ще бъде малко по-сложно.

Ще започнем отново с документацията. И така, трябва да качим всеки слой, да съберем съответния манифест и да го качим също. Изглежда просто.

След като изучихме документацията, можем да разделим процеса на качване на няколко стъпки:

• Инициализация на процеса — "POST \/v2\/{repoName}\/blobs\/uploads\/
• Качване на слой (ще използваме монолитно качване, т.е. всеки слой изпращаме цял) — "PUT \/v2\/{repoName}\/blobs\/uploads\/{uuid}?digest={digest}
  Content-Length: {size of layer}
  Content-Type: application\/octet-stream
  Layer Binary Data".
• Качване на манифест — "PUT \/v2\/{repoName}\/manifests\/{reference}".

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

"PATCH \/v2\/{repoName}\/blobs\/uploads\/{uuid}
Content-Length: {size of chunk}
Content-Type: application\/octet-stream
{Layer Chunk Binary Data}".

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

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

• Инициализация
• PATCH на слоя
• Качване на слоя
• Качване на манифест
  Стъпки 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/[36m$configSize[0m/g; s/config_hash/[36m$configName[0m/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:
Какви резултати получихме?
На първо място, реални данни за анализ, тъй като тестовете се изпълняват в blazemeter и данните от заявките на клиента на docker са доста неинформативни в сравнение с чистите HTTP заявки.

На второ място, преходът ни позволи да увеличим броя на виртуалните потребители за docker upload с около 150% и получихме avg response time, който е с 20-25% по-бърз. При docker download успяхме да увеличим броя на потребителите с 500%, като същевременно avg response time намаля с около 60%.

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

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