Last Updated: 2023-12-03
To get my Rails app running along with all its dependencies in development, I used a
Procfile.dev that looked like this:
redis: redis-server /usr/local/etc/redis.conf --port 6379 elasticsearch: elasticsearch # Unimportant for present purposes webpack: ./bin/webpack_dev_server web: ./bin/rails server -p 3000 scheduler: ./bin/scheduler.sh docservices: ./bin/docservices worker: ./bin/rake jobs:work
i.e. elasticsearch and redis were started here instead of with
brew services start x, as is typical for these services. My motivation for doing things this way was that I wanted to notice their boot failures or logs right away when I started my software (instead of needing to rummage around for their logs).
This, however, was less than ideal. Elasticsearch took 20 seconds to start, which meant rebooting sucked. Whatsmore, by starting and stopping redis and elasticsearch manually from this location, this meant I wasn't running them as services, which, in turn, means that other environments, like seed and test, would throw errors if I didn't either create additional Procfiles for these environments (adding weight and boilerplate) or (as I actually ended up doing) resorting to the hackish solution of running the dev environment Procfile in other environments (e.g. test) in order to get them working.
Eventually I rewrote the procfile to use existing services but instead tap into their logs and display them in my terminal foreground. This let me retain my ability to be aware of logged issues in my software dependencies:
redis: ./bin/follow_with_syslog.sh redis-server elasticsearch: tail -f /usr/local/var/log/elasticsearch.log webpack: ./bin/webpack_dev_server web: ./bin/rails server -p 3000 docservices: ./bin/docservices scheduler: ./bin/scheduler.sh worker: ./bin/rake jobs:work