Web Development Notes

  Overview This tutorial will show you how to deploy a Rails application to AWS Elastic Beanstalk. Using Elastic Beanstalk is just one of many (perhaps an infinite number of!) AWS deployment options. Each approach has different pros and cons. I’ll briefly go over some of them because it’s good to understand the pros and cons of various approaches (at least to an extent) before choosing one. Manual EC2 deployment One option is to do things “the old fashioned way” and manually set up a Rails application on a single EC2 instance. This is the approach I go over in  this AWS/Rails deployment post  and it’s perfectly fine for hobby projects where the stakes are low. The downside to manual EC2 deployment is you end up with a  snowflake server , a server with a one-of-a-kind configuration that’s hard to understand, modify, or replicate. Elastic Beanstalk Elastic Beanstalk is  kind of  analogous to Heroku. The basic idea is the same in that both Elastic Beanstalk and Heroku are abstraction laye

systemd systemd   is a commonly available init system (PID 1) on many Linux distributions. It offers process monitoring (including automatic restarts) and other useful features for running Puma in production. Service Configuration Below is a sample puma.service configuration file for systemd, which can be copied or symlinked to   /etc/systemd/system/puma.service , or if desired, using an application or instance-specific name. Note that this uses the systemd preferred "simple" type where the start command remains running in the foreground (does not fork and exit). [Unit] Description =Puma HTTP Server After =network.target # Uncomment for socket activation (see below) # Requires=puma.socket [Service] # Puma supports systemd's `Type=notify` and watchdog service # monitoring, if the [sd_notify](https://github.com/agis/ruby-sdnotify) gem is installed, # as of Puma 5.1 or later. # On earlier versions of Puma or JRuby, change this to `Type=simple` and remove # t