スタビライザーを作ろう1

天球儀を作っていた裏方で
3Dプリンターさんはスタビライザーの部品を印刷
このほっとけば部品が出来上がるのが素敵すぎる

機械式スタビライザー用の部品
スタビライザーって何やねんと言われると
カメラ撮影時に手ブレを抑えて
なめらかな動画撮影をするための道具
車のネジレを抑えるものじゃないよ

下の動画のやつは電動式だけど
だいたい、こんな感じのことが出来る物、という感じ

ベアリングとかネジとか部品が一通りあったので
とりあえず仮組みしてみる

内側から順にベアリングを挟みネジを締めていく
少しコツはいるけど、ネジ締めるだけだから
サクサク出来ますな

外側を取り付ける
中心部分にカメラが繋がる支柱が通り
一番外側のパーツに持ち手が付く構造

この構造のお陰で持ちての動きがベアリングで吸収され
手ブレが軽減される仕組み

カメラ取付部と反対方向のウェイトを取り付け
シャフトの長さが物凄く短いけど、仮だし良いかな
本来は持ち手部分からカメラまでの長さの4か5倍程度
ウェイトまでの長さを取ったほうが良い

テコの原理よろしく、ここが短いと
亀の重さを支えるのに結構な重さのウェイトが必要になるので
シャフトを長くしたほうが安定性と重量が軽くなる

試しに自撮り棒の先っぽを取り付けて見た感じがこれ

回ってしまってるけど
しっかり手の動きを軽減できている

中国製のベアリングだから
スムーズに動くわけ無いだろうと思っていただけど
嬉しい誤算と言うやつか

簡単に作れた上に機能することが分かったので
一回ばらしてちゃんと組み立てる

MRヘッドセットを買いたい

ようやく姿が見えた廉価版のMRデバイス

Hololensの頃から言われていた課題

1:処理用の機械まで載せているので重い
2:MR表示される範囲が非常に狭い
3:価格が高すぎる
4:利用までの視差の調整等が長い

これを解決するにはカメラで撮影した映像を合成して
VRゴーグルに出すしか無いと言われていたが
その通りに現実的な対応で出てきて逆に安心

値段とスペックを抑えるためにスクリーン解像度は控えめだが
見える範囲全てにMR表示が可能になり
センサー、映像ともに外部処理に変わったので軽量化を果たしている
とても現実的な内容になったので是非とも欲しい一品

パソコンにつながっていないと駄目とか
常時1キロ程度の重しを頭に取り付けて作業とか
日常的に使うことは今のところ考えにくい
PS VRで鍛えられている層には大丈夫か

企業用途では発展目覚ましく
海外は色々ニュースになっていて、国内でも

小柳建設が設計から現場作業まで網羅可能なシステム開発を進め

完成途中の状態に完成品を投影したり
図面を元に埋まっているものを投影できる
設計事務所やゼネコンはかなり作業性が向上するだろう

JALもパイロットの訓練から整備の訓練
整備内容の指示まで可能なシステムの開発を進めている

こっちはAudiとかVolvoもやってるから
点検項目の多い現場ほどやっぱり都合がいい

産業的にはこれ以外にも電車の点検や、不審物の検出
橋桁やビルの点検、警備員が特定の人物を探す手助けとか
超高性能な車のカーナビも考えられる
可能性は無限大

一般事務とか開発作業でも
上手く収まれば、ディスプレイから解放されるのは
非常に喜ばしい人も多いんじゃないかね

稼働に必要なパソコン側のスペックから見るに
最適化が進んでいない物をハードに物を言わせて無理やり
許容範囲の遅延で使えるようにした
という空気が物凄く出ている
もう少し制限をかけて、セルフスキャンとか
プリレンダリングで負荷を下げれたのではないかね
何せケーブルが届く範囲しか動けないし

初期の頃のKinect付属XBOXを思い出しますな
センサー処理用にCPUコア1コ専有するから
ゲーム開発側はCPU1コア使えなかったのが
当時は色々議論の的になっとりました

しかしHololensの約30万円超、保証込み50万超という
とんでも価格から考えるととても魅力的で
妥協込みでも良い価格帯にしっかり収めてきたと思う

とりあえず買うならHP製かな

パズドラの盤面からコンボ数を計算する 2

前回に引き続き盤面の計算を考える

人間がやると、見たまんまで数えれば良いものを
コンピューターにやらせるにはどうすればいいか
考え方は色々あるし、こういう時用の優れたアルゴリズムもあるんだろう

こういう問題はプログラミングの基礎で習う
ソートアルゴリズムの勉強みたいで面白いと思う

■確認

ドロップの繋がりは非常に多くのパターン存在しる


こんなパターンや


こんなパターンとか
ここから縦か横に3個以上連続で並んでいるものだけ
どうやってカウントするか、が課題

前回のサンプルに作った時の考え方が
プログラムとしてそのまま実装されてるんで
ぶっちゃけそっち見たほうが早いかもしれない

■考え方1

ど単純に調べる流れで行くと

1・配列の開始点になる左上から順に調査開始
2・自分の周りに同じ色のドロップが並んでいるかチェック
3・同じ色のドロップがある場合は座標を全て記録
 3.5・無い場合は1の続きに戻る
4・記録された座標の周りにさらに同じ色のドロップが並んでいるかチェック
5・新たに同じ色のドロップが見つかり座標が重複していない場合は座標を記録

こんな感じかな?
最終的に、配列の数=ドロップの結合数となる
これで行くと同色のドロップが幾つ並んでいるのか?
は最終的に分かるし座標を除外してやることで
1番の調査に戻ったときも同じドロップを多重に数える心配も無い

しかし、この方式で問題なのは
このループが終わった時点で
「縦か横に3個以上連続して並んだ物をカウントする」
という条件を満たせていない
数えながら、縦横の座標の連続数もカウントすれば良いけど
調査中に分岐が多いと、カウントしなければいけないポイントが増えて
配列がややこしくなる


こういう並びの場合は更に困ることになる

途中までは順調に計算できて

こういう感じに縦横が伸びていってると計算できる
しかし、このまま進んでいくと


こういう形態になったときに繋がることになるので
どことどこの分岐から始まったカウントを結合するのか
を判断する仕組みも必要になり
正しい値を求めることは出来るけども計算が複雑化する

配列への格納方法を最適化したり
検索テーブル的なものに新しい座標を追記して
ループを回す方法等も考えたが
その場合は3つ以上並んでいる事を計算後にまた計算する必要があり
考えていた時点で間違いなく面倒な上にバグが発生しやすい、という結論に達した

人によっては、こっちの方法で良い解決策を見つけ出し
綺麗に収める人も当然いると思う。

■考え方2

サンプルプログラムはこっちの考え方を採用

迷路探索のアルゴリズム並に網羅する考えだと少し面倒になる
なのでこの問題をもう1段分解すると割りと簡単な話になる


この盤面を考える場合に
以下のように分解して考える


横1列づつを計算


縦1列づつを計算

同じ色が3つ以上連続している場合にその座標を記録させ
縦と横の記録を結合、さらに同じ座標を含むものを1つに結合することで
縦横を含めた、同じドロップの集合で尚且つ3つ以上並んでいるものを計算する

縦横の計算の時点で縦か横方向に3個以下は除外され
綺麗に3個以上のブロックだけが計算される
逆に見ると、3個以下のドロップを除外しているので
フィルター処理と見ることも出来る

色ごとに集計をとり
縦横の配列を合体させれば
各色ごとに
・幾つのドロップを繋いで消したのか
・合計何コンボになるのか

が導ける

この方法の場合、今回は書かないけどパズドラのドロップの消し方に
横一列を消した場合の列消し、4個ドロップを並べて消すと2way
十字型に消すと十字消しなんかがあって、これが計算しやすい

後、以前実際のパズドラのゲーム内で

闇ドロップが上記のように並んでいる場合
縦横は繋がっているけど3つ以上並ばないといけない
というルールに合致していないため本来は2コンボにならないといけないのに
実際には1コンボになる、というバグがあった

この計算方式だとこれは発生しない

■2回めおわり

長くなってきたのでここで一回締める。
問題を解決する場合、与えられた情報をそのまま
解決しようとするんじゃなくて
内容をさらに細分化し細分化した内容ごとに
考えていったほうが単純化出来て最終的に早い場合が多い
とっつきやすいところから進めていこうの考え方かいね

2020年からプログラムの授業必須かされるけど
イギリスとか先駆者の情報を活かし
言語をそのまま教えるとかいう
英語授業のコンピューター版みたいな事をせずに
問題解決や認識力の向上とか
Program(手筈とか計画)の意味に沿った
内容が展開してほしいですな

どないなるやら

寺の柱飾りにいる象は貘

お寺とか神社を見に行った時は
柱飾りとか、天井画をよく見ている

門飾りや柱飾りに施されている装飾は
その建物がどういう建物なのか何を祀っているのか等
色んな情報を含んでいる。柱の組み方や、装飾の有無で
その神社や寺がどのくらい格式高い物なのか
ある程度推測することも出来る

今回GW中に回った中の一つ
かるたの聖地近江八幡宮だと
本堂とは別で恋愛成就の社があった

この建物は恋愛に関するものなので
柱飾りとしてハートが掘られている

そして比叡山に登って凄く気になる柱飾りを発見

パット見、ゾウです

何故ゾウがいるのか謎
その後、近江八幡の日牟禮八幡宮(ひむれはちまんぐう)に行ったときも

似たようなのがいる

ただこっちを見ると、ゾウじゃないのかな?
と思い気になっていた
龍、獅子、朱雀、鳥、蓮とかは
よく見る気がするけどゾウは何なのかと

帰ってから調べてみると

この柱から突き出た飾りは
「木像」と言うそうで、ここに掘られているのは
夢を食う幻獣でお馴染みの「貘」

じゃぁ、何故「貘」が掘られているのか調べてみると
元々貘は悪夢を食べるばかりじゃなくて鉄も食べる

なので武器になる鉄を食べることから
平和の象徴として祀られる事があるんだそうな

なるほど、と思ったけど
平和の象徴を掲げる理由があったならば
比叡山にお寺が出来たのが奈良時代後期から平安時代だった気がするので
長い平和の世の中を祈る目的なのか
それとも何か戦乱があったのか、続けて気になる

歴史に詳しいわけじゃないので
ぼけ~と眺める程度で見た感じでは
戦乱っぽいものはないんかな?
都を平安京に移して時代が変わったとなってるし

ただ、比叡山に登るのに使うケーブルカー
これの途中に、ケーブルカーの工事中に
織田信長が行った焼き討ちによって死んだ人たちを
慰霊するためと思われる石像が大量に見つかり
それを安置している

というアナウンスと、祠に並べられた石像を見ていたので
戦乱の時代に焼き討ちで死んだ人への鎮魂と
平和を願って再建されたのか?

とか、一人で勝手に妄想にふけっていた

美術展とかもそうだけど
何故そうなったのか、何故そう表現したのか
詳しくなくても、この辺をボケーと考えながら見てみると
思わぬ発見があったりして面白いと思う

何とも変な発見がありましたわ

Orray(天球儀)を作ろう8

前回見事な空回りを見せた天球儀
ギアの調整もあるけど、肝心なのはメインシャフトのブレ


真上から見るとこんな感じで
シャフトの中にギア用のドライブシャフトが通っているが
固定されていないので中で動きまくる

色々見ていると、1個だけ必要と書かれていて
どこに使うかわからなかったベアリング「684zz」がある
もしかして、ここに使うのか?

アーム部品のシャフトを通す部分の内径は8mm
684zzは外形9mmなので9mmドリルで中をザグリ、ベアリングを取り付ける
内径は4mmなのでドライブシャフトはそのまま通る
やっぱりここ用か・・・

後は、一旦全部バラしアームとセンターギアを
順番に調整しながら組み上げていく
星が繋がっているパイプの角度が悪いと
ギアに当たるので曲げ角の調整も一緒に行う

そして、一通り調整し組み上がった結果がこれ

動いた・・・・
物凄い達成感がある

モーターのうるさいギア音が無かったら
ずっと見ていられそう

まだ、星の色塗りが残ってるけど
とりあえず一段落したかいな?
綺麗に回すのは見かけ以上に職人技がいると痛感

子供向けの夏休みの工作とか
趣味に良いかと思ったけど
制作にかかる手間と時間を考えると
物凄くおすすめできない

でも完成品の満足度は素晴らしいです
ゆっくり星に色を塗って行きますかいね

とりあえず次は、スタビライザーを作ろう

Orarry(天球儀)を作ろう7

物作りにおいて
全作業時間の80%が、残り20%の工程で費やされる
8:2の法則の物作り版みたいなのがある
正にそんな感じ、前回組み上がった天球儀
部品が揃えが形はすぐできる
しかし、綺麗に回らない・・・

アーム部品の上下にギアが取り付けられた部品

金属とPLAの接地面が小さいせいか、かなりスベる


摩擦が足りないわけだから
表面を荒くして接着剤流せばいいかと
やってみたけど、全く効果なし

そこで閃いたのが

3mmパイプの軸なので4mm~5mmくらいのプラスドライバーを
ゴムハンマーとかで打ち付けてやると
真鍮は柔らかいので、ギア穴の中で裂ける

こうなると裂けた部分がPLA部品に食い込むのでがっちり固まる
ほぼ滑らなくなった

打ち込む角度が垂直じゃないと、ギアごと斜めになるし
強く打ち込みすぎると、ドライバが抜けなくなるので注意

後は、ギア自体をスムーズに回せば良いんだけど
ヤスリやナイフで少しづつあたりを見ながら削っていく

調整がある程度進むとこんな感じになる

ここまで来ると、始めに購入して一度も登場していない
ギアドモーターさんの登場

5v駆動の製品の時点でお察しだが
USBから電気を取るだけで回る

なので、100均に売ってる充電用のUSBケーブルを購入し

こいつを分解して使う
UBSの端子は右端と左端の部分が電源に割り振られている

いつの間にかデバイスid用の信号線増えてるのね
1番が「+」5番が「-」となる
回転向きの問題だけなので完成した時の公転の向きを気にしなければ
どっちでも良いと思う、良いのか?


物が充電用なので初めからケーブルは2本のみ
スマホに接続する側のケーブルを根本でぶった切り
先端部分の皮膜を向き、半田でコーティング


後はギアドモーターを繋げば準備OK


土台部分に取付用のマウントがあるので
ここに3mmの木ネジで留める

そして、再度組み上げ、電源を投入してみた結果がこれ

はい、調整ミス・・・・
というかメインシャフトが固定されてないから思いっきりズレている
何か対策が必要ですなこれは

後ちょっと~

パズドラの盤面からコンボ数を計算する

プログラム系の話しも書かねばと思ったけれどパット思いつくものがない
コーディングの技術的な内容なら素敵な記事は世の中たくさんある

2年ほど前にパズドラのシミュレーターサイトを作った
パズル盤面から、コンボ数やら列消、2Wayを計算し
チームのステータスから与ダメージを計算するプログラムがあるんで
全部書いてるとえらいことになるので
ここか盤面からどうやってコンボ数を計算させたのか
な部分を書いてみようかと思う

多分内容は簡単だと思うし
プログラムというより考え方の話になる気がする

いきなり話が脱線するが
プログラムをある程度習得すると
コード自体の品質やテクニックうんたらはさておき
仕様が決まっていて、単体で完結するシステムなら
割りとなんでも書けるようになってくる

そこからコーティング関係の技術
開発技法、フレームワーク、OSからネットワークIOT系のハードとか
複数言語プログラム、うんたらと色々広がって行くか
どこかに特化していくか

作文とか物語を作るのをイメージすると良いのかもしれない
効率的に書き、誤字、誤植を減らし
定型句、定型文を活用し安定した品質を保ち
複数人で執筆しても効率よく作業が行える

機械に指示を出す指示書を、いかに効率的に作り上げるか
これと同じではないかと

たとえば、「シンデレラ」という作る対象があったとして
完成品は同じシンデレラでも
文書力や表現、構成によって作り人で内容が物凄く変わる
絵本とディズニー作品では受ける印象は全く異なると思う
各パートを担当する人、指揮を執る監督
それぞれのイメージや解釈が多かれ少なかれ出て来る
同じ話でも語り手によって伝わり方が変わるのと同じ

プログラミングはこう言うのに似てる
文書力が優れると表現したイメージを的確に文字(プログラム)で書ける

表現が優れていれば、分かりにくい表現をさせけ、完結に書くことができる
ページ(メモリ)の節約が出来、読む時間(処理時間)の短縮になる

構成が優れていれば、後から読み直す(変更や、作り直し)時に
少ない手間で目的の部分にたどり着ける

全体の指揮を執るチーフの下で
複数のプログラマがコードを書くが
その書き方はそれぞれ異なりやすい、人間性が出やすいとも言うのかね

なので、ある意味プログラマ、特にコーダーの人は
文系、脚本家とか作家に近いのではないか?と思ったりする

一人で黙々と書き続け、その人独自の世界観を作る人もいるのは
特に作家もプログラマも同じだろう
プログラムの場合悲惨な結末を迎えやすいが・・・・

そして前後するが、大事になるのが
この例だと「シンデレラ」という最終目的の部分

シンデレラとは何か
シンデレラとはどういう話(機能)で構成されるのか
これらの定義、解釈が作品の良し悪しを決める
要するにあらすじの部分

これが適切で、かつ良いもので無ければ
その後の作家人(プログラマ)が優れていても
良いものにはならない

個人的に定番のカレーで例えたほうが適切かもしれない

カレーを作る、という目的は明確なのに
カレーのあらすじに、「メロンを投入」とかあったら
調理過程が優れていても、美味しそうになる未来が見えない
解釈した者の感性が疑われる瞬間である

冷や汗が出るほど前置きが長くなりましたが

パズルの盤面を計算する、という目的に対して
優れたプログラムを書く方法は色々あるし
そういった技術は間違いなく自分より優れている人の方が世の中多い

なので、どういう段階を踏んで「盤面の計算」という
最終目的に到達するのかという問題解決能力に当たる部分

要は、アルゴリズムをどうするのか
(やっと言えた・・・。)

この部分を、うだうだと書いていく
プログラムあんまり関係ないし
パズルやクイズを解くみたいだから頭の体操にもなっていいと思う

■というわけで今更お題

・1 パズドラのパズル盤面5x6マスの中を精査し
   3つ以上繋がっているドロップが何組あるか調べる


こういう風に並んでいるドロップのグループを数える
この場合
回復ドロップ、1コンボ
光ドロップ、1コンボ

・2 ドロップは縦横どちらかに3個以上並んでいないと
   同色のドロップが繋がっている状態でも消えない(カウントしない)


縦方向には木ドロップが3個並んでいるけど
横方向には2個しか並んでいないので
横にはみ出た分はカウントしない

こんな感じ

文で書いてもあれなので
実際に動くサンプルと言うか、作ってたやつから
盤面部分だけを引っこ抜いたサンプルが下になる
コードが汚いのはご了承下さい。。
こんな感じで盤面の内容を計算してコンボ数が分かる

iPhoneのRawモードを使う

あるのは知ってたけど使っていなかった機能
RAW撮影機能

初めから入っているカメラ機能で使えないのと
微妙な評価が多かったから
これまではあんまり気にしてなかった

今回滋賀に行ってくるついでに
いつも持っていくカメラだと重いのから
このRAW機能が使えるLightRoomMobileで全部撮影してみた

初期状態だとJPG保存なので

画面上に「JPG」と出ている所をタップ
設定画面が出てくるので「DNG」に切り替えればいい

同じく初期状態だと
撮った写真を片っ端からクラウドにアップロードする
勝手に同期されるので便利は便利だけど
撮影枚数が多いと格安1日足らずで2GBは余裕で超え、3GB~4GBに到達する
通信制限にひっかかる恐れがある

アプリ左上の「Lr」マークをタップし


表示される設定から「WiFiでのみ同期」を有効にする
これで勝手にアップロードされなくなる

現像はパソコンのLightRoomで実施
iPhoneでも同じような感じで現像できるけども
現像中は本体の発熱が凄いのと、電池の減りが加速するので
帰ってからのほうが良いかも

やっぱりセンサーサイズが小さいからか
ノイズが結構目立つ、この辺は前に見たレビューそのまま
代わりにディテールが残っているから自分でノイズ除去しながら
調整することになる

個人的に気になったのは
スマホを立てに構えて撮影する前提だからだと思うけど
横向に構えて撮ると像が結構歪む
お前の腕が悪いんだよと言われると精進しますとしか言えないが
ミラーレスでバシバシ撮ってた感覚でいたので
ちょっとビックリした

標準のカメラアプリは
色々自動で補正かけてるんだね

ノイズキャンセルと簡易HDR化
歪み補正を行った結果が下記の写真になる

ほぼ手ぶらで、散策できたことを考えると割りと満足な結果
iPhone7Plusだともうちょっといい絵になるんかね

撮影したデータはCreative Cloud経由で自動でパソコンに飛ばせるし
スマホのGPSのおかげでどこで撮影したかも地図で確認できる
便利な時代になったもんだ

前置きが長くなったが、以下写真

Docker Swarmをさわる4

前回コンテナの稼働まで行ったので
今回はnginxで簡単にロードバランスする

1回目のやつにロードバランサの事
書いてない気がする・・・。
クラスタの外にいるので
今回作るのは別ホストになります、はい

・作る環境
OS:CentOS7

・ネットワーク
IP:192.168.2.174

■OS環境準備

同じくとりあえずアップデートと
邪魔になるのでSelinuxとFirewalldは止める

・アップデート他

# yum update -y
# sed -i "s/SELINUX=enforcing/SELINUX=disabled/g" /etc/selinux/config
# systemctl disable firewalld
# reboot

■nginxリポジトリ追加

・ファイル作成
# vi /etc/yum.repos.d/nginx.repo
以下を記入
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

追加のリポジトリが標準で有効になっているのが
意見が別れる今日このごろ
特定用途だけなら良いんじゃないのかと思ったり思わなかったり

■nginxインストール

# yum install nginx
# systemctl start nginx
# systemctl enable nginx

■nginx設定
標準では行っているhttpセクションの中身を全て消し
下記のようにする
「upstream」の後に書いているのがリバース先の
管理名になるのでここは好きに記載
「max_fails=3」にて3回接続に失敗したらサーバーを切り離す
切断条件はtimeoutとか幾つか種類があるので
試す場合は公式で確認推奨

# cd /etc/nginx/
# vi nginx.conf
 
http {
    upstream wasabi {
        server 192.168.2.175 max_fails=3;
        server 192.168.2.176 max_fails=3;
        server 192.168.2.177 max_fails=3;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://wasabi;
        }
    }
}

■nginx再起動
# systemctl restart nginx

■確認

これだけでとりあずロードバランスしてくれる
ブラウザから設定したIP今回なら「192.168.2.174」に繋ぐと

wordpressのデフォルトテーマが表示される
このままだとリンクを踏んだ場合にクラスタ側のIPに転送されたり
このIPから管理ページに入れない

合わせるならば
クラスタ側のIPで管理画面に入り

「Wordpressアドレス」と「サイトアドレス」を変える
これで、一般向けページも管理ページも入れる

本来はDNSも立ててドメインでやったほうが
より実環境ぽくていい感じになる
PowerDNSとか直ぐに立てれるから一緒に作ったほうが良い

後はテーマとかプラグインの更新が今のままだと出来ないんで
FTPの設定とかあるけど、それをやるにはパーミッションやら
Dockerのホストとコンテナのユーザー問題とか色々あるんで
Wordpressの公式コンテナよろしく
Dockerno流儀に従い、Wordpressごとコンテナに内包して
バージョンアップの時はコンテナごと入れ替えたほうがいいと思う
ローリングアップデートもあるし

■終わり

vmとかhypervとか仮想化にやらクラウドに比べると
コンテナはこれっていう環境が無いような
ベストプラクティスが無い代わりに
全てのレイヤーで非常に大量の選択肢があり
構築する人、会社の考え方や運用方法の違いで
多様なシステムが考えられている

lxcから発展し、OSS化してDocker社が焦り
無い機能をフル装備してGoogleがKubernetesを作り
カオスな状況になってるな~と思う
遥か前からあったBSDのサンドボックス機能は何故流行らなかったのか

リソースの集約率向上とか、障害耐性の向上とかメリットは色々ある
Dockerの貢献で一番大きいのはサーバーに明るくないプログラマが
欲しい環境を直ぐに用意できて不要になったら消せばいい
この手軽さが大きいと思う

この手軽さを実際のサーバー運用環境にも持ってこようと
管理者が四苦八苦しているのが現在の状況かいね

実際に動かしてみると
想定外や関係のないものが問題なったり
運用上の問題に直面することになったりと
思っていたもの、欲しかったものとは微妙に違っていたりする
そういうトライ・アンド・エラーを繰り返して
色んなノウハウや生まれて進歩していく
なのでとりあえずとっつくことが出来る環境は
あったほうがいいと思う

後、物凄く余談だけど社内ではRancherOSメインで進めている
初めは「Rancher」な「OS」なのかと思っていて
マスコットが何故牛なのか疑問だった

ある日ふとイメージ検索してみると

「ランチェロス」といういかしたメキシコ料理が並んでいる
美味そうやな

Docker Swarmをさわる3

SwarmモードなDockerとGlusterの共有ボリュームが出来たので
次は上で動くコンテナを準備する
以下の作業は全てMasterで行う

■準備するコンテナ
・PHP+Apache
・Mysql

両方公式のコンテナを使用
web側はPDO等いくつかExtensionを追加する必要があり
イメージをカスタムする必要があるので

このイメージを共有する方法が何か必要になる

1・DockerHUB
2・プライベートリポジトリを用意する
3・全てのサーバーでイメージを作る

大雑把に上のどれかが必要になる
今回は面倒なのでDockerHUBのアカウントが何かある
という前提で進める

■ApacheのDockerfile作成

PHPの設定追加のExtentionのインストール等
付帯情報が多いので興味があればここで確認推奨
管理コマンドとか色々用意されていて便利だけど
中身見るとphpizeとか最近あんまり見た記憶がないコマンドが使われている
ソースからビルドする前提とか
パッケージ管理に慣れた最近だと何か凄いなぁって思う
メンテナーに感謝です

・Dockerfileの作成
# mkdir ~/centokun

# cd centokun
# vi Dockerfile
※下記を記入

FROM php:5.6-apache
RUN apt-get update && docker-php-ext-install pdo_mysql mysqli mbstring

■Apacheイメージ作成

※イメージ名の「yasukosan/centokun」のyasukosanの部分を
 DockerHUBのアカウント名にする
 全てのサーバーでビルドする場合は「localhost/centokun」で良い

# docker build --rm -t yasukosan/httpd .

余談だけど、初めはCentOSコンテナで同じ環境を作っていたのが
いつ頃からかprivilegidを有効にしないと動かなくなった
色々言われているけど
実環境ではコンテナにCentOSを使わない方が良いんだろう
運用によるけどサービスごとに公式のイメージをカスタムするほうが
正解かもしれない

■DockerイメージをDockerHUBに上げる

・DockerHUBにログインする
# docker login -u yasukosan -p *********
Login Succeeded

・上げる
# docker push yasukosan/httpd

※これでコンテナを作るときに「yasukosan/httpd」で
 イメージを指定すると使えるようになる

■wordpres準備

wordpressの日本語サイトから最新版のwordpressを落とす
これをglasterの共有領域に展開する

master、nodeどれでもいいので
前回作成した共有ディレクトリに移動し
コンテナにアタッチするディレクトリを作成

# cd /glfs/data
# mkdir wasabi_web
# mkdir wasabi_db

・webの作業ディレクトリに移動
# cd wasabi_web

・wordpressを展開
 直接ダウンロードするか
 何かしらの方法でアップロード

※テスト時のバージョンは4.7.4

# tar zxvf wordpress-4.7.4-ja.tar.gz
# rm wordpress-4.7.4-ja.tar.gz

■swarmネットワーク作成
標準で用意されている「ingress」は
内部通信用のネットワークの為別途用意する

・作成
# docker network create -d overlay test_network
40phcxdlek0a4s116bpjj4428
・ネットワークの確認
# docker network ls
40phcxdlek0a        test_network        overlay             swarm

■Mysqlコンテナ起動
 swarm上にサービスとしてMysqlコンテナを起動する

※公式標準のままだと文字コードが「latin1」になってるので
 本来は設定ファイルを別途作成しマウントする事になる
 コンテナ向けに設定の自動読み込みや設定可能な環境変数が充実しており
 興味があるか、調べるならば公式の内容を確認


・コンテナ起動
 下記のような設定起動
 ◯コンテナ名:mysql
 ◯使用ネットワーク:test_network 上で作ったやつ
 ◯データベースの設定:rootパスワードやらwordpress用のDB作成やら
            wordpresが使うユーザーの作成やら
 ◯データベース保存先マウント
 ◯レプリカ数1で起動
 ◯使うコンテナはmysql5.7

docker service create \
--name mysql --network test_network \
-e MYSQL_ROOT_PASSWORD=test123 \
-e MYSQL_DATABASE=wordpress \
-e MYSQL_USER=wordpress \
-e MYSQL_PASSWORD=test123 \
--mount type=bind,source=/glfs/data/wasabi_db,target=/var/lib/mysql \
--replicas=1 mysql:5.7

■Mysqlコンテナ起動確認
無事起動すれば下記のようになる

# docker service ls
ID            NAME   REPLICAS  IMAGE      COMMAND
1ohmu37jpbut  mysql  1/1       mysql:5.7

・Glusterの共有領域確認

・Glusterは大きなファイルの共有が得意なので
 普通は小規模な書き込みが発生するDBには向いていないので
 こういう使い方は多分良くない
※下記のようにデータベースが保存される
 全てのサーバーで同じファイルが保存されているはず
# ls /glfs/data/wasabi_db/
auto.cnf  ca.pem client-key.pem ib_logfile0 ibdata1 mysql
private_key.pem server-cert.pem sys ca-key.pem client-cert.pem
ib_buffer_pool ib_logfile1 ibtmp1  performance_schema
public_key.pem server-key.pem wordpress

■Webサーバ起動

「replicas」を指定する方法だと
コンテナが一つのホストに偏ることが多々ある
可用性を上げるために増やしてるのに偏っては意味が無いので
全てのホストで動かす「global」モードで動かす

・コンテナ起動
 下記のような設定起動
 ◯コンテナ名:wasabi
 ◯使用ネットワーク:test_network 上で作ったやつ
 ◯wardpress保存先マウント
 ◯グローバルモードで起動
 ◯ポート80を繋ぐ
 ◯使うコンテナはyasukosan/httpd 自分のDockerHUBに上げたやつを使用

docker service create \
--name wasabi --network test_network \
--mount type=bind,source=/glfs/data/wasabi_web/wordpress,target=/var/www/html \
--mode global --publish 80:80 \
yasukosan/httpd

■確認

1分もしないうちに
Master、NodeどちらのIPでも良いので
ブラウザからアクセスすると

定番のWordpressの初期設定画面が表示される

■wordpress設定
パーミッションを設定していないので
初期設定をこのまま進めることは出来ない
ので、手動で直す

どのサーバーでもいいのでログイン後

・wprdressのディレクトリに移動
# cd /glfs/data/wasabi_web/wordpress/

・設定ファイル作成
# cp wp-config-sample.php wp-config.php

・編集
# vi wp-config.php

・コンテナ作成時に作成したデータベース名を入れる
define('DB_NAME', 'wordpress');

・コンテナ作成時に作成したユーザー名を入れる
define('DB_USER', 'wordpress');

・コンテナ作成時に作成したパスワードを入れる
define('DB_PASSWORD', 'test123');

・Mysqlコンテナ名を入れる
define('DB_HOST', 'mysql');


完了後、再度どのサーバーでもいいので
ブラウザからアクセスすると

WordPressの管理ユーザー作成画面が表示される
適当に情報を入力、メールも空欄になってるけど入力し
「wordpressをインストール」をクリック

インストールが完了するので
「ログイン」をクリックし

作ったユーザーでログインすると

管理画面が表示される

どのサーバーにアクセスしても
管理画面に入れるけど、設定時のサーバー情報が
wordpressのアドレスとして保持されるので
今の状態だと他のサーバーからログインしても勝手にリダイレクトされる

内部的にはロードバランスされているはずだけれども
このままだとアクセスの入口になるホストが1台なので
他が動いていてもこの1台が落ちたらサービスは止まる

■3回目終わり

この時点でとりあえずどれかサーバーが落ちても
wordpressが止まらない状態にはなっている
実際には復旧に問題があるので
このまま運用は当然不可能だけど
イジれる環境がまず用意できれば

目標の設定で色々出来るので
試験用途では意味があるんじゃないかと思っている

次回はnginxで簡単にロードバランスをさせる
なんかDNS無いからぱっとしませんな