ခေတ်မီ Yarn တွင် ရွေးချယ်ထားသော Host များအတွက် မတူညီသော Proxy ပေးခြင်း

အထွေထွေ proxy တစ်ခုတည်းသည် ပက်ကေ့ချ် ရင်းမြစ်တိုင်းအတွက် မသင့်လျော်နိုင်ပါ။ ခေတ်မီ Yarn သည် host အမည်အလိုက် ကွန်ရက်ဆက်တင်များကို ပံ့ပိုးထားပြီး ရွေးချယ်ထားသော host တစ်ခုကို ပုံသေထက် မတူညီသော လမ်းကြောင်းကို အသုံးပြုခွင့်ပြုသည်။

ဥပမာအားဖြင့် ပရောဂျက်တစ်ခုသည် အထွေထွေလမ်းကြောင်းတစ်ခုကို ထားရှိပြီး အတွင်းပိုင်း registry အတွက် အခြားတစ်ခုကို ရွေးချယ်နိုင်သည်:

httpsProxy: "http://203.0.113.10:8080"
networkSettings:
  "registry.example.internal":
    httpsProxy: "http://203.0.113.20:8080"

လိပ်စာနှစ်ခုလုံးသည် နေရာယူထားသော တန်ဖိုးများဖြစ်သည်။ အများပြည်သူ ပက်ကေ့ချ် ရင်းမြစ်များသို့ သွားသော အထွေထွေလမ်းကြောင်းအတွက် အများပြည်သူ proxy များ ခွင့်ပြုထားချိန်တွင် HTTP proxy စာရင်း က ကိုယ်စားလှယ်လောင်းများကို ကမ်းလှမ်းသည်။ အတွင်းပိုင်း registry ၏ override ကို ၎င်း၏ အတည်ပြုထားသော proxy ပေါ်တွင် ထားရှိပါ။ ဖွဲ့စည်းမှုကို သင့်လျော်သော ဖိုင်တွင် (.yarnrc.yml) ခေတ်မီ Yarn ထုတ်ဝေမှုတစ်ခုအတွက် ထည့်ပါ။ ဤဥပမာသည် proxy နှစ်ခုကို ရွေးချယ်သည်; အတွင်းပိုင်း host သည် တိုက်ရိုက် ချိတ်ဆက်သင့်သည်ဟု ၎င်းက မဆိုပါ။

တောင်းဆိုထားသော host အမည်ကို ကိုက်ညီစေပါ

networkSettings ထည့်သွင်းချက်သည် host အမည် ပုံစံတစ်ခုအတွက် သက်ရောက်သည်၊ ပက်ကေ့ချ် scope သို့မဟုတ် မတော်တဆ URL လမ်းကြောင်းအတွက် မဟုတ်ပါ။ host တစ်ခုတည်းအတွက် စည်းမျဉ်းကို ရည်ရွယ်သည့်အခါ တိကျစွာ ထားရှိပါ။ wildcard သည် အပိုဆောင်း host များ ဖွဲ့စည်းမှုကို မျှဝေရန် အမှန်တကယ် ရည်ရွယ်သည့်အခါတွင်သာ အသုံးဝင်သည်။

ပက်ကေ့ချ် scope နှင့် ကွန်ရက် host အမည်သည် မတူညီသော ရွေးချယ်မှုများဖြစ်သည်။ scope ပါသော ပက်ကေ့ချ်ကို အခြားပက်ကေ့ချ်များနှင့် host မျှဝေထားသော registry မှ ရယူနိုင်ပြီး ပြန်ညွှန်ထားသော artifact သည် လုံးဝ အခြားသော host အမည်မှ လာနိုင်သည်။

ပြည့်စုံသော ဒေါင်းလုဒ်လမ်းကြောင်းကို လိုက်ပါ

metadata သည် host တစ်ခုကို အသုံးပြုပြီး archive ဒေါင်းလုဒ်က အခြားတစ်ခုကို အသုံးပြုပါက ၎င်းတို့သည် မတူညီသော ကွန်ရက်ဆက်တင်များနှင့် ကိုက်ညီနိုင်သည်။ စည်းမျဉ်းကို ချဲ့ထွင်မီ အမှန်တကယ် မအောင်မြင်သော URL ကို မှတ်တမ်းတင်ပါ။ “registry အလုပ်လုပ်ခဲ့သည်” ဟူသည် နောက်ပိုင်းတောင်းဆိုမှုက မည်သည့်လမ်းကြောင်းကို ရွေးချယ်ခဲ့သည်ကို မသက်သေပြပါ။

Yarn ၏ host အလိုက် ဆက်တင်များတွင် CA နှင့် အခြား TLS ဖွဲ့စည်းမှုလည်း ပါဝင်နိုင်သည်။ ထိုဆုံးဖြတ်ချက်များကို သီးခြား ထားရှိပါ: proxy လိပ်စာ ရွေးချယ်ခြင်းသည် စစ်ဆေးသည့် ပတ်ဝန်းကျင်အတွက် လိုအပ်သော ယုံကြည်မှုကို သူ့အလိုလို မပေးပါ။

override ကို မြင်သာအောင် လုပ်ပါ

ပရောဂျက်၏ အကျိုးသက်ရောက်သော ဖွဲ့စည်းမှုကို ၎င်း၏ Yarn ထုတ်ဝေမှု ပံ့ပိုးသော ကိရိယာများဖြင့် စစ်ဆေးပြီး ရည်ရွယ်ထားသော တောင်းဆိုမှုကို စမ်းသပ်ပါ။ ဖွဲ့စည်းမှု အပြည့်အစုံ dump တွင် အထောက်အထား ရှိပါက မျှဝေခြင်းကို ရှောင်ကြဉ်ပါ။

host များသည် မတူညီသော လမ်းကြောင်းများကို အမှန်တကယ် လိုအပ်သည့်အခါ ဤအင်္ဂါရပ်သည် အသုံးဝင်သည်။ တောင်းဆိုမှုတိုင်း တူညီသော endpoint ကို အသုံးပြုသင့်ပါက အထွေထွေဆက်တင် တစ်ခုတည်းသည် တိုးပွားနေသော တူညီသော host အမည် override စာရင်းထက် ထိန်းသိမ်းရန် ပိုလွယ်သည်။