RancherのOpenStack Driverを試す

少し前に試したけど記録していなかったのでその記録。Rancherは2015年に RancherOSの起動時の仕組みを調べて以降あまり追っていなかったのだけど、最近話題なのとコンテナオーケストレーション周りをキャッチアップしないとな、ということで触ることにした。

構成

こんな感じの構成になる予定。OpenStackのAPIを叩くため、専用のネットワークに繋げている。

Rancher Serverの構築と準備

まずはRancherServerを構築する。今回は、OpenStack上にインスタンス(rancher-server)を1台作成し、その上のDockerに起動する。イメージは素朴にubuntu-16.04を選択し、 https://docs.docker.com/engine/installation/linux/ubuntu/ に従って、Dockerをインストールする。インストールが終わったら、rancherを起動。
ふむふむ。

rancher-serverにはFloatingIPを付与してあるので、http://floating-ip:8080/ でアクセスできる。なお、8080番ポートをSGで許可しておく必要がある。

画面が見えた。次は、ユーザを作成する。ADMIN=>AccessControllから作成できる。ユーザを作ったらKubernets用のEnvironmentを作成する。Default=>ManageEnvironmentから追加できる。EnvironmentTemplateにはKubernetesを選択し、AccessControlでは先ほど作成したユーザがownerになるようにする。作成したら、それをデフォルトにして、Environmentの準備は完了。

Kubernetes用のホスト登録

さて、次はKubernetesを動かすためのホストを追加していく。OpenStackのインスタンスをホストにしたいので、MachineDriverを有効にする。ADMIN=>MachineDriversからOpenStackをActivateしよう。

次はホストの追加を行う。画面からポチポチ作っても良いが、コマンドラインからやろう。画面右下からCLIをダウンロードできる。CLIからrancher-serverを使うため、URLとアクセス用のキーを登録する。キーはAPI=>Keysから生成できます。

さて、ホストの追加だが…こんな感じでできる。イメージにはUbuntuを使ってみる。

注意点としては、private-key-fileはrancher-serverが見える場所でないといけない、という所だ。今回はrancher-serverをコンテナで起動したので、コンテナ内に配置する。

また、rancher agentが使用するAPI用のURLを変更しておく。http://floating-ip:8080/ になっているが、これだとrancher agentがURLをうまく認識しなかった。SGまわりかもしれないが、今回はrancher-internalネットワーク内のアドレスを指定してやる。
 pemの配置とURLを変更したら、コマンドを実行する。
Rancher側にホストが追加され、インスタンスの作成やDockerのインストールが始まった!
しばらく待つと…起動した!
KUBENETES=>Dashboardからk8sのダッシュボードも開くことができるし、KUBENETES=>CLIからkubectl用のコンフィグもダウンロードできる。

ホストを増やす

しかし、これだとホストが1台だけで面白みがないので、台数を増やしてみる。ついでに、ubuntuからrancherOSに変えてみよう。イメージとssh-userを変更して、2台ほど追加する。

すると…3台にちゃんと増えた。

ダッシュボードを見ても、ちゃんと増えてますね。

どこまでKubetnetes側を触れるのか分かっていないけど、かなり手軽に試すことができるなあ。

ホストを消してみる

ここで、せっかくなのでおもむろにk8s-1を消してみて、どうなるのか試すことにした。Rancher側でホストを削除すると、OpenStack側でもインスタンスが消える。
少し時間がかかったが、消したホストでのみ動いていたものが別のホストで起動したようだ。ダッシュボードも見えるようになった!

まとめ

RancherServerをOpenStack上に用意し、OpenStack MachineDriverを使ってホストとしてOpenStackのインスタンスを使ってみた。気になる所としては、以下の3つがある。

  • Floating IPをつけないとインターネットに繋がっていないように見える
    • FIPをつけないとホストの構築がうまくいかないようだ。Rancherの問題なのか、OpenStack側の問題なのかの調査が必要そう。
  • OpenStackのAPIを使うためのパスワードが各ホストのView in APIから見えている
    • APIを使うための認証情報は見えないようにした方が安全じゃないかな…
  • ホストを消す時にキーペアが消えることがある
    • 条件がよくわかっていないけどこれも割と困るのでは。

PuppetのFacterでもrspecしたい!

そういうわけです。Rubyなので、Rubyのテストツールでテストできると複雑なCustomFacterの維持・管理がしやすいですよね。

今日は「あるFacterについてのテストを2つ以上書くときテスト毎にそのFacterの値をクリアする」ということをしたのでそれについて書きます。

まずはテストを1つ書いてみる

ホスト名からタグ(何のタグか、は気にしない)を生成するFacterのテストを書く、ということにします。最初のコードはこれ。雑…

テストはこうしましょう。CustomFacter内で別のFacterを使っているので、allowとreceiveを使ってstub化します。

テストを実行します。いいですね。

2つ以上のテストがあると?

さて、次です。いろいろなホスト名に対応したいので、安直にこうしてみます。

テストはこうなりますね。

よさそうです。テストを実行してみましょう。

うーむ、失敗してしまった。追加した「hostname の prefix が piyo の場合」がうまくいっていません。これは、1つ前のテストで一度tag facterが呼び出されたため、その値がメモリに保持されてしまっているためです。

解決策

解決策としては、テスト毎にtag facterの結果をクリアしてやればよい。ベストかどうかは自信が無いですが、今回はbefore(:each)で以下を実行して解決しました。

クリアしたいFacterをピンポイントでflushしてやります。Facter.clearというメソッドもあるのだけど、それを実行すると他のものも消えてしまって面倒だった。最終的なテストコードはこうなります。

実行すると、テストは2つとも通ることが確認できます。

これで、少ないコードでCustomFacterのテストを書けるようになりました。実際のCustomFacterは30行程度のものなので、テストがなくてもまぁ分かるのだけど、滅多に触らないのでテストがあると安心すると思います。

 

OpenStack HeatのResourceGroupを使って任意の台数のインスタンスを起動する

OpenStack Heatを試す の続き。指定した個数のリソースを作成する、ResourceGroupを試します。Mitakaを使用。

まずは使ってみる

例によってテンプレート。resource_defを使って、ResourceGroupで管理するリソースを定義している。

更新前のリソース一覧はこう。

更新する。

リソース一覧はどうなるか?

my_instanceが消え、instancesになった。個別のインスタンスは管理せず、あくまでもグループとして管理すると言うことかな。

インスタンス一覧を見たら、ちゃんと3台いた。なるほど〜。しかし、こうなるとupdate時に台数を指定したくなる。ということでそれも試した。

インスタンスの数をupdateコマンドの引数で指定する

updateコマンドにはparameterオプションがあり、これを使うとコマンド実行時に任意の値を指定することができる。つまり、このオプションでインスタンスの台数を指定すると実行時に台数を自由に選べるということになる。

まずはテンプレート。parameters sectionが増えており、この値をResourceGroupのcountプロパティで参照している。デフォルト値も指定できる。

アップデートコマンドを実行する前にインスタンス台数をチェック。

3台だ。では、台数を変更してみよう。

少し待ってからインスタンス一覧を見てみると、ちゃんと5台になっていた。

インスタンスの数を何台にするか、というのはAutoScallingGroupを使えばCeilometerから取得した情報を使えるが、取得できない情報を使う場合はResourceGroupだけでも十分活用できそう。

RollingUpdateを試す

ドキュメントを見ていると、rolling_update という気になる文字を発見した。これはもしかして…!

update_pollicyとしてrolling_updateを追加。最初書き方が分からなくて四苦八苦してしまった。以下、実行の様子。

2台更新して、5秒待ってから次の2台…というような動きになっていることが分かる。これはいいね。

まとめ

HeatのResourceGroupを試した。思ったよりお手軽で、結構衝撃を受けている。Heatを管理するのが手間そうだなと思っていたけど、その手間をかけてもいいかもしれないと感じた。何でも試してみないと分からないなー。

参考リンク

OpenStack Heatを試す

TerraformにするかHeatにするか悩んで、いったんTerraformにしたのだけど、一応Heatも触っておいた方がいいなあと思ったので軽く触る(決める時に触っておこうよという話だが…)。試すだけであればPackStackが楽。例によって、「触ってみた」以上の情報はない。なお、http://docs.openstack.org/developer/heat/ に全ての情報は書かれており、Mitakaを使って試した。

インスタンスを作成する

何はともあれインスタンスを作ってみよう。以下のようなテンプレートを用意する。

作成。引数の最後で指定しているのはStackの名前で、Stackとはリソースの集合ということのようだ。また、Terraformはインスタンスの作成などは同期実行だが、HeatはOpenStack上のコントローラーがやってくれるので非同期実行である。

スタックの詳細を見てみる。

作成されたリソース一覧。

Horizonからもいろいろ見ることができる。

トポロジーがあった。ほうほう。

リソース一覧。

イベントの一覧も見られる。ここを見ればどのような操作が行われたのか分かるのは便利そう。

というわけで、インスタンスは無事に作成できた。次は、ネットワークを作成してみる。

ネットワークを作成する

manage-networks のサンプルをコピペしてきて、少しリソース名を変更した。

スタックを更新することでネットワークとサブネットが作られる模様。dry-runがあるのでまずはそれを試す。

滅茶苦茶長いが、追加したmy_netとmy_subnetがaddedにあることが分かる。これ、リソース増えた時収集つくのだろうか?

ひとまずそれは置いておき、本番実行する。

完了。ネットワークとサブネットが作成されたのか、イベントを見てみる。なお、CLIからも見られるのでそちらを試す。

ちゃんと作成されているようだ。リソース一覧もCLIから見られるので見てみよう。

ふむふむ〜。トポロジーを見ると、ネットワークとサブネットが追加されていた。

しかし、ネットワークトポロジーを見ると、パブリックネットワークに繋がっているが、今作成したネットワークには繋がっていない。インスタンスのネットワークを設定していないので、当然である。

 

というわけで、次はmy_netにインスタンスを繋げる。

インスタンスをネットワークに繋げる

my_instanceでnetworksを設定してやるだけでよい。なお、Publicネットワークとの接続はなくなるはず。

dry-runの結果は滅茶苦茶長いので省略。

イベント一覧を見ると、インスタンスが更新されていることがわかる。

インスタンスを見てみる。

my_netに繋がっている。ネットワークトポロジーを見ても、my_netに繋がっていることが分かった。

まとめ

Heatを使ってインスタンスを作成した。また、ネットワーク・サブネットを追加したあと、最初に作ったインスタンスをそのネットワークに繋げてみた。

参考リンクは以下の通りです。

KubernetesのDeploymentを試す

k8sでDockerイメージを更新するのはどうやるのかなと思って調べたところ、 Deployments というものがあるようなので触ってみた。

これは Pod と ReplicaSet をまとめて管理できるようなもののようですね。

Deployment用のマニフェスト

mysqlは作成済み。以前作ったReplicationControllerやPodは削除しておいた。

Deploymentを作る

Deploymentを作成します。kubectlコマンドにもそろそろ慣れてきたな。

作成するとDeploymentとReplicaSet、Pod、Serviceが作られる。

イメージを更新したらローリングデプロイされる様子を観察する

この時点ではデプロイされているイメージは0.0.1。

これを0.0.2などに変更すると、そのイメージにローリングデプロイされるはず。

イメージを更新するにはこうやる。簡単〜

デプロイの様子を見守ろう。

 

ちゃんと、少しずつ0.0.1から0.0.2に切り替わっていることを確認できた。すごい!

ロールバックやオートスケールなど

間違えたような場合はロールバックできる。

レプリカセットの台数も設定可能。

まとめ

Deployment機能を触って、イメージを簡単に更新できそうだ、というのを知ることができた。ロールバック、スケールアウトも楽々でわくわくする。ただ、起動コンテナが増えた場合やそもそものイメージサイズが大きい場合、完全に切り替わるのにどのくらい時間がかかるのかは気になるな。