Fly.ioについて

Herokuの無料化が終わったということで、代替サービス探し中。

今のところ個人的にはfly.io一択だろうと思ってる。実際に使っているがドキュメントなどもわかりやすいし、Railsを重点的にサポートしてくれていてデプロイもらくちん。自分が利用してる範囲で言うとスケジューラー/cron相当の機能はないが、Herokuより良い点としては時間制限や自動スリープがないこと、PostgreSQLが1GBまで無料なのでテキスト系のデータしか扱わないならHerokuの1万行ルールより遙かに緩いことなどがある。cronはないとはいっても、Redisが無料であつかえる上に公式でSidekiqの導入が紹介されているので、Sidekiq-schedulerを使えば定期実行も扱えるのだ。

逆にHerokuより明確に弱い点としては、VMのRAMが256MBとかなーり貧弱なのが上げられる。Heroku/Render.com/Railway.comはVMが512MBで、このVMのRAMが少ないというのは結構大きい。自分の場合は身内向けなので別に重いとかはいいんだけど、seleniumなど重めの非同期処理を動かすのはどうやら厳しいようだ。

Render.comについて

そこでrender.comだ。

render.comは正直、無料でスタンドアロンで普通に使うのは普通はほぼ不可能だと思う。DB（postgres）が90日でリセットされるのでまともには使えない。

ただVMは512MBとHeroku相当あるので、非同期処理をやるには心強い。なので、fly.ioをサポートするサービスとして使う分にはなかなかいいんじゃないかと思う。そこで、fly.ioのデータベースにRender.comを繋ぐ方法を備忘録的に残しておきます。

（renderはworker有料だった…意味なし）

単純にrender.comを無料で使いたいから、fly.ioに限らず外部データベースと接続したいって人にも参考になるかもしれない。

ちなみに環境はwindows10、railsです。

Fly.io側の準備

fly.io側のデータベースアプリは既に立っていて、flyctlもインストール済みとして話を進める。仮にデータベースアプリはfly-dbという名前だとする。

まずデータベースアプリ用のフォルダを作成しておく。
コンソールで作成したフォルダに入り、flyctl config save --app {データベースアプリの名前}を実行。ここではflyctl config save --app fly-dbになる。これでfly.tomlが作成される。

IPを固定するために、コンソールでフォルダに入ったままflyctl ips allocate-v4とflyctl ips allocate-v6を実行しておく。

fly.tomlというファイルがデータベースアプリ用のフォルダに出来ているはずなので

[[services]]
http_checks = []
internal_port = 5432
processes = ["app"]
protocol = "tcp"

に書き換え。そして

  [[services.ports]]
  handlers = []
  port = 10000

を追加する。この状態でflyctl deploy . --app <データベースアプリ名> --image flyio/postgres:<postgresのバージョン名>でfly.tomlをデプロイ。これでポート10000が開かれる。postgresのバージョンはflyctl postgres connectでpostgresに入り、SELECT version();で調べられる。

これで外部接続の準備が出来たので、必要なアドレスを作る。データベースを繋ぐのに必要なのは、次の形式のアドレス。

postgres://{ユーザー名}:{パスワード}@{外部用のホストネーム}:{ポート番号}/{データベース名}

データベース名は先ほどと同じようにpostgresに接続して、\lでデータベース一覧が見られるので、多分リスト一番上がデータベース名のはず。不安な人はデータベース内に入ってテーブル名とか確認したらわかるはず。

ポート番号は10000。外部用のホストネームはfly.ioのダッシュボードに入り、Application Informationのhostnameの部分（データベース.fly.devとかそんなアドレスになってるはず）。

ユーザー名とパスワードの部分は…データベース立てたときにログに表示されるのでそれを確認したらはやいけど、後から確認ってどうするんだろ。わかんね。

そんなこんなでこのアドレスが出来たら、確認としてpsql 上でつくったアドレス繋いで、接続できたらOK。一応、\dt;でテーブル一覧を確認しておいてもいい。

Render.com側の準備

アプリのデプロイは公式ドキュメントを参照。一応軽く触れると、githubにまずデプロイして、renderと紐付けることで自動的にデプロイされる形式になる。windwosで普通にやるとgemfile関係でエラーを吐くので、自分はbundle lock　--add-platform x86_64-linuxをコンソールから実行が必要だった。あとbinフォルダにrender-build.shを作成して、ドキュメント通りの内容をコピペしておくとか。

あとはrender用の設定ファイルとしてrender.yamlというファイルをルートフォルダに作成するんだけど、この設定が自分はちょっと曖昧。自分は

databases:
  - name: [fly.ioのデータベース名]
    databaseName: [fly.ioのデータベース名]
    user: [fly.ioのデータベースのユーザー名]

services:
  - type: web
    name: [renderのアプリ名]
    env: ruby
    buildCommand: "./bin/render-build.sh"
    startCommand: "bundle exec puma -C config/puma.rb"
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: [fly.ioのデータベース名]
          property: connectionString
      - key: RAILS_MASTER_KEY
        sync: false

というものをかき込んだけど、あってるか正直わからん。一応これで動いてはいるし、公式に聴いたらyamlは公式ガイド通り書けば問題ないみたいな受け答えで、よくわからない。

これでデプロイした状態で、renderのwebサイトからアプリのダッシュボードに入る。そしてEnvironmentのDATABASE_URLの項目に、上で作ったfly.ioのアドレスを入れる。

自分の場合はこれで接続完了できて、アプリ内でちゃんとfly.ioのデータを表示できた。うれしい。

追記

ちゃんと表示できるか確認するためにデータ表示用のテストページつくるとき、当然だけどちゃんとモデルを作らないといけない。しかし既にデータベース内にはテーブルが存在するので、rails g model テーブル名でテーブルを作ったあとは、マイグレーション用のファイルを消せばたぶんOKっぽい。間違ってたらすみません。