مدیر عملیات پورتال Banki.ru آندری نیکولسکی در کنفرانس سال گذشته صحبت کرد در مورد خدمات یتیم: چگونه یک یتیم را در زیرساخت شناسایی کنیم، چرا خدمات یتیم بد هستند، با آنها چه باید کرد، و اگر هیچ کمکی نکرد چه باید کرد.
در زیر برش نسخه متنی گزارش آمده است.
سلام همکاران! نام من آندری است، من مدیر عملیات بانکی.رو هستم.
ما خدمات بزرگی داریم، این خدمات یکپارچه هستند، خدمات به معنای کلاسیک تر وجود دارد و خدمات بسیار کوچکی وجود دارد. در اصطلاح کارگری - دهقانی من می گویم که اگر خدمتی ساده و کوچک باشد، خرد است و اگر خیلی ساده و کوچک نباشد، فقط یک خدمت است.
مزایای خدمات
من به سرعت مزایای خدمات را مرور خواهم کرد.
اولین مورد مقیاس بندی است. شما می توانید به سرعت کاری روی سرویس انجام دهید و تولید را شروع کنید. شما ترافیک دریافت کرده اید، سرویس را شبیه سازی کرده اید. شما ترافیک بیشتری دارید، آن را شبیه سازی کرده اید و با آن زندگی می کنید. این امتیاز خوبی است و اصولاً زمانی که ما شروع کردیم، مهمترین چیز برای ما محسوب می شد که چرا این همه کار را انجام می دهیم.
دوم، توسعه ایزوله، زمانی که شما چندین تیم توسعه، چندین توسعه دهنده مختلف در هر تیم دارید و هر تیم سرویس خود را توسعه می دهد.
با تیم ها یک تفاوت ظریف وجود دارد. توسعه دهندگان متفاوت هستند. و برای مثال وجود دارد . من اولین بار این را با ماکسیم دوروفیف دیدم. گاهی اوقات افراد دانه برف در برخی تیم ها حضور دارند و در برخی دیگر نه. این باعث می شود خدمات مختلف مورد استفاده در سراسر شرکت کمی ناهموار باشد.
به تصویر نگاه کنید: این یک توسعه دهنده خوب است، او دست های بزرگی دارد، او می تواند کارهای زیادی انجام دهد. مشکل اصلی این است که این دست ها از کجا می آیند.
خدمات امکان استفاده از زبان های برنامه نویسی مختلف را فراهم می کند که برای کارهای مختلف مناسب تر هستند. برخی از سرویس ها در Go، برخی در Erlang، برخی در Ruby، برخی در PHP، برخی در Python هستند. به طور کلی، شما می توانید به طور گسترده گسترش دهید. تفاوت های ظریف در اینجا نیز وجود دارد.
معماری سرویس گرا در درجه اول در مورد devops است. یعنی، اگر اتوماسیون ندارید، هیچ فرآیند استقرار وجود ندارد، اگر آن را به صورت دستی پیکربندی کنید، تنظیمات شما می‌تواند از نمونه سرویس به نمونه دیگر تغییر کند، و برای انجام کاری باید به آنجا بروید، پس در جهنم هستید.
به عنوان مثال، شما 20 سرویس دارید و باید به صورت دستی مستقر شوید، 20 کنسول دارید، و همزمان مانند یک نینجا "enter" را فشار می دهید. خیلی خوب نیست
اگر سرویسی بعد از تست دارید (البته در صورت وجود تست) و باز هم باید آن را با فایل تمام کنید تا در تولید کار کند، خبر بدی هم برای شما دارم.
اگر به خدمات خاصی آمازون تکیه می کنید و در روسیه کار می کنید، دو ماه پیش نیز "همه چیز در اطراف آتش گرفته است، من خوبم، همه چیز عالی است."
ما از Ansible برای خودکارسازی استقرار، Puppet برای همگرایی، Bamboo برای استقرار خودکار، و Confluence برای توصیف همه آن استفاده می کنیم.
من در این مورد با جزئیات صحبت نمی کنم، زیرا این گزارش بیشتر در مورد شیوه های تعامل است و نه در مورد اجرای فنی.
به عنوان مثال، ما در جایی که Puppet روی سرور با Ruby 2 کار می کند، مشکلاتی داشته ایم، اما برخی از برنامه ها برای Ruby 1.8 نوشته شده اند و با هم کار نمی کنند. آنجا مشکلی پیش می آید. و زمانی که نیاز به اجرای چندین نسخه روبی روی یک دستگاه دارید، معمولاً دچار مشکل می شوید.
مثلاً ما به هر توسعه‌دهنده‌ای پلتفرمی می‌دهیم که تقریباً همه چیزهایی که داریم، همه خدمات قابل توسعه روی آن وجود دارد، تا او یک محیط ایزوله داشته باشد، بتواند آن را بشکند و آن‌طور که می‌خواهد بسازد.
این اتفاق می افتد که شما به بسته ای خاص با پشتیبانی از چیزی در آنجا نیاز دارید. خیلی سخته من به گزارشی گوش دادم که در آن تصویر داکر 45 گیگابایت وزن دارد. در لینوکس، البته، ساده‌تر است، همه چیز در آنجا کوچک‌تر است، اما همچنان فضای کافی وجود نخواهد داشت.
خب، وابستگی های متناقضی وجود دارد، وقتی یک قطعه از پروژه به کتابخانه یک نسخه وابسته است، قطعه دیگری از پروژه به نسخه دیگری بستگی دارد، و کتابخانه ها اصلا با هم نصب نمی شوند.
ما سایت ها و سرویس هایی با PHP 5.6 داریم، شرمنده آنها هستیم، اما چه کنیم؟ این یک سایت ماست سایت ها و سرویس هایی در PHP 7 وجود دارد، تعداد آنها بیشتر است، ما شرمنده آنها نیستیم. و هر توسعه دهنده پایگاه مخصوص به خود را دارد که با خوشحالی می بیند.
اگر در یک شرکت به یک زبان بنویسید، سه ماشین مجازی برای هر توسعه دهنده طبیعی به نظر می رسد. اگر زبان های برنامه نویسی متفاوتی دارید، وضعیت بدتر می شود.
شما سایت ها و خدماتی را در این مورد دارید، در این، سپس یک سایت دیگر برای Go، یک سایت برای Ruby، و تعدادی Redis دیگر در کنار. در نتیجه، همه اینها به یک میدان بزرگ برای پشتیبانی تبدیل می‌شود و همیشه مقداری از آن می‌تواند شکسته شود.
بنابراین، ما مزایای زبان برنامه نویسی را با استفاده از فریمورک های مختلف جایگزین کردیم، زیرا فریم ورک های PHP کاملاً متفاوت هستند، آنها دارای قابلیت های مختلف، جوامع مختلف و پشتیبانی متفاوت هستند. و می توانید یک سرویس بنویسید تا از قبل چیزی برای آن آماده کرده باشید.
هر سرویس تیم خاص خود را دارد
مزیت اصلی ما، که طی چندین سال متبلور شده است، این است که هر سرویس تیم خاص خود را دارد. این برای یک پروژه بزرگ راحت است، می توانید در زمان اسناد صرفه جویی کنید، مدیران پروژه خود را به خوبی می شناسند.
شما به راحتی می توانید وظایف را از پشتیبانی ارسال کنید. مثلا خدمات بیمه خراب شد. و بلافاصله تیمی که با بیمه سر و کار دارد برای رفع آن می رود.
ویژگی‌های جدید به سرعت ایجاد می‌شوند، زیرا وقتی یک سرویس اتمی دارید، می‌توانید به سرعت چیزی را در آن پیچ کنید.
و هنگامی که سرویس خود را قطع می کنید، و این به ناچار این اتفاق می افتد، روی خدمات دیگران تأثیری نمی گذارید، و توسعه دهندگان تیم های دیگر با بیت به سمت شما نمی آیند و نمی گویند: "آی-ای، این کار را نکن."
مثل همیشه، تفاوت های ظریف وجود دارد. ما تیم های باثباتی داریم، مدیران به تیم میخکوب شده اند. اسناد روشنی وجود دارد، مدیران به دقت همه چیز را زیر نظر دارند. هر تیم با یک مدیر خدمات متعددی دارد و یک نقطه صلاحیت خاص وجود دارد.
اگر تیم ها شناور هستند (ما گاهی اوقات از این نیز استفاده می کنیم)، روش خوبی به نام "نقشه ستاره" وجود دارد.
شما لیستی از خدمات و افراد دارید. ستاره به این معنی است که شخص در این خدمت متخصص است، کتاب به این معنی است که شخص در حال مطالعه این سرویس است. وظیفه شخص این است که دفترچه را به صورت ستاره تغییر دهد. و اگر چیزی جلوی سرویس نوشته نشده باشد، مشکلات شروع می شود که در ادامه در مورد آن صحبت خواهم کرد.
خدمات یتیم چگونه ظاهر می شود؟
اولین مشکل، اولین راه برای دریافت خدمات یتیم در زیرساخت شما اخراج افراد است. آیا کسی تا به حال پیش از ارزیابی وظایف، ضرب الاجل های یک کسب و کار را رعایت کرده است؟ گاهی اوقات اتفاق می افتد که ضرب الاجل ها تنگ است و زمان کافی برای مستندسازی وجود ندارد. ما باید خدمات را به تولید واگذار کنیم، سپس آن را اضافه خواهیم کرد.»
اگر تیم کوچک باشد، این اتفاق می افتد که یک توسعه دهنده وجود دارد که همه چیز را می نویسد، بقیه در بال هستند. "من معماری اولیه را نوشتم، بیایید رابط ها را اضافه کنیم." سپس در یک نقطه، مدیر، به عنوان مثال، ترک می کند. و در این مدت، زمانی که مدیر رفت و مدیر جدیدی هنوز منصوب نشده است، توسعه دهندگان خودشان تصمیم می گیرند که سرویس به کجا می رود و در آنجا چه اتفاقی می افتد. و همانطور که می دانیم (بیایید چند اسلاید به عقب برگردیم)، در برخی از تیم ها افراد دانه برف وجود دارند، گاهی اوقات یک تیم دانه برف رهبری می کند. بعدش استعفا می دهد و ما یک سرویس یتیم می گیریم.
در عین حال، وظایف حمایتی و تجاری ناپدید نمی شوند، آنها به عقب ماندگی ختم می شوند. اگر در طول توسعه سرویس خطاهای معماری وجود داشته باشد، آنها نیز به عقب ماندگی ختم می شوند. سرویس کم کم رو به وخامت است.
چگونه یک یتیم را شناسایی کنیم؟
این فهرست وضعیت را به خوبی توصیف می کند. چه کسی در مورد زیرساخت های خود چیزی یاد گرفته است؟
درباره کارهای مستند: یک سرویس وجود دارد و به طور کلی کار می کند، یک کتابچه راهنمای دو صفحه ای در مورد نحوه کار با آن دارد، اما هیچ کس نمی داند که چگونه در داخل کار می کند.
یا مثلا نوعی کوتاه کننده لینک وجود دارد. به عنوان مثال، ما در حال حاضر از سه کوتاه کننده لینک برای اهداف مختلف در سرویس های مختلف استفاده می کنیم. اینها فقط عواقب آن است.
حالا من کاپیتان بدیهیات خواهم بود. آنچه باید انجام شود؟ ابتدا باید سرویس را به مدیر دیگری، تیم دیگری منتقل کنیم. اگر سرپرست تیم شما هنوز کنار نرفته است، در این تیم دیگر، وقتی متوجه شدید که خدمات مانند یک یتیم است، باید فردی را وارد کنید که حداقل چیزی در مورد آن می‌فهمد.
نکته اصلی: باید مراحل انتقال با خون نوشته شود. در مورد ما، من معمولاً این را نظارت می کنم، زیرا برای کار کردن به همه آن نیاز دارم. مدیران به تحویل سریع نیاز دارند و اینکه بعدا چه اتفاقی می افتد دیگر برایشان مهم نیست.
راه بعدی برای یتیم کردن این است که "ما این کار را به صورت برون سپاری انجام می دهیم، سریعتر خواهد بود، و سپس آن را به تیم تحویل خواهیم داد." مشخص است که همه در تیم برنامه هایی دارند، یک نوبت. اغلب یک مشتری تجاری فکر می کند که برون سپاری همان کاری را که بخش فنی شرکت دارد انجام می دهد. اگرچه انگیزه های آنها متفاوت است. راه حل های تکنولوژیکی عجیب و راه حل های الگوریتمی عجیبی در برون سپاری وجود دارد.
به عنوان مثال، ما یک سرویس داشتیم که Sphinx را در مکان‌های مختلف غیرمنتظره داشتیم. بعدا بهت میگم باید چیکار میکردم
برون سپاری ها چارچوب های خودنویس دارند. این فقط PHP خالی با کپی پیست از پروژه قبلی است، که در آن می توانید انواع چیزها را پیدا کنید. اسکریپت‌های استقرار وقتی نیاز به استفاده از چند اسکریپت Bash پیچیده برای تغییر چندین خط در یک فایل دارید، یک اشکال بزرگ هستند و این اسکریپت‌های استقرار توسط اسکریپت سوم فراخوانی می‌شوند. در نتیجه، سیستم استقرار را تغییر می‌دهید، چیز دیگری را انتخاب می‌کنید، پرش می‌کنید، اما سرویس شما کار نمی‌کند. چون اونجا باید 8 تا لینک دیگه بین فولدرهای مختلف قرار میداد. یا پیش می آید که هزار رکورد کار می کند، اما صد هزار دیگر کار نمی کند.
من به کاپیتانی ادامه خواهم داد. پذیرش خدمات برون سپاری یک روش اجباری است. آیا تا به حال کسی بوده است که یک سرویس برون سپاری رسیده باشد و جایی پذیرفته نشود؟ البته این به اندازه یک سرویس یتیم محبوب نیست، اما همچنان.
سرویس باید بررسی شود، سرویس باید بررسی شود، رمز عبور باید تغییر کند. یک مورد داشتیم که به ما سرویس دادند، یک پنل مدیریت وجود دارد "اگر ورود == 'admin' && password == 'admin'..."، درست در کد نوشته شده است. ما می نشینیم و فکر می کنیم، و مردم این را در سال 2018 می نویسند؟
آزمایش ظرفیت ذخیره سازی نیز یک چیز ضروری است. شما باید ببینید در صد هزار رکورد چه اتفاقی خواهد افتاد، حتی قبل از اینکه این سرویس را در جایی تولید کنید.
در ارسال یک سرویس برای بهبود نباید شرم آور باشد. وقتی می گویید: "ما این سرویس را قبول نمی کنیم، 20 کار داریم، آنها را انجام دهید، سپس می پذیریم"، این طبیعی است. وجدان شما نباید از این موضوع که مدیر راه اندازی می کنید یا کسب و کار در حال هدر دادن پول است آزرده خاطر شود. سپس کسب و کار بیشتر هزینه خواهد کرد.
موردی داشتیم که تصمیم گرفتیم یک پروژه آزمایشی را برون سپاری کنیم.
به موقع تحویل داده شد و این تنها معیار کیفی بود. به همین دلیل است که ما یک پروژه آزمایشی دیگر ساختیم، که حتی دیگر واقعاً آزمایشی نبود. این خدمات پذیرفته شد و از طریق اداری گفتند کد شما اینجاست تیم اینجا مدیر شماست. خدمات در واقع قبلاً شروع به سودآوری کرده اند. در عین حال، در واقع، آنها هنوز یتیم هستند، هیچ کس نمی فهمد که چگونه کار می کنند، و مدیران تمام تلاش خود را می کنند تا وظایف خود را رد کنند.
یک مفهوم عالی دیگر وجود دارد - توسعه چریکی. زمانی که برخی از بخش‌ها، معمولاً بخش بازاریابی، می‌خواهند یک فرضیه را آزمایش کنند و کل خدمات را برون‌سپاری می‌کنند. ترافیک شروع می شود به داخل آن، اسناد را می بندند، با پیمانکار سند امضا می کنند، وارد عملیات می شوند و می گویند: رفقا، ما اینجا سرویس داریم، قبلاً ترافیک دارد، برای ما پول می آورد، قبول کنیم. ما می گفتیم: "اوپا، چطور ممکن است."
و یک راه دیگر برای دریافت سرویس یتیم: وقتی یک تیم ناگهان خود را لود می بیند، مدیریت می گوید: "بیایید سرویس این تیم را به تیم دیگری منتقل کنیم، بار کمتری دارد." و سپس آن را به تیم سوم منتقل می کنیم و مدیر را تغییر می دهیم. و در نهایت ما دوباره یک یتیم داریم.
مشکل یتیمان چیست؟
کسی که نداند، این کشتی جنگی Wasa است که در سوئد پرورش یافته است و به این دلیل مشهور است که 5 دقیقه پس از پرتاب غرق شد. و پادشاه سوئد، اتفاقا، کسی را برای این اعدام نکرد. این توسط دو نسل مهندس ساخته شد که نمی دانستند چگونه چنین کشتی هایی بسازند. اثر طبیعی.
به هر حال، کشتی می توانست به روشی بسیار بدتر غرق شود، مثلاً زمانی که پادشاه قبلاً در جایی در طوفان سوار بر آن بود. و بنابراین، او بلافاصله غرق شد، به گفته Agile، خوب است که زود شکست بخورید.
اگر زودتر شکست بخوریم، معمولاً هیچ مشکلی وجود ندارد. مثلا در حین پذیرش برای بازبینی ارسال شد. اما اگر از قبل در تولید شکست بخوریم، زمانی که پول سرمایه گذاری می شود، ممکن است مشکلاتی وجود داشته باشد. عواقب، همانطور که در تجارت به آنها گفته می شود.
چرا خدمات یتیم خطرناک است:
- ممکن است سرویس به طور ناگهانی خراب شود.
- تعمیر سرویس زمان زیادی می برد یا اصلا تعمیر نمی شود.
- مشکلات ایمنی
- مشکلات با بهبود و به روز رسانی.
- اگر یک سرویس مهم خراب شود، شهرت شرکت آسیب می بیند.
با خدمات یتیم چه کنیم؟
باز هم تکرار می کنم که چه کار کنم. اولاً باید مستندات موجود باشد. 7 سال در Banki.ru به من آموخت که آزمایش کنندگان نباید حرف توسعه دهندگان را بپذیرند و عملیات نباید حرف همه را بپذیرد. باید بررسی کنیم.
ثانیاً، نوشتن نمودارهای تعامل ضروری است، زیرا اتفاق می افتد که خدماتی که چندان مورد استقبال قرار نگرفته اند دارای وابستگی هایی هستند که هیچ کس در مورد آنها صحبت نکرده است. به عنوان مثال، توسعه دهندگان این سرویس را روی کلید خود برای برخی از Yandex.Maps یا Dadata نصب کردند. محدودیت رایگان شما تمام شده است، همه چیز خراب است و اصلاً نمی دانید چه اتفاقی افتاده است. همه چنین رنک‌هایی باید شرح داده شوند: این سرویس از داده‌ها، پیامک و چیز دیگری استفاده می‌کند.
ثالثاً کار با بدهی فنی. وقتی نوعی عصا انجام می دهید یا خدمتی را می پذیرید و می گویید کاری باید انجام شود، باید مطمئن شوید که انجام شده است. زیرا در این صورت ممکن است معلوم شود که سوراخ کوچک آنقدرها هم کوچک نیست و شما از آن می افتید.
با کارهای معماری، داستانی درباره ابوالهول داشتیم. یکی از سرویس ها از Sphinx برای ورود به لیست ها استفاده می کرد. فقط یک لیست صفحه بندی شده، اما هر شب دوباره نمایه می شد. آن را از دو شاخص مونتاژ می کردند: یکی بزرگ هر شب نمایه می شد و یک شاخص کوچک نیز وجود داشت که به آن پیچ می شد. هر روز با احتمال 50 درصد بمباران یا نه، شاخص در حین محاسبه سقوط می کرد و اخبار ما در صفحه اصلی به روز نمی شد. در ابتدا 5 دقیقه طول کشید تا شاخص دوباره نمایه شود، سپس شاخص رشد کرد و در مقطعی شروع به 40 دقیقه برای نمایه سازی مجدد کرد. وقتی این را قطع کردیم، نفس راحتی کشیدیم، چون معلوم بود که کمی بیشتر می گذرد و نمایه ما به صورت تمام وقت مجددا ایندکس می شود. این یک شکست برای پورتال ما خواهد بود ، هشت ساعت خبری نیست - همین است ، تجارت متوقف شده است.
برای کار با یک سرویس یتیم برنامه ریزی کنید
در واقع، انجام این کار بسیار دشوار است، زیرا devops در مورد ارتباطات است. شما می خواهید با همکاران خود رابطه خوبی داشته باشید، و زمانی که با قوانین سر به سر همکاران و مدیران خود می زنید، ممکن است احساسات متناقضی نسبت به افرادی که این کار را انجام می دهند داشته باشند.
علاوه بر همه این نکات، یک نکته مهم دیگر وجود دارد: افراد خاصی باید برای هر سرویس خاص، برای هر بخش خاص از روند استقرار مسئولیت داشته باشند. وقتی مردم نباشند و مجبور شوید افراد دیگری را برای مطالعه این موضوع جذب کنید، کار سخت می شود.
اگر همه اینها کمکی نکرد، و سرویس یتیم شما هنوز یتیم است، هیچ کس نمی خواهد آن را به عهده بگیرد، اسناد نوشته نشده است، تیمی که به این سرویس فراخوانده شده است از انجام کاری امتناع می ورزد، یک راه ساده وجود دارد - انجام مجدد همه چيز .
یعنی الزامات سرویس را از نو می گیرید و سرویس جدید را بهتر، روی پلتفرم بهتر و بدون راه حل های تکنولوژیکی عجیب می نویسید. و شما در جنگ به آن مهاجرت می کنید.
ما موقعیتی داشتیم که سرویسی را در Yii 1 دریافت کردیم و متوجه شدیم که نمی توانیم آن را بیشتر توسعه دهیم، زیرا توسعه دهندگانی که می توانند روی Yii 1 به خوبی بنویسند تمام شده است. همه توسعه دهندگان به خوبی در Symfony XNUMX می نویسند. چه باید کرد؟ ما زمان را اختصاص دادیم، تیمی را اختصاص دادیم، مدیری را اختصاص دادیم، پروژه را بازنویسی کردیم و ترافیک را به آرامی به آن تغییر دادیم.
پس از این، سرویس قدیمی را می توان حذف کرد. این روش مورد علاقه من است، زمانی که شما باید برخی از سرویس ها را از سیستم مدیریت پیکربندی بردارید و پاک کنید و سپس مرور کنید و ببینید که همه خودروهای در حال تولید غیرفعال شده اند، به طوری که توسعه دهندگان هیچ ردی از آن باقی نماند. مخزن در Git باقی می ماند.
این تمام چیزی است که می خواستم در مورد آن صحبت کنم، من آماده بحث هستم، موضوع هولیوار است، بسیاری در آن شنا کرده اند.
اسلایدها می گفتند که شما زبان ها را یکپارچه کرده اید. یک مثال تغییر اندازه تصاویر بود. آیا واقعاً لازم است که آن را به یک زبان محدود کنیم؟ از آنجا که تغییر اندازه تصویر در PHP، خوب، در واقع می تواند در Golang انجام شود.
در واقع، مانند همه تمرین ها اختیاری است. شاید در برخی موارد حتی نامطلوب باشد. اما باید بدانید که اگر یک بخش فنی در یک شرکت 50 نفره دارید، 45 نفر از آنها متخصص PHP هستند، 3 نفر دیگر توسعه دهنده هستند که Python، Ansible، Puppet و مواردی از این قبیل را می شناسند، و فقط یکی از آنها در برخی از آنها می نویسد. برخی از خدمات تغییر اندازه تصویر Go، پس از خروج، تخصص با آن همراه می شود. و در عین حال، باید به دنبال یک توسعه دهنده خاص بازار باشید که این زبان را بلد باشد، به خصوص اگر نادر باشد. یعنی از نظر سازمانی این مشکل دارد. از نقطه نظر توسعه، شما نه تنها نیازی به شبیه سازی مجموعه آماده ای از کتاب های بازی که برای استقرار سرویس ها استفاده می کنید ندارید، بلکه باید آنها را دوباره از نو بنویسید.
ما در حال حاضر در حال ساخت یک سرویس در Node.js هستیم و این فقط یک پلتفرم در نزدیکی هر توسعه دهنده با یک زبان جداگانه خواهد بود. اما ما نشستیم و فکر کردیم که بازی ارزش شمع را دارد. یعنی این سوالی است که شما بنشینید و به آن فکر کنید.
چگونه بر خدمات خود نظارت می کنید؟ چگونه گزارش ها را جمع آوری و نظارت می کنید؟
لاگ ها را در Elasticsearch جمع آوری می کنیم و در کیبانا قرار می دهیم و بسته به اینکه محیط های تولیدی یا آزمایشی باشد از کلکتورهای مختلفی در آنجا استفاده می شود. جایی چوب‌جنگ، جای دیگری چیز دیگری، یادم نیست. و هنوز جاهایی در برخی سرویس‌ها وجود دارد که ما Telegraf را نصب می‌کنیم و در جای دیگری جداگانه عکس می‌گیریم.
چگونه با Puppet و Ansible در یک محیط زندگی کنیم؟
در واقع ما الان دو محیط داریم، یکی Puppet و دیگری Ansible. ما در حال کار برای ترکیب آنها هستیم. Ansible یک چارچوب خوب برای راه اندازی اولیه است، Puppet یک چارچوب بد برای راه اندازی اولیه است زیرا به کار عملی مستقیماً روی پلت فرم نیاز دارد، و Puppet همگرایی پیکربندی را تضمین می کند. این بدان معناست که پلتفرم خود را در وضعیت به‌روز نگه می‌دارد و برای اینکه دستگاه غیرفعال‌شده به‌روز نگه داشته شود، باید همیشه کتاب‌های پخش را با مقداری فرکانس روی آن اجرا کنید. این تفاوت است.
چگونه سازگاری را حفظ می کنید؟ آیا تنظیماتی در Ansible و Puppet دارید؟
این درد بزرگ ما است، ما با دستان خود سازگاری را حفظ می کنیم و به این فکر می کنیم که چگونه از این همه جایی در حال حاضر حرکت کنیم. معلوم می‌شود که Puppet بسته‌ها را منتشر می‌کند و برخی از پیوندها را در آنجا نگه می‌دارد، و برای مثال Ansible، کد را منتشر می‌کند و آخرین تنظیمات برنامه را در آنجا تنظیم می‌کند.
ارائه در مورد نسخه های مختلف روبی بود. چه راه حلی؟
ما در یک جا با این موضوع مواجه شدیم و باید همیشه آن را در ذهن خود نگه داریم. ما به سادگی قسمتی را که روی Ruby اجرا می شد و با برنامه ها ناسازگار بود خاموش کردیم و آن را جدا نگه داشتیم.
کنفرانس امسال در تاریخ 7 دسامبر در تکنوپولیس برگزار می شود. ما تا 11 نوامبر در حال پذیرش درخواست های گزارش هستیم. اگر مایلید با ما صحبت کنید
ثبت نام برای شرکت کنندگان باز است، به ما بپیوندید!
منبع: www.habr.com