قمنا بتطوير DevOps قدر الإمكان. كان هناك 8 منا ، وفاسيا كان أروع على ويندوز. فجأة ، غادر Vasya ، وكان لدي مهمة لإخراج مشروع جديد يوفر تطوير Windows. عندما سكبت مجموعة تطوير Windows بالكامل على الطاولة ، أدركت أن الموقف يمثل ألمًا ...
هكذا تبدأ قصة
ألكساندر سينشينوف في
DevOpsConf . عندما غادر أخصائي Windows الرائد الشركة ، تساءل ألكساندر عما يجب فعله الآن. التبديل إلى Linux ، بالطبع! سيخبر ألكساندر كيف تمكن من وضع سابقة ونقل جزء من تطوير Windows إلى Linux باستخدام مثال لمشروع مكتمل لـ 100،000 مستخدم نهائي.
كيف يمكن تسليم مشروع جهد إلى RPM بسهولة وبدون عناء باستخدام TFS و Puppet و Linux .NET الأساسية؟ كيفية الحفاظ على إصدار قاعدة بيانات المشروع إذا كان التطوير يسمع أولاً كلمات Postgres و Flyway ، والموعد النهائي ليوم غد؟ كيف تتكامل مع Docker؟ كيفية تحفيز مطوري .NET على التخلي عن Windows و smoothies لصالح Puppet و Linux؟ كيف يمكن حل النزاعات الإيديولوجية ، إذا لم تكن هناك قوى أو رغبة أو موارد لخدمة Windows في الإنتاج؟ حول هذا الموضوع ، وكذلك حول Web Deploy ، الاختبار ، CI ، حول ممارسات استخدام TFS في المشاريع الحالية ، وبطبيعة الحال ، حول العكازات المكسورة وحلول العمل ، في فك شفرة تقرير ألكساندر.
لذلك ، غادر Vasya ، المهمة بالنسبة لي ، المطورين يتطلعون
مع مذراة . عندما أدركت أخيرًا أن فاسيا لا يمكن إعادتها ، بدأت العمل. بادئ ذي بدء ، قدرت النسبة المئوية للفوز VM في منتزهنا. وكانت النتيجة ليست في صالح ويندوز.
نظرًا لأننا نعمل على تطوير DevOps بشكل نشط ، فقد أدركت أنه يجب تغيير شيء ما في طريقة الحصول على تطبيق جديد. كان الحل واحدًا - إن أمكن ، نقل كل شيء إلى Linux. لقد ساعدني Google - في ذلك الوقت. تم نقل Net إلى Linux بالفعل ، وأدركت أن هذا الحل!
لماذا تم دمج .NET الأساسية مع Linux؟
كانت هناك عدة أسباب لذلك. بين "دفع المال" و "لا تدفع" ، ستختار الأغلبية الثانية - مثلي. تبلغ تكلفة ترخيص MSDB حوالي 1000 دولار ؛ وتكاليف صيانة أسطول الجهاز الظاهري لـ Windows مئات الدولارات. بالنسبة لشركة كبيرة ، هذه تكلفة كبيرة. لذلك ،
الادخار هو
السبب الأول . ليس الأكثر أهمية ، ولكن واحدة من أهم.
تستهلك أجهزة Windows الافتراضية موارد أكثر من إخوانها في نظام Linux -
فهي ثقيلة . بالنظر إلى حجم شركة كبيرة ، اخترنا لينكس.
تم دمج النظام ببساطة في CI الحالي . نحن نعتبر أنفسنا بمثابة أدوات تطوير تقدمية ، نستخدم Bamboo و Jenkins و GitLab CI ، لذا فإن معظم أعمالنا تعمل على نظام Linux.
السبب الأخير هو
مرافقة مريحة. اضطررنا إلى خفض عتبة الدخول لـ "مرافقين" - الرجال الذين يفهمون الجزء الفني ، ويضمنون التشغيل والخدمات غير المنقطعة من السطر الثاني. لقد كانوا معتادًا بالفعل على رصة Linux ، لذا فمن الأسهل عليهم فهم المنتج الجديد ، والمحافظة عليه ، وصيانته ، بدلاً من إنفاق موارد إضافية للتعامل مع الوظائف المشابهة للبرنامج لنظام Windows الأساسي.
متطلبات
أولاً وقبل كل شيء ،
راحة الحل الجديد للمطورين . لم يكن جميعهم مستعدين للتغيير ، خاصة بعد الكلمة المنطوقة Linux. يريد المطورون من Visual Studio المحبوب ، TFS مع اختبارات الإنشاء والعصائر. كيف يتم التسليم في الإنتاج - لا يهتمون. لذلك ، قررنا عدم تغيير العملية المعتادة وترك كل شيء دون تغيير لتطوير Windows.
يحتاج المشروع الجديد
إلى تضمينه في CI الحالي . كانت القضبان موجودة بالفعل وكان يتعين القيام بجميع الأعمال مع مراعاة معايير نظام إدارة التكوين ومعايير التسليم المقبولة وأنظمة المراقبة.
بساطة في الدعم والتشغيل ، كشرط لعتبة دخول الحد الأدنى لجميع المشاركين الجدد من مختلف الإدارات وإدارة الدعم.
الموعد النهائي - أمس .
فوز مجموعة التنمية
ماذا عمل فريق ويندوز مع ذلك؟
الآن يمكنني أن أقول بثقة أن
IdentityServer4 هو بديل مجاني رائع لـ ADFS مع إمكانيات مماثلة ، أو أن
Entity Framework Core هو جنة مطور حيث لا يمكنك عناء كتابة نصوص SQL ، ولكن وصف الاستعلامات في قاعدة البيانات بعبارات OOP. ولكن بعد ذلك ، عند مناقشة خطة العمل ، نظرت إلى هذه المجموعة على أنها كتابة مسمارية سومرية تعترف فقط بوحدة PostgreSQL و Git.
في ذلك الوقت ، استخدمنا بنشاط
Puppet كنظام إدارة التكوين. في معظم مشاريعنا ، استخدمنا
GitLab CI ، و
Flex ، خدمات متوازنة محملة للغاية باستخدام
HAProxy ، وراقبنا كل شيء مع
Zabbix ، ومجموعة من
Grafana و
Prometheus ،
Jaeger ، وكل هذا كان يدور على أجهزة
HP مع
ESXi على
VMware . يعلم الجميع - كلاسيكي من هذا النوع.
دعونا ننظر ونحاول أن نفهم ما حدث قبل أن نبدأ كل هذه التدخلات.
ماذا كان
TFS هو نظام قوي إلى حد ما لا يقدم فقط رمزًا من المطور إلى آلة الإنتاج النهائية ، ولكن لديه أيضًا مجموعة من أجل التكامل المرن للغاية مع مختلف الخدمات - لتوفير CI على مستوى النظام الأساسي المشترك.
سابقا ، كانت هذه النوافذ الصلبة. تستخدم TFS العديد من وكلاء Build ، والتي جمعت الكثير من المشاريع. كل وكيل لديه 3-4 عامل واحد من أجل موازنة المهام وتحسين هذه العملية. علاوة على ذلك ، وفقًا لخطط الإصدار ، قامت TFS بتسليم الإصدار Build to baked إلى خادم تطبيقات Windows.
ما أردنا أن نأتي إليه
للتسليم والتطوير ، نستخدم TFS ، ونطلق التطبيق على خادم تطبيق Linux ، وهناك نوع من السحر بينهما. هذا
المربع السحري هو ملح العمل القادم. قبل تفكيكه في أجزاء ، سوف أتخذ خطوة إلى جانب وأقول كلمتين حول التطبيق.
مشروع
يوفر التطبيق وظائف للتعامل مع البطاقات المدفوعة مسبقا.
زبون
كان هناك نوعان من المستخدمين. حصلت
الأولى على وصول عن طريق تسجيل الدخول باستخدام شهادة SSL SHA-2. وكان
الثاني الوصول عن طريق تسجيل الدخول وكلمة المرور.
HAProxy
علاوة على ذلك ، وقع طلب العميل في HAProxy ، مما أدى إلى حل المهام التالية:
- إذن أساسي
- إنهاء SSL
- ضبط طلبات HTTP ؛
- طلبات البث.
تم التحقق من شهادة العميل عبر السلسلة. نحن
سلطة ويمكننا تحملها ، لأننا نصدر شهادات لخدمة العملاء.
انتبه إلى النقطة الثالثة ، بعد قليل سنعود إليها.
الخلفية
خططوا لجعل الخلفية على لينكس. تتفاعل الواجهة الخلفية مع قاعدة البيانات ، وتحمل قائمة الامتيازات اللازمة ، ثم ، وفقًا للامتيازات التي يتمتع بها المستخدم المصرح به ، تتيح الوصول لتوقيع المستندات المالية وإرسالها للتنفيذ ، أو إنشاء نوع من التقارير.
حفظ مع HAProxy
بالإضافة إلى السياقين اللذين كان كل عميل يستخدمهما ، كان هناك أيضًا سياق هوية. يسمح لك
IdentityServer4 فقط بتسجيل الدخول ، بل هو تناظرية مجانية وقوية لـ
ADFS -
خدمات اتحاد الدليل النشط .
تمت معالجة الطلب في الهوية في عدة خطوات. الخطوة الأولى -
سقط العميل في الواجهة الخلفية ، حيث قام بتبادل البيانات مع هذا الخادم والتحقق من وجود رمز مميز للعميل. إذا لم أجده ، فسيتم إرجاع الطلب مرة أخرى إلى السياق الذي جاء منه ، ولكن مع إعادة توجيه ، ومع إعادة توجيه انتقل إلى الهوية.
الخطوة الثانية - ذهب الطلب
إلى صفحة المصادقة في IdentityServer ، حيث تم تسجيل العميل ، وظهر الرمز المميز الذي طال انتظاره في قاعدة بيانات IdentityServer.
الخطوة الثالثة -
إعادة توجيه العميل إلى السياق الذي جاء منه.
لدى IdentityServer4 خصوصية:
تقوم بإرجاع الاستجابة إلى طلب الإرجاع عبر HTTP . بغض النظر عن الطريقة التي واجهنا بها إعداد الخادم ، وبغض النظر عن كيفية تنويرنا بالوثائق ، في كل مرة تلقينا فيها طلبًا أوليًا من العميل بعنوان URL يأتي عبر HTTPS ، وعاد IdentityServer إلى السياق نفسه ، ولكن مع HTTP. كنا في حالة صدمة! وتم نقل كل هذا من خلال سياق الهوية إلى HAProxy ، وفي الرؤوس كان علينا تعديل بروتوكول HTTP إلى HTTPS.
ما هو التحسن وأين حفظوا؟
لقد وفرنا المال عن طريق استخدام حل مجاني للترخيص لمجموعة من المستخدمين ، والموارد ، حيث أننا لم نأخذ IdentityServer4 كملاحظة منفصلة في مقطع منفصل ، ولكن استخدمناها مع خلفية في نفس الخادم حيث تدور خلفية التطبيق.
كيف ينبغي أن تعمل
لذلك ، كما وعدت - ماجيك بوكس. نحن نفهم بالفعل أننا مضمونون للتقدم نحو Linux. دعونا صياغة مهام محددة تتطلب الحلول.
الدمية تظهر. لتقديم وإدارة تكوين الخدمة والتطبيق ، كان عليك كتابة وصفات رائعة. توضح لفة القلم ببلاغة مدى سرعة وفعالية ذلك.
طريقة التسليم. المعيار هو RPM. يفهم الجميع أنه في نظام Linux لا توجد طريقة بدونه ، لكن المشروع نفسه بعد التجميع كان عبارة عن مجموعة من ملفات DLL القابلة للتنفيذ. كان هناك حوالي 150 منهم ، المشروع صعب للغاية. الحل الوحيد المتناغم هو حزمة هذه الثنائيات في دورة في الدقيقة ونشر التطبيق منه.
الإصدارات. كان علينا أن نطلق سراحنا في كثير من الأحيان ، وكان علينا أن نقرر كيفية تشكيل اسم الحزمة. هذه مسألة مستوى تكامل TFS. كان لدينا وكيل بناء على لينكس. عندما يرسل TFS المهمة إلى المعالج - العامل - إلى وكيل Build ، فإنه يرسلها أيضًا مجموعة من المتغيرات التي تقع في بيئة عملية المعالج. يتم تمرير متغيرات البيئة هذه الاسم Build ، واسم الإصدار ، والمتغيرات الأخرى. اقرأ المزيد حول هذا الموضوع في قسم "تجميع حزمة RPM".
إعداد TFS جاء لإعداد خط أنابيب. في السابق ، جمعنا جميع مشاريع Windows على وكلاء Windows ، والآن يوجد وكيل Linux - وكيل Build الذي يجب إدراجه في مجموعة التجميع ، المخصب مع بعض القطع الأثرية ، أخبرنا عن نوع المشاريع التي سيتم بناؤها على وكيل Build هذا ، وتعديل خط أنابيب بطريقة أو بأخرى.
IdentityServer. ADFS ليست طريقتنا ، نحن نغرق للمصدر المفتوح.
دعنا نذهب من خلال المكونات.
المربع السحري
يتكون من أربعة أجزاء.
وكيل بناء لينكس. لينكس ، لأننا نقوم بتجميعه ، هو منطقي. تم تنفيذ هذا الجزء في ثلاث خطوات.
- تكوين العمال وأكثر من واحد ، لأنه كان يفترض توزيع العمل على المشروع.
- تثبيت .NET Core 1.x. لماذا 1.x عندما يكون الإصدار 2.0 متاحًا بالفعل في المستودع القياسي؟ لأنه عندما بدأنا التطوير ، كانت النسخة المستقرة 1.09 ، وتقرر القيام بالمشروع من أجله.
- بوابة 2.x.
مستودع دورة في الدقيقة. حزم RPM اللازمة ليتم تخزينها في مكان ما. كان من المفترض أن نستخدم نفس مستودع RPM للشركة المتاح لجميع مضيفي Linux. وكذلك فعلوا.
تم تكوين
webhook على خادم المستودع الذي قام بتنزيل حزمة RPM المطلوبة من الموقع المحدد. تم الإبلاغ عن إصدار الحزمة إلى webhook بواسطة وكيل Build.
GitLab. تحذير! لا يستخدم GitLab هنا من قِبل المطورين ، بل يستخدمه قسم العمليات للتحكم في إصدارات التطبيقات وإصدارات الحزم ومراقبة حالة جميع أجهزة Linux ويقوم بتخزين الوصفة - جميع قوائم Puppet.
Puppet - يحل جميع القضايا المثيرة للجدل ويقدم بالضبط التكوين الذي نريده من Gitlab.
نبدأ الغوص. كيف يتم تسليم DLL في دورة في الدقيقة؟
تسليم DDL إلى RPM
دعنا نقول لدينا نجم الروك لتطوير .NET. يستخدم Visual Studio وإنشاء فرع الإصدار. بعد ذلك يتم تحميله في Git ، Git هنا عبارة عن كيان TFS ، أي ، هو مستودع التطبيق الذي يعمل عليه المطور.
بعد ذلك ترى TFS أن هناك التزامًا جديدًا قد وصل. أي تطبيق؟ في إعدادات TFS ، هناك تسمية حول الموارد التي يملكها وكيل Build معين. في هذه الحالة ، يرى أننا نقوم ببناء مشروع .NET Core واختيار وكيل بناء Linux من المجموعة.
يتلقى عامل الإنشاء المصادر ، ويقوم بتنزيل
التبعيات الضرورية من .NET ، ومستودع npm ، إلخ. وبعد إنشاء التطبيق نفسه والتعبئة اللاحقة ، يرسل حزمة RPM إلى مستودع RPM.
من ناحية أخرى ، يحدث ما يلي. يشارك مهندس الصيانة مباشرة في تنفيذ المشروع: إنه يغير إصدار الحزم في
Hiera في المستودع حيث يتم تخزين وصفة التطبيق ، وبعد ذلك تقوم Puppet بتشغيل
Yum ، تلتقط الحزمة الجديدة من المستودع ، والإصدار الجديد من التطبيق جاهز للاستخدام.
بكلمات ، كل شيء بسيط ، لكن ماذا يحدث في الداخل على عامل Build نفسه؟
التعبئة والتغليف RPM DLL
تم استلام مصادر المشروع ومهمة الإنشاء من TFS.
يبدأ عامل
الإنشاء في بناء المشروع من المصدر . يتوفر المشروع المجمّع في شكل العديد من
ملفات DLL التي تم حزمها في أرشيف مضغوط لتقليل التحميل على نظام الملفات.
يتم طرح أرشيف ZIP
في دليل الإنشاء الخاص بحزمة RPM. بعد ذلك ، يقوم البرنامج النصي Bash بتهيئة متغيرات البيئة ، والعثور على إصدار Build ، وإصدار المشروع ، والمسار إلى دليل البناء ، وتشغيل RPM-build. في نهاية التجميع ، يتم نشر الحزمة إلى
المستودع المحلي ، الموجود على وكيل Build.
علاوة على ذلك ،
يتم إرسال طلب JSON من وكيل Build إلى الخادم في مستودع RPM مع اسم الإصدار والبناء. يقوم Webhook ، الذي تحدثت عنه سابقًا ، بتنزيل هذه الحزمة نفسها من المستودع المحلي على وكيل Build وإتاحة التجميع الجديد للتثبيت.
لماذا مثل هذا المخطط لتسليم حزمة إلى مستودع RPM؟ لماذا لا يمكنني إرسال الحزمة المجمعة على الفور إلى المستودع؟ الحقيقة هي أن هذا شرط للأمن. يقيد هذا السيناريو إمكانية التنزيل غير المصرح به لحزم RPM من قبل الغرباء إلى خادم يمكن الوصول إليه من جميع أجهزة Linux.
إصدار DB
عند التشاور مع التطوير ، اتضح أن اللاعبين أقرب إلى MS SQL ، ولكن في معظم المشروعات التي لا تعمل بنظام Windows ، استخدمنا بالفعل برنامج PostgreSQL مع القوة والرئيسية. نظرًا لأننا قررنا بالفعل التخلي عن كل شيء مدفوع ، فقد بدأنا في استخدام PostgreSQL هنا.
في هذا الجزء أريد أن أتحدث عن كيفية تطبيقنا لإصدار قاعدة البيانات وكيفية الاختيار بين Flyway و Entity Framework Core. النظر في إيجابيات وسلبيات.
سلبيات
يذهب Flyway في اتجاه واحد فقط ،
لا يمكننا التراجع - وهذا ناقص كبير. يمكن إجراء المقارنة مع Entity Framework Core وفقًا لمعايير أخرى - من وجهة نظر راحة المطور. تتذكر أننا وضعنا هذا في المقدمة ، وكان المعيار الرئيسي هو عدم تغيير أي شيء لتطوير Windows.
بالنسبة إلى Flyway ، احتجنا
إلى نوع من البرامج المجمعة بحيث لا يكتب
اللاعبون استعلامات SQL . هم أقرب بكثير للعمل من حيث OOP. لقد كتبنا تعليمات للعمل مع كائنات قاعدة البيانات ، وشكلنا استعلام SQL ونفذنا. الإصدار الجديد من قاعدة البيانات جاهز ، ملفوف - كل شيء على ما يرام ، كل شيء يعمل.
يحتوي Entity Framework Core على ناقص - تحت الأحمال الثقيلة ، فإنه
لا ينشئ استعلامات SQL المثلى ، ويمكن أن يكون سحب قاعدة البيانات كبيرًا. ولكن نظرًا لعدم وجود خدمة تحميل عالية ، فنحن لا نحسب الحمل بمئات RPS ، لقد اتخذنا هذه المخاطر وقمنا بتفويض المشكلة للمستقبل لنا.
الأشياء الجيدة
يعمل Entity Framework Core
خارج الصندوق وهو سهل التطوير ،
ويدمج Flyway
بسلاسة في CI الحالي . لكننا نفعل ذلك بشكل مريح للمطورين :)
لفة المتابعة الإجراء
يرى Puppet أن هناك تغييرًا في إصدار الحزم من بينها الحزمة المسؤولة عن الترحيل. أولاً ، يقوم بتثبيت حزمة تحتوي على البرامج النصية الترحيل والوظائف المرتبطة بقاعدة البيانات. بعد ذلك ، يتم إعادة تشغيل التطبيق الذي يعمل مع قاعدة البيانات. التالي هو تثبيت المكونات المتبقية. يرد وصف ترتيب تثبيت الحزم وإطلاق التطبيقات في بيان Puppet.
تستخدم التطبيقات بيانات حساسة ، مثل الرموز وكلمات المرور إلى قاعدة البيانات ، كل هذا يتم سحبه إلى التكوين باستخدام برنامج Puppet الرئيسي ، حيث يتم تخزينها في شكل مشفر.
قضايا TFS
بعد أن قررنا وأدركنا أن كل شيء يعمل حقًا بالنسبة لنا ، قررت أن أرى ما كان يحدث مع المجالس في TFS ككل لقسم تطوير Win للمشاريع الأخرى - كنا سنستعد بسرعة / لا نستعد ونصدر ، ووجدنا مشاكل كبيرة في السرعة .
سيستغرق أحد المشروعات الرئيسية ما بين 12 إلى 15 دقيقة - إنه وقت طويل ، ولا يمكنك العيش بهذه الطريقة. أظهر تحليل سريع انخفاضًا رهيبًا في I / O ، وهذا في الصفائف.
بعد أن قمت بتحليل مكون ، حددت ثلاثة بؤر. الأول هو
Kaspersky antivirus ، الذي يقوم بمسح التعليمات البرمجية المصدر على جميع وكلاء Windows Build. والثاني هو
ويندوز مفهرس. لم يتم قطع الاتصال به ، وعلى عملاء Build في الوقت الفعلي تم فهرسة كل شيء أثناء عملية النشر.
والثالث هو
تثبيت Npm. اتضح أننا في معظم خطوط الأنابيب استخدمنا هذا السيناريو بعينه. لماذا هو سيء؟ يبدأ إجراء تثبيت Npm عندما يتم تكوين شجرة التبعية في
package-lock.json ، حيث يتم إصلاح إصدارات الحزم التي سيتم استخدامها لبناء المشروع. المهم هو أن تثبيت Npm يقوم بإخراج أحدث إصدارات الحزم من الإنترنت في كل مرة ، وهذا وقت كبير في حالة مشروع كبير.
يقوم المطورون في بعض الأحيان بالتجربة على الجهاز المحلي لاختبار تشغيل جزء فردي أو مشروع ككل. في بعض الأحيان اتضح أن كل شيء محليًا كان رائعًا ، لكن تم تجميعه وطرحه - لم ينجح شيء. نبدأ في فهم المشكلة - نعم ، إصدارات مختلفة من حزم التبعية.
قرار
- مصادر إلى استثناءات AV.
- تعطيل الفهرسة.
- التبديل إلى npm ci .
تتمثل ميزة npm ci في أننا
نجمع شجرة التبعية مرة واحدة ، ونحصل على فرصة لتزويد المطور
بقائمة محدثة من الحزم التي يمكنه من خلالها التجريب محليًا قدر الإمكان. هذا
يوفر الوقت للمطورين الذين يكتبون الكود.
ترتيب
الآن قليلا عن تكوين مستودع. تاريخياً ، كنا نستخدم
Nexus لإدارة المستودعات ، بما في ذلك
REPO داخلي . يتم تسليم جميع المكونات التي نستخدمها لأغراض داخلية ، على سبيل المثال ، المراقبة المكتوبة ذاتيا ، إلى هذا المستودع الداخلي.
نحن نستخدم أيضًا
NuGet ، لأنه ذاكرات أفضل من مديري الحزم الآخرين.
يؤدي
بعد أن قمنا بتحسين وكلاء Build ، تم تقليل متوسط وقت البناء من 12 دقيقة إلى 7.
إذا عدنا جميع الأجهزة التي يمكن أن نستخدمها لنظام Windows ، لكننا قمنا بنقلها إلى Linux في هذا المشروع ، فقد وفرنا حوالي 10000 دولار ، وهذا فقط على التراخيص ، وإذا كنت تأخذ المحتوى في الاعتبار - أكثر.
خطط
في الربع القادم ، وضعت خطة العمل على تحسين تسليم رمز.
الانتقال إلى مرحلة ما قبل بناء صورة عامل الميناء . TFS شيء رائع مع الكثير من المكونات الإضافية التي تسمح لك بالاندماج في Pipeline ، بما في ذلك التجميع وفقًا للمشغل ، على سبيل المثال ، صورة Docker. نحن نريد أن نجعل هذا الزناد على نفس
الحزمة lock.json . إذا تغيرت مكونات المكونات المستخدمة لبناء المشروع بطريقة ما ، فسنحصل على صورة Docker جديدة. يتم استخدامه لاحقًا لنشر الحاوية مع التطبيق المترجم. الآن هذا ليس صحيحًا ، لكننا نخطط للتبديل إلى بنية الخدمات المصغرة في Kubernetes ، التي تتطور بنشاط في شركتنا وتخدم منذ فترة طويلة حلول الإنتاج.
ملخص
أحث الجميع على إلقاء نظام ويندوز ، لكن هذا ليس لأنني لا أعرف كيف أطبخه. والسبب هو أن معظم الحلول مفتوحة المصدر هي
كومة لينكس .
ستوفر على الموارد جيدا . في رأيي ، فإن المستقبل يكمن في حلول Open Source Linux مع مجتمع قوي.
نبذة عن المتحدث الكسندر سينشينوف على جيثب .DevOps Conf هو مؤتمر حول دمج عمليات التطوير والاختبار والتشغيل للمهنيين من المحترفين. هذا هو السبب في المشروع الذي تحدث الكسندر؟ تنفيذها والعمل ، وفي يوم الأداء تم إصدار نسختين ناجحتين. في DevOps Conf على RIT ++ يومي 27 و 28 مايو ، سيكون هناك المزيد من هذه الحالات من الممارسين. لا يزال بإمكانك القفز إلى آخر عربة وإرسال تقرير ، أو قضاء بعض الوقت في حجز تذكرة. قابلني في سكولكوفو!