Topaz DeNoise AI で天体写真のノイズ除去

概要

最近アマチュア天体写真界隈で流行っている Topaz DeNoise AI というノイズ除去ソフトを使ってみたテストです。 DeNoise AI はこちらからダウンロードできます。1ヶ月間は無料で使用できるのでとりあえずお試し。

topazlabs.com


M45 プレアデス

こちらは、2017/9に戦場ヶ原で撮影してきたM45です。コンポジット枚数が足りていないので拡大するとノイジーですが、DeNoise AIを使うとなめらかになりました。しかもディテールは損なわれていないように見えます。

shakemid.hatenablog.com

馬頭星雲

今度は、2019/12に自宅から撮影した馬頭星雲です。東京近郊のひどい光害の下でよくここまで写ったものだと思いましたが、DeNoise AIを使うとさらになめらかになりました。恒星の周りの赤ハロも目立たなくなってる感じがします。

ばら星雲

同じく、2019/12に自宅から撮影したばら星雲です。これも、DeNoiseAIでディテールを保ったまま、ノイズを低減できているように見えます。

天の川

今度は、2020/2に房総半島最南端の野島崎で撮影してきた天の川です。RAW1枚だけなので拡大するとノイズだらけですが、だいぶなめらかになります。散光星雲のような対象だけでなく、星景にも使えそうですね。

まとめ

話題の Topaz DeNoise AI を使ってみました。想像以上にノイズを除去できて、しかもディテールは保ったままで驚きました。天体写真のコンポジット枚数が足りないとき、もう一押し強調したいけどノイズが気になってしまうときなどに、かなり有効なツールだと思いました。

なお、画像の比較には、Cocoenを使用しました。はてなブログでも、JavascriptCSSを本文に埋め込んで使用できました。

github.com

# 使い方の例

<link type="text/css" rel="stylesheet" href="https://cdn.jsdelivr.net/npm/cocoen@2.0.5/dist/css/cocoen.min.css">
<script type="text/javascript" src="https://cdn.jsdelivr.net/npm/cocoen@2.0.5/dist/js/cocoen.min.js"></script>

<div class="cocoen">
  <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/shakemid/20200301/20200301140314.jpg" alt="">
  <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/s/shakemid/20200301/20200301140319.jpg" alt="">
</div>

<script>document.querySelectorAll('.cocoen').forEach(function(element){ new Cocoen(element); });</script>

数字で振り返る、紅白歌合戦けん玉ギネスチャレンジ2019

序章

2019年の年末も、2017年、2018年に引き続き、三山ひろしさんとともに、紅白歌合戦のステージ上でギネス世界記録に挑戦させていただきました。今回も、2018年に続いてちょっと分析的な視点で振り返ってみたいと思います。今回は私は最前列の115番を務めさせていただきました。

2018年の振り返りは↓から。

shakemid.hatenablog.com

2018年は、成功必達を命題として、定員124人に対して140名を招集し、選抜を行うとともに、練習で1回でも失敗したらリザーバーと即入れ替えるというかなり厳しい進め方でした。今回は、成功必達と言うよりは、挑戦を楽しむことを重視して、選考や入れ替えは行わないことになりました。事故や急病の際のやむを得ない場合に備えて、数人の控えメンバーだけを確保していました。

そのため、成功の確率は、集まったメンバーの個々の実力にすべて依存することになります。2018年は124人でしたが、今回は125人連続で大皿を成功させるチャレンジなので、125人連続で成功する全体の成功率をPとして、個々の大皿の成功率をpとすると、Pは以下のように表すことができます。

P=p^{125}

これの意味するところは、125人連続で成功するのは非常に難しいということです。仮に100回中99回大皿を成功できるメンバーを125人揃えたとすると、125人連続で成功する確率は以下のように28.5%となります。99%は高い成功率のように思えますが、ぜんぜん低いということになります。

P=0.99^{125} \fallingdotseq 0.285=28.5\%

さらに、仮に1000回中999回成功できるメンバーを揃えたとしても、125人連続となると88.2%となり、9割を超えません。

P=0.999^{125} \fallingdotseq 0.882=88.2\%

たかが大皿といえども、ここまで難しくなるのです。大皿という簡単な技を、難しいと思えるかどうかがこのチャレンジの肝だと言えます。2018年にこのチャレンジに成功したのはいかに難しいことであったかがよくわかると思います。

2019/12/29 リハ1日目

この日初めて、ギネス記録に挑戦する125人の内、一般人115人が一堂に会しました。今回この企画が決定したのは12/8ですから、準備にかけられたのはわずか3週間しかありませんでした。この短期間で115人集まったことはそれだけで驚くべきことです。そのうち2018年の経験者は7割ほどで、3割ほどは初めて参加するメンバーでした。

集まってすぐに、練習として大皿を100回連続で行いました。今回は、大皿100回連続を楽にできることを条件として参加者を募っていましたが、それでも、4名が1回ずつ失敗しました。100回の試行で個々の実力を正確に推定することは難しいのですが、昨年考えたモデルに当てはめて、成功率を推定してみました。

参加者のレベルを以下のように分けてみることにします。大皿100回のうち1回失敗するということは、下記の中級者のカテゴリに入ると考えられます。達人や上級者は100回程度の試行では失敗しないことが多いので、推定することしかできません。

カテゴリ 大皿1回の成功率 大皿100回連続の成功率 例示
達人 99.99% 99.0% 1万回に1回失敗する。高段者、大会上位者など。三山ひろしさんはここ。
上級者 99.9% 90.5% 1000回に1回失敗する。おそらくけん玉ヒーローズのボリュームゾーン。一般的な目で見れば「けん玉名人」。
中級者 99% 36.6% 100回に1回失敗する。2018年のDJ KOOさんはおそらくこのへん。
初級者 90% 0.027% 10回に1回失敗する。2017年のDJ KOOさんはおそらくこのへん。(例に出してごめんなさい。)

2018年と同様、達人クラスは44人と仮定して、中級者は4人、残りのメンバー77人は上級者として計算してみます。

  • 達人: 44人
  • 上級者: 77人
  • 中級者: 4人
  • 初級者: 0人

これで成功率を計算すると、以下のようになります。9割を切っているものの、まずまずの成功率ではあります。この値を12/29の時点で頭に入れていました。

P=0.9999^{44} \cdot 0.999^{77} \cdot 0.99^{4} \fallingdotseq 0.885=88.5\%

12/29 は、スタジオでの練習と、ステージ上でのリハーサル(板踏み)を含めて、8回の全体練習を行い、7回成功しました。1回の失敗はスタジオでの練習のときでした。成功率は87.5%となり、推定値と近い値になりました。

7 \div 8=0.875=87.5\%

2019/12/30 リハ2日目

12/30 も引き続き、スタジオでの練習と、ステージ上でカメラリハーサルを行いました。スタジオでの失敗はありませんでしたが、カメラリハーサルの際に1回失敗しました。全体練習は12/29からの累積で17回行い、成功は15回となりました。成功率は88.2%と、推定値に近い値のままでした。

15 \div 17 \fallingdotseq 0.882=88.2\%

2019/12/31 本番

この日は本番を迎えるのみで、スタジオでの練習を行いました。練習での失敗は1回もありませんでした。全体練習の回数はは12/29からの累積で26回で、そのうち24回成功していました。成功率を計算すると92.3%となりました。(試行回数が1,2回違うかもしれませんが成功率はほぼ変わりません)

24 \div 26 \fallingdotseq 0.923=92.3\%

この状態で、非常によい雰囲気で本番に臨みましたが、残念ながら本番では成功することができませんでした。最終的には3回失敗したので、成功率を計算すると以下のように88.9%となり、推定値と非常に近い値になりました。

24 \div 27 \fallingdotseq 0.889=88.9\%

ちなみに、2018年は本番含めて26回中25回成功しているので、成功率は以下のように96.2%と、非常に高い値に達していました。2018年の方がやや成功率が良かった印象ですが、試行回数が少ないので、有意な差があったとまでは言い切れません。

25 \div 26 \fallingdotseq 0.962=96.2\%

残酷なようですが、個々の大皿の成功率は元々かなり高く、そこからさらに2,3日で大幅に上昇することはまずないので、最初に集まった時点で成功率はほぼ固定されるということになります。全体練習の成功率に表れるのはあくまで結果なので、大数の法則により、個々の成功率に基づく期待値に収束することになります。決して低い成功率ではなかったので、願わくば本番で成功したかったですが、これは結果として受け止めるしかありません。

なお、ギネス挑戦後の現場は、非常に和やかで爽やかなものであったことを、重ねて強調しておきます。三山ひろしさんも他の芸能人の方も含めて、あの場のメンバーには信頼関係が醸成されていて、誰も責めたりせず、みんなで挑戦したことを讃え合っていました。三山ひろしさんもブログで言及されていますね。

ameblo.jp

フジテレビけん玉部部長のシマヲさんのこちらの記事もおすすめです。

www.fujitv-view.jp

次回への展望

結果は惜しくも失敗に終わりましたが、すでに4回目の挑戦に言及されていたりして、次回に期待が持てそうです。過去3回は、あまりにも時間がない中での準備でしたが、次回は挑戦がある前提ならもっと準備に時間をかけることができるかもしれないですね。三山ひろしさん、そして、けん玉ヒーローズの今後の挑戦に乞うご期待です!

www.nikkansports.com

Kata Containers on Oracle Linux について Oracle Open World でお話ししてきました

概要

2019/9にサンフランシスコで開催されたOracle Open World 2019で登壇する機会をいただきました。Linuxとセキュリティという切り口で、Oracle LinuxのPMのSimon Coterさんといっしょに、Kata Containersというセキュリティ指向のコンテナランタイムについてお話ししてきました。

実は英語で登壇するのは初めての経験だったので、出落ちのクレイジージャパニーズくらいの気持ちで行きましたが、それなりに形になってたようです。我ながらかなりの変態ミッションだったと思います。

  • 夏休みの個人旅行でOracle Open Worldに行く
  • 個人で登壇する
  • 英語で30分ぐらい話してデモもやる
  • アイスブレイクでけん玉をちょっとやる

Oracle Open Worldに登壇した日本人はいっぱいいますが、けん玉をやった人はいないでしょう。

Oracle Open World 2019 の資料はこちらのサイトからダウンロードできます。(英語版です)

events.rainfocus.com

2019/8に日本で開催された、Oracle Modern Cloud Day Tokyoでも、同じ内容を日本語でお話しさせてもらったので、そちらの資料を使って解説したいと思います。

Oracle Modern Cloud Day Tokyo の資料はこちらのサイトからダウンロードできます。

https://www.oracle.co.jp/campaign/moderncloudday/2019/

導入

表紙の背景に特に意味はありませんが、自分で撮影してきた天体写真をぶっ込むスタイルでいきました。この写真は2017年8月にアメリカで撮影してきた皆既日食の写真です。OOWで皆既日食を見た人がいるか聞いてみたら、2,3人手を上げてくれました。

余談ですが、2017/8/21 北米皆既日食の記事はこちら。

shakemid.hatenablog.com

自己紹介スライドはいつもながら自己主張強めです。OOWではちょっとけん玉やりました。だいぶうけてたのでアイスブレイクには成功したようです。芸は身を助ける、です。

アプリケーションコンテナ

コンテナ型仮想化の歴史は、1979年にUnixに実装されたchrootに遡ります。chrootはプロセスからファイルシステムを隔離する仕組みで、今でもよく使われます。2000年には、FreeBSDでJailという仕組みが導入されました。これはchrootをさらに強化したもので、プロセス空間も隔離します。Jailによって、OSの中に仮想OSを作るような使い方ができるようになりました。2005年には、Solaris 10でSolaris Zones (Solaris Containers)という仕組みが導入されました。これはほぼ仮想サーバのような機能で、ZonesがあるからSolarisを使っていた方も多いんじゃないかと思います。Solaris 11では、Kernelまで隔離した、Kernel Zonesというほぼハイパーバイザのような機能も導入されました。

またも余談ですが、2014年にSolarisのVPのBill Nesheimさんといっしょに、Solarisの仮想化についてお話ししたことがありました。我ながら、面白い機会をいただいていてありがたいことです。 www.sbbit.jp

Linuxでのコンテナ型仮想化も歴史が長く、2000年代半ば頃から、OpenVZ/Virtuozzoや、Linux-Vserverがレンタルサーバなどによく使われていました。初期のDockerでも使われていたLXCや、LXCを便利にした感じのLXDや、systemdに統合されたsystemd-nspawnなど、様々な実装があります。 2013年にDockerが登場してからアプリケーションコンテナが一気に広まってきました。2014年にKubernetesが登場し、今回紹介するKata Containersは2017年に登場したかなり新しい技術です。

今ではすっかり、「コンテナ」と言えば「アプリケーションコンテナ」のことを指すようになってしまいましたが、私は単に「コンテナ」と言うと、コンテナ型仮想化(OSレベル仮想化・システムコンテナ)の方を想像してしまうので、なるべく「アプリケーションコンテナ」と言うようにしていたりします。コンテナ型仮想化は、仮想サーバと同じような使い方をしますが、アプリケーションコンテナはその延長線上にはないのではないかと思います。

アプリケーションコンテナと従来のコンテナ型仮想化は似ていないと言いましたが、アプリケーションコンテナはサーバ仮想化などのインフラの話よりも、アプリケーション開発やDevOpsの文脈で語られることが多いのではないかと思います。Dockerの典型的な使い方としては、ビルド、パッケージング、デプロイという流れになると思いますが、昔からあるサーブレットコンテナととてもよく似ていたりします。アプリケーションコンテナとは、仮想サーバを置き換えるものではなく、アプリケーションをデリバリするためのものであると捉えるのがわかりやすいと思います。

アプリケーションコンテナのセキュリティ

ガートナーが最近出しているリサーチによると、2019年時点で、アプリケーションコンテナを商用で使っている組織は、ワールドワイドで30%未満とのことです。しかし、2022年にはこれが75%超になると予想されています。 会場の方に、アプリケーションコンテナを商用で使っているか聞いてみたところ、日本のModern Cloud Dayでは10%未満でしたが、アメリカのOpen Worldでは30~40%くらいの方が手を上げました。ガートナーのリサーチはそれなりに当たっていそうな感じです。 ガートナーは同じ記事の中で、アプリケーションコンテナを商用で使うための、6つの重要な要素を挙げていて、その1番目に「セキュリティ&ガバナンス」を挙げています。

www.gartner.com

アプリケーションコンテナのセキュリティと一言に言っても、どうすればいいのかなかなか難しいです。NIST(米国国立標準技術研究所)がよくまとまった文書を公開しているので、そちらを参照してみましょう。NIST SP800シリーズはセキュリティ関連の文書で、SP800-190 はアプリケーションコンテナのセキュリティについてまとめられています。2017年9月に公開されたものなので、かなり新しい文書です。 その中で、アプリケーションコンテナの典型的なアーキテクチャは上の図のようなコンポーネントから成り立っていると述べられています。図の左から、開発者がコンテナイメージを作って、テストして、レジストリに登録して、管理者がオーケーストレータを使ってホストにデプロイする、という流れになっています。Docker、Kubernetes、DockerHubなどは、このアーキテクチャの実装例といえます。

SP800-190はこちらからダウンロードできます。 csrc.nist.gov

一部の文書はIPAが日本語化して公開しています。SP800-190はまだないようです。 www.ipa.go.jp

同文書の中で、アプリケーションコンテナには5つの主要なリスクがあると述べられています。5つのリスクとは、イメージのリスク、レジストリのリスク、オーケストレータのリスク、コンテナランタイムのリスク、ホストOSのリスクです。

コンテナイメージの中身は、概ね上のような図のようになっています。先ほど、アプリケーションコンテナはアプリケーションをデプロイするためのものだと述べました。誤解を恐れずに言えば、アプリケーションの開発者はほぼアプリケーションにしか興味がないことが多いんじゃないかと思います。でも、コンテナの中身はOSイメージそのものなので、インフラやセキュリティの人は、ライブラリやユーザランドが気になってしまうのではないかと思います。 でも一般に、アプリケーションコンテナの場合は、中に入ってプロセスを監視したりログを監視するようなことはあまりやりません。むしろお行儀が悪いと言われたりします。これは仮想サーバのように使うコンテナ型仮想化の場合とは異なるやり方が必要になりますが、セキュリティとしてはコンテナイメージの中身も見る必要があります。DevOpsにセキュリティを加えたDevSecOpsのような考え方が必要になるということだろうと思います。

次に、ホストOSのリスクの中の、Kernelの共有の項目に注目したいと思います。一般的に、アプリケーションコンテナ環境では、アプリケーションレベルで隔離が行われているものの、Kernelを共有しており、ハイパーバイザによる仮想化より隔離のレベルが低いと考えられます。Kernelを共有しているので、1つのアプリケーションコンテナが侵害されれば、ほかのアプリケーションコンテナもリスクにさらされる可能性が高いといえます。この手の攻撃が刺さる可能性はそう高くないかもしれませんが、カーネルを共有していることがセキュリティの論点になることはあるということです。

Kata Containers

Kernelの共有がセキュリティのリスクになることがあるということから、ようやくKata Containersの話に入ります。ハイパーバイザの技術を利用し、 アプリケーションの強い隔離を実現するコンテナランタイムで、OpenStack Foundataion(OSF)がサポートしています。2017/12に出たばかりのとても新しい技術です。 コンテナオーケストレータは、今のところKubernetesデファクトスタンダードといえますが、一方、コンテナランタイムはいろいろな特性を持ったものが出てきています。Kata Containersはかなりセキュリティに振り切ったコンテナランタイムだと言えます。

katacontainers.io

この図は、Kata Containersのアーキテクチャを模式図にしたものです。一般的なコンテナランタイムでは、左の図のように、Kernelを共有して、Namespaceの機能でアプリケーションを隔離します。それに対して、Kata Containersでは、アプリケーションコンテナ毎にKernelが分離するので、ハイパーバイザによる仮想化と同等の隔離を実現しています。

この図は、DockerとKata Containersの関連性を表したものです。kata-runtimeはLow-Levelのコンテナランタイムです。また、CNCFが策定したOCI Runtime Specificationに準拠しています。Dockerでは、通常runCがLow-Levelコンテナランタイムとして使用されますが、もちろんrunCもOCI Runtime Specificationに準拠しています。つまり、runCをkata-runtimeに置き換えることが可能ということになります。Kata ContainersはDockerやKubernetesを置き換えるものではなく、組み合わせて使うものと考えるのがよいと思います。

Kata Containersは、Oracle Linuxでは Oracle Linux Cloud Native Environment (OLCNE) の一部として取り込まれています。とはいえ、OLCNEという製品があるわけでもなく、サービスがあるわけでもありません。Oracle Linuxには、クラウドでのアプリケーション開発や運用に必要な機能がバンドルされているという、コンセプトのようなものだと私は理解しています。

Demo

こんな感じの環境で簡単なデモを行いました。仮想化にはVMware Playerを使いましたが、Oracle LinuxのPMのSimonさんは、VirtualboxのPMでもあるので、できればVirtualboxを使いたいと思っていました。Kata ContainersはKVMを使うので、仮想環境で動かすには、Nested VMができる必要があります。Virtualbox 6.0でAMDのCPUではNested VMに対応しているのですが、IntelのCPUではまだ対応していませんでした。VMware PlayerではIntel CPUでもNested VMができました。Virtualbox 6.1では、Intel CPUでもNested VMに対応予定のようなので、期待したいと思います。 イベントでは機材トラブルがつきものなので、デモをやるのは度胸が必要です。幸い日本でもアメリカでもデモ環境はすんなり動いてくれてよかったです。

デモのシナリオです。Docker Hubから取得した、Nginxのイメージを、Docker+runC と Docker+kata-runtime でそれぞれ起動するというデモを行いました。docker run の --runtime オプションを指定するだけで、必要に応じてコンテナランタイムを切り替えることができ、混在させることもできます。 Solaris 11をよく知っている方は、Native ZonesとKernel Zonesとの関係に似ていると考えるとわかりやすいんじゃないかと思います。

Oracle LinuxでKata Containersを使うのはわりと簡単です。この手順は、Developer Previewでの手順なので、GA(General Availability)になったら変わるかもしれませんのでご了承ください。

必要なYumリポジトリを有効化します。

# yum-config-manager --enable ol7_addons
# yum-config-manager --enable ol7_developer
# yum-config-manager --enable ol7_developer_kvm_utils

必要なRPMをインストールします。

# yum install docker-engine
# yum install qemu
# yum install oracle-olcne-release-el7
# yum install kata-runtime

Dockerの起動オプションを変更して、kata-runtimeを有効にします。

# vi /etc/sysconfig/docker
---
OPTIONS='-D --add-runtime kata-runtime=/usr/bin/kata-runtime'

# systemctl restart docker

Kata Containersを使用するには、KVMが有効になっている必要があります。

# lsmod
…
kvm     643072  1 kvm_intel

設定がうまくいっていれば、docker info でランタイムが追加されているのがわかります。

# docker info
…
Runtimes: kata-runtime runc

docker run でコンテナを起動すると、runCの場合は1秒くらいで起動しますが、kata-runtimeは仮想マシンを起動するので4~5秒くらいかかりました。パフォーマンスのテストは詳細にはやっていませんが、KVMで仮想化しているのと同じくらいのオーバーヘッドはあると考えられます。 pstreeでプロセスを見ると、runCのほうはNginxのプロセスが見えているのに対して、kata-runtimeのほうは、qemuのプロセスが見えて、たしかに仮想化されているのがわかります。Nginxのプロセスは仮想マシンの中なので、ホストOSからは見えなくなっています。

まとめ

というわけで、アプリケーションコンテナを商用環境で使うときにはそれ相応のセキュリティを考慮する必要があるということと、Kernelの共有はセキュリティリスクとして論点になりうるという話から、ハイパーバイザの技術でアプリケーションコンテナを隔離するKata Containersというコンテナランタイムについて紹介しました。今後、Kata Containersが主流になるかはまったくわかりませんが、コンテナランタイムは必要に応じて特性の違うものを使い分けるようなケースが増えてくるのではないかと考えています。

またも余談ですが、最後のスライドも自分で撮影してきた天体写真をぶっ込みました。2018年に、世界有数の美しい星空だと言われる、ニュージーランドのテカポ湖で撮影してきた天の川の写真です。 ニュージーランド旅行の記事はこちらから。 shakemid.hatenablog.com

相貌失認

相貌失認(そうぼうしつにん)をご存じでしょうか。

相貌失認は高次脳機能障害の一種で、人の顔を覚えられない、人の表情がわからないといった症状があります。 人口の2%が該当するとも言われ、意外と多いです。程度は様々で、重症だと家族の顔すら覚えられないこともあるそうです。治療法は基本的にはありません。

私は軽度の相貌失認を自認しています。

ja.wikipedia.org

ブラッド・ピットなど、相貌失認を告白している著名人もいます。この人がブラッド・ピットだと、皆さんわかるのだと思いますが、たぶん私は目の前にいてもわかりません。

movie.walkerplus.com

私はまったく覚えられないわけではないので、軽度なのだと思いますが、以下のようなことがよくあり、困ることがあります。

  • およそ3人~4人に1人は顔を覚えるのが非常に難しい。法則性は特になし。
  • 仕事で顔を合わせていても、街中など、違う場面だと誰かわからない。
  • 大勢の中から目的の人を探せない。オープンスペースのようなところで待ち合わせると詰むことあり。
  • 2回目以降会っても誰かわからない。何回も会っている人でも、初めて会うのか会ったことがあるのかわからない。
  • 芸能人の顔がわからない。映画などで役柄はわかっても、誰なのかわからない。

こちらのサイトで、相貌失認のセルフチェックができるサイトが紹介されていました。ふつうの人だと平均80%で、60%を切ると相貌失認の疑いありとのことなのですが、私がやってみたところ50%ほどでした。まあまあの相貌失認なのだと思います。

www.gizmodo.jp

テストはこちらのサイトです。(英語です)

www.bbk.ac.uk

治療法はないので、受け入れるしかないのですが、自分が他人の顔を覚えられないので、なるべく自分が覚えていただけるように心がけていることから、自己主張が強めに感じる方もいるかもしれません。 街中など、たくさんの人がいる中で私に会って、無視しているように見えても、おそらく顔を認識できていないので、気を悪くしないでいただけるとありがたいです。

こうして相貌失認のことを書けば、少しは世の中の役に立つかもしれないので、書かせていただきました。

ZWO ASIAIR + Sky-Watcher SynScan Wi-Fi + EQ5GOTO で自動導入

概要

f:id:shakemid:20190824160809j:plain

ZWO ASIAIR と Sky-Watcher SynScan Wi-Fi を組み合わせて、 EQ5GOTO で自動導入できるところまで検証してみたメモです。

ASIAIR は1年ほど前からアマチュア天文界で話題になっているデバイスで、天体写真に必要な、カメラや赤道儀の操作を、スマートフォンタブレットでまとめてできてしまうという画期的な製品です。私は Sky-Watcher EQ5GOTO を、SynScan Wi-Fiスマートフォンから操作できるようにしていたので少し様子見していましたが、ASIAIRは23,000円とこの手の製品にしては安いので気付いたら買っていました。

http://hoshimiya.com/?pid=133669448hoshimiya.com

hoshimiya.com

通常は ASIAIR と EQ5GOTO の接続は、ハンドコントローラにシリアルケーブルを挿して有線で連携するのですが、どうせなら無線で連携したいと思いました。 ASIAIR と AZ-GTi での連携は公式にサポートされていたので、中身がほとんど同じと思われる SynScan Wi-Fi との連携もできるだろうと思いました。

https://astronomy-imaging-camera.com/manuals/ASIAIR_Sky-Watcher_AZ-GTI.pdf

ZWO社のFacebookページで、AZ-EQ5GT での動作報告例があったので、私も EQ5GOTO での動作報告を共有しておきました。

www.facebook.com

シナリオ

設定の手順を簡単に解説します。無線LANの設定のところが少々ややこしいかもしれません。私は、光学や制御のことはさっぱりですが、ネットワークのことは仕事上得意分野です。最近のアマチュア天文界はIT化が著しいようなので、私にはありがたいかもしれません。

私はiPadで検証したので、画面はiPadのものですが、たぶんAndroidでもだいたい同じ手順でいけると思います。

SynScan Wi-Fi の設定

iPad/iPhone を、SynScan Wi-FiSSID無線LANに接続し、SynScan Pro App で SynScan Wi-Fi に接続します。

SynScan Wi-Fi は、アクセスポイントモード(無線LAN親機)として動作していますが、ASIAIR と同じネットワークセグメントに接続するために、ステーションモード(無線LAN子機)に変更します。ASIAIR のSSIDとパスワード(ASIAIRの本体側面に記載)を入力し、固定IPアドレスを割り当てます。ここでは 10.0.0.10 に設定します。

f:id:shakemid:20190825225512p:plain

「Apply(適用)」を押すと設定が反映され、以後は、ASIAIRを無線LAN親機として接続するようになります。設定を間違えると、SynScan Wi-Fi に接続できなくなるので慎重に設定してください。

もし設定を間違えたら、SynScan Wi-Fi をリセットする必要があります。説明書によると、SynScan Wi-Fi をリセットするには、電源を入れて接続せずに1時間放置すればよいようです。(なんという仕様...)

ASIAIRの設定

iPad/iPhone を、ASIAIR のSSID無線LANに接続します。デフォルトでは、ASIAIRの無線LANの周波数帯は5GHzになっていますが、SynScan Wi-Fiは2.4GHzにしか対応していないので、2.4GHzにしておいてください。そもそも、日本では電波法により屋外で5GHz帯は使ってはいけないので、おとなしく2.4GHzにしておきましょう。

f:id:shakemid:20190825224521p:plain

SynScan Pro App でのアラインメント

iPad/iPhone を ASIAIR のSSID(ASIAIR_xxx)に接続したら、SynScan Pro App で SynScan Wi-Fi に接続してください。設定がうまくいっていれば、10.0.0.10 で SynScan Wi-Fi に接続できると思います。

SynScan Pro App で、アラインメントを行ってください。3スターアラインメントが推奨らしいのですが、ASIAIRの Plate Solving が優秀なようなので1スターアラインメントでも十分な気がします。アラインメントを行わないと、ASIAIR から接続ができないようです。

ASIAIR から SynScan Wi-Fi への接続

ASIAIR のアプリに切り替えて、望遠鏡のアイコンを選択し、以下のように設定して SynScan Wi-Fi に接続してください。

  • Telescope: EQMod Mount (SynScanではなく)
  • IP: 10.0.0.10
  • Port: 11880
  • Protocol: UDP

f:id:shakemid:20190825224856p:plain

接続がうまくいけば、ASIAIRから自動導入などが行なえるようになります。

f:id:shakemid:20190825224914p:plain

まずはここまでしか検証できていませんが、オートガイドや Plate Solving など、魅力的な機能が他にもあるので、徐々に試したいと思います。

野辺山で星を見てきました

令和最初の天体観測ということで、GWの後半は3泊4日で野辺山高原に出かけてきました。 野辺山は首都圏からアクセスしやすい天体観測スポットで、私が住んでいる千葉県浦安市からだと車で3~4時間ほどで行くことができます。 www.kanko-nobeyama.jp

野辺山には2014年にも来たことがあるのですが、そのときは1泊だけで、残念ながら夜は曇ってしまい星を見ることができませんでした。約4年半ぶりのリベンジです。

撮影場所は、野辺山駅から車で5分くらいのところにある、八ヶ岳ふれあい公園にしました。24時間無料で使える駐車場とトイレがあり、天体観測スポットとして人気があるようです。深夜でも常に星を見に来ている人がいました。

公園には1周500mの大きな池があります。水面を使った星景写真を撮るのも面白いと思います。

妙に整った形の池だと思ったら、もともとはスケートリンクだったとのことです。

こんな感じの清掃の行き届いたトイレが24時間使えます。管理人さんが常駐しているようです。

今回の装備です。1日目は、 BORG 71FL+α7S+EQ5GOTO で、主に系外銀河を狙いました。BORG 71FLは400mmしかないので系外銀河を撮影するにはちょっと小さいです。系外銀河をちゃんと撮影しようとするとさらに上の機材が必要ですが、比較的コンパクトな機材で10分くらいで気軽に撮影してきたことに価値があると思います。

2日目は池のほとりで一晩中天の川を見ていました。この日は一晩中快晴でした。夏の天の川を見るなら梅雨の前の4月~5月の夜2時~3時頃がおすすめです。池の水面を入れて、星景っぽく天の川を撮影してみました。野辺山は天頂近くは暗いのですが、低空は残念ながら光害がかなりあります。冬場はスキー場の照明でさらに光害がひどいようです。せっかくの星空なのに、残念なところです。

一晩中外にいたらカメラバッグに霜が降りてました。ホームセンターで買った防寒作業着が優秀でした。標高1300mの山と同じようなもんですから、防寒着がなかったら凍死しますね。山での天体観測は凍死との戦いです。

3日目は、北天にカメラを向けてタイムラプス撮影してみました。水面にも星が写っていい絵になるかなと思ったのですが、野辺山上空は飛行機が多すぎでした。人工衛星や流星ぽいものも写ってますね。これはこれでおもしろいです。

3泊中3晩とも晴れて、天体観測を楽しむことができました。3日目は体力が続かず、ほどほどにしてホテルに帰りました。

野辺山高原は首都圏からアクセスしやすい天体観測スポットとしては屈指ではありますが、思ったより低空の光害が目立つと思いました。特に南側が明るいので、天の川の撮影にはあまり向いてないように思いました。空の暗さでは栃木県の戦場ヶ原のほうが暗かったと思います。

shakemid.hatenablog.com

戦場ヶ原も南側はそれなりに光害があるので、関東周辺で天の川を撮影するなら千葉の南房総がよいように思います。ただし、南房総も、北側は東京の光害があります。関東周辺で光害がないところはないので、撮影したい対象に応じて撮影場所を選ぶ必要があると思います。

Elasticsearch Cluster on Linux Container

概要

Linuxコンテナ(systemd-nspawn)を使って、複数ホストにまたがるElasticsearchクラスタを構築してみました。 私はコンテナ歴12年くらいですが、ほとんどSolarisコンテナ(Zones)ばかり使っていて、Linuxコンテナはどんなものかよくわかっていないので、おかしなことを言っていましたらご指摘ください。

背景

以下のような感じの要件で、基盤のアーキテクチャを考えていました。

  1. 50~100ノード規模のElasticsearchクラスタを作りたい
  2. オンプレ環境で
  3. 一度起動したら年単位で動き続ける
  4. 商用ライセンスはあまり使いたくないけど、人柱になって自力でなんとかする気概はあり

なんとなく以下のような実現方式を考えました。本音はSolaris Zonesを使いたくてたまりませんが今回はLinux縛りです。

カテゴリ 方式 評価(主観)
物理系 物理サーバ50台 × ラックが足りない。運用嫌だ。
物理サーバ+マルチプロセス △ 運用嫌だ。
ハイパーバイザ系 VMware △ ライセンス必要。オーバーヘッド嫌だ。
KVM, Xen △ オーバーヘッド嫌だ。
コンテナ系 Docker △ どうも合わない。k8s, Swarmとかは大がかりすぎ。
OpenVZ △ まだあるのだろうか?
LXD ○? 良さそう。使うならUbuntuが良さそうか。
systemd-nspawn ○? ほぼOS標準の機能!

Dockerは少し検証してみたのですが、動くには動くのでしょうが、ホストまたぎのネットワークを構成するのが面倒で、KVSを立ち上げて、VXLANでオーバーレイネットワークとかになるのでやる気がなくなりました。 そのためだけにKubernetesとかSwarmを使うのも大がかりすぎに思えました。

qiita.com

DockerをDisる気はなく、用途がマッチすれば良いと思いますが、仮想マシンのようなことがやりたいならまったく不向きで、無理矢理使っても悲惨な運用になるのが落ちという感じがします。 長年Solarisコンテナを使ってきたのもあって、なるべくシンプルでほぼOS標準の機能で動作するということから systemd-nspawn にたどり着き、検証してみようと思いました。

なお、クラウド前提なら、Amazon Elasticsearch Service を検討するのもいいと思います。

aws.amazon.com

シナリオ

今回構築する環境は以下のようなイメージです。物理マシンがあれば使ってもいいですが、私はVirtualBox上に構築することにしました。 f:id:shakemid:20190407085152p:plain

構築は以下のような流れで進めました。

  • ホスト構築編
    • CentOS 7 をインストールする
    • systemd-networkd をインストールする
    • ZFS をインストールする(任意)
  • コンテナ構築編
    • コンテナイメージをインストールする
    • コンテナを起動する
    • Elasticsearchをインストールする
    • コンテナをコピーする

構築

ホスト構築編

CentOS 7 をインストールする

OSはユーザが多いであろうCentOSにしました。バージョンは現時点で最新の7.6にしました。

インストールはできましたが、グラフィカルインストーラだとマウスでボタンをクリックできないことがある謎の事象に遭遇したので、テキストインストーラを使う方がいいような気がします。

qiita.com

今回はホスト間で通信できる必要があるので、VirtualBoxのネットワークの設定でブリッジアダプターを使うとよいと思います。また、プロミスキャスモードを許可する設定も必要です。 f:id:shakemid:20190407085205p:plain

また、OSの領域とコンテナの領域を分けたいので、ストレージの設定画面でディスクイメージを1つ追加しました。

SELinuxは無効にしました。

$ sudo vi /etc/sysconfig/selinux
----
...
SELINUX=disabled
...
systemd-networkd をインストールする

今回はホスト間で通信できるようにネットワークブリッジを使うので、ネットワークの管理をsystemd-networkdで行うのがよいようです。以下のページを参考にしました。

renediepstraten.nl

以下のページも参考にしました。systemd関連のドキュメントはArch Linuxのものがわかりやすい感じがします。

wiki.archlinux.jp

systemd-networkd と systemd-resolved をインストールします。

$ sudo yum install systemd-networkd systemd-resolved

設定ファイルを作成します。内容は環境に合わせて適当に変えてください。Redhat標準の /etc/sysconfig/network-scripts/ 以下のファイルは使われなくなります。

/etc/systemd/network/br0.netdev
----
[NetDev]
Name=br0
Kind=bridge
/etc/systemd/network/enp0s3.network
----
[Match]
Name=enp0s3

[Network]
Bridge=br0
/etc/systemd/network/br0.network
----
[Match]
Name=br0

[Network]
Address=192.168.0.10
Gateway=192.168.0.254
DNS=192.168.0.254

systemd-networkd と systemd-resolved を有効にします。

$ sudo systemctl disable network NetworkManager
$ sudo systemctl enable systemd-networkd systemd-resolved
$ sudo reboot

resolve.conf を入れ替えておきます。

$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

networkctl コマンドで、IPアドレスなどを確認することが出来ます。

$ networkctl status
●      State: routable
     Address: 192.168.0.10 on br0
     Gateway: 192.168.0.254 (XXX) on br0
         DNS: 192.168.0.254
ZFS をインストールする(任意)

ZFSは必須ではありませんが、コンテナの領域を管理するのに都合が良さそうなので使ってみたいと思います。 systemd-nspawn はBtrfsと連携する機能があるようなのですが、ここは慣れ親しんだZFSにします。

ZFSCentOSで使用するには、カーネルモジュールを追加する必要があります。ZFS on Linux の公式の手順に従ってインストールします。

github.com

ZFSYumリポジトリを使えるようにします。

$ sudo yum install http://download.zfsonlinux.org/epel/zfs-release.el7_6.noarch.rpm

zfs-kmod のほうを有効にします。

$ sudo vi /etc/yum.repos.d/zfs.repo
----
 [zfs]
 name=ZFS on Linux for EL 7 - dkms
 baseurl=http://download.zfsonlinux.org/epel/7/$basearch/
-enabled=1
+enabled=0
 metadata_expire=7d
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux
@@ -9,7 +9,7 @@
 [zfs-kmod]
 name=ZFS on Linux for EL 7 - kmod
 baseurl=http://download.zfsonlinux.org/epel/7/kmod/$basearch/
-enabled=0
+enabled=1
 metadata_expire=7d
 gpgcheck=1
 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-zfsonlinux

ZFS をインストールします。

$ sudo yum install zfs

ARCのサイズを制限しておきます。

$ sudo vi /etc/modprobe.d/zfs.conf
----
options zfs zfs_arc_max=1073741824

ストレージプールを作成します。ZFS on Linux では、ls -l /dev/disk/by-id で表示されるデバイスIDを使用することが推奨されているようです。

$ sudo zpool create tank ata-VBOX_HARDDISK_XXXXXX-XXXXXX

tank という名前でストレージプールができました。

$ zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  39.8G   291K  39.7G         -     0%     0%  1.00x  ONLINE  -

コンテナ用の領域(データセット)を作成します。compressionの設定はお好みに合わせてという感じです。近年はCPUが高速なので、圧縮した方が Disk I/O が減って高速になるケースもあります。

$ sudo zfs create -o compression=lz4 -o mountpoint=/var/lib/machines tank/machines
$ sudo zfs create tank/machines/es11
$ sudo zfs create tank/machines/es12

こんな感じでデータセットができました。

$ zfs list
NAME                 USED  AVAIL  REFER  MOUNTPOINT
tank                 162K  38.5G  25.5K  /tank
tank/machines         73K  38.5G    25K  /var/lib/machines
tank/machines/es11    24K  38.5G    24K  /var/lib/machines/es11
tank/machines/es12    24K  38.5G    24K  /var/lib/machines/es12

systemd-nspawnでは、 /var/lib/machines/ 配下のディレクトリ名がコンテナのhostnameになるように想定されているようです。長さの制限は一見ないように見えるのですが、systemd-networkd がインタフェース名を自動生成するときに先頭11文字で切り落としてしまうようで、先頭11文字がユニークでないと名前が衝突するようです。そのうち改善するのかもしれませんが、ディレクトリ名(コンテナ名)は11文字以下にするのが無難なようです。

github.com

コンテナ構築編

コンテナイメージをインストールする

systemd-nspawn では、コンテナイメージをインストールする方法は主に3種類くらいあるようです。

  1. yum install --installroot でインストールする。chroot環境を作るのと似た感じ。
  2. ビルド済みのイメージを使う。Dockerのイメージも使えるようだ。
  3. すでに作成済みのコンテナからコピーする。

ひとまずオーソドックスな1.でやってみることにします。3.はあとからやります。

ZFSで作成した領域に最低限のパッケージをインストールします。

$ sudo yum -y --nogpg --releasever=7 --installroot=/var/lib/machines/es11 install systemd systemd-networkd passwd yum vim-minimal

lsで見ると、OSのイメージぽく見えます。

$ ls -l /var/lib/machines/es11/
total 17
lrwxrwxrwx.  1 root root   7 Apr  6 23:24 bin -> usr/bin
dr-xr-xr-x.  2 root root   2 Apr 11  2018 boot
drwxr-xr-x.  2 root root   3 Apr  6 23:24 dev
drwxr-xr-x. 47 root root 113 Apr  6 23:25 etc
drwxr-xr-x.  2 root root   2 Apr 11  2018 home
lrwxrwxrwx.  1 root root   7 Apr  6 23:24 lib -> usr/lib
lrwxrwxrwx.  1 root root   9 Apr  6 23:24 lib64 -> usr/lib64
drwxr-xr-x.  2 root root   2 Apr 11  2018 media
drwxr-xr-x.  2 root root   2 Apr 11  2018 mnt
drwxr-xr-x.  2 root root   2 Apr 11  2018 opt
dr-xr-xr-x.  2 root root   2 Apr 11  2018 proc
dr-xr-x---.  2 root root   2 Apr 11  2018 root
drwxr-xr-x. 12 root root  12 Apr  6 23:25 run
lrwxrwxrwx.  1 root root   8 Apr  6 23:24 sbin -> usr/sbin
drwxr-xr-x.  2 root root   2 Apr 11  2018 srv
dr-xr-xr-x.  2 root root   2 Apr 11  2018 sys
drwxrwxrwt.  7 root root   7 Apr  6 23:25 tmp
drwxr-xr-x. 13 root root  14 Apr  6 23:24 usr
drwxr-xr-x. 18 root root  21 Apr  6 23:24 var

ちなみに、圧縮率を見てみると2倍以上になっていてなかなかいい感じです。lz4は圧縮率と速度のバランスが良く、ZFSを使うならおすすめです。

$ zfs get compressratio tank/machines/es11
NAME                PROPERTY       VALUE  SOURCE
tank/machines/es11  compressratio  2.03x  -
コンテナを起動する

systemd-nspawn -Dオプションで、イメージをインストールしたディレクトリを指定してコンテナを起動し、rootのパスワードを設定します。

$ sudo systemd-nspawn -D /var/lib/machines/es11
-bash-4.2# passwd
...
-bash-4.2# exit

SELinuxを適切に設定するか無効にしないとパスワード変更で↓のようなエラーになるようなのでご注意ください。私は恥ずかしながらSELinuxをまともに使ったことがありません。

passwd: Authentication token manipulation error

コンテナをデーモンモードで起動します。

$ sudo systemd-nspawn -b -D /var/lib/machines/es11

起動シーケンスが走って、ログインプロンプトが出てくるのでrootでログインします。

Spawning container es11 on /var/lib/machines/es11.
Press ^] three times within 1s to kill container.
systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to CentOS Linux 7 (Core)!

...
CentOS Linux 7 (Core)
Kernel 3.10.0-957.el7.x86_64 on an x86_64

es11 login: root
Password:
Last login: Sat Apr  6 23:43:37 on console

ps -ef で見ると、最低限のプロセスが起動しているのがわかります。

container# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  1 23:45 ?        00:00:00 /usr/lib/systemd/systemd
root        14     1  0 23:45 ?        00:00:00 /usr/lib/systemd/systemd-journald
dbus        19     1  0 23:45 ?        00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfil
root        21     1  0 23:45 ?        00:00:00 /usr/lib/systemd/systemd-logind
root        23     1  0 23:45 ?        00:00:00 login -- root
root        25    23  0 23:45 console  00:00:00 -bash
root        37    25  0 23:45 console  00:00:00 ps -ef

デフォルトでは、ホストとネットワークを共有しています。

container# networkctl status
●      State: n/a
     Address: 192.168.0.10 on br0
     Gateway: 192.168.0.254 (JStream Technologies Inc.) on br0

Ctrl+] を3回入力するとコンテナが終了します。

Container es11 terminated by signal KILL.

ネットワークの設定を追加します。コンテナの中身はただのディレクトリなので、ホスト側からも見えます。

$ cd /var/lib/machines/es11
$ cd etc/systemd
$ sudo mkdir network
$ cd network

systemd-nspawnではhost0という仮想NICが自動的に作られるので、以下のように設定ファイルを作成します。

$ sudo vi host0.network
----
[Match]
Name=host0

[Network]
Address=192.168.0.11/24
Gateway=192.168.0.254
DNS=192.168.0.254

今度は、--network-bridge オプションを追加して起動します。

$ sudo systemd-nspawn -b -D /var/lib/machines/es11 --network-bridge=br0

host0にIPアドレスが設定されていることがわかります。これで、コンテナに独自のIPアドレスを割り当てて外部と通信できるようになりました。

container# networkctl status
●      State: routable
     Address: 192.168.0.11 on host0
     Gateway: 192.168.0.254 on host0
         DNS: 192.168.0.254

machinectl login でrootでログインできるように、/etc/securettyにpts/0を追記しておきます。

container# echo pts/0 >> /etc/securetty

いったん Ctrl+] を3回入力してコンテナを終了します。

Container es11 terminated by signal KILL.

ここからは、machinectlコマンドでコンテナを操作します。

ネットワークブリッジを使うように起動オプションを書き換えます。また、network.targetより後に起動するようにします。

$ sudo vi /usr/lib/systemd/system/systemd-nspawn\@.service
> After=network.target
...
< ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth --machine=%I
---
> ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-bridge=br0 --machine=%I

machines.targetを有効にします。

$ sudo systemctl enable machines.target

machinectl enable でコンテナが自動起動するようにします。

$ sudo machinectl enable es11
Created symlink from /etc/systemd/system/machines.target.wants/systemd-nspawn@es11.service to /usr/lib/systemd/system/systemd-nspawn@.service.

machinectl start コマンドで、コンテナを起動できます。

$ sudo machinectl start es11

machinectl login コマンドで、コンテナにログインできます。

$ sudo machinectl login es11

ここまでで、コンテナを仮想サーバと同じような感覚で扱えるようになりました。

systemd-nspawn の概要は、例によって Arch Linux のページがわかりやすいと思います。

wiki.archlinux.jp

Elasticsearchをインストールする

ホスト側で、vm.max_map_countの値を増やしておきます。

$ sudo vi /etc/sysctl.d/10-vm.conf
---
vm.max_map_count=262144

$ sudo sysctl -p

Elasticsearchのyumリポジトリを追加します。

container# cd /etc/yum.repos.d
container# vi elasticsearch.repo
---
[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Javaをインストールします。

container# yum install java-11-openjdk

Elasticsearchをインストールします。

container# yum install elasticsearch

設定を変更します。

container# cd /etc/elasticsearch
container# vi elasticsearch.yml
---
...
node.name: ${HOSTNAME}

network.host: 0.0.0.0

discovery.zen.ping.unicast.hosts: ["192.168.0.11", "192.168.0.12","192.168.0.21", "192.168.0.22"]

本番で使うなら Shard allocation awareness も考慮した方がよいと思います。

www.elastic.co

サービスを有効にします。

container# systemctl daemon-reload
container# systemctl enable elasticsearch.service
container# systemctl start elasticsearch.service

動作確認してみます。ひとまず単一ノードで無事に起動しているようです。

container# curl http://localhost:9200/
{
  "name" : "es11",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "Rnvu_GRyQoapvhnodWHb4A",
  "version" : {
    "number" : "6.7.1",
    "build_flavor" : "default",
    "build_type" : "rpm",
    "build_hash" : "2f32220",
    "build_date" : "2019-04-02T15:59:27.961366Z",
    "build_snapshot" : false,
    "lucene_version" : "7.7.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}
コンテナをコピーする

いったんコンテナを停止します。

$ sudo machinectl poweroff es11

machinectlコマンドには、export-tarというオプションがあるようなのですが、CentOS 7 に付属のものはバージョンが古いのかそのオプションがありません。

machinectl(1) — Arch manual pages

仕方がないので、rsyncでコピーすることにします。

$ cd /var/lib/machines/
$ sudo rsync -av es11/ es12
...

Node IDが重複しないように消しておきます。

container# rm -rf /var/lib/elasticsearch/nodes/0/

ネットワークの設定を書き換えます。

$ cd es12
$ cd etc/systemd/network
$ sudo vi host0.network
----
[Match]
Name=host0

[Network]
Address=192.168.0.12/24
Gateway=192.168.0.254
DNS=192.168.0.254

machinectl enable でコンテナが自動起動するようにします。

$ sudo machinectl enable es12
Created symlink from /etc/systemd/system/machines.target.wants/systemd-nspawn@es12.service to /usr/lib/systemd/system/systemd-nspawn@.service.

machinectl start コマンドで、コンテナを起動します。

$ sudo machinectl start es11
$ sudo machinectl start es12

2台でクラスタ構成を組めていることを確認できました。

$ curl http://192.168.0.11:9200/_cat/health?v
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554574589 18:16:29  elasticsearch green           2         2      0   0    0    0        0             0                  -                100.0%

ホストの追加

もう一式ホストを追加します。私はVirtualBoxのクローン機能を使って作りました。以下のあたりに気をつければ良いと思います。

  • ホスト
    • ホスト名変更: hostnamectl set-hostname ...
    • machine-id変更: rm /etc/machine-id; systemd-machine-id-setup
    • IPアドレス変更: /etc/systemd/network/ 以下
    • ブリッジのMACアドレス変更
    • zpoolのimport: zpool import -f tank
  • コンテナ
    • コンテナ名変更: zfs rename
    • IPアドレス変更
    • ElasticseachのID情報削除

クラスタの状態を確認すると、無事に4台でクラスタ構成を組めていることを確認できました。

$ curl http://192.168.0.11:9200/_cat/health?v
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1554575745 18:35:45  elasticsearch green           4         4      0   0    0    0        0             0                  -                100.0%

まとめ

Linuxコンテナ(systemd-nspawn)でホストまたぎのElasticsearchクラスタを構築してみました。 Docker+Kubernetes よりはるかにシンプルにできたと思います。 今回は私の趣味で ZFS on Linux を使っていますが、ほぼOS標準の機能だけでもできるので、運用の観点でも安心感があるのではないでしょうか。

今回の検証で、Linuxコンテナを完全に理解しました(※チュートリアルを終えたレベルという意味)。なお、Solarisコンテナについては何もわかりません(※10年以上キャリアグレードの商用環境で使いまくったという意味)。

Qiitaにも上げてみました。 qiita.com