خدمة Dart: مقدمة ، البنية التحتية الخلفية

جدول المحتويات
1.

2. Backend

2.1. .

2.2. . SSL.

2.3. Dart.



3. Web

3.1. «Under construction»



4. Mobile





المقدمة



بصفتي مطور Flutter ، كثيرًا ما يسألني أصدقائي: "ما هي لغة Dart؟" يهزون رؤوسهم بالكلمات التالية: "لكن بيتيا يكتب وسائل نقل جادة في جافا ، وفي ياندكس بشكل عام ، هناك إيجابيات في البيع ...". حسنًا ، ربما ، حقًا ، Dart بعيدة كل البعد عن ممارسة " مصانع لإنشاء المصانع " من جافا. ومع ذلك ، إذا كانت المهمة هي تنفيذ تطبيقات العميل لعدة منصات في وقت واحد ، دون الغرق في تدفق المهام لمزامنة مطوري أنظمة تشغيل مستهدفة مختلفة ؛ لإنشاء واجهة مستخدم متماسكة يمكن التعرف عليها ، ولكنها خاصة بنظام Android و iOS والويب ، وبشكل عام لتلبية ميزانية وإطار زمني مناسبين - هنا لا يوجد لدى Flutter منافسون. وهذه الأسئلة لها أهمية مضاعفة إذا كان لديك ... شركة ناشئة.



إذن ، الأسطورة: قررت شركة ناشئة إنشاء خدمة جديدة ... حسنًا ، على سبيل المثال ، لـ
تقاسم قوائم التسوق
, , ToDo , :)

بين مستخدمي الخدمة. الهدف من بدء التشغيل هو إطلاق MVP في ثلاثة أشهر على ثلاثة منصات (بالإضافة إلى الخادم الرابع بالطبع).



قبل 10 سنوات ، كنت أقول إن هذه الحالة ليس لها حل وسأحاول الابتعاد عنها ، منذ 3 سنوات يمكن أن تصبح حزمة ReactNative / React / NodeJs هي الحل ، في عام 2020 هناك Dart لهذا الغرض مرحبًا بكم في جو تطوير الإصدار ألفا من الخدمة ، سأحاول بصريًا متابعة وشرح عملية التطوير بأكملها. سيتم نشر رمز جميع التطبيقات. التعليقات ، بما في ذلك الرسومات والهوليفار ، مرحب بها. يمكنك أن تسأل المؤلف "في الجوهر" أو فقط اطلب النصيحة في قناة Telegram التابعة لقسمنا .







البنية التحتية الخلفية



الطريقة النموذجية لاستضافة تطبيق الخادم هي ، بالطبع ، VPS (خادم خاص افتراضي). في الواقع ، هذا جزء من خادم فعلي في مركز بيانات ، يتم فصل موارده (نوى المعالج وذاكرة الوصول العشوائي) باستخدام تقنية المحاكاة الافتراضية (يمكنك أن تقرأ عن أكثر تقنيات المحاكاة الافتراضية للأجهزة شيوعًا هنا XEN و KVM ) انتباه: قد لا تكون تقنيات المحاكاة الافتراضية للبرامج ( OpenVZ ، Virtuozzo ) مناسبة لمهمتنا بسبب التعارض مع Docker والبيع المفرط العدواني(في كثير من الأحيان ، عند القراءة المتأنية لاتفاقية الإيجار لمثل هذا الخادم الافتراضي الخاص ، ستجد أن مقدمي الخدمة يضمنون "5٪ على الأقل" (!) استخدام نواة المعالج المستأجر. وهذا يعني أن الموفر يخطط لبيع معالجنا الأساسي 20 (!) مرة).



لذلك ، دعنا نحصل على VPS للميزانية بالخصائص التالية: معالج أساسي واحد ، وذاكرة وصول عشوائي (RAM) سعة 1 جيجابايت ، وذاكرة تخزين 10 جيجابايت (في حالتي ، هذا محرك أقراص صلبة هجين). دعنا نختار Ubuntu كنظام تشغيل ، ويفضل أن يكون أحد إصدارات LTS . بعد ذلك ، ستتلقى رسالة بريد إلكتروني حول تنشيط الخادم مع تسجيل الدخول وكلمة المرور للوصول إلى SSH ( الوصول المشفر إلى وحدة تحكم نظام التشغيل في VPS لدينا) بتنسيق SSH:



عنوان IP: 91.230.60.120

المستخدم:

كلمة مرور الجذر : <كلمة المرور>



دعنا نتحقق من الاتصال عن طريق كتابة سطر الأوامر:



ssh root@91.230.60.120


وعند الطلب:



password: <>


يجب أن تكون النتيجة إخراج المعلومات حول الخادم الافتراضي وحقل الإدخال في الأسفل:



تتم استضافة الخادم بواسطة xxxxxxxxxx



اسم المضيف: 91.230.60.120

Kernel: 3.19.0-22-generic (Ubuntu xx.xx LTS)

وقت التشغيل: 09:07:06 لمدة 3 أيام ، 17:17 ، مستخدم واحد ، متوسط ​​التحميل: 0.00 ، 0.01 ، 0.05

وحدة المعالجة المركزية: Intel® Xeon® CPU 0 @ 2.00 جيجاهرتز (1 مركز)

الذاكرة: إجمالي 989 ميجابايت / 723 ميجابايت مجانًا



root@91.230.60.120: ~ $



تهانينا ، لدينا تم إنشاء الخادم الافتراضي وإتاحته للعمل.



الآن دعنا نحدد بنية الواجهة الخلفية. نحن بحاجة إلى خادم HTTP. سنكون باستخدام إنجن إكس . ستكون مهامها:



  1. خدمة الملفات الثابتة (ملفات تطبيقات الويب).
  2. توزيع موارد الخدمة ، على سبيل المثال ، ملفات إثبات ملكية المجال لتطبيقات الهاتف المحمول ، ومعلومات حول المالك للحصول على شهادات SSL ، دعنا نشفر ، إلخ.
  3. وكيل عكسي للوصول إلى تطبيقات الخادم.
  4. تشفير الاتصالات - https.


تطبيقان للخادم:



  1. تسجيل المستخدم وطلب الترخيص. دعنا نسميها auth_app.
  2. التطبيق مع البيانات. دعنا نسميها التطبيق.
  3. لكل من التطبيقات الواردة في الفقرة 2 ، نحتاج إلى قاعدة بيانات PostgreSQL منفصلة.
  4. طلب الحصول على شهادات تشفير SSL وتجديدها تلقائيًا (في المقالة التالية).


من الواضح أن مثل هذه "حديقة الحيوانات" من التطبيقات يجب عزلها عن بعضها البعض ، وكذلك حظرها من الخارج. لهذا سوف نستخدم عامل الميناء التكنولوجيا الحاويات و عامل الميناء الإنشاء مدير حاوية . في شكل رسم بياني ، يمكن تمثيل ذلك على النحو التالي:



صورة



سيتم تنفيذ التطوير في Visual Studio Code IDE من Microsoft ، والذي سيسمح لك ، بفضل العديد من المكونات الإضافية المتاحة ، بالعمل مع جميع التقنيات اللازمة. تحتاج أيضًا إلى تثبيت الملحقات التالية:





بعد إعادة تشغيل VScode ، دعنا نتصل بخادمنا VPS. اضغط على F1 وابدأ في إدخال الأمر:



Remote-SSH: connect to  Host…


ثم اتصال جديد:



+ Add New Ssh Host


ثم:



ssh root@<ip- >


افتح نافذة طرفية VScode (قائمة / طرفية / محطة جديدة) وتحقق من موارد النظام باستخدام الأمر:



top


تم الوصول إلى وحدة تحكم VPS ونظام الملفات:











سيتم استخدام الأداة المساعدة العليا كثيرًا ، لذا دعنا نثبت إصدار htop الزائف:



Ctrl-C #   top


apt-get update #  


apt-get install htop # htop 


htop # 


صورة



أنت الآن بحاجة إلى تثبيت Docker and Docker compose:



Ctrl-C #   htop


نظرًا لأن docker ليس في مستودع Ubuntu الرسمي ، فسنقوم بتثبيت مستودع إضافي



apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common #   


curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - #   docker 


add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" #  


apt-get install docker-ce docker-ce-cli containerd.io #


curl -L "https://github.com/docker/compose/releases/download/1.26.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose #  Docker compose 


chmod +x /usr/local/bin/docker-compose #     « »


ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose #       


 docker  --version #


docker-compose --version


رائع ، الخادم جاهز لاختبار نشر الخدمة.



لنقم الآن بتثبيت سطح المكتب Docker على كمبيوتر التطوير المحلي الخاص بنا. المثبت لنظام التشغيل Windows 10 ، إصدار MacOS هنا . لن يتم تثبيت Docker فحسب ، بل سيتم أيضًا تثبيت Docker toolbox ، والذي يتضمن أدوات إنشاء Docker والأدوات الرسومية للعمل مع الحاويات.



لنفتح نافذة VScode جديدة ، قائمة / ملف / فتح مجلد ... لنقم بإنشاء مجلد جديد لمشروعنا ، على سبيل المثال ، Srv ونفتحه . في هذا المجلد ، أنشئ ملف docker-compose.yaml :



صورة



يصف هذا الملف البرنامج النصي لبدء حاويات الخدمة ، وتبعياتها ، ومتغيراتها ، وأوامرها ، وشبكاتها ، ومستودعاتها ، وما إلى ذلك.



هذا هو المكان الذي نحتاج فيه إلى التوقف وتوضيح الفرق بين الصورة وحاوية Docker. الحاوية عبارة عن تطبيق + تبعياتها (على سبيل المثال ، الحزم والمكتبات) + نظام تشغيل يمكنك تشغيله باستخدام Docker كتطبيق عادي. والصورة عبارة عن حاوية معدة للإطلاق ومعبأة في أرشيف. وبالتالي ، ستكون الواجهة الخلفية لدينا عبارة عن مجموعة من الحاويات مع وصف للبرنامج النصي لإطلاقها.



ستكون الحاوية الأولى التي خططنا لها هي خادم NGINX HTTP. ودعونا نجهز الصورة اللازمة ... ام لا؟ الحقيقة هي أنه بالنسبة للعديد من تطبيقات الويب وبيئات وقت التشغيل الخاصة بها ، قام المطورون أو المجتمع بالفعل بجمع الصور الضرورية ووضعها في سجل DockerHub العام . بالطبع ، تم بالفعل تجميع مثل هذه الصورة المستخدمة على نطاق واسع وتنتظرنا في هذا الشأنالارتباط .



انتبه إلى القائمة - فهذه إصدارات مختلفة ، فهي تختلف في كل من إصدارات NGINX نفسها والأدوات الإضافية (على سبيل المثال ، المثبتة بواسطة PERL). للتطوير ، يمكنك استخدام العلامة "الأحدث" (أحدث إصدار مستقر في وقت طلب الصورة) ، ولكن للنشر على الخادم ، بالطبع ، يجب استخدام إصدار محدد. في الوقت الحالي ، هذه هي صورة nginx: 1.19.0 .



فيما يلي ، سأشير إلى التفسيرات اللازمة لمحتويات docker-compose.yaml في التعليقات الموجودة في الملف الذي يسرد نفسه:







احفظ التغييرات على الملف ، وافتح وحدة تحكم VScode وقم بتنفيذ أمر تشغيل البرنامج النصي



docker-compose up


لم يقم هذا الأمر بتشغيل البرنامج النصي فحسب ، بل أرسل أيضًا إخراج وحدة التحكم في الحاوية إلى وحدة تحكم المضيف. الآن ، إذا انتقلت إلى المضيف المحلي على المنفذ 8081 في شريط العنوان في متصفحك ، فستتلقى استجابة NGINX القياسية:







الحاوية الأولى لدينا قيد التشغيل بالفعل. عادةً ما يتم تشغيل البرنامج النصي باستخدام الأمر:



docker-compose up -d


يسمح هذا ببدء تشغيل الحاويات في وضع الخدمة (بدون إخراج إلى وحدة التحكم). يتم إيقاف حاويات البرامج النصية باستخدام الأمر:



docker-compose down


لاختبار طلبات http ، يحتوي VScode على امتداد عميل REST سهل الاستخدام .



دعنا نثبته ونكتب أول اختبار تصحيح أخطاء لخدمتنا. للقيام بذلك ، قم بإنشاء ملف client.http في مجلد / http_dev / test :











وبالتالي ، يمكنك تنفيذ طلبات الاختبار ، وعرض المعلومات التفصيلية حول استجابات الخادم.



الآن دعونا نلقي نظرة داخل الحاوية. أوقف تنفيذ البرنامج النصي في وحدة التحكم:



Ctrl-C


وركض بعلم:



docker-compose up -d


لنطلب الآن قائمة بالحاويات (العمليات) قيد التشغيل حاليًا:



docker-compose ps






توجد حاوية واحدة فقط في قائمة الملفات القابلة للتنفيذ. لنفتحه:



docker exec -it srv_web_1 bash


ينفذ هذا الأمر (exec) تطبيق bash (غلاف أوامر Linux) في حاوية srv_web_1 ويمنع وحدة التحكم من الإغلاق (-it flags): سيعرض







الأمر lsبنية مجلد Linux القياسية:







نحن مهتمون بالملف /etc/nginx/conf.d/default.conf - إعدادات NGINX ، يمكنك استخدام الأداة المساعدة cat لعرضها



cat /etc/nginx/conf.d/default.conf






في إعدادات NGINX ، توجد كتلة واحدة (ما يسمى بالموقع ) ، يتم فيها تمكين الاستماع على المنفذ 80 وتقديم الملفات الثابتة من مجلد الحاوية / usr / share / nginx / html . يمكنك محاولة إجراء تغييرات على ملف تكوين NGINX وإعادة تشغيله بالتغييرات المطبقة ، ولكن عند إعادة تشغيل البرنامج النصي ، ستتم استعادة الحاوية من الصورة ولن يتم حفظ أي من تغييراتنا. هذه هي الطريقة الخاطئة.



لنخرج من وحدة تحكم الحاوية:



Ctrl-D


سنكتب ملف التكوين الخاص بنا ونضع ملفاتنا الثابتة ، وعند بدء التشغيل سنقوم بتركيبها في حاوية NGINX. قم بإنشاء ملف default.conf في مجلد /conf.d الخاص بمشروعنا :











قم بإنشاء كعب للملف الثابت /public/index.html :







الآن ، في البرنامج النصي لبدء التشغيل docker-compose.yaml ، قم بتركيب مجلداتنا في نظام ملفات الحاوية:







لاحظ أن محتويات مجلد المشروع. سيستبدل /conf.d محتويات الحاوية في /etc/nginx/conf.d/ ، وسيتم تحميل المجلد ./public إلى المجلد الجذر لمجلد الحاوية.



لنقم بإعادة تشغيل البرنامج النصي:



docker-compose restart


طلب الاختبار:







دعنا نلقي نظرة على ملف default.conf . يرجى ملاحظة أننا قمنا بتعطيل تسجيل الوصول إلى الملفات الثابتة access_log . هذا حل بيع جيد ، لكنه غير مريح للغاية للاختبار والتطوير. دعونا خلق اختبار إنجن إكس ملف التكوين /conf.dev.d/default.conf و النصي عامل ميناء compose.dev.yaml .















دعنا نتوقف عن النص:



docker-compose down


وتشغيله بأعلام اسم الملف:



docker-compose -f docker-compose.yaml -f docker-compose.dev.yaml up


سيؤدي تشغيل البرنامج النصي بهذه الطريقة أولاً إلى قراءة الإعدادات من ملف docker-compose.yaml ، ثم إضافة أو استبدال الحقول المطابقة من docker-compose.dev.yaml (المنافذ ، وحدات التخزين). دعنا نتحقق من التسجيل عن طريق تكرار الطلب:











لذلك ، نحتاج فقط إلى النسخ والتشغيل على الخادم. أنشئ المجلد / opt / srv_0 / على الخادم (لم نغلق نافذة VScode مع اتصال SSH بـ VPS حتى الآن) وانسخ محتويات مشروعنا بالكامل فيه باستخدام الأمر:



scp scp -r ./* root@91.230.60.120:/opt/srv_0/ 






الآن على الخادم في مجلد المشروع / opt / srv_0 / قم بتشغيل الأمر:



docker-compose up -d


لنكتب اختبار http آخر الآن لـ VPS:







أو افتح الرابط في المتصفح .



-> شفرة المصدر جيثب



بدلا من الاستنتاج



لذلك ، تم اتخاذ الخطوة الأولى. لقد نجحنا في طرح التطبيق على خادم الإنتاج. في المقالة الثانية ، سنستمر في تكوين الخادم عن طريق تعيين اسم المجال وتثبيت شهادة تشفير SSL. في المقالة الثالثة ، سنقوم بكتابة تطبيق ويب flutter مع عد تنازلي لإطلاق خدمتنا ، ونجمعه ونضعه على خادمنا. في المقالة الرابعة ، سنكتب ونبني خادم Linux أصليًا بلغة Dart ، والذي سيصبح أساسًا لتطبيقات الترخيص والبيانات لخدمتنا.



تعليقات واقتراحات هي موضع ترحيب. يمكنك الدردشة مع المؤلف في قناة Telegram .



All Articles