تطوير البرامج في أي مكان: مكان عملي الموزع البعيد

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

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

يعتمد نهجي إلى حد كبير على الميزات التي تقدمها SSH والأدوات ذات الصلة على Linux. لاحظ أن مستخدمي MacOS والأنظمة الأخرى الشبيهة بـ Unix يمكنهم الاستفادة من الإجراءات الموصوفة أيضًا ، إلى الحد الذي تدعم أنظمتهم الأدوات الموصوفة.

الخادم الصغير الشخصي الخاص بي

تتمثل الخطوة الأولى المهمة في الإعداد الخاص بي في وجود خادم يعمل بالطاقة Raspberry Pi 2 في منزلي ، ويستخدم لاستضافة كل شيء من مستودعات الكود المصدري إلى المواقع التجريبية.

على الرغم من أنني أسافر ، إلا أن شقتي تعمل بمثابة "قاعدة عمليات ثابتة" عن بُعد مع اتصال إنترنت لائق (100 ميجابت / ثانية) وتقريباً لا يوجد زمن انتقال إضافي. هذا يعني أنني ، من شقتي ، مقيد بشكل أساسي فقط بسرعة الشبكة الوجهة. الإعداد الذي أصفه يعمل بشكل أفضل مع هذا النوع من الاتصال ، على الرغم من أنه ليس شرطًا. في الواقع ، لقد استخدمت أيضًا هذا النهج بينما كان لدي اتصال ADSL ذي نطاق ترددي منخفض نسبيًا ، حيث تعمل معظم الأشياء بشكل جيد. الشرط الحقيقي الوحيد ، من واقع خبرتي ، هو أن يكون النطاق الترددي إما غير مُقاس أو رخيص الثمن.

بصفتي مستخدمًا سكنيًا ، لدي أرخص جهاز توجيه شبكة منزلية يمكن أن يشتريه مزود خدمة الإنترنت ، وهو ببساطة لا يكفي لما أحتاج إلى القيام به. لذلك طلبت أن يضع مزود خدمة الإنترنت الموجه في "وضع الجسر" ، حيث يعمل فقط كمنهي اتصال ، مما يوفر نقطة نهاية PPPoE لنظام متصل واحد بالضبط. هذا يعني أن الجهاز يتوقف عن العمل كنقطة وصول WiFi أو حتى كجهاز توجيه منزلي مشترك. يتم التعامل مع كل هذه المهام بواسطة جهاز توجيه Mikrotik الصغير الاحترافي RB951G-2HnD. يقوم بتنفيذ خدمة NAT لشبكتي المحلية (التي قمت بترقيمها 10.10.10.0/24) ، ويقدم DHCP للأجهزة السلكية واللاسلكية المتصلة بها. يحتوي Mikrotik و Raspberry Pi على عناوين ثابتة لأنها تستخدم في السياقات التي تتطلب عنوانًا معروفًا. في حالتي ، هما 10.10.10.1 و 10.10.10.10 على التوالي.

لا يحتوي اتصال منزلي على عنوان IP ثابت. بالنسبة إلى أغراضي ، يعد هذا مجرد إزعاج بسيط أثناء العمل عن بُعد لأن الهدف هو إنشاء بيئة عمل شخصية أو بيئة عمل SOHO ، وليس موقعًا يعمل على مدار الساعة طوال أيام الأسبوع. (بالنسبة لأولئك الذين يحتاجون إلى عنوان IP ثابت لخادمهم ، من الجدير بالذكر أن تكلفة عناوين IP الثابتة استمرت في الانخفاض وأن خيارات VPN IP ثابتة وغير مكلفة إلى حد ما متوفرة.) وسيط DNS الذي أستخدمه ، Joker.com ، تقدم خدمة DNS ديناميكية مجانية إلى جانب جميع خدماتها الأخرى ، لذلك يوجد مجال فرعي واحد من نطاقي الشخصي كاسم ديناميكي. أستخدم هذا الاسم للاتصال من الخارج بشبكتي الخاصة ، وتم تكوين Mikrotik لتمرير SSH و HTTP عبر NAT إلى Raspberry Pi. أنا ببساطة بحاجة إلى كتابة ما يعادل ssh mydomain.example.com لتسجيل الدخول إلى خادم منزلي الشخصي.

البيانات في أي مكان

أحد الأشياء المهمة التي لا يقدمها Raspberry Pi هو التكرار. لقد قمت بتجهيزها ببطاقة 32 جيجا بايت ، ولا يزال هناك الكثير من البيانات لتفقدها في حالة حدوث شيء ما. للتغلب على ذلك ، ولضمان الوصول إلى بياناتي في حالة حدوث عوائق في الوصول إلى الإنترنت ، أقوم بنسخ جميع بياناتي إلى خادم خارجي يشبه السحابة. نظرًا لأنني في أوروبا ، كان من المنطقي بالنسبة لي الحصول على أصغر خادم مخصص من المعدن (أي غير افتراضي) من Online.net ، والذي يأتي مزودًا بوحدة معالجة مركزية VIA منخفضة المستوى توفر ذاكرة وصول عشوائي (RAM) بسعة 2 جيجابايت وذاكرة وصول عشوائي (SSHD) سعة 500 جيجابايت. كما هو الحال مع خادم Raspberry Pi الصغير ، لا أحتاج إلى أداء عالٍ لوحدة المعالجة المركزية أو حتى ذاكرة ، لذا فهذه مباراة مثالية. (بعيدًا عن ذلك ، أتذكر أول خادم "كبير" يحتوي على وحدتي CPU Pentium 3 وذاكرة وصول عشوائي (RAM) سعة 1 غيغابايت ، وربما كان نصف سرعة Raspberry Pi 2 ، وكيف قمنا بأشياء رائعة باستخدامه ، مما أثر على الاهتمام بالتحسين.)

أقوم بعمل نسخة احتياطية من Raspberry Pi على الخادم البعيد الذي يشبه السحابة باستخدام rdiff-backup. انطلاقًا من الأحجام النسبية للأنظمة ، ستوفر لي هذه النسخ الاحتياطية سجلًا غير محدود تقريبًا. هناك شيء آخر لدي على الخادم الشبيه بالسحابة وهو تثبيت ownCloud ، والذي يمكّنني من تشغيل خدمة شبيهة بخدمة Dropbox خاصة. تتجه ownCloud كمنتج نحو البرامج الجماعية والتعاون ، لذلك يصبح أكثر فائدة إذا كان يستخدمه المزيد من الأشخاص. منذ أن بدأت في استخدامه ، لا أمتلك حرفيًا أي بيانات محلية لم يتم نسخها احتياطيًا إلى Raspberry Pi أو إلى خادم يشبه السحابة ، ويتم نسخ معظمها احتياطيًا مرتين. دائمًا ما يكون أي تكرار إضافي للنسخ الاحتياطي يمكنك إجراؤه أمرًا جيدًا ، إذا كنت تقدر بياناتك.

"سحر" SSHFS

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

أصبح الخيار الأخير ممكنًا بفضل SSHFS ، والذي يمكّنني من تحميل دليل بعيد من Raspberry Pi محليًا. هذا يشبه قطعة صغيرة من السحر: يمكنك الحصول على دليل بعيد على أي خادم لديك وصول SSH إليه (يعمل تحت الأذونات التي يمتلكها المستخدم على الخادم) مثبتًا كدليل محلي.

هل لديك دليل مشروع بعيد؟ قم بتثبيته محليًا واذهب إليه. إذا كنت بحاجة إلى خادم قوي للتطوير أو الاختبار - ولسبب ما ، فإن مجرد الذهاب إلى هناك واستخدام vim في وحدة التحكم ليس خيارًا - فقم بتثبيت هذا الخادم محليًا وافعل ما تريد. يعمل هذا بشكل جيد بشكل خاص عندما أكون على اتصال منخفض النطاق الترددي بالإنترنت: حتى إذا كنت أعمل في محرر نصوص وحدة التحكم ، فإن التجربة تكون أفضل بكثير إذا قمت بتشغيل هذا المحرر محليًا ثم نقل الملفات عبر SSHFS ، بدلاً من ذلك من العمل على جلسة SSH عن بعد.

هل تحتاج إلى مقارنة عدة أدلة /etc على خوادم بعيدة مختلفة؟ لا مشكلة. فقط استخدم SSHFS لتركيب كل منها محليًا ثم استخدم فرق (أو أي أداة أخرى قابلة للتطبيق) لمقارنتها.

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

لأغراضي ، أستخدم الخيارات التالية في سطر أوامر sshfs :

sshfs -o reconnect -o idmap=user -o follow_symlinks -C server.example.com:. server

إليك ما تفعله خيارات سطر الأوامر هذه:

• -o reconnect - يخبر sshfs بإعادة توصيل نقطة نهاية SSH في حالة تعطلها. هذا مهم للغاية لأنه افتراضيًا ، عند انقطاع الاتصال ، ستفشل نقطة التحميل إما فجأة أو تتوقف ببساطة (وهو ما وجدته أكثر شيوعًا). يبدو لي حقًا أن هذا يجب أن يكون الخيار الافتراضي.
• -o idmap=user - يخبر sshfs أن يقوم بتعيين المستخدم البعيد (أي المستخدم الذي نتصل به) ليكون هو نفسه المستخدم المحلي. نظرًا لأنه يمكنك الاتصال عبر SSH باسم مستخدم عشوائي ، فإن هذا "يصلح" الأشياء بحيث يعتقد النظام المحلي أن المستخدم هو نفسه. تنطبق حقوق وأذونات الوصول على النظام البعيد كالمعتاد للمستخدم البعيد.
• -o follow_symlinks - بينما يمكن أن يكون لديك عدد تعسفي من أنظمة الملفات البعيدة المثبتة ، أجد أنه من الأنسب تحميل دليل بعيد واحد ، ودليل منزلي ، وفيه (في جلسة SSH البعيدة) يمكنني إنشاء روابط رمزية إلى أدلة مهمة في أي مكان آخر على النظام البعيد ، مثل /srv أو /etc أو /var/log . هذا الخيار يجعل sshfs يحل الارتباطات الرمزية البعيدة إلى ملفات وأدلة ، مما يسمح لك بمتابعة الدلائل المرتبطة.
• -C - يقوم بتشغيل ضغط SSH. هذا فعال بشكل خاص مع البيانات الوصفية للملفات والملفات النصية ، لذلك يبدو أنه خيار آخر يجب أن يكون خيارًا افتراضيًا.
• server.example.com:. - هذه هي نقطة النهاية البعيدة. الجزء الأول ( server.example.com في هذا المثال) هو اسم المضيف ، والجزء الثاني (بعد النقطتين) هو الدليل البعيد المطلوب تحميله. في هذه الحالة ، أضفت "." للإشارة إلى الدليل الافتراضي الذي ينتهي به المستخدم الخاص بي بعد تسجيل الدخول إلى SSH ، وهو دليلي الرئيسي.
• server - الدليل المحلي الذي سيتم تركيب نظام الملفات البعيد فيه.

خاصة إذا كنت تستخدم نطاق ترددي منخفض أو اتصال إنترنت غير مستقر ، فأنت بحاجة إلى استخدام SSHFS مع مصادقة المفتاح العام / الخاص SSH ، ووكيل SSH محلي. بهذه الطريقة ، لن تتم مطالبتك بكلمات المرور (إما كلمات مرور النظام أو كلمات مرور مفتاح SSH) عند استخدام SSHFS وستعمل ميزة إعادة الاتصال كما هو معلن. لاحظ أنه إذا لم يكن لديك وكيل SSH تم إعداده بحيث يوفر المفتاح غير المؤمَّن حسب الحاجة في جلستك ، فستفشل ميزة إعادة الاتصال عادةً. الويب مليء بدروس SSH الرئيسية ، ومعظم بيئات سطح المكتب المستندة إلى GTK حاولت بدء وكيل خاص بهم (أو "المحفظة" ، أو أي شيء يختارونه) تلقائيًا.

بعض حيل SSH المتقدمة

إن وجود نقطة ثابتة على الإنترنت يمكن الوصول إليها عن بُعد من أي مكان في العالم ، وهي متصلة بنطاق ترددي عالٍ - بالنسبة لي ، إنه نظام Raspberry Pi الخاص بي ، ويمكن أن يكون حقًا أي خادم VPS عام - يقلل من التوتر ويسمح لك بالقيام بذلك كل أنواع الأشياء بتبادل البيانات ونفقها.

هل تحتاج إلى nmap سريع وأنت متصل عبر شبكة هاتف محمول؟ فقط افعلها من ذلك الخادم هل تحتاج إلى نسخ بعض البيانات بسرعة و SSHFS يعد مبالغة؟ فقط استخدم SCP العادي.

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

• 192.168.77.15 - مضيف في الشبكة المحلية البعيدة خلف جدار حماية تحتاج إلى الاتصال بمنفذه 80
• foo.example.com - مضيف لديك وصول SSH إليه ، والذي يمكنه الاتصال بالمضيف أعلاه
• نظامك المحلي ، المضيف المحلي

سيكون أمر إعادة توجيه المنفذ 80 على 192.168.77.15 إلى المضيف المحلي: 8080 عبر خادم foo.example.com SSH هو:

ssh -L 8080:192.168.77.15:80 -C foo.example.com

تحدد الوسيطة إلى -L المنفذ المحلي وعنوان الوجهة والمنفذ. تتيح الوسيطة -C الضغط ، بحيث يمكنك مرة أخرى تحقيق توفير في عرض النطاق الترددي ، وفي النهاية يمكنك ببساطة كتابة اسم مضيف SSH. سيفتح هذا الأمر جلسة SSH shell عادية للمضيف ، وبالإضافة إلى ذلك ، استمع إلى منفذ localhost 8080 ، الذي يمكنك الاتصال به.

إحدى الحيل الأكثر إثارة للإعجاب التي طورتها SSH في السنوات الأخيرة هي قدرتها على إنشاء أنفاق VPN حقيقية. تُظهر هذه الأجهزة نفسها كأجهزة شبكة افتراضية على جانبي الاتصال (بافتراض أن لديهم عناوين IP مناسبة تم إعدادها) ويمكن أن تسمح لك بالوصول إلى الشبكة البعيدة كما لو كنت هناك فعليًا (تجاوز جدران الحماية). لأسباب فنية وأمنية ، يتطلب هذا الوصول إلى الجذر على كلا الجهازين المتصلين بالنفق ، لذا فهو أقل ملاءمة بكثير من مجرد استخدام إعادة توجيه المنفذ أو SSHFS أو SCP. هذا واحد للمستخدمين المتقدمين هناك ، والذين يمكنهم بسهولة العثور على برامج تعليمية حول كيفية القيام بذلك.

المكتب البعيد في أي مكان

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