RHEL

2014年01月31日

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

次のマイナーバージョンがリリースされた事により、困った事は無いだろうか?

少し前の事だが、CentOSが6.5がリリースされた。何も気にせずにyum updateすると、6.5へ・・・・。検証等の理由あって手元の環境は6.4を維持しておきたい事がある。さて、この状況をどうやって回避するのか。その手段の1つが、/etc/yum/vars/releaseverファイルによる固定。

検証環境
  • CentOS 6.4
  • kernel-2.6.32-358.el6.x86_64
  • yum-3.2.29-40.el6.centos.noarch
手順は/etc/yum/vars/releaseverを作成するだけ
  1. /etc/yum/vars/releaseverを作成
  2. ファイルの中身は、固定化したいバージョン
例: 6.4 固定化
/etc/yum/vars/releasever を作成
$ sudo $SHELL -c "echo 6.4 > /etc/yum/vars/releasever"
中身を確認
$ cat /etc/yum/vars/releasever
6.4
考察

例えばCentOSであれば、/etc/yum.repos.d/CentOS-Base.repoを修正し、$releaseverを特定バージョンに固定化する手段がある。しかし、これはCentOSに限定される。/etc/yum/vars/releaseverファイルの場合、特定ディストリビューションに依存しせず、固定が可能である事。RHELであろうがCentOSだろうがScientificLinuxであろうが、幅広く利用可能である事。

あとがき

1つ前のリリースバージョンのパッケージが、ミラーサイトから徐々に消えて行くのは、どうしたものか。

参考文献



編集
@hansode at 13: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)

2013年01月14日

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

Bash + Vagrant ⇒ Bagrant

これまでに何度も仮想マシンイメージを作って来て、どこか面倒臭さを感じていた。そんな中、Vagrantに出会い、ソレが欲しかったモノの1つであると感じ、調査・検証・評価。そして、bash実装する事にした。

Bagrantの機能
  • Bagrantfileで仮想マシンを定義
  • bagrantコマンドで仮想マシンをビルド・起動・停止
  • ハイパーバイザーはKVM
利用ライブラリ

自作したvmbuilderのみ。

使い方

詳細はhansode/bagrantを参照の事で、起動までは、下記手順で行える。

  1. Bagrantfileを作成 $ bagrant init
  2. 仮想マシンイメージをビルド $ bagrant build
  3. 仮想マシンを起動 $ bagrant up

また、hansode/bagrant-boxがBagrantfileを含んだテンプレート集となっているので、Bagrantfileを自作したい方の参考になるはず。

開発期間

移植作業だったので、結構あっさりと実装出来た気がする。

  • 設計: 3日(主にVagrantの調査)
  • 実装: 2日
今後の予定

開発した動機がそうであるように、何か機能追加される事があったら、自分自身が欲しいと思ったタイミング。

あとがき

これも、まだ、自動化したかった事の1つでしかない。

フィードバックなど

もしBagrantに興味がある方がいらっしゃいましたら、ご一報下さい。

続きを読む


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

2012年11月01日

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

複数ディストリビューション対応へ向けて

ギーク達はfedora対応を希望

前回のエントリに反応してくれたギーク達は、CentOSよりもfedora対応を希望していた。『fedora対応…!』と思ったけども、fedoraを使ってないので良くわかってない。それよりは、複数ディストリビューション対応への準備体操として、CentOS 5対応に着手してみた。

検証環境

インストール
$ git clone git://github.com/hansode/vmbuilder.git
実行方法
$ cd vmbuilder/kvm/rhel/6/
$ sudo ./vmbuilder.sh --distro-name=**centos** --distro-ver=**5**

実行してから約10分程度で実行したディレクトリ直下に仮想マシンイメージが作成される。

2012/11/01現在の対応ディストリビューション

distro-name と distro-ver に指定可能な組み合わせは下記の通り。

  • centos 5 (5.x)
  • centos 6 (6.x)
  • sl 6 (6.x)

新規追加されるタイミングは、今の所、自分が欲しいと思う時か、聞こえて来る周りからの声。

問題点

rhel6環境でrhel5を構築すると、仮想マシンイメージを作成可能ではあるが、rhel5環境としては不完全だ。

  • 今のvmbuilder.shの仕様では、ホスト環境のyumコマンドでゲスト環境を構築する
  • ゲスト環境におけるrpmdbのフォーマットは、ホスト環境に依存する

個人的に困ってないので、しばらくの間は保留扱い。

改善案

検証すべき項目

  • ホスト環境とゲスト環境を一致させる
    • 例) rhel5用仮想マシンイメージを構築する場合は、rhel5環境で行う
  1. post installフェーズで、rpmdbを変換するなどの対応をする
  2. yumコマンドかyum.confにrpmdbのバージョン指定する方法があれば、指定してみる

上記のうち、 1 が良さそうなので、対応手段は、構築フェーズを分ける事だろうか。

  1. ゴールとなる仮想マシンをビルドする為のビルド環境(1次chroot環境) を構築
  2. 構築されたビルド環境(1次chroot環境)にて、ゲスト環境(2次chroot環境)を構築
  3. ホスト環境にてマシンイメージ化

これで対応出来そうな気がするので、あとは検証・実装するだけの事。この辺をしっかり実装しておかないと、fedora対応も大変そう。

あとがき

環境差異が発生するとは面白い事。

フィードバックなど

希望するネタ等、フィードバック、大歓迎です。

続きを読む


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

2012年10月25日

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

コマンドラインで仮想マシンイメージを作ろう!

面倒臭かった。世の中に出回っているCentOS用仮想マシンイメージ作成手順が。

  1. インストールDVD(ISOファイル)を用意
  2. virt-installコマンドを多数のオプション指定で実行…
  3. VNC接続して…

この手順には問題・課題があり、幾つか挙げると、

  • 手作業が入るので多少なりとも作業ブレが発生
  • 自動化すべく、kickstartを使うとしても、ks.cfg作成などの準備作業が面倒臭い
  • libvirt依存、KVM依存
  • どうやってテストする…?

Ubuntuであれば、VMBuilderが上記の問題・課題を解決してくれる。

$ sudo apt-get install ubuntu-vm-builder
$ sudo vmbuilder [options]....

vmbuilderコマンド実行後、10分ほどで仮想マシンイメージを作成される。

vmbuilderのお手軽さを知っていると、CentOSにおいても同様・同等の事が出来る事を期待した。しかし、残念ながら、VMBuilderはubuntu用だった。ゆえに、VMBuilderではCentOS用の仮想マシンイメージを作成出来ない。VMBuilderに似たツールを探してみたが、満足の行く物は見つからなかった…。

無いなら…作ろう!そして作った。bashで!

検証環境

  • RHEL 6.X / CentOS 6.X / Scientific Linux 6.X
  • bash 4.00
  • git 1.7

※他にkpartxやpartedなどに依存するが、本エントリでは詳細な依存パッケージは省略。

インストール
$ git clone git://github.com/hansode/vmbuilder.git
実行方法

KVM環境がなくても、KVM用仮想マシンイメージを作成可能なのである。

$ cd vmbuilder/kvm/rhel/6/
$ sudo ./vmbuilder.sh

実行してから約10分。実行したディレクトリ直下に仮想マシンイメージが作成される。

⇒ centos-6.3_x86_64.raw

※2012/10/25 現在、 centos-6.3 がデフォルトセット。

動作確認

出来上がった仮想マシンイメージを軽く確認したくなる。その場合は、下記手順でkvm-ctl.shを実行。 ここで初めてKVMが登場する。kvm-ctl.shはkvmコマンドのラッパースクリプトなので、virsh系のコマンドは不要。依然として、libvirtに依存しないまま。

$ sudo ./misc/kvm-ctl.sh start --image-path=./centos-6.3_x86_64.raw

tcp/6901でVNCが口を開けてるので、VNCクライアントで接続する。

仮想マシンにログイン
  • user: root
  • pass: root

開発用途なので、脆弱なパスフレーズで良いものとしてる。

あとがき

これは、まだ、自動化したかった事の1つでしかない。

フィードバックなど

本エントリはインストール手順と実行手順に留めておき、次のエントリからは開発苦労話などを執筆予定。 希望するネタ等、フィードバック、大歓迎です。

続きを読む


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