その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

#builderscon 2018 tokyoに参加しました & 話してきました

builderscon.io

builderscon 2018 tokyoで「Java Cardの世界」というタイトルで話してきました．発表資料は以下のとおりです．

喋りたいトピックはJava Card以外にも様々あったのですが，「知らなかった、を聞く」というカンファレンスのテーマを鑑みた結果，あまり一般には知られていなさそうな *1，しかし身の回りを確かに支えている技術についてお伝えしたいと思い至り今回のような発表をした次第です．この発表で少しでも生活が豊かになってもらえれば望外の喜びであります．

さてこの発表はありがたくもベストスピーカー賞第1位を頂戴しまして，感激の極みであります．本当に嬉しい！！！　もちろんこの発表は僕個人の力のみで成し遂げたものではなく，所属しているソラコムの同僚の多大なる協力があって達成したものです．特にJava Cardの偉大な知識を授けてくれたolivier，yaman，kennyには本当に感謝したいと思います．ありがとうございます！！！

副賞としてなんかすげえ量のガジェットがやってくる予定なので向こう1年くらい遊べるんじゃないでしょうか．中でも「マウス自作セット」という文字が僕の心を掴んで離しません！　作ったものについては色々このブログとかに書いていきたいですね．


[追記]

ついにガジェットが来ました！！！！　すごい！！！！！！
スポンサーのGMOペパボの皆様をはじめまして関係者の皆様本当にありがとうございます！！！！！

最高！！！！！！！！！！！！！！

f:id:moznion:20180910112011j:plain

これは同僚のtomoに撮影してもらった目録の写真です！！！

[追記ここまで]


さて，参加したセッションの中でも印象的だった発表について記したいと思います．

産業でガチ利用されるRaspberry Piの話 - @kazuphさん

builderscon.io

本当に身の回りで見かけるようになった，ともすればここ最近では一番身近なコンピュータである可能性があるRaspberry Piを産業利用される話でした．発表中，「BluetoothのIoTゲートウェイなー！！！　本当に難しいんだよな！！！！！」という共感が生まれ，非常に面白い発表でした．
ansibleのようなweb app的な文脈で多く使われてきた技術がIoT分野でも利用されている事例を聞いたときは，いままで隔たりのあった技術間の融合というか，汽水域のようなものができてきているように感じ，非常に興味深かったです．これは素晴らしいことだと思います．

カクヨムでの縦組み表示の実装と、縦書きWebの将来に向けて - @nanto_viさん

builderscon.io

縦書きWebという特別な環境における開発の話が聞けて貴重でした．今まで縦書きWebの開発をやったことがなかったので……
「やっぱりブラウザのバグとか結構踏むんだな〜大変そう，うわっすげえ壊れ方してる！」みたいな感じで拝見していたのですが，しかしそういった問題に対して適切にworkaroundを入れていく，そして適切にブラウザ本体に対してバグレポートを送る，といったことを淡々とこなされており，そうした姿勢が非常に尊く大変良かったです．

実録！ある担当者がみた「謎ガジェット」開発１年史 - @uzullaさん

builderscon.io

これめっちゃ良かった，電子名札ガジェットのプロトタイプ作成から量産するという無茶ストーリーを発表されており，圧巻です．ガジェットを200個作るというのはそれはそれはすごいことなのです．明らかに個人でやることではない！！！！！
これは動画が公開されたら絶対見たほうが良いと思います．最高．

Jepsen 10 - @aphyrさん

builderscon.io

ウオー，俺はこれが見たかったんだよ！！！！！！！！！！　分散システム・DBを調べたり使ったりする時に，ほぼ必ずと言っても良いほど参照することになるJepsen testの著者の方の発表です．このブログは真に最高なので，読んだことがない方はぜひ読むと良いと思います． https://aphyr.com/
本当に最高で，分散システムが勢い良くどんどん壊れていく．ネットワークの物理的分断，タイムアウト，魔のタイミングでのノードの立ち上げ，入力する時刻を揺らすなどなど様々な破壊シナリオが紹介されていてめちゃめちゃに面白い．発表中の「分散ロックできるっていうのはだいたい嘘です」という言葉に説得力があり，大変に良かった．
発表後にRedis Sentinel/Clusterの質問や，InfluxDBの分散エディションについての話をできたのも良かった……

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ - @aerealさん

builderscon.io

いつもお世話になっております (このブログとか)．数万規模のSSL/TLS証明書を管理しなくてはならないというなかなかタフかつ珍しい要件の話を聞けて非常に楽しかったです．各コンポーネントの責務を非常にミニマルかつ明確にされており (つまり責務の境界が明確化されている)，それぞれが正しく協調動作している点に非常に美しさと正しさを感じました．また「AWS Step Functionsよさそう，使ってみたい」とも思いました．

その他雑感

今年はspeakers dinnerという新たな取り組みが行われており，これも非常に面白かったです．懇親会とはまた違った感じで，ゆるーく知らない人 (しかしおそらく距離は近いであろう人) と話したり意見交換したりできる場というのはなかなか新鮮で良かったです．ただ本会の前に開催されるため，そこでうっかり話しすぎてしまい，逆に懇親会で無口になるという珍事が発生しました．ハハハ．

ところで今回はafter partyに参加できなかった，できなかったのです．なぜか？　それは僕がチケットを買い忘れたからなんですけど……これにはへこみました……まいった……
だもんで「とりあえずこれ買っておけば全部OKチケットx万円！！！！！！！！」みたいなチケットが出ると嬉しいですね！

今年は非常に印象的なカンファレンスになりました，スタッフをはじめ皆さん本当にありがとうございました．
また来年お会いしましょう，お元気で！！

*1:事実僕もやるまで知らなかった

Linux Kernel 4.12以前であればhostマシンのsysctlの値がDocker container環境に引き継がれるかどうか検証した

Docker - IPVS connection timeout issue

これを読んでいたところ

From Linux kernel 4.13 onwards, sysctl default values can be modified per container basis. Container will not inherit changes from the host sysctl modified values.

とあったので，逆にhostマシンのLinux Kernelが4.12以前であればhostマシンのsysctlの値がDocker containerに引き継がれるのか？　と思い検証してみました．

TL;DR

  • (手元の環境で試してみた限り) 引き継がれなかった
  • 変なことを考えず，おとなしくdocker run の --sysctl オプションを使おう！！
    • Amazon ECSは早くsysctlのサポートしてくれ！！！！！

hostマシン環境

$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
$ docker -v
Docker version 18.06.1-ce, build e68fc7a

コンテナ環境

https://hub.docker.com/_/ubuntu/

ubuntu:bionicを使用．

Kernel 4.13.16でやってみる

$ uname -a
Linux moznion 4.13.16-041316-generic #201711240901 SMP Fri Nov 24 09:02:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ sysctl -n net.ipv4.tcp_keepalive_time # <= host
7200
$ sudo docker run ubuntu:bionic sysctl -n net.ipv4.tcp_keepalive_time # <= container
7200
$ sudo sysctl -w 'net.ipv4.tcp_keepalive_time=600' # <= ここでhostのtcp_keepalive_timeをいじってみる
net.ipv4.tcp_keepalive_time = 600
$ sysctl -n net.ipv4.tcp_keepalive_time # <= host
600
$ sudo docker run ubuntu:bionic sysctl -n net.ipv4.tcp_keepalive_time # <= container
7200

引き継がれてないですね．

Kernel 4.12.14でやってみる

$ uname -a
Linux moznion 4.12.14-041214-generic #201709200843 SMP Wed Sep 20 12:46:23 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ sysctl -n net.ipv4.tcp_keepalive_time # <= host
7200
$ sudo docker run ubuntu:bionic sysctl -n net.ipv4.tcp_keepalive_time # <= container
7200
$ sudo sysctl -w 'net.ipv4.tcp_keepalive_time=600' # <= ここでhostのtcp_keepalive_timeをいじってみる
net.ipv4.tcp_keepalive_time = 600
$ sysctl -n net.ipv4.tcp_keepalive_time # <= host
600
$ sudo docker run ubuntu:bionic sysctl -n net.ipv4.tcp_keepalive_time # <= container
7200

あれ，引き継がれないですね．

もちろんsysctlオプションを食わせながらdocker runすれば反映される

$ sudo docker run --sysctl 'net.ipv4.tcp_keepalive_time=600' ubuntu:bionic sysctl -n net.ipv4.tcp_keepalive_time # <= container
600

所感

Kernel 4.12.0とKernel 4.10.17でも試してみましたがhostマシン側のsysctlがcontainerに引き継がれているようには見えませんでした．なんか間違ってるんですかね？　それとも引き継がれないのが普通？
とはいえ新しいKernel上ではhostのsysctlは引き継がれないし，やはりdocker runの--sysctlオプションで渡すのが良いでしょう．しかしAmazon ECSではsysctlオプションが対応されておらず*1……嗚呼

*1:https://github.com/aws/amazon-ecs-agent/issues/789

LinuxでもMagic Trackpad 2使いたいじゃないですか……って時

なぜかLinux Desktopで生活したくなったのでLinux Desktopで生活しているんですが (Ubuntu 18.04.1)，やはり入力インターフェースは良い方が良いわけですよ．良いですか．というわけでMagic Trackpad 2を使いたいですよね．
しかし素の状態ではマシンとBluetoothで繋げないし，USBで繋いだとしてもGenericなマウスとして認識されてしまうのでめちゃめちゃ使い勝手が悪い *1．なんとかなってほしい……

というわけでこれです．

github.com

これはもともとMagic Mouse向けのドライバにMagic Trackpad 2のサポートを足したものらしく，このドライバをインストールするとちゃんとしたTouchpad HIDとして認識してくれるようになる上にBluetoothでの接続も可能となります．
インストールするにあたってはKernel 4.18以降という割と新しめのKernelが求められるので適宜バージョンアップする必要があるでしょう (Ubuntu 18.04.1はデフォルトのKernelが4.15.0だったのでエイヤとKernelをupgradeする必要があった)．
ドライバのインストールに関してはREADME.mdにある通りDKMSを使う方法が一番手っ取り早いのでそれでやると良いです．


とまあそんな具合にMagic Trackpad 2がLinux Desktopで使えるようになってめでたいわけですが，しかしmacOSと完全に同じ使い味というわけにはゆかず (やはり選択する際の細かい動きやスクロール感が違う)，やはり入力デバイスの良し悪しはOS側の制御と密接に関わっているのだなあと実感しました．とはいえ他の下手な入力デバイスで操作するよりは良いと思います！

*1:具体的に言うとtap to clickが効かなかったり，2本指スクロールが効かなかったりする．後者は致命的

ECS Agent 1.19.0だとDocker containerのメタ情報を取れない場合がある

表題のとおりですが，ECS Agent 1.19.0だとDocker containerのメタ情報を取れず (取れない場合がある)，いろいろ困るという現象が発生します．

github.com

このissueにあるようにDocker Container IDをうまく取れないことが問題のようです．
おかげでElastic BeanstalkのDocker環境で動かしているアプリケーションが吐くログをうまく取れなくなってしまって大層困った……

なおこの問題はECS Agent 1.19.1で修正されているので，お使いの方はアップグレードしたほうが良いと思います．以上です．

Kyoto.なんか #4で最近運用しているJenkinsの情報について発表してきました

jenkins

[2020-09-07追記]
この構成，もうウチではやってません！！！！
moznion.hatenadiary.com
[追記ここまで]


kyoto-nanka.connpass.com

表題の通り，最近AWS上で運用しているスケールする & 運用が省エネなJenkinsについて発表してきました．

簡単にまとめると

  • JenkinsのslaveをAWS CodeBuildに委譲することで実質無限のスケールアウトとメンテコスト削減を実現
  • JenkinsのストレージをAmazon EFSにすることでロバスト性と自動ボリューム拡張を実現
  • ElasticBeanstalk with Dockerを使って運用することで運用コストの省力化

という内容です．


会場やインターネットで質問されたことについては以下のとおりです:

値段的には従来のサービスを使うよりも下がったかどうか？

  • 試算的には下がっている
  • やはりCIが寝ている時間が多いと，CodeBuildの時間貸しスタイルがうまくはまって効くという感じ
  • とはいえ今後継続的にコストの実測を行って経過観察をする必要がある

強い環境でビルドしたいという話だったが，CodeBuildはインスタンスタイプを選べる？

  • 選べる
  • 3 GB メモリ、2vCPU
  • 7 GB メモリ、4vCPU
  • 15 GB メモリ、8vCPU
  • (会場ではうろ覚えで間違えたスペックを口走ったかもしれません，すみません)

CodeBuild上でのビルド環境はDockerということだったが，このDockerイメージはどこかにアップロードしておく？　あとキャッシュみたいなのは効く？

  • CodeBuild上ではサポートされている言語であれば素のDockerイメージが提供されており，その上でビルドを行うことができる
  • 独自のビルド環境が欲しいのであれば自分でDockerイメージを構築してECRにアップロードして利用すれば良い
  • キャッシュについては任意のファイル (or ディレクトリ) をS3に突っ込んでキャッシュすることができるので便利
    • 例えば解決済みの node_modules のようなものをキャッシュしておくことが可能

プラグイン管理が魔界にならないか

Jenkins.instance.pluginManager.plugins.each{
  plugin ->
  println ("${plugin.getShortName()}")
}

Jenkinsは色々とランタイムを入れられて環境が汚くなる印象があるがどのように対処しているか

  • 実際のビルド環境は基本的にCodeBuild上なのでJenkinsがいたずらに汚くなることはなさそう
  • なんらかのランタイムをインストールする必要がある場合はDockerfileで構成管理するぞ，という気持ち
    • (まだその状況に至っていない)


という感じでした．参考になれば幸いです．

Kyoto.なんかはいろいろおもしろい話が聞けて楽しいですね．来年の開催も楽しみにしています！！

あるgit commitがどのpull requestでmergeされているかをAPIでシュッと取ってくる方法

github

というのを id:side_tana さんが探っていたので，このAPIをGETで叩くとできるよというやつです．

https://api.github.com/search/issues?q=repo:${owner}/${repo-name} pr:merged ${commit-hash}

あ，GitHubの話です．良かったですね．

JenkinsでGitHub Pull Request Builder pluginを使いつつ任意のブランチにpushしたコミットもビルドする

jenkins

JenkinsでGitHub Pull Request Builder (ghprb) を使っている時に，pull request以外のcommit (例えばmasterへのマージコミットや任意のブランチへの直push) もbuildしたいんすよね〜みたいなことをid:hdkshjmさんに相談したところ良い感じの方法を教えてもらったのでメモとして記すものです．ありがとうございます！

前提として

  • ghprbの設定は済んでいる
  • Git pluginがインストールされている
  • GitHub pluginがインストールされている
  • GitHubのリポジトリのWebhook設定で $JENKINS_BASE_URL/github-webhook/ に向けてpushイベントを設定している

ものとします．

そんでもって以下のようにすると良い:

  • プロジェクト設定のGit SCMのリポジトリ設定でRefspecに +refs/pull/*:refs/remotes/origin/pr/* +refs/heads/*:refs/remotes/origin/* を指定する (高度な設定から設定できる)
    • ghprbではpull requestだけがターゲットなので +refs/pull/*:refs/remotes/origin/pr/* を指定しておけば良い
    • それに加えて +refs/heads/*:refs/remotes/origin/* を指定することによって任意のブランチへのpushも引っ張ってこれるようにしておく
  • 「ビルドするブランチ」にビルドしたいブランチの名前 (e.g. master, develop and etc) を指定する
    • ghprb向けには ${sha1} とか設定されているはずなので *1，そこに追加するという感じ
  • トリガ設定で GitHub hook trigger for GITScm polling にチェックを入れる

これでOK！　例えば「ビルドするブランチ」に master を設定しておけばmasterへのマージコミットや直push (まあ野蛮！) についてもbuildを回すことができて便利です．
pull-requestについてはghprb pluginがbuildをキックし，一方で指定したブランチへのpushについてはGitHub pluginがbuildをキックするという感じです．基本的に互いが重複してbuildをキックすることは無いでしょう (「ビルドするブランチ」に指定したブランチを他のブランチに向けるpull-requestを作ったら話は別ですが)．


ところでJenkins 2.0以降を使っている場合Jenkinsfile及びパイプラインが使えますから，pipeline-githubあたりを駆使するとgroovyでプログラマブルに色々操作できるため，今となってはghprbを使わずにJenkinsfileでやったほうが良いかもわかりませんね．そう思います．現場からは以上です．

*1:${ghprbActualCommit} if you want to use the head of the pull request branch (e.g. refs/pull/4/head); or ${sha1}, to use GitHub's tentative merge of the compare and base branches (e.g. refs/pull/4/merge) if the PR can be automatically merged or the head of the pull request branch (e.g. refs/pull/4/head) if they can not be automatically merged. GitHub - jenkinsci/ghprb-plugin: github pull requests builder plugin for Jenkins