Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年12月18日

Kayo

Ansibleで連番の複数ホストを指定できなかったのでその原因と対策

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。

フリュー Advent Calendar 2018の12/18分の記事になります。

 

先日、SSL証明書の更新をAnsibleで実施しようとコードを書いていた時にはまった

「Ansibleで連番の複数ホストを指定できなかった件」について、シェアしたいと思います。

みなさんも、「これで動きそうなんだけど、なぜ動かない!!」と思ったことあるかと思います。

今回、私もそんな状況になってしまいました。

※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。

やりたかったこと

今回やりたかった作業はSSL証明書の更新です。この作業をAnsibleで実施しようと考えました。

サーバ ドメイン
test-web-01~05 hoge.com
test-web-06~10 fuga.com

SSL証明書の場所は下記の通りです。

Webサーバ証明書ファイル /usr/local/ssl/server.crt
Webサーバの秘密鍵ファイル /usr/local/ssl/private.key
中間CA証明書ファイル /usr/local/ssl/server_ca.crt

ここで注意ポイントがあります。
test-web-01~test-web-05はドメインhoge.comの証明書
test-web-06~test-web-10まではドメインfuga.com証明書
のように、サーバによって証明書が異なることです。

実際のAnsibleコード

role配下のmain.ymlはこんな感じで書きました。

playbook.ymlはこんな感じです。

サーバによって証明書が異なるので、when句を使って
test-web-01~test-web-05はhoge_com
test-web-06~test-web-10はfuga_com
のように指定したつもりでしたが、うまくいきませんでした。

ex) test-web-05, test-web-10に対して実行した結果

エラー出力されませんが、すべてskippingされた状態になりました。

対処法

下記のようにplaybook.ymlを修正しました。

inventroy_hostname(ホスト名)の数字の部分だけを取り出し、「5以下」、「6以上」と識別するようにしました。
公式ドキュメントにも書いている通り、CentOSのバージョンによって処理を分けることもできます。

Tip: Sometimes you’ll get back a variable that’s a string and you’ll want to do a math operation comparison on it.

このTipsは今後も使えそうです!

だめだった方法

記述方法をいろいろ替えてやってみましたが、うまくいかず。。。

こちらの記事を参考にしてみましたが、うまいかず。。。

うまくいかなかった問題に関しては、また時間がある時に調べてみたいと思います。

最後に

2018年度の私の投稿はこの記事で最後になります。

2018年は大変お世話になり、ありがとうございました。来年もどんどんブログを書くつもりなので、

今後ともどうぞよろしくお願い致します。

 

みなさまにとって2018年は素敵な年となりましたでしょうか?
願わくは、2019年も素敵な年となりますように★


2018年12月17日

adachi

Reactive Swift に Completable 的なものを導入した話

こんにちは。
ピクトリンク事業部の足立です。

ピクトリンクはプリントシール機で撮影した画像データを使ったコミュニケーションツールで、私はそのiOS版のアプリの開発を担当をしてます。

 

最近は、12/10に遅ればせながら、スマブラSPを買いました👋
一応ほぼ全作やっているので、使命感に駆られるように、大乱闘を繰り広げる毎日でちょっと寝不足気味です😪
アドベンチャーモード、ふつうレベルでも意外に難しく苦戦しています。楽しいです✨

 

では、本題に入りたいと思います。

 

この記事は フリュー Advent Calendar 2018 の 12/17(月) の記事になります。
今回はピクトリンクアプリの開発で導入している Reactive Swift をプロジェクト内でカスタマイズしたお話です。

 

きっかけ

ある日のPRレビューを実施していた時のことです。
 
足立
  「ここ SignalProducer<Void, HogeError> なんですけど、呼び出し元が observer.sendCompleted() しかしていないので then(_:) で繋げないと動かないと思いますよ」

メンバーM
  「え、そうなんですか? I/Fの定義だけだとわかりにくいし、なんとかならないんですかね」
 

的な会話が繰り広げられていました。

たしかに、SignalProducer<Void, HogeError> だけを見ると completed イベントしか通知されるとは思いませんよね。
実装をするたびに、関数の中を調べるなんて時間の無駄ですし、そんなわかりにくい設計は無くすべきです。

 

ということで Completable 的なものを導入する

「じゃあ、どんな感じにしようか?」
 

と、設計しているときに「完了のみの通知だし Completed? Completable? 的な感じですかねー」と進んでいき RxSwift 的には似たような機能はないのか?
と調べ始めました。
 

ありました。RxSwift / Completable

Completable についての詳しい説明はここではしませんが、 Completable そのものを返却できるような設計のようです。
Reactive Swift でそこまでのカスタマイズをするとなると、とてもじゃあないですが大変です💦
 

そこで、弊社iOSアプリ開発チームでは 専用のオブジェクトを通知することで Completable のような扱いにする としました。

 

やったこと

  • 通知に使う専用のオブジェクトを作成
  • Completable の時に使わないメソッドの非推奨化

 

通知に使う専用のオブジェクトを作成

こんな感じで Completable を定義しました。

`Completable` の時に使わないメソッドの非推奨化

通知されるイベントが completed のみになるので、間違った実装にならないために、 SignalProducerSignal などで定義されている幾つかのメソッドを利用させないようにします。
ReactiveSwift / UninhabitedTypeGuards.swift を参考にしました。
 

主に startWith***flatMap など value イベントの通知で使用するメソッド周りです。
以下は SignalProducer 周りの定義を抜粋しています。

 

使い方

基本的には通常の Reactive Swift の実装通りです。
Value の指定を Completable にするだけです。

 

まとめ

導入した結果としては、とても良かったと思います。
きっかけ でも触れましたが、PRレビューの際の
 

  • completed イベントのみしかこない実装ではないか?
  • value イベントが通知される前提の実装になっていないか?
     

などの、メソッドの定義をだけでなく実装の中身まで遡って見る必要がなくなったと思います。
   = PRレビューでの不要な指摘も減る(する側もされる側もハッピー😉)
 

実装するときも CompletableTypeGuards.swift の設定のおかげで間違った実装を防げるのも地味に良かったりします。
慣れていけば 使えない ことはわかっていきますが、プロジェクトにJOINしてきた人たちにとってはWarning表示という目に見えるカタチで知らせてくれるのも良い感じです。
 

と、ここまで良かった点を書いてきましたが、念のために。
Completable の使用にあたっては用法/用量をまもって欲しいと思います。
便利だからといって 「本当に Completable の通知で良いのか?」 という「その機能の責務」を考えずに実装を進めることは、その時は良くても数週間後、数ヶ月後にタイヘンなことになるかも・・・😇

 


2018年12月14日

araki

Google Apps Scriptで勤怠管理用のSlack Botを作りました

この記事は フリューAdvent Calendar 2018 の12/14分です。

こんにちは。ピクトリンク事業部開発部の荒木です。普段はピクトリンクというアプリのAndroid版を開発しています。最近発売されたスマブラSPが気になっていますが、時間が溶けるのが怖いので買うかどうか悩んでいます。

今回の記事では、Google Apps Scriptを使って勤怠管理用のSlack Botを作った話をしたいと思います。

作ったもの

Slackの勤怠管理チャンネルに、今日誰が休むのかを投稿してくれるBotを作りました。これまで、今日誰が休むのかはSlackチャンネルを遡らないと分かりませんでしたが、このBotによってその問題が解決されました。

以下のように、勤怠の情報を勤怠管理チャンネルに投稿しておくと

スクリーンショット 2018-12-12 10.46.37

毎日、始業前に今日の勤怠情報を投稿してくれます。

スクリーンショット 2018-12-12 10.40.44

※ FTはフレックスタイムのことです。

使っているもの

勤怠管理Botで使っているものは、以下の2つです。

Slack Outgoing Webhooks

Slack Outgoing Webhooksは、Slack上の特定の文字列をトリガーとして指定したURLにPOSTリクエストを投げられる機能です。POSTリクエストには、投稿者や投稿した本文といった情報が含まれています。

Google Apps Script (GAS)

Google Apps Script(以下ではGASと呼びます)は、Javascript互換のスクリプト言語です。特徴は、Google Apps(Googleドキュメントやスプレッドシートなど)を操作するためのAPIが用意されていることです。また、GASはGoogleドライブ上で保管され、時間やHTTPリクエストをトリガーにして動作させることが可能です。

システム構成

勤怠管理Botのシステム構成は以下のようになっています。動作は、勤怠記録と勤怠集計に分かれます。

KintaiBotシステム構成

勤怠記録

スクリーンショット 2018-12-12 10.46.37

上記のような勤怠に関する投稿をスプレッドシートに記録します。

Slack Outgoing Webhooksによって、GASの勤怠記録コードにこの投稿の情報が含まれたPOSTリクエストが投げられます。
勤怠記録コードは、

  • 勤怠対象日:上記の投稿では 12/11
  • 勤怠種別:FT
  • ユーザー名:araki
  • 本文:【FT申請】2018/12/11(火) 10:30 私用のため
  • SlackのユーザーID:POSTリクエストに含まれているSlackのユーザーID

を記録します。勤怠対象日と勤怠種別については、投稿の本文から正規表現で抽出します。

実際に勤怠情報をスプレッドシートに記録する部分は以下のようになっています。最後の行で、GASのAPIを呼び出しています。

※ GASではなくTypeScriptで書かれています。claspというツールで、GASに変換して使っています。

勤怠集計

スクリーンショット 2018-12-12 10.40.44

「Reminder: 今日の勤怠は?」という文字列をトリガーにして、Slack Outgoing WebhooksでGASの勤怠集計コードにPOSTリクエストを投げています。

今日の勤怠情報のみを集計する部分は以下のようになっています。

※ このコードもGASではなくTypeScriptで書かれています。

作ってからのこと

自分や一緒に働くメンバーからどんどん要望が出てきたので、少しずつ叶えていきました。

  • 勤怠種別ごとに出力してほしい
  • 出力のインデントを整えたい
  • 登録できたことを通知して欲しい
  • 現在登録している勤怠情報を出せるようにしたい

まだ叶えていない要望もあります。

  • 間違えて登録した勤怠情報を削除したい
  • 曜日も出して欲しい

これだけ要望が出てくるということは、みんなにあるのが当たり前と思ってもらえるようになったのかなと思います。

さいごに

今回、勤怠管理Botを作ってみて、GASで気軽にいろんなことができるということがわかりました。何より、自分が作ったものが一緒に働いているみんなに使ってもらえて、直接フィードバックがもらえるというのがとても嬉しい体験でした。

みなさんも、Google Apps Scriptで何かを作ってみてはいかがでしょうか?


2018年12月13日

Gradle Kotlin DSLやってみた

こんばんはこんにちは、フリューのジョンです。
この記事はフリューAdvent Calendar 2018の12/13分となります。

2018/12/15 JJUG CCC 2018 Fall にて 既存アプリケーションでKotlinを導入してみた というタイトルで登壇します。
そのKotlinつながりでGradle Kotlin DSLについて書こうと思います。

Kotlin DSLとは

さてさてGradleのところを調べていると最近Kotlinという単語を見るようになりました。
どうやら Groovyではなく KotlinのDSLで書こうということらしいです。
個人的に触って感じているメリットとしては、「アプリケーションがKotlinならそのままKotlinでタスクなどを記述できる」という点でしょうか。
既存の書き方より優れている点は今のところは思い当たらないです。

Gradleプロジェクトを作成しよう

Gradle Initializrを使ってみましょう。 せっかくだからKotlinプロジェクトを選択します。

スクリーンショット 2018-12-12 11.40.30

downloadできたzipファイルを解凍して、IntelliJで開いてApp.ktにあるmain関数を実行してみましょう。

スクリーンショット 2018-12-12 13.42.30

Hello Worldとコンソールにでましたね。とりあえず、Gradleプロジェクトとしてアプリケーションが作成できていそうです。

Gradleタスクを書いてみよう

以下のようにbuild.gradle.ktsにタスクを追加してみましょう

// build.gradle.kts
tasks {
task("helloWorld") {
doLast { println("hello kotlin dsl world") }
}
}

動かしてみましょう。

$ ./gradlew helloWorld

以上です。hello kotlin dsl worldと表示されましたか?

まとめ

1.0になって間もなく、IntelliJで開いてもエラーと表示されているなど、使っていると壁にぶつかるところは多いと思います。
なので、本当に頑張る場合は、公式のサンプルを見比べながらタスクを作成してみてください。

Kotlin DSLガイド
Kotlin DSLサンプル


2018年12月12日

Hashimoto Naoto

ESXiサーバ上で動作しているゲストサーバの詳細情報一覧を取得したい

ピクトリンク事業部開発部インフラ課の「メガネとマスクを同時着用すると耳が痛くなる系エンジニア」の橋本です。この上さらにヘッドホンとか装備しようものなら、耳が爆発します。

 

本記事は フリューAdvent Calendar 2018 の12/12分です。

 

前回の記事で、ESXiサーバにパスワードなしで簡単にSSH接続できる環境を整えました。

今回はそれを活かしつつ、ESXi仮想環境をより便利にしていきます。

やりかた

  1. いい感じに必要情報を取得するスクリプトを作成する
  2. SSH越しにスクリプトを実行する

いい感じに必要情報を取得するスクリプトを作成する

ESXiホストサーバでは、「そのホスト上で動作しているゲストサーバの概要を取得するコマンド」が用意されています。

しかし、これで取得できる情報は、登録されているゲストサーバ名とvmイメージのpath, イメージのバージョン情報くらいのもの。かなり限定的です。

 

個人的見解ですが、少なくともホストサーバの稼働状態(起動中・サスペンド中・停止中)は知りたい。
できれば、いつから稼働しているかとかの情報もわかると嬉しい。

 

そういう詳細情報まで取得したい場合、ESXiに用意されているget.summaryコマンドを使います。

これを叩くと、ずらずらっとjsonモドキの形式で情報が取れます。

出力結果は長いので省略しますが、割り当ててあるCPUのコア数であるとか、いろいろな情報が出ます。

 

ですが、ここで問題となるのが「対象となるVMのID」を指定しなければならない、というところ。

 

ホストの情報は1ホスト分ずつしか取得できず、しかもそのためにはVMのIDが必要なのです。(VMID自体は上記のgetallvmsで取得できる情報です)

 

なので、これらをいい感じに組み合わせるスクリプトを用意しました。

シェバンが #! /bin/sh となっていますが、ESXiサーバで使えるのは /bin/bash ではなく/bin/sh です。
bashとは一部記法が違ったり、たとえば配列みたいな構造体が使えなかったりします。

実行権限付与をお忘れなきよう。

 

実行してみると、こんな感じの結果が帰ってきます。

スクリプト21行目のgrep以降、

この部分で取得する情報を絞っているので、たとえば「IPアドレス情報も取得したい!」という場合には

といった具合に、取得したい項目を追加してやれば良い感じになります。

SSH越しにスクリプトを実行する

esx構成

こんな感じに複数のESXiサーバから単一のストレージサーバ(仮にhoge_fuga_maxheartとします)をマウントし、そこにスクリプトを置いてやれば、どのサーバからも先ほどのスクリプトが叩けるようになります。

ssh越しに複数サーバのスクリプトを叩くには、接続用の鍵ファイルを置いてある環境で下記のようにします。

前回の記事でパスワードなしにSSH接続する環境が整っていれば、一発で全てのホストサーバの状態を取得できます。情報を取ってくるだけなら、このコマンドを都度叩くだけで解決です。

あとはイイカンジのGUIのガワを作って、URLにアクセスがあるたびに情報を取ってきてやれば、見た目にも優しい状態確認画面の完成です。

esx_kanseizu