iPad Pro 10.5インチモデルを買った

今年の頭頃からiPad Proの12.9インチモデルが欲しいなと思っていて、でもそろそろ新製品が出るかも…ということで買っていなかった。

今回、新モデルが発売されて、友人が買った実機を触らせてもらい、その結果12.9インチモデルではなく10.5インチモデルを買うことにした。

目的としてはメモしたりポンチ絵を書いたりする時、紙の代わりに使いたいというものが大きい。なので、A4サイズの12.9インチモデルがよいと思っていたのだけど、ちょっとしたメモや絵、作業くらいなら10.5インチでも問題なさそうだった。平日は仕事用のマシンも持ち歩いているので、12.9インチはちょっと大きすぎるかも…という懸念もあったが、10.5インチならマシンと一緒に持ち歩いていてもそんなに気にならないサイズだと思う。


Apple Pencilを使うため、以前から気になっていたNote Alwaysというアプリをインストールして軽く試した。これはとてもいいね。書き味は紙とは違うけど、少しすればすぐ慣れると思う。それより、書いたり絵や文字を簡単にリサイズしたり移動できるのがめちゃくちゃいい。しばらく、ポンチ絵を書く時はiPadを使ってみようと思う。

Smart Keyboardも一緒にに購入したのだけど、これも結構いい。10.5インチ用ということで手に合わないんじゃないかと思っていたのと、以前から使っていたSurfaceProのキーボードが好きになれなかったのであまり関心がなかったけど、今日触ってみてこれなら使える!と感じたのだった。もちろん普段使っているキーボードとはキーピッチも打鍵感も違うけど、勉強会やちょっとした書き物なら問題ないかな。ちなみにこの記事もiPadで書いている。

SurfaceProを除けば、実は初タブレット。スマートフォンとPCで困っていなかったけど、本を読むならちょうどいいサイズなので少しずつ使う場面を増やしていきたい。セルラーモデルなので回線契約してSIM刺さなきゃなー。

ngx_mrubyを使ってコンテンツベースのルーティングを行ってみる

第35会 PaaS勉強会 で Amalgam8 というルーティングサービスが紹介されていて、ふとngx_mrubyを使えばこういうものを作ることはできそうだな、と思ったので試してみた。なお、今回のコードはtakaishi/ngx_mruby-content-base-routingに置いてあります。

今回は、以下の図のような構成とする。基本的にngx_mrubyはproductionサービスにアクセスを流すが、「X-Environment」に「STAGING」を指定した場合だけstagingサービスに流す。

 

curlを用いた応答は以下のようになり、ヘッダによってレスポンスが変わる。

 

これを実現するnginx.confが以下。ヘッダ情報を見て、条件に合致したかどうかでupstreamのサーバーを書き換えるような仕組み。

現在ロードバランサとしてnginxを使っているのであれば試してみてもいいかもしれない。いきなり専用のツールを使うよりは障壁が低そうだ。もちろん、Kubernetesのようなオーケストレーションに最適化されているかというとそうではないので、場合に応じて使い分ける必要はあるだろう。また、serverの切り替えを確率ベースにすればstagingに全体の1%だけアクセスを流す、ということもできそうだ。

 

OpenStack Heat再び

Terraformを使っているのだが、結構困ることもちょこちょこ出てきて、実はHeatの方がよかったのでは?という思いも出てきたりしているのでもうちょっと実践的な検証を行うことにした。OpenStackのバージョンはMitaka。

今回は、スケールさせるインスタンス群とそうではないシングルインスタンスを作成し、シングルインスタンスにはFloatingIPを付与する、という構成にする。インスタンス一覧はこのようになっている。

各リソースについて

main.yaml

メインはこのようになる。リソースはネットワーク類、スケールインスタンス、シングルインスタンス、シングルインスタンスへのFIP付与だ。パラメータとしては、スケールインスタンスの台数を指定できるようにしている。

ここで、”OS::Alpaca::Network” や “OS::Alpaca::Server” というタイプがあるが、これは独自に定義したリソースだ。Terraformのモジュールに似た機能といってよいだろう。独自定義リソースを使うには、”env.yaml”でリソース名とそれを定義したファイルを関連づける。詳細はドキュメントを参照するとよい。なお、拡張子が”.yml”だとうまく動かなかった。”.yaml”じゃないとダメなようだ。

OS::Alpaca::Network

必要なネットワークリソースを1つのリソースに定義した。素朴にネットワークとサブネットを作成し、Publicネットワークとはルーターを経由して接続している。

outputsでネットワークを参照できるようにしているが、これはサーバー作成時にネットワークの情報が必要なためだ。

OS::Alpaca::Server

次はサーバーだ。サービスで使うベースのインスタンスはって大体設定が共通なので、独自リソースで定義しておくと楽だ。サーバーにユニークな名前をつけようと思って、付与するIPアドレスを用いて「hoge-127-0-0-1」のような名前にしたかったが、うまくいかなかった。get_attrの結果を置換する方法が今のところないようだ。Terraformだと可能なのだが。

OS::Alpaca::AttachFloatingIP

次はサーバーにFIPを付与するためのリソース。本当は、OS::Alpaca::Serverのパラメータで「attach_fip: true」のようにするとFIPを付与するようにしたかったが、Mitakaだとconditionが使えなかった。newtonかららしい…これもTerraformだとできるので、Newtonにしたい〜!という気持ちになる。

OS::Alpaca::ServerGroup

最後はスケールさせるための独自リソース。OS::Heat::ResourceGroupとOS::Alpaca::Serverを組み合わせて、DRYにスケールさせるための記述を成立できた。これは今のところTerraformではできないことだ。

まとめと感想

より実際に使いそうな記述でHeatを使ってみた。次はCloudConfigを試すかなー。

  • 実行した時の差分がよくわからない。どう変化するのかがもうちょっとわかりやすく見られるとよいのだが…何かコマンドがあるのだろうか。サーバーが再作成されるのかどうかというのも分からないので実行が不安になる。
  • Horizonから実行履歴が見られるのはよい。
  • TerraformからHeatへ移行する場合、かなり運用フローを変えないといけないだろうと感じた。Heatを用いて複数人で開発するのはどうやるんだろう?

うーん、使ってみたらやはりTerraformなのかなー。移行するほどのメリットは感じられないかなあ。

mastodonで自分用のインスタンスを作った感想

ブームに乗っておくか〜、と思ったのと、使っている技術も割となじみのあるものであること、docker-composeで気軽に立ち上げられるようだったので日曜に軽く試してみた。

1人用なら、t2.microでもまぁ動く。本格的にスケールさせるならRDS、S3、ElastiCacheのようなマネージドサービスを使えば楽そうだ。ただ、自分がフォローした人の投稿しか見えず、負荷も高くないので使用者としても運用者としてもおもしろさは感じにくい。やはり、大量のユーザがいるといろいろ問題も発生して楽しそうだと思う。

mastodon自体は、mstdn.jpが移転する前にアカウントを作ってみていた。1ヶ月ほど前から諸事情でSNSをほとんど見ないようにしていてSNSに対する関心が薄れかけているので、mastodonでも何を投稿すればいいのだろうかと思ってしまった(これにより人付き合いがひどく減ってしまった気がするが…)。なので個人用インスタンスを作ってはみたけどそのうち消しそうだなあ。気軽に立ち上げられても運用は手軽ではないし。

cloud-initのドキュメントを読んだ

cloud-initのドキュメントを読んでいたのでメモ。なぜかこのドキュメントに今まで気づいていなかった…

今、スクリプトを書いて実現しているけどcloud-initのモジュールでもできそうなものがいくつかあった。

  • Growpart:パーティションを広げる
  • Phone Home:指定したURLにデータをPOSTする
  • Puppet:Puppetのインストールと設定、実行
  • Resizefs:ファイルシステムのリサイズ
  • Resolve Conf:resolv.confの設定

モジュールでできるならその方がすっきり書けてよいかなあ。