Docker နှင့် Gitlab CI ဖြင့် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်

Inventos "Docker + Gitlab CI ဖြင့် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်" မှ Alexander Sigachev ၏ မှတ်တမ်းကို ဖတ်ရန် ကျွန်ုပ်အကြံပြုအပ်ပါသည်။

Docker + Gitlab CI ကိုအခြေခံ၍ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် စမ်းသပ်မှုလုပ်ငန်းစဉ်ကို စတင်အကောင်အထည်ဖော်နေသူများသည် အခြေခံမေးခွန်းများ မေးလေ့ရှိပါသည်။ ဘယ်မှာစရမလဲ။ ဘယ်လိုစည်းရုံးမလဲ။ ဘယ်လိုစမ်းသပ်မလဲ။

Docker နှင့် Gitlab CI ကို အသုံးပြု၍ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်အကြောင်း စနစ်တကျ ဆွေးနွေးထားသောကြောင့် ဤအစီရင်ခံစာသည် ကောင်းမွန်ပါသည်။ အစီရင်ခံစာကိုယ်တိုင်က 2017 ကပါ။ ဤအစီရင်ခံစာမှ အခြေခံများ၊ နည်းစနစ်များ၊ အကြံဥာဏ်များနှင့် အသုံးပြုမှုအတွေ့အကြုံများကို စုဆောင်းနိုင်သည်ဟု ကျွန်ုပ်ထင်ပါတယ်။

ဘယ်သူ ဂရုစိုက်လဲ ကြောင်အောက်မှာ ကျေးဇူးပြုပြီး

ကျွန်တော့်နာမည် Alexander Sigachev ပါ။ ကျွန်တော် Inventos အတွက် အလုပ်လုပ်ပါတယ်။ Docker ကိုအသုံးပြုခြင်းအတွေ့အကြုံနှင့် ကုမ္ပဏီရှိ ပရောဂျက်များတွင် ၎င်းကို ဖြည်းဖြည်းချင်း အကောင်အထည်ဖော်ပုံတို့ကို ပြောပြပါမည်။

အစီရင်ခံစာ၏အကြောင်းအရာ- Docker နှင့် Gitlab CI ကို အသုံးပြု၍ ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်။

ဒါက Docker အကြောင်း ကျွန်တော့်ရဲ့ ဒုတိယမြောက် ဆွေးနွေးမှုပါ။ ပထမအစီရင်ခံချိန်တွင် ကျွန်ုပ်တို့သည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာစက်များတွင် ဖွံ့ဖြိုးတိုးတက်ရေးတွင် Docker ကိုသာ အသုံးပြုခဲ့သည်။ Docker သုံးတဲ့ ဝန်ထမ်းဦးရေက ၂-၃ ယောက်လောက်ရှိတယ်။ တဖြည်းဖြည်းနဲ့ အတွေ့အကြုံတွေရလာပြီး ကျွန်တော်တို့ နည်းနည်းပိုဝေးသွားတယ်။ ကျွန်တော်တို့ရဲ့လင့်ခ် ပထမအစီရင်ခံစာ.

ဒီအစီရင်ခံစာမှာ ဘာတွေပါမလဲ။ ကျွန်ုပ်တို့ စုဆောင်းထားသော ကိတ်မုန့်များ၊ မည်သို့သော ပြဿနာများ ဖြေရှင်းခဲ့သည်များအကြောင်း ကျွန်ုပ်တို့၏ အတွေ့အကြုံကို မျှဝေပါမည်။ နေရာတိုင်းက မလှပပေမယ့် အဲဒါက ကျွန်တော်တို့ကို ဆက်လျှောက်ခွင့်ပေးတယ်။

ကျွန်ုပ်တို့၏ဆောင်ပုဒ်- ကျွန်ုပ်တို့လက်လှမ်းမီသမျှကို လက်ကိုင်ထားလိုက်ပါ။

ဘယ်လိုပြဿနာတွေကို ငါတို့ဖြေရှင်းနေလဲ။

ကုမ္ပဏီတစ်ခုတွင် အဖွဲ့များစွာရှိသည့်အခါ ပရိုဂရမ်မာသည် မျှဝေထားသော အရင်းအမြစ်တစ်ခုဖြစ်သည်။ ပရိုဂရမ်မာတစ်ဦးကို ပရောဂျက်တစ်ခုမှ ဆွဲထုတ်ပြီး အခြားပရောဂျက်တစ်ခုသို့ အချိန်အတန်ကြာ ပေးအပ်သည့်အခါ အဆင့်များရှိသည်။

ပရိုဂရမ်မာတစ်ဦးသည် လျင်မြန်စွာနားလည်နိုင်စေရန်အတွက် ပရောဂျက်၏အရင်းအမြစ်ကုဒ်ကို ဒေါင်းလုဒ်လုပ်ပြီး ပတ်ဝန်းကျင်ကို တတ်နိုင်သမျှ မြန်မြန်ဖွင့်ရန် လိုအပ်ပြီး ၎င်းသည် ဤပရောဂျက်၏ပြဿနာများကို ဖြေရှင်းရာတွင် ပိုမိုတိုးတက်ကောင်းမွန်လာစေမည်ဖြစ်သည်။

အများအားဖြင့်၊ သင် အစမှ စတင်ပါက ပရောဂျက်တွင် စာရွက်စာတမ်း အနည်းငယ်သာရှိသည်။ ရှေးခေတ်ဟောင်းများသာ ၎င်းကို သတ်မှတ်ပုံနှင့်ပတ်သက်သည့် အချက်အလက်ရှိသည်။ ဝန်ထမ်းများသည် ၎င်းတို့၏ လုပ်ငန်းခွင်ကို တစ်ရက် သို့မဟုတ် နှစ်ရက်အတွင်း ၎င်းတို့ဘာသာ သတ်မှတ်ပေးသည်။ ၎င်းကိုအရှိန်မြှင့်ရန် Docker ကိုအသုံးပြုခဲ့သည်။

နောက်အကြောင်းအရင်းမှာ Development ရှိ ဆက်တင်များ၏ စံသတ်မှတ်ခြင်းဖြစ်ပါသည်။ ကျွန်ုပ်၏အတွေ့အကြုံအရ၊ ဆော့ဖ်ဝဲရေးသားသူများသည် အမြဲတမ်း အစပျိုးလုပ်ဆောင်သည်။ ပဉ္စမကိစ္စတိုင်းတွင်၊ ဥပမာ vasya.dev စိတ်ကြိုက်ဒိုမိန်းတစ်ခုကို ထည့်သွင်းထားသည်။ ငါ့ဘေးမှာထိုင်နေတဲ့ ငါ့အိမ်နီးချင်း Petya က petya.dev ပါ။ ၎င်းတို့သည် ဤဒိုမိန်းအမည်ကို အသုံးပြု၍ ဝဘ်ဆိုက် သို့မဟုတ် စနစ်အစိတ်အပိုင်းအချို့ကို တီထွင်သည်။

စနစ်ကြီးထွားလာပြီး ဤဒိုမိန်းအမည်များကို စီစဉ်ဖွဲ့စည်းမှုတွင် စတင်ထည့်သွင်းသောအခါ၊ ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်များတွင် ပဋိပက္ခတစ်ခု ဖြစ်ပေါ်လာပြီး ဆိုက်လမ်းကြောင်းကို ပြန်လည်ရေးသားပါသည်။

ဒေတာဘေ့စ်ဆက်တင်များတွင်လည်း အလားတူကိစ္စရပ်မျိုးဖြစ်တတ်သည်။ အချို့သောလူများသည် လုံခြုံရေးအတွက် အနှောက်အယှက်မပေးဘဲ အချည်းနှီးသော root စကားဝှက်ဖြင့် လုပ်ဆောင်ကြသည်။ တပ်ဆင်သည့်အဆင့်တွင်၊ MySQL သည် တစ်စုံတစ်ဦးအား စကားဝှက်တစ်ခုတောင်းပြီး စကားဝှက်သည် 123 ဖြစ်သွားသည်။ ဆော့ဖ်ဝဲရေးသားသူ၏ ကတိကဝတ်အပေါ် မူတည်၍ ဒေတာဘေ့စ်ပြင်ဆင်မှုမှာ အဆက်မပြတ်ပြောင်းလဲနေတတ်သည်။ တစ်စုံတစ်ယောက်က ပြုပြင်ထားတယ်၊ တစ်စုံတစ်ယောက်က ပြုပြင်မှုပုံစံကို မပြင်ဘူး။ စမ်းသပ်မှုပုံစံအချို့ကို ထည့်သွင်းသောအခါတွင် လှည့်ကွက်များရှိသည်။ .gitignore developer တစ်ခုစီသည် database ကို install လုပ်ရမည်ဖြစ်ပါသည်။ ယင်းက စတင်သည့် လုပ်ငန်းစဉ်ကို ပိုမိုခက်ခဲစေသည်။ အခြားအရာများထဲတွင်၊ သင်သည် database အကြောင်း မှတ်သားထားရန် လိုအပ်သည်။ ဒေတာဘေ့စ်ကို အစပြုရမည်၊ စကားဝှက်တစ်ခု မှတ်ပုံတင်ရမည်၊ အသုံးပြုသူ မှတ်ပုံတင်ရမည်၊ ဆိုင်းဘုတ်ကို ဖန်တီးရမည်၊ စသည်ဖြင့်။

နောက်ပြဿနာတစ်ခုကတော့ စာကြည့်တိုက်တွေရဲ့ ဗားရှင်းအမျိုးမျိုးပါပဲ။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် မတူညီသောပရောဂျက်များတွင် လုပ်ဆောင်လေ့ရှိသည်။ လွန်ခဲ့သောငါးနှစ်က (2017 မှစတင်ခဲ့သည် - တည်းဖြတ်သူ၏မှတ်ချက်) ။ အစတွင် ကျွန်ုပ်တို့သည် MySQL 5.5 ဖြင့် စတင်ခဲ့သည်။ ဥပမာ 5.7 နှင့်အထက် (2017 ခုနှစ် - တည်းဖြတ်သူ၏မှတ်စု)

MySQL နှင့်အလုပ်လုပ်သူတိုင်းသည် ဤစာကြည့်တိုက်များသည် မှီခိုမှုများရှိသည်ကိုသိသည်။ ဒေတာဘေ့စ် 2 ခုကို အတူတူ run ဖို့က တော်တော်ပြဿနာတက်ပါတယ်။ အနည်းဆုံးတော့၊ ဖောက်သည်ဟောင်းတွေကို ဒေတာဘေ့စ်အသစ်နဲ့ ချိတ်ဆက်ဖို့က ပြဿနာရှိတယ်။ ယင်းက ပြဿနာများစွာကို ဖြစ်ပေါ်စေသည်။

နောက်ပြဿနာမှာ developer သည် local machine တစ်ခုတွင်အလုပ်လုပ်သောအခါ၊ local resources, local files, local RAM ကိုအသုံးပြုသည်။ ပြဿနာများအတွက် အဖြေတစ်ခုကို တီထွင်နေချိန်တွင် အပြန်အလှန်ဆက်သွယ်မှုအားလုံးကို စက်တစ်လုံးတည်းတွင် လုပ်ဆောင်သည့်အချက်၏ မူဘောင်အတွင်း ဆောင်ရွက်ပါသည်။ ဥပမာတစ်ခုက Production 3 တွင် backend ဆာဗာများရှိသည်ဖြစ်၍ developer သည် ဖိုင်များကို root directory တွင်သိမ်းဆည်းပြီး nginx မှ တောင်းဆိုချက်အား တုံ့ပြန်ရန်အတွက် ဖိုင်များကို ယူဆောင်သွားမည်ဖြစ်သည်။ ထိုသို့သောကုဒ်သည် ထုတ်လုပ်ရေးသို့ရောက်ရှိသောအခါ၊ ဖိုင်သည် ဆာဗာ 3 ခုအနက်တစ်ခုတွင် ရှိနေကြောင်း ထွက်ပေါ်လာသည်။

Microservices ၏ ဦးတည်ချက်သည် လက်ရှိတွင် တိုးတက်နေပါသည်။ ကျွန်ုပ်တို့၏ ကြီးမားသော အပလီကေးရှင်းများကို တစ်ခုနှင့်တစ်ခု အပြန်အလှန် ဆက်သွယ်နိုင်သော အစိတ်အပိုင်းငယ်များအဖြစ် ပိုင်းခြားသောအခါ။ ၎င်းသည် သင့်အား သီးခြားလုပ်ငန်းဆောင်တာတစ်ခုအတွက် နည်းပညာများကို ရွေးချယ်နိုင်စေပါသည်။ ၎င်းသည် သင့်အား developer များအကြား အလုပ်နှင့် တာဝန်ဧရိယာကို ပိုင်းခြားနိုင်စေပါသည်။

JS တွင်ဖော်ဆောင်နေသော frontend developer သည် backend ပေါ်တွင်သြဇာသက်ရောက်မှုမရှိသလောက်ဖြစ်သည်။ backend developer သည် ကျွန်ုပ်တို့၏အခြေအနေတွင် Ruby on Rails နှင့် Frondend ကို အနှောင့်အယှက်မပေးပေ။ API ကို အသုံးပြု၍ အပြန်အလှန်တုံ့ပြန်မှုကို လုပ်ဆောင်သည်။

ဘောနပ်စ်အနေဖြင့် Docker ကိုအသုံးပြု၍ Staging တွင် အရင်းအမြစ်များကို ပြန်လည်အသုံးပြုနိုင်ခဲ့သည်။ ပရောဂျက်တစ်ခုစီသည် ၎င်း၏အသေးစိတ်အချက်များကြောင့် အချို့သောဆက်တင်များ လိုအပ်သည်။ ရုပ်ပိုင်းဆိုင်ရာအားဖြင့်၊ ၎င်းသည် virtual server တစ်ခုခုကို ခွဲဝေပြီး သီးခြားစီ စီစဉ်ရန် လိုအပ်သည်၊ သို့မဟုတ် အချို့သော ပြောင်းလဲနိုင်သော ပတ်ဝန်းကျင်ကို ပိုင်းခြားရန်နှင့် စာကြည့်တိုက်များ၏ ဗားရှင်းပေါ်မူတည်၍ အချင်းချင်း လွှမ်းမိုးနိုင်သည့် ပရောဂျက်များ လိုအပ်ပါသည်။

ကိရိယာများ။ ဘာကိုသုံးမှာလဲ?

• Docker ကိုယ်တိုင်။ Dockerfile သည် အပလီကေးရှင်းတစ်ခုတည်း၏ မှီခိုမှုကို ဖော်ပြသည်။
• Docker-compose သည် ကျွန်ုပ်တို့၏ Docker အပလီကေးရှင်းများစွာကို စုစည်းထားသော အတွဲတစ်ခုဖြစ်သည်။
• ကျွန်ုပ်တို့သည် အရင်းအမြစ်ကုဒ်ကို သိမ်းဆည်းရန် GitLab ကို အသုံးပြုသည်။
• စနစ်ပေါင်းစည်းရန်အတွက် ကျွန်ုပ်တို့သည် GitLab-CI ကိုအသုံးပြုသည်။

အစီရင်ခံစာတွင် အပိုင်းနှစ်ပိုင်းပါဝင်သည်။

ပထမအပိုင်းသည် developer များ၏စက်များတွင် Docker ကိုမည်သို့လုပ်ဆောင်ရမည်ကိုပြောပြလိမ့်မည်။

ဒုတိယအပိုင်းတွင် GitLab နှင့် မည်သို့အပြန်အလှန်ဆက်ဆံရမည်၊ စစ်ဆေးမှုများလုပ်ဆောင်ပုံနှင့် Staging သို့ မည်သို့လုပ်ဆောင်ရမည်ကို ဆွေးနွေးပါမည်။

Docker သည် လိုအပ်သောအစိတ်အပိုင်းများကိုဖော်ပြရန် (ကြေငြာချဉ်းကပ်နည်းကိုအသုံးပြု၍) ခွင့်ပြုသောနည်းပညာတစ်ခုဖြစ်သည်။ ဒါက ဥပမာ Dockerfile တစ်ခုပါ။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် Ruby:2.3.0 ၏တရားဝင် Docker ပုံမှ အမွေဆက်ခံနေပြီဖြစ်ကြောင်း ကြေညာပါသည်။ ၎င်းတွင် Ruby ဗားရှင်း 2.3 ထည့်သွင်းထားသည်။ ကျွန်ုပ်တို့သည် လိုအပ်သော စည်းဝေးပွဲစာကြည့်တိုက်များနှင့် NodeJS ကို တပ်ဆင်သည်။ ကျွန်ုပ်တို့သည် လမ်းညွှန်တစ်ခု ဖန်တီးနေကြောင်း ဖော်ပြပါသည်။ /app. ကျွန်ုပ်တို့သည် အက်ပ်လမ်းညွှန်ကို အလုပ်လမ်းညွှန်အဖြစ် သတ်မှတ်ပေးသည်။ ဤလမ်းညွှန်တွင် ကျွန်ုပ်တို့သည် လိုအပ်သော အနည်းဆုံး Gemfile နှင့် Gemfile.lock ကို ထားရှိသည်။ ထို့နောက် ဤမှီခိုပုံအား ထည့်သွင်းသည့် ပရောဂျက်များကို တည်ဆောက်ပါသည်။ ကွန်တိန်နာသည် ပြင်ပ port 3000 တွင် နားဆင်ရန်အဆင်သင့်ဖြစ်မည်ဟု ကျွန်ုပ်တို့ညွှန်ပြပါသည်။ နောက်ဆုံးအမိန့်မှာ ကျွန်ုပ်တို့၏အပလီကေးရှင်းကို တိုက်ရိုက်ဖွင့်သည့်အမိန့်ဖြစ်သည်။ အကယ်၍ ကျွန်ုပ်တို့သည် ပရောဂျက်လုပ်ဆောင်ခြင်းအမိန့်ကို လုပ်ဆောင်ပါက၊ အပလီကေးရှင်းသည် သတ်မှတ်ထားသော အမိန့်ကို လည်ပတ်လုပ်ဆောင်ရန် ကြိုးစားမည်ဖြစ်သည်။

၎င်းသည် docker-compose ဖိုင်တစ်ခု၏ အနည်းငယ်မျှသာ ဥပမာတစ်ခုဖြစ်သည်။ ဤကိစ္စတွင်၊ ကွန်တိန်နာနှစ်ခုကြားတွင် ချိတ်ဆက်မှုရှိကြောင်း ပြသပါသည်။ ၎င်းသည် ဒေတာဘေ့စ်ဝန်ဆောင်မှုနှင့် ဝဘ်ဝန်ဆောင်မှုသို့ တိုက်ရိုက်ဖြစ်သည်။ ကျွန်ုပ်တို့၏ ဝဘ်အက်ပလီကေးရှင်းအများစုတွင် ဒေတာသိမ်းဆည်းရန်အတွက် နောက်ကွယ်တွင် ဒေတာဘေ့စ်တစ်မျိုးမျိုး လိုအပ်ပါသည်။ ကျွန်ုပ်တို့သည် MySQL ကိုအသုံးပြုသောကြောင့်၊ ဥပမာသည် MySQL ဖြင့်ဖြစ်သည် - သို့သော် အခြားဒေတာဘေ့စ်အချို့ (PostgreSQL၊ Redis) ကိုအသုံးပြုခြင်းမှ ကျွန်ုပ်တို့အား မည်သည့်အရာကမှ တားဆီးထားသည်။

Docker hub မှတရားဝင်အရင်းအမြစ်မှပြောင်းလဲမှုမရှိဘဲ MySQL 5.7.14 ပုံကိုယူသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝဘ်အပလီကေးရှင်းအတွက် တာဝန်ရှိသော ပုံကို လက်ရှိလမ်းညွှန်မှ စုဆောင်းပါသည်။ ပထမအကြိမ် လွှတ်တင်ချိန်တွင် ကျွန်ုပ်တို့အတွက် ပုံတစ်ပုံကို စုဆောင်းသည်။ ထို့နောက် ကျွန်ုပ်တို့ ဤနေရာတွင် လုပ်ဆောင်နေသော command ကို run သည်။ ကျွန်ုပ်တို့ပြန်သွားပါက၊ Puma မှတစ်ဆင့် launch command ကိုသတ်မှတ်ထားကြောင်းတွေ့ရပါမည်။ Puma သည် Ruby ဖြင့်ရေးသားထားသောဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ ဒုတိယကိစ္စတွင်ကျွန်ုပ်တို့ထပ်ရေးသည်။ ဤအမိန့်သည် ကျွန်ုပ်တို့၏လိုအပ်ချက် သို့မဟုတ် လုပ်ဆောင်ချက်များအပေါ် မူတည်၍ မထင်သလိုဖြစ်နိုင်သည်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ developer host machine တွင် port ကို 3000 မှ 3000 container port သို့ပေးပို့ရန်လိုအပ်ကြောင်းဖော်ပြပါသည်။ Docker တွင် တိုက်ရိုက်ထည့်သွင်းထားသည့် iptables နှင့် ၎င်း၏ကိုယ်ပိုင်ယန္တရားတို့ကို အသုံးပြု၍ ၎င်းကို အလိုအလျောက်လုပ်ဆောင်သည်။

ဆော့ဖ်ဝဲရေးသားသူသည် ယခင်ကဲ့သို့ပင်၊ ရရှိနိုင်သော IP လိပ်စာ၊ ဥပမာ၊ 127.0.0.1 စက်၏ ဒေသတွင်း သို့မဟုတ် ပြင်ပ IP လိပ်စာကို ရယူနိုင်သည်။

နောက်ဆုံးစာကြောင်းက ဝဘ်ကွန်တိန်နာသည် db ကွန်တိန်နာပေါ်တွင် မူတည်သည်ဟု ဆိုသည်။ ဝဘ်ကွန်တိန်နာကို စတင်ရန် ကျွန်ုပ်တို့ခေါ်ဆိုသောအခါ၊ docker-compose သည် ကျွန်ုပ်တို့အတွက် ဒေတာဘေ့စ်ကို ဦးစွာ စတင်ပါမည်။ ဒေတာဘေ့စ်စတင်ချိန်တွင်ဖြစ်နေပြီ (တကယ်တော့ ကွန်တိန်နာကို လွှင့်တင်ပြီးနောက်၊ ၎င်းသည် ဒေတာဘေ့စ်၏ အဆင်သင့်ဖြစ်မှုကို အာမမခံနိုင်ပါ) ၎င်းသည် ကျွန်ုပ်တို့၏ အက်ပ်လီကေးရှင်း၊ ကျွန်ုပ်တို့၏ နောက်ခံဖိုင်ကို စတင်ပါမည်။

၎င်းသည် ဒေတာဘေ့စ်မတက်သည့်အခါ အမှားအယွင်းများကို ရှောင်ရှားနိုင်စေပြီး ဒေတာဘေ့စ်ကွန်တိန်နာကို ရပ်တန့်လိုက်သည့်အခါ အရင်းအမြစ်များကို သိမ်းဆည်းနိုင်စေကာ အခြားပရောဂျက်များအတွက် အရင်းအမြစ်များကို ဖယ်ရှားပေးနိုင်သည်။

ပရောဂျက်တစ်ခုတွင် database dockerization ကိုအသုံးပြုခြင်းသည် ကျွန်ုပ်တို့အား အဘယ်အရာပေးသနည်း။ developer အားလုံးအတွက် MySQL ဗားရှင်းကို ကျွန်ုပ်တို့ မှတ်တမ်းတင်ပါသည်။ ၎င်းသည် ဗားရှင်းများ ကွဲပြားသည့်အခါ၊ အထားအသို၊ ဖွဲ့စည်းမှုနှင့် ပုံသေဆက်တင်များ ပြောင်းလဲသည့်အခါ ဖြစ်ပေါ်လာနိုင်သည့် အမှားအယွင်းအချို့ကို ရှောင်ရှားနိုင်စေမည်ဖြစ်သည်။ ၎င်းသည် သင့်အား ဒေတာဘေ့စ်၊ လော့ဂ်အင်၊ စကားဝှက်အတွက် ဘုံအိမ်ရှင်အမည်ကို သတ်မှတ်ခွင့်ပြုသည်။ ကျွန်ုပ်တို့သည် ယခင်ကရှိခဲ့သည့် config ဖိုင်များတွင် အမည်များနှင့် ကွဲလွဲမှုများကို တိရစ္ဆာန်ရုံမှ ဝေးရာသို့ ပြောင်းရွှေ့နေပါသည်။

ကျွန်ုပ်တို့သည် မူလပုံစံနှင့် ကွဲပြားမည့် ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်အတွက် ပိုမိုသင့်လျော်သောပုံစံကို အသုံးပြုရန် အခွင့်အရေးရှိသည်။ MySQL သည် အားနည်းသော စက်များအတွက် ပုံသေဖြင့် configure ပြုလုပ်ထားပြီး ဘောက်စ်ပြင်ပမှ ၎င်း၏စွမ်းဆောင်ရည်မှာ အလွန်နိမ့်ပါသည်။

Docker သည် သင့်အား လိုချင်သောဗားရှင်း၏ Python, Ruby, NodeJS, PHP ဘာသာပြန်ကို အသုံးပြုခွင့်ပေးသည်။ ကျွန်ုပ်တို့သည် ဗားရှင်းမန်နေဂျာတစ်မျိုးမျိုးကို အသုံးပြုရန် လိုအပ်မှုကို ဖယ်ရှားပစ်လိုက်သည်။ ယခင်က၊ ပရောဂျက်အပေါ် မူတည်၍ ဗားရှင်းကို ပြောင်းလဲခွင့်ပြုသည့် Ruby အတွက် rpm ပက်ကေ့ဂျ်ကို ယခင်က အသုံးပြုခဲ့သည်။ Docker ကွန်တိန်နာကြောင့်၊ ၎င်းသည် ကုဒ်ကို ချောမွေ့စွာ ရွှေ့ပြောင်းနိုင်ပြီး မှီခိုမှုနှင့်အတူ ၎င်းကို ဗားရှင်းပြောင်းနိုင်စေပါသည်။ စကားပြန်နှင့် ကုဒ်နှစ်ခုစလုံး၏ ဗားရှင်းကို နားလည်ရန် ပြဿနာမရှိပါ။ ဗားရှင်းကို အပ်ဒိတ်လုပ်ရန်၊ သင်သည် ကွန်တိန်နာဟောင်းကို လျှော့ချပြီး ကွန်တိန်နာအသစ်ကို မြှင့်တင်ရန် လိုအပ်သည်။ တစ်ခုခုမှားသွားရင် ကွန်တိန်နာအသစ်ကို နှိမ့်ချပြီး ကွန်တိန်နာဟောင်းကို မြှင့်တင်နိုင်ပါတယ်။

ရုပ်ပုံတည်ဆောက်ပြီးနောက်၊ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် ထုတ်လုပ်မှု နှစ်ခုစလုံးတွင် ကွန်တိန်နာများသည် တူညီမည်ဖြစ်သည်။ အထူးသဖြင့် ကြီးမားသော တပ်ဆင်မှုများအတွက် ဤသည်မှာ မှန်ပါသည်။

Frontend တွင်ကျွန်ုပ်တို့သည် JavaScipt နှင့် NodeJS ကိုအသုံးပြုသည်။

ယခု ကျွန်ုပ်တို့တွင် ReacJS တွင် ကျွန်ုပ်တို့၏ နောက်ဆုံးပရောဂျက်ရှိသည်။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာသည် ကွန်တိန်နာအတွင်းရှိ အရာအားလုံးကို စတင်ခဲ့ပြီး hot-reload ကို အသုံးပြု၍ တီထွင်ခဲ့သည်။

ထို့နောက်၊ JavaScipt တပ်ဆင်ခြင်းလုပ်ငန်းကို စတင်ခဲ့ပြီး အရင်းအမြစ်များကို သိမ်းဆည်းကာ nginx မှတဆင့် ကိန်းဂဏန်းဖြင့် စုစည်းထားသော ကုဒ်ကို ပေးပို့သည်။

ဤတွင်ကျွန်ုပ်တို့၏နောက်ဆုံးပေါ်ပရောဂျက်တစ်ခုအား ကျွန်ုပ်တင်ပြထားပါသည်။

ဘယ်လိုပြဿနာတွေကို သင်ဖြေရှင်းခဲ့လဲ။ ကျွန်ုပ်တို့သည် မိုဘိုင်းလ်စက်ပစ္စည်းများနှင့် အပြန်အလှန် အကျိုးပြုသည့် စနစ်တစ်ခုကို တည်ဆောက်ရန် လိုအပ်ပါသည်။ ဒေတာလက်ခံရယူကြသည်။ ဖြစ်နိုင်ချေများထဲမှတစ်ခုမှာ ဤစက်ပစ္စည်းသို့ တွန်းအားပေးအကြောင်းကြားချက်များကို ပေးပို့ရန်ဖြစ်သည်။

ဒီအတွက် ငါတို့ဘာလုပ်ခဲ့လဲ။

ကျွန်ုပ်တို့သည် အပလီကေးရှင်းအား အောက်ပါအစိတ်အပိုင်းများအဖြစ် ပိုင်းခြားထားသည်- JS ရှိ စီမံခန့်ခွဲသူအပိုင်း၊ Ruby on Rails အောက်ရှိ REST အင်တာဖေ့စ်မှတဆင့် အလုပ်လုပ်သော နောက်ခံဖိုင်။ Backend သည် ဒေတာဘေ့စ်နှင့် အပြန်အလှန်အကျိုးသက်ရောက်သည်။ ထုတ်ပေးသောရလဒ်ကို client ကိုပေးသည်။ စီမံခန့်ခွဲသူအကန့်သည် REST အင်တာဖေ့စ်မှတဆင့် နောက်ကွယ်မှ ဒေတာဘေ့စ်နှင့် အပြန်အလှန်တုံ့ပြန်သည်။

Push အကြောင်းကြားချက်များကို ပေးပို့ရန်လည်း လိုအပ်ပါသည်။ ယင်းမတိုင်မီတွင်၊ ကျွန်ုပ်တို့သည် မိုဘိုင်းပလက်ဖောင်းများသို့ အသိပေးချက်များကို ပေးပို့ရန် တာဝန်ရှိသည့် ယန္တရားတစ်ခုကို အကောင်အထည်ဖေါ်ခဲ့သည့် ပရောဂျက်တစ်ခုရှိခဲ့သည်။

ကျွန်ုပ်တို့သည် အောက်ပါအစီအစဥ်ကို တီထွင်ထားပါသည်- ဘရောက်ဆာမှ အော်ပရေတာသည် စီမံခန့်ခွဲသူအကန့်နှင့် အပြန်အလှန်တုံ့ပြန်သည်၊ စီမံခန့်ခွဲသူဘောင်သည် နောက်ခံဖိုင်နှင့် အပြန်အလှန်တုံ့ပြန်သည်၊ အလုပ်မှာ Push အကြောင်းကြားချက်များကို ပေးပို့ရန်ဖြစ်သည်။

Push အကြောင်းကြားချက်များသည် NodeJS တွင်အကောင်အထည်ဖော်သည့် အခြားအစိတ်အပိုင်းနှင့် အပြန်အလှန်အကျိုးသက်ရောက်သည်။

တန်းစီဇယားများကို တည်ဆောက်ပြီး ၎င်းတို့၏ ကိုယ်ပိုင်ယန္တရားအရ အကြောင်းကြားချက်များကို ပေးပို့သည်။

ဤနေရာတွင် ဒေတာဘေ့စ်နှစ်ခုကို ရေးဆွဲထားသည်။ လက်ရှိတွင်၊ Docker ကို အသုံးပြု၍ ကျွန်ုပ်တို့သည် တစ်ခုနှင့်တစ်ခု ချိတ်ဆက်၍မရသော သီးခြားဒေတာဘေ့စ် 2 ခုကို အသုံးပြုပါသည်။ ၎င်းတို့တွင် ဘုံ virtual network တစ်ခုရှိခြင်းအပြင်၊ ဆော့ဖ်ဝဲရေးသားသူ၏စက်ရှိ မတူညီသောလမ်းကြောင်းများတွင် ရုပ်ပိုင်းဆိုင်ရာဒေတာများကို သိမ်းဆည်းထားသည်။

တူညီသောအချက်မှာ ကိန်းဂဏန်းများဖြစ်သည်။ ဤနေရာတွင် ကုဒ်ကို ပြန်သုံးရန် အရေးကြီးသည်။

အစောပိုင်းက ကျွန်ုပ်တို့သည် စာကြည့်တိုက်များပုံစံဖြင့် ကုဒ်ကို ပြန်လည်အသုံးပြုခြင်းအကြောင်း ပြောဆိုခဲ့လျှင် Push အသိပေးချက်များကို တုံ့ပြန်သည့် ဤဥပမာတွင် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုကို ပြီးပြည့်စုံသော ဆာဗာအဖြစ် ပြန်လည်အသုံးပြုပါသည်။ ၎င်းသည် API ကိုထောက်ပံ့ပေးသည်။ ကျွန်ုပ်တို့၏ ဖွံ့ဖြိုးတိုးတက်မှုအသစ်သည် ၎င်းနှင့် အကျိုးသက်ရောက်သည်။

ထိုအချိန်တွင် ကျွန်ုပ်တို့သည် NodeJS ၏ ဗားရှင်း 4 ကို အသုံးပြုနေပါသည်။ ယခု (2017 တွင် - တည်းဖြတ်သူ၏မှတ်စု) သည် ကျွန်ုပ်တို့၏နောက်ဆုံးပေါ်တိုးတက်မှုများတွင် NodeJS ဗားရှင်း 7 ကိုအသုံးပြုသည်။ စာကြည့်တိုက်များ၏ ဗားရှင်းအသစ်များပါ၀င်ရန် အစိတ်အပိုင်းအသစ်များတွင် ပြဿနာမရှိပါ။

လိုအပ်ပါက၊ သင်သည် Push အသိပေးချက်ဝန်ဆောင်မှု၏ NodeJS ဗားရှင်းကို ပြန်လည်ပြင်ဆင်ပြီး မြှင့်တင်နိုင်သည်။

API ၏ လိုက်ဖက်ညီမှုကို ထိန်းသိမ်းထားနိုင်ပါက ၎င်းကို ယခင်က အသုံးပြုခဲ့သည့် အခြားပရောဂျက်များနှင့် အစားထိုးရန် ဖြစ်နိုင်ပါမည်။

Docker ထည့်ဖို့ ဘာတွေလိုအပ်လဲ။ ကျွန်ုပ်တို့သည် လိုအပ်သော မှီခိုမှုကို ဖော်ပြသည့် ကျွန်ုပ်တို့၏ သိုလှောင်ခန်းသို့ Dockerfile ကို ပေါင်းထည့်ပါသည်။ ဤဥပမာတွင်၊ အစိတ်အပိုင်းများကို ယုတ္တိနည်းကျကျ ပိုင်းခြားထားသည်။ ဤသည်မှာ နောက်ခံဆော့ဖ်ဝဲရေးသားသူအတွက် အနည်းဆုံး အစုံဖြစ်သည်။

ပရောဂျက်အသစ်တစ်ခုဖန်တီးသောအခါတွင်၊ ကျွန်ုပ်တို့သည် Dockerfile တစ်ခုကိုဖန်တီးပြီး လိုချင်သောဂေဟစနစ် (Python၊ Ruby၊ NodeJS) ကိုဖော်ပြပါသည်။ docker-compose တွင်၊ ၎င်းသည် လိုအပ်သော မှီခိုမှု - ဒေတာဘေ့စ်ကို ဖော်ပြသည်။ ဒေတာသိမ်းဆည်းရန်အတွက် ထိုနေရာတွင် ဒေတာသိမ်းဆည်းရန် ထိုကဲ့သို့သော ဗားရှင်းတစ်ခု၏ ဒေတာဘေ့စ်တစ်ခု လိုအပ်ကြောင်း ဖော်ပြပါသည်။

ကျွန်ုပ်တို့သည် တည်ငြိမ်သောအကြောင်းအရာကို ဆောင်ရွက်ပေးရန်အတွက် nginx ပါသော သီးခြားတတိယပုံးကို အသုံးပြုပါသည်။ ဓါတ်ပုံတွေ တင်လို့ရပါတယ်။ Backend သည် ၎င်းတို့အား တည်ငြိမ်ဒေတာကို ပံ့ပိုးပေးသည့် nginx ပါသည့် ကွန်တိန်နာတစ်ခုတွင် တပ်ဆင်ထားသည့် ကြိုတင်ပြင်ဆင်ထားသော အသံအတိုးအကျယ်တစ်ခုတွင် ထည့်သွင်းထားသည်။

nginx နှင့် mysql configuration ကို သိမ်းဆည်းရန်အတွက် လိုအပ်သော configuration များကို သိမ်းဆည်းထားသည့် Docker folder ကို ပေါင်းထည့်ခဲ့ပါသည်။ ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦးသည် ၎င်း၏စက်တွင် သိုလှောင်မှုတစ်ခု၏ git clone တစ်ခုကို ပြုလုပ်သောအခါ၊ သူ့တွင် ဒေသဖွံ့ဖြိုးရေးအတွက် ပရောဂျက်တစ်ခု အဆင်သင့်ရှိနေပြီဖြစ်သည်။ မည်သည့်ဆိပ်ကမ်း သို့မဟုတ် မည်သည့်ဆက်တင်များကို အသုံးပြုရမည်နှင့်ပတ်သက်၍ မေးခွန်းထုတ်စရာမရှိပါ။

နောက်တစ်ခုတွင် ကျွန်ုပ်တို့တွင် အစိတ်အပိုင်းများစွာရှိသည်- စီမံခန့်ခွဲသူ၊ အချက်အလက်-API၊ တွန်းအားပေး အသိပေးချက်များ။

ဤအရာအားလုံးကို စတင်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် dockerized-app ဟုခေါ်သော အခြား repository တစ်ခုကို ဖန်တီးခဲ့သည်။ ကျွန်ုပ်တို့သည် အစိတ်အပိုင်းတစ်ခုစီအတွက် သိုလှောင်မှုအများအပြားကို လက်ရှိအသုံးပြုနေသည်။ ၎င်းတို့သည် ရိုးရိုးရှင်းရှင်း ယုတ္တိနည်းဖြင့် ကွဲပြားသည် - GitLab တွင် ၎င်းသည် ဖိုဒါတစ်ခုနှင့်တူသော်လည်း developer ၏စက်တွင် ၎င်းသည် သီးခြားပရောဂျက်တစ်ခုအတွက် ဖိုင်တွဲတစ်ခုနှင့်တူသည်။ အောက်ပါအဆင့်တစ်ခုသည် ပေါင်းစပ်မည့် အစိတ်အပိုင်းများဖြစ်သည်။

ဤသည်မှာ dockerized-app ၏ အကြောင်းအရာများ ဥပမာတစ်ခုဖြစ်သည်။ အစိတ်အပိုင်းအားလုံး၏ အပြန်အလှန်ဆက်သွယ်မှုများအတွက် လိုအပ်သော ဖွဲ့စည်းမှုပုံစံများကို ဖြည့်ပေးသည့် Docker လမ်းညွှန်ကို ဤနေရာတွင် ထားရှိပါမည်။ ပရောဂျက်ကို ဘယ်လိုစတင်ရမလဲဆိုတာ အတိုချုပ်ဖော်ပြထားတဲ့ README.md တစ်ခုရှိပါတယ်။

ဤတွင် ကျွန်ုပ်တို့သည် docker-compose ဖိုင်နှစ်ခုကို အသုံးပြုထားသည်။ အဆင့်ဆင့် လွှင့်တင်နိုင်စေရန်အတွက် လုပ်ဆောင်သည်။ developer သည် kernel နှင့်အလုပ်လုပ်သောအခါ၊ သူသည် Push အကြောင်းကြားချက်များကိုမလိုအပ်ဘဲ၊ သူသည် docker-compose ဖိုင်ကိုရိုးရှင်းစွာဖွင့်လိုက်ပြီး၊ ထို့ကြောင့်အရင်းအမြစ်များကိုသိမ်းဆည်းထားသည်။

Push အသိပေးချက်များနှင့် ပေါင်းစည်းရန် လိုအပ်ပါက၊ ထို့နောက် docker-compose.yaml နှင့် docker-compose-push.yaml ကို စတင်လိုက်ပါသည်။

docker-compose.yaml နှင့် docker-compose-push.yaml ဖိုင်တွဲတွင် ရှိနေသောကြောင့်၊ virtual network တစ်ခုတည်းကို အလိုအလျောက် ဖန်တီးပါသည်။

အစိတ်အပိုင်းများ၏ဖော်ပြချက်။ ဤအရာသည် အစိတ်အပိုင်းများကို စုဆောင်းရန်အတွက် တာဝန်ရှိသော ပိုမိုအဆင့်မြင့်သောဖိုင်တစ်ခုဖြစ်သည်။ ဒီမှာ ဘာထူးခြားလဲ။ ဒီနေရာမှာ Balancer အစိတ်အပိုင်းကို မိတ်ဆက်ပေးပါမယ်။

၎င်းသည် nginx နှင့် Docker socket ကို နားထောင်သည့် အဆင်သင့်လုပ်ထားသည့် Docker ပုံဖြစ်သည်။ ကွန်တိန်နာများကို အဖွင့်အပိတ်လုပ်ထားသည့်အတွက် Dynamic၊ nginx config ကို ပြန်လည်ထုတ်ပေးပါသည်။ ကျွန်ုပ်တို့သည် တတိယအဆင့် ဒိုမိန်းအမည်များကို အသုံးပြု၍ အစိတ်အပိုင်းများ၏ ကိုင်တွယ်မှုကို ဖြန့်ဝေပါသည်။

ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်အတွက် ကျွန်ုပ်တို့သည် .dev ဒိုမိန်း - api.informer.dev ကို အသုံးပြုသည်။ .dev ဒိုမိန်းပါရှိသော အပလီကေးရှင်းများကို ဆော့ဖ်ဝဲရေးသားသူ၏ စက်တွင်းစက်တွင် ရနိုင်ပါသည်။

ထို့နောက် configs များကို ပရောဂျက်တစ်ခုစီသို့ လွှဲပြောင်းပြီး ပရောဂျက်အားလုံးကို တစ်ပြိုင်နက်တည်း စတင်လုပ်ဆောင်သည်။

၎င်းကို ဂရပ်ဖစ်ဖြင့် သရုပ်ဖော်ပါက၊ client သည် ကျွန်ုပ်တို့၏ browser သို့မဟုတ် balancer သို့ ကျွန်ုပ်တို့ တောင်းဆိုမှုပြုလုပ်သည့် tool တစ်မျိုးဖြစ်ကြောင်း ပေါ်လွင်ပါသည်။

ဒိုမိန်းအမည်ကို အခြေခံ၍ မည်သည့်ကွန်တိန်နာကို ဝင်ရောက်ရန် လိုအပ်သည်ကို ချိန်ခွင်လျှာမှ ဆုံးဖြတ်သည်။

၎င်းသည် စီမံခန့်ခွဲသူအကန့်သို့ JS ကို ပံ့ပိုးပေးသည့် nginx ဖြစ်နိုင်သည်။ nginx သည် ပုံများကိုတင်သည့်ပုံစံဖြင့် nginx မှပံ့ပိုးပေးသော API သို့မဟုတ် static ဖိုင်များကို ပံ့ပိုးပေးသော nginx ဖြင့်လုပ်ဆောင်နိုင်သည်။

ပုံးသည် ကွန်တိန်နာများကို virtual network တစ်ခုနှင့်ချိတ်ဆက်ထားပြီး proxy နောက်ကွယ်တွင်ဝှက်ထားကြောင်းပြသသည်။

developer ၏စက်တွင် IP ကိုသိသော container ကိုသင်ဝင်ရောက်နိုင်သည်၊ သို့သော်မူအရအားဖြင့်၎င်းကိုကျွန်ုပ်တို့အသုံးမပြုပါ။ လက်တွေ့တွင် တိုက်ရိုက်ထိတွေ့ရန် မလိုအပ်ပါ။

ကျွန်ုပ်၏အပလီကေးရှင်းကို dockerize ပြုလုပ်ရန် အဘယ်ဥပမာကို ကြည့်ရှုသင့်သနည်း။ ကျွန်တော့်အမြင်အရ၊ ဥပမာကောင်းတစ်ခုသည် MySQL အတွက်တရားဝင် docker ပုံဖြစ်သည်။

တော်တော်ရှုပ်ထွေးပါတယ်။ ဗားရှင်းများစွာရှိပါတယ်။ သို့သော် ၎င်း၏လုပ်ဆောင်နိုင်စွမ်းသည် သင့်အား နောက်ထပ်ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်တွင် ဖြစ်ပေါ်လာနိုင်သည့် လိုအပ်ချက်များစွာကို ဖြည့်ဆည်းပေးနိုင်သည်။ သင်အချိန်ယူ၍ ၎င်းသည် မည်ကဲ့သို့ အပြန်အလှန်အကျိုးသက်ရောက်သည်ကို နားလည်ပါက၊ ၎င်းကို သင်ကိုယ်တိုင် အကောင်အထည်ဖော်ရာတွင် ပြဿနာတစ်စုံတစ်ရာရှိမည်မဟုတ်ဟု ကျွန်ုပ်ထင်ပါတယ်။

Hub.docker.com တွင် ပုံတစ်ပုံကို ကိုယ်တိုင်တည်ဆောက်နိုင်သည့် ဒေတာအကြမ်းကို တိုက်ရိုက်ပေးသည့် github.com နှင့် လင့်ခ်များ ပါတတ်သည်။

ထို့အပြင် ဤသိုလှောင်ခန်းတွင် ကနဦးအစပြုခြင်းနှင့် အပလီကေးရှင်းစတင်ခြင်း၏နောက်ထပ်လုပ်ဆောင်ခြင်းအတွက် တာဝန်ရှိသော script docker-endpoint.sh ရှိပါသည်။

ထို့အပြင် ဤဥပမာတွင် ပတ်ဝန်းကျင် ကိန်းရှင်များကို အသုံးပြု၍ configuration လုပ်ရန် ဖြစ်နိုင်ခြေရှိသည်။ ကွန်တိန်နာတစ်ခုတည်းကိုအသုံးပြုသည့်အခါ သို့မဟုတ် docker-compose မှတစ်ဆင့်၊ ကျွန်ုပ်တို့သည် MySQL တွင် root အတွက် docker အတွက် ဗလာစကားဝှက်တစ်ခု သတ်မှတ်ရန် လိုအပ်သည်ဟု ပြောနိုင်သည်။

ကျပန်းစကားဝှက်တစ်ခုဖန်တီးရန် ရွေးချယ်ခွင့်တစ်ခုရှိသည်။ ကျွန်ုပ်တို့သည် သုံးစွဲသူတစ်ဦး လိုအပ်သည်ဟု ဆိုသည်၊ အသုံးပြုသူအတွက် စကားဝှက်တစ်ခု သတ်မှတ်ရန် လိုအပ်ပြီး ဒေတာဘေ့စ်တစ်ခု ဖန်တီးရန် လိုအပ်သည်ဟု ကျွန်ုပ်တို့ပြောပါသည်။

ကျွန်ုပ်တို့၏ ပရောဂျက်များတွင်၊ ကျွန်ုပ်တို့သည် အစပြုခြင်းအတွက် တာဝန်ရှိသော Dockerfile ကို အနည်းငယ် ပေါင်းစည်းထားပါသည်။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် အပလီကေးရှင်းအသုံးပြုသည့် သုံးစွဲသူအခွင့်အရေးများကို ရိုးရှင်းစွာချဲ့ထွင်ရန် ကျွန်ုပ်တို့၏လိုအပ်ချက်များနှင့် ချိန်ညှိထားပါသည်။ ၎င်းသည် အနာဂတ်တွင် အပလီကေးရှင်းကွန်ဆိုးလ်မှ ဒေတာဘေ့စ်တစ်ခုကို ရိုးရိုးရှင်းရှင်း ဖန်တီးနိုင်စေခဲ့သည်။ Ruby အပလီကေးရှင်းများတွင် ဒေတာဘေ့စ်များကို ဖန်တီးခြင်း၊ ပြင်ဆင်ခြင်းနှင့် ဖျက်ခြင်းအတွက် အမိန့်များရှိသည်။

ဤသည်မှာ github.com တွင် MySQL ၏ သီးခြားဗားရှင်းနှင့် မည်သို့တူကြောင်း ဥပမာတစ်ခုဖြစ်သည်။ Dockerfile ကိုဖွင့်ပြီး install လုပ်ပုံလုပ်ပုံကိုကြည့်နိုင်ပါတယ်။

docker-endpoint.sh script သည် entry point အတွက် တာဝန်ရှိသည်။ ကနဦးအစပျိုးချိန်အတွင်း၊ အချို့သောပြင်ဆင်မှုလုပ်ဆောင်ချက်များ လိုအပ်ပြီး ဤလုပ်ဆောင်မှုများအားလုံးကို ကနဦးစခရစ်တွင် ထည့်သွင်းထားသည်။

ဒုတိယအပိုင်းကို ဆက်သွားရအောင်။

အရင်းအမြစ်ကုဒ်များကို သိမ်းဆည်းရန် gitlab သို့ ပြောင်းခဲ့သည်။ ၎င်းသည် အမြင်အာရုံခံစနစ်ပါရှိသော အတော်လေး အားကောင်းသည့် စနစ်တစ်ခုဖြစ်သည်။

Gitlab အစိတ်အပိုင်းတစ်ခုသည် Gitlab CI ဖြစ်သည်။ ၎င်းသည် သင့်အား ကုဒ်ပေးပို့မှုစနစ်အား စုစည်းရန် သို့မဟုတ် အလိုအလျောက်စမ်းသပ်ခြင်းကို လုပ်ဆောင်ရန် နောက်ဆက်တွဲတွင် အသုံးပြုမည့် ညွှန်ကြားချက်များကို ဆက်တိုက်ဖော်ပြရန် ခွင့်ပြုသည်။

Gitlab CI 2 ကို အစီရင်ခံပါ။ https://goo.gl/uohKjI - Ruby Russia ကလပ်မှ အစီရင်ခံစာသည် အလွန်အသေးစိတ်ရှိပြီး သင့်အတွက် စိတ်ဝင်စားဖွယ်ဖြစ်နိုင်ပါသည်။

ယခု ကျွန်ုပ်တို့သည် Gitlab CI ကိုဖွင့်ရန် လိုအပ်သည်များကို ကြည့်ရှုပါမည်။ Gitlab CI ကို စတင်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် ပရောဂျက်၏ အမြစ်တွင် .gitlab-ci.yml ဖိုင်ကို ထားရန် လိုအပ်ပါသည်။

ဤနေရာတွင် ကျွန်ုပ်တို့သည် စမ်းသပ်မှု၊ ဖြန့်ကျက်မှုကဲ့သို့သော ပြည်နယ်များ၏ ဆက်တိုက်လုပ်ဆောင်လိုကြောင်း ဖော်ပြထားပါသည်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ အပလီကေးရှင်း၏ docker-compose တည်ဆောက်မှုကို တိုက်ရိုက်ခေါ်ဆိုသော script များကို လုပ်ဆောင်ပါသည်။ ဒါက backend ရဲ့ ဥပမာတစ်ခုပါ။

ဒေတာဘေ့စ်ကိုပြောင်းလဲရန်နှင့် စမ်းသပ်မှုများလုပ်ဆောင်ရန် ရွှေ့ပြောင်းခြင်းများကို လုပ်ဆောင်ရန် လိုအပ်သည်ဟု ကျွန်ုပ်တို့ပြောပါသည်။

scripts များကိုမှန်ကန်စွာလုပ်ဆောင်ပြီး error code မပြန်ပါက၊ system သည် deployment ၏ဒုတိယအဆင့်သို့ရောက်ရှိသွားမည်ဖြစ်ပါသည်။

ဖြန့်ကျက်ခြင်းအဆင့်ကို လက်ရှိအဆင့်တွင် အကောင်အထည်ဖော်ဆောင်ရွက်လျက်ရှိသည်။ စက်ရပ်ခြင်းမရှိသော ပြန်လည်စတင်ခြင်းကို ကျွန်ုပ်တို့ မစီစဉ်ထားပေ။

ကျွန်ုပ်တို့သည် ကွန်တိန်နာအားလုံးကို အတင်းအကျပ် ငြှိမ်းသတ်ပြီး စမ်းသပ်နေစဉ် ပထမအဆင့်တွင် စုဆောင်းထားသော ကွန်တိန်နာအားလုံးကို ထပ်မံ၍ မြှင့်တင်ပါသည်။

လက်ရှိ ပြောင်းလဲနိုင်သော ပတ်ဝန်းကျင်အတွက် developer မှ ရေးသားထားသော ဒေတာဘေ့စ် ပြောင်းရွှေ့မှုများကို လုပ်ဆောင်ကြပါစို့။

၎င်းကို မာစတာဌာနခွဲတွင်သာ အသုံးချသင့်ကြောင်း သတိပြုပါ။

အခြားအကိုင်းအခက်ပြောင်းသည့်အခါ အလုပ်မလုပ်ပါ။

အကိုင်းအခက်များတစ်လျှောက် ဖြန့်ချိမှုများကို စုစည်းနိုင်သည်။

၎င်းကို ထပ်မံစုစည်းရန်၊ ကျွန်ုပ်တို့သည် Gitlab Runner ကို ထည့်သွင်းရန် လိုအပ်ပါသည်။

ဤအသုံးဝင်ပုံကို Golang ဖြင့်ရေးသားထားသည်။ မှီခိုမှုမလိုအပ်သော Golang ကမ္ဘာတွင်တွေ့ရလေ့ရှိသည့်ဖိုင်တစ်ခုတည်းဖြစ်သည်။

စတင်ချိန်တွင် ကျွန်ုပ်တို့သည် Gitlab Runner ကို စာရင်းသွင်းသည်။

ကျွန်ုပ်တို့သည် Gitlab ဝဘ်အင်တာဖေ့စ်တွင် သော့ကို လက်ခံရရှိပါသည်။

ထို့နောက် command line တွင် initialization command ကို ခေါ်သည်။

ဒိုင်ယာလော့မုဒ်တွင် Gitlab Runner ကို ပြင်ဆင်သတ်မှတ်ခြင်း (Shell၊ Docker၊ VirtualBox၊ SSH)

Gitlab Runner ရှိ ကုဒ်သည် .gitlab-ci.yml ဆက်တင်ပေါ်မူတည်၍ commit တစ်ခုစီတိုင်းတွင် လုပ်ဆောင်မည်ဖြစ်သည်။

ဝဘ်အင်တာဖေ့စ်ရှိ Gitlab တွင် ၎င်းကို မည်သို့မြင်နိုင်သနည်း။ GItlab CI ချိတ်ဆက်ပြီးနောက်၊ ကျွန်ုပ်တို့တွင် လက်ရှိတည်ဆောက်မှုအခြေအနေအား ပြသသည့် အလံတစ်ခုရှိသည်။

ပြီးခဲ့သော 4 မိနစ်ခန့်က စမ်းသပ်မှုများအားလုံးကို အောင်မြင်ပြီး ပြဿနာတစ်စုံတစ်ရာမဖြစ်စေဘဲ ကတိကဝတ်တစ်ခုပြုလုပ်ထားသည်ကို ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။

တည်ဆောက်မှုများကို အသေးစိတ်ကြည့်ရှုနိုင်ပါသည်။ ဒီနေရာမှာ ပြည်နယ်နှစ်ခု ဖြတ်သန်းပြီးသွားပြီလို့ မြင်ပါတယ်။ အဆင့်စစ်ဆေးမှုအခြေအနေနှင့် အသုံးချမှုအခြေအနေ။

အကယ်၍ ကျွန်ုပ်တို့သည် သီးခြားတည်ဆောက်မှုကို နှိပ်ပါက၊ .gitlab-ci.yml အရ လုပ်ငန်းစဉ်တွင် စတင်ခဲ့သော ကွန်ဆိုးလ်အထွက်ရှိမည်ဖြစ်သည်။

ဤသည်မှာ ကျွန်ုပ်တို့၏ ထုတ်ကုန်၏ ဇာတ်လမ်းပုံစံဖြစ်သည်။ အောင်မြင်တဲ့ ကြိုးပမ်းမှုတွေ ရှိနေတယ်လို့ မြင်ပါတယ်။ စာမေးပွဲများကို တင်သွင်းသောအခါတွင် ၎င်းတို့သည် နောက်တစ်ဆင့်သို့ မရွှေ့ဘဲ အဆင့်ဆင့်သော ကုဒ်ကို အပ်ဒိတ်မလုပ်ပါ။

docker ကို အကောင်အထည်ဖော်တဲ့အခါ ဇာတ်ခုံမှာ ဘယ်လိုပြဿနာတွေကို ဖြေရှင်းခဲ့လဲ။ ကျွန်ုပ်တို့၏စနစ်တွင် အစိတ်အပိုင်းများပါဝင်ပြီး စနစ်တစ်ခုလုံးမဟုတ်ဘဲ သိုလှောင်မှုတွင် မွမ်းမံထားသော အစိတ်အပိုင်းအချို့ကိုသာ ပြန်လည်စတင်ရန် လိုအပ်ပါသည်။

ဒါကိုလုပ်ဖို့၊ အရာအားလုံးကို သီးခြား folders တွေအဖြစ် ခွဲထုတ်ရမယ်။

ဒါကိုလုပ်ပြီးနောက်၊ Docker-compose သည် ဖိုဒါတစ်ခုစီအတွက် ၎င်း၏ကိုယ်ပိုင်ကွန်ရက်နေရာကို ဖန်တီးပြီး ၎င်း၏အိမ်နီးနားချင်း၏အစိတ်အပိုင်းများကို မမြင်ရသည့်အချက်နှင့် ပြဿနာတစ်ခုရှိခဲ့သည်။

သွားလာရန် Docker တွင် ကွန်ရက်ကို ကိုယ်တိုင်ဖန်တီးခဲ့သည်။ Docker-compose တွင် သင်သည် ဤပရောဂျက်အတွက် ထိုကဲ့သို့သော ကွန်ရက်ကို အသုံးပြုသင့်သည်ဟု ရေးသားထားသည်။

ထို့ကြောင့်၊ ဤ mesh မှစတင်သောအစိတ်အပိုင်းတစ်ခုစီသည် system ၏အခြားအစိတ်အပိုင်းများကိုမြင်သည်။

နောက်ပြဿနာမှာ ပရောဂျက်များစွာကြားတွင် အဆင့်ခွဲဝေခြင်းပင်ဖြစ်သည်။

ဒါတွေအားလုံးဟာ လှပပြီး ထုတ်လုပ်မှုနဲ့ အနီးစပ်ဆုံးဖြစ်တာကြောင့် WEB မှာ နေရာတိုင်းသုံးတဲ့ port 80 သို့မဟုတ် 443 ကို အသုံးပြုတာကောင်းပါတယ်။

ဒါကို ဘယ်လိုဖြေရှင်းခဲ့လဲ။ ကျွန်ုပ်တို့သည် ကြီးမားသော ပရောဂျက်များအားလုံးတွင် Gitlab Runner တစ်ဦးကို တာဝန်ပေးအပ်ခဲ့သည်။

Gitlab သည် သင့်အား ဖြန့်ဝေထားသော Gitlab Runners အများအပြားကို စတင်ခွင့်ပြုသည်၊ ၎င်းသည် အလုပ်အားလုံးကို ဖရိုဖရဲဖြစ်စေပြီး ၎င်းတို့ကို တစ်ခုပြီးတစ်ခု လုပ်ဆောင်စေမည်ဖြစ်သည်။

အိမ်ပြဿနာများကိုရှောင်ရှားရန်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ပရောဂျက်အုပ်စုကို ပြဿနာမရှိဘဲ ကျွန်ုပ်တို့၏ volumes များကိုဖြေရှင်းနိုင်သော Gitlab Runner တစ်ခုသို့ကန့်သတ်ထားသည်။

ကျွန်ုပ်တို့သည် nginx-proxy ကို သီးခြားစတင်သည့် ဇာတ်ညွှန်းအဖြစ်သို့ ရွှေ့ပြီး ၎င်းရှိ ပရောဂျက်အားလုံး၏ ဂရစ်ဒ်များကို ရေးသားခဲ့သည်။

ကျွန်ုပ်တို့၏ပရောဂျက်တွင် ဇယားကွက်တစ်ခုပါရှိပြီး ချိန်ခွင်လျှာတွင် ပရောဂျက်အမည်များကို အခြေခံထားသော ဂရစ်များစွာရှိသည်။ ၎င်းသည် ဒိုမိန်းအမည်များဖြင့် နောက်ထပ် proxy ပြုလုပ်နိုင်သည်။

ကျွန်ုပ်တို့၏တောင်းဆိုချက်များသည် ဆိပ်ကမ်း 80 ရှိ ဒိုမိန်းမှတဆင့် ရောက်လာပြီး ဤဒိုမိန်းကို ဝန်ဆောင်မှုပေးသည့် ကွန်တိန်နာအုပ်စုတစ်စုထံ ဖြေရှင်းပေးပါသည်။

တခြားဘာပြဿနာတွေရှိလဲ။ ဤသည်မှာ ပုံသေအားဖြင့် ကွန်တိန်နာအားလုံးသည် root အဖြစ် လုပ်ဆောင်သည်။ ၎င်းသည် စနစ်၏ မညီမျှသော root host ဖြစ်သည်။

သို့သော်၊ သင်သည် ကွန်တိန်နာကို ထည့်သွင်းပါက၊ ၎င်းသည် root ဖြစ်ကာ၊ ဤကွန်တိန်နာတွင် ကျွန်ုပ်တို့ဖန်တီးသည့်ဖိုင်သည် root လုပ်ပိုင်ခွင့်များကို ရရှိမည်ဖြစ်သည်။

အကယ်၍ developer သည် ကွန်တိန်နာထဲသို့ ဝင်ပြီး ဖိုင်များကိုထုတ်ပေးသည့် ကွန်တိန်နာတွင် ကွန်တိန်နာအချို့ကို ပြုလုပ်ပါက၊ ထို့နောက် ကွန်တိန်နာမှ ထွက်ခွာသွားပါက၊ ၎င်း၏လုပ်ငန်းဆောင်တာလမ်းညွှန်တွင် သူဝင်ရောက်ခွင့်မရှိသော ဖိုင်တစ်ခုရှိသည်။

ဒါကို ဘယ်လိုဖြေရှင်းနိုင်မလဲ။ ကွန်တိန်နာအတွင်းရှိမည့် အသုံးပြုသူများကို သင်ထည့်နိုင်သည်။

အသုံးပြုသူကို ထည့်သောအခါတွင် မည်သည့်ပြဿနာများ ပေါ်ပေါက်လာသနည်း။

အသုံးပြုသူတစ်ဦးကို ဖန်တီးသောအခါ၊ အုပ်စု ID (UID) နှင့် အသုံးပြုသူ ID (GID) တို့သည် မကြာခဏ မကိုက်ညီပါ။

ဤပြဿနာကို ဖြေရှင်းရန်အတွက် ကွန်တိန်နာတွင် ID 1000 ရှိသော သုံးစွဲသူများကို ကျွန်ုပ်တို့ အသုံးပြုပါသည်။

ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ ၎င်းသည် developer အားလုံးနီးပါး Ubuntu OS ကိုအသုံးပြုသည့်အချက်နှင့် တိုက်ဆိုင်နေပါသည်။ Ubuntu OS တွင် ပထမဆုံးအသုံးပြုသူသည် ID 1000 ရှိသည်။

ငါတို့မှာ အစီအစဉ်ရှိလား။

Docker စာရွက်စာတမ်းကို ပြန်ဖတ်ပါ။ ပရောဂျက်သည် တက်ကြွစွာ ဖွံ့ဖြိုးနေပြီး စာရွက်စာတမ်းများ ပြောင်းလဲနေသည်။ လွန်ခဲ့သော နှစ်လ သို့မဟုတ် သုံးလခန့်က ရရှိခဲ့သော ဒေတာများသည် တဖြည်းဖြည်း ခေတ်နောက်ကျလာသည်။

ကျွန်ုပ်တို့ဖြေရှင်းခဲ့သော ပြဿနာအချို့ကို စံနည်းလမ်းဖြင့် ဖြေရှင်းပြီးသားဖြစ်ပေမည်။

ကျွန်တော် တကယ်ပဲ ဆက်လျှောက်ပြီး ကြိုးကိုင်မှုဆီ တိုက်ရိုက်သွားချင်ပါတယ်။

ဥပမာတစ်ခုမှာ Docker ၏ Built-in ယန္တရားကို Docker Swarm ဟုခေါ်သည်၊၊ Docker Swarm နည်းပညာကို အခြေခံ၍ ထုတ်လုပ်မှုတွင် တစ်စုံတစ်ရာကို စတင်လိုပါသည်။

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

source: www.habr.com