Belajar Ruby on Rails - Configuration & Environments

#Pendahuluan

Setelah membangun API di episode 15, episode 16 membahas lapisan yang membuat aplikasi bisa berjalan di tiga tempat berbeda: konfigurasi & environments. Di development, test, dan production, nilai konfigurasi (database, SMTP, storage, API key) harus berbeda — dan yang paling krusial: secret tidak boleh di-commit.

Mengapa episode ini penting? Karena aplikasi yang baik memisahkan kode dari konfigurasi. Secret yang bocor ke repository berarti kompromi total — akses ke database, cloud, dan layanan pihak ketiga. Rails menyelesaikannya dengan encrypted credentials dan env vars; episode ini membedah keduanya plus pola multi-environment yang rapi.

#Lingkungan Rails

Rails berjalan di environment yang dibaca dari Rails.env:

bin/rails server          # development (default)
RAILS_ENV=production bin/rails server
RAILS_ENV=test bin/rails test

Setiap environment punya file konfigurasi sendiri:

config/application.rb memuat pengaturan bersama; file environment menimpa per kebutuhan (misal config.cache_store, config.active_storage.service).

Cek environment di kode

Rails.env.development?  # true di development
Rails.env.production?
if Rails.env.development?
  Rails.application.config.x.debug_mode = true
end

#ENV Variables

Konfigurasi non-secret maupun secret sebaiknya dibaca dari env vars — inilah pola 12-factor app: konfigurasi di luar kode.

Membaca env var

ENV.fetch("APP_HOST", "localhost:3000")
ENV.fetch("SMTP_USERNAME")   # raise jika tidak ada

Gunakan ENV.fetch dengan default agar kegagalan terdeteksi sejak awal. Di development, file .env di-load gem dotenv:

APP_HOST=localhost:3000
SMTP_USERNAME=dev@example.com

Gemfile

gem "dotenv-rails"

.env di-gitignore; .env.example di-commit sebagai template.

#Encrypted Credentials

Rails menyimpan secret langsung di repository — tapi terenkripsi. File config/credentials.yml.enc berisi secret terenkripsi yang hanya bisa dibaca dengan config/master.key (di-gitignore) atau env var RAILS_MASTER_KEY.

bin/rails credentials:edit

smtp:
  user_name: api@example.com
  password: super-secret
aws:
  access_key_id: AKIA...
  secret_access_key: ...

Dibaca di kode sebagai Rails.application.credentials:

Membaca credentials

Rails.application.credentials.smtp[:user_name]
Rails.application.credentials.dig(:aws, :secret_access_key)

Keuntungan: secret ter-version-control (audit perubahan), tetapi tetap aman karena hanya terbaca dengan master key.

#Environment-Specific Credentials

Pola lengkap untuk multi-environment:

bin/rails credentials:edit                       # default (dev/test)
bin/rails credentials:edit --environment production

Akses kontekstual

# development & test
Rails.application.credentials.smtp[:user_name]
# production (nil di env lain)
Rails.application.credentials.production!.dig(:aws, :access_key_id)

Di production server, master key untuk tiap environment diberikan lewat env var (bukan file):

export RAILS_MASTER_KEY="$(cat config/credentials/production.key)"
export AWS_ACCESS_KEY_ID="..."
export SMTP_USERNAME="..."

Rails membaca RAILS_MASTER_KEY otomatis jika config/master.key tidak ada.

#Praktik: Secrets Management Multi-Env

Alur yang direkomendasikan untuk project nyata:

1. .env di-gitignore untuk dev; .env.example di-commit sebagai template.
2. Secret yang perlu version control → encrypted credentials.
3. Secret per-environment → credentials --environment di Rails 8.
4. Secret deployment → env vars / secret manager di server (Kamal env, CI secrets, Vault).
5. Jangan pernah menaruh key di kode, log, atau commit.

git check-ignore .env && echo ".env aman"
rg -i "password|secret|api_key" --glob '!*.yml.enc' .

#Common Pitfalls

• Secret di-hardcode di kode — misal API key di seeds.rb; selalu credentials/env vars.
• ENV["X"] tanpa default — return nil diam-diam; pakai ENV.fetch.
• Master key ter-commit — file .enc jadi tidak berguna; jaga di gitignore.
• Konfigurasi berbeda hanya di satu file — pengaturan yang harus konsisten (misal timezone) di application.rb, bukan environment.
• .env di-commit — kebocoran langsung; .env.example saja yang di-commit.
• Credential expired tidak di-rotasi — tetapkan proses rotasi key berkala, bukan menunggu insiden.

#Penutup

Episode 16 membekali kalian konfigurasi Rails: tiga environment dengan file konfigurasi masing-masing, env vars sebagai sumber konfigurasi 12-factor, encrypted credentials dengan credentials:edit, dukungan credentials per-environment di Rails 8, serta pola secrets management untuk development sampai production.

Inti yang harus dibawa pulang:

• Kode dan konfigurasi dipisahkan; env vars & credentials menyalurkannya.
• config/credentials.yml.enc dienkripsi master key; baca via Rails.application.credentials.
• Rails 8: credentials per-environment dengan --environment.
• .env di-gitignore, .env.example di-commit sebagai template.
• Secret yang pernah bocor = kompromi; rotasi, bukan sekadar hapus.

Di episode 17 selanjutnya kita akan membedah logging & debugging — log levels, structured log untuk production, gem debug dengan breakpoints, dan troubleshooting via console. Sampai jumpa di episode 17!