35歳からの中二病エンジニア

社寺・鉄道・アニメを愛でるウェブ技術者の呟き

ChatWork向けIncoming Webhooks的なものを作った

技術 Python

ウェブサービスでアイコンがデフォルトのアカウントはみんなじゃがいもだと思っているaikawameです。ごきげんよう。

はじめに

僕の勤めている会社では、社内チャットにChatWorkを利用している。「ChatWorkが許されるのは小学生までだよねー」とかSlack派に煽られそうだけれども、僕自身はそんなに嫌いではない。ただ、Slackに比べて欲しい機能が足りていないのは事実だったりする。

その中でも特に、会社のメンバー間でも不満だったのが、Incoming Webhooksが無いということだった。これだけのためにエンジニアはSlackも使うという残念な状況が出来てしまっていた。

そこで、似たような仕組みを誰か作っていないかと探してみたが、要件を全て満たしてくれるようなイケてる子は見当たらなかったので、無いものは作るの精神でサクッと作ってみた。

作ったもの

出来上がったものはこちら。

github.com

標準でGitHub、Backlog、ScrapboxとSlackのAttachment structureに対応しつつ、基本的に設定とテンプレートの追加だけで対応サービスを増やしていけるので、サクッと作った割には良い感じになったと思う。

フレームワークとして採用したのはChalice。AWS Lambdaを使ってAPI環境を実行できるサーバーレスフレームワークだ。Lambda界隈だとServerless Frameworkが強いとは思いつつも、個人的にnodeよりはPythonの方が好きなので、こちらを選んだ。というかLambdaはPythonでしか使ったこと無い…。

苦労したこと

Chalice周りとか、普通の実装については割とすんなり行ったと思う。面倒だったのは主にWebhookで送られてくるJSONの解析や、テンプレートのフォーマット周りだった。

前者については、これはもう地道にやるしかなかった。ScrapboxはSlackのAttachment structureに対応していたし通知も1種類だったから一瞬だったけれども、GitHubとBacklogは曲者過ぎた。さすがに全てのパターンを網羅するのは辛いので、とりあえず業務で使っている部分だけテンプレートを用意して、あとは無視する形でお茶を濁している…。この辺、Webhookの共通フォーマットとか作ってもらえないものだろうか、Attachment structureみたいに。

後者については、ChatWorkで使える装飾が少なすぎて辛かった。Attachment structureでは色やリンクを指定できる所をどうやって表現しようとか、段々と考えるのが面倒になってきたので、とりあえず最低限タイトルと本文だけでいいやという感じに落ち着いた。

おわりに

会社でX2ChatWorkを導入してみた限りでは概ね好評で、既存のSlackへの通知はほぼChatWorkに置き換えた。この勢いならばSlackの撲滅は近そうだ。もし、ChatWorkを使いつつIncoming Webhooks的な仕組みも欲しいという方がいれば、是非とも試していただきたい。そして星くれ。

チャットワーク【公式】活用ガイド

チャットワーク【公式】活用ガイド

平成30年の初詣

社寺巡礼

神社の境内で馬鹿笑いしている人を見るとモスクで同じことをしたらどうなるのかなんて想像してしまうaikawameです。ごきげんよう。

はじめに

年末年始は1年の中で最も神社に人が集まる時期だ。特に初詣の時期は神社が賑やかになるので、平素から参拝している神社でもついつい写真に収めてしまう。というわけで、この年末年始に参った神社についてまとめておきたい。

御礼参り

僕はここ数年、師走の中頃になると、氏神様である新宿諏訪神社と新宿総鎮守である花園神社へ御礼参りに出掛けている。その1年の御礼のためと、翌年の御神札を頂くためだ。本当はお伊勢さんまで参拝したいのだけれども、さすがに東京からは遠いので、数年に1度しか参れていないのは残念なところではある。

昨年はバタバタしてしまい、御礼参りは最終週の平日になってしまったけれども、無事に済ませて御神札も取り替えることが出来た。

初詣

初詣については元旦にすべきか2年参りか迷い所ではあるけれども、基本的にその年々の気分で決めている。今年は元旦だと起きるのが辛い気配だったので、先に参ろうと日が変わる前から氏神様に並ぶことにした。

実は諏訪神社へ夜に参拝したのは初めてで、松明を焚いていたりお神酒が振る舞われていたりと賑やかだったのには驚いた。しかも先着500名で宝船（枕元に敷くアレ）まで頂いてしまった。2年参り、アリだな。

続いて花園神社へは6日に参拝。こちらは毎年のことながら凄い人だかり。新宿で遊びがてら寄った感じの若者がやたら多い。まぁ、神社が潤うことには違いないので、僕はそこまで毛嫌いしているわけではない。ただ、御手水で柄杓に口付けるのだけはやめてね（にっこり）。

更に9日、仕事始めということもあり、出社前に東京大神宮へ参拝。お伊勢さんへ直接参れていないので、せめてもと毎年東京大神宮か芝大神宮のどちらかには参拝するようにしている。こちらは参る度に感じるのだけれども、鳥居の前で一礼している人が靖國神社を超えるのではないかというくらい多い。

会社でも初詣

僕が勤めているのはバリバリのウェブ系スタートアップなので縁がないかと思っていたけれども、意外にも会社として初詣に出掛けることになっていた。しかも神田神社へ。この時期大混雑の、あの神田明神だ。

と思ったら意外にも空いていて、すぐに受付を済ませられてしまった。そして拝殿へ。昇殿参拝は久々だったけれども、やはり気が引き締まる。

おわりに

兎にも角にも、初詣は無事に済ませられた。今年もこれから各地の社寺を巡りたいと思っている。

冴えない彼女の育てかたを全巻読んだ

漫画・ラノベ

コミケでサークル入場者が「見ろ、人がゴミのようだ！」と言っているのを見ると「フ…貴様もこの世界からすればゴミのようなもの…」と心の中で呟いてしまうaikawameです。ごきげんよう。

はじめに

ネタバレは無しの方向で。

冴えない彼女の育てかた、通称冴えカノ。僕にとっては今の所唯一まともに読んだライトノベルだったりする。そっち系の趣味というと、20代まで所謂美少女ゲー（というかエロゲーですぼかしてごめんなさい）をちょくちょくやっていたくらいで、今は基本的にアニメ専門という感じ。アニメ繋がりだと、漫画原作ならば面白ければ読むことはあっても、ラノベ原作となると時間的な所で中々手を出せずにいた。

そんな僕がアニメ1期でどハマりして全巻読破、しかもコミカライズ3ルートまで全て網羅するくらいなので、冴えカノは凄いと思う。最終巻を買ってから暫く経つが、漸く踏ん切りをつけて読み切ったので、つらつらと思うがままに綴っていく。

何が良かったのか

冴えカノが僕の琴線に触れた所は2点あって、作品全体がエロゲーの文脈で綴られていることと、同人活動を主題にした作品であるということだ。

前者については、作者の丸戸史明先生がそもそもエロゲー畑の方で、しかも蛭田信者という筋金入りなので、さもありなんという感じがする。エロゲーというと僕らの世代だと葉鍵が鉄板だけれども、僕はあの手のあざとさは若干苦手で、それよりも初期蛭田作品のようなドタバタコメディーと重厚なドラマが入り交じったような作風を好んでいたりする。そういう意味では、冴えカノの主人公は底抜けにバカで妙に熱いあたり、ドンピシャなのだ。どこかの鳴○孝○君とは正反対だな…。いや、○ge作品は好きだけれども。

閑話休題。

後者については、完全に個人的な理由になるけれども、僕自身も20台の頃同人活動をやっていたことが大きい。色々あってエンジニア業に集中することにはなったけれども、締切前の修羅場感とか、コミケ出展の高揚感、あとはクリエイターの矜持など、当時があったからこそ共感することばかりだった。

特にクリエイターの心情表現が熱い。クリエイターの世界を扱う作品としては直近だとSHIROBAKOが有名だけれども、あれはどちらかと言えば叙事的だと思う。というか、そう思えるくらいに冴えカノがドロドロとしたクリエイターの内面をよく描いているのかもしれない。特にアニメや原作準拠コミカライズで描かれていない先の話に至っては、一般人からすれば狂っているとしか思えないような、狂いすぎていてファンタジー扱いされそうな場面が出てくる。

でも、クリエイターの世界に足を突っ込んだ人ならわかるのだろうけれども、あの世界は創作があらゆる他の事象に優先するという意味では確かに狂っていると思う。そういう人達の生々しい心情表現をラブコメに混ぜて一つの作品に昇華しているのが、冴えカノの凄い所だ。

創作とは何なのか、才能とは何なのか

僕は、創作というのは公開オナニーだと思っている。少なくとも同人界隈においては。だってそうだろう、純粋に自分が理想としているものを形にして世に出して、それによって満足を得ているのだから。R-18の同人誌など、「私はこういうシチュエーションでの絡みが一番抜けます」と宣言しているようなものだ。そして、その公開オナニーの持続力こそが才能だと思っている。これ、割と真面目な話。

冴えカノは、まさにこういったクリエイターの本質的な部分を緻密に描くことで、創作とは、才能とはという問いに対する答えをそれぞれの登場人物を通して表現していると思う。巷ではキャラが皆頭おかしいとかキ○ガイとか言われて久しいけれども、これもまた、普通の神経ではガチの創作なんて出来やしないことを示唆しているように思えてならない。実際の同人の世界にも、頭のネジが何本か抜けたような人がわんさかいるし。しかも、そういう人ほど凄い作品を作っていたりするから、あの界隈は面白いし、だからやっぱり創作はイカれた行為なのだ（異論は認める）。

そんな世界をリアルに描写しているから、冴えカノもまた面白いのだ。

少しだけ自分の話

少しだけ自分の話をすると、僕の場合は同人活動において、持続力が足りなかったと思う。創作自体は好きだったとしても、すぐスランプに陥って、プログラミングの方に浮気して、なかなかネタが出なかった。しかも、作品を創ることだけでなく、サークルの運営も好きだったので、ガチで創作一筋の人達に敵う訳が無かった。いや、別に同人なので誰に勝つとか負けるとかは無いのだけれども、それでも本業以外の時間の大半を割いてやるだけの価値があるのか？と自問した時に、最終的には余暇も含めてエンジニア業に集中すべきだという結論になった。

今でもこの判断は正しかったと思っている。というのも、僕にとってはエンジニア業も創作なのだ。公私含めて。しかも、同人でやっていた時よりもスランプは短い（それでもあるが）し、他に浮気するようなものも無い。晴れて自分もガチで創作一筋の人になれたというわけだ。まぁ余暇に鉄道旅行したり社寺を巡っていたりはするので、キチ○イクリエイターの域には達していないと思うけれども、そこが才能というやつで、僕は余暇を100%プログラミングに注ぎ込む才能は無いというだけのことだ。それは多分自分でも制御し切れない部分なので、あとは代わりに与えられた「器用貧乏」という才能を活かしていくということになるのだろう。

とは言いながらも、どこかでまだ、本物のキ○ガイクリエイターへの憧れがあるから、冴えカノに惹かれるのだろうな。

おわりに

冴えカノはライトノベルという形での刊行だし、表面上はゆるいラブコメなので、SHIROBAKOであれば手に取れた層でもこれはさすがに…となりがちかもしれない。でも、冴えカノは読めば読むほどクリエイターの光と闇の世界に引き込まれていくこと間違いないので、あの世界に興味のある方は一度読んでみると良いと思う。ちなみに、僕はこの作品の真骨頂は後半部分だと思っているので、アニメやコミカライズではなく原作をお薦めしておく。

ちなみに、僕の推しは紅坂朱音です。

冴えない彼女の育てかた13 (ファンタジア文庫)

冴えない彼女の育てかた13 (ファンタジア文庫)

ブログとQiitaの使い分け

ポエム

ブログとQiitaに同じ内容の記事が上がっているのを見るとティム・バーナーズ＝リーにジャンピング土下座させたくなるaikawameです。ごきげんよう。

はじめに

僕はQiitaアカウントも持っているのだけれども、ブログを始めてみてどちらにどんな記事を投稿するのかを決めておかないと後々面倒だと思ったので、まとめておく。

Qiitaに書くこと

Qiitaは、プログラミングに関する知識を記録・共有するためのサービスです。

とあるように、Qiitaはその目的を明確に定義している。なので、まずはQiitaに書くことを整理してみる。

プログラミングや周辺技術に関する知見

  • プログラミング
  • インフラ技術
  • 開発に役立つツール

ブログに書くこと

一方で、ブログに書くことは早い話がQiitaに書くこと以外の全てとなるが、一応整理してみる。

技術的でない記事

  • 鉄道
  • 社寺巡礼
  • アニメ・ゲーム等
  • その他趣味など

このあたりは考えるまでもない。

プログラミングには関係の無い（薄い）技術的な記事

  • 自作PC
  • デジタルガジェット

このあたりは若干プログラミングも絡んできそうだけれども、プログラミングが主でなければ全てブログに書く。

プログラミングに関係はあるが知識ではない記事

  • 作ってみた
  • 書評
  • ポエム

作ってみた系は若干ややこしくなりそう。成果物についての説明はブログに、その途中で得た知見は切り出してQiitaに書くのが良さそうかな。

結論

  • 知見はQiitaへ
  • 主張はブログへ

蛇足

  • ブログとQiitaに同じ内容を投稿するのは技術者としてあるまじき行為なので絶許。
  • Qiitaにブログへの踏み台記事を投稿するのは人としてあるまじき行為なので絶許。

Qiita 人気の投稿

Qiita 人気の投稿

キーバインド 復活のKarabiner

技術 Mac

JISキーボードを見ると半角/全角キーにセメダインを流し込みたくなるaikawameです。ごきげんよう。

はじめに

macOS Sierraになってから、IMEのトグルやEmacsキーバインドを設定していたKarabinerというツールが動かなくなってしまった。当時は暫くEl Capitanを使い続ければ良いやくらいに思っていたものの、昨年の夏に転職してSierraの入ったMacを手にしたことで、強制的に代替策を検討する必要に駆られてしまった。

当時はKarabiner-Elementsという後継ツールはあったものの、単一キーの入れ替えにしか対応していなかったので選択肢とはならなかった。そこで代わりとして不十分ながらもHammerspoonを使っていたのだけれども、Karabiner-Elementsがここ数ヶ月で正式リリースを経て格段に進化していたらしい。これは試さない理由は無い。

作ったもの

というわけで、論より証拠で自分用のキーバインド設定を作ってみたのがこちら。

github.com

Karabiner時代とは違い、設定ファイルは分割できて、JSONで書けるようになっている。それぞれのファイルの内容は次のような感じだ。

emacs_key_bindings.json

本家サイトからもEmacsキーバインドの設定はインポートできるのだが、僕は主にブラウザー向けとして、C-s/C-rで検索したり、C-x b/C-x kでタブを開閉したり、テキスト入力にもオレオレ設定が必要なので、全部自分で書くことにした。あくまで個人用途に書いたものなので、

  • 除外するアプリケーションは自分の使っているものしか書いていない（iTerm2、Sublime3、IntelliJ）
  • CapsLockを有効にしていると使えない
  • 左側のCtrl/Optionキーしか使えない

等の制限があるが、書き換えるのは簡単なので自由に利用してもらって構わない。

for_japanese.json

僕はUSキーボードを使っていて、IMEの切り替えは右Optionでトグルしている。これはPC-98を愛用していた頃のXFERキーの名残だったりする。そもそもUSキーボードを使っているのも、「PC-98みたいにスペースバーが長いから」というのがそもそもの理由だったりする…。

閑話休題。こちらの設定では右OptionによるIMEのトグルが実現できる。別のキーに替える時の参考にもどうぞ。

windows_key_bindings.json

こちらはWindows時代の名残で、ブラウザーの更新はやっぱりF5だよねというやつ。くれぐれも攻撃には使わないように。

おわりに

この3ファイルを作った所で、僕が必要としているキーバインドの条件は全てクリアされたので、めでたくHammerspoonからKarabiner-Elementsに移行完了できた。僕はKarabinerがKeyRemap4MacBookと呼ばれていた頃から使わせてもらっていたこともあり、今回ばかりはと寄付もさせてもらった。macOSの仕様変更にも負けず、更に使いやすいツールに育ててくれた作者のtekezo氏には感謝するしかない。

コードギアス 反逆のルルーシュＩ 興道

コードギアス 反逆のルルーシュＩ 興道

元日によせて

ポエム

渋谷の年越しカウントダウンを見ると上空から水溶き片栗粉を散布したくなるaikawameです。ごきげんよう。

はじめに

あけましておめでとうございます。早いもので平成も30年となりました。今年からはいよいよ本格的に記事を書いていこうと思いますので、どうぞよろしくお願いします。

今年の抱負

一年の計は元旦にありと言うけれども、僕は今年の抱負というのを具体的には掲げないようにしている。年初に抱負を掲げると、それに縛られてしまうと考えているからだ。自らの可能性を狭めてしまうようにも思う。それよりも、時々で見つけた興味対象に打ち込んで、面白おかしく過ごしていければと思っている。

こうやって言うと少し格好付けた感じになるが、結局の所は目標や抱負を掲げた通りに実行するのが大の苦手というだけだ。何かをやろうと思っていても、他に強い興味対象が出てくるとすぐに目移りしてしまう。なので、先に決めていたことなど足枷にしかならない。

ただ、その結果として今もそれなりに楽しく生きられているので、悪くはないと思っている。僕がもっと堅実な人間だったとしたら、ソシャゲ黎明期にえいやっと業界に飛び込むような真似もしなかっただろうし、人に誘われてホイホイ転職なんてこともしなかっただろうから、エンジニアとしてそれなりの経験を積めたかどうか逆に怪しい。

どうせ根底部分の性格は大人になってからはそうそう変わらないし、その性格を有効活用することに注力した方が良いだろうということだな。

蛇足

今年は3度目の年男らしい。一応戌年なのだけれども、誰か僕に忠誠心を分けてください。

中の人について

ポエム

スタバでドヤ顔している人を見るとMacを叩き割りたくなるaikawameです。ごきげんよう。

はじめに

所謂ブログというやつの最初の記事に自己紹介とか痛すぎないかと思ったけれども、意外と色々なブログを巡ってみても自己紹介記事のあるブログが余り見当たらなかったので、逆に書いてみたくなった。

年齢

昭和57年（1982年）生まれ。PC-98誕生の1ヶ月後に生を受ける。

住んでいる所

東京都新宿区、歌舞伎町の銃声が聞こえてくるくらいの所。

主に住んでいた所

  • 三重県鈴鹿市、サーキットのF1レースが聞こえてくるくらいの所。生誕から高校まで。
  • 滋賀県彦根市、夏になると彦根城のお堀が臭ってくるくらいの所。大学の4年間。
  • 滋賀県大津市、「中二病でも恋がしたい！」の主人公自宅の近所。仕事で3年ほど。

言葉

伊勢弁と近江弁のごった煮。
京滋圏の人からは名古屋人と思われ、それ以外からは京都人と思われやすい。東京弁には意地でも染まらない。

仕事

ウェブ系のエンジニア。サーバーサイドを中心に、インフラやフロントもぼちぼち。

  • 2005年から新卒でSIerに入るも、すぐに辞める。
  • 2007年から携帯電話向けのサービス開発に携わる。
  • 2010年からソーシャルゲームの開発に携わる。
  • 2017年から普通のウェブ系スタートアップへ。

好き

プログラミング、鉄道、社寺巡礼、アニメ、音楽、ソニー

嫌い

チャラい系、煙草、現金決済、カタカナ語、運動、Apple

性格

見た目は紳士、中身は中二。決して厨二ではない（ここ重要）。
普段は口外しないが、大抵は「俺はあいつらとは違う」みたいなことを考えている。「中二病でも恋がしたい！」については、「厨二病でも恋がしたい！」に改名すべきだと壁に向かって言い続けているが、なかなか聞き入れてもらえない。

コミュ障と言うと意外な顔をされるが、大のコミュ障。
中学に入るまでは担任の教師ともまともに話せなかった。大人になってから一般人に擬態することを覚え、仕事でマネージャー的な立場だったような時期もあるが、本当は人よりもPCとキャッキャウフフしていたい。

なぜブログを始めたのか

一番の理由はタイトルにもある年齢。「エンジニア35歳定年説」なるものも囁かれる中で、寄る年波に抗うおっさんエンジニアの生態について書き綴っていくのは、それなりに意味のあることではないかと思ったため。

ちなみに、ブログを書こうと思ったことは何度かあった。ただ、文章を書くのは割と好きなのだが、凝り性なのでついつい時間を掛けてしまい、これでは続かない、と最初の記事も公開せずに投げ出してしまうことの繰り返しだった。

そんな事情もあり、とにかくその時々に思った内容をあっさりと書いていくことを念頭に、無理せず続けていければと思っている。ちなみに、大晦日に最初の記事を公開したのは、年明けだと在り来りだからに決まっている。皆まで言わせるな。

これからのこと

僕は健康でいられる限りはエンジニアという人種であろうと思っている。また、生涯中二病なのも変わらないと思っている。その辺りを軸に、僕の興味対象となる技術や時事ネタ、鉄道・社寺巡礼など趣味の話をつらつらと綴っていきたいと思う。

Mac使い向けのはかどるGUIツール10選

技術 Mac ツール

自分の使っているツールが会社のメンバーに意外と知られていなかったので、紹介してみたら好評だった。そこでこちらでも紹介してみることにした。

Alfred

  • マカーな開発者にはお馴染みのイケてるランチャー
    • むしろ使っていない人を知りたい
    • さらにはかどるWorkflowの使えるPowerpackは£19～

www.alfredapp.com

Stay

  • ウィンドウ位置記憶ツール（有料）
    • アプリ毎やウィンドウ毎に、位置とサイズを覚えてくれる
    • デュアルディスプレイ時と通常時で別々に記憶してくれる！
    • ノートPCでデュアルディスプレイするなら必須かも
    • 公式サイトかApp Storeから約$18で買える

cordlessdog.com

HyperSwitch

  • ウィンドウ切り替えツール
    • Cmd+Tabのすごい版
    • Windowsのようにウィンドウ単位で切り替えられる！

bahoom.com

iTerm2

  • 痒いところに手が届くターミナル
    • フォントとか色とか変えて、自分好みに
    • キーバインドも弄れる

www.iterm2.com

Sequel Pro

  • GUIのMySQLクライアント
    • これに慣れるとphpMyAdminが苦痛でしかなくなる…

www.sequelpro.com

Tower

  • GUIのGitツール（有料）
    • リビジョングラフが直感的に追いやすい
      • 指定したブランチから見たグラフを追える
    • コミットログのインクリメンタルサーチ
    • 個人的にはSourceTreeよりもかなり使いやすい
    • ￥7,499/年と若干お高め

www.git-tower.com

Paw

  • 高機能なRESTクライアント（有料）
    • 変数を設定して、モック・開発・本番等の環境を切り替えられる
    • GUIがかなりイケてて入力しやすい
    • API Blueprintからインポートできる（若干微妙だが…）
    • お値段は$49.99

paw.cloud

Insomnia

  • 高機能なRESTクライアント、しかも無料
    • GUIの使い勝手はPawより落ちるが、大体同じことができる

insomnia.rest

IntelliJ IDEA

  • Android Studio開発元によるIDE（有料サブスクリプション）
    • 言語毎に特化したIDEが用意されている
    • Eclipseよりかなり軽い
    • NetBeansよりかなりカスタマイズ性が高い
    • お値段は高めだが個人ライセンスで仕事にも使えるので、趣味と仕事で併用するエンジニアも

www.jetbrains.com

OmniFocus

  • GTD（すごいToDo管理）ツール（有料）
    • 脳内にしか無い「やるべきこと・気になることリスト」をゼロに！
    • GTDはそれだけで勉強会を開けるくらい奥が深い…
    • 公式サイトかApp Storeで約$40で買える

www.omnigroup.com

おわりに

開発が滞っているものの、代替ソフトが見つかっていないというツールもあるので、オススメがあればぜひ教えてほしい。ちなみに、エディターについては宗教戦争になるので書かないでおくが、VimかEmacsの二択を迫られたらEmacsである。

OpenShift難民が自分用PaaSを作った話

技術 OpenShift

個人ウェブサービスをOpenShift v2で無料運用していたのだが、残念ながら2017年9月でサービス終了の運びとなった。v3やHerokuではコスト的に複数サービスを回すのが辛いので、これを機会に自前のPaaSを構築することにした。

やりたいこと

  • 小規模な個人サービス4つを￥1,000/月以内で運用
  • うち1つはRails+MySQL、1つはPHP+MySQL、残りはPHPのみ
  • git push でデプロイ（OpenShift v2やHerokuと同様に）

IDCFクラウドでDokkuなら楽勝のはずが

条件に合う事例として、次の記事がすぐに見つかった。

muunyblue.github.io

IDCFクラウドの最小構成は￥500/月で安いし、DokkuはミニHerokuとして使えそうだ。この記事はIDCF公式のBlogでも紹介されていたこともあり、そのまま従っていけば楽勝だろうと高をくくっていた…のだが。

確かにDokkuの公式ドキュメントとこの記事を参考にしてスムーズにappを構築していけたのだが、3サービス目のappを立ち上げた所でストレージの空きが0%になってしまった。

何が問題だったのか

DokkuはHerokuと同様に、コンテナ管理にはDockerを使用している。そのベースイメージとしてherokuishを利用しているのだが、これが曲者で、なんとイメージサイズが1.35GBもあった。MySQLのイメージも400MB近いし、加えて色々な実験をするうちに15GBのストレージを全て食ったようだ。

なお、現状のherokuishはHerokuのイメージであるcedar-14をベースとしているが、最新のheroku-16では465 MBまでスリム化されているようだ。とはいえ、Dokkuでいつ採用されるかは不明であるし、採用されたとしてもDockerイメージとしてはまだ巨大なため、別のやり方を検討することにした。

どのように解決したか

Dokkuの公式ドキュメントにDockerfile Deploymentとあるように、自前のDockerfileもデプロイに使えるということで、試してみることにした。

今回はストレージを食わない事を優先したかったのと、複数コンテナの連携をうまくDokkuで実現できるのかという懸念があったため、邪道とは思いつつもPHP-FPMとnginxを同一コンテナで立ち上げる最小限のイメージを作ることにした。以下がそのDockerfileの内容である。

FROM php:7.1-fpm-alpine

RUN curl -sS https://getcomposer.org/installer | php \
    && mv composer.phar /usr/local/bin/composer \
    && docker-php-ext-install \
        mbstring \
        pdo_mysql \
    && apk add --update --no-cache \
        nginx \
    && mkdir -p /run/nginx \
    && echo -e "#!/bin/sh\nphp-fpm -D\nnginx -g 'daemon off;'" \
        > /usr/local/bin/php-nginx \
    && chmod +x /usr/local/bin/php-nginx

EXPOSE 80

CMD ["php-nginx"]

Alpine Linuxにしたこともあって、イメージサイズは70MBほどに収まった。なお、一応イメージはDocker Hubにも公開している。

このイメージをベースに（Railsのサービスについては既存イメージを使用）各appを構築したところ、特にハマる事も無くDokku上に展開できた。気になるストレージの使用率は35%程度で落ち着いている。メモリーの使用率が80%近くなってはいるが、こちらはswapを1GB確保しているのでひとまずは問題無いだろう。

おわりに

安価なクラウドやVPSで自前PaaSを構築する事例は多々あり、いずれもメモリーを確保する事に注意を促しているが、実際に複数サービスを運用するとなると、留意すべきはむしろストレージの方であった。

Dokkuの場合、自前のDockerfileも使えるため、スリムなイメージを用意すればストレージの小さい環境でも複数サービスを運用できそうである。小規模な個人サービスを複数運用しているのであれば検討しても良いかもしれない。

Ansibleでカーネルチューニング

技術 Ansible

LinuxのカーネルパラメーターやPAM limitsの設定は、大規模なサービスで抜けが発生すると大変な事になるので、Ansibleで一気に適用してしまいたい。最近のバージョンではどちらも専用のモジュールが用意されているため、備忘録がてら記載しておく。

カーネルパラメーター


sysctlモジュールを使用する事で、/etc/sysctl.conf を編集できる。
デフォルトで設定は即時反映される。

- sysctl:
    name: "{{ item.name }}"
    value: "{{ item.value }}"
    state: present
    ignoreerrors: yes
  with_items:
    - name: net.core.somaxconn
      value: 8192
    - name: fs.file-max
      value: 5242880

PAM limits

pam_limitsモジュールを使用する事で、/etc/security/limits.conf を編集できる。
なお、PAM認証を介さない制限には当然ながら使えないので、nginx等のdaemonの制限は別途行う必要がある事を忘れずにおきたい。

- pam_limits:
    domain: "{{ item.domain }}"
    limit_type: "{{ item.limit_type }}"
    limit_item: nofile
    value: 655360
  with_items:
    - domain: root
      limit_type: soft
    - domain: root
      limit_type: hard
    - domain: "*"
      limit_type: soft
    - domain: "*"
      limit_type: hard