Release 1.8

Rails 7. Start Kit. Production Mode and Configurations

Install and Run Ruby on Rails now!

Copy & Paste in your terminal

git clone https://github.com/the-teacher/rails7-startkit.git && \
  cd rails7-startkit && \
  bin/setup

Rails 7. My Configuration Approach

It was time when I finally had to manage configuration of my Rails application.

A Rails app always full of configuration parameters. There are some places where you can meet them

• config/database
• config/initializers
• config/credentials.yml.enc and config/master.key

It is normal when you need to provide many different parameters for different parts of your "system".

Configuration files and "Classic approach"

Probably you know, that from the very beginning of the software engineering it was fine to have configurations in files. In rails you can find an example of it in config/database.yml. It originally looks like that

development:
  pool: 5
  adapter: mysql2
  encoding: utf8
  database: app_development
  username: root
  password: qwerty
  socket: /tmp/mysql.sock

ENV variables for configuration. "Cloud oriented approach"

After cloud calculations and automatic infrastructure scaling took the world many applications started to use ENV variables for application configuration by default.

Lets take the same config/database.yml and show how it may look in Rails

development:
  pool: 5
  adapter: mysql2
  encoding: utf8
  database: <%= ENV['DATABASE_NAME']%>
  username: <%= ENV['DATABASE_USER']%>
  password: <%= ENV['DATABASE_PASSWORD']%>
  socket: /tmp/mysql.sock

What an approach is better?

If you ask people around "what is better?" they may answer differently. I think it is a "holy war" topic. I can provide only my own opinion:

File configuration

• is great for small and not "very serious" projects
• is great for having structured parameters and group configurations in order to their scope
• not very good for auto-scaling systems

ENV configuration

• is great for big and auto-scalable (cloud) projects
• not very convenient. Structure is plain and could be scoped only by using a name convention
• can be uncontrolled spread in the application. Can be a cause of problems with running an application until you find all required variables in the application

Synthetic approach

I prefer to use a Synthetic configuration approach. It can be implemented with using to ruby gems

• gem dotenv -- For managing Env variables
• gem config -- For managing configurations in an application

The idea is clear

• I use ENV as a source of the configuration information
• I use ENV variables only in one configuration file to collect all ENV in the only place to avoid pollution of the code with ENVs
• I use classic config files to provide a structure and scoping of parameters
• I use gem config to provide a comfortable interface for configurations

Synthetic Configuration Approach in Practice

We have ENV variables on the level of the OS, or for local development in .env files

.env file

All this parameters go to config/_CONFIG.yml. This file is being managed by gem config

• As you can see I use ENV.fetch for setting up defaults
• As you can see I collect all ENV variables in the only place in my application

Now in my application I use so beauty way to setup required configurations:

For database:

For elastic:

Also sometimes it is very great to do something like that Settings.redis.to_hash:

⚠️ Combining 2 different solutions for rails configuration I keep my code clean, maintainable, ready for clouds services, and easy to use.

And one more time:

• gem dotenv -- For managing Env variables
• gem config -- For managing configurations in an application

The idea and following changes was provided in the PR

Production Mode

Finally I spent some time to improve my code to make possible running Rails 7. Start Kit in Production mode.
You can easily use production mode, just with setting a required ENV variable.

RAILS_ENV=production bin/setup

RAILS_ENV=production bin/exec start
RAILS_ENV=production bin/exec stop

RAILS_ENV=production bin/exec start_all
RAILS_ENV=production bin/exec stop_all

That is it!

👉 Subscribe to the project to know about most recent updates.

Happy coding with Rails 7. Start Kit