memori

Alternative facts

Google App Engine で PHP 7.1 を動かしてみるよ (Flexible Environment)

前提として、ローカル環境はこんな感じです

  • macOS 10.12
  • PHP 7.1.8 (homebrew/php/php71)
  • Google Cloud SDK 等導入済み
    • gcloud コマンド使用可能

ひとまず、Slim を使ってみることにします。

composer create-project slim/slim-skeleton try-gaephp7

これで、以下のようなファイルが作られます。

ls -1
CONTRIBUTING.md
README.md
composer.json
composer.lock
logs/
phpunit.xml
public/
src/
templates/
tests/
vendor/

今回はフレームワークの読み込みと、PHP バージョンの確認のために

src/routes.php を

<?php
// Routes

$app->get('/', function ($request, $response) {
    // Sample log message
    $this->logger->info("Slim-Skeleton '/' route");

    // Render index view
    return $this->renderer->render($response, 'index.phtml', [
        'version' => phpversion(),
    ]);
});

templates/index.phtml で

<p>PHP Version: <?= $version ?></p>

のようにしてみました。

ひとまずは手元で動かしてみます。 Slim の Skeleton からプロジェクトを作ると、 composer run-script start というコマンドでローカルサーバーが起動します。

http://localhost:8080/ をブラウザで開くとちゃんと動いているのが確認できました。

f:id:riaf:20170830121442p:plain

それでは、今度はこれを GAE の Flexible Environment で実行したいと思います。

まず、GAE の設定ファイル (app.yaml) を以下のようにしました。

runtime: php
env: flex

runtime_config:
  document_root: public

そして composer.json の php バージョンを PHP 7.1 系で動かしたいので "php": "7.1.*", と変更してみます。

nginx-app.conf も設置します。app.yaml と同じところに配置できる設定ファイルは他にもいくつかあります。 https://cloud.google.com/appengine/docs/flexible/php/configuring-your-app-with-app-yaml#the_runtime_config_section

location / {
  try_files $uri /index.php$is_args$args;
}

これで、gcloud app deploy --promote を実行すると、まあなんか色々聞かれたり答えたりしたのちにデプロイ完了しました

https://try-gaephp7.appspot.com

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

macOS

かわいいかんじになった

f:id:riaf:20161129152535p:plain

手順

powerline/fontpatcher と fontforge を用意

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)

PHP BEAR.Sunday

追記: 実行時に書かれるファイルは所謂キャッシュなので、生成後にデプロイすれば良いとのこと

  • 基本的にタイトルの通り
  • 所謂 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_instance の remote-exec だと、まだ外部接続が不可 (ポートフォワーディングのルールは cloudstack_instance 実行後ではないとつけられないため)
  • それならば、と cloudstack_port_forward のタイミングで remote-exec すると、ポートフォワードのルールを書き換えるたびに実行されてしまう

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

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

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

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