SVX日記

2004|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|

2015-11-03(Tue) アイ・オープン・スタック

  OPENSHIFT上で、PostgreSQLのDBアクセスをテストしたり、Gmailのsmtpへのメール送信をテストしたりする一方で、特に明確な使い道は考えないまま、openstack環境も作りはじめてみた。

  マシンも新調。消費電力優先で探したら、ZBOX CI323 nanoなどというマシンが浮上してきた。Celeron N3150という、vmx対応、4コア4スレッド、超低消費電力なCPUを搭載。超小型筐体、ファンレス、不思議なことにLANが2口あり、openstackを導入してくれと言わんばかりだ。せっかくなので2台を発注。

  しばらくPCパーツ界隈から離れているうちに、M.2などという規格が出ていたらしく、このマシンにも付いているっぽいので、併せてSANDISKのSSDを発注したのだが、文字通りフタを開けてみれば、なんとそこには無線LANカードが取り付け済みであり、物理的にも長さの短いものしか取り付けできない場所だった……SATAのSSDを発注しなおしだ、とほほ。

  RAIDも組んでいないし、容量も120Gしかなく、サーバとしては不完全な構成だが、その気になれば後からマトモなストレージを追加すりゃいいさ、と無計画でいられることこそがopenstack環境の強みだろう。ここぞとばかりに思いっきり無計画でいることにしよう。ほい、並べて、つなげて、スイッチオン。

  画像の説明

  OSは、もうすぐFedora23が出るが、どうせ何度か入れなおすことになるだろうから、待たずにFedora22を導入。コントローラノードは「troll0」コンピュートノードは「pute0」という安直な名前をつけつつ、troll0にrdoのpackstackの一撃。

[root@troll0 ~]# dnf update -y
[root@troll0 ~]# dnf install -y https://www.rdoproject.org/repos/rdo-release.rpm
[root@troll0 ~]# dnf install -y openstack-packstack
[root@troll0 ~]# packstack --allinone

  画像の説明

  おー、本当にこれだけで入っちまうのな。Fedora22にはうまく入らない、という情報もあったが、本日試した限りでは「NetworkManagerを止めなよ」という指摘を除けば、エラーらしい出力は皆無。アッサリとHorizonの画面まで辿りつけた。とりあえず、pute0の追加から始めてみようかしらん。


2015-11-10(Tue) アイ・キャント・オープン・スタック

  Fedora23が出たし、コンピュートノードを別にしたいし、ということで、Fedora23でopenstackを入れなおすことにした。先日「どうせ何度か入れなおすことになるだろうから」などとは書いたが……

  何度入れなおしゃええんじゃ!

  ……というくらい、すんなりと入らない。フタをあけてみれば、packstackが呼んでいるpuppetが呼んでいるhieraのバグだったのだが、puppetもhieraも触ったことがなかったので、問題の追い方すら手探り状態でエラく回り道してしまった。

  まずは出るこのエラー。

Error: Evaluation Error: Error while evaluating a Function Call, undefined method `unsafe_load_file' for Psych:Module at /var/tmp/packstack/xxxx/manifests/xx.xx.xx.xx_prescript.pp:2:22 on node pute0.itline.jp

  これはhieraのバグで、Bugzillaに報告がある。そして、それに関連する別のBugzillaに……

# dnf --enablerepo=updates-testing update hiera

  ……という「最新のhiera-1.3.4-3.fc23から、テスト中のhiera-3.0.1-1.fc23に更新する」対処っぽいものがあるので、それをやっちまう……と状況によっては、また別の問題にハマるのだ。

Error: Evaluation Error: Error while evaluating a Function Call, Could not find data item CONFIG_USE_SUBNETS in any Hiera data file and no default supplied at /var/tmp/packstack/xxxx/manifests/xx.xx.xx.xx_prescript.pp:2:22 on node pute0.itline.jp

  hiera-3.0.1-1.fc23では、ナゼか/etc/hiera.yamlのdefaultsの定義がcommonに変わっており、packstackが用意したdefaults.yamlが読まれなくなってしまう。その結果「CONFIG_USE_SUBNETSが未定義」となってしまうのだ。

  ここは、hieraを上げたりせず、直接パッチを当てれば済むようだ。

# vi /usr/share/ruby/vendor_ruby/hiera/config.rb
<       YAML.unsafe_load_file(source)
>       YAML.load_file(source)

  なんなんじゃ、このイカにもヤリかけっぽいバグは……。

  それと、packstackの謎仕様にもハマった。今回、2ノード分のマシンを用意したので、コントローラとコンピュートノードにするつもりで……

# packstack --answer-file=answer_file --install-hosts=172.24.0.172,172.24.0.173

  ……などとやったのだが、そうすると、せっかく編集したanswer_fileが無視されてしまうのだ。answer-fileを利用する場合、ホスト指定もanswer_file内で行い、--install-hostsオプションを使ってはいけないようだ。

  さらに、ストレージを供給するcinderとswiftだが、特に指定をしないと適当な領域が確保されてしまうので、ここは最初から意図したところを指定したいところなのだが、cinderはcinder-volumesという名前のLVMのボリュームグループを、swiftはフォーマット済みの領域を、各々準備しておく必要がある。

  最後に、すんなりと入ってしまえば問題ないのだが、不思議なことにpackstackは、途中でエラーが起こると、最後に関連ログをサックリと消して終了し、証拠の隠滅を図ろうとするので、それをヤメさせるパッチを当てる。

# vi /usr/lib/python2.7/site-packages/packstack/installer/run_setup.py
<         server.append('rm -rf %s' % host_dir)
>         server.append('#rm -rf %s' % host_dir)

  で、どうにかこうにかインストールが完了したところで、ウェブブラウザからHorizonにアクセスする……と、妙に重い……しばしば500番が返ったりする……ログを見てみたら、OOM Killerだらけじゃねーか。4GBではメモリが足りんという事か。

  しかし、インストール作業も飽きてきた。puppetとhieraと付き合い始めたのも縁であるから、ちょっと自動化でも図ってみようかしらん。


2015-11-30(Mon) アイ・キャン・オープン・スタック……メイビー

  前回「ちょっと自動化でも図ってみようかしらん」などと、軽い気持ちでpuppetやchefを調べ始めたのだが、どうも自分には合わなそうだ、ということがわかってきた。そもそも、最初に対象ホストにログインしてインストールが必要、という仕様が自己矛盾していて気に食わない。記述の例を見ても、抽象化レベルが高く、汎用性が高そうな反面、あまりクドいことはできなさそうにみえる。てなわけで、自分なりにサーバ設定の自動化機構を作り始めたところ、それなりに楽しくなってきてしまい、結果、かなり納得の行くものができてしまった。

  その名も「kugutsu」。結構、直感的に設定が記述できて、我ながら大いに気に入っている。実際、Fedora23のインストール後、ワンショットでpackstack実行直前までのお膳立てするスクリプトを書いたが、非常に便利だ。なにしろ、OSのインストール完了後、対象ホストにログインする必要すらなく、外部ホストから設定を完結してしまえるのがいい。

  しかし、ひととおり動くようになったところで、大トラップ。先日に導入を回避したhiera-3がupdateリポジトリに入ってきてしまっているではないか。ならばと、updateリポジトリを外したところ、packstackが頓挫するようになってしまった。おいおい、packstackさん、モグラ叩き大会やってんじゃねーんだぞ。

  結局、updateリポジトリを無効化して、hieraを導入後、updateリポジトリを再度有効化する、というワケのわからない手順が必要になった。なんだ、この針の穴を通すようなインストール手順は。普通の人がこんな状況に遭遇したら、アッサリとあきらめざるを得ないじゃねーか、マジかよ……と思ったら、今度はpackstack側に修正が加わり、新しいhieraでも動くようになったようだ……って、もういいや、そのままで。とりあえず開発物件一式を置いておく。んが、上記のような状況なんで、いつまでもこの導入手順が有効とは限らない、ってことだな。

  ちなみに、kugutsuとは、こんなスクリプトで……

$ ./kugutsu prep_openstack_fed23.kgt troll -l 26-34 -c
    26: kgt.modify(
    27: 	'/etc/ssh/sshd_config', [
    28: 	kgt.ss_set_param('UseDNS', ' no'),
    29: 	kgt.ss_comment_out('GSSAPI.*'),
    30: 	kgt.ss_set_param('GSSAPIAuthentication', ' no'),
    31: ])
    32: kgt.exec(
    33: 	kgt.systemctl(%w!restart sshd!)
    34: )

  ……こんな実行結果を得られるというシロモノだ。

$ ./kugutsu prep_openstack_fed23.kgt troll -l 26-34
kugutsu version is [1.0-0-20151201].
target host is [troll0.itline.jp].
start at [2015-12-01 23:07:29 +0900].
 
===> [ ! -e /etc/ssh/sshd_config.org ]
---> 0
 
===> mv /etc/ssh/sshd_config /etc/ssh/sshd_config.org
---> 0
 
===> cp -a /etc/ssh/sshd_config.org /etc/ssh/sshd_config
---> 0
 
===> sed -r -i /etc/ssh/sshd_config -e 's!^#?(UseDNS).*!\1 no!' -e 's!^#?(GSSAPI.*)!#\1!' -e 's!^#?(GSSAPIAuthentication).*!\1 no!'
---> 0
 
===> diff -bc /etc/ssh/sshd_config.org /etc/ssh/sshd_config
	*** /etc/ssh/sshd_config.org	2015-09-25 21:31:40.000000000 +0900
	--- /etc/ssh/sshd_config	2015-12-01 23:07:29.448391002 +0900
	***************
	*** 90,97 ****
	  #KerberosUseKuserok yes
	  
	  # GSSAPI options
	! GSSAPIAuthentication yes
	! GSSAPICleanupCredentials no
	  #GSSAPIStrictAcceptorCheck yes
	  #GSSAPIKeyExchange no
	  #GSSAPIEnablek5users no
	--- 90,97 ----
	  #KerberosUseKuserok yes
	  
	  # GSSAPI options
	! GSSAPIAuthentication no
	! #GSSAPICleanupCredentials no
	  #GSSAPIStrictAcceptorCheck yes
	  #GSSAPIKeyExchange no
	  #GSSAPIEnablek5users no
	***************
	*** 126,132 ****
	  #ClientAliveInterval 0
	  #ClientAliveCountMax 3
	  #ShowPatchLevel no
	! #UseDNS no
	  #PidFile /var/run/sshd.pid
	  #MaxStartups 10:30:100
	  #PermitTunnel no
	--- 126,132 ----
	  #ClientAliveInterval 0
	  #ClientAliveCountMax 3
	  #ShowPatchLevel no
	! UseDNS no
	  #PidFile /var/run/sshd.pid
	  #MaxStartups 10:30:100
	  #PermitTunnel no
---> 1
 
===> which systemctl
	/usr/bin/systemctl
---> 0
 
===> systemctl restart sshd
---> 0
finished at [2015-12-01 23:07:30 +0900].

  しかし、今回の開発の主な動機は「packstack実行直前までのお膳立てをラクしたい」だったのだが、これってむしろ、openstackのインスタンス起動後の初期設定にこそ、真価を発揮するんじゃないだろうか。また、インスタンスの起動そのものを自動化してしまうことにも使うべきかもしれない。

  さて、もう一回、最初からインストールしてみるかな……って、いつしかインストール自体が目的になってしまってるような……。