Heroku

Ruby apps will now have the BUNDLED WITH declaration in their Gemfile.lock removed after detecting Bundler version｜Heroku Dev Center このアナウンスがあったので、調べてツイートした。ブログにも貼っておく。 loading... アナウンスの内容要約 Gemfile.lock の ‘BUNDLED WITH’ には問題があるから、Heroku では bundler version の決定（v1 or v2）に使った後、‘BUNDLED WITH’ は削除してからデプロイするよとのこと。 Heroku というより heroku-buildpack-ruby の話ね。 heroku-buildpack-ruby の処理 LanguagePack::Ruby#install_bundler_in_app から呼ばれるここで bundler v1 か v2 かを判別。 https://github.com/heroku/heroku-buildpack-ruby/blob/v207/lib/language_pack/helpers/bundler_wrapper.rb#L183-L192 下の LanguagePack::Helpers::BundlerWrapper#detect_bundler_version_and_dir_name! で、v1 なら 1.17.3、v2 なら v2.0.2 だと決定していた。 https://github.com/heroku/heroku-buildpack-ruby/blob/v207/lib/language_pack/helpers/bundler_wrapper.rb#L194-L204 その後の LanguagePack::Ruby#build_bundler で ‘BUNDLED WITH’ ブロックをゴリッと削除。 https://github.com/heroku/heroku-buildpack-ruby/blob/v207/lib/language_pack/ruby.rb#L788-L790 当該 PR Remove bundler version in Gemfile....

※ 会社の esa.io に投稿した記事の転載です。 本番環境で DB の値を書き換えるために、rails runner や rails console を使うことがある。bash もあるかもしれない。 $ heroku run rails r scripts/important.rb -a <App Name> # or $ heroku run rails c -a <App Name> heroku run のログは現在の端末だけにしか出力されない。アプリのログには出力されないため、LogDNA や Papertrail などにも記録されない。 現在の端末を閉じてしまうと、ログが消失するため十分注意すること。 回避方法 ↓ 以下のような非対話型コマンドであれば、run:detached サブコマンドを使うことで、LogDNA などに送ることが出来る。ただし、現在の端末には出力されない。 ・rails runner ・ls ↓ 対話型コマンドは今回の方法は使えない。他の回避方法があるかは不明。 ・rails console ・bash 非対話型コマンドのログをアプリのログに出力する ※ 以下、 を immense-shelf-19179 とします。 run:detached サブコマンドと -t オプションを使う。 $ heroku run:detached -t ls -a immense-shelf-19179 Running ls on ⬢ immense-shelf-19179....

先月、固定 IP アドレス機能を提供する QuotaGuard Static Add-on の Buildpack を作りました。 https://github.com/masutaka/heroku-buildpack-qgsocksify https://github.com/masutaka/heroku-buildpack-qgtunnel Buildpack を自作したのは今回が初めてです。 Add-on のドキュメント の通りにインストールすると、バイナリファイルをリポジトリに commit することになります。あまりきれいな方法に思えなかったことが、これらの Buildpack を作った動機です。 Buildpack を作ってみて、それがどのようにインストールされるか興味が湧いたので、詳しく調べてみました。 前準備 今回は Getting Started on Heroku with Node.js のサンプルアプリを使って確認しました。 Heroku App を作成したら、Buildpack に heroku-buildpack-qgsocksify の check ブランチ を指定しつつ、環境変数 HOGE をセットしておきます。 $ git clone https://github.com/heroku/node-js-getting-started.git $ cd node-js-getting-started $ heroku create $ git push heroku master $ heroku buildpacks:add 'https://github.com/masutaka/heroku-buildpack-qgsocksify#check' $ heroku config:set HOGE=aaa Buildpack をインストールする 適当な commit をして 2 回目の git push を行うと、heroku-buildpack-qgsocksify のインストールが始まると同時に、check ブランチに仕込んだログがダラダラと出力されました。出力多めです。読み飛ばしても OK です。...

[2019-01-19-1] で Heroku の Hobby Dyno ($7/mo) を使い始めたので、Heroku CI も導入してみました。 やり方はこのとおり簡単です。 pipeline を作成し、app と紐付ける Heroku CI を有効にし、GitHub とも連携する app.json を作成する 1. pipeline を作成し、App と紐付ける Heroku Dev Center > Pipelines を参考にして作るだけです。 2. Heroku CI を有効にし、GitHub とも連携する pipeline 右上の Enable CI ボタンをクリックすると有効になります。 3. app.json を作成する 今回は hadolint で Dockerfile を、shellcheck でシェルスクリプトの lint をするだけのテストを書きました。 このような素朴な設定で動きます。 test-setup と test のコンテキストは同じで、例えば test-setup で作ったファイルは test でも使えます。あと、App の環境変数も参照できますし、テスト用の環境変数を app.json に追加することも出来ます。 デフォルトでは Performance-M Dyno が使われます。Parallel Test も出来るらしいです。 詳しくは Heroku Dev Center > Heroku CI をどうぞ。...

個人の通知ツールとして、Pushover を愛用しています。[2015-03-08-1] でも紹介してます。 GitHub の自分のリポジトリにスターが付いたら通知 Pushover gem を使った、若干複雑なケースのデプロイ通知 Heroku にデプロイしたら通知 今まで Heroku のデプロイ通知は Heroku Deploy Hooks の Email に Pushover の E-mail Gateway を指定して出来ていましたが、Heroku Deploy Hooks の Email は 2018 年 5 月に Deprecate になっていました 。 仕方がないので、Heroku Deploy Hooks の HTTP post hook で通知する方法を調べました。 デプロイ成功の通知方法 結論から書くと、GET パラメータっぽくダラダラと書けば通知出来ました。 （なぜか通知されなくて一人ハマってましたが… ） 以下は改行と半角スペースを入れて読みやすくしたものです。各パラメータは url encode が必要です。 https://api.pushover.net/1/messages.json ? user=<YOUR USER/GROUP KEY> & token=<YOUR APPLICATION API TOKEN> & device=iPhone & priority=0 & title=masutaka.net+has+deployed & message=masutaka+deployed+app & url=https%3A%2F%2Fdashboard....

ここ一年半くらい、このブログが乗っていたサーバをメンテンスしていませんでした。４月に Ubuntu 14.04 LTS が EOL になることと、サーバの面倒をみることに疲れてしまったので、このブログを CloudFront+Heroku に移しました。 さくらのVPSに引っ越したのは [2013-05-27-2] だったので、５年半くらい使っていたことになります。このブログ自体は静的コンテンツですが、nginx のログを fluentd に流したり、各種メトリクスを kibana や GrowthForecast で可視化したり、ちょっとしたアプリケーションを動かしたり、いろいろ実験や素振りをすることが出来ました。今までありがとう。 さて、引っ越し前後の環境の変化です。 引っ越し前（さくらのVPS） https://vps.sakura.ad.jp/ 仮想サーバのプラン 2G、石狩リージョン、年額 18,770 円 ドメイン さくらのドメイン、年額 1,852 円 OS Ubuntu 14.04 LTS 構成管理 knife-solo デプロイ方法 GitHub の master ブランチに push すると、CircleCI 上で capistrano が自動デプロイ ビルド方法 capistrano でのデプロイ時に chalow が CHANGELOG メモを HTML に変換 配信方法 静的な HTML ファイルを nginx が配信 引っ越し後（CloudFront + Heroku） https://aws.amazon.com/jp/cloudfront/ https://jp.heroku.com/ Dyno Type Hobby、年額 $7 x 12 = $84 ≒ 9,554 円 ドメイン AWS Route53、年額 $12 + ($0....

この記事は heroku Advent Calendar 2018 の 21 日目の記事です。 20 日目は @pukka さんの『【Heroku検討者向け】デプロイ方法５選！ 』でした。（４）マニフェストでの heroku.yml の使い方は初めて知りました。デプロイした ところ、heroku18 Stack の Docker Image が使われているようでした。Slug を作る従来の非 Docker デプロイも Docker に寄せられていくのかな？ 今日はそんな Slug に注目した記事をお届けします。 Slug とは みなさん、Heroku の Slug はご存知でしょうか？ ダッシュボードの Settings タブからサイズを確認できます。 でもこれしか情報がないのですよね。恥ずかしがり屋さんかな？ Slug Compiler のドキュメントによると、 Slugs are compressed and pre-packaged copies of your application optimized for distribution to the dyno manager . When you git push to Heroku, your code is received by the slug compiler which transforms your repository into a slug....

これは Redash Advent Calendar 2018 の 17 日目の記事です。 16 日目は @mazamachi さんの『kubernetess の redash か黒魔術』ですが、まだ投稿されていないようですね。今回の記事にも関連するので期待してます。 1 日目の『2018年12月現在における Redash のはじめかた 』を拝見しました。実際問題、どこに立てれば良いか、悩む方もいらっしゃるのではないでしょうか。今回はその点をまとめていきます。 Redash をどこに立てれば良いか？ 身も蓋もありませんが、ご自身が一番慣れた Docker の PaaS 上で動かすのが良いと思います。 AWS EC2 や GCE などの、非 Docker 環境は運用負荷がそれなりに発生するため、避けたほうが良いでしょう。アップグレードでハマったり、ストレージ使用量 100% になるのはあるあるです。 ↓ 公式の How to Upgrade はいつの頃からか、非 Docker 環境でのアップグレード方法が “legacy guide” になってました。公式でも Docker 推しのようです。 This instructions are for those who use our new Docker based instance. If you use our older instances (or used the old bootstrap script), check the legacy guide ....

この記事は heroku Advent Calendar 2018 の 13 日目の記事です。 12 日目もわたくしマスタカの当番で、内容は『Heroku の Preboot 機能を深掘りした 』でした。その気になればドキュメント以上のことを探れることは、Heroku のメリットだと感じています。 今日は Heroku の BitBar plugin を紹介します。macOS 限定です。 BitBar とは BitBar - Put anything in your Mac OS X menu bar macOS のメニューバーにこんなものを置けるツールです。例として Homebrew Updates plugin を表示しています。 標準出力を吐きさえすれば、シェルスクリプトでも Ruby でも言語を問わないのが気楽です。 ↓ ちょっとだけ変更しています。 --- brew-updates.1h.sh.orig 2018-12-11 23:42:41.000000000 +0900 +++ brew-updates.1h.sh 2018-12-11 23:42:25.000000000 +0900 @@ -12,13 +12,13 @@ /usr/local/bin/brew update > /dev/null || exit_with_error; PINNED=$(/usr/local/bin/brew list --pinned); -OUTDATED=$(/usr/local/bin/brew outdated --quiet); +OUTDATED=$(/usr/local/bin/brew outdated --verbose); UPDATES=$(comm -13 <(for X in "${PINNED[@]}"; do echo "${X}"; done) <(for X in "${OUTDATED[@]}"; do echo "${X}"; done)) UPDATE_COUNT=$(echo "$UPDATES" | grep -c '[^[:space:]]'); -echo "↑$UPDATE_COUNT | dropdown=false" +echo "🍺$UPDATE_COUNT | dropdown=false" echo "---"; if [ -n "$UPDATES" ]; then echo "Upgrade all | bash=/usr/local/bin/brew param1=upgrade terminal=false refresh=true" Heroku plugin Heroku の異常に緩く気づける plugin です。https://status....

https://herokujp.doorkeeper.jp/events/82754 最近業務で Heroku 周りのことを一手に引き受けています。社内に本番環境での知見はあまりないので、参加してきました。 参加は初なんですが、前回の記事 [2018-11-21-1] を Slack の HerokuJP User Group にシェアしたら成り行きで話すことに。LT 以外で外で話すのは初でしたが、良い意味でこじんまりした Meetup で、割とリラックスして話せましたね。 会社の勉強会だと 20 人くらいいるので、良い訓練になっていたのかも。 アプリケーションエンジニアから見た The Twelve-Factor App by @kimihom The Twelve-Factor App は以前読んだことがあったけど、もう一度確認しようと思いました。 config/environments/staging.rb 作ってしまうとか、忘れてますね…。中身は require_relative ‘./production.rb’ にしてますがね。 先々週 GA になった heroku.yml を使った Docker Deploy の紹介 by @masutaka 前述のとおり、[2018-11-21-1] のプレゼン版です。 プレゼン用に ↓ このリポジトリを作りました。README.md に沿って試すと、とっても簡単に Heroku の Docker 周りを試せます。興味ある方は是非どうぞ。 正しく理解する Heroku Flow by @sho7650 ちょうど Heroku CI と Promotion は知りたかったので、タイミングが良かったです。 Promote で引き継ぐのは Slug のみで、環境変数は引き継がないそうなので、うちのチームのデプロイ高速化と安全性の向上に使えると思いました。...