critical alertのブログ

普段はサーバのお世話係をしています

我が家の Hue の運用について

おはようございます。 この記事は feedforce Advent Calendar 2017 - Adventar の4日目です。

昨日は 将棋歴17年。成長の止まった僕が、1日20分で強くなる方法。 – Daisuke Mori – Medium でした。

毎日コツコツ練習し、最新の情報をキャッチアップするのは何事にも言えることですね。ちなみに私の将棋知識といえば三月のライオンくらいですね。にわかもいいところです。

さて、先月社内の LT 大会で 「Hue で始めるおうちハック入門」というテーマで LT をしました。 スライドはこちら。

おうちハックガチ勢からすると取るに足らない内容ですが入門としては Hue は手軽で良いですね。

今回は Philips Hue を導入してだいたい一年くらい経ったので現在の運用をまとめておこうかと思います。

Philips Hue とは

http://www2.meethue.com/ja-jp/

みなさんご存知スマート電球です。

自分が買ったのはホワイトグラデーションってやつです。いわゆる電球色と昼白色のみの調光に対応したモデルでフルカラーのモデルと比べると少しお安い感じです。 フルカラー版だと雨が降る日は青くしたり、ここぞというときにピンクな明かりにしてムーディーな演出をしたりできますが自分は使いこなせる自信がなかったのでホワイトグラデーションにしました。

電球の操作方法はたくさんあります。

  • スマホのアプリから操作
  • Siri(Home Kit), Google アシスタント, Alexa 経由
  • Web API 経由
  • 付属のリモコン

リモコン以外は電球を操作するまで数ステップ必要です。

スマート○○の弱点

Hue に限った話ではないのですがアプリ経由でスイッチ入れられるというのは最初はいいんですが日常的に点けたり消したりするようなものだといちいちスマホのロック解除してアプリ立ち上げて...みたいな操作がめんどうになってくるんですよね。

最終的にボタン1個押せば済む物理リモコン最強や...ってなってしまいがちです。

真価は自動化

スマート○○が真価を発揮するのは自動化です。操作がめんどうなら自動化してしばえばいいのです。

たくさん用意された操作手段から自分に合った方法で自動化していくのが楽しいところです。

幸い Hue の場合はオフィシャルのアプリがとても充実していてノンプログラミングで大体のやりたいことはできます。

自動化を考える

ここでは電球を操作したいタイミングを考えてみます。 自分の生活サイクルだと大きくわけて下記の4つ。

  • 朝起きた時
  • 夜寝る時
  • 外出時
  • 帰宅時

昼間は仕事なので考えません。また休日は少し違うこともあります。 上記パターンが自動化されていればスイッチに関わる運用が楽になると言えます。

それぞれ考えてみます。

朝起きた時、夜寝る時

起きる時間に勝手に点いて、寝る時間になったら消える、が理想です。

これは Hue アプリでは「ルーチン」でできます。

朝は起きる時間に合わせて電球が点く設定をしています。 30分くらいかけて少しづつ明るくするようにしているのでいきなり全開で明るくならないところが良いです。 朝は光を浴びるとセロトニンが分泌され気持ちの良い目覚めがうんぬんかんぬんという話もありますが感じかたは人それぞれですね。(個人の感想です)

夜は寝る時間の30分くらい前から少しづつ暗くするようにしています。暗くするといっても完全に真っ暗にはならないようにしてます。 部屋がだんだん暗くなってきたら「そろそろ寝る時間か...」と悟り、寝る準備を始めます。

生活サイクルを一定に保つのに部屋の明るさというのは意外と大事なことがわかりました。

外出時、帰宅時

家を出る時は点けたままで家を出て、家から離れたら自動的に消えるように、帰宅時は家に近づいたら自動的に点くようにするのが理想です。

これは Hue アプリの「帰宅 & 外出」というまさにそのままの機能でできます。 家の位置を設定しておいて、位置情報を使って消したり点けたりします。

時間固定で明かりが点くようにすると飲みに行ったりちょっと帰りが遅くなった時に残念な気持ちになるのでやはり位置情報で点くのがベストだと思います。

ちなみに設定した初日はすっかり忘れてて帰宅時に外から自室をみたとき「あれ、電気点いてる、え、空き巣!?」ってなったのはいい思い出です。

所感

  • 自動化してこそ真価を発揮する
  • 大部分は自動化して、個別に操作したい場面のみアプリ等から操作すると良い

上記のおかげで普通に生活していて電球のスイッチを操作したいタイミングはほとんど自動化されています。

たまに読書したいときなどは電球色に切り替えたりはしますがそのタイミングでアプリを操作すればいいのであまりめんどうは感じません。 そういうスポットで切り替えたいときなどは音声アシスタントを使って操作できるのがいいのかなーと思っています。

ほんとは Amazon Echo が届いていればそれも合わせて紹介したかったのですが課金額が少ない(真意は謎)のか、なかなか Amazon さんから購入権利がもらえないのでまた別の機会にしたいと思います。

そんなこんなで以上となります。

明日の feedforce Advent Calendar 2017 は

弊社のアイス大好き人事 Yasuharu Watanabeこだわらないこだわり?!フィードフォースがつけた組織や制度のネーミング紹介 です。次回をお楽しみに!

Serverlessconf Tokyo 2017 に行ってきました

11/03(金) に開催された Serverlessconf Tokyo 2017 に行ってきました。

参加のモチベーションとしては現在 AWS Batch を活用してバッチシステムを作ろうとしているのと、AWS Lmabda を使って AWS サービス同士をのり付けしているうちにこの分野に興味が湧いてきたところでちょうどいいところに Serverlessconf の開催を知ったため最新情報を仕入れようと思って参加しました。 それからよくある文脈としては「サーバーの管理をしなくていいぜ、やったー」みたいに語られることが多い気がしているので果たして本当にそうか?という疑問を解消したかったのもあります。

イベントそのものの話

飯田橋ベルサールが会場でした。

セッションは2トラックあってどちらも混みすぎることなく基本的に着席して聞けたのでよかったです。 スポンサーブースもアンケートに答えるとTシャツもらえたりして豪華だった気がします。 著名な方が普通にブースにいて気軽に話せるのはよく考えるととてもすごいことなのでは...と思ったりました。

あとお昼に出たお弁当が美味しかった。

以下、聞いてきたセッションの簡単な感想です。

続きを読む

月イチで定期的にもくもく会をやってる話

今年に入ってから月に1回くらいの頻度でもくもく会をやっていて、1月から始めて今月で4回やったのでこの辺で感想をまとめておこうと思います。

もくもく会

d.hatena.ne.jp

どこかに集まって各自で自習をする会、です。

なぜやっているか

自分は普段の勉強や作業は家でやろうとすると誘惑が多すぎてすぐゲームを始めてしまう意志の弱い人間なのでなかなか集中できないタイプだったりします。

以前は他の方が主催するもくもく会に参加していたのですが最近はあまり開催されておらず、かといって家でやろうとしても上記の通り気を抜くと遊んでしまうので最近勉強できてないなと思っていました。

無いなら自分が開催すればいい!ってことで社内で軽く募集したら3人くらい集まったのでとりあえずやってみようということで始まりました。
スタンスは一人でもくもくするのは寂しいのでどうせなら一緒にやる人集まれ〜〜って感じです。

こんな感じでやっている

主催といってもやってることは大したことなくて日時の設定と開催場所の選定くらいです。

基本的には休日の開催で土日どちらか。でもだいたい土曜日です。日程は月末あたりに調整さんを作って日程を決めます。
休日なのは平日の業務後だと力尽きていて別のことをやる気力がないので一日しっかりと時間を取ってやろうという思いです。

時間は 11:00 ~ 19:00 くらいで途中参加、途中離脱OK。 とくに成果の発表とかもしないです。発表したい人はやります!

あとはこのもくもく会専用の Slack team を作って参加者を Invite してます。

やってる場所

意外と大事なのが会場選び。
普通のカフェ等でなくコワーキングスペースの一日利用を活用しています。
一日利用だとだいたい 1500円〜3000円 くらいのところが多いですね。 それで良い環境で作業できるなら安いものです。

コワーキングスペースは安定した Wifi と電源が完備されているというのとまわりの人が仕事なり勉強なりで来ているのでカフェより居心地がいいと自分では思います。(来ている目的がだいたい一緒のためだと思います)

今まで行ったのは下記。それぞれ2回づつ利用。

ここ二ヶ月は LODGE を利用していて、かなり気に入ってます。とにかく広くて綺麗なので居心地がよいです。
周りは普通に会話しているので静かな空間で作業したい人はちょっと厳しいかもしれない。
集中ゾーンのような一人席もあるので一人で行く場合はそれらを活用すると良さそうです。

いまは無料キャンペーン中で料金はかかりませんが有料化されても行きたいですね。

よかったこと

  • 定期的な勉強する時間が作れる
  • 適度な強制力。一人だと気分が乗らなかったりまぁいいかって感じで行かなかったりしてしまうのを防げる
  • すぐそばに人がいてとても気楽に質問とかできる

普段なかなか時間が取れなかったり自宅だと集中できない人などにとてもオススメです。

最近は技術チーム以外の人も参加してくれたりして業務や飲み会以外での交流が持てて個人的には良い会になっていると思います。 何より興味を持って参加してくれるのがうれしい。

さいごに

買ったまま積んでた技術書を読んだり気になってた技術を試したり自由にやってます。(あと久々にBlog書いたり)

もしかすると社外の方と一緒にやったりするといいのかもしれないですが参加者の調整とかあまりその辺を考えたくないのであくまで自分の気軽さを優先しています。 会の運用に悩むようになってしまっては何のためにやっているかわからなくなる気がするので。

そんな感じでこれからも月1回ペースを保ちつつゆるくやっていこうかと思っています。

f:id:critical_alert:20170422185420j:plain

SRE Tech Talks に行ってきました

SRE Tech Talks - connpass

7/25(月)に行われた SRE Tech Talks に行ってきました。

SRE という単語はメルカリさんの有名な記事(下記リンク参照)で初めて知りました。しかし実際にどのようなことを行っているのかあまりピンときていなかったので、具体的な話を聞きたかった。申し込み数がエライことになってましたが運良く当選しましたのでスライドや感想などを簡単にレポートにまとめます。

tech.mercari.com

各セッションタイトルはイベントのページから引用しました。

続きを読む

JAWS-UGおコンテナ支部 #5 に行ってきました

JAWS-UGおコンテナ支部 #5

少し前になりますが6/27(月)に行われたJAWS-UGおコンテナ支部 #5に行ってきました。

コンテナ支部には初参加でした。ちょうど業務でECSを検討しているところで、今回は運用系の話が多そうだったので思わず参加。

みなさんもう普通にコンテナを使っていらっしゃる。具体的な運用例なども聞けたのでかなり参考になりました。

以下メモ付き感想。ちょっとうろ覚えのところもあるかもしれません。目次はイベントのページから引用させていただきました。

続きを読む

rubyのRPMを作るのをDockerとCircleCIにやらせたら便利だった

この記事はフィードフォースエンジニア Advent Calendar 2015 - Adventar4日目です!

みなさんrubyRPMビルドってどうしてますか!

CentOSをメインで使っていると最新のrubyyumで入らないのでどこかのリポジトリからインストールするか自前でビルドする必要があるかと思います。

プロビジョニングのタイミングでrbenvやmakeで入れてもいいのですがciや新規ホストを立てた時など毎回rubyのビルドをするので時間がかかってしまうんですよね。 それが嫌でrubyはリリースされるたびにrpm化してインストールするようにしています。 ところがrpmのビルド環境って用意するのが面倒だったりビルドしたい環境ごとにvagrantを立ち上げて〜とか意外と手間がかかる。

自動化したいなーと思っていて、Dockerは特定の環境を再現するのに最適だし、CircleCIはGitHubのpushやmergeをトリガーにしてあれこれできるし、これだ!っていうことでDockerとCircleCIを使って自動でビルドできるようにしました。

今回の記事で使ったソースコードはこちらです。

critical-alert/oreno-ruby-rpm · GitHub

全体の流れ

circle.ymlを見るとなんとなくわかると思いますが、流れとしては以下のような感じ。

  1. GitHubにpushまたはマージされたタイミングでCircleCIが走る
  2. docker build でdocker imageをビルドする
  3. docker run で実際にRPMビルドを行う
  4. docker cp でコンテナの中から出来たRPMを取り出す

RPMを取り出すと書いていますがこれは正確ではなく、$CIRCLE_ARTIFACTS というパスにファイルを置くとCircleCiのArtifactsからDLできるようになっています。

ポイント

実際にRPMのビルドを行っているのはdocker runで立ち上げたコンテナの中です。 肝心のDockerfileはこのようになっています。

FROM centos:6.6
MAINTAINER hirokazu SUGIUCHI

# setup
RUN yum update -y
RUN yum install -y rpm-build tar

# ruby depends
RUN yum -y install readline-devel ncurses-devel gdbm-devel glibc-devel gcc openssl-devel libyaml-devel libffi-devel zlib-devel

# builduser
RUN useradd rpmbuilder

# build prepare
RUN mkdir -p /home/rpmbuilder/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
RUN chown rpmbuilder:rpmbuilder /home/rpmbuilder/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
WORKDIR /home/rpmbuilder/rpmbuild
ADD http://cache.ruby-lang.org/pub/ruby/2.2/ruby-2.2.3.tar.gz SOURCES/
COPY ruby22x.spec SPECS/ruby22x.spec
RUN chmod 777 /home/rpmbuilder/rpmbuild/SOURCES/*

# build
USER rpmbuilder
CMD ["rpmbuild", "-ba", "/home/rpmbuilder/rpmbuild/SPECS/ruby22x.spec"]

いくつかポイントがるのでそれぞれ解説します。

rpmをbuildするuserを作った

通常Dockerはすべてrootユーザーでコマンドが実行されますが、rpmをビルドするときはrootでのビルドは推奨されません。(今回に限ればそれほど問題は無いと思いますが) お作法に則ってrpmbuilderという一般ユーザーを作成しています。

Dockerfile内でUSERと指定すると、それ以降はその指定されたユーザーでコマンドが実行されます。 それより前でパーミッションの調整しているのはそのためです。

最後にCMDでrpmbuild

初期の段階では build.sh なるものを作ってそのなかでrubyのソースをダウンロードし、rpmbuildコマンドを実行する、としていました。 そのあとdocker run時に docker run ruby-rpm /bin/sh ./build.sh といったようにshスクリプトを実行させていました。

run時にスクリプトを叩くのはあるあるですが、そのようにしてしまうとそのスクリプトの中であれこれやってしまい何をやっているのかわかりづらくなるのと、スクリプト のメンテも必要になってしまうのでDockerfileで完結するならその方が良いと考えDockerfileのみで完結するようにしました。

Dockerfileの中にCMDがあることによってそのコンテナの役割が明確になるというメリットもあります。 そうすることで、このコンテナはrpmを作るバイナリとして扱えるようになったとも言えます。 (docker imageをrunするだけでrpmがポンとできるような...)

課題

複数のOSに対応していない。今回はCentOS6でビルドしましたが、CentOS7にも対応したいです。 これはDockerfileがDockerfileという名前ではなくてもよくなったことを利用してDockerfileを複数(Dockerfile_centos6Dockerfile_centos7)作り、docker build時に指定しそれぞれ実行すれば作れそうです。

まとめ

  • 特定の環境で実行する処理をDockerで行った
  • GitHubとCircleCIを使うことによって誰でもRPMを作れるようになった
  • Dockerfileを知るいい機会になった

これでrpmのspecファイルとrubyのソースURLをちょいっと変更してpushすればrubyrpmが出来上がります。 12/25日にはrubyの2.3.0が公開されるはずなのでその時には活躍してもらおうと思っています!

というわけで、5日目の明日はフィードフォースのMaker、kasei_sanです!

参考リンク

大変参考にさせていただきました

Chef Meetup(Tech-Circle&CreationLine共催) に行ってきました

Chef Meetup (Tech-Circle&CreationLine共催) - connpass

2015/8/31(月) TIS株式会社 で行われた Chef Meetup(Tech-Circle&CreationLine共催) に行ってきた。 いつもはハンズオン形式らしいのですが今回はセミナー形式での開催とのこと。 質問タイムがほとんどなかったので発表者に質問できるタイミングがあると良かった。(または懇親会的なもの)

1. DevOps, マイクロサービスの米国動向

スライド無し

DevOpsをとりまくdocker,chef,マイクロサービスについての最近の動向についてという内容だった。 chefの話はあんまり出てこず。 dockerは普及のスピードがすごく早いのが特徴的。やはりアプリ層に近いので直接的な効果が大きいのも要因だとか。

コンテナ技術自体は標準化されていっているので、運用周りでビジネスしようとしている。

サービスデリバリーのスピードを獲得するために開発環境で作ったものがそのままコンテナになって本番環境で動くのであれば確かにスピードは速そうとは思ったが、コンテナのスケジューリングとか運用管理が大事よなぁ。

マイクロサービスの話は自分の前提知識の不足と、具体的な活用方法が思い浮かばなくてよくわらかなかった。

2. Chef, Consulを使ったクラウドオーケストレーション

www.slideshare.net

ChefとConsulとありましたがさらにCloudConductorというツールが使われていた。
(自分はAWSのOpsWorksのようなものと理解した)

システムの構成変化をイベントとしてとらえ、 イベントを意識してchefのレシピを分割することで運用フェーズでのクラウドの機能やツールをうまく活用出来る、ということでした。

上記のスライドではアプリケーションコードのdeployまでchef recipeで行っていて、自分は別途deployツールを使用しているので新鮮に感じた。

Consulの使い所としてはchef solo単体では難しい下記を補う用途で使われていた。

  • システムの構成管理
  • 膨大で不定なノード
  • 起動するたびかわるIPアドレス
  • サーバー間連携
  • 起動しないとわからないパラメーター連携
  • サーバーをまたいだレシピの実行順序の制御
    • (DB - apacheの順でリスタートしたい、とか)

よく使う機能としては、

  • key/value storage
    • クラスタ全体で同期されているためノード障害が発生してもデータは保持される
  • consul watch
    • イベントや通知を受け取ると特定のコマンド、スクリプトを実行
  • consul event
    • 任意のイベントをクラスタ内に伝播
    • 特定ノードのみとかもできる

ただしconsul eventはノードに届く順序は保障されない、先のイベントの処理中でもつぎのイベントを処理してしまう。 順序制御したいのでそのようなツールを作成して使っている。

https://github.com/cloudconductor/metronome

集中管理ではなく自律分散することによってシステム構成が変化するクラウド環境でもうまく自動化できる。

3. Chef12 PremiumAdd-ons について

speakerdeck.com

Chef12になって追加されたPremiumAdd-onsのデモや解説。

  • Management Console
    • Hosted Chefとほぼ同等のUI
    • nodeのattributeやrun_list、cookbookなどがWebUIから閲覧できる
  • Reporting
    • chef clientの実行履歴(成功、失敗)
    • エラー内容、更新されたファイルのdiff
  • High Availability
    • 通常はDRDBで冗長化
    • これをAWSのEBSでやる、というアドオン。障害時EBSを付け替えて対応する
  • Replication
    • Chef Server apiエンドポイントを複製する機能
    • まだRCなので評価できません
  • Analytics
    • Chef Serverとは別のアプリケーション
    • chefの全般のオペレーション解析UI
    • 独自ルールを定義し外部に通知できる
    • cookbookの変更やchef-client実行などのアクションをルールとして定義できる
    • それらをNotifierで通知
    • Notifierにはmail,slack連携やwebhookもある

どんな画面なのか気になる人はcreationlineさんのところにいくつかスクリーンショットがあったのでリンクを貼っておく。

Chef Server Enterprise アドオン - CREATIONLINE, INC.

ReportingやAnalyticsあたりはデモもあってすごく便利そうと思ったが、常に自分の頭の中では(でもお高いんでしょう?)という言葉が繰り返されていた。 PremiumAdd-onsなので有料プランだとは思うが値段についてはプレゼンの中での言及はなかった。

公式をみるとこんな感じだった Chef | IT automation for speed and awesomeness | Chef

Chef Server前提だったりAnalyticsはそもそも別のアプリケーションだったりして小規模なシステムだと運用コストに見合わないような印象を受けた。 (小規模ならHosted Chefを使おうということなのかもしれない)

LT#1. Managing Docker hosts in Chef

speakerdeck.com

Chefでdockerをプロビジョニングできるぜ!的な内容でした。

https://supermarket.chef.io/cookbooks/docker

こんなcookbookがあるのを初めて知りましたが、見てみるとなかなかすごいことをしていると思う。

これでコンテナを配置できるようになったけど運用とスケジューリングはどうするの?...っていうオチでした。

まとめ

  • Chefの使い方として、ライフサイクルごとに分割してrecipeを書くのは新しい発見だった
    • 実際のrecipeが見てみたい
  • Chefを単なる自動化のパーツとしてつかう、という感覚はAWSのOpsWorksのようだと思った
  • 監視(メトリクス)とかは主題ではなかったためか触れられていなかったが、みんなどうやってるのか気になった
    • Consulである程度できたりするのかな?
  • Consulの具体的な運用例が聞けてどうやって使っているのかイメージがついた