herokuでphp動かすためのDockerイメージを組んだ

「herokuでDocker使えるよ」って言うから試そうとしたらハマった - 大好き!にちようび というものを書いたじゃないですか。 あれ以来、「一旦Container registryでやるの諦めてアプリケーションだけ書いちゃおう・・・」となり放置、さらに他のことに浮気をしたりが重なりアプリケーション自体も書いていなかったのですが。

他のことが消化されたり、というのもあったので「久々に作るかー」となり起動したのでした。

で、結論、できた。

ということで、かなり参考にさせていただきつつphp72のものを組めた。今の所、php:7.2-fpm-alpineをベースとしてnginxを足した感じ。

o0ho0h/heroku-php72-fpm - Docker Hub

これを使って、例えば「PostgreSQLとxDebugを足したものを作りたいな」となったら、次のようなDockerfileを用意すれば立ち上がるしHerokuに載せられる。

FROM o0ho0h/heroku-php72-fpm
RUN apk add --no-cache \
    $PHPIZE_DEPS \
    postgresql-dev \
    && docker-php-ext-install pdo pdo_pgsql \
    && pecl install xdebug \
    && docker-php-ext-enable xdebug

ENV COMPOSER_ALLOW_SUPERUSER=1
COPY ./webapp /var/www/html
WORKDIR /var/www/html
RUN php composer install -o

構成イメージはこんな感じだ。

$ tree -L 2
.
├── Dockerfile
├── docker-compose.yml
└── webapp
    ├── composer
    ├── composer.json
    ├── composer.lock
    ├── index.php
    ├── public
    ├── src
    └── vendor

composerは本体をgitに入れて管理させちゃっても良いか、と思ったので入れてある。デプロイ周りの整え方によっては、composer/composer - Docker Hubを使っても良いかもしれない。

実際のアプリケーションを作ってみながらコチラも整えていこう、という気持ちでいるのでまずは「動くところまで」という着地。最終的には、気になっているところをちゃんと取り除きたい。
いま気持ち悪いのは以下

  • rootのままになっている。 docker-nginx-php-fpm-heroku を見ると ADDUSER はしているのだが、USER nonroot とはしておらず、さて・・?という疑問が。
  • 近い問題で、herokuでの起動時にfpmでの user group` ディレクティブが注意される。「superユーザーで実行しない限り効かないよ」と。無指定にすればlocalでの起動に失敗するので、今の所「書いておく、herokuに怒られているけど仕方ない」みたいな割り切り
  • run.sh に乗せている内容を、どうにかDockerfileに持ってこれないものか。理由としては、ベースイメージのCMDの中で実行される内容が肥大化すると、自分のDockerfileに細やかな処理が書きにくくなりそうじゃない?と思うから。

はぁ、それにしても「同じイメージをそのまま使える」のマジで便利。すごいと思う、革命や・・・ 前回apacheでうまく行かなかった理由は相変わらず謎のまま〜〜

Redash Meetup 3.0.0に参加しました #redashmeetup

もう1週間前のことですが。
たまたま知り合い経由で主催の id:ariarijp さんにお声がけをいただいて、Redash Meetupの第3回でお話をしてまいりました。

会全体的な振り返りは、こちらにまとめてくださっているので。 ariarijp.hatenablog.com

発表しましたですよ

で、わたくしめの話した内容はこちらの「minnaka-redash-wo-qi-chi-tiyokushi-uyarifang-wo-kao-eru-number」でございます。
speaker deckの生成するJP->ENなURL、好き。

speakerdeck.com

もともとは tech.connehito.com の記事を書いた時に「こういう内容、meetupで話してみたらどうですか!」と言われたのがキッカケだったので、エントリーの内容を肉付けしたり削ったりして組んだのが今回の発表内容。
正直なところ、これを以てウチの組織で「めちゃくちゃ上手く行っていて快適、ユートピア!」なんて状態はまだほど遠いのだけれど・・・

↓1番思うところはココでありまして。

f:id:o0h:20180711101342p:plain

当日、お話を聞いてくださった方々ありがとうございました。
人の前で話すの久しぶりすぎて、自分のターン終わって着席後に貧血ぽさ&吐きそうになったのは秘密です。

登壇内容で持ち帰ってきたもの

自分としてはAPI経由の操作やQueryRunner等「Redash自体の拡張」というのに手を出していなかったので、お話をされていた他の3名の内容が結構ビシビシ刺さった。

クエリのバックアップ/差分管理・・・そういうのもあるのか・・・とかビックリしたり。

JQL(mixpanel)のQuery Runnerとか書いてみたいな・・・JQL叩くとかチーム内で自分くらいしか使っていないけど、それにしたって自分が叩くのだから欲しい・・・。あとJS/JQL知識はあるのに!みたいなメンバーはいる状態なので、「pythonでリクエストしたり整形しなければいけない」というのが余計。これを是正すれば活用度合い広がりそうなので。やるかぁ。。

"Redash運用に付きまとう課題とその解決方法"が 「未来の話」ぽくて良かった

それとは別観点で、エウレカ大久保さんの話が、自チームよりはるかに先のステージで戦っている!!感があってとてもおもしろかったんですよ。なるほど、そうやって対処していくのか〜的な。

「課題は組織文化・規模等においてケースバイケースだと思う」というのは自分の発表においても述べたとおりなので、同じやり方をそのまま引っ張ってこれるか?についてはNOだと思うけれど。あと、例えば「命名規則管理」は結局・・・みたいな話も御本人がされていたので、これは「minnaka-redash-wo-qi-chi-tiyokushi-uyarifang-wo-kao-eru-number」のテーマとは確かに真っ向に立場を異としているよね!とか。

その中で、じゃあお前は何が「刺さった」といっているのか?というと、「Redashと周辺ツールの組み合わせ方」みたいなところで。
当然ながら「RedashのQueryをAPI経由でSpreadsheetに食わせられるよね」みたいなところは知っていたのだけども。Redash単体だと「ダッシュボード作成のために、似たようなクエリを複数書く必要がある」とか「簡単な集計をビジュアライズに含めるためにソース側に都度集計列を足す必要があったり」「PivotTable含め、集計結果を加工したものを用いてビジュアライズすることができない」とか。 これらが、「データソースから引っ張ってくる部分」と「ビジュアライズのための集計処理をする部分」と「ビジュアライズをする部分」が分離されるような構成にする事で、とても楽になるなぁ〜・・・・・と。*1
「知見や視点を1箇所にまとめたい」がためにRedashは魅力的なので、運用を考えないとなぁとは思うけれど、それでも「SpreadSheetに投げる」は納得感があり良さそうと感じた

あとは「古いクエリによる誤った情報の引き出し」も、たしかになぁ。。

その他、真似したいなぁ〜と思ったのは「ビジュアライズするときの色の使い方等のルールを定める」とか。「男性を表すのが、ものによって赤だったり青だったりすると混乱する」は確かに・・

懇親会で感じたもの

当然ながら自分が話したのが「運用どうしていくか」というものだったので、立ち話も運用どうですか〜〜みたいな話題も多かったのだけど。どの会社も大変そうだ・・w

  • データ分析専任ぽいファクターがあるところはまだまだ少なそうだけど、情シス的な機能や社内ツール的な機能を持つエンジニアが「データ出し」を代行したり管轄していたりすることが多いのかなぁという印象
  • 「非エンジニアがばりばりSQL書く」みたいなのはやっぱりハードルがありそう、そこに達しているだけでも結構恵まれている感じ
  • 「どのくらいの数のクエリやキィーがあるか」「触っている人数がどのくらいか」で求められているものが全く違いそうだな、と改めて

とかかなぁ

企画と会場提供とてもありがとうございました!

個人的にはずいぶんと久しぶりな勉強会登壇で、本番までずいぶんと気が重かったのですがw
発表してみたら会場の方々が温かい雰囲気で聴いてくださってよかった〜
そして会場がすごくキレイでおしゃれだった・・・アレほしい・・・

ということで、主催の有田さん・会場のエウレカさんありがとうございました!!
何かおもしろ知見溜まったらどっかでまた発信したいなー

*1:とはいえシズル感のあるダッシュボードを組むには、やっぱりTableauやDataStudio、もしくはRedash4.x的な「ダッシュボード作成」のための機能がほしいな〜とは感じつつ・・

「herokuでDocker使えるよ」って言うから試そうとしたらハマった

Heroku container registryっていうのができたんだ!!っていうから、喜び勇んで飛びついた俺たちは・・・

php:php72-apacheでやろうとしたが、「MPMモジュールが複数あるから!!」などと言われ、そのままでは使えず。

ログを見ると、

AH00534: apache2: Configuration error: More than one MPM loaded.

となっている。 しかしそのイメージはローカルだと正常に動いたんだぜ!!という気持ち。 heroku run zsh --type=web で、コンテナに入れるよ〜っていうから見てみたら確かに、思っていたんと違うファイルがある。。。mods_enabledの中身が違う。

謎すぎて心折れた

俺がPHP環境作っていてXdebugが動かない(DBGpからのコネクトバックが来ない?)と思った時のメモ

掲題のとおりです作業メモです。 昨日今日から zendframework/zend-stratigility 触ってます楽しいですしかしブレイクポイント貼れないのがストレスどうにかするぞ、と思ったときのメモです。

xdebug食っているか見る

  • php自体が食っていてもサーバー側(Apacheとか)が食っていないみたいな自体があったら嫌だから確認しましょう
  • phpinfo() するか php -i |grep xdebug

Dockerイメージ、php:7.2-apache でやった時は

  • RUN pecl install xdebug-2.6.0 && docker-php-ext-enable xdebug を忘れずにね
  • /usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so にモジュールあるよ

DBGpからのコネクトバックが来るか確認

  • コンテナ側で「9000番に飛ばしていますか」を見る
sudo tcpdump -nn  dst port 9000

正解例:

root@8a529e47bb64:/var/www/html# tcpdump -nn dst  port 9000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:59:17.461157 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [S], seq 1168735218, win 29200, options [mss 1460,sackOK,TS val 65964320 ecr 0,nop,wscale 7], length 0
09:59:17.466740 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [.], ack 452897992, win 229, length 0
09:59:17.466918 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 0:490, ack 1, win 229, length 490
09:59:17.469833 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [.], ack 38, win 229, length 0
09:59:17.470018 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 490:713, ack 38, win 229, length 223
09:59:17.473338 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 713:934, ack 73, win 229, length 221
09:59:17.476681 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 934:1158, ack 113, win 229, length 224
09:59:17.477883 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1158:1389, ack 158, win 229, length 231
09:59:17.479941 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1389:1610, ack 193, win 229, length 221
09:59:17.481909 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1610:1806, ack 210, win 229, length 196
09:59:17.483123 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 1806:2020, ack 222, win 229, length 214
09:59:17.484186 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2020:2320, ack 237, win 229, length 300
09:59:17.485338 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2320:2548, ack 295, win 229, length 228
09:59:17.486849 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2548:2777, ack 350, win 229, length 229
09:59:17.488071 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 2777:3046, ack 409, win 229, length 269
09:59:17.491217 IP 172.23.0.3.39156 > 192.168.65.2.9000: Flags [P.], seq 3046:3311, ack 468, win 229, length 265

xdebug.remote_host をいじってみる

docker.for.mac.host.internal で動くはずなんだけど。
デバッグのときの前提は「素直な気持ちになれ」「先入観を捨てろ」なので、「より確実に動く方!!」に近づいていきましょうってことでhostを決め撃ちしてみる。
tcpdumpで「宛先」がわかっているはず

ちなみに動くxdebug.ini

これで今は動いてる。

zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20170718/xdebug.so
xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.remote_host = docker.for.mac.host.internal
xdebug.remote_port=9000

Serversの設定について

うまく接続が返ってくれば、自動的に設定ダイアログが開くのでソレを待っても良い気がする。f:id:o0h:20180603191243p:plain