memori

ちょっとだけ技術的なことをメモ〜

Terminal のフォントを San francisco mono + powerline にした

かわいいかんじになった

f:id:riaf:20161129152535p:plain

手順

powerline/fontpatcherfontforge を用意

ghq get powerline/fontpatcher
brew install fontforge

SFMono にパッチ当ててインストール

cd ~/Library/Fonts
fontforge -lang=py -script ~/.ghq/github.com/powerline/fontpatcher/scripts/powerline-fontpatcher /Applications/Utilities/Terminal.app/Contents/Resources/Fonts/SFMono-Regular.otf

簡単だね!

BEAR.Skeleton で作ったアプリケーションでファイル書き込みをしたくない (WIP)

  • 基本的にタイトルの通り
  • 所謂 PaaS とかの環境とかで動かすには、アプリを実行するときにファイルシステムに書き込みをして欲しくない
  • あんまり時間がないので、息抜きにマイペースに調べてつつ回避を試してみよう
  • 毎度ブログ記事にする余裕はないので、とりあえずこの記事を編集しながら作業進めてみよう

現状の見解: 依存パッケージがそれぞれカジュアルにファイルを書く傾向にあるので排除するのは難しい

調べてみる

  • 基本的には BEAR.Package がベースになっていて、そこの Bootstrap で AppMeta が作られるので、AppMeta でまずは mkdir が呼ばれてしまう。
  • ということは、bootstrap/bootstrap.php$app を作るときに独自の AppMeta を使って作るとまずはスキップできそう
  • 試しに
<?php
class MyAppMeta extends \BEAR\AppMeta\AppMeta
{
    public function __construct($name, $context = 'app')
    {
        $appModule = $name . '\Module\AppModule';
        if (!class_exists($appModule)) {
            throw new \BEAR\AppMeta\Exception\AppNameException($name);
        }
        $this->name = $name;
        $this->appDir = dirname(dirname(dirname((new \ReflectionClass($appModule))->getFileName())));
    }
}

route:{
    $appMeta = new MyAppMeta(__NAMESPACE__, $context);
    $app = (new Bootstrap)->newApp($appMeta, $context);
    /* @var $app AbstractApp \BEAR\Sunday\Extension\Application\AbstractApp */
    $request = $app->router->match($GLOBALS, $_SERVER);
}
  • としてみたが、今度は Ray.Compiler がファイルを書けなくてコケるようだ
  • 思いの外根が深い雰囲気出てきたな...

ngx_small_light を組み込んだ nginx パッケージ作る

ちょっと試してみたくてやってみたけど、 動かしてみたら、Docker 案件だったなって思った。

github.com

ただ作るだけならコマンド一発になった。

vagrant up

使い物になるかどうかっていうと、また別問題だし、 あちこち決め打ちすぎて何かのバージョンが変わると動かないだろうから、もう少し頭よくやる必要がありそうでした。

IDCF クラウドの環境を terraform で構築したい

と思っているんですが、 ちょっと悩ましい問題があるんですよね。

  • Atlas + Terraform で構築したい
  • GitHub で tf ファイルを管理したい
  • サーバー追加時に初期セットアップもやりたい (ベースになるパッケージのインストールとかユーザー追加とか)

Atlas+Terraform+GitHub でインフラを用意することはできても、初期セットアップをどこでやるかという問題があって、

  • cloudstack_instanceremote-exec だと、まだ外部接続が不可 (ポートフォワーディングのルールは cloudstack_instance 実行後ではないとつけられないため)
  • それならば、と cloudstack_port_forward のタイミングで remote-exec すると、ポートフォワードのルールを書き換えるたびに実行されてしまう

素直に Packer で準備したものを配布しろよっていう気もするけど、Packer もどうせなら Atlas でビルドしたい。そうすると、IDCF のテンプレートには OVA しか使えないので厳しいという新たな問題が。

cloudstack_instanceremote-exec 実行中に次の cloudstack_port_forward も実行してくれると嬉しいんだけど、現状だと素直に待ち続けてしまうっぽくて、繋がるのを待つ、ということもできないし、あまり綺麗な解法が思いつかないなあ。

ベースになる VM は手動で立ててしまって、そこを Bastion Host として実行するのがいいのかな〜。うーん。


Packer でビルドした後のものを ovftool で変換し続けるだけのサーバーを用意してもいいのかもしれない。

結局 PHP

巡り巡ってやっぱり PHP が最適なのでは?という答えになることがよくあります。