読者です 読者をやめる 読者になる 読者になる

Wallpaper Engine 試した

Wallpaper Engine という動く壁紙が良さそうだったので、しばらく左側のディスプレイに表示してみることにした。

一見すると近未来的なようにも錯覚してしまうけれど、スクリーンセーバーなどは寧ろ一昔前に流行った文化で、どちらかと言うとレトロな印象を受ける。画面の中の画面が発する薄暗い光をぼうっと眺めていると、Samurizeをはじめとしたデスクトップ改造スレに入り浸っていた頃の懐かしい思い出に引き摺り込まれそうになる。

amakanのCIをShippableに移行した

https://amakan.net/ のこの辺の改善の続き。


f:id:r7kamura:20170114143123p:plain

CircleCIからShippableに移行した

amakanをDocker化した感想 - ✘╹◡╹✘ で触れた「CIのビルドに時間が掛かるようになった」という問題に対応するため、利用するCIサービスをCircleCIからShippableに移行した。他の候補としてTravisCI、Werckerなどを見たけれど、ShippableはDockerのキャッシュに上手く対応しているということで、これを選択した。

ビルドに掛かる時間が500秒から60秒になった

CIの中では、こういうことをやっている。

  • Node.js用のDockerイメージをビルドする
  • Node.js用のDockerイメージでテストを実行する
  • Node.js用のDockerイメージでCSSJavaScriptを生成する
  • Rails用のDockerイメージをビルドする (直前で生成したCSSJavaScriptを含めつつ)
  • Rails用のDockerイメージでテストを実行する
  • Rails用のDockerイメージをAmazon ECRにPushする

CircleCIからShippableに移行したことで、過去にビルドしたDockerイメージのキャッシュが再利用できるようになったので、それぞれのDockerイメージをビルドする部分が一瞬で終わるようになった。

Volumeを使おうとすると複雑

上述の処理を実現するために、これまで --volume $(pwd)/public/assets:/app/public/assets というオプションを利用していたが、--volumes-from ${SHIPPABLE_CONTAINER_NAME} というようにデータボリュームを用意する方法に変更する必要があった。--volume オプションを指定してもホスト側とは何も共有されない (エラーも出ない) という挙動を元に原因を調べるのに時間が掛かった。

UIが分かりづらい

他のCIサービスと比べると、UIが見づらくて使いづらい。良い機能を提供していると思うので、余計に勿体無く感じる。

無料ではプライベートリポジトリは1つまで

無料では1つまでしかプライベートリポジトリが利用できないので、高速化したいamakanだけとりあえずShippableで運用してみている。

設定例

amakanのshippable.ymlです。

language: none
build:
  pre_ci_boot:
    options: -v /app/public/assets
  ci:
    - export DOCKER_TAG=${ECR_REPOSITORY_URL}:${BUILD_NUMBER}
    - docker build --file ./docker/node/Dockerfile --tag amakan_node .
    - docker run amakan_node yarn run test
    - docker run --volumes-from ${SHIPPABLE_CONTAINER_NAME} amakan_node yarn run build
    - cp /app/public/assets/* public/assets/
    - docker build --file ./docker/rails/Dockerfile --tag ${DOCKER_TAG} .
    - docker run ${DOCKER_TAG} bundle exec rake test
  post_ci:
    - >
      if [[ "${BRANCH}" == "master" ]]; then
        sudo docker push ${DOCKER_TAG}
      fi
integrations:
  hub:
    - integrationName: ecr
      type: ecr
      region: ap-northeast-1
      branches:
        only:
          - master
  notifications:
    - integrationName: email
      type: email
      on_success: never
      on_failure: never
      on_pull_request: never
    - integrationName: slack
      type: slack
      on_failure: always
      on_success: always
      recipients:
        - "#shippable"

石川県の和倉温泉に合宿に行った

温泉地での開発合宿、通称シバ温泉ソンを敢行した。

予習

image

和倉温泉のある能登半島はアニメ『花咲くいろは』の舞台となった場所と聞いていたので、前日にTSUTAYAに入会してDVDを全巻借りて観ておいた。

京都駅から和倉温泉駅

image

サンダーバードに乗って終点まで行くと和倉温泉駅に着きます。最近だと新幹線で金沢まで行けるので、東京からも早い。意外と混んでいるので、デッキで立つ羽目になりたくなければ指定席を取っておいたほうが良い。ネットでJ-WEST会員になって早めに予約しておくと1000円ぐらい安くなります。

和倉温泉駅周辺

image

駅から温泉街までの数kmはこういう感じで、半島の海沿いにホテルが立ち並んでいる以外は、なんというかこう、土地が余っている。道の脇にいきなり70度の湯が湧き出ていたりする。

image

温泉卵を大量に抱えたわくたま君という恐ろしいキャラが居る。公園の奥に行くと海が見える足湯がある。

温泉街周辺

image

ドラクエのようなスポットがあり、最寄りの店で購入した生卵を投げ入れると十数分後に温泉卵が得られるというイベントが発生する。火を使わないレシピとして 温泉卵おき - #つくりおき にまとめられているので参考にされたい。

温泉

image

海が見える露天風呂がべらぼうに良かった……。

宿

image

5人で2部屋、2泊3日で朝夕付いて1人辺り17000円という民宿に泊まった。新MacBook Proのペタペタしたキーボードで畳で作業するとなんとなく腰が持って行かれる。

湯乃鷺駅

image

和倉温泉からのと鉄道に乗って、花咲くいろはの舞台となった無人駅があるので降りてみたところ。

image

これは、

image

ここ。

image

これは駅舎内にある可愛いポスター。

かき小屋

image

次の電車が来るまで駅の外でぶらついていたところ、かき小屋があり、生牡蠣・牡蠣フライ・牡蠣飯・焼き牡蠣をやった。たまたま降りただけなのに地元の人で行列が出来るほど賑わっていたのでこれは良かった。

ラッピング電車

image

5年前の作品だけど、未だに1日数本ラッピング電車が走っていて、今回はたまたまキャラクターが車内音声を担当してくれる便に乗れた。湯乃鷺駅のときだけ車内音声のテンションが高かったりして面白い。

アプリ

image

キャラクターが最寄りの観光名所の方角を指し続けてくれる上に、そこまで辿り着くと音声で案内してくれる上に、はいふりカメラみたいな感じで写真撮影も出来るという最高のアプリがあり、その辺をぶらぶら歩くのに使ってみて便利だった。京都アニメーションさんに京都用につくってほしい。

合宿成果

image

友人の集いという様相の合宿で特にテーマなどは決まっていなかったので、各位思い思いの実装をした。

自分はまずSlack Appの仕様を調べ、Amazon API GatewayAWS LambdaとNode.jsとTerraformを利用した、簡単なBotをつくる実験をした。これはそこそこ動くようになって、仕事でChatOps改善系のタスクに絡めて改善するつもり。WebSocketやXMPPを使うのではなくて、POSTリクエストを受け取るWebアプリケーションとしてChatter Botを実装できることと、API GatewayとLambdaの組み合わせでそこそこまともなWebアプリがつくれること、Terraformで上手く管理できること、全てのチャンネルで発言を受け取れるようなBotがつくれることが分かったのが良かった。

次に https://amakan.net/ の改善をやろうとして、amakanの亜種としてAmazon プライムビデオなどの視聴履歴を管理できるamakanビデオの構想を考えた。

それから、amakan全体でデザインのテイストを統一するために、これまで利用していた有料のCSSテーマを捨て、CSSフルスクラッチで書き直した。合宿中は、スマホとPCとで同じコンテンツを表示する方法について3日間延々と悩んでいた。PCはメインターゲットではなく、どちらかと言うとスマホ向けに最適化した方がメリットが大きいだろうと考えた。こうなるとPC用に表示したときにコンテンツが少なく寂しい印象になるんだけど、amakanとしては華やかな見た目で楽しませるよりも、シンプルなインターフェースで使いやすさを追求したサービスになる方が良いだろうと考えている。フロントエンド全て書き直したので数千行ぐらいの変更で、CSSgzip圧縮前で480kbから60kb程度に軽量化。

ちなみに2日前から新デザインに切り替わっている。いろいろと部品を共通化した恩恵で、作品を表示するどのページでも読んだ・読みたいボタンが押せるようになった。まだまだ土壌が整ったばかりという段階なので、ここから便利にしていきたい。

おわりに

今から花咲くいろはを見て、春に花見も兼ねて温泉に入りに行くのがおすすめです。

amakanをDocker化した感想

https://amakan.net/ のこの辺の改善の続き。


CIのビルドに時間が掛かるようになった

f:id:r7kamura:20170102230018p:plain

これはわりとしんどい。CircleCIのDockerのバージョンが古く、イメージのキャッシュをしづらいため、毎度新規にイメージをビルドしていることが原因。キャッシュが可能で、ビルド中にイメージを作成することができ、その作成したイメージでテストを実行でき、特定のブランチにおいてはそのままDockerレジストリにPushが可能で、環境変数の管理やチャットサービスとの連携が容易なサービスがあれば、それに乗り換えたい (Werckerとか?)。

デプロイしやすくなった

f:id:r7kamura:20170102225931p:plain

CircleCIでビルドされたイメージにそれぞれ番号 (タグ) が割り振られているので、その番号を指定すると、Amazon ECSが実行中のコンテナを数台ずつそのイメージに自動的に交換してくれる。なので、デプロイ時にやることとしてはDockerのタグを指定するだけとなった。わかりやすいので精神が楽になった。

ロールバックしやすくなった

コンテナの交換作業中に問題が起きた場合は、前のタグに戻すだけで前の状態に戻るようになった。配信する静的ファイルも全てイメージ内に置くようにしてあるので、その辺りも含めてすぐにロールバックできて嬉しい。

DBをMigrationしにくくなった

前までCapistranoを利用していて、デプロイ時に rake db:migrate が実行されるようにしていたが、これを自分でやる必要が発生した。まあCapistranoの場合でも、実行した直後 (からコードが切り替わるまで) にエラーが出ないように気を付ける必要があり、結局デプロイ前後どちらのコードでも新旧データベースに対応できるようにしつつ二度デプロイする必要はあったので、実際の差分としては「rake db:migrate を実行するコードを適当に自分で書く必要がある」ことぐらいだけど若干面倒。

ミドルウェアを変更しやすくなった

Node.jsはNode.js用のイメージ、RailsRails用のイメージ、というように複数のミドルウェアが1つの環境に共存することがなくなったので、互いに影響する可能性を考慮する必要がなくなり、バージョン変更などが楽になった。また、イメージを構築するときも単純なシェルスクリプトを幾らか実行するコードを書くだけなので、気持ち分かりやすくなった。

マシン資源の管理がやりやすくなった

f:id:r7kamura:20170102225902p:plain

同じインスタンスで複数の (異なる種類の) コンテナを動かすことも容易になり、あまりお金をかけられない個人開発でも手軽に節約できるようになった (手軽ではない節約方法は沢山ある)。例えばRubyのバージョンを上げるときでも、SidekiqはRuby 2.3 、Pumaは Ruby 2.4という構成にすることもできる。SidekiqとPumaが1プロセスずつ動くと、それぞれ250MBずつで合計500MB。デプロイ時にイメージを交換するために1コンテナ余分に動かすことを考えて、メモリが1GBあるインスタンスを利用しよう、という具合でリソースを管理できる。結果的にちょっとサーバ代が浮いた。

ALBが高い

浮いたサーバ台がちょうど相殺されてしまった……。

Docker for Macの時刻がずれる

スリープしてるとDocker for Macの時刻が遅れてしまう。TerraformをDocker経由で実行するようにしているので、AWSAPIを利用するときに署名に含めるタイムスタンプが古すぎてエラーになることがある。これはDocker for Macを再起動すれば直る。そもそも手元からTerraformを動かすより、CIで動かすようにしたほうが良さそう。

SSHが不要になった

実行中のサーバにSSH接続してローリングデプロイするようなことが無くなったので、SSHが不要になった。鍵の管理が必要なくなってだいぶ楽。

検証環境や別サービスがつくりやすくなった

似た構成のテスト用環境をすぐにつくれるようになったのが便利で、staging環境をつくれた。あと別のサービス用に似た構成をつくるときに、コードを真似て簡単に始められるようになったので気持ちが楽。