Docker

2014年02月13日

このエントリーをはてなブックマークに追加

イベント
Docker Meetup in Tokyo #1
日付
2014/02/12(水) 19:00〜21:00
場所
国立情報学研究所
天気
晴れ
概要
発表後記
  • 開始直後の会場アンケート、30人強のうち、ICCを知ってるのは、たった1人!マジか
  • ↑な状況で話を進めたので、何だか会場全体を置き去りにしてる感
  • しかし、この発表をきっかけにICCを使う人が増え、情報共有・検証報告が増えたら、それは成功と言える。
  • 身近な数人からは『むしろ突き抜けてて良かった。』との言葉を頂けた。
  • ICCに関わらず、Dockerのネットワーク周辺を触ってる人は少数派だと言う事を実感。



編集
@hansode at 14:00|PermalinkComments(0)TrackBack(0)

2013年12月17日

このエントリーをはてなブックマークに追加

S3-backedで一歩先行く使い捨て生活

docker-top-logo

前回に続いてPrivate Docker Registry。前回やり残していた検証、

S3 Storage : 使い捨ての良き友

まだ動作検証してないけども、S3と連携させられる所までは分かっている。

この後の戦略・シナリオは、

  1. s3 config済みのカスタムregistryイメージを作成(Dockerfile経由で)
  2. カスタムregistryコンテナを起動
  3. カスタムregistryイメージをpush

ここまで済ませておけば、必要な時にプライベートregistryコンテナを起動すれば良い。カスタムregistryでさえも、気軽に使い捨てられる。この辺の検証は、また別のエントリで。

残り検証作業をしてみた。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
  • s3cmd-1.0.1-1.el6.noarch
事前準備:S3 bucket

新規作成でも既存バケットでも、どちらでも良い。s3cmdでバケットを新規作成する場合の例。

$ s3cmd mb s3://private-docker-registry
Bucket 's3://private-docker-registry' created

※本書用にでっち上げたバケット名

事前準備:Dockerイメージ用ファイル

イメージビルド用に必要なファイルを用意/配置しておく。

  1. Dockerfile
  2. config.xml
1: Dockerfile
$ cat Dockerfile
FROM stackbrew/registry

ADD config.yml /docker-registry/config.yml
2: config.xml(docker-registry用)

コンテナイメージに焼き込むdocker-registry用config.xml

# The common' part is automatically included (and possibly overriden by all
# other flavors)
common:
    # Bucket for storage
    boto_bucket: ***s3 bucket名***

    # Amazon S3 Storage Configuration
    s3_access_key: ***s3_access_key****
    s3_secret_key: ***s3_secret_key***
    s3_bucket: ***s3 bucket名***
    s3_encrypt: 1
    s3_secure: 1

    # Set a random string here
    secret_key: ***適切なパスフレーズ***

priv:
    storage: s3
    storage_path: /priv

privターゲットは、環境変数SETTINGS_FLAVOR用で、privでなくても良い。

イメージビルド
$ sudo docker build -t registry.private .
Uploading context 10240 bytes
Step 1 : FROM stackbrew/registry
 ---> 3321c2caa0cf
Step 2 : ADD config.yml /docker-registry/config.yml
 ---> ad03546fac66
Successfully built ad03546fac66
コンテナ作成

今回は -e=SETTINGS_FLAVOR=priv を指定して起動。これにより、private用途の設定内容を指定して起動可能となる。

$ sudo docker run -d -p 5000:5000 -e=SETTINGS_FLAVOR=priv registry.private
411732c40b673a7ef8bfde9c4a696a0446096d30c488b66e6bf790b0caf5b21b
接続テスト
$ curl -v http://localhost:5000/
* About to connect() to localhost port 5000 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: gunicorn/18.0
< Date: Tue, 17 Dec 2013 11:22:17 GMT
< Connection: keep-alive
< Expires: -1
< Content-Type: application/json
< Pragma: no-cache
< Cache-Control: no-cache
< Content-Length: 31
< X-Docker-Registry-Version: 0.6.2
< X-Docker-Registry-Config: priv
<
* Connection #0 to host localhost left intact
* Closing connection #0
"docker-registry server (priv)"

"docker-registry server (priv)" となってる。これにより、SETTINGS_FLAVORがprivである事を確認出来る。

いよいよS3-backed Private Registryにpush

イメージ取得とtag打ちは、前回の作業により既に終わってるものとする。

sudo docker push 127.0.0.1:5000/ubuntu
The push refers to a repository [127.0.0.1:5000/ubuntu] (len: 1)
Sending image list
Pushing repository 127.0.0.1:5000/ubuntu (1 tags)
Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c

Pushing tags for rev [8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c] on {http://127.0.0.1:5000/v1/repositories/ubuntu/tags/latest}

clientサイドとしては、何か変化してるのかどうかすら、分からない。

S3バケットを覗いてみる
$ s3cmd ls s3://private-docker-registry/
                       DIR   s3://private-docker-registry/priv/

/priv/ ディレクトリが作成されている。これは "storage_path: /priv" と一致する。

$ s3cmd ls s3://private-docker-registry/priv/
                       DIR   s3://private-docker-registry/priv/images/
                       DIR   s3://private-docker-registry/priv/repositories/

その配下には、 /images/ と /repositories/ が作成されている。

$ s3cmd ls s3://private-docker-registry/priv/images/
                       DIR   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/

その先にはハッシュ値のディレクトリが存在。これの値は、push時にも出力されていたイメージID。

$ s3cmd ls s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/
2013-12-17 11:24        78   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/_checksum
2013-12-17 11:23        68   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/ancestry
2013-12-17 11:23       437   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/json
2013-12-17 11:23  71488718   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/layer

遂に実態オブジェクトが現れた。pushの裏側でs3バケットにオブジェクトが正しく登録されていた事が分かる。

気軽に使い捨てる

これだけでは使い捨て感を得られないので、使い捨てしてみる。

  1. private registryコンテナを破棄
  2. 新private registryコンテナを作成
  3. ローカルからイメージを一度削除
  4. 新private registry経由でイメージをpull
private registryコンテナを破棄
$ sudo docker kill 411732c40b673a7ef8bfde9c4a696a0446096d30c488b66e6bf790b0caf5b21b
新private registryコンテナを作成
$ sudo docker run -d -p 5000:5000 -e=SETTINGS_FLAVOR=priv registry.private
febb22cad222594f2158bf240b199deda243bbc976bcf7b956c689b1c3cddffe
新private registryコンテナが起動してる事を確認
$ sudo docker ps
CONTAINER ID        IMAGE                                    COMMAND                CREATED             STATUS              PORTS                    NAMES
febb22cad222        127.0.0.1:5000/registry.private:latest   /bin/sh -c cd /docke   32 seconds ago      Up 31 seconds       0.0.0.0:5000->5000/tcp   evil_brown
イメージ削除前に存在有無確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
127.0.0.1:5000/ubuntu   latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ローカルからイメージを削除
$ sudo docker rmi 127.0.0.1:5000/ubuntu
Untagged: 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
ローカルにイメージが無い事を確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
pullしてイメージを取得
$ sudo docker pull 127.0.0.1:5000/ubuntu
Pulling repository 127.0.0.1:5000/ubuntu
8dbd9e392a96: Download complete
再びローカルにイメージが作成された事を確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
127.0.0.1:5000/ubuntu   latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)

無事、復活。

あとがき

private registry構築により、複数リポジトリを扱ってみると、DockerイメージがGitライクに操作出来てる事を再認識させられる。実によく出来てる。

  • 成果物としてDockerイメージリポジトリごと納品するケースも出て来るだろうか
  • S3-backedにしておけばオブジェクトが無くなる心配はほぼ皆無で、心配事を減らせるか

遊べそうな事ばかり増えて行く。

参考文献



編集
@hansode at 22:30|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

Public Registryには登録できないコンテナイメージの登録先

docker-top-logo

構築作業をしているとpublic registryに登録するまでもないイメージや、手元の環境に特化した設定を焼きこんでいるがゆえに、public registryには登録出来ないイメージが幾つか作成される。自分の場合は、Dockerホストごと再構築する事が多々あるので、イメージをどこかに保存しておきたい事がある。そう言った要件を満たすのが、プライベートDockerレジストリ。

Dockerがdocker-registryを開発・公開していてる。

更に、registryイメージがpublic registryに登録されている。

ここまで材料が揃っていると、あっと言う間にセットアップが完了する。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
事前準備としてマシンイメージをpull
$ sudo docker pull stackbrew/registry

$ sudo docker images stackbrew/registry
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
stackbrew/registry   0.6.0               982e72a4385c        5 days ago          596.8 MB (virtual 4.537 GB)
stackbrew/registry   0.5.9               ddba540fb44c        5 days ago          596.6 MB (virtual 4.536 GB)
stackbrew/registry   0.6.1               3321c2caa0cf        5 days ago          472.2 MB (virtual 3 GB)
stackbrew/registry   latest              3321c2caa0cf        5 days ago          472.2 MB (virtual 3 GB)

検証当時は、0.6.1が最新。

$ sudo docker history stackbrew/registry
IMAGE               CREATED             CREATED BY                                      SIZE
3321c2caa0cf        5 days ago          /bin/sh -c #(nop) CMD [/bin/sh -c cd /docker-   472.2 MB
709278331dd3        5 days ago          /bin/sh -c #(nop) EXPOSE [5000]                 472.2 MB
a2d8a28078d8        5 days ago          /bin/sh -c cp --no-clobber /docker-registry/c   472.2 MB
20dae6853028        5 days ago          /bin/sh -c cd /docker-registry && pip install   472.2 MB
b34b73dac452        5 days ago          /bin/sh -c #(nop) ADD . in /docker-registry     415.6 MB
0fa5f53aba34        5 days ago          /bin/sh -c apt-get install -y git-core python   415 MB
4f73ac94d99d        5 days ago          /bin/sh -c sed -i 's/main$/main universe/' /e   192.4 MB
9a776d8a79dd        4 weeks ago         /bin/sh -c #(nop) ADD raring.tar.xz in /        88.42 MB
adfd622eb223        4 weeks ago         /bin/sh -c #(nop) MAINTAINER Tianon Gravi <ad   0 B
511136ea3c5a        6 months ago                                                        0 B

Dockerfileの内容である事が分かる。

コンテナを起動
$ sudo docker run -d -p 5000:5000 stackbrew/registry
eb20a3b33092e44bd31ed12860adcfe39133d6e0b6dc88a964876c68d0789c4c

$ sudo docker ps
CONTAINER ID        IMAGE                      COMMAND                CREATED             STATUS              PORTS                    NAMES
eb20a3b33092        stackbrew/registry:0.6.1   /bin/sh -c cd /docke   4 seconds ago       Up 2 seconds        0.0.0.0:5000->5000/tcp   cocky_archimede

Dockerホストの 0.0.0.0:5000 から、コンテナ内の 5000/tcp へポートフォワードされる設定まで入った。

接続テスト
$ curl -v http://localhost:5000/
* About to connect() to localhost port 5000 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: gunicorn/18.0
< Date: Tue, 17 Dec 2013 01:03:25 GMT
< Connection: keep-alive
< Expires: -1
< Content-Type: application/json
< Pragma: no-cache
< Cache-Control: no-cache
< Content-Length: 30
< X-Docker-Registry-Version: 0.6.2
< X-Docker-Registry-Config: dev
<
* Connection #0 to host localhost left intact
* Closing connection #0
"docker-registry server (dev)"

サービスしてる事を確認出来る。

登録用イメージを取得

イメージは何でも良い。ここでは ubuntu を使用。

$ sudo docker pull ubuntu
Pulling repository ubuntu
8dbd9e392a96: Download complete
b750fe79269d: Download complete
27cf78414709: Download complete

$ sudo docker images ubuntu
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ubuntu              12.04               8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ubuntu              latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ubuntu              precise             8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ubuntu              12.10               b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
ubuntu              quantal             b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)

$ sudo docker images ubuntu | grep -w latest
ubuntu              latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)

イメージIDは、 8dbd9e392a96。メモっておく。

tag打ち

tagが、イメージ を どのendpointへ登録するのか が定まる。(どっか!ではない・・・)今回のendpointは、 localhost:5000 なので、下記の様にtag打ちする。

$ sudo docker tag 8dbd9e392a96 localhost:5000/ubuntu
プライベートレジストリ localhost:5000 へ登録してみる
$ sudo docker push localhost:5000/ubuntu
The push refers to a repository [localhost:5000/ubuntu] (len: 1)
Sending image list
Pushing repository localhost:5000/ubuntu (1 tags)
Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c

Pushing tags for rev [8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c] on {http://localhost:5000/v1/repositories/ubuntu/tags/latest}

無事、成功。

S3 Storage : 使い捨ての良き友

まだ動作検証してないけども、S3と連携させられる所までは分かっている。

この後の戦略・シナリオは、

  1. s3 config済みのカスタムregistryイメージを作成(Dockerfile経由で)
  2. カスタムregistryコンテナを起動
  3. カスタムregistryイメージをpush

ここまで済ませておけば、必要な時にプライベートregistryコンテナを起動すれば良い。カスタムregistryでさえも、気軽に使い捨てられる。この辺の検証は、また別のエントリで。

あとがき

プライベートレジストリを使えば、プロジェクト特化したconfig入りイメージを気軽に登録できるので、コンテナベースデプロイを、一歩も二歩も進められそうか。

参考文献



編集
@hansode at 13:00|PermalinkComments(0)TrackBack(0)

2013年12月14日

このエントリーをはてなブックマークに追加

アップグレード検証はコンテナの得意分野の1つ

RHEL 7 Beta 1 が公開された。

気になったのでアップグレードを検証してみた。

  1. CentOS-6.5 minimal Dockerコンテナを作成
  2. RHEL-7.0 Beta 1へアップグレード
  3. build結果を観察

アップグレードは、期待通り失敗する。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
事前準備
  1. Dockerホスト構築
  2. Dockerfileを配置
  3. rhel-beta.repoを配置
Dockerfile
FROM hansode/centos-6-x86_64

RUN rpm --import http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/RPM-GPG-KEY-redhat-beta
RUN rpm --import http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/RPM-GPG-KEY-redhat-release

ADD rhel-beta.repo /etc/yum.repos.d/rhel-beta.repo

CMD yum update --enablerepo=rhel-beta -y

ベースイメージは拙作のhansode/centos-6-x86_64/を使用。

rhel-beta.repo
[rhel-beta]
name=Red Hat Enterprise Linux 7 Beta - $basearch
#baseurl=ftp://ftp.redhat.com/pub/redhat/rhel/beta/7/$basearch/os/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=rhel-7-beta&arch=$basearch
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta
build検証
imageをbuild
$ sudo docker build -t centos6-to-rhel7beta .

Uploading context 266240 bytes
Step 1 : FROM hansode/centos-6-x86_64
 ---> cff199166afa
Step 2 : RUN rpm --import http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/RPM-GPG-KEY-redhat-beta
 ---> Using cache
 ---> 29fe8e11a311
Step 3 : RUN rpm --import http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/RPM-GPG-KEY-redhat-release
 ---> Using cache
 ---> 79d5818a221b
Step 4 : ADD rhel-beta.repo /etc/yum.repos.d/rhel-beta.repo
 ---> bae8fd8675fa
Step 5 : CMD yum update --enablerepo=rhel-beta -y
 ---> Running in f637d63aec99
 ---> 45b4fb3644ae
Successfully built 45b4fb3644ae
buildしたイメージを起動
$ sudo docker run -t centos6-to-rhel7beta

Transaction Check Error:
  file /etc/my.cnf from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/Index.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/armscii8.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/ascii.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/cp1250.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/cp852.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/hebrew.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/latin1.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/latin2.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/charsets/latin5.xml from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/czech/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/danish/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/dutch/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/english/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/estonian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/french/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/german/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/greek/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/hungarian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/italian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/japanese/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/korean/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/norwegian-ny/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/norwegian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/polish/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/portuguese/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/romanian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/russian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/serbian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/slovak/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/spanish/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/swedish/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /usr/share/mysql/ukrainian/errmsg.sys from install of mariadb-libs-1:5.5.33a-3.el7.x86_64 conflicts with file from package mysql-libs-5.1.71-1.el6.x86_64
  file /lib/firmware/ql2500_fw.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package ql2500-firmware-7.00.01-1.el6.noarch
  file /lib/firmware/ql2400_fw.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package ql2400-firmware-7.00.01-1.el6.noarch
  file /lib/firmware/radeon/ARUBA_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/BTC_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/CAYMAN_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/CEDAR_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/CYPRESS_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/JUNIPER_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/PITCAIRN_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/R700_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/REDWOOD_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/SUMO_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/TAHITI_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch
  file /lib/firmware/radeon/VERDE_rlc.bin from install of linux-firmware-20131106-0.1.git7d0c7a8.el7.noarch conflicts with file from package xorg-x11-drv-ati-firmware-7.1.0-3.el6.noarch

Error Summary
-------------

minimal構成で、この結果。そうか、MariaDBになったんだっけ。

参考文献
あとがき

こう言った使い捨て検証は、コンテナの得意分野の1つで、実際に実施してみると、それを実感する。




編集
@hansode at 09:40|PermalinkComments(0)TrackBack(0)

2013年12月10日

このエントリーをはてなブックマークに追加

素のCentOS6でpipeworkを使うと、エラーに遭遇する

Dockerコンテナに狙ったIPアドレスを割り当てるpipeworkを使った。この時に触れてない無い事がある。それは、CentOSでpipeworkを使う為の事前準備作業。おそらくUbuntuの場合は、関係が無い話。

必要な事前準備作業は2つ

  1. pipeworkのipコマンドによる中のブリッジ操作箇所を計2箇所、brctlコマンドで置き換える
  2. 最低限netns対応のiprouteで置き換える

その手順を追っていく。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
  • iproute-2.6.32-130.el6ost.netns.2.x86_64
  • bridge-utils-1.2-10.el6.x86_64
1. pipework修正
pipework修正: brctlで書き換え対応1

修正しない場合に出るエラーメッセージ。

$ sudo pipework br1 $cid 192.168.1.10/24
Error: either "dev" is duplicate, or "master" is a garbage.

118行目をbrctlコマンドで書き換える。

-    ip link set $LOCAL_IFNAME master $IFNAME
+    brctl addif $IFNAME $LOCAL_IFNAME
pipework修正: brctlで書き換え対応2

修正しない場合に出るエラーメッセージ。

$ sudo pipework br1 $cid 192.168.1.10/24
Object "netns" is unknown, try "ip help".

109行目をbrctlコマンドで書き換える。

-    ip link add $IFNAME type bridge
+    brctl addbr $IFNAME
修正版pipeworkはforkしてメンテナンス中

上記修正対応済みコードは、forkして下記リポジトリにてメンテナンス予定。

本家はUbuntu向けであるはずなので、CentOS向けはforkリポジトリでメンテナンスするのが良いと考えてる。役目を終える時は、RHEL7/CentOS7がリリースされた時か。

2. iprouteを入れ替える

baseのiprouteパッケージはnetns機能不十分iprouteである為、netns周りを設定出来ないようだ。探してみると、同じように困ってる方が居た。なお、この方はDockerホスト環境で困っていた訳では無さそう。

残念なことにバージョン 6.4 ではまだ Linux Network Namespace (netns) が使えない。 どうやら Linux カーネルと iproute2 のバージョンが足りてないらしい。じゃあどうするかっていうと RedHat が出している OpenStack ディストリビューションの RDO を使う。

この戦略を拝借してiprouteを置き換える。

$ sudo yum install -y http://rdo.fedorapeople.org/openstack/openstack-havana/rdo-release-havana.rpm
$ sudo yum update --enablerepo=openstack-havana -y iproute

$ rpm -qa iproute
iproute-2.6.32-130.el6ost.netns.2.x86_64

※このバージョンのipコマンドでも、ブリッジ操作までは対応してなかったので、前半のbrctlコマンド仕様に書き換える必要性は残ったまま。

以上でpipeworkを使うための準備体操は終わり。快適なpipework生活を!




編集
@hansode at 00:20|PermalinkComments(0)TrackBack(0)

2013年12月07日

このエントリーをはてなブックマークに追加

固定IPアドレス指定のコンテナ作成

Dockerコンテナに狙ったIPアドレス割り当てした環境で検証をしたい場合がある。それを解決する手段の1つが、pipework。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
例として 192.168.1.10/24 をコンテナに割り当ててみる
コンテナを起動

今回は base を使用。どのマシンイメージを使っても良い。

$ sudo docker run -i -t base /bin/bash
root@9e6eb5df1d30:/# ip addr show
135: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 46:48:66:3b:64:ba brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.35/16 brd 172.17.255.255 scope global eth0
    inet6 fe80::4448:66ff:fe3b:64ba/64 scope link
       valid_lft forever preferred_lft forever
137: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
</loopback,up,lower_up></broadcast,multicast,up,lower_up>

起動直後は、eth0 - 172.17.0.35 の組み合せで割り当てられている。

コンテナIDを確認

割り当て対象コンテナIDを知っておく必要がある。

$ sudo docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
9e6eb5df1d30        base:latest         /bin/bash           17 seconds ago      Up 17 seconds                           clever_mccarthy

作ったコンテナIDは、 9e6eb5df1d30。

pipeworkで狙ったIPアドレスを割り当てる
$ sudo pipework br1 9e6eb5df1d30 192.168.1.10/24

ブリッジは br1 でなくても良い。pipeworkのREADMEがbr1を使っていたので、br1を使用。

ブリッジ状態を確認
$ brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.aa2ead359fe8       no              vethl17357
docker0         8000.fe1cbcd978e9       no              veth8D13Bz

pipeworkがホストに影響を与えた事

  1. br1追加(無い場合は自動的に追加される)
  2. veth8D13Bzがbr1に刺さる
コンテナ中のIPアドレスは?
root@9e6eb5df1d30:/# ip addr show
135: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 46:48:66:3b:64:ba brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.35/16 brd 172.17.255.255 scope global eth0
    inet6 fe80::4448:66ff:fe3b:64ba/64 scope link
       valid_lft forever preferred_lft forever
137: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
138: eth1: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether b2:e6:66:26:d0:41 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 scope global eth1
    inet6 fe80::b0e6:66ff:fe26:d041/64 scope link
       valid_lft forever preferred_lft forever
</broadcast,multicast,up,lower_up></loopback,up,lower_up></broadcast,multicast,up,lower_up>

pipeworkがゲストに影響を与えた事

  1. eth1追加
  2. eth1に192.168.1.10/24割り当て
ホスト・ゲスト間通信してみる

狙ったIPアドレス割り当てする場合は、ホストからゲストへ通信したい場合である事が多い。おまけ作業としてホストからゲストへ通信するセットアップをしてみる。

  • ホスト 192.168.1.254/24
  • ゲスト 192.168.1.10/24
割り当て前のIPアドレス状態を確認
$ ip addr show br1
28: br1: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether aa:2e:ad:35:9f:e8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f493:8bff:fed9:9566/64 scope link
       valid_lft forever preferred_lft forever
</broadcast,multicast,up,lower_up>

IPアドレス割り当てされてない事を確認。

ホストブリッジにIPアドレス割り当て
$ sudo ip addr add 192.168.1.254/24 dev br1

$ ip addr show br1
28: br1: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether aa:2e:ad:35:9f:e8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.254/24 scope global br1
    inet6 fe80::f493:8bff:fed9:9566/64 scope link
       valid_lft forever preferred_lft forever
</broadcast,multicast,up,lower_up>

192.168.1.254/24 が割り当てされてる。

ゲストへ向けてping
$ ping -c 1 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.043 ms

--- 192.168.1.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.043/0.043/0.043/0.000 ms
ゲストから抜ける
root@9e6eb5df1d30:/# exit
コンテナ破棄後のブリッジ状態
$ brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.000000000000       no
docker0         8000.000000000000       no

br1に刺さってたvethXが自動的に削除されている

あとがき

pipeworkの戦略は、eth0に割り当てる訳では無い。

  • 狙ったIPアドレス用veth追加し、
  • IPアドレス割り当てる

eth0を使いたい場合は、pipeworkの出番ではない。そのうちDockerが対応するのかな?




編集
@hansode at 19:00|PermalinkComments(0)TrackBack(0)
このエントリーをはてなブックマークに追加

EPELリポジトリにDockerパッケージが追加された

CentOS6にDockerホストを構築しようとすると大分面倒だったが、状況は一変した。EPELにパッケージが追加されたからだ。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
Dockerをインストール
$ sudo yum install -y http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
$ sudo yum install -y docker-io

実に簡単。これだけ。

Dockerを起動
$ sudo /etc/init.d/docker start
Starting docker:                                           [  OK  ]
$ sudo /etc/init.d/docker status
docker (pid  1428) is running...
マシンイメージをダウンロード
$ sudo docker pull base
Pulling repository base
b750fe79269d: Download complete
27cf78414709: Download complete
$ sudo docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
base                latest              b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
base                ubuntu-12.10        b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
base                ubuntu-quantal      b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
base                ubuntu-quantl       b750fe79269d        8 months ago        175.3 MB (virtual 350.6 MB)
コンテナを起動
$ sudo docker run -i -t base /bin/bash
root@d004fa70a753:/# ip addr show
7: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether f2:df:e9:48:38:52 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
    inet6 fe80::f0df:e9ff:fe48:3852/64 scope link
       valid_lft forever preferred_lft forever
9: lo: <loopback,up,lower_up> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
root@d004fa70a753:/# uname -a
Linux d004fa70a753 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
root@d004fa70a753:/# exit
exit
</loopback,up,lower_up></broadcast,multicast,up,lower_up>
参考文献



編集
@hansode at 15:10|PermalinkComments(0)TrackBack(0)