Chelyabinsk ۾ Southbridge ۽ Kubernetes ۾ Bitrix

سسادمينڪا سسٽم ايڊمنسٽريٽر ميٽنگون چيليابنسڪ ۾ ٿي رهيون آهن، ۽ آخري ڀيرو مون ڪبرنيٽس ۾ 1C-Bitrix تي هلندڙ ايپليڪيشنن لاءِ اسان جي حل تي رپورٽ ڏني.

Bitrix، Kubernetes، Ceph - هڪ وڏو مرکب؟

مان توهان کي ٻڌايان ٿو ته اسان هن سڀني مان هڪ ڪم ڪندڙ حل ڪيئن گڏ ڪيو.

اچو ته اچو!

ملاقات 18 اپريل تي چيليابنسک ۾ ٿي. توھان پڙھي سگھوٿا اسان جي گڏجاڻين بابت ٽائيم پيڊ ۽ ڏسو يوٽيوب.

جيڪڏھن توھان چاھيو ٿا اسان وٽ ھڪڙي رپورٽ سان يا ٻڌندڙ جي طور تي - ڀلي ڪري آيا، لکندا [ايميل محفوظ ٿيل] ۽ ٽيليگرام تي t.me/vadimisakanov.

منهنجي رپورٽ

سلائيڊ

حل "Bitrix in Kubernetes، نسخو Southbridge 1.0"

مان اسان جي حل جي باري ۾ ڳالهائيندس ”ڪبرنيٽس ۾ ڊميز لاءِ“ فارميٽ ۾، جيئن ميٽنگ ۾ ڪيو ويو. پر مان سمجهان ٿو ته توهان لفظن کي ڄاڻو ٿا Bitrix, Docker, Kubernetes, Ceph گهٽ ۾ گهٽ وڪيپيڊيا تي آرٽيڪل جي سطح تي.

ڪبرنيٽس ۾ Bitrix بابت ڇا تيار آهي؟

Kubernetes ۾ Bitrix ايپليڪيشنن جي آپريشن بابت پوري انٽرنيٽ تي تمام گھٽ ڄاڻ آھي.
مون کي صرف اهي مواد مليا آهن:

اليگزينڊر سربول، 1C-Bitrix، ۽ Qsoft کان Anton Tuzlukov پاران رپورٽ:

مان ان کي ٻڌڻ جي صلاح ڏيان ٿو.

استعمال ڪندڙ کان توهان جي پنهنجي حل کي ترقي ڪندي سرڪيرون Habré تي.
وڌيڪ مليو اهڙو فيصلو.

اڙي... اصل ۾، بس.

مان توهان کي ڊيڄاريان ٿو، اسان مٿي ڏنل لنڪ ۾ حل جي معيار جي جانچ نه ڪئي آهي :)
رستي ۾، جڏهن اسان جو حل تيار ڪيو، مون اليگزينڊر سربل سان ڳالهايو، پوء هن جي رپورٽ اڃا تائين ظاهر نه ڪئي هئي، تنهنڪري منهنجي سلائڊ ۾ هڪ شيء آهي "Bitrix Kubernetes استعمال نٿو ڪري."

پر Docker ۾ Bitrix هلائڻ لاءِ اڳ ۾ ئي ڪافي تيار ٿيل ڊڪر تصويرون آھن: https://hub.docker.com/search?q=bitrix&type=image

ڇا اهو ڪافي آهي ته ڪبرنيٽس ۾ Bitrix لاءِ مڪمل حل پيدا ڪرڻ لاءِ؟
نه. اهڙا ڪيترائي مسئلا آهن جن کي حل ڪرڻ جي ضرورت آهي.

Kubernetes ۾ Bitrix سان ڪهڙا مسئلا آهن؟

پهرين، Dockerhub کان تيار ڪيل تصويرون ڪبرنيٽس لاء مناسب نه آهن

جيڪڏهن اسان هڪ مائڪرو سروسز آرڪيٽيڪچر ٺاهڻ چاهيون ٿا (۽ ڪبرنيٽس ۾ اسان عام طور تي ڪندا آهيون)، اسان کي پنهنجي ڪبرنيٽس ايپليڪيشن کي ڪنٽينرز ۾ الڳ ڪرڻ جي ضرورت آهي ۽ هر ڪنٽينر کي هڪ ننڍڙو فنڪشن انجام ڏيڻ گهرجي (۽ اهو سٺو ڪريو). صرف هڪ ڇو؟ مختصر ۾، سادو وڌيڪ قابل اعتماد.
وڌيڪ مخصوص ٿيڻ لاء، هي مضمون ۽ وڊيو ڏسو، مهرباني ڪري: https://habr.com/ru/company/southbridge/blog/426637/

Dockerhub ۾ Docker تصويرون بنيادي طور تي سڀني ۾ هڪ اصول تي ٺهيل آهن، تنهنڪري اسان کي اڃا تائين پنهنجي سائيڪل ٺاهڻو پوندو ۽ اڃا به شروع کان تصويرون ٺاهي.

ٻيو - سائيٽ جو ڪوڊ ايڊمنٽ پينل مان ايڊٽ ڪيو ويو آھي

اسان سائيٽ تي هڪ نئون سيڪشن ٺاهيو - ڪوڊ اپڊيٽ ڪيو ويو (نئين سيڪشن جي نالي سان هڪ ڊاريڪٽري شامل ڪئي وئي).

جيڪڏهن توهان انتظامي پينل مان جزو جي ملڪيت کي تبديل ڪيو، ڪوڊ تبديل ڪيو.

Kubernetes "ڊفالٽ طور" هن سان ڪم نٿو ڪري سگهي؛ ڪنٽينر بي رياست هجڻ گهرجن.

سبب: ڪلستر ۾ هر ڪنٽينر (پوڊ) صرف ٽرئفڪ جو هڪ حصو عمل ڪري ٿو. جيڪڏهن توهان ڪوڊ کي صرف هڪ ڪنٽينر (پڊ) ۾ تبديل ڪريو ٿا، پوء ڪوڊ مختلف پوڊ ۾ مختلف هوندو، سائيٽ مختلف طريقي سان ڪم ڪندي، ۽ سائيٽ جا مختلف ورزن مختلف استعمال ڪندڙن کي ڏيکاريا ويندا. تون ائين رهي نه سگهندين.

ٽيون - توهان کي مقرري سان مسئلو حل ڪرڻ جي ضرورت آهي

جيڪڏهن اسان وٽ هڪ واحد ۽ هڪ "کلاسڪ" سرور آهي، هر شي بلڪل سادو آهي: اسان هڪ نئون ڪوڊ بيس ترتيب ڏيو ٿا، ڊيٽابيس کي منتقل ڪريون ٿا، ٽرئفڪ کي ڪوڊ جي نئين ورزن ڏانهن تبديل ڪريو. سوئچنگ فوري طور تي ٿيندي آهي.
جيڪڏهن اسان وٽ ڪبرنيٽس ۾ هڪ سائيٽ آهي، مائڪرو سروسز ۾ ڪٽي، ڪوڊ سان گڏ ڪيترائي ڪنٽينر آهن - اوه. توهان کي ڪوڊ جي نئين ورزن سان ڪنٽينرز گڏ ڪرڻ جي ضرورت آهي، انهن کي پراڻن جي بدران رول آئوٽ ڪريو، ڊيٽابيس کي صحيح طور تي لڏپلاڻ ڪريو، ۽ مثالي طور تي اهو ڪم ڪرڻ وارن جي نظر کان سواء. خوشقسمتيءَ سان، ڪبرنيٽس اسان جي مدد ڪري ٿو هن سان، مختلف قسم جي ڊيپلائيشنز جي مڪمل گروپ جي حمايت ڪندي.

چوٿون - توهان کي اسٽوريج اسٽوريج جي مسئلي کي حل ڪرڻ جي ضرورت آهي

جيڪڏهن توهان جي سائيٽ "صرف" 10 گيگا بائيٽ آهي ۽ توهان ان کي مڪمل طور تي ڪنٽينرز ۾ ترتيب ڏيو ٿا، توهان ختم ٿي ويندا 10 گيگا بائيٽ ڪنٽينرز جيڪي هميشه لاءِ ترتيب ڏيڻ ۾ وٺن ٿا.
توهان کي سائيٽ جي "سڀ کان ڳري" حصن کي ذخيرو ڪرڻ جي ضرورت آهي ڪنٽينرز کان ٻاهر، ۽ سوال اهو پيدا ٿئي ٿو ته اهو ڪيئن ڪجي.

اسان جي حل مان ڇا غائب آهي؟

سڄو Bitrix ڪوڊ microfunctions/microservices ۾ ورهايل نه آهي (انهي ڪري ته رجسٽريشن الڳ آهي، آن لائن اسٽور ماڊل الڳ آهي، وغيره). اسان هر ڪنٽينر ۾ سڄو ڪوڊ بيس ذخيرو ڪندا آهيون.

اسان ڪبرنيٽس ۾ ڊيٽابيس کي ذخيرو نٿا ڪريون (مون اڃا تائين ترقي جي ماحول لاءِ ڪبرنيٽس ۾ ڊيٽابيس سان حل لاڳو ڪيو، پر پيداوار لاءِ نه).

اهو اڃا تائين سائيٽ جي منتظمين لاءِ قابل ذڪر هوندو ته سائيٽ ڪبرنيٽس تي هلندي آهي. "سسٽم چيڪ" فنڪشن صحيح طريقي سان ڪم نٿو ڪري؛ ايڊمن پينل مان سائيٽ ڪوڊ ايڊٽ ڪرڻ لاءِ، توھان کي پھريون ڪلڪ ڪرڻ گھرجي "مان ڪوڊ ايڊٽ ڪرڻ چاھيان ٿو" بٽڻ.

مسئلن جي نشاندهي ڪئي وئي آهي، مائڪرو سروسز کي لاڳو ڪرڻ جي ضرورت جو اندازو لڳايو ويو آهي، مقصد واضح آهي - ڪبرنيٽس ۾ Bitrix تي ايپليڪيشن هلائڻ لاء ڪم ڪندڙ سسٽم حاصل ڪرڻ، Bitrix جي صلاحيتن ۽ ڪبرنيٽس جي فائدن کي محفوظ ڪرڻ. اچو ته عمل درآمد شروع ڪريون.

تعمير

ويب سرور سان گڏ ڪيترائي "ڪم ڪندڙ" پوڊ آهن (ڪارڪنن).
هڪ هيٺ ڪرون ڪمن سان (صرف هڪ گهربل آهي).
ايڊمن پينل مان سائيٽ ڪوڊ ايڊٽ ڪرڻ لاءِ هڪ اپ گريڊ (پڻ صرف هڪ گهربل آهي).

اسان سوال حل ڪريون ٿا:

• سيشن ڪٿي رکڻ لاء؟
• ڪيش ڪٿي رکڻ لاء؟
• اسٽيٽيڪس کي ڪٿي رکڻ لاءِ، نه ته گيگا بائيٽ جي اسٽيڪ کي ڪنٽينر جي هڪ گروپ ۾ رکڻ لاءِ؟
• ڊيٽابيس ڪيئن ڪم ڪندو؟

ڊاکر تصوير

اسان هڪ Docker تصوير تعمير ڪندي شروع ڪريون ٿا.

مثالي اختيار اهو آهي ته اسان وٽ هڪ آفاقي تصوير آهي، ان جي بنياد تي اسان کي ڪم ڪندڙ پوڊ، ڪرونٽاسڪ سان پوڊ، ۽ پوڊ کي اپڊيٽ ڪرڻ.

اسان هڪ اهڙي تصوير ٺاهي.

ان ۾ شامل آهي nginx، apache/php-fpm (تعمير دوران چونڊجي سگھجي ٿو)، ميل موڪلڻ لاءِ msmtp، ۽ ڪرون.

تصوير کي گڏ ڪرڻ وقت، سائيٽ جو سڄو ڪوڊ بيس /ايپ ڊاريڪٽري ۾ نقل ڪيو ويندو آهي (انهن حصن جي استثنا سان جيڪي اسان هڪ الڳ حصيداري اسٽوريج ڏانهن منتقل ڪنداسين).

Microservices، خدمتون

ڪم ڪندڙ ٻج:

• nginx سان گڏ ڪنٽينر + ڪنٽينر apache/php-fpm + msmtp
• اهو ڪم نه ڪيو ويو ته msmtp کي هڪ الڳ مائڪرو سروس ۾ منتقل ڪيو وڃي، Bitrix ناراض ٿيڻ شروع ڪيو آهي ته اهو سڌو ميل نه موڪلي سگهي ٿو
• هر ڪنٽينر هڪ مڪمل ڪوڊ بيس آهي.
• ڪنٽينرز ۾ ڪوڊ تبديل ڪرڻ تي پابندي.

هيٺ ڪرون:

• apache، php، cron سان گڏ ڪنٽينر
• مڪمل ڪوڊ بنيادي شامل
• ڪنٽينر ۾ ڪوڊ تبديل ڪرڻ تي پابندي

هيٺيون واڌارو:

• nginx ڪنٽينر + apache/php-fpm ڪنٽينر + msmtp
• ڪنٽينرز ۾ ڪوڊ تبديل ڪرڻ تي ڪا به پابندي ناهي

سيشن اسٽوريج

Bitrix ڪيش اسٽوريج

ٻي اهم شيءِ: اسان هر شيءِ سان ڳنڍڻ لاءِ پاسورڊ ذخيرو ڪندا آهيون، ڊيٽابيس کان ميل تائين، ڪبرنيٽس رازن ۾. اسان کي هڪ بونس ملي ٿو: پاسورڊ صرف انهن لاءِ نظر اچن ٿا جن کي اسان رازن تائين رسائي ڏيون ٿا، ۽ هر ڪنهن کي نه جن وٽ پروجيڪٽ جي ڪوڊ بيس تائين رسائي آهي.

statistics لاء اسٽوريج

توھان ڪجھ به استعمال ڪري سگھو ٿا: ceph، nfs (پر اسان پيداوار لاءِ nfs جي سفارش نٿا ڪريون)، ڪلائوڊ فراهم ڪندڙن کان نيٽ ورڪ اسٽوريج وغيره.

اسٽوريج کي ڪنٽينرز ۾ /upload/ سائيٽ جي ڊاريڪٽري ۽ جامد مواد سان ٻين ڊائريڪٽرن سان ڳنڍڻ جي ضرورت پوندي.

ڊيٽابيس

سادگي لاءِ، اسان سفارش ڪريون ٿا ڊيٽابيس کي ڪبرنيٽس کان ٻاهر منتقل ڪريو. ڪبرنيٽس ۾ بنياد هڪ الڳ پيچيده ڪم آهي؛ اهو اسڪيم کي وڌيڪ پيچيده انداز جي ترتيب ٺاهيندو.

سيشن اسٽوريج

اسان memcached استعمال ڪندا آهيون :)

اهو سيشن اسٽوريج کي چڱي طرح سنڀاليندو آهي، ڪلستر ٿيل آهي، ۽ سپورٽ ڪئي وئي آهي "مقتي طور تي" جيئن php ۾ session.save_path. اهڙي نظام کي ڪيترائي ڀيرا آزمايو ويو آهي ڪلاسيڪل monolithic فن تعمير ۾، جڏهن اسان وڏي تعداد ۾ ويب سرورز سان ڪلسٽر ٺاهيا. تعیناتي لاءِ اسان هيلم استعمال ڪندا آهيون.

$ helm install stable/memcached --name session

php.ini - هتي تصوير ۾ سيٽنگون سيٽنگون شامل آهن memcached ۾

اسان ماحوليات جي تبديلين کي استعمال ڪيو هوسٽن بابت ڊيٽا کي پاس ڪرڻ لاءِ memcached سان https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/.
اهو توهان کي ساڳيو ڪوڊ استعمال ڪرڻ جي اجازت ڏئي ٿو ديو، اسٽيج، ٽيسٽ، پروڊ ماحول ۾ (انهن ۾ ياد ڪيل ميزبان جا نالا مختلف هوندا، تنهنڪري اسان کي هر ماحول ۾ سيشن لاء هڪ منفرد ميزبان نالو پاس ڪرڻ جي ضرورت آهي).
Bitrix ڪيش اسٽوريج

اسان کي غلطي برداشت ڪرڻ واري اسٽوريج جي ضرورت آهي ته سڀئي پوڊس لکي ۽ پڙهي سگهن ٿا.

اسان پڻ استعمال ڪندا آهيون memcached.
هي حل پاڻ Bitrix طرفان سفارش ڪئي وئي آهي.

$ helm install stable/memcached --name cache

bitrix/.settings_extra.php - هتي Bitrix ۾ اهو بيان ڪيو ويو آهي ته ڪيش ڪٿي ذخيرو ٿيل آهي

اسان پڻ استعمال ڪندا آهيون ماحولياتي متغير.

ڪرنٽاسڪي

ڪبرنيٽس ۾ ڪرونٽاسڪ هلائڻ جا مختلف طريقا آهن.

• Crontasks هلائڻ لاءِ هڪ پوڊ سان الڳ الڳ مقرري
• cronjob crontasks تي عمل ڪرڻ لاءِ (جيڪڏهن هي ويب ايپ آهي - wget سان https://$host$cronjobname، يا kubectl exec اندر هڪ ڪم ڪندڙ پوڊ وغيره.)
• وغيره.

توھان سڀ کان وڌيڪ صحيح بابت بحث ڪري سگھو ٿا، پر ھن صورت ۾ اسان اختيار ڪيو آھي "Crontasks لاءِ پوڊ سان الڳ مقرري"

اهو ڪيئن ڪيو ويو آهي:

• ڪرون ڪم شامل ڪريو ConfigMap ذريعي يا config/addcron فائل ذريعي
• هڪ مثال ۾ اسان هڪ ڪنٽينر لانچ ڪريون ٿا جيڪو ڪم ڪندڙ پوڊ سان ملندڙ جلندڙ آهي + ان ۾ تاج جي ڪمن کي انجام ڏيڻ جي اجازت ڏيو
• ساڳيو ڪوڊ جو بنياد استعمال ڪيو ويو آهي، متحد ٿيڻ جي مهرباني، ڪنٽينر اسيمبلي سادو آهي

اسان کي ڪهڙو سٺو ملي ٿو:

• اسان وٽ ڪم ڪري رهيا آهيون ڪرونٽاسڪ هڪ ماحول ۾ هڪجهڙائي واري ماحول ۾ ڊولپرز جي ماحول سان (ڊاڪر)
• ڪرنٽاسڪس کي ڪبرنيٽس لاءِ ”ٻيهر لکڻ“ جي ضرورت ناهي، اهي ساڳيا فارم ۽ ساڳي ڪوڊ بيس ۾ ڪم ڪن ٿا جيئن اڳ ۾
• cron ٽاسڪ سڀني ٽيم جي ميمبرن طرفان شامل ڪري سگھجن ٿا پروڊڪشن برانچ جي حق سان، نه صرف منتظمين

Southbridge K8SDDeploy module and code editing from Admin Panel

اسان هيٺ اپ گريڊ بابت ڳالهائي رهيا هئاسين؟
اتي ٽرئفڪ کي ڪيئن سڌو ڪجي؟
ها، اسان هن لاءِ PHP ۾ هڪ ماڊل لکيو آهي :) هي Bitrix لاءِ هڪ ننڍڙو کلاسک ماڊل آهي. اهو اڃا تائين عام طور تي دستياب ناهي، پر اسان ان کي کولڻ جو منصوبو ٺاهيو.
ماڊل نصب ٿيل آهي هڪ باقاعده ماڊل وانگر Bitrix ۾:

۽ اهو هن وانگر ڏسڻ ۾ اچي ٿو:

اهو توهان کي هڪ ڪوڪي سيٽ ڪرڻ جي اجازت ڏئي ٿو جيڪا سائيٽ جي منتظم جي سڃاڻپ ڪري ٿي ۽ Kubernetes کي اجازت ڏئي ٿي ته ٽرئفڪ کي اپڊيٽ پوڊ ڏانهن موڪلي.

جڏهن تبديليون مڪمل ٿي وينديون آهن، توهان کي ڪلڪ ڪرڻ جي ضرورت آهي گٽ پش، ڪوڊ تبديلين کي گٽ ڏانهن موڪليو ويندو، پوء سسٽم ڪوڊ جي نئين ورزن سان هڪ تصوير ٺاهيندو ۽ ان کي ڪلستر ۾ "رول آئوٽ" ڪندو، پراڻي پوڊ کي تبديل ڪندي. .

ها، اهو هڪ ڪچرو جو ٿورو آهي، پر ساڳئي وقت اسان microservice فن تعمير کي برقرار رکون ٿا ۽ بٽريڪس استعمال ڪندڙن کان انهن جي پسنديده موقعو نه کڻندا آهن ايڊمن پينل کان ڪوڊ کي درست ڪرڻ لاء. آخر ۾، هي هڪ اختيار آهي؛ توهان مختلف طريقي سان ڪوڊ کي تبديل ڪرڻ جو مسئلو حل ڪري سگهو ٿا.

هيلم چارٽ

Kubernetes تي ايپليڪيشنون ٺاهڻ لاءِ، اسان عام طور استعمال ڪندا آهيون Helm پيڪيج مئنيجر.
Kubernetes ۾ اسان جي Bitrix حل لاءِ، سرجي بونڊاريف، اسان جي معروف سسٽم ايڊمنسٽريٽر، هڪ خاص هيلم چارٽ لکيو.

اهو ڪم ڪندڙ، يوگريڊ، ڪرون پوڊز ٺاهي ٿو، داخل ڪري ٿو، خدمتن کي ترتيب ڏئي ٿو، ۽ ڪيبرنيٽس رازن کان پوڊ تائين متغير کي منتقل ڪري ٿو.

اسان ڪوڊ کي Gitlab ۾ ذخيرو ڪندا آهيون، ۽ اسان Gitlab کان هيلم تعمير پڻ هلائيندا آهيون.

مختصر ۾، اهو هن وانگر ڏسڻ ۾ اچي ٿو

$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=production

هيلم پڻ توهان کي اجازت ڏئي ٿو ته هڪ "سيميل" رول بيڪ ڪرڻ جي صورت ۾ اوچتو ڪجهه غلط ٿي وڃي ٿو ڊيپلائيشن دوران. اهو سٺو آهي جڏهن توهان خوف ۾ نه آهيو "ايف ٽي پي ذريعي ڪوڊ کي درست ڪريو ڇاڪاڻ ته پروڊ گر ٿي ويو،" پر ڪبرنيٽس اهو خودڪار طريقي سان ڪري ٿو، ۽ بغير وقت جي.

مقرر ڪرڻ

ها، اسان پرستار آهيون Gitlab ۽ Gitlab CI، اسان ان کي استعمال ڪندا آهيون :)
جڏهن Gitlab ۾ منصوبي جي مخزن ڏانهن ڪم ڪندي، Gitlab هڪ پائپ لائن شروع ڪري ٿو جيڪا ماحول جي نئين نسخي کي ترتيب ڏئي ٿي.

مرحلا:

• تعمير (هڪ نئين Docker تصوير جي تعمير)
• ٽيسٽ (امتحان)
• صاف ڪريو (ٽيسٽ ماحول کي ختم ڪرڻ)
• push (اسان ان کي ڊاڪر رجسٽري ڏانهن موڪليندا آهيون)
• deploy (اسان هيلم ذريعي ڪبرنيٽس تائين ايپليڪيشن کي ترتيب ڏيون ٿا).

هيري، اهو تيار آهي، اچو ته ان تي عمل ڪريون!
خير، يا سوال پڇو جيڪڏهن ڪو به آهي.

پوءِ اسان ڇا ڪيو

ٽيڪنيڪل نقطي نظر کان:

• dockerized Bitrix؛
• "ڪٽ" Bitrix ڪنٽينرز ۾، جن مان هر هڪ گهٽ ۾ گهٽ ڪم انجام ڏئي ٿو.
• ڪنٽينرز جي بي رياستي حالت حاصل ڪئي؛
• Kubernetes ۾ Bitrix کي اپڊيٽ ڪرڻ سان مسئلو حل ڪيو؛
• سڀ Bitrix افعال ڪم ڪرڻ جاري رکي (تقريبا سڀ)؛
• اسان ڪبرنيٽس کي ترتيب ڏيڻ ۽ ورزن جي وچ ۾ رول بيڪ تي ڪم ڪيو.

ڪاروباري نقطي نظر کان:

• غلطي رواداري؛
• ڪبرنيٽس ٽولز (گٽلاب سي آءِ سان آسان انضمام، بيحد ترتيب، وغيره)؛
• ڳجهو پاسورڊ (صرف انهن لاءِ نظر اچن ٿا جن کي سڌو سنئون پاسورڊ تائين رسائي ڏني وئي آهي)؛
• اهو آسان آهي اضافي ماحول ٺاهڻ لاءِ (ترقي لاءِ، ٽيسٽون وغيره) هڪ انفراسٽرڪچر اندر.

جو ذريعو: www.habr.com