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

Имахме 2 торби трева, 75 таблетки мескалин, среда на Unix, Docker хранилище и задача да реализираме командите docker pull и docker push без Docker клиента.

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

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

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

"Изтегляне на изображение или хранилище от регистър".

Там намираме и връзка към разбиране на изображения, контейнери и драйвери за съхранение..

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

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

"Едно 'изображение' е комбинация от JSON манифест и индивидуални файлове на слоеве. Процесът на изтегляне на едно изображение се съсредоточава върху извличането на тези два компонента."

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

Няма да го изтегляме, но информацията от него ни е необходима. Следва пример за заявка: GET /v2/{name}/manifests/{reference}

"Параметрите name и reference идентифицират изображението и са задължителни. Параметърът reference може да включва маркер или хеш."

Нашето 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}".

„Достъпът до един слой ще бъде ограничен от името на хранилището, но уникално се идентифицира в регистъра по хеш.“

Хешът в случая е хешът, който получихме.

Опитваме

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\/\$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:
Какво получихме в резултат?
Първо, реални данни за анализ, тъй като тестовете се изпълняват в blazemeter и данните от заявките на docker клиента са доста неинформативни в сравнение с чистите HTTP заявки.

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

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

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