内容は Self-Hosted Kubernetes の紹介と、 OpenStack 上で Self-Hosted K8s をデプロイする自作ツールの紹介。
]]>
内容は Self-Hosted Kubernetes の紹介と、 OpenStack 上で Self-Hosted K8s をデプロイする自作ツールの紹介。
]]>思ったよりも時間がかかってしまったがようやくクラスターを構成できた。 当初思ってたように全て Minnowboard に載せるというのは実際にアプリを乗せた際、 (gitlab やら Gluster) メモリが問題になりそうだったので、 結局ワーカーノードは ECS LIVA Z の Pentium モデルと相成った。
ワーカーノードには USB でストレージを繋いで Gluster で管理。今流行りのハイパーコンバージド？ 結局 Gluster 公式のプロビジョナーである Heketi に不満を感じた ので自分でプロビジョナーを書いてしまった。 その話を書こう書こうと思っていたのだけどめんどくさくてブログには書いておらず。
なぜ自宅 Kubernetes クラスターの構築にこんなに時間がかかってしまったかというと、 主に Kubernetes のデプロイに使うスクリプトに意外に時間を食ってしまったから。
Kubespray やら Kops やら kubeadm やら Rancher やらを色々検討はしてみたものの、 自分好みのクラスターを構築しようと思ったら自分で構築するのが一番という身もふたもない結論に。 これも結局デプロイツールを自分で書いた。
最初は Kubernetes The Hard Way の内容を スクリプト化して、k8s 各コンポーネントの ClusterRoleBinding をちゃんと設定してあげたもの程度だったのだが、 Self-Hosted Kubernetes 化して keepalived/haproxy で冗長化、 DNS に CoreDNS 採用とかしてたら手間取った。
Self-Hosted は面白かったので次の 日本OpenStackユーザ会 第36回勉強会 で話す予定。もし枠が空いていたら次次回の Kubernetes Meetup の LT でも。
]]>なぜかずっとコンテナのボリュームどうしようか、、と悩んで止まってましたが、 ようやく目処がついてきたので進捗を。
とりあえずボリュームには GlusterFS を使うことにした。 NFS、という選択肢もあったが可用性を担保しようとするとストレージを RAID で構成しなければならなかったり(RAID はなんか好きじゃない。)、 結局 NFS Server が SPOF になるんじゃないかという点が気に食わなかった。 もちろん、NFS Server を Act-Standby にしたり最近は Failover できるらしいが、 とりあえず無視する。なんとなく Gluster が使いたかった。
Gluster を使えば、
すごい！
動的に Gluster のボリュームをプロビジョニングしてコンテナのボリュームとして使う方法もあるのだけど、 どうも微妙なので、とりあえずはすでに存在する Gluster のボリュームを Kubernetes の Persistent Volume として登録する方法。
ぶっちゃけ kubernetes/examples の GlusterFS の内容そのままだが。
ボリュームを提供する Gluster Cluster のエンドポイント情報を Kubernetes に教えるために、
Endpoint を作る必要がある。
kind: Endpoints
apiVersion: v1
metadata:
name: glusterfs-cluster
subsets:
- addresses:
- ip: "192.168.1.111"
ports:
- port: 1
- addresses:
- ip: "192.168.1.112"
ports:
- port: 1subsets の addresses にそれぞれ GlusterFS Cluster のノードのアドレスを書く。
ports 内の port は 1-65535 以内の数値ならなんでもいいらしい。
作った Endpoint を永続化するために関連する Service を作っておく必要があるらしいが、
具体的にはどういう意味があるのかわかっていない。
とりあえず Service を作らずに Endpoint だけで運用しているが今の所困ったことはないが…。
kind: Service
apiVersion: v1
metadata:
name: glusterfs-cluster
spec:
ports:
- port: 1普通の Service と違うところは selector が無いところで、
そのおかげでKubernetes はこの Service に関連する Endpoint を勝手にいじったりすることがなくなる。
Endpoint さえ作ってしまえばあとは PV を作れば良いだけ。
kind: PersistentVolume
apiVersion: v1
metadata:
name: gluster-volume
spec:
accessModes:
- ReadWriteMany
capacity:
storage: 2Gi
glusterfs:
endpoints: glusterfs-cluster
path: test-volume
readOnly: falseEndpoint の名前。とりあえず、これを PV の数だけ一個一個手作業でやって行くのは面倒。
]]>SSD を買ってしまった。SATA コネクタもあるし。
が、問題は SATA コネクタはあるが SATA の電源をどこから確保するか。 電源のためだけに USB を一個潰すのもなんだかなあと思うし、 かと言って別電源を持ち出すのも気持ち悪い。
調べたところ SATA の電源ケーブルは 4 本出てはいるものの、 実際に使っているのは 5V の線だけらしい。 そして 5V なら CPU Fan 用のコネクタ (J2) か Low Speed Expansion (JP2) の Pin#2, #3 あたりから供給可能なのでそこらあたりから持ってくるのが 常道の模様。
ただし、そのためには SATA の電源コネクタから 2pin コネクタに変換するケーブルが必要になってくる、 のだが日本にはどうやら売ってない、ので作った。
ケーブルを切ったりつなげたりするのは正直初めてだったので、 そもそも仕様がよくわからなったのだが、 どうやら 2pin のファンコネクタは Molex の 5051 の 2pin というもので、 Molex 5159 というピンをケーブルに圧着して繋ぐらしい。
さらにはコネクタピンの対応するケーブルの仕様が AWG サイズ 22 - 28 まで、という、 (そもそも AWG ってなんじゃそりゃ) みたいなところから、 コネクタピンをどうやってケーブルに圧着するのか、 ケーブルの被膜をどうやって剥くのかみたいなところまで調べて非常にめんどくさい。
SSD をマウントするためにケースを別に買ったり、色々したので、 結局 Minnnowboard 買うんだったら Intel NUC とかでも良かったなあと今更ながらに。
]]>etcd3を CoreOS で使ってハマったことなどを。
Kubernetes 1.6 がリリース
された。
早速使ってみようと思ったのだが、
どうやら 1.6 からストレージのバックエンドが etcd3 になったらしい。
それはいいのだが、CoreOS のドキュメントを見るに、
etcd を
cloud-config で起動する方法
は etcd2 のものばかりで、
etcd3 をどうやって起動すればいいのやら。
そもそも CoreOS に etcd3
のバイナリが含まれてなくないかい？
いくらかウェブを彷徨った末に、etcd3 は flannel などと同じように、
コンテナとして起動するようになったということに気づく。
service の名前が etcd-member とやらになってたせいで若干わかりづらい。
なにはともあれ、CoreOS 1298.6.0 における etcd-member の Unit ファイルを確認する。
[Unit]
Description=etcd (System Application Container)
Documentation=https://github.com/coreos/etcd
Wants=network.target
Conflicts=etcd.service
Conflicts=etcd2.service
[Service]
Type=notify
Restart=on-failure
RestartSec=10s
TimeoutStartSec=0
LimitNOFILE=40000
Environment="ETCD_IMAGE_TAG=v3.0.10"
Environment="ETCD_NAME=%m"
Environment="ETCD_USER=etcd"
Environment="ETCD_DATA_DIR=/var/lib/etcd"
Environment="RKT_RUN_ARGS=--uuid-file-save=/var/lib/coreos/etcd-member-wrapper.uuid"
ExecStartPre=/usr/bin/mkdir --parents /var/lib/coreos
ExecStartPre=-/usr/bin/rkt rm --uuid-file=/var/lib/coreos/etcd-member-wrapper.uuid
ExecStart=/usr/lib/coreos/etcd-wrapper $ETCD_OPTS
ExecStop=-/usr/bin/rkt stop --uuid-file=/var/lib/coreos/etcd-member-wrapper.uuid
[Install]
WantedBy=multi-user.target
これだけ見ると etcd-wrapper に起動オプションとして $ETCD_OPTS を環境変数として渡せばいいだけに見える。
が、自分は TLS クライアント認証を有効化して利用したいので、
どうにかして etcd-wrapperから起動されるコンテナに、
証明書を保存しているディレクトリをマウントさせなければならない。
その場合、$ETCD_OPTS にオプションを渡すだけでは無理だろうと想像できる。
ちらっと、etcd-wrapper のソースをのぞいて見ると、
$ETCD_SSL_DIR
という環境変数が目に見える。
そこで思考停止して drop-ins などで Environment="ETCD_SSL_DIR=/etc/kubernetes/ssl"
などとしてやると
(ホスト上の /etc/kubernetes/ssl に証明書を置いておいたので。)
当然動かない。
デフォルトで ETCD_SSL_DIR は /etc/ssl/certs を指していて、
etcd が利用するデフォルトの CA の証明書ディレクトリとして利用されているっぽい。
これを変なところに変更してやると、
ディスカバリ URL として使ってる、
https://discovery.etcd.io/ の証明書が invalid であると怒られる羽目となる。
そりゃそうだ、CA の証明書が無いんだから。
最終的には https://discovery.etcd.io/ を使っている限り、
ETCD_SSL_DIR を変更するのはあまり良い方法では無いということがわかった。
そうすると解決する方法としては、
/etc/ssl/certs に保存する。/etc/kubernetes/ssl をマウントする。の二案ということになる。
案1は、元の CA の証明書は /usr/share/ca-certificates にあってシンボリックリンクになっているだけとはいえ、
システムにインストールされた証明書と同じ場所にオレオレ証明書をインストールするのはなんとなく憚られたため、
案2とすることにした。
結論を言ってしまうと、$RKT_RUN_ARGS という環境変数があるのでそれに渡してやればいい、
ということになる。
最終的には以下のような cloud-config になった。
...
units:
- name: etcd-member.service
command: start
drop-ins:
- name: 00-override.conf
content: |
[Service]
Environment="RKT_RUN_ARGS=--uuid-file-save=/var/lib/coreos/etcd-member-wrapper.uuid \
--volume etc-ssl-k8s-certs,kind=host,source=/etc/kubernetes/ssl,readOnly=true \
--mount volume=etc-ssl-k8s-certs,target=/etc/kubernetes/ssl"
Environment="ETCD_IMAGE_TAG=v3.1.2"
Environment="ETCD_NAME=master01"
Environment="ETCD_DISCOVERY=https://discovery.etcd.io/XXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Environment="ETCD_ADVERTISE_CLIENT_URLS=https://192.168.1.111:2379"
Environment="ETCD_INITIAL_ADVERTISE_PEER_URLS=https://192.168.1.111:2380"
Environment="ETCD_LISTEN_CLIENT_URLS=https://192.168.1.111:2379,http://127.0.0.1:2379"
Environment="ETCD_LISTEN_PEER_URLS=https://192.168.1.111:2380"
Environment="ETCD_CLIENT_CERT_AUTH=true"
Environment="ETCD_CERT_FILE=/etc/kubernetes/ssl/apiserver.pem"
Environment="ETCD_KEY_FILE=/etc/kubernetes/ssl/apiserver-key.pem"
Environment="ETCD_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
Environment="ETCD_PEER_CLIENT_CERT_AUTH=true"
Environment="ETCD_PEER_CERT_FILE=/etc/kubernetes/ssl/apiserver.pem"
Environment="ETCD_PEER_KEY_FILE=/etc/kubernetes/ssl/apiserver-key.pem"
Environment="ETCD_PEER_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
Environment="ETCD_PEER_CA_FILE=/etc/kubernetes/ssl/ca.pem"
...
drop-ins で RKT_RUN_ARGS を上書きするのは良いんだけど、
デフォルトの RKT_RUN_ARGS もあるのでちょっと気持ち悪い。
Environment="RKT_RUN_ARGS=${RKT_RUN_ARGS} --volume etc-ssl-k8s-certs,kind=host,source=/etc/kubernetes/ssl,readOnly=true --mount volume=etc-ssl-k8s-certs,target=/etc/kubernetes/ssl"
みたいにできれば良いのだが…。
]]>It's alive! My home Kubernetes cluster is alive! pic.twitter.com/BH4P6ysbJJ
— Ian Lewis (@IanMLewis) 2016年12月23日
始まりは去年の12月に見たこのツイート。一瞬で心奪われて思いました、「俺もやる！」 次の日には Minnowboard Turbot を発注してました。6台。
海外からの購入の割に届くのは早く、次の週には実機を手にしていたのですが、それからが長かった。 最終的にはこの6台に Kubernetes をインストールして自鯖の環境を全部これに引っ越したかったのですが、 そもそもベアメタル上に Kubernetes をどうインストールしよう、と言うことに時間がかかり。 仮想環境上で試行錯誤を繰り返して目処が見えたのでようやく実機に OS をインストールすることにしました。
CoreOS のドキュメントを見る限りディスクに CoreOS をインストールする手順は、
Live CD などで (PXE とかでもいい) テンポラリに OS を起動しておいて、
そこから coreos-install と言うスクリプトでターゲットとするディスクに CoreOS をインストールする
と言うものでした。
が、家の環境に PXE のセットアップとかしたくないし、
かといっていちいち Minnowboard にディスプレイとキーボード繋いで coreos-install ってするの面倒だなあと。
RaspberryPI みたいに SD カードに OS を dd して電源ボタン押すだけで良いとかないのかいなと思ったわけですよ。
coreos-install を読むとりあえず coreos-install を 読んで見ました。
色々ごちゃごちゃやっているようだけど、 自分の興味あるところだけ要約すると、
してるだけでした。何だ、SDカードにあらかじめインストールしておけるじゃん。
最終的に Kubernetes をクラスターにインストールすることを念頭にしてるので、 ちょびっとごちゃごちゃしてるけど、 イメージを作成するスクリプトを書いた。
etcd と Kubernetes を https で起動したかったので、 あらかじめ TLS サーバ/クライアント証明書をイメージに埋め込んでおくことにした。
利用した user-data はこんな感じ。ネットワークデバイス名は enp2s0 らしい。
#cloud-config
hostname: master01
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0ol7jQ4umQMrE1qtXnyeYk/23g6zVJyVPh0+rljElu/7zj6iJZtixxs+LebPH6mZP13RIGPP0GlrSXRVBj9F2pjb/Y/PMyHBq3+BMeiYhn6XmNMwtTK2O69vvFZQi0M3wTVSezP9OxxrPay+eCXkGVi8lnh6ZDMrvSKI2c5SQ7wFJfT/4XTxzcP2gsotRV0rzADie1EF4MYke+ZJuiwnrFbZpeogrNtSvivR4f/g0/fD8NOjCKgbk4uY//6YhEqNaGhm0wABKt0MtimmxLLe2kosoFS539t88y5tD4ispcxlOAtVKZEL1ogf0VRrcBWSTfIiJty5vw6aRTfoFwuzZ ootsuka@mxs.nes.nec.co.jp
coreos:
etcd2:
name: master01
discovery: https://discovery.etcd.io/XXXXXXXXXXXXXXXXXXXXXXXXXXX
advertise-client-urls: https://192.168.3.111:2379
initial-advertise-peer-urls: https://192.168.3.111:2380
listen-client-urls: https://192.168.3.111:2379,http://127.0.0.1:2379
listen-peer-urls: https://192.168.3.111:2380
client-cert-auth: true
cert-file: /etc/kubernetes/ssl/apiserver.pem
key-file: /etc/kubernetes/ssl/apiserver-key.pem
trusted-ca-file: /etc/kubernetes/ssl/ca.pem
ca-file: /etc/kubernetes/ssl/ca.pem
peer-client-cert-auth: true
peer-cert-file: /etc/kubernetes/ssl/apiserver.pem
peer-key-file: /etc/kubernetes/ssl/apiserver-key.pem
peer-trusted-ca-file: /etc/kubernetes/ssl/ca.pem
peer-ca-file: /etc/kubernetes/ssl/ca.pem
units:
- name: etcd2.service
command: start
- name: 00-enp2s0.network
runtime: true
content: |
[Match]
Name=enp2s0
[Network]
DNS=8.8.8.8
Address=192.168.3.111/16
Gateway=192.168.11.1
さて、適当な Linux マシンでイメージを作成したら、 今度はそれを Mac に持ってきて、SD カードに書き込む。 (何で Linux マシンから SD カードに直接書き込まないのかと言うと、 VM だから SD カードマウントするのめんどかったからです。)
手順は、
diskutils で SD カードの場所を調べる。dd で書き込み。書き込みが終わったら、とうとう Minnowboard の起動です。 SD カードを刺して電源繋げば起動するはず…。
が、起動しない。
Power up the MinnowBoard Turbot を読んだところ、
UEFI shell とやらがデフォルトで起動してしまう模様。
とりあえずドキュメント通りに HW の時刻を合わせ、boot order を変更したのちに、
再度電源オン…。
起動した。
次のエントリで Kubernetes が動いてると良いな…。
]]>
自鯖にオレオレ Cloud Foundry は色々なウェブアプリを色々な環境で突っ込めて便利だなあと思う反面、 一台のサーバにあんなに重厚な仕組みはいらないよなーと思ってたところに docker ですよ。
概要 とか 使い方 とかはすでに他のえらい人たちが紹介してるので、 使ってて気づいた便利な使い方を紹介ですよ。
いままで Remote API を http で公開してたので、 簡単にリモートから docker の API を叩けたのですが最新の Docker ですとデフォルトが Unix ソケットを利用するように変更されてしまっているので起動時にわざわざ http でも API を公開するよと指定しなくちゃならない。
bind するホストやポートやソケットは複数設定することができるので、 デフォルトのソケットも bind しつつ、http でも API を公開したい場合は以下のようになる。
# docker -d -H="tcp://0.0.0.0:4243" -api-enable-cors -H unix:///var/run/docker.sock
ホスト(docker)を再起動した時にコンテナも自動で再起動してほしいなあ、
と思っていたら、-r オプションで解決だった。
# docker -d -r
そのものがあった。crosbymichael/dockerui -- A web interface for docker.
docker のイメージも公開されているので pull して run してやればすぐ使える。
# docker pull crosbymichael/dockerui
# docker run -d crosbymichael/dockerui /dockerui -e="http://192.168.1.9:4243" -p 9000:9000
-e のオプションで docker を起動しているホストのアドレスを指定してやる。
-p のオプションでホスト側とコンテナ側のポートを同時に指定できるようになってた。
# docker run -d yuanying/mysql -p 3306:3306
これで毎回サーバを再起動するたびに mysql のポートが変更してしまうとかいうアホな事態を避けられる。
Dockerfile はこんな感じになった。
# Ruby
#
# VERSION 0.0.1
FROM ubuntu:precise
# make sure the package repository is up to date
RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list
RUN apt-get update
RUN apt-get -y install build-essential openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison nodejs subversion
RUN curl ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p247.tar.gz | tar zxvf -
RUN cd ruby-2.0.0-p247 && ./configure && make && make install && gem install --no-ri --no-rdoc bundler
以下のような設定ファイルになった。
root@precise64:/home/vagrant# more /etc/init/docker.conf
description "Run dockerd"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
script
/usr/local/bin/docker -d -H="tcp://0.0.0.0:4243" -api-enable-cors -H="unix:///var/run/docker.sock" -r
end script
久しぶりにサーバを Mac から Linux にしたくなってきたと思ったら、 買ってた。Intel Next Unit Computing とやらを。
CPU がオンボードなベアボーンであるため、メモリと SSD を購入。 あと必要なのは、テレビにつなげるための HDMI ケーブル、 電源をつなぐためのミッキータイプなるアダプターケーブル。
16GB メモリを装着したところ。 ノート用のメモリの大きさと、マザーボードの大きさのスケール感がどうしてもおかしい。
SSD なんかもこの大きさで 256GB。
AirMac よりも遥かに小さい自宅サーバが完成。 家で一番小さいマシンのくせに一番スペックが高い。頭おかしい。
インストールしたのは Ubuntu Linux 12.04。 これに docker とリバースプロキシ入れてアプリケーションを運用予定。
]]>
CloudFoundry という PaaS 環境を自分で作れるオープンソースがあるのだが、 いかんせんそれを構築しようとすると、IaaS が必要だったり、 古いバージョンしかインストールできなかったりと気軽に最新バージョンを試すための環境を作るのがめんどくさい。
ところがつい最近、Nise-BOSH という、 気軽に Cloud Foundry のコンポーネントのインストールを試すことができるツールが出てきたので、 それを使って 1VM 上に Cloud Foundry の必須コンポーネントを全部インストールしてやって、 実際に動作する Cloud Foundry を 1VM で構築してみた。
試した環境は、MacBook Air 11-inch, Late 2010 @ 4GB 上に Vagrant で構築した、 こんな構成。
本当は、以下を説明する前に BOSH とはなんぞやとかそのような説明をするのが筋と言うものだと思うが、 面倒なので割愛する。slideshare に すごいBOSHたのしく学ぼう という資料があがってるのでそれですべてを理解してもらいたい。
理解したなら、Cloud Foundry には cf-release という BOSH 用のレシピが公開されていて、
そのレシピ中の以下の Job Template をインストールすれば、
Cloud Foundry が構築されるということを把握できているはずであろう。
以降の操作はすべて Vagrant で起動した VM 上で root でおこなう。 だって頻繁に root 権限が必要になって面倒なのですもの。
本来ならば、本物の BOSH を利用して cf-release をインストールするのが手順なのだが、
そのためには aws やら OpenStack などが必要になってくるので、
自分の PC 上に Cloud Foundry をインストールするために OpenStack をインストールするだとかよくわからない行動をとることになってしまいがち。
そこで Nise-BOSH ですよ。
apt-get install debootstrap runit
cd /vcap
git clone https://github.com/nttlabs/nise_bosh.git
cd ./nise_bosh
git remote add yuanying https://github.com/yuanying/nise_bosh.git
git fetch yuanying
git checkout -b multi-monitrc-spike yuanying/multi-monitrc-spike
bundle install
./bin/init
reboot
以上で Nise-BOSH のインストールが完了。vap ユーザの作成や必須パッケージがインストールされて、
Cloud Foundry がインストールされる準備が整う。
ちなみに、本家の Nise-BOSH を利用しても良いのだが、
今のところ本家では複数の Job Template を 1VM にインストールすることを想定していないので、
複数 Job Template のインストールに対応しているブランチを利用することにした。
Cloud Foundry のインストールの前に、cf-release というリリースのソースから、
リリースを作成する必要がある。
cf-release は本家のものを使いたいところだが、1VM で動くことを考えていないのかわからないが、
そのまま使うとうまくインストールできないため、
これまたワタクシ作成のパッチを適用してあげたものを利用する。
cd /vcap
git clone https://github.com/cloudfoundry/cf-release.git
cd ./cf-release
git remote add yuanying https://github.com/yuanying/cf-release.git
git pull yuanying master
./update
gem install bosh_cli
bosh create release --force
リリースをダウンロードした後に、bosh create release でリリースを作成した。
BOSH はシステムの構築のために、リリースと、Deployment Manifest という、
そのシステムをどういう構成で構築するのかの情報を記述したファイルを必要とする。
今回はとりあえず 1VM で動くための Deployment Manifest を用意したのでそれを利用する。
ドメインは自分の利用したいドメインに修正すること。xip.io を使うと便利かもしれない。
ダウンロードした Deployment Manifest を、
micro-ng.yml という名前で保存した後に、nise_bosh コマンドで
Cloud Foundry の各コンポーネントをインストールする。
cd /vcap/nise_bosh
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 postgres
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 nats
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 gorouter
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 dea_next
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 health_manager_next
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 cloud_controller_ng
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 serialization_data_server
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 uaa
yes | bundle exec ./bin/nise-bosh /vcap/cf-release /vcap/micro_ng.yml -n 127.0.0.1 vcap_redis
インストールした Cloud Foundry を、以下のコマンドで実行する。
cd /vcap/nise_bosh
mkdir -p /var/vcap/shared
chown vcap:vcap /var/vcap/shared
mkdir -p /var/vcap/store
./bin/run-job start postgres
./bin/run-job start nats
./bin/run-job start gorouter
./bin/run-job start dea_next
./bin/run-job start health_manager_next
./bin/run-job start cloud_controller_ng
./bin/run-job start serialization_data_server
./bin/run-job start uaa
./bin/run-job start vcap_redis
メールアドレス micro@vcamp.me、パスワード micro というアカウントができているので、 適当なクライアントで試せます。起動して安定するまで時間がかかるので、コーヒーを一杯飲んでから試すのが良いかもしれない。
cf target http://api.192.168.33.10.xip.io
cf login micro@vcap.me
んで、利用したのが、
ソースコードは github で公開されている。
とりあえず試す。
gem からインストールする。
$ sudo gem install gunark-rubycas-server
Password:
For more information on RubyCAS-Server, see http://code.google.com/p/rubycas-server
If you plan on using RubyCAS-Server with languages other than English, please cd into the
RubyCAS-Server installation directory (where the gem is installed) and type `rake mo` to
build the LOCALE_LC files.
Successfully installed builder-2.1.2
Successfully installed markaby-0.5
Successfully installed picnic-0.8.1.20100201
Successfully installed gunark-rubycas-server-0.8.0.20090812
4 gems installed
とりあえず一回起動すると /etc/rubycas-server/config.yml
というファイルが生成されるので、それをいじる。
$ sudo rubycas-server
$ sudo vim /etc/rubycas-server/config.yml
とりあえず動かすだけなので、行う設定は、
rake のタスクに、
というのがあるので、それを使っても良かったのだけれども、 テストに使うだけなら rubycas-server のプロジェクトページから、 テスト用の pem ファイルをダウンロードしてそれを使っても良いようだ。
ダウンロードしてきた pem ファイルを適当な場所に保存。今回は /etc/rubycas-server/ssl.pem として保存した。
設定ファイルをいじって保存した pem ファイルを使うように変更する。
$ sudo vim /etc/rubycas-server/config.yml
$ diff -u config.old.yml config.yml
--- config.example.yml 2010-04-07 17:10:24.000000000 +0900
+++ config.yml 2010-04-08 10:45:12.000000000 +0900
@@ -30,7 +30,7 @@
server: webrick
port: 443
-ssl_cert: /path/to/your/ssl.pem
+ssl_cert: /etc/rubycas-server/ssl.pem
# If your private key is in a separate file from the cert
設定ファイルを見ると、mysql の casserver というデータベースを利用してるようなので、 作ってやる。
$ mysql5 -uroot
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 32
Server version: 5.1.45 Source distribution
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> create database casserver default character set utf8;
Query OK, 1 row affected (0.65 sec)
rubycas-server がどうやって username/password を使って認証を行うのか設定をしてやる。
いくつか認証方法があって、
Google のアカウントを使う方法が設定も簡単で面白そうなので、試してみることにした。
$ sudo vim /etc/rubycas-server/config.yml
$ diff -u config.old.yml config.yml
--- config.example.yml 2010-04-07 17:10:24.000000000 +0900
+++ config.yml 2010-04-08 10:45:12.000000000 +0900
@@ -262,8 +262,8 @@
# would use to log in to Google services like Gmail). This authenticator
# requires no special configuration -- just specify its class name:
#
-#authenticator:
-# class: CASServer::Authenticators::Google
+authenticator:
+ class: CASServer::Authenticators::Google
#
# Note that as with all authenticators, it is possible to use the Google
# authenticator alongside other authenticators. For example, CAS can first
これらの設定が終わったら、再度 rubycas-server を起動してみる。
$ sudo rubycas-server
認証サーバにブラウザで接続してみる。
できたできた。
つぎは passenger で動かしてみたい。
]]>