Thuta Learning
Cloud & Deployment
IntermediateDevOps & Toolsbeginner

Environment Variables and Secrets

ဒီခန်းပြီးရင် ဘာတတ်သွားမလဲ

  • Environment Variables and Secrets concept ကို နားလည်ရှင်းပြနိုင်ရန်
  • Diagram ကို ဖတ်ပြီး architecture ထဲမှာ request/data ဘယ်လိုစီးဆင်းသလဲ ခြေရာခံနိုင်ရန်
  • ကိုယ့် project အတွက် ဘယ်လို ဆုံးဖြတ်သင့်သလဲ ရှင်းပြနိုင်ရန်

နားလည်ထားရမယ့် အချက်

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 တစ်ခုဖြစ်ပြီး လိုအပ်ခွင့်မရှိသူ ဘယ်သူ့ကိုမှ ဘယ်တော့မှ မြင်ခွင့်မပြုသင့်ပါ။
text
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 ဟာ ဖျောက်ထားတာ မဟုတ်ပါ — ထုတ်ဝေလိုက်တာပါ။

အတူတူ စမ်းရေးကြည့်မယ်

javascript
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));
You should see
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 ဘယ်မှာ ထားသင့်သလဲ

သင့် app က database တစ်ခုကို password သုံးပြီး ချိတ်ဆက်ဖို့ လိုအပ်ပါတယ်။ ဒီ password ကို ဘယ်မှာ ထားသင့်သလဲ။

The Twelve-Factor App — III. ConfigCloud & Deployment

ဒီနေရာမှာ လူအများမှားတတ်တယ်

  • .env file ကို git ထဲ commit လုပ်မိတာ — ပါဝင်တဲ့ secret တိုင်းကို permanent ဖြစ်ပြီး ပြန်ရှာလို့ရတဲ့ history ထဲ ထည့်လိုက်ရာရောက်ပါတယ်။
  • process.env ကနေ ဖတ်ထားလို့ လုံခြုံတယ်လို့ ထင်မှတ်တာ — public-safe prefix မပါဘဲ frontend code ထဲ bundle ဖြစ်သွားရင် ပေါက်ကြားနေပါပြီ။
  • Localhost မှာ အလုပ်လုပ်တာနဲ့ Production မှာ အလိုအလျောက်အလုပ်လုပ်မယ်လို့ မယူဆပါနှင့် — environment, network, database, security ကွာခြားချက်တွေ ရှိနိုင်ပါတယ်။

လေ့ကျင့်ခန်း

Code ဥပမာထဲ 'staging' environment ကိုယ်စားပြုတဲ့ တတိယ env state တစ်ခုကို ကိုယ်ပိုင် DATABASE_URL နဲ့ ထည့်ပြီး getConfig() က function ကိုယ်တိုင် မထိမိပဲ environment object ကိုသာ ပြောင်းလိုက်ရုံနဲ့ မှန်ကန်တဲ့ value ကို ပြန်ပေးလားစစ်ဆေးပါ။

You'll know it worked when: 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 ကို အသုံးပြုတာကို သတိပြုပါ)