なぜrailsの本番環境ではUnicorn,Nginxを使うのか? 　~ Rack,Unicorn,Nginxの連携について ~【Ruby On Railsでwebサービス運営】RubyRailsnginxunicornrack railsでwebサービスを運営するためにサーバー内でrailsアプリを立ち上げる方法を調べると、なぜかどのサイトでも、nginx+unicornを使っていています。 ローカルでは rails s をして立ち上げるのに、サーバー内では他のものを使うことをちょっと不思議に思うのではないでしょうか。 今回はなぜ rails s で立ち上げず、nginxやunicornを使うのかということが最終的に納得できることを目指して、解説していきたいと思います。 Webサーバーとアプリケーションサーバー railsやnginxなどの話をする前にまずはwebサーバーとアプリケーショ

先日、RFC9116が発表されました🚀 あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txtを標準化するものです。 この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。 なぜこれが必要だったのか https://securitytxt.org/のSummary(概要)にはこのように書かれています。 Webサービスのセキュリティリスクが、リスクの重大性を理解している独立したセキュリティ研究者によって発見された場合、それらを適切に開示するためのチャンネルが不足していることがよくあります。 その結果、セキュリティの問題が報告されないままになる可能性があります。 security.txtは、組織がセキュリティ研究者がセキュリティの脆弱性を安全に開示するためのプロセスを定義するのに役立つ標

このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(

Ruby向けのDockerイメージで使いがちな環境変数について整理する。 GEM_HOME RubyGemsに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば gem install foo を実行すると、この環境変数で指定したディレクトリにfoo gemがインストールされる。 Dockerでありがちな作戦として、/gem のような適当なパスにデータボリュームをマウントしておいて、そこにGemを永続化させておくというのがある。このときGEM_HOMEを /gem に指定しておくと、gem install bundler を実行したときそこにBundlerがインストールされ、更に /gem/bin/bundle も用意される。 BUNDLE_PATH Bundlerに対して、どのディレクトリにGemをインストールするかを指定する環境変数。例えば bundle i

新年あけましておめでとうございます。 @rosylilly です。 この前 SRE 養成講座の体験授業配信 をしたんですが、その時にハンズオンの一環で Ruby 製アプリケーションをいじって高速化してみる。という内容を実施しました。 コンセプトとしては、『ちゃんと設定ファイルを書くだけでも高速化する』という感じです。作業としてはアプリケーションをいじらずに、設定だけいじって高速化する、ということなんですが、結局何がどれくらい効くのか、というのを事前に参考値レベルで弾いておかないとぶっつけ本番になっちゃうな、ということで何がどれくらい効くのかを試してからにしようということで、事前に調査したときのベンチテストと何を変えたかの記録になります。 ベンチマークの前準備 今回はほぼ何もしない Sinatra アプリケーションを作って、その性能差から測ります。ということで用意した性能測定用何もしない S

JAWS FESTA 2017