Vagrant libvirt boxのディスクサイズを変更する
Vagrantは便利なんですが、ディスクイメージのサイズが固定されているので、デカイもの突っ込んで新しいイメージを作成とかするときに困ってしまいました。単にデカイのつっこむなら別のディスクをアタッチすればいいのですが、新しいイメージを作る時にはVagrant boxにはディスクイメージは2つ同梱できないので困ります。どうせqcow2のthinなので上限大きくしても特に影響なしで使いやすいですし。
今回はRHEL 7.1のイメージで、Red Hat Container Development Kitという今回のような開発とか評価用途のサポートなしのダウンロードのところにRHEL 7.1のVagrant libvirt boxがあるのでダウンロードします。ちなみにVirtualBox用のもあります。
https://access.redhat.com/downloads/content/293/ver=1/rhel---7/1.0.0/x86_64/product-downloads
ダウンロードしたboxの元サイズは500Mちょいです。.boxはfile *.boxしてみるとわかりますがtar.gzなので、展開してみます。
$ mkdir work
$ cd work
$ tar xf ../rhel-server-libvirt-7.1-0.x86_64.box
$ ls -l
total 1543500
-rwxr-xr-x. 1 nekop nekop 1580531712 Mar 12 01:25 box.img
-rw-r--r--. 1 nekop nekop 62 Mar 12 01:25 metadata.json
-rw-r--r--. 1 nekop nekop 356 Mar 12 01:25 Vagrantfile
$ file box.img
box.img: QEMU QCOW Image (v2), 10737418240 bytes
$ cat metadata.json
{"provider": "libvirt", "format": "qcow2", "virtual_size": 11}
中身のbox.imgは11Gのqcow2イメージです。今回はこれを20Gへ拡大します。
中身の構成を見てみましょう。
$ virt-filesystems -lh --parts --pvs --vgs --lvs --extra -a box.img Name Type VFS Label MBR Size Parent /dev/sda1 filesystem unknown - - 1.0M - /dev/sda2 filesystem ext4 - - 200M - /dev/VolGroup00/LogVol00 filesystem ext4 - - 8.0G - /dev/VolGroup00/LogVol01 filesystem swap - - 1.5G - /dev/VolGroup00/LogVol00 lv - - - 8.0G /dev/VolGroup00 /dev/VolGroup00/LogVol01 lv - - - 1.5G /dev/VolGroup00 /dev/VolGroup00 vg - - - 9.8G /dev/sda3 /dev/sda3 pv - - - 9.8G - /dev/sda1 partition - - 83 1.0M /dev/sda /dev/sda2 partition - - 83 200M /dev/sda /dev/sda3 partition - - 8e 9.8G /dev/sda
/dev/sda3がLVMのパーティションで、これを拡大すれば後はオンラインでどうにでも割り当てられますね。謎の1Mの/dev/sda1がありますが使われていませんね。
20Gのqcow2イメージを作って、virt-resizeで/dev/sda3をリサイズ指定します。PVも自動的にpvresizeしてくれます。
qemu-img create -f qcow2 box.img.new 20G virt-resize --expand /dev/sda3 box.img box.img.new mv box.img.new box.img tar czf ../rhel-7.1-20g.box ./*
これで20Gのイメージが出来上がりました。
起動してルートパーティションを拡大してみます。
$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 8093624 1520852 6138596 20% / devtmpfs 498944 0 498944 0% /dev tmpfs 508380 0 508380 0% /dev/shm tmpfs 508380 6668 501712 2% /run tmpfs 508380 0 508380 0% /sys/fs/cgroup /dev/vda2 194235 96794 83105 54% /boot $ sudo lvresize -L 12G /dev/VolGroup00/LogVol00 $ sudo resize2fs /dev/VolGroup00/LogVol00 $ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 12255112 1524888 10128280 14% / devtmpfs 498944 0 498944 0% /dev tmpfs 508380 0 508380 0% /dev/shm tmpfs 508380 6668 501712 2% /run tmpfs 508380 0 508380 0% /sys/fs/cgroup /dev/vda2 194235 96794 83105 54% /boot
OpenShift上でprivate Docker registryを動かす
Dockerで遊んでるとテスト用にDocker registryが欲しくなります。Docker registryはdocker run -d -p 5000:5000 registry:latestとかで動かせるのですが、こういうのはOpenShiftに投げてしまうとラクです。
Docker registryのイメージはユーザを切り替えていますが、OpenShiftではDockerコンテナは割り当てられたUIDしか利用できないセキュリティ設定になっているので、ユーザの切り替えができるように事前にadmin権限でoc edit scc restrictedしてrunAsUser.TypeをRunAsAnyへ変更します。デフォルトではMustRunAsRangeになっています。
あとはざざっと作って、httpsのルートも作成します。
oc new-app registry:latest --name=v1 oc expose service v1 --name=v1-http oc expose service v1 --name=v1-https oc new-app registry:2.0 --name=v2 oc expose service v2 --name=v2-http oc expose service v2 --name=v2-https oc edit route v1-https oc edit route v2-https
oc exposeはデフォルトでhttpのルートを作成するので、httpsのものは作成してから編集してedge TLSを有効化します。spec部にtlsの2行を加えるだけです。これでv1もv2もhttp/https共にアクセスできるようになります。
spec:
tls:
termination: edge
おしまい。
OpenShift Origin v3の最新版を試す - 利用編
前回OpenShift Origin v3の最新版の環境を構築したので、アプリケーションを動作させてみます。慣れるとある程度複雑な構成のアプリケーションもコピペ感覚でボコボコ生やすことができて面白いですよ。
OpenShiftのクライアントコマンドであるocのバイナリさえあればOpenShiftへのアクセスできます。通常はこのocコマンドを配布してリモートからOpenShiftを操作するのですが、今回はVagrant環境上でそのまま利用します。ocコマンドにはMacOSX, Windows, Linux版があるのでどのOSでも動作します。
Vagrant環境ではocコマンドが利用する設定ファイルパスを示す環境変数$KUBECONFIGがadminのものに設定されているので、まずはunsetしてまっさらな状態にします。それから、一般ユーザとしてログインします。
$ cd
$ unset KUBECONFIG
$ oc login
Server [https://localhost:8443]:
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
Username: nekop
Authentication required for https://localhost:8443 (openshift)
Password:
Login successful.
You don't have any projects. You can try to create a new project, by running
$ oc new-project <projectname>
ユーザ名は何でも構いません。All-in-one環境ではAllowポリシーというザル認証モジュールが設定されているので、どのユーザにどのようなパスワードを入力しても認証が通ります。パスワードが空の場合ははじかれます。
次にプロジェクトを作成します。ここもユニーク値であれば何でも構いません。
oc new-project nekop
次にアプリケーションを作成します。まずはオフィシャルで提供されているSTIビルド (Source to image build, ソースコードからDocker imageをビルドするやつ) のテンプレートで作成します。
oc new-app -f https://raw.githubusercontent.com/openshift/origin/master/examples/sample-app/application-template-stibuild.json
このテンプレートで指定されているアプリケーションのソースコードは https://github.com/openshift/ruby-hello-world で、データベースアクセスを行うRubyのsinatraアプリケーションです。アプリケーション自体は、データベースの接続情報を環境変数から取得する、という点以外はごく一般的なsinatraアプリケーションです。.stiというOpenShift特有のディレクトリがあって説明ドキュメントやデフォルト設定が置いてありますが、これは無くても変わりません。
テンプレートというのは複雑な構成をひとまとめにできる設定です。このテンプレートにはデータベースの設定などが入っているので長くなっています。もちろん、テンプレートを利用しなくてもコマンドをいくつか発行することで同じ構成をマニュアルで作成できるので、見通しをよくするためにテンプレートを利用せずシェルスクリプトにするという方法もあります。
oc new-appを実行すると、必要なDocker imageのpullや、アプリケーションのDocker imageのビルドなどが行われるので、コーヒーを淹れましょう。ビルドの状況の確認にはoc get build, oc build-logs <build name>, oc get eventなどを利用します。
ビルドが完了したら、frontendサービスにアクセス可能になっているはずです。
$ oc get service NAME LABELS SELECTOR IP(S) PORT(S) database template=application-template-stibuild name=database 172.30.247.13 5434/TCP frontend template=application-template-stibuild name=frontend 172.30.90.201 5432/TCP $ curl 172.30.90.201:5432 (長いので省略)
今回はDockerのサービスIPに直接アクセスできる環境でテストしていますが、本来は外部から通常のブラウザでURLアクセスを行えるようにします。このあたりはDNSの設定などが入ってくるので今回のAll-in-oneセットアップでは対象外です。
oc new-appには、github上の通常のアプリケーションのclone URLを指定することもできますし、通常のアプリケーションではなくDockerfileのあるソースツリーも指定できます。また、docker pullのpullspec形式も指定でき、既存のDocker imageをそのままOpenShift上で動作させることもできます。
oc new-app https://github.com/nekop/hello-sinatra # sinatraのhello world oc new-app oc new-app https://github.com/openshift/centos7-wordpress # Dockerfile oc new-app openshift/jenkins-16-centos7 # Docker image pull
どれもビルドが終わればcurlで問題なくアクセスできるはずです。
ocコマンドさえあれば、リモートからOpenShift上のノードのどこかにあるDockerコンテナにexecを発行して操作することもできます。
oc get pod oc exec -it -p <pod-name> bash # sshのようなリモートシェル感覚な接続 pod> ls
一般的なPaaSっぽい機能でいくと、oc scale rc frontend-1 --replicas=8のようにレプリカ増やしてコンテナ分散配置してスケールアウトができます。また、podやDockerコンテナ内のpid=1のプロセスが死んだりしても、検知して勝手に再起動して障害復旧してくれます。ローリングアップデートがサポートされているので、無停止リリースもできます。もちろんロールバックも。
OpenShiftにはアプリケーションの構成を確認するためのWebコンソールが付属しています。Vagrantではポートフォワード設定がされるので、 https://localhost:8443/console/ でアクセスできます。
とりあえず今回はここまで。
OpenShift Origin v3の最新版を試す - Vagrantで構築編
OpenShift Origin v3の最新版はVagrantで簡単に試せるようになっています。現時点でのOpenShift Origin v3はバージョン1.0.3がリリースされたところなので、今回動かすのは1.0.4の開発版ということになります。
Vagrantで複数ノード構成を構築することもできるのですが、まずは一台のAll-in-one構成を作ります。基本的な使い方を知るにはこのAll-in-one構成で十分です。
ちなみにOpenShift v3のv3というのはアーキテクチャバージョンであり、実装のバージョンを示しているわけではありません。コードネームのようなものです。実装のソフトウェアバージョンはふつうに0.6や1.0.3など、よくあるx.y.zの形式です。初見でびっくりするかもしれません。
Vagrantの準備
自分はFedora 22でVagrantのバックエンドはlibvirt/qemu-kvmなので、それらをインストールします。Mac/WindowsではVirtualBoxを使うことになると思うので以下は読み飛ばして環境に合わせたVagrant/VirtualBoxのインストールを行ってください。
libvirtはインストールした後に以下の設定をしておいて都度認証しないようにしておきます。
sudo dnf install -y libvirt qemu-kvm sudo groupadd libvirt sudo usermod -aG libvirt nekop sudo vi /etc/libvirt/libvirtd.conf # 以下の設定を有効化 unix_sock_group = "libvirt" unix_sock_ro_perms = "0777" auth_unix_ro = "none" auth_unix_rw = "none" sudo systemctl enable libvirtd && sudo systemctl start libvirtd
そしてVagrantをインストールします。
sudo dnf install -y vagrant vagrant-libvirt
OpenShift Origin v3のインストール
OpenShift Originのソースコードを取得します。ソースツリーにVagrantfileが含まれているので、そのままvagrant upするだけでOpenShiftのビルドおよび動作が可能なFedora 21のVMが立ち上がります。最初はboxのダウンロードを行うので少し時間がかかります。デフォルトでVMのメモリは1GBなのですが、ビルドに2GB使うので2GBを設定しておきます。
git clone https://github.com/openshift/origin/
cd ./origin/
cat <<EOF >.vagrant-openshift.json
{
"cpus": "4",
"memory": "2048"
}
EOF
vagrant up
vagrant ssh
もう修正がマージされたので大丈夫だと思いますが、vagrant upでMssing required arguments: libvirt_uri (ArgumentError)が出力される場合はFix incorrect ENV["VAGRANT_LIBVIRT_URI"] if statement by nekop · Pull Request #3862 · openshift/origin · GitHubの変更を適用してください。
VMにsshしたら、OpenShiftの最新版をビルドします。
cd /data/src/github.com/openshift/origin/ # vagrant ssh後のカレントディレクトリなので移動してなければ不要 make clean build
ビルドが終わったら起動します。systemdの定義ファイルは最初からVagrant環境に配置されており、ビルドしたバイナリを指すようになっています。
sudo systemctl start openshift
OpenShiftは起動時にcertファイルなどを自動生成します。systemctlで起動した場合は/以下に生成され、/openshift.local.configのようなサブディレクトリが3つできます。
Vagrant環境では/etc/profile.d/openshift.shにPATHやKUBECONFIGが指定されていて、sudoなどを使う場合にちょっとトリッキーな挙動になることに注意してください。vagrantユーザではoc, oadmコマンドにPATHが通してあり、KUBECONFIGがadmin権限のものを指しているのでocコマンドなどの操作はデフォルトでOpenShiftのadmin権限となります。sudoは環境変数を明示的に渡さない限り環境変数を引き継がないですし、profileも読み込まないので、oc/oadmなどの実行時にこの点に引っかかるとoc: command not foundや、KUBECONFIGが必要なのに存在しない場合のError in configuration: default cluster has no server definedというメッセージが表示されます。
初期状態を確認してみましょう。
oc get all
10行くらいいろいろ出力されますが、kubernetesのサービスだけが見えると思います。
インストール後に最初はoadmコマンドを利用してDocker registryをデプロイするのですが、sudoを利用するのでoadmコマンドを事前にwhichに渡してフルパスに変換しています。
sudo `which oadm` registry --create --credentials=/openshift.local.config/master/openshift-registry.kubeconfig --config=/openshift.local.config/master/admin.kubeconfig
もう一度oc get allを実行してみてください。docker-registryがPendingステータスで見えるはずです。ここではdocker pullが行われているので、実際にDocker registryが起動してRunningの状態になるまで2分程度かかると思います。oc get pod, oc get pod --watch, oc get evなどでステータスを確認できます。
次にデフォルトのImageStreamをインポートします。
cat ./examples/image-streams/image-streams-centos7.json | oc create -n openshift -f -
ここまででAll-in-one構成のOpenShift Origin v3のインストールは完了です。
次回は一般ユーザからこのOpenShiftを利用する手順を紹介します。ちなみに、このVagrant環境上で一般ユーザを試したい場合は、デフォルト設定されているadmin設定ファイルへの参照を消す必要があるので、unset KUBECONFIGを実行する必要があります。unsetした場合のKUBECONFIGのデフォルトは$HOME/.kube/configになります。
Vagrantではなく他の方法としてdockerで動かすというのもありますが、Fedora/RHEL/CentOS以外では動作しないようです。
Fedora 22でブリッジ接続
インストール後はeno1で普通の有線LAN接続なのを、ブリッジに変更して仮想マシンもブリッジインタフェース使うことで同じネットワークに繋げられるように。
sudo cp /etc/sysconfig/network-scripts/ifcfg-eno1{,.org}
sudo vi /etc/sysconfig/network-scripts/ifcfg-eno1
以下を追加、コメントアウトは削除。
NM_CONTROLLED=no # BOOTPROTO=dhcp BOOTPROTO=none BRIDGE=br0 DEVICE=eno1
ifcfg-br0を新規作成。
sudo vi /etc/sysconfig/network-scripts/ifcfg-br0
内容はこれだけ。
NM_CONTROLLED=no TYPE=Bridge BOOTPROTO=dhcp NAME=br0 DEVICE=br0 ONBOOT=yes
終わったらブリッジインタフェースを作ってeno1を追加してネットワークをリスタートして反映させる。(ifcfg書いたのでbrctlいらないかも？未確認)
sudo brctl addbr br0 sudo brctl addif br0 eno1 sudo systemctl enable network sudo systemctl restart network
起動時に上記のifcfg設定を処理してくれるnetwork.serviceはデフォルト無効なので、このブリッジ定義を使うためには有効化と起動を行う必要がある。systemctl restart networkでdhclientが既に起動されている状態の場合エラーになるかもしれないけど次回起動時には正常な状態になるので放置。
ip addrでIPアドレスがbr0のほうについていて、普通に通信できるのを確認できればおしまい。
あとはlibvirtでネットワークブリッジにbr0を使うようにすればホストマシンと同じネットワークになる。
Fedora 22 WorkstationのLive USBで作業用サーバ
Fedora 22 WorkstationのLive USBはいつも使うので持っているのだけど、ちょっと作業用のサーバを作るのに使ったらインストーラでインストール内容がカスタマイズできないようで困った。今回の用途はsshして使うだけなのでGUIは必要ない。
ちょっと調べたけど手軽な方法は見当たらなかったので、素直にGUI込みでインストールしてCtrl-Alt-F2でtty2を開いてログインし、昔の用語で言うところのデフォルトのrunlevelを変更してGUIを無効化する。今はsystemdが起動時にどの依存関係を起動するのか、がrunlevelに相当する。
sudo systemctl set-default multi-user.target
これでGUIが起動しなくなる。
デフォルトがgraphical.targetで、multi-user.targetが名前が直感的ではないけどいわゆる普通のテキストモードだ。この名前はたぶんシングルユーザモードであるrescue.targetからきている。
tty2からsshdだけstart/enableしてGUIログイン画面でてるけど画面は気にしないで放置、というのもアリだけど使ってないものが動いてるのも微妙だしね。
WildFly 9.0.0.Final リリースしました
Java EE 7アプリケーションサーバであるWildFly 9.0.0.Finalがリリースされました。WildFlyのサイトからダウンロードできます。
リリースノートはこちら。起動時間は8.2.0.Finalとほぼ変わらないようで1.5秒台でした。
10:14:47,764 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Final (WildFly Core 1.0.0.Final) started in 1535ms - Started 203 of 379 services (210 services are lazy, passive or on-demand)
開発の先っちょmasterブランチはだいぶ前にWildFly 10になっていて、Java 8が必須になっています。WildFly 10がリリースされた後、それをベースとしてJBoss EAP 7がリリースされます。
