ノートPCを新調したりVPSを乗り換えたりした

なんか、最近、普段家で使ってるコンピューター周りを色々変えたのでそれについて書いてみる。

ノートPCを新調した

2014年頃のmacbook air 11inch から、色々悩んで2019年のmacbook pro 13inchのusb c端子が4つついてる方に乗り換えた。VMなどをそれなりに動かすことになるだろうと考え、メモリは16GB、SSDは512GBにした。
新調の一番の理由は、コタツを導入したのでコタツで色々できるようにしたかったけど、それには5年前のmacbook airでは主にメモリの量を中心に辛いと感じることが増えてきたこと。
新調にあたっては、現行の各種macbookはusb cしかついていないことが気に食わず、windows のノートPCにしようかなとも思ったのだけど、そうすると、ctrl + p,n,f,b あたりでのカーソルの移動ができない場面が増えてストレスを溜めるのだろうなぁと思ってしまったので、結局macにしてしまった。

usb cについては、実はあんまり外に何かを付けて使うということ自体がないけれど、もしもつけたとしても、電源やら画面やらを1本のケーブルにまとめられて、今はもう便利だとしか思わない。
昔は、usb cからいろんな端子に変換するための変換器みたいなのの種類が少なかったり値段が高かったりで大変だったみたいだけど、2019年だともうそんなでもないのかなと思った。

そんな感じで、家に帰ってきてもコンピューターいじるときは机と椅子に座ってガッツリと向き合うしかなかった状態が、こたつで緑茶でも飲みながらのんびりと色々する、みたいに変わった。

あと、結構前だけどテレビにkindle fire tv stickを刺した。なので、家族と一緒にスマホで撮った写真をみたり、webページを一緒に眺めたりといったときも、kindle fire tv stick に Air Playで接続してさっさとテレビに画面を表示できるようになった。これが想像以上に便利で、テレビは見るだけのものから、家族の間で情報を共有するための道具に変わってきたな、みたいな意識の変化があった。

windowsのノートPCを選んでいたら、Air Playではなくmiracastで画面を表示することになると思うんだけど、miracastについては使ったことがなく、どの程度使い勝手が良いものなのか知らない。実際のところどんな感じなんだろうか。

VPS乗り換えた

かれこれ7年くらい、sakuraのVPSを何度かインスタンスのタイプを乗り換えつつメインで使い続けてきたけど、支払いが月極なので、遊ぶ際にインスタンスを新しく作ったり破棄したりといったことがやりづらくて辛いという理由で、色々お試しするときののVPSについては別の海外のVPS業者の日本リージョンを併用している状況が1年ほど続いていた。
(sakuraにおいて、インスタンスを上げたり壊したりといった用途には、おそらくsakuraのVPSではなくsakuraのクラウドが想定されている。だから、自分がsakuraのVPSがターゲットとする客ではなくなってしまったので辛いという話であって、sakuraのVPSのサービス内容が良くないというわけではないと思う。)
海外VPSを1年使って、これと言ったトラブルも特になかったため、sakuraの方は引き上げ、海外VPSの方に一本化した。
もともとsakuraにメモリ2GBのインスタンスが1台、海外VPSの方にメモリ1GBのインスタンスが1台あったが、これを4GBメモリの海外VPSに1台にまとめた。
値段的にはsakuraのメモリ2GBと海外VPSのメモリ4GBが同じ価格だったので、月々の支払いは減ることになったし、管理対象も減ったし、いい感じだなーと思っている。

引っ越しにあたり、勉強も兼ねて、ホストOSの上にソフトを色々インストールするのは控え、全部dockerコンテナの中に入れた。全部のサービスをdocker-composeで管理するようにした。
結果として、自分がどういうサービスを立てているのかということが明確になって、覚えておかなきゃいけないことが減ったので良かったなぁと思った。

あ、なので、このblogも実はお引越ししたあとだったりします。なんとなくテーマも変えました。

k8s のクラスタを組んでその上に全部移すということも考えたけれど、自分が動かしっぱなしにしておきたいアプリケーションの総量に対して、k8s 自体の主にメモリに対するオーバヘッドが大きすぎてなんかもったいない気がしたというのと、スケールアウトしなきゃいけないほど上で動くアプリケーションが増えたり減ったりするわけでもなく、コンテナ冗長化をかっこよく行う必要も特にないなーと思ったので、シンプルにdockerとdocker-composeで全部済ませてしまうことに今回はした。
k8s がこなれてきて、オーバヘッドがあんま気にならないくらい小さくなってくるというか、オーバーヘッドが小さい構成も手軽に組めるように状況が整ってきて、自分自身がそれを使いこなすノウハウがこの先数年で溜まったら、k8sベースにすることもあるのかもしれない。と思う。

なんかまぁ、そんな感じです。
全部コンテナに入って取り回しが良くなったので、調子よく色々やっていきたいなー。

複数マシン間で、atomで取ったメモを同期するための環境を整えた

自分は、いろんな作業をするときに、人に報告したり、twitterに書いたりするほどでもないことを、atomを使ってmarkdown形式でメモをとりながら進めています。
1台のマシンでメモを取るだけなら、シンプルでいいんですが、VMを含め、複数台のマシンを行ったり来たりしながら作業するとなると、これらの間でどうやってメモを同期するか、という点が悩ましくなってきます。
今回のエントリは、どうやってatomを用いて、複数のマシンでどうやってメモを同期させるか考えたっていう、そんなお話。

TL;DR

atomのsync-on-saveはとても良い
WindowsとLinuxだとパッチ当てないと動かない(2017年10月12日時点)

gitでメモの同期をとりたい。でもコマンド打つの、面倒だな。

ファイル単位で同期を取る仕組みというのは、atomには色々あって、たとえばRemote-FTPというパッケージで実現することができます。
最初はこれを使っていたんですが、同期の粒度がファイルだと、複数のマシンで同じファイルを変更したときに、どちらかがどちらかをうっかり上書きして、せっかく書いたメモを失う、なんてことになりそうだなと思いました。
実際に上書きをしてしまったことはなかったものの、そういうことが起こりうるということを意識しなければならないのがなんとなくストレスでした。

だから、ファイルよりも小さい単位で同期を取りたい。
そうだ！僕達には、gitがある！gitを使おう！と考えました。

でも、gitも、コミットメッセージを書いたり、共有のためにpushしたりと、やらなければいけないことが多くてちょっと面倒です。

sync-on-save というパッケージに面倒事を引き受けてもらう

どうせ、自分が適当に見るメモなんだから、コミットメッセージなんて適当に自動でつけてくれればいいし、pushも勝手にやってくれればいいのに。
そんなパッケージないかなー？と探してみたところ sync-on-saveというパッケージがありました。

このパッケージを使って救われました。本当に欲しいものそのものでした。
コマンドパレットからEnable Syncすると、ファイルを保存したタイミングでgit commitとgit pushを自動でしてくれます。
あとなんか他の場所で同じファイル編集してたらmergeもしてくれる。

本当に便利だ。素敵だなぁ。

LinuxとWindows向けにバグがあって動かなかった→なおした

バグを見つけたので直しました！バージョン0.1.5からは何も考えずにATOMのパッケージをインストールすれば使えるようになりました！
みんな使ってみてね。

2017年10月12日時点でダウンロード可能な、バージョン0.1.4にはちょっとしたバグあり、WindowsとLinuxでは動きません。
直したのでプルリク投げてみるつもりです。

差分は1行なので、これ読んで今すぐ使ってみたい！って思った人は、sync-on-saveをインストールした上で、コードを直接いじるのが楽そうです。
コミットの情報はここにおいときますので参考にしていじってみてね。

https://github.com/sirrow/sync-on-save/commit/7df50d7094156b9fd030ab698a6ff69a680177af
おしまい。

本文に書ききれなかったけど書きたかった事

sync-on-saveを作った人について

sync-on-saveを作った人すごいなぁ、ありがたいなぁ。プルリクも投げなきゃいけないし、どんな人なんだろう？って思ったので調べてみたら、 Hajime Morita さんでした。
そういえば、rebuild.fm 聞いたことないし、今度聞いてみよう。

昔はssh + screen + emacsでメモを取ってた

自分は一昔前は、VPS上でscreenを動かして、その上で動かしたemacs -nwに、色んなマシンからsshでログインした上でattachしてメモを取ってました。
これはこれで悪い方法じゃなかった気がします。手軽だしね。ただ、ネットワークから切断されるとつらいんだこれ。
gitなら手元にコピーあるからネットワークなくても編集できるしね。そんなところが素敵。

タスク管理をtrelloからOpenProjectに変えようかなと思ったけど結局redmineにした話

今回の移行に当たって考えたことのまとめから書いておく

Wrikeは最高だけど、高すぎて厳しい。
OpenProjectは貧乏VPSには性能面で辛かった。
結局Redmineしか選択肢がなかった。
RedmineをDockerでインストールするとプラグインのインストールが辛かった。

ことの経緯

自分は生きるのが下手で、タスク管理やスケジュール管理がうまくできず、どうやってこれらをやっていくのかということについて色々試行錯誤していたりします。

昔はredmineで何でもかんでも管理することで落ち着いていたのですが、

タスクの数が増えてきた時にごちゃごちゃしてくる
自力でホスティングするのめんどくさい
UIが前時代的で辛い

あたりが理由で、trelloに移行していました。
子供が生まれてあんまり難しいことを家でやらなくなっていたので、シンプルな使い勝手のtrelloがとてもいい感じでした。
ただ、このところ子供がある程度大きくなってきて、自分が色々する時間も取れるようになってきたので、何か新しいことをしようと思った時に、タスクの入れ子が1段階しかできないtrelloだと複雑なことをしようとしたきのタスクのドリルダウンがしづらくて窮屈に感じられるようになってきました。

なので、タスクの入れ子現実的な範囲でいいので入れ子にできることを条件に色々探して見ました。

Wrike試してみた

2017年っぽいUIでスッゲー使いやすくて、これにしようって思ったのですが、試用期間が終わると、Freeではタスクの入れ子ができないので今回の要件に合わない。
けど課金額はどうだ？と思って調べて見たところ、課金は1人あたり月 $5と書いてあったので、$5ならVPS1つ借りるのと同じだしいけるんじゃないかと思ったんですが、5人ぶんまとめて契約しなきゃいけないらしく、1人で使うとしても月$25になってしまって辛いということが判明し断念。

すごくつかいやすいのに。もうちょっとカジュアルに使える価格設定だったらよかったのになぁと後ろ髪を引かれつつ使うのをやめました。

OpenProjectを試してみた

自力でホストしてもいいので何かいいものないかなぁと思って探して見たところ、最近はOpenProjectというOSSのプロジェクト管理ツールがあるという情報に当たったので、試してみようと一念発起。
公式でdocker imageが用意されていたので、これを利用しようとGoogle Compute Engineに1番安いインスタンスを立てて、dockerホスティング用のイメージを起動。その上にインストールすることを試みました。
が、なんかインストールがコケる。

インストールの感じを見ていると、どうも、dockerのイメージがでかいらしく、ディスクを使い切ってしまっていた模様。
なるほどね、と思って手元のPCのLinuxのVM上にdocker環境を整備してそこに入れてみたらいい感じで動いた。

Wrikeほどの使い勝手はないものの、RedmineよりはちょっぴりモダンなUIで、これでいいんじゃないかと思ってメモリの使用量を軽くチェックして見た所、起動するだけで1.2GBほど使う模様。
なんか、dockerのイメージ内に、サービスの本体であるRubyだけでなく、postgresやmemcacheも含んでいた。なるほど、イメージがでかいわけだ、とある程度納得。
しかし、メモリ使用量がこれでは、やすいVPSやクラウドインスタンス上に立てっぱなしに使うってのは若干厳しい。

とはいえ、ものは試しだと思って、昔契約した2GBのメモリが使える海外の安いVPSにインストールしてみた。
そしたら、起動はちゃんとしたものの、めちゃめちゃ重たい。
多分、ブラウザとサーバ間のレイテンシが何倍にも重なってUIの表示に効いてくるような作りになっているんだと思う。（未検証）

となると、手元のVMや家の中に置いたサーバーで動かすにはいいけど、外に置こうとするとレイテンシが辛くなってしまうな、ということで、これも不採用。

Redmineに戻ってきてしまった

色々不自由な点もあるけど、軽いし、もうredmineでいいや　ということで、Redmineを改めて使い始めることにしました。
インストールはdockerで気軽に。アップデートもきっと手軽にできるでしょう。
いい時代だ。

Dockerでインストールした時にプラグインどうするんだ問題

Redmineには、プラグインが存在しています。いくつかのプラグインをDockerでインストールした手前、コンテナの中に踏み込んでプラグインをインストールするのはなんだかダサい気がしました。なので、自分でプラグイン用のDockerfileを書いてプラグイン類をインストールしました。
複数のプラグインを入れるのでそれぞれのDockerfileは分割して作成しました。
Dockerfileは、ベースとなるイメージの名前とバージョンを指定して、このイメージにどういうファイルを追加するのか、どういう風に起動するのかといった情報を追加して行くという書き方をするようになっています。

例えば、2つのプラグイン（それぞれプラグインAとプラグインBとする）をインストールするために
公式Redmineイメージ -> プラグインA追加イメージ → プラグインB追加イメージ
という順番でイメージを拡張するとします。
この時、プラグインA追加イメージを作るためのDockerfileには、ベースとなるのは公式Redmineイメージですよと書いてありますし、ブラグインB追加イメージを作るためのDockerfileにはベースはプラグインA追加イメージですよと書かれています。
なので、例えば、上記の状態から、やっぱりプラグインAが不要だから、プラグインAを取り除こうと思っても、単純にプラグインA追加イメージを作成しないだけではダメうまくいきません。プラグインB追加イメージ作成用DockerfileにあるベースとなるイメージをブラグインB追加イメージから公式Redmineイメージに書き換えないといけないという手間があります。

そんな感じで、若干、長く管理できるんだろうか、大丈夫なんだろうかという疑問は持ちつつも、とりあえずDockerでやっていこうということに決めました。

ちなみに、プラグインは、easy gantt plugin(free) と Time Loggerだけ使ってます。シンプルに。

プラグイン追加後のDockerイメージをdockerhubにアップしておこうかなとも思ったのですが、easy gantt plugin が GPL v2にも関わらず、ソースコードは配布して欲しくなさそうなので自重。プラグインダウンロード用のワンタイムのURLを生成したり、そもそもgithubあたりにも置いてなかったりして、長く使い続けられるのか若干不安。ただ、そういった不安に目をつぶれるくらいeasy ganttでredmineは使いやすくなるので使っていこうと思います。
easy gantt freeは、ソースコード開示をしぶったりせず、最初からインストール済みのDockerイメージを配布しちゃえば、試してくれる人、買ってくれる人増えるんじゃないかなって思ったりするんですが、そうでもないんですかねぇ。

それよりも、easy redmineのホスティングサービス売りたい感じなのかなぁ。

ConoHaのAPIを叩く・・・のは面倒くさかったのでnovaコマンドを使ってみた。

ConoHa VPSのインスタンスをコマンドラインから操作したい！

こんにちは。先日、ConoHa VPS上にVDI環境を作ったよ！という日記を書きまして、結構いい感じに実用しております。

で、先日作った環境だと、起動や終了のためにウェブブラウザを使ってConoHaのポータルを開いてマウスでポチポチするひつようがありまして、それってちょっと面倒くさい。起動や終了やイメージの作成なんかを自動化したいなぁとおもうのは人のサガでありまして、なので、APIを叩いて、コマンドラインツールを作ろうかなぁ、などと思ったのですが・・・

Conoha VPSはOpenStackベースだからOpenStack向けのコマンドラインツールが使える！

よくよく考えたら、ConoHa VPSは、OpenStackというOSSのクラウドを作るためのソフトをベースに作られているので、OpenStack用に作られたコマンドラインツール群を用いてある程度コントロール可能なはずです。なので、まずはOpenStack用のコマンドラインツールのうちVMの起動、停止、削除などを行えるnovaコマンドについて試してみることにしました。

novaコマンドとは

OpenStackは、幾つかのサーバで構成されています。それぞれのサーバはAPIを公開しています。このうち、VMを起動したり停止したり削除したりといった操作を行うサーバをnovaと呼びます。novaコマンドは、novaのAPIを叩き、novaの持つVMを起動したり停止したり削除したりといった機能を呼び出します。

novaコマンドのインストール

OpenStackを構成するサーバや、これらのサーバを操作するためのコマンド群をインストールする方法には、いくつかあります。今回は、手元にある環境がCentOS 7.1だったため、RDOと呼ばれる、OpenStackをインストールするためのyumレポジトリに置かれているrpmのパッケージをインストールすることにしました。CentOSやFedoraならこの手順で大丈夫なはずです。

sudo yum install -y https://www.rdoproject.org/repos/rdo-release.rpm
sudo yum install python-novaclient

これでnovaコマンドがインストールできました。

ちなみに、UbuntuにはUbuntu OpenStack Installer が用意されていますし、pipのパッケージとしても公開されているので、好みに応じてインストール方法は選べそうです。

novaコマンドの設定

環境変数に設定されている値を使うので設定します。必要な情報はConoHaのダッシュボード右下のAPIボタンのところを叩けば参照したり設定したりできます。

export OS_USERNAME=APIユーザのユーザ名
export OS_PASSWORD=APIユーザのパスワード
export OS_TENANT_NAME=テナント情報のテナント名
export OS_TENANT_ID=テナント情報のテナントID
export OS_AUTH_URL=https://identity.tyo1.conoha.io/v2.0

以上をファイルに書き込んでおいて、必要に応じて読みだすようにすると楽だと思います。

novaコマンドを使ってみる

novaコマンドを実行すると、どういうオプションがあるのか色々表示できます。

起動したり、削除したり、リブートしたり、イメージを作ったりなど先日のVDI作成エントリで必要な操作は全部コマンドラインから実行できることが確認できました。これまでブラウザからしなければならなかった作業がコマンドラインからできるようになりました！これでちょっと楽になりました。

インタフェースを守ってくれているConoHaの中の人に感謝！

おそらく、ConoHaではOpenStackのコードをそこそこ変更していると思うのですが、それでもAPIを変更せずに守ってくれているおかげで既存のツールを使えてとてもありがたいです。

中の人たちに感謝しつつ、OpenStackを前提としたエコシステムのありがたみを享受して楽しく生きていきましょう。

以上です。

VDI環境をConoHa上に作った、その理由。

安くVDIを実現したい！

お小遣いに悩めるIT系サラリーマンの皆様こんにちは。
最近は、容量が小さいSSDを積んだノートPCが多くて、なんだか困りますよね。
ホストに入っているOSがWindowsやOS Xなのだけど、Linux環境が欲しい！でも、SSDの容量が小さいのでVMを作ってディスクの容量をガバガバ食うのはちょっとつらい。
かと言って、新しいPCを用意してそこにリモートアクセスするのも、PCを買うのも電気代もかかっちゃって、なかなか厳しい。
と言うシチュエーションはまま有ると思います。というか、僕自身がそうですしね。

そこで、考えてみました。クラウド上に開発環境を作ればいい！と！思いつきました。
でも、クラウドに置いたLinuxのインスタンスにはsshでアクセスして、emacsやvimで開発するんでしょ？ちがうんだよ！IntelliJやsublimeみたいなもっとリッチな環境が使いたいんだよ！という人、多いと思います。
と言うか、僕自身がそうですしね。

というわけで、いろいろ試してみたところ、ConoHaのインスタンス上にTigerVNCを用いてアクセスすることで、安くVDI環境を構築できたので紹介します。

なんでConoHaを選んだのか

インスタンスの料金体系がVDI向き

ConoHaのインスタンスは、1時間刻みで課金されます。
お小遣いに悩めるIT系サラリーマン的には、開発環境は常時起動しているわけではありません。
例えば、仕事から帰ってきた後とか、土日だけとか、限られた時間、安く使えることが大切なのです。
なので、細かい粒度で課金してくれるConoHaはとてもこういった用途に向いているな！と思うわけです。

50GBまでディスクイメージの保存にお金がかからない

これがけっこう重要なポイントで、一般的なクラウドでは、インスタンスの電源を切っても削除しなければお金がかかりつづけます。
インスタンスの削除を行うと、一緒にそのインスタンスで用いていたディスクのイメージも削除されます。
したがって、インスタンスを削除し、課金を止めるためには、ディスクのイメージのバックアップを取得する必要が有ります。
ConoHaでは、このディスクイメージバックアップが50GBまで無料です。
そして、インスタンスが用いるディスク容量は低スペック～中スペックくらいのものは50GBです。
なので、ディスクイメージを無料でバックアップすることが可能です。

したがって、
インスタンスの停止　→　ディスクイメージのバックアップ取得　→　インスタンス削除
という手順を踏むことで、ディスクイメージを保持したまま課金を止めることができます。

また、インスタンスの起動時にバックアップイメージを書き戻して起動することが出きるので、
インスタンス削除時の環境を取り戻すこともできます。

必要に応じて性能が選べる

インスタンスをバックアップイメージから書き戻して起動する際には、以前に用いていたインスタンスと異なる性能のものを選ぶことができます。
したがって、普段は最低スペックのものを用いておき、必要に応じて、高性能のインスタンスを選ぶことで、簡易に性能向上が可能デス。

SSDが乗っている

人間が直接扱う環境に関しては、CPUが早いよりもSSDが乗っていることのほうが体感速度に影響は大きいと思います。
ConoHaは全部のインスタンスがSSDで動いているので、人間が快適に使うのに向いていると考えます。

日本国内にホストされている

VDIはネットワーク越しに用いるものなので、手元の環境からホストされているインスタンスまでのネットワーク的な距離、主にレイテンシが重要になります。
ConoHaは国内にインスタンスをホストしてくれるため、レイテンシを小さく抑えることができます。

まとめ

以上の理由で、安くVDI環境を構築するのに、ConoHaは向いていると考えます！
このエントリも、ConoHa上で起動した最低スペックのインスタンス上のIntelliJ IDEAで書いています。
まったく何の問題もなく使えています。
新しい開発環境は欲しいけどどうしよう・・・と悩んでいる方、
ConoHaはユーザ登録すると、いくらか分か無料で使えますので、ぜひ試してみてくださいね！