平常運転

アニソンが好き

過去記事とかは記事一覧で見れます

Mackerel Meetup #11 Tokyo で Mackerel の時系列データベースについて発表しました

ここ1年半くらい仕事でサーバ管理・監視サービス Mackerelの開発をしているのですが、そのユーザミートアップイベント Mackerel Meetup #11 Tokyo が2/5にあり、そこで"AWS で実現した Mackerel 時系列データ1分粒度長期保存の裏側"というタイトルで発表してきました。

mackerelio.connpass.com

続きを読む

Travis CI で go のバージョン指定するときに気をつけたいこと

tl;dr

  • 1.9.x とかでパッチバージョンを指定したいけど
  • これは手作業のアップデートが必要なのですぐには更新されなくて
  • みなさん気をつけてやっていきましょう

資料

Building a Go Project - Travis CI

github.com

今回の話題のネタはだいたいここで語られている:

github.com

解説

Travis で go のバージョンを指定すると、指定されたバージョンは travis-ci/gimme によってインストールされる。
gimme 自体には 1.9.x のようなバージョン指定を受け付ける機能は特になくて、 gimme だけでは「特定マイナーバージョンの最新パッチバージョンを使う」というような仕組みはない。けれど Travis では一見この機能が使えるようになっていて、それは何故かというと Travis のプロビジョニング側で 1.9.x => 1.9.2 のようなマッピングを行っているからである。様子はここにある:

travis-build/go.json at master · travis-ci/travis-build · GitHub

しかし、このファイルは特に自動的に更新される訳ではなくて、人間が更新する必要がある。テクニカルにはこのファイルは gimme リポジトリ内のテストデータを元に生成されている(不思議だ……)ので、 gimme => travis-build の順に更新してもらう必要がある。

github.com

github.com

大本のマスターデータ自体は Google API のデータで、( 様子 )、このデータ自体は素早く更新されるのだけど、 gimme と travis-build は手作業で更新しなければならないようで大変。僕は乱暴に gimme 側に p-r を送ったけど、 issue を立てれば更新してもらえる可能性は高そう。

まとめ

  • 1.9.x とかで望んだパッチバージョンが落ちてこなかったら
  • Issues · travis-ci/travis-ci · GitHub とかで issue を立てましょう
  • 人間が丁寧に更新しています

感想

gimme がネイティブで 1.x.x 解釈してくれ〜〜〜

ISUCON7に参加して予選敗退した

はい。

isucon.net

Iikanjini Speedup Contest こと ISUCON に参加して本戦出場できず予選敗退となった。2年前に出場したときは本戦に出場(して惨敗)したけど、今年は予選落ち。予選を突破できなかったのは残念だし力及ばず悔しい点もあったけど、いっぽうで上位10%には食い込めたことに一定の手応えも得られたなど実りも大きく、参加した甲斐のあった ISUCON だったと思う。

去年の様子です:

astj.hatenablog.com

astj.hatenablog.com

詳しいところはチームメンバーだった id:aereal がブログを書いているので、そちらにお任せ。こちらでは単純に感想とポエムを書きます:

this.aereal.org

続きを読む

YAPC::Fukuoka 2017 HAKATA で "稼働中の Web サービスの Perl 処理系バージョンアップをしていく話" をしました

f:id:astj:20170706040838j:plain

スライドが200枚を超え20分のトーク枠に収まらない予感がしましたが案の定収まりませんでした。誠に申し訳ございませんでした…… ちなみに社内で再演したところ30分かかりました。はい……

yapcjapan.org

ということで話してきました。前半は割と教科書っぽいお話、後半がはてなの実験的サービスである大チェッカーでの実事例を紹介する、という中身でした。つまり大事な本題を話しそびれたことになりますね……

スライドはこちらです。多分これだけ見ても意味分からない。

speakerdeck.com

後半の事例のうち、大チェッカー自体に関する部分については発表するはずだった内容をエントリ下部に記載しましたのでご確認ください。130枚目くらいからの中身に相当します(が、スライドの順序通りでない部分も多いです)。

処理系のバージョンアップはやったことがないとなにやら末恐ろしいことのように感じるかもしれませんが、(きちんとテストや検証体制がある前提で)バージョン差分が小さければ実際の所そんなに特別なことではないのだ……という認識のもと、サービスの寿命に合わせてヘルシーにバージョンを上げていけるとよいように思います。また、必要とされる変更を小さく切り分けて少しずつリリースしていくことで、バージョンアップそのもののリリースインパクトを小さくすることもヘルシーなバージョンアップ作業の大事な要素ですが、これはよくよく考えると継続的デリバリーにおける割と普遍的な考えではないでしょうか。

今回、B会場では Perl プロダクトの保守に関するいろいろな立場、話題のトークがあって大変興味深かったのですが、このトークもそんなトークの一つとして華を添えられていたなら何よりかなと思います。Hokkaido(Perl6 LT) => Kansai(Perl6 Talk) => Fukuoka(Perl5 Talk) と来たので次の Okinawa でも是非トークしたい。今度は時間に収まるトークをしたい!!!という気持ちであります。

補足

そういえば社内で再演したところ、「じゃあ具体的にはどうバージョンを上げたらいいんや」という話題になりました。個人的な所感としては、

  • 5.x.0 はやや(安定性重視だと)蛮勇なので、 5.x.1 くらいまで待つ
  • 最新の安定版で動作するところまで CPAN モジュールのバージョンは上げる
  • アプリケーションコード自体は、コード内で使っている廃止機能が廃止ではなく警告で収まるギリギリのバージョンまでまず上げる
    • 警告を見ながら廃止予定機能に対応していく
  • 警告を潰せたら最新 or 1つ前の安定版まで上げる

くらいのフローがまあまあヘルシーではないかなと思いました。勿論様々な事情や条件によって変わってきそうですが。

続きを読む

CentOS 5 の公式 yum リポジトリが終了したので centos:5 の置き換え用 Docker Image をつくりました

タイトルがだいたい全てです。

CentOS 5 が EOL を迎えたことにより、 CentOS 5 の公式 yum リポジトリはもはや利用できなくなりました。素の CentOS 5 の yum リポジトリ設定のままだとリポジトリがないので yum で新しくパッケージをインストールすることは最早できません。(CentOS 5 だと curl もデフォルトで入ってない!)
それ自体は EOL なので文句を言う筋合いは特にないし、最早 CentOS 5 を使い続けるための努力をするべき時期ではないのだけど、世の中場合によっては CentOS 5 ベースの Docker コンテナの上でスクリプトが動いていたり、あるいは CI 環境などで CentOS 5 上での動作確認をする必要が残っているということもあるにはあると思います。というかあります。そういった環境であっても特に前者では CentOS 5 を脱出する努力をするべきだと思うけれど、 yum リポジトリが消えてしまった以上標準の centos:5 Docker イメージは最早そういう用途には使えないのでハードランディングというか強制的に移行を求められることになります。具体的にはある日突然 yum コマンドがこけるようになって😇という気持ちになる。

ところで、 CentOSyum リポジトリは各バージョンにおけるスナップショットが http://vault.centos.org/ で公開されているので、 /etc/yum.repos.d/ 以下の設定を書き換えて vault (やそのミラー)に変えてやると一応スナップショットに対するインストールなどは行うことができます。(vault のミラーもそれはそれで存在するので、国内のミラーなどに向けるとなお良いとは思う)

……ということで、 centos:5 からのひとまずの移行先として、 astj/centos5-vault という Docker Image を Docker Hub に公開しました。

https://hub.docker.com/r/astj/centos5-vault/

Dockerfile はこちら。素朴。

github.com

5.11 の snapshot を向いているのでひとまず centos:5.11 の代替 Image として利用することができます。CentOS 5 の検証用 Image としてであったり、実行環境移行のソフトランディング用に使えるのではないでしょうか。

ちなみに気付いたら 32bit バージョンの fork も誕生していました。

https://hub.docker.com/r/themattrix/centos5-vault-i386/

ちなみに Ubuntu 12.04 も 04/28 付けで EOL になっていますね。こちらもみなさまがんばっていきましょう。

Ubuntu 12.04 (Precise Pangolin) reaches End of Life on April 28 2017

YAPC::Kansai 2017 OSAKA で Perl 6 で Web Application Framework をつくる、というトークをしました

3/4 に行われた YAPC::Kansai で Perl6 の話をしてきました。 "Perl6 で Web Application Framework をつくる" というタイトルで、 Sinatra っぽい簡易 Web フレームワークの簡易実装 Sixatra を紹介する、という発表でした。

speakerdeck.com

yapcjapan.org

よくよく考えると、社外で開催されるカンファレンスで LT ではないトークをするのは実は初めてでした。はてなエンジニアセミナーでのトークや、社外でもLTはあった。今回のトークのテーマが「温故知新」であることは実は忘れていたんですが、温故の側に寄った興味深いトークが色々あった中で、"新"というか夢の世界というか、なんというかそういう感じの話で花を添えられたら幸いです。別に花を添える為にトークしているわけではない。

トークの中でも触れましたが、 Perl 6 で Web 開発するために必要なコンポーネントは現状でも一通りは揃っています。尤も、本番投入可能な水準に達している物はあまり多くなくて、趣味で触って動くねやったー、という物が多いのも事実です。まあそもそも Perl6 自体がまだそういうフェイズではないという評価からするとやむなしという感じ。 Sixatra もそういう状態なので今すぐ本番投入!というものでは残念ながらありませんが、 Sinatra like な簡単な文法で Perl6 で Web アプリケーションを書き始められる起点としては使っていただけるのではないでしょうか。尤も、今はちょっと発表が終わったと言うことで気が抜けて手が止まっていますが、 Sixatra もふつうに使える軽量フレームワークにしていきたいという気持ちがあります。

github.com

他のトークも興味深いトークが山盛りでよかったですね。Perl の話あり、言語に寄らない Web 開発の話ありと YAPC らしく大変学びに溢れた一日だったと思います。あと大阪は近くて最高。

次は福岡とのこと。テーマは"未来"らしいですね。 Perl6 と指名されてしまったのでなにかまたトークしたい。ということでまたネタを仕入れておこうと思います。

・新モジュールありPerl6あり、未来に向けたPerlの話
・これからますます重要になる、セキュリティに関する話
・新しい働き方、新しい技術といった、未知の世界の話

http://yapcjapan.org/2017fukuoka/

yapcjapan.org