octoreleaseのJavaScript版 "octopublish"と、PHP版 "octopackage" を作った

JavaScript PHP

自分はawspecやkomaなど、gemのリリースにずっとoctoreleaseを使っていて、いつも便利さを感じています（mizzyさんありがとうございます）。

k1low.hatenablog.com

特に便利な機能は、関連PRへのコメントとリリースノートのPullRequestへのリンクです。

これは、PullRequestしてくれた人へのお知らせだけでなく自分用のメモとしてもとても重宝しています。

ところが、最近個人的に課題がありました。

octoreleaseは他の言語では使えない

OSS活動をしていて、Rubyでは簡単にできるのにJavaScriptやPHPでできないことにストレスを感じていました。

それがoctreleaseを利用したリリースでした。

というわけで、やっと、それぞれ作りました。

github.com

github.com

使い方はoctoreleaseとほぼ同じです。hubコマンドの利用（~/.config/hub）が前提なのも同じです。

詳しくはREADMEをご覧ください。

言語ごとにリリース方法が違う

今回、otoreleaseの別言語実装を作ってはじめて意識したのが、

各言語でリリース方法（リポジトリへの登録方法）が違うということです。

「使い方はoctoreleaseと"ほぼ"同じです」というのは「同じではない」ということです。

例えば、Rubyでは rake release によって、*.gemspec (正確には *::VERSION )にかかれているバージョン番号でGitHubへtagが振られ、そしてrubygems.orgへリリースされます。一番便利です。

（※今回は簡単にするためにGitHubだけを例に取り上げます）

JavaScriptはGitHubへのtagの登録は自身で行う必要があります。npm publish は package.json のバージョン番号でリリースされます。

PHPもGitHubへのtagの登録は自身で行う必要があります。そして（連携していれば）GitHubのtagと同じバージョン番号でPackagist.orgへリリースされます。

つまり、PHPスクリプトやcomposer.json内にそのライブラリのバージョン番号を示すものがありません。

今回、octopublishとoctopackageでは、そこらへんを個人的な感覚で吸収しました（＝適当）。

Composerプラグインを作ってみた

今回PHP版octoreleaseであるoctopackageを作るにあたって、Hirakさんのスライドと発表映像が本当に役に立ちました。

PHP Conference2016 Track1 (2) Composerプラグインの作り方 - YouTube

この発表は、まさにチュートリアルでした。発表を見ながら順番に実装していくだけでできました。

これはHirakuさんの発表も当然ですが、発表を映像として残してくれたPHPカンファレンスの方々のおかげです。

スライドの行間を体験できました。本当にありがとうございます。

というわけで

誰得というか俺得なわけですが（そして最低限の実装ですが）、octoreleaseと同じ便利さをJavaScirptとPHPで実現できて最高です。

PHPカンファレンス福岡2017でfaultlineについて発表してきました #phpconfuk

PHP

前回とほぼ同じタイトルですが、無事発表してきました。

github.com

実はスタッフとしてもお手伝いさせてもらったのですが、こちらは前日までにピークになる印刷業を担当しているので、カンファレンス自体は比較的楽をさせてもらいました。すみません 🙇 ありがとうございます 🙇

(登壇者視点で) Ask the Speakerが良かった

会場は一番小さいDホールだったので、ほぼ満席の中発表させていただきました。ありがとうございました。

25分で発表を終えたのでその場で質問を受けることができたのですが、その後、Ask the Speakerの席でも多くの方にかなり良い反応をもらえてとても嬉しかったです。

会場での質問のときに「Ask the Speakerの場でfaultline-webuiのデモを見せる予定です」と言ったのが良かったのかもしれません。

かなり込み入った質問をもらったり、POST with configに共感してもらったり、近くで会話できたのが良かったです。

頂いた質問はこんな感じでした。

最低限のAWSリソースの設定でfalutlineを構築したら、どれくらいのエラー通知に耐えられるの？

最低限の設定の場合、DynamoDBのCapacityが支配的になるので1秒間に1回のエラー通知を処理出来ます。

falutlineをインストールするときにAWS KMSのキーなどを事前に作る必要があるの？

いいえ、faultlineのデプロイをするために利用するIAM Userの作成以外で、AWSマネジメントコンソールで何かをポチポチする必要はありません。

faultline / faultline-webui にACLはあるの？

ないです。

ユーザの概念もありません。エラーをPOSTすることができる clientApiKey と全エラーを参照/操作できる apiKey しかありません。

ちなみに、パラメータ名は失敗したと思っています。

fautline-webuiで検索機能をつくれる？

実現可能だとは思います。

ただ、faultlineのストレージには最低限の情報のみだけを格納しているので、それに検索機能を実現しようとするとそれなりにIOコストやCPUコストが必要になって、結果、費用が高くなりそうではあります。

例えば、faultlineのエラーの詳細ログはJSON形式でS3に保存されているので、Amazon Athenaを活用した検索は可能だと思います。が、マニーが飛びそうですね。

PHPカンファレンス福岡2017 After Hack

fusic.doorkeeper.jp

昨年度に引き続き、非公式ながらまたしても開催しました。

ここでもfaultlineのハンズオンをやらせてもらったり、その場でPull Requestをもらったりして最高でした。

実際は上記以外のほうが濃かったです。来てくださった人が界隈で著名な人ばかりで発表も面白かった！

特に @slywalker さんのCakePHPの上に積み上げられたコードは別次元でした。ほんと精進します。。。。

ただ、

今年も！！

無限ビールを達成してしまいました！！

来年もし開催できたら「無限ビール達成できませんでした。。残念」と言いたい。

かかってこい！！

（※注意: 無限ビールを用意しているのは私ではなくFusicです。会社のみんなに感謝）

というわけで

皆さんお疲れ様でした！

PHPカンファレンス福岡2017でfaultlineについて発表します #phpconfuk

AWS Serverless PHP Ruby JavaScript

昨年から faultline というエラートラッキングツールを開発しています。

github.com

PHPの現場 #4 でも紹介されていたRollbarと同じジャンルのツールです。

php-genba.shin1x1.com

faultlineというOSS

fautlineはAWSのマネージドサービスのみで構成されています。

いわゆるサーバレスアーキテクチャなため、サーバ自体の管理は（AWS任せで）不要になり、運用コストも（完全なゼロにはならないですが）限りなく小さくすることができています。

つまり、運用面において、OSSでありながら有料のSaaSに近い感覚で運用ができます。

また、簡単に導入できるようにfautline自体のインストールもシンプルにしています。

さらに各アプリケーションへの導入も、PHPだけでなくJavaScriptやRubyのライブラリも提供することで簡単にしています。

なぜここまで整備をしているかというと、複数のプロダクション環境で実際に運用しているからです。

というわけで

「実際どうなの？運用できているの？」という気になる点について、今週末6月10日に開催されるPHPカンファレンス福岡2017で、“faultline / faultline-php によるサーバ管理不要なエラートラッキングとその効果"というタイトルで発表します。

“OSS"の"サーバレスアーキテクチャなツールの活用” というのはまだまだめずらしいと思いますので、興味ある方は是非。

awspecのための簡易AWSリソース取得ライブラリ awsrm をはじめた

AWS Ruby

AWS Summit Tokyo 2017が開催されている中、皆さんいかがお過ごしでしょうか？

弊社も IoT開発のためのテストサービスであるmockmockを出展しています。

mock-mock.com

皆さん、是非ブースに遊びに来てください。

ちなみに、私は金曜日のAWS Dev Dayに一般参加者として参加予定です。

さて、本エントリは、以下のエントリに対しての実装です。

k1low.hatenablog.com

いよいよAWSリソースの一意特定が難しくなってきた

awspecで上げられたIssueで、現行awspecだとテストが書きにくいものとして

  • Auto Scaling GroupをTerraformで作っているので名前をつけていない。タグでリソースを特定したい
  • Route Tableをテストする際にVPCでフィルタリングしたい
  • SubnetをCIDRでテストを書きたい（名前やIDで特定していない）（必然的にVPCでフィルタリング）

などがありました。

ただ、様々なリソースの様々な特定方法をawspecの各リソースタイプに実装するのは、実装が複雑になりそうなのであまり乗り気ではありませんでした。

とはいえ、「awspecを使う人にSDKを駆使してもらうのを強いるのもなー」と思っていまして、思考が紆余曲折した結果ライブラリとして切り出しました。

awsrm

github.com

awsrmはシンプルで統一したAWSリソース情報の取得方法の提供を目指すライブラリです。

（Relational Mappingとは言えない実装ですが、情報取得の仕方を少し世の中ののORMに似せているので、名前の末尾に rm を付けてみました。）

SDKを直接使うよりも簡単に（でも、できることは少ない）

「統一したAWSリソース情報の取得方法」というのが結構重要で、実はAWSリソースの取得方法はSDKレベルだとそれぞれ似ているけどちょっと違います。

そこらへんを強引に統一することで、awspecを利用するときにあまり考えることなく必要最低限のAWSリソース情報を取得できるようにしています。

例えば、SubnetをVPCでフィルタリングしつつCIDRブロックでテストを書きたいときは one メソッドが使えます。

require 'awspec'
require 'awsrm'

describe route_table(Awsrm::Subnet.one(cidr: '10.0.0.1/24', vpc: 'my-vpc').id) do
  it { should exist }
  it { should belong_to_vpc('my-vpc') }
end

あるVPC内のRoute Tableのテストを一気にしたいときは all メソッドを利用します。

require 'awspec'
require 'awsrm'

Awsrm::RouteTable.all(vpc: 'my-vpc').each do | route |
  describe route_table(route.id) do
    it { should exist }
    it { should belong_to_vpc('my-vpc') }
  end
end

find(:first) とちょっと違う動きの one

awsrmのユースケースは、awspecにおけるリソースの特定ですので、SQLでいう LIMIT = 1 ではリソースの一意な特定ができているとは言えません。

なので、awsrmで提供している one メソッドは、取得結果が0件だったり2件以上だった場合はエラーになります。

というわけで

「awspecでこんな感じでリソースをまとめてテストしたいんだけどなー」と思いましたら awsrm へPull Requestをよろしくお願いいたします！

最後になりますがawspecと一緒じゃなくても使えますよ？

楽しみにしているテック系Podcastまとめ

未再生エピソードがもうありません。

半年以内に配信があった中で、配信を楽しみにしているPodcastをいくつかリストアップしてみます。

目的は「もっとエピソード配信が増える」「もっとテック系Podcastが増える」です。

Rebuild.fm

http://rebuild.fm/

最近のテック系Podcastブームの先駆け。

テック系を通り越して既に別次元のエンターテイメントになっている。

なんでこんなに面白いのかわかりません。でも面白いんです。

mozaic.fm

http://mozaic.fm/

Web技術。毎回濃くて勉強になります。

そのWeb技術をよく知らなかったらmozaic.fmその技術のエピソードを聞いてテンションを上げる方法をとったりします。

最近配信が止まっていますが、まだ凄いWeb技術がでてきたら配信されそうです。

engineer meeting podcast

http://engineer-meeting.tumblr.com/

エンジニアの人たちの話。ゆるい。リアルなエンジニアの人たちの話っぽい話の流れが好きです。

もう3年続いているらしいです。老舗なほうですかね。

「こんばんわ。エンジニアミーティングPodcastでーす。」の入りがクセになっています。

「プロジェクト開発カードゲームを作ろう」のコーナーは是非聞いてみて欲しいです。プレイしたくなります。

のぼりーさんのクラウドインフラPodcast

https://cloudinfra.audio/

クラウド系Podcast。自分の仕事の守備範囲と近い話なのでいつも興味深く聞いています。

Rebuild.fmと並んで、奥さんとドライブ中に聞くことがあるPodcastです。

Frontend Lunch

https://soundcloud.com/hatena-frontend

はてなのフロントエンドのエンジニアの人たちの技術ばかりのPostcast。レベルの高いエンジニアの人たちの話題ってこんな感じなのかなーと思っています。

最近、JSer.infoの話題からはじまるのですが、フロントエンドについていけていない自分としては「あーそういうところに興味を持つのか」と勉強になります。

PHPの現場

http://php-genba.shin1x1.com/

まさにPHPの現場。最も「あーあるある！」ってなるPodcast。あと耳が痛い。「もっと頑張らないと」と思ってしまいます。

boot.fm

https://bootfm.github.io/

話題の範囲や割合がすごく好みなPodcast。

最近更新がないのがちょっと寂しいです。

genba.fm

https://genba.fm/

最近はじまったJavaScriptの現場のPodcast。

らしいですが、フロントエンドに弱い自分にはレベルが高いのかまだ現場感が感じられない感じです。

mosaic.fmとは別の感じで濃くて「次のエピソードはなんだろう？」と楽しみです。

Vue.jsにも興味を持ちました。

以上です。

技術の話が多くて、アニメなど趣味の話題が少ない（もしくは知らない人のために都度噛み砕いている）Podcastが多い気がします。

技術の話は（当然）勉強になりますし、それ以外でも、聞いている間だけでも話題についていけているフリができるようなエピソードが好きみたいです。

オススメがありましたら教えて下さい。

最近のCertman活動またはCHANGELOG

AWS Ruby

日本だけでなく海外の方にも（どこで見つけたんだ？）使って頂いていて、ACMやDNSにおける知識を教えてもらいつつ修正を繰り返してとりあえず一段落した感じです。

前回 からのアップデートをCHANGELOG代わりに記録しておきます。

--remain-resources オプションを追加した

github.com

証明書の自動更新の条件に当てはまらないときのための対応です。

ACMを取得するために利用したRoute53/SES/S3の設定を残しておくというものです。

実はこの条件についてリクエストをもらうまで知りませんでした。ありがたいです。

これをきっかけにできるだけ将来にわたってリソースを残しても問題がなくなるように、 v0.7.0までにわたっていろいろ改修を加えました。

各リージョンでACMを発行しても問題がないようにした

当初はRoute53でも使える証明書が発行できる us-east-1 固定でした。

リクエストをもらって各リージョンでも使えるようにしました。

github.com

その際に不可解な現象に悩まされ（あるリージョンではうまくいくけどあるリージョンではうまくいかない）、 muranushi さんにかなり付き合ってもらいながら改善できました。

ちなみに不可解な現象というのはS3のバケット名のバリデーションがリージョンごとに違ったというものでした。

ワイルドカード指定のドメインや www. なドメインに対応した

やっぱり要望がありました。Pull Requestまでいただきました。

まあ、そうですよねー。

認証用メール用のドメイン（MXレコードの配置）についていろいろなパターンに対応した

認証メールを受け取る方法がいろいろあるので（これもあまり知らなかったです）、いろいろとアドバイスをもらいながら修正をしました。

S3/SESのリージョンをCertman側で指定するようにした

SESは全てのリージョンにはないので、SESがないリージョンでACMの証明書を作成する場合SESは別のリージョンになります。

最初は「別のリージョンにする必要があれば」us-east-1にするような実装だったのですが、これを「ドメイン名をハッシュ関数に渡して、Certman側でSES/S3のリージョンを指定する」ようにしました。

これはCertmenを作成する際に、Certman側でSES/S3のリージョンを知る方法が必要だったのと、リージョンが分散されているほうが有効だと判断したためです。

SESのReceipt Ruleを作成する際に、既存のActive Receipt Rule Setに追加するようにした

SESのActive Receipt Rule Setは各リージョンで1つしか設定できません。当初は新しいReceipt Rule Setを作成してそれに切り替えてACMの認証メールを受け取っていました（終わったら既存のReceipt Rule Setに戻す）。

しかし、これだと認証メールを受け取っている間、既存のReceipt Rule SetにあったRecipt Ruleが動かないという問題あります。

さらに、 --remain-resources を指定してリソースを残してしまうと既存のReceipt Rule Setが適用されないままになります。

なので、v0.7.0からCertman用Receipt Ruleは既存のActive Receipt Rule Setに追加するように修正しました。

認証メールの再送に対応した

github.com

CertmanではACMの認証に必要なリソースを一気に作るので、ときどき認証メールを受け取れないタイミングがあります。 なので、ACMの認証メールを一定間隔で再送するようにしました。

今後対応したいこと

  • 最初のpromtをスキップできようにする（-y オプション)
  • 既存のACM証明書の認証メール取得用AWSリソースを後から作成できるようにする ( コマンド名決まっていない )
  • 証明書のインポートに対応する ( import コマンド )
  • 証明書のステータスを取得する ( status コマンド )

Certmen (ACMの証明書全てを管理する何か) が必要かどうかはいろんな人からフィードバック貰いたいところですね。

ACMの証明書取得方法を忘れたい人は是非利用してみてください。

Infrastructure as Code 第I部読了。Infrastructure as Codeとそれを構成する要素を俯瞰できる第I部でした

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

やっと、Infrastructure as Codeの第I部を読み終わることができました。 （なかなかまとまった時間がとれなくて、何度も読み戻ってしまいました）

Infrastructure as Codeといえば、

ちょうどnobolycloudでもmizzyさんがゲストで、Infrastructure as Codeの見どころを紹介していましたね。

cloudinfra.audio

自分が言いたいことはタイトルで書いてしまったのですが、以下長々と感想です。

第I部

Infrastruture as Codeはクラウド時代に仕事を終わらせなければならないエンジニアのためのもの

「仕事を終わらせなければならない」が個人的パワーワードでした。

確かになーと。

ここ数年で自分の中でAnsibleやCapistrano、TerraformやServerspecがあたり前になっていて、それらを当然として開発をしています。

先日もRoute53で管理されている複数のドメインの設定変更を行いました。

その時もRoadworkerやPiculet、そして少しのRubyスクリプトを駆使することで事前の検証や一括設定変更ができて、心理的負担少なく対応ができました（今度どこかで書きます）。

もし、Infrastructure as Codeがなかったとしたら

「もし、Infrastructure as CodeやCodenizeの考え方がなかったとしたら、、、？」というのは、今となっては考えられません。

自分は、社内では少なくなった「CDでOSをインストールしたことがある」「データセンターにラックサーバを設置したことがある」世代です。

しかし、当時のインフラ運用の仕方を今もしていたら到底仕事は回らないと思います。

むしろ、「さらにInfrastructure as Code / Codenizeを進めていかないと会社として競争力を失い遅れていくのでは？」という不安も強く感じます。

例えば1章では、そういった不安の原因を「課題」として名前を付けてわかりやすく説明してくれています。

「スノーフレーク」や「オートメーション恐怖症」など、あるある過ぎます（何を意味するのかは是非本書を読んでみて欲しいです）。

それらの課題についてどのようなアプローチで解決するべきなのかを俯瞰的に紹介してくれます。そしてそれらを原則と呼んでいます。

IaCに興味があるエンジニアだけでなく、IaCの導入が進まないエンジニアにも是非読んで欲しいです。

「へー、Infrastructure as Codeってこういう課題から生まれているのか。うちに必要かな」

「Infrastructure as Codeの原則に沿っているかな？」

と読むのに良い章だと思います。

この章だけ読むのも十分価値があります。

インフラがプログラマブルになったからInfrastructure as Codeが定着したという側面

Infrastructure as Codeは全てのインフラに十分な形で適用できるわけではありません。

Infrastructure as Codeの発展の裏にはインフラの進化があって、その進化したインフラにInfrastructure as Codeがマッチするというのです。

2章や5章はそういった「Infrastructure as Codeと相性の良いインフラの条件」について紹介しています。

自分はAWSを良く使うのですが、AWSはまさに本章で紹介する「ダイナミックインフラストラクチャプラットフォーム」です。

操作のほとんどがAPI経由で実現できますし、サービスのリリースのタイミングでAPIやSDKがリリースされることもあります。

そんなAWSが「Infrastructure as Codeと相性が良い」というのは感覚ではわかっていました。

本書では「Infrastructure as Codeと相性の良いインフラの条件」をしっかりと説明しています。

読むと逆にそれらの条件を満たしているAWSやその他のクラウドサービスの凄さを改めて感じます。

良い時代。

受け身かオートメーションか

「サーバを追加したら、サーバ管理システムに登録してください」

正直、これが本当に面倒です。

「脆弱性が報告されたので、各自管理しているサーバを確認してください」

必要なのはわかっていますが、これも面倒です。

この課題をいつか解決をしたいと思っています。（実は受託開発会社ならではの悩ましいところもあるのですが、解決はしたいのです。）

今ならVulsがありますし、komaも作ったりしました。なんかできそうな気がしています。

そういった意味で3章のCMDBについての話はうなずきっぱなしでした。

（CMDBの話も是非本書を読んでみてください。）

サーバ構成ツールからコンテナの世界

4章は「Infrastructure as Code」と聞いて個人的に真っ先に想像するサーバ構成ツールの話です。

やはりコンテナに章の大部分を割いており、コンテナの利点やセキュリティの考え方などがわかりやすく説明されています。

イミュータブルな世界には憧れます。

第II部が楽しみ

第I部は、Infrastructure as Codeの基礎でした。

それを踏まえて第II部はさまざまなパターンについて書かれているそうです。

nobolycloudでも好印象な箇所なので非常に楽しみです。

最後に

mizzyさん、ご恵投いただきありがとうございました！

まだ時間はかかりそうですが、じっくり読んでいきます！