2015.01.30
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していないのかもしれません。
今回はあまり突っ込んだ使い方ができておらず十分な検証ができておりませんが、引き続きチューニングを続けてまたの機会に情報共有できればと考えております。
次世代システム研究室では、グループ全体のインテグレーションを支援してくれるアーキテクトを募集しています。インフラ設計、構築経験者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。
それではまた
グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。
Follow @GMO_RD