14. サーバでの公開¶
14.1. Railsの動作環境(Environment)¶
Railsには動作環境として development と production がある（ほんとは test もあるけれど、それは省略）。
development
毎回コードを読み込んで実行するので、変更がすぐに反映される。
production
一度読み込んだコードはキャッシュするので、変更したらウェブサーバの再起動などが必要。その代わり速い。
14.1.1. 環境の指定¶
環境変数
RAILS_ENVで指定する。ウェブサーバから起動するプロセスについては、使うシステムによって指定方法が用意されている。例えばApache+Passengerの場合は、Apacheの設定ファイルの中に
PassengerAppEnvディレクティブを書く。
14.1.2. 環境による設定の切り替え¶
初期設定は
config/environments/development.rbとconfig/environments/production.rbに書く。データベースの設定は
config/database.ymlの中に環境ごとに区切って書く。デフォルトでは開発環境も本番環境もsqlite3を使うが、データベースのファイルは
db/development.sqlite3とdb/production.sqlite3と別のものになっている。本番環境では扱うデータ量が多いので、PostgresqlやMySQLを使うことが多い。
14.2. gemのインストール¶
gemによってはnative extensionを含むものがあり、これはCPUやOSやライブラリに依存するので、一般には本番マシンでインストールし直さなければならない。
最近は開発マシンも本番マシンもDockerを使って全く同じ環境にすることも多い。
14.3. セキュリティ¶
一般に公開する場合はセキュリティホールを作らないように注意。
CNSのサーバを使う場合は、CNSの規則も守ること。
参考資料： SFC-CNS利用内規
14.4. Renderへのデプロイ¶
14.4.1. Renderについて¶
Render はRailsホスティングサービスの一つ。
商用サービスであるが、ごく小さなアプリケーションなら無料アカウントで利用可能。ただし、データベースは90日経つと削除される。
14.4.2. GitHubについて¶
Renderは、GitHubまたはGitLabのリポジトリからデプロイするようになっているので、まずGitHub（またはGitLab）のリポジトリを作ることが必要。GitHubについてはググればいくらでも解説が見つかる（例えば次の資料）ので、そちらを参照。
14.4.3. デプロイの手順¶
とりあえず動作を確認するだけならば、次の手順でよい。
Your First Render Deploy – Render Docs
Build Command は、デフォルトで入っているものの後に
bundle exec rake db:migrate; bundle exec rake db:seedを付け加える。
ただし、この手順ではデータベースはsqlite3であり、実行イメージ上のファイルシステムに作られる。Renderの無料プランでは、しばらくアクセスが無いとインスタンスは停止され、実行イメージは（そこにあったデータベースもろとも）消えてしまう。したがって、実用的に使うには別にデータベースを用意する必要がある。詳しくは次の資料を参照。
14.4.4. メール送信の設定¶
メールを送信する必要がある場合は、 config/environment/production.rb にSMTPの設定を書き（ 13.2.4 章 ）、環境変数でメールサーバのログイン名とパスワードを設定する。環境変数は Dashboard の Environment で設定できる。
Deviseでメールを送信するのはパスワード再発行のときだけなので、面倒くさい、あるいはパスワード漏洩リスクが嫌な人は、設定しないのもアリ。
14.4.5. ファイルのアップロード¶
Active Storage によるファイルのアップロード（ 11 章 ）でサーバのディスクに保存するよう指定した場合、Renderでは実行イメージ上のファイルシステムに保存されるので、とりあえずは動く。しかし、無料プランではアイドル状態が一定時間続くと実行イメージは消去されるので、次にアクセスしたときには画像が消えていることがある。
14.4.6. デプロイした例¶
https://sfc-script-lang-deploy.onrender.com/
最終課題
ソースコードはK-LMSの「最終課題（ソースコード）」に次のどちらかを提出。
Railsアプリケーションのディレクトリ（例題だったらschool）をzipまたはtar+gzipで圧縮してアップロード。
GitHubやGitLabに置いている人は、そのURLを提出。（private repository だと見えないので、publicであること）
レポートはK-LMSの「最終課題（レポート）」に提出。構成は次のような感じで。
最初にどのようなものを作ろうと思ったか、動機や目標や背景。
できたアプリケーションの使い方の説明。
アプリケーションの内部構造の説明。
思った通りのものができたか、何が難しかったか。
Renderや自宅サーバにデプロイした場合は加点するので、「最終課題（サーバ）」にURLを提出。
全員、1月23日の授業でデモをする。
締め切りは1月22日(木)。
注意：参考にした資料はレポートの最後に参考文献リストとして書くこと。公開されているソースコード、友達に教えてもらったコード、生成AIが作ったコードをそのまま使った場合は、コメントとしてどこからコピーしたかを明記すること。出典を明記せずにコピペすると、不正行為としてその学期の単位がすべてDになることがある。