docker-registryのcache機能で速度向上するか試した

こんにちは N.Oです。パワフルなdocker-registryの機能 「Search-engine/Mirroring」についての続編として、今回cache機能を試してみます。

環境

• CentOS Linux release 7.0.1406 (64bit)
• docker-1.3.2-4.el7.centos.x86_64
• docker-registry 0.9.0

cache-options

cache-optionsではtagやmetadataなどの小さいファイルをcacheします。S3をstorageにしてる場合は劇的にスピードが上がるとありますのでopenstack swiftベースであるConoHaのオブジェクトストレージでも効果があるか試してみます。

ConoHaにオブジェクトストレージのコンテナを作成する

docker-regsitryのstorage用にConoHaのオブジェクトストレージにコンテナを作成します。詳しくはこちらをご参照頂くことにして詳細な操作は割愛させていただきます。今回はpython-swiftクライアントを利用してコンテナを作成します。

  swift post myrepo

swiftとcacheをサポートしたdocker-registryイメージを作成します。

適当にフォルダを作成してDockerfileを作成します。仮にmyreg-cacheディレクトリとします。

  mkdir myreg-cache
  cd myreg-cache
  vi Dockerfile

Dockerfileの内容は以下となります。今回docker-registry-driver-swiftのインストールにあたり必要なパッケージを追加しております。

FROM registry:0.9.0

RUN apt-get update; apt-get -y install libxml2-dev libxslt1-dev python-dev zlib1g-dev ; apt-get clean ; apt-get autoclean
RUN pip install docker-registry-driver-swift
ADD ./config_sample.yml /docker-registry/config/config_sample.yml

ENV MIRROR_SOURCE https://registry-1.docker.io
ENV MIRROR_SOURCE_INDEX https://index.docker.io
ENV STORAGE_PATH /opt/registry

DockerfileでADDしているconfig_sample.ymlです。Dockerfileと同じディレクトリに配置します。

# All other flavors inherit the `common' config snippet
common: &common
    issue: '"docker-registry server"'
    # Default log level is info
    loglevel: _env:LOGLEVEL:info
    # Enable debugging (additional informations in the output of the _ping endpoint)
    debug: _env:DEBUG:false
    # By default, the registry acts standalone (eg: doesn't query the index)
    standalone: _env:STANDALONE:true
    # The default endpoint to use (if NOT standalone) is index.docker.io
    index_endpoint: _env:INDEX_ENDPOINT:https://index.docker.io
    # Storage redirect is disabled
    storage_redirect: _env:STORAGE_REDIRECT
    # Token auth is enabled (if NOT standalone)
    disable_token_auth: _env:DISABLE_TOKEN_AUTH
    # No priv key
    privileged_key: _env:PRIVILEGED_KEY
    # No search backend
    search_backend: _env:SEARCH_BACKEND
    # SQLite search backend
    sqlalchemy_index_database: _env:SQLALCHEMY_INDEX_DATABASE:sqlite:////tmp/docker-registry.db

    # Mirroring is not enabled
    mirroring:
        source: _env:MIRROR_SOURCE # https://registry-1.docker.io
        source_index: _env:MIRROR_SOURCE_INDEX # https://index.docker.io
        tags_cache_ttl: _env:MIRROR_TAGS_CACHE_TTL:172800 # seconds

    cache:
        host: _env:CACHE_PORT_6379_TCP_ADDR
        port: _env:CACHE_PORT_6379_TCP_PORT
        db: 0
    cache_lru:
        host: _env:CACHE_PORT_6379_TCP_ADDR
        port: _env:CACHE_PORT_6379_TCP_PORT
        db: 1


local: &local
    <<: *common
    storage: local
    storage_path: _env:STORAGE_PATH:/tmp/registry

# This flavor is for storing images in Openstack Swift
swift: &swift
    <<: *common
    storage: swift
    storage_path: _env:STORAGE_PATH:/registry
    # keystone authorization
    swift_authurl: 'https://ident-r1nd1001.cnode.jp/v2.0'
    swift_container: _env:OS_CONTAINER
    swift_user: 'ConoHa API情報のユーザー名'
    swift_password: 'ConoHa APIユーザのパスワード'
    swift_tenant_name: 'ConoHa API情報のテナント名'


# This is the default configuration when no flavor is specified
dev: &dev
    <<: *local
    loglevel: _env:LOGLEVEL:debug
    debug: _env:DEBUG:true
    search_backend: _env:SEARCH_BACKEND:sqlalchemy

# This flavor is used by unit tests
test:
    <<: *dev
    index_endpoint: https://registry-stage.hub.docker.com
    standalone: true
    storage_path: _env:STORAGE_PATH:./tmp/test

# To specify another flavor, set the environment variable SETTINGS_FLAVOR
# $ export SETTINGS_FLAVOR=prod
prod:
    <<: *s3
    storage_path: _env:STORAGE_PATH:/prod

buildします

  docker build -t myreg-cache .

redisイメージからcacheコンテナを作成します

  docker run --name cache -d redis:2.8.13

myregcacheイメージからprivate registryコンテナを作成します。

  docker run -d --name=myreg-swift-cache \
    -p 5000:5000 -e SETTINGS_FLAVOR=swift \
    -e OS_CONTAINER=myrepo \
    --link cache:cache \
    myreg-cache

cacheあり、なしの比較

公式のnginxイメージをpullする速度を比較しました。

  time docker pull localhost:5000/nginx

cacheなし

• 1回目 0m42.166s
• 2回目 0m52.660s
• 3回目 0m37.957s

cacheあり

• 1回目 0m48.595s
• 2回目 0m31.270s
• 3回目 0m43.533s

参考 dockerhubから直接pullした場合

• 1回目 1m55.755s

結果、cacheの効果は確認できませんでした。見た感じmetadataよりはfs-layerのダウンロードに時間が掛かっていた印象です。fs-layerの方はcacheしていないのかもしれません。
今回はあまり突っ込んだ使い方ができておらず十分な検証ができておりませんが、引き続きチューニングを続けてまたの機会に情報共有できればと考えております。

次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

それではまた