#builderscon に参加してきました。

builderscon.io

に参加してきました。

企業スポンサーのチケットで参加してきた形になるので、細かいレポート的なことは会社のブログで書くことになるので、自分のブログでは個人的な感想とかを書き残そうかと思います。

個人のブログとは言え、所属する会社との関係も多少あるので書いておきます

本記事での発言は個人の責任で、所属する組織を代表するものではありません。

参加したセッション

一応buildescon2017が開催されている時間帯は全部いました。

• 前夜祭
  • オンプレミスデータセンター撤退！
  • データストア撤退の歴史
  • PaaS完全撤退の歴史
  • ブロックストレージとの戦い、そして撤退
• 初日
  • phpで支える大規模アーキテクチャ
  • ランチセッション A 株式会社VOYAGE GROUP
  • マイクロチームでの高速な新規開発を支える開発・分析基盤
  • Haskellを使おう
  • RDBアンチパターンリファクタリング
  • 各LT
• 2日目
  • ココまでできるmruby
  • 小さく始めるて育てるコンパイラ
  • ランチセッション【PR】エンジニアがkintoneを使うべき3つの理由 サイボウズ株式会社
  • AWS CodeBuild を使ってものすごい並列数で CI を実行しよう
  • OSS貢献超入門
  • The Evolution of PHP at Slack HQ

難しいなと思ったこと

楽しくない話しは先に書いておきます。

リアルのイベントを開催すると集客人数とかセッションごとの人の分散とかを想定しづらいのだろうなぁと思いました。前夜祭やランチセッション等で利用していた会場は若干席不足感が否めなかったです。ただ会場サイズには限りがあると思いますし、参加者全員を収容できる場所なんてなかなかないはずなので難しいなぁと思った次第です。もっとスポンサーとか集まると解消するのでしょうかね？

お昼ごはん

ランチセッションで提供されたお弁当美味しかったです。

羨ましいなあと思ったこと

しゃもじ。

会社で振り回したかったなぁという気持ちです。

真面目な感想

まずSNSでの拡散禁止になっていた前夜祭が めちゃくちゃ おもしろかった！！！　拡散禁止になるレベルの話なので面白くないわけが無いのですが、やっぱり聞いたら面白かったです。各社 ~お腹が痛くなるような~ 苦難を乗り越えて今があるんだなぁって感じです。この様な話を聴くと、SNS拡散禁止のリアルなイベントに参加する価値がとても高いなぁと感じました。

2014,2015のyapcに参加し、1年飛んでbuildersconに参加したのですが、カルチャーが受け継がれているなぁと思いました。プログラミングを始めたのが大体2013年で、始めた当時からyapc ~ buildersconがあった身分なのですが、今年も各セッションで頑張る気持ちが高まる話が聞けて色々頑張るぞ！！！って気持ちになってます。

加えて、個人的なブログなので好き勝手書くと、PHPでwebアプリケーションを書いている人がいっぱいいて羨ましい気持ちになりました。現在のお仕事も楽しいので不満等は全く無いのですが、PHPを書くことは無く、むしろPHPを別のモノに置き換える仕事がメインで、PHPでプログラミングを覚えてきた身としては寂しさがあるのです。(PHPの話しを書いていてふと思ったのですが今年はPerlがメインな話がもしかしたら無かった?)

今後に向けて

2014年(過去のセッションの動画や資料をあさっているのでそれをカウントするともうチョット昔)から、builderscon界隈のコニュニティからは知見を頂きっぱなしになっているので、来年はLTとか本編のプロポーザルを書こうと思います。自分がやって来たことに対する知見等をコミュニティに還元できればなぁと思ってます。

しゃもじは欲しかったので、来年もそのようなサプライズがあることを期待しつつ個人スポンサーするのを忘れないようにしたい気持ちもあります。

また、所属している会社がスポンサーをさせてもらった割に、お金しかだせていないのはなんだか申し訳ない気持ちになったので来年は個人的に、スタッフとして協力も出来ればよいなぁと考えています。

要はbuilderscon最高だと思っているので、何かしらでもっと協力をさせてもらいたいなぁと思っています。

最後に

どうせブログのアカウント名をググると自分の各種アカウントしか出てこないはずなので。

もうclosingも間近ですが、今回の幕間CMを出していた会社の名前、できれば「富士通」ではなく「富士通クラウドテクノロジーズ」で認識していればありがたいです。 #builderscon

— やま(´･_･`)ぐち (@yaaamaaaguuu) 2017年8月5日

現在 #builderscon で提供させていただいている、弊社エンジニア紹介動画を、youtubeにアップロードしました。皆さんに名前を覚えていただけるとうれしいです！ https://t.co/51puCduXgX

— 富士通クラウドテクノロジーズ株式会社 (@Fujitsu_FJCT) 2017年8月4日

ありがとうございました。

Docker Compose の fluentd ロギングドライバの設定で環境変数を使いたい時に見るページ

ロギングドライバの設定で環境変数を使いたい

個人的にはfluentd driverを使う時のタグの文字列を環境変数を利用して組み立てたかった

ドキュメントと記事

docs.docker.com

https://docs.docker.com/engine/admin/logging/log_tags/docs.docker.com

https://docs.docker.com/engine/admin/logging/fluentd/docs.docker.com

要は上記をきちんと読めば分かること(だけど自分は詰まった)

使うまでの3ステップ

1. envファイルを読み込む
2. --log-optに env=HOGE で利用したい環境変数を渡す
3. --log-optに tag=(.ExtraAttributes nil).HOGE の様な形で引き渡す

compose-fileに落とし込むと以下の様な感じ

env_file: .env
logging:
    driver: fluentd
    options:
        env=HOGE,HUGA
        tag="(.ExtraAttributes nil).HOGE-(.ExtraAttributes nil).HUGA"

gitリポジトリをCIするのに Jenkins Pipeline もしくは Jenkinsfileが辛いなぁと思った話

背景

• いくつかでCIをやってみた
  • golangのプロジェクトをgitlab CI で
  • swiftのiosアプリをbitrise.ioで
  • CircleCI で Railsのアプリ
• システムではなくソースコードをCIしたい
• 本家?のJenkinsはやってみてなかった
  • GUIでポチポチ形式が割りと嫌
• そう言えばJenkinsfileがあるらしい
  • 宣言的にCIの内容を書ける
  • チャレンジしてみよう

Jenkinsfileとは

jenkins.io

• GroovyでCIのjobのステップを宣言するやつ
• とは言えJenkins上でプログラムだと何でも動かせるので制約がいくつか付いている
  • 制限突破をするための設定があるので余り気にならない可能性はある
• Jobの実行時にYes/Noをinputできるようにしている

辛さ

ちょっと触って詰まって調べた程度なので間違いはあるかもしれません

• Jenkinsが想定している前提が広いこと
  • 他のCIならばgitとリポジトリに対するイベントが前提となっていると思う
• Jenkinsfileが閉じていること
  • webhookでキックすることはできる　
    • Jenkinsfileだけではwebhookのpayloadが拾えない
    • webhookのpayloadを拾うにはJenkinsfile以外の仕組みが必要
      • 例えばgithub用のjobを作成
      • github用のjobがjenkinfileで宣言したjobをピタゴラスイッチする
  • 環境変数がJenkinsのGUIから設定できない
    • チャットへの通知用にtokenとかは以下を実現したい
      • Jenkinsfile内では環境変数への参照
      • JenkinsのGUIで環境変数を設定
    • 厳密にいうと環境変数へのアクセスはできるが、変数はサーバーにログインして設定する必要があるはず
• いろいろやろうとするとJenkinsfile外との連携を考える必要が出てくる
  • Jenkinsfileの良さを殺している

雑記

冒頭で述べたように個人的にはGUIでしか設定できないのは嫌なのだが、「Jobの内部はJenkinsfile, 外部とのやり取りはGUIで設定」という現状は結局GUIでの設定に依存していてはっきり言って不便。

ソースコードをCIするだけならば、GitlabCIもしくはSaaSのCIが圧倒的に便利。前提として考えているワークフローがJenkinsとそれ以外では違いすぎる。

JenkinsはOSSだから文句を垂らすならコントリビュートする努力をしたほうが良いのだろうけど、便利な代替があるので、不便なJenkinsfileを改善する努力もするつもりが無い。

自分の観測範囲だとJenkinsはスクリプトにGUIを提供するためのラッパーツールっぽくて、CIツールとしてはあまり使われていない。多分だけど自分の観測範囲外でも同じような使われかたをしているのでは？と思えるJenkinsfileの機能だと思った(Job実行時のyes/noとか)。ただ僕にとってはスクリプトをラップしたGUIとか何も有り難みが無い。結局設定されているスクリプトを見るし、直接たたいてオプションとか調べるし。調べた後はJenkinsが無駄なGUI層として残ることになる。

が、スクリプトをラップしたGUIは、スクリプトを読めない人でも安心して実行することができる利点？があるので、Jenkinsはそっちの方で生き残るのかな？

ココまで書いて、「自分が主体的に使うシーンを想定すると割りと辛い気持ちになり、他人のためにスクリプトのラッパーを用意してあげるだけならばJenkinsで良いのかも。」と思った。

pythonでslackのmessage buttons

TL;DL

api.slack.com

こんなのがあったから, 試すがてらPythonで再実装してみた.

github.com

SSLとかはLet’s Encryptとかでよしなにやってほしい。

1点注意としては、現在Firefoxからslack appの作成をしようとするとどのチームでslackアプリを作るか？という選択肢が選べない。Chromeとかだと上手くいく。

背景とかモチベーション

• 現在の会社で所属しているチームには定型的なオペレーションがある
• 手順は確立されているがもっと効率化, 自動化したい
  • が、最終的な対応の実施可否は人間が判断したい
    • 実行しますか？の問いにyes, noで回答させて欲しい

という背景があった上で、

• 通知を受け取った人間がCLIで1コマンド叩く形の自動化は嫌
• Jenkinsとかも違うなぁと思った
• 通知と対処をシームレスに実行できれば嬉しい

そんなこんなでインタラクティブにシステムとやりとりできるslack message buttonsがいい感じに自動化のUIになってくれるのではないか？と思って試した。

個人的には以下の流れができたら最高だなと思っていた。

(一連の流れは全てslackのメッセージとしてlog化)
なにかしらの出来事 -> slackへの通知 (yes, noのbuttonの送信) -> yesを押したらスクリプト等の実行
                                                       -> noなら何もしないで終了

成果物

• TL;DLのgithub
• pythonにポートをした理由は所属するチーム的な理由
  • 主な利用言語にpythonがあり, nodeは使ってないから

所感

• slack の message buttonはSSL必須
  • 試すだけなら, 単純に手間もしくは制約が多くなるだけ
    • Herokuで制約をとるか
    • Let’s Encryptで手間をかけるか
• とはいえ、たんなるコミュニケーションツールとして、message button を用意するのは面倒だなぁと思った.
  • message button以外の(SSLが任意の)apiでなんとか賄える気がする
• slackのUIでオペレーションをするのは厳しい
  • message button をレスポンスするアプリケーションのセキュリティ的な問題

問題点

どこまでslackを信用するかの問題。

message button appの作りとしては、以下の2つの点でアプリケーションのセキュリティを担保しようと考えている

1. httpsでの通信
2. slackしか知らない, slack app用の Verification Token を使う
   • アプリケーション側で Verification Token をチェックする

コレだけだと、slackから送信されてくるリクエストによく似たリクエストが送られてきたら対処のしようが無い.(特に、Verification Tokenが漏れたとかのケースを考えると…)

個人的には上記に加え, 以下の対策が取れれば良いのだけどなぁと思った。

• slackのリクエストもとIPもしくはIP帯が公開されていること
  • slack appを動かすサーバーに対して、送信元IPでFWをかけられるようにする

送信元IPで制限がかけられればVerificationTokenが漏れましたとかなっても大丈夫なはず。

しかし、結局これでも、 万が一slackのサーバーが乗っ取られて「slackのサーバーからいろいろrequestを投げてみました(´･◡･`) 」 みたいな自体になると対処のしようが無い。

message button でアンケートが取りたいとかの、「ちょっとしたコミュニケーションの延長線上の事をやりたい」程度なら万が一message button用のアプリに不正なリクエストがあっても問題ないはずだが、「インタラクティブに実行したいオペレーション」を実行するアプリケーションに不正なリクエストがあった時のことを考えると結構厳しいはず.

なので問題点としては、以下となると思っている.

どこまでslackを信用するか

ただし、slackの問題というより、コミュニケーションツールをコミュニケーションから大幅に外れた用途で使おうと検討した自分が原因なので、slackには全く落ち度が無いと思っている.

まとめ

• slackでサービスのオペレーションはリスクがあるのを認識できた
  • 実際に手を動かしてみたから, そこら辺に気づけたと思っている
• 個人的考えてた用途としては厳しい

DIとリポジトリパターンは何が嬉しかったのか？がよくわからなくなった。

まだ色々考えている途中

qiita.com

上記のページからリポジトリパターンの良さを抜粋すると以下の様な事が挙げられている

テストがしやすくなる

DBエンジンの変更に対応しやすくなる

データ操作のロジックが1箇所にまとまり、管理しやすくなる

そうだよねと思いつつ、Laravel系でリポジトリパターンに言及している別のページも見て回った.　

結果、気がついた事が一つある。基本的に返り値を言及していない。

当たり前過ぎて言及されていない前提の話しなのかもしれないが。

例えば、SQLite様に書いたリポジトリがsqliteのコネクションを返し、Redis様にかいたリポジトリがredisのコネクションを返したら、リポジトリインターフェースを要求しているコードはそのDBエンジンに寄ってコードを書き換える必要が出てくる. それでは本来のリポジトリパターンの意味が薄いと思った。

DBエンジンをすげ替えられるようにpythonで書いてみた

とりあえず自分で書いてみたら答えが出るかもと思って、RedisとSQLiteと単なるモックコードを切り替えられるようにした。

以下のページの183行目で生成するクラスを変更したら使われるDBが変わるようになっている

github.com

実行結果は基本的に同じようになっているはず (だが途中でめんどくなってredisあたりのconfiguとか端折ってる)

書いてみた結論として

• たしかにテストはし易いはず
  • DI自体は例えばコントローラーのテストの際にmodelのモックが気軽に差し込めるのは良いと思う
• リポジトリパターンでなくても良いのでは?という気持ち
  • リポジトリパターン自体はインターフェースを統一させるための存在という認識
    • RDBMS -> RDBMS (例えば, MySQLからPostgreSQL) だけを考えるならばORMが似た事をカバーしてくれそう
    • NoSQLも同じ
      • KVSならKVS向けのwrapperがあれば良い
      • ドキュメント指向ならドキュメント指向のwrapperがあれば良い
  • NoSQLとRDBMSとではリポジトリインターフェースの互換性を維持するのがそもそも大変
    • どれくらい自前のコードで吸収するか？
    • 現実問題として、RDBMSなコードをRedisやMongoにすげ替える前に考える事がもっとありそう
• リポジトリに持たせる実装がもう少し厚い場合考えが変わるかもしれない
  • 現状リポジトリにはどの位の責務で実装を持たせたら良いのかがわかってない
  • が、DBを操作する系のメソッドが長くなるとその実装自体がテストできなくなるので…
• リポジトリパターンってなんだ？
  • アダプタ

ということで、本日のブログ 「DIとリポジトリパターンは何が嬉しかったのか？がよくわからなくなった。」 になる。

追加の参考

blog.comnect.jp.net

上記のリンクを見るに、自分の実装ではリポジトリパターンになっていなかった。

リポジトリ内で実装をすげ替えるより、リポジトリに対して更にクライテリアをDIするほうが責務としてはきれいに別れて良さそう.

だけど根本的な疑問として、そこまでしてRDBMSとNoSQLとの互換性を保ちたいか？と聞かれると微妙なのは変わらず.

vSphereでterraformする時のポイント

VMを立てるだけならばvagrantでも良い気がするし、色々設定するならAnsibleで事足りている.

が、仮想基盤に対してリソースを用意するための適切なツールを利用する意味で、terraformを利用してみる

入門自体は以下

dev.classmethod.jp

公式ドキュメントのvSpherプロバイダページ

www.terraform.io

ポイント

1. providerの箇所には allow_unverified_ssl = true 記述すること
   • vSpher providerのドキュメントをパクっていくと分かる
   • vCenterあるあるの証明書の話し
2. resource "vsphere_virtual_machine" には skip_customization = true を記述すること
   • terraformを利用すると、作成したいVMのOS上の設定までいじれるらしい
   • ただ、vSphere で利用すると vsphere_virtual_machine.es: Customization of the guest operating system というエラーが出る
   • redhat系とdebian系がダメって言うなら普通はスキップする設定にしておいたほうが無難そう
3. いつまでたっても apply が終了しない
   • 何やら、 network_interface の項目に, labelしか記述しないと正常に終了しないらしい？
     • customizationがいじれないのに、これ以上何を記述したら良いのか (´･_･`)
   • 問題のissueは以下 github.com
   • とりあえずぶち切っても大丈夫そう

所感

• ドキュメントを見る感じ、出来ること
  • フォルダを作る
  • VMを作成
    • VMを作るための素(新しくisoからなのか、templateからなのか)
    • ネットワークの指定
• Ansibleとの比較
  • playbookとroleとAPIでゴリゴリ設定できるAnsibleのほうが、自由度が高く出来ることも多い
    • ポートグループを作るとか
    • NSXと連携してDFWを当てるとか
  • 正直terraformのvsphereプロバイダだと...
  • ただ、オープンソースなのでコードを書いて貢献しろと言われると確かに... と言う話し
• HCL
  • www.terraform.io
  • 使い込んでないけどYAMLより良いと思う
    • なんとなくレベルの話し

haskell で gnuplotを利用する + 利用したときの個人的な詰まりどころ

gnuplot: 2D and 3D plots using gnuplot を利用してみた

だいたい以下のページの感じで出来る.

d.hatena.ne.jp

ただし今回はもうチョット踏み込んだことをやってみる。

用意

gnuplot等の用意は上記のページを見て欲しい。

haskellのライブラリとしてのgnuplotはstackで準備できるので、プロジェクト.cabal にgnuplotを追記したら良い

library
  hs-source-dirs:      src
  exposed-modules:     Lib
  build-depends:       base >= 4.7 && < 5
                     , gnuplot
  default-language:    Haskell2010

で、stack build したら怒られるはずなので、 stack solver とか stack build --modify-stack-yml とかを叩いてやれば良い

棒グラフのサンプル

module Lib
    ( someFunc
    ) where

import Graphics.Gnuplot.Simple

someFunc :: IO ()
someFunc = do
  plotPathStyle [(Title "Frequency"), (XTicks (Just ["('hoge' 0, 'huga' 1, 'piyo' 2)"]))] (defaultStyle{plotType = Boxes }) [(0::Int,0), (1,1), (2,2)]

stack ghci
> someFunc

以上で実行可能

スタイルはデフォルトのまま

gnuplotで出来ることとしてはもうちょいいい感じに出来るはずだけど、 もう少しきれいにやるなら Graphics.Gnuplot.Advances を使う必要がある。

詰まりどころ1

まず注意しなければならないのが、 おそらく GHCiからでないと利用できない様子. ドキュメントにGHCiかHugsから使えるよって書いてある.

少なくとも自分の環境ではコンパイルが上手く行った後のバイナリを動作させても、gnuplotが起動することは無かった。

ただしstackの環境であれば、 stack ghci を実行すると src/Lib.hs のモジュールを読み込む設定が最初から書かれているので、 コードを書いてghciから実行させる形で妥協したら良いと思う。

詰まりどころ2

ghciから実行させるのは良いが、gnuplot自体はおそらく非同期でコードが実行される。 非同期で実行されるから、間違ったコードで死んでるのか、処理中なのかわかりづらい。

具体的には遅延評価される重めのlistをgnuplotに突っ込もうとすると、動いているのかどうかよくわからない問題が発生する. (自分は1~2日気づかなかった)

そんなときはtopコマンドを見れば良い。

Processes: 332 total, 3 running, 329 sleeping, 1548 threads                                                                                                                                                                          00:29:13
Load Avg: 1.97, 2.12, 2.08  CPU usage: 13.71% user, 1.45% sys, 84.83% idle  SharedLibs: 174M resident, 43M data, 48M linkedit. MemRegions: 67643 total, 5202M resident, 175M private, 3489M shared.
PhysMem: 16G used (2002M wired), 22M unused. VM: 1930G vsize, 627M framework vsize, 0(0) swapins, 0(0) swapouts. Networks: packets: 256919/208M in, 222563/26M out. Disks: 870239/13G read, 162387/6235M written.

PID    COMMAND      %CPU      TIME     #TH    #WQ  #PORT MEM    PURG   CMPRS  PGRP  PPID  STATE    BOOSTS          %CPU_ME %CPU_OTHRS UID  FAULTS    COW    MSGSENT   MSGRECV   SYSBSD    SYSMACH   CSW       PAGEINS IDLEW   POWER
12713  ghc          99.8      00:17.90 5/1    0    14    1778M  0B     0B     12700 12700 running  *0[1]           0.00000 0.00000    501  525572    1375   70        34        150746+   3997      15304+    59      316     99.8

ghcがCPU利用率100%で張り付いているって言うことは、裏で頑張って処理しているんだな。ってことが分かる