HTTP 요청을 사용하여 docker 클라이언트 없이 docker pull 및 docker push 명령 구현

우리는 2개의 풀 봉지, 75개의 메스칼린 태블릿 Unix 환경, 도커 저장소, 그리고 도커 클라이언트 없이 도커 풀 및 도커 푸시 명령을 구현하는 작업을 수행했습니다.

UPD :
질문: 이 모든 것은 무엇을 위한 것입니까?
답변: 제품의 부하 테스트(bash를 사용하지 않고 스크립트는 교육 목적으로 제공됨) 추가 레이어를 줄이고(합리적인 한도 내에서) 그에 따라 더 높은 로드를 에뮬레이트하기 위해 Docker 클라이언트를 사용하지 않기로 결정했습니다. 결과적으로 Docker 클라이언트의 모든 시스템 지연이 제거되었습니다. 우리는 제품에 직접 비교적 깨끗한 하중을 받았습니다.
이 기사에서는 GNU 버전의 도구를 사용했습니다.

먼저, 이 명령들이 무엇을 하는지 알아봅시다.

그렇다면 docker pull은 어디에 사용되나요? 에 따르면 선적 서류 비치:

"레지스트리에서 이미지 또는 저장소 가져오기".

거기에는 다음 링크도 있습니다. 이미지, 컨테이너, 스토리지 드라이버 이해.

여기에서 우리는 도커 이미지가 이미지의 최신 변경 사항에 대한 정보를 포함하는 특정 레이어 세트라는 것을 이해할 수 있습니다. 이는 분명히 우리에게 필요한 것입니다. 다음으로 살펴보겠습니다. 레지스트리 API.

그것은 다음과 같이 말합니다 :

""이미지"는 JSON 매니페스트와 개별 레이어 파일의 조합입니다. 이미지를 가져오는 프로세스는 이 두 구성 요소를 검색하는 데 중점을 둡니다."

따라서 문서에 따르면 첫 번째 단계는 “이미지 매니페스트 가져오기".

물론 우리는 그것을 쏘지는 않을 것이지만 그것으로부터 데이터가 필요합니다. 다음은 요청 예시입니다. GET /v2/{name}/manifests/{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부 - 도커 푸시

이것은 조금 더 복잡할 것입니다.

다시 시작하자 선적 서류 비치. 따라서 각 리더를 다운로드하고 해당 매니페스트를 수집한 후 다운로드해야 합니다. 간단한 것 같습니다.

문서를 연구한 후 다운로드 프로세스를 여러 단계로 나눌 수 있습니다.

• 프로세스 초기화 - "POST /v2/{repoName}/blobs/uploads/"
• 라이프라인 업로드(모놀리식 업로드를 사용합니다. 즉, 각 라이프라인을 전체적으로 보냅니다.) - "PUT /v2/{repoName}/blobs/uploads/{uuid}?digest={digest}
  콘텐츠 길이: {레이어 크기}
  콘텐츠 유형: 애플리케이션/옥텟 스트림
  레이어 바이너리 데이터'를 참조하세요.
• 매니페스트 로드 중 - "PUT /v2/{repoName}/manifests/{reference}".

그러나 문서에는 한 단계가 빠져 있으며, 이 단계가 없으면 아무 것도 작동하지 않습니다. 모놀리식 로딩과 부분(청크) 로딩의 경우 레일을 로딩하기 전에 PATCH 요청을 수행해야 합니다.

"패치 /v2/{repoName}/blobs/uploads/{uuid}
콘텐츠 길이: {청크 크기}
콘텐츠 유형: 애플리케이션/옥텟 스트림
{레이어 청크 바이너리 데이터}".

그렇지 않으면 첫 번째 지점을 넘어 이동할 수 없습니다. 왜냐하면... 예상되는 응답 코드 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

UPD :
그 결과 우리는 무엇을 얻었습니까?
첫째, 분석을 위한 실제 데이터입니다. 테스트는 blazemeter에서 실행되고 docker 클라이언트 요청에 대한 데이터는 순수한 HTTP 요청과 달리 그다지 유익하지 않습니다.

둘째, 전환을 통해 Docker 업로드를 위한 가상 사용자 수가 약 150% 증가하고 평균 응답 시간이 20-25% 더 빨라졌습니다. Docker 다운로드의 경우 사용자 수는 500% 증가한 반면 평균 응답 시간은 약 60% 감소했습니다.

관심을 가져 주셔서 감사합니다.

출처 : habr.com