နားလည်ထားရမယ့် အချက်
Database connection string ဒါမှမဟုတ် API key ကို source code ထဲ တိုက်ရိုက် hardcode လုပ်ထားတာက အစပိုင်းမှာ အလုပ်ဖြစ်ပေမယ့် code ကို share လုပ်တာ၊ git ထဲ commit လုပ်တာ၊ တခြားနေရာ deploy လုပ်တာနဲ့ ပြဿနာဖြစ်လာပါတယ်။
Environment variable တွေက configuration ကို code အပြင်ဘက်မှာ လုံးဝထားပေးပါတယ်။ DATABASE_URL လို value ကို run နေတဲ့ environment ထဲ set ထားပြီး code ကတော့ JavaScript ရဲ့ process.env ဒါမှမဟုတ် Python ရဲ့ os.environ ကနေ runtime မှာ ဖတ်ရုံပါပဲ။
Codebase တစ်ခုတည်းဟာ run နေတဲ့နေရာအလိုက် မတူညီပဲ ကျင့်ကြံနိုင်ပါတယ် — dev က debug ဖွင့်ထားတဲ့ localhost ကို ညွှန်ပြနိုင်ပြီး prod ကတော့ variable တူတူပဲ debug ပိတ်ထားတဲ့ live domain ကို ညွှန်ပြပါတယ်။ ပတ်ဝန်းကျင် configuration ပဲ ပြောင်းလဲတာပါ။
- API key နဲ့ access token
- Database password နဲ့ connection string
- Signing key နဲ့ authentication secret
- Environment Variable
- Code အပြင်ဘက်၊ application run နေတဲ့ environment ထဲမှာ set ထားပြီး code က runtime မှာ ဖတ်တဲ့ နာမည်ပါ configuration value။
- Secret
- API key၊ password၊ token လို sensitive environment variable တစ်ခုဖြစ်ပြီး လိုအပ်ခွင့်မရှိသူ ဘယ်သူ့ကိုမှ ဘယ်တော့မှ မြင်ခွင့်မပြုသင့်ပါ။
CODE + ENVIRONMENT CONFIG -> RUNNING APP
----------------------------------------
+------------------+
Dev Config -->| |--> App: localhost DB,
| Same Code | debug ON
| |
Prod Config-->| |--> App: prod DB,
+------------------+ debug OFFလက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
Configuration တစ်ခုချင်းစီအတွက် server ဘက်မှာသာ ရှိသင့်သလား browser ဆီ ရောက်လို့ရသလားဆိုတာ ဆုံးဖြတ်ပါ။ Credential နဲ့ signing secret တွေက server ဘက်မှာသာ ရှိသင့်ပြီး public API URL ဒါမှမဟုတ် feature flag ကတော့ client code ဆီ ဖော်ပြခွင့်ရဖို့ public-safe prefix အတိအလင်း လိုအပ်ပါတယ်။
Local development
.env file ထဲမှာ value တွေ ထားပြီး secret တွေ မတော်တဆ commit မဖြစ်အောင် .gitignore ကနေ version control ထဲ ခြွင်းချက်ထားပါ။
Production
Value တွေက file မဟုတ်တော့ဘဲ deployment platform ရဲ့ environment variable setting ထဲမှာ ရှိပါတယ်။
Secret တစ်ခုကို git ထဲ မတော်တဆ commit ဖြစ်သွားရင် သုံးနေတဲ့နေရာတိုင်းမှာ rotate လုပ်တာက optional မဟုတ်ပါ — git history က commit အဟောင်းတွေကို အမြဲသိမ်းထားလို့ commit အသစ်တစ်ခုမှာ line ဖျက်ရုံနဲ့ history ထဲက မဖယ်ရှားနိုင်ပါ။
Server-side secret တွေကို frontend code ထဲ ဘယ်တော့မှ မဖော်ပြပါနဲ့
Client-side JavaScript ထဲ ရောက်နေတဲ့ ဘာမဆို visitor တိုင်းရဲ့ browser ဆီ download ဖြစ်သွားပြီး developer tools ဖွင့်ကြည့်တဲ့ တစ်ယောက်ယောက်က ဖတ်နိုင်ပါတယ် — ဘယ်လို build/minify လုပ်ထားပါစေ။ Variable တစ်ခုမှာ framework ရဲ့ public-safe prefix မပါရင် (ဒါမှမဟုတ် browser ဆီ ပို့မယ့် component ထဲ import လုပ်မိရင်) ချက်ချင်း public ဖြစ်သွားပြီလို့ သဘောထားပါ။ Frontend code ထဲက database password၊ private API key၊ signing secret ဟာ ဖျောက်ထားတာ မဟုတ်ပါ — ထုတ်ဝေလိုက်တာပါ။
အတူတူ စမ်းရေးကြည့်မယ်
function getConfig(env) {
return {
databaseUrl: env.DATABASE_URL || "postgres://localhost:5432/dev_db",
appUrl: env.APP_URL || "http://localhost:3000",
};
}
const devEnv = {};
const prodEnv = {
DATABASE_URL: "postgres://prod-db.internal:5432/app",
APP_URL: "https://myapp.com",
};
console.log("Dev config:", getConfig(devEnv));
console.log("Prod config:", getConfig(prodEnv));Dev config: { databaseUrl: 'postgres://localhost:5432/dev_db', appUrl: 'http://localhost:3000' }
Prod config: { databaseUrl: 'postgres://prod-db.internal:5432/app', appUrl: 'https://myapp.com' }
(env object ထဲ value မရှိရင် fallback default ကို အသုံးပြုတာကို သတိပြုပါ)၅ မိနစ် စမ်းကြည့်
Code ဥပမာထဲ 'staging' environment ကိုယ်စားပြုတဲ့ တတိယ env state တစ်ခုကို ကိုယ်ပိုင် DATABASE_URL နဲ့ ထည့်ပြီး getConfig() က function ကိုယ်တိုင် မထိမိပဲ environment object ကိုသာ ပြောင်းလိုက်ရုံနဲ့ မှန်ကန်တဲ့ value ကို ပြန်ပေးလားစစ်ဆေးပါ။
သတိလေးတစ်ချက်
.env file ကို git ထဲ commit လုပ်မိတာ — ပါဝင်တဲ့ secret တိုင်းကို permanent ဖြစ်ပြီး ပြန်ရှာလို့ရတဲ့ history ထဲ ထည့်လိုက်ရာရောက်ပါတယ်။
process.env ကနေ ဖတ်ထားလို့ လုံခြုံတယ်လို့ ထင်မှတ်တာ — public-safe prefix မပါဘဲ frontend code ထဲ bundle ဖြစ်သွားရင် ပေါက်ကြားနေပါပြီ။
ဒီ password ဘယ်မှာ ထားသင့်သလဲ
The Twelve-Factor App — III. Config — Cloud & Deployment