سرویس ملی اطلاعات ماهواره‌ای محیطی (NESDIS) هزینه‌های مدیریت پیکربندی خود را برای لینوکس سازمانی Red Hat (RHEL) با مهاجرت از Puppet Enterprise به Ansible Tower تا 35 درصد کاهش داده است. در این ویدیوی «چگونه این کار را انجام دادیم»، مهندس سیستم، Michael Rau، مورد این مهاجرت را توضیح می‌دهد و نکات مفید و درس‌های آموخته‌شده از انتقال از یک SCM به دیگری را به اشتراک می‌گذارد.
از این ویدیو یاد خواهید گرفت:
- چگونه می توان امکان تغییر از شرکت عروسکی به برج Ansible را برای مدیریت توجیه کرد.
- از چه استراتژی هایی استفاده کنیم تا انتقال را تا حد امکان هموار کنیم.
- نکاتی برای تبدیل PE آشکار به Ansible Playbook.
- توصیه هایی برای نصب بهینه برج Ansible.
سلام به همه، نام من مایکل راو است، من یک مهندس ارشد سیستم در ActioNet هستم که برای سرویس NESDIS اداره ملی اقیانوسی و جوی (NOAA) کار می کند. امروز ما در مورد پیرایش رشته صحبت خواهیم کرد - تجربه شخصی من از مهاجرت از شرکت عروسکی به برج Ansible. موضوع این ارائه "نگاهی به زخم های من" است که پس از انجام این انتقال در اوایل سال باقی مانده است. من می خواهم آنچه را که در این فرآیند یاد گرفتم به اشتراک بگذارم. بنابراین وقتی کاری شبیه به این را بر عهده می گیرید، با استفاده از تجربه من، می توانید بدون هیچ کار اضافی، انتقال را انجام دهید.
اسلایدهای مشابه این را در ابتدای هر ارائه در Ansible Fest مشاهده می کنید. این اسلاید تاریخچه اتوماسیون شرکت من را نشان می دهد. من تازه وارد این کار نیستم زیرا از سال 2007 از Puppet/Puppet Enterprise استفاده می کنم. من در سال 2016 کار با Ansible را شروع کردم و مانند بسیاری از کاربران دیگر این محصول، امکان "ترفند" با استفاده از خط فرمان و اسکریپت های ساده (کتاب های بازی) را به خود جلب کرد. در پایان سال 2017، در مورد دلایل قوی انتقال به برج Ansible به مدیریت خود مراجعه کردم. در عرض یک دقیقه در مورد دلایلی که من را ترغیب به انجام این مرحله کرد به شما خواهم گفت. پس از دریافت رضایت مدیریت، چندین ماه دیگر برای تکمیل طرح به طول انجامید و من در ژانویه-بهمن ماه امسال این انتقال را انجام دادم. بنابراین، ما کاملاً Puppet را به نفع Ansible رها کردیم، و این یک چیز عالی است.
چیزی که در مورد Ansible بیشتر برای من جذابیت دارد توانایی نوشتن و استفاده از نقش ها و کتاب های بازی است. نقش ها برای ایجاد وظایف متمایز اما مرتبط و قرار دادن تمام داده های مربوط به آن وظایف در یک مکان عالی هستند. Playbook یک دستور YAML، فایل اسکریپتی است که اقدامات یک یا چند میزبان را توصیف می کند. من در مورد این ویژگی ها به کاربران، در درجه اول توسعه دهندگان نرم افزار، می گویم. Ansible Tower به شما این توانایی را می دهد که بگویید: "نه، شما به پوسته دسترسی ندارید، اما من به شما این امکان را می دهم که تمام فرآیندهای Tower را اجرا کنید و در صورت نیاز سرویس را دوباره راه اندازی کنید." در مورد محیط کار و تجهیزاتی که استفاده می کنیم به شما خواهم گفت.
این یک شبکه محلی فدرال است، 7 سایت فیزیکی متصل از طریق MPLS ابری، 140 سرور RHEL که 99 درصد آنها مجازی (vSphere)، سخت افزار SuperMicro، ذخیره سازی شبکه NexentaStore، مجموعه ای از سوئیچ های Cisco، Arista و Cumulus و مدیریت تهدید یکپارچه Fortinet UTM است. ابزارهای موجود در هر سایت
شبکه فدرال به این معنی است که من باید از تمام اقدامات امنیتی اطلاعاتی که توسط قانون ارائه شده است استفاده کنم. باید در نظر داشته باشید که Puppet Enterprise از اکثر سخت افزارهایی که ما استفاده می کنیم پشتیبانی نمی کند. ما مجبوریم از سخت افزار بودجه استفاده کنیم زیرا دستگاه های دولتی در تامین مالی این اقلام هزینه ای مشکل دارند. به همین دلیل است که ما سخت افزار SuperMicro را می خریم و تجهیزات خود را از قطعات جداگانه که نگهداری از آنها توسط قراردادهای دولتی تضمین شده است، مونتاژ می کنیم. ما از لینوکس استفاده می کنیم و این یکی از دلایل مهم تغییر به Ansible است.
سابقه ما با Puppet به شرح زیر است.
در سال 2007، ما یک شبکه کوچک از 20-25 گره داشتیم که Puppet را در آن مستقر کردیم. اساسا، این گره ها فقط "جعبه" RedHat بودند. در سال 2010، ما شروع به استفاده از رابط وب داشبورد عروسکی برای 45 گره کردیم. با ادامه گسترش شبکه، در سال 2014 به PE 3.3 رفتیم و با بازنویسی مانیفست برای 75 گره، یک انتقال کامل انجام دادیم. این باید انجام می شد زیرا Puppet دوست دارد قوانین بازی را تغییر دهد و در این مورد آنها زبان را کاملاً تغییر دادند. یک سال بعد، وقتی پشتیبانی از نسخه 3 Puppet Enterprise به پایان رسید، مجبور شدیم به PE 2015.2 مهاجرت کنیم. ما مجبور شدیم مانیفست را دوباره برای سرورهای جدید بازنویسی کنیم و مجوزی با ذخیره 100 گره بخریم، اگرچه در آن زمان فقط 85 نود داشتیم.
فقط 2 سال گذشته است و ما دوباره مجبور شدیم کارهای زیادی برای مهاجرت به نسخه جدید PE 2016.4 انجام دهیم. ما مجوزی برای 300 گره خریداری کردیم که فقط 130 گره داشت. دوباره مجبور شدیم تغییرات عمده ای در مانیفست ایجاد کنیم زیرا نسخه جدید زبان دارای نحو متفاوتی با زبان نسخه 2015 بود. در نتیجه، SCM ما از کنترل نسخه SVN به Bitbucket (Git) تغییر کرد. این "رابطه" ما با پاپت بود.
بنابراین، باید به مدیریت توضیح می‌دادم که چرا باید با استفاده از آرگومان‌های زیر به یک SCM متفاوت برویم. اولین مورد قیمت بالای خدمات است. من با بچه ها در RedHat صحبت کردم و آنها گفتند که هزینه اجرای یک شبکه 300 گره با Ansible Tower نصف هزینه Puppet Enterprise است. اگر Ansible Engine را نیز خریداری کنید، هزینه تقریباً یکسان خواهد بود، اما ویژگی های بسیار بیشتری نسبت به PE دریافت خواهید کرد. از آنجایی که ما یک شرکت دولتی هستیم که از بودجه فدرال تامین مالی می شود، این یک استدلال بسیار قوی است.
استدلال دوم تطبیق پذیری است. Puppet فقط از سخت افزارهایی پشتیبانی می کند که دارای Puppet agent هستند. یعنی روی همه سوییچ ها باید یک Agent نصب شود و آخرین نسخه باشد. و اگر برخی از سوئیچ های شما از یک نسخه و برخی دیگر از نسخه دیگر پشتیبانی می کنند، باید نسخه جدیدی از عامل PE را روی آنها نصب کنید تا همه آنها بتوانند در یک سیستم SCM کار کنند.
سیستم Ansible Tower متفاوت عمل می کند زیرا هیچ عاملی ندارد، اما دارای ماژول هایی است که از سوئیچ های Cisco و همه سوئیچ های دیگر پشتیبانی می کند. این SCM از Qubes OS، Linux و 4.NET UTM پشتیبانی می کند. Ansible Tower همچنین از کنترلرهای ذخیره سازی شبکه NexentaStore مبتنی بر هسته Illumos، یک سیستم عامل منبع باز مبتنی بر یونیکس، پشتیبانی می کند. این پشتیبانی بسیار کمی است، اما Ansible Tower به هر حال آن را انجام می دهد.
بحث سوم که هم برای من و هم برای مدیریت ما بسیار مهم است، سهولت استفاده است. من 10 سال را صرف تسلط بر ماژول های Puppet و کد مانیفست کردم، اما Ansible را در عرض یک هفته یاد گرفتم زیرا کار با این SCM بسیار آسان تر است. اگر فایل های اجرایی را اجرا می کنید، البته، مگر اینکه این کار را غیرضروری انجام دهید، کنترل کننده های هوشمند و پاسخگو با آنها کار می کنند. راهنماهای مبتنی بر YAML به راحتی قابل یادگیری و استفاده سریع هستند. کسانی که قبلاً هرگز نام YAML را نشنیده اند می توانند به سادگی اسکریپت ها را بخوانند و به راحتی بفهمند که چگونه کار می کند.
صادقانه بگویم، Puppet کار شما را به عنوان یک توسعه دهنده بسیار دشوارتر می کند زیرا مبتنی بر استفاده از Puppet Master است. این تنها ماشینی است که مجاز به برقراری ارتباط با عوامل عروسکی است. اگر تغییراتی در مانیفست ایجاد کرده اید و می خواهید کد خود را آزمایش کنید، باید کد Puppet Master را بازنویسی کنید، یعنی فایل Puppet Master /etc/hosts را برای اتصال همه کلاینت ها و راه اندازی سرویس Puppet Server پیکربندی کنید. تنها پس از این می توانید عملکرد تجهیزات شبکه را روی یک میزبان آزمایش کنید. این یک روش نسبتا دردناک است.
همه چیز در Ansible بسیار ساده تر است. تنها کاری که باید انجام دهید این است که کدی را برای ماشینی ایجاد کنید که بتواند از طریق SSH با میزبان تحت آزمایش ارتباط برقرار کند. کار با این خیلی راحت تر است.
مزیت بزرگ بعدی Ansible Tower توانایی استفاده از سیستم پشتیبانی موجود و حفظ پیکربندی سخت افزاری موجود است. این SCM از تمام اطلاعات موجود در مورد زیرساخت و سخت افزار، ماشین های مجازی، سرورها و غیره بدون هیچ مرحله اضافی استفاده می کند. در صورت داشتن سرور RH Satellite می تواند با سرورهای RH Satellite شما صحبت کند و به شما ادغام هایی می دهد که هرگز با Puppet نخواهید داشت.
نکته مهم دیگر کنترل دقیق است. می دانید که Puppet یک سیستم ماژولار است، یک برنامه کاربردی سرویس گیرنده-سرور است، بنابراین باید جنبه های موجود همه ماشین های خود را در یک مانیفست طولانی تعریف کنید. در این مورد، وضعیت هر یک از عناصر سیستم باید هر نیم ساعت آزمایش شود - این دوره پیش فرض است. عروسک اینگونه کار می کند.
برج شما را از آن نجات می دهد. شما می توانید فرآیندهای مختلفی را روی تجهیزات مختلف بدون محدودیت اجرا کنید؛ می توانید کارهای اساسی را انجام دهید، فرآیندهای مهم دیگر را اجرا کنید، یک سیستم امنیتی راه اندازی کنید و با پایگاه های داده کار کنید. شما می توانید هر کاری را که در Puppet Enterprise دشوار است انجام دهید. بنابراین، اگر آن را روی یک هاست پیکربندی کرده باشید، اعمال تغییرات بر روی هاست های باقی مانده زمان می برد. در Ansible همه تغییرات به طور همزمان اعمال می شوند.
در نهایت، بیایید به ماژول امنیتی نگاه کنیم. برج Ansible آن را به طرز شگفت انگیزی با دقت و دقت زیاد پیاده سازی می کند. می‌توانید به کاربران اجازه دسترسی به خدمات خاص یا میزبان‌های خاص بدهید. من این کار را با کارمندانم که عادت به کار بر روی ویندوز دارند، انجام می‌دهم و دسترسی آنها به پوسته لینوکس را محدود می‌کنم. من اطمینان می‌دهم که آنها به برج دسترسی دارند تا فقط بتوانند کار را انجام دهند و فقط خدماتی را که به آنها مربوط است اجرا کنند.
بیایید به کارهایی که باید زودتر انجام دهید تا انتقال خود به برج Ansible را آسان‌تر کنید، بررسی کنیم. اول از همه، شما باید تجهیزات خود را آماده کنید. اگر برخی از عناصر زیرساخت شما قبلاً در پایگاه داده نیستند، باید آنها را در آنجا اضافه کنید. سیستم هایی وجود دارند که ویژگی های خود را تغییر نمی دهند و بنابراین در پایگاه داده Puppet نیستند، اما اگر قبل از انتقال به Tower آنها را به آنجا اضافه نکنید، تعدادی از مزیت ها را از دست خواهید داد. این ممکن است یک پایگاه داده اولیه "کثیف" باشد، اما باید حاوی اطلاعاتی در مورد تمام تجهیزاتی باشد که دارید. بنابراین، شما باید یک اسکریپت سخت افزاری پویا بنویسید که به طور خودکار تمام تغییرات زیرساخت را به پایگاه داده فشار دهد، سپس Ansible می داند که کدام هاست ها باید در سیستم جدید حضور داشته باشند. لازم نیست به این SCM بگویید کدام هاست ها را اضافه کرده اید و کدام هاست ها دیگر وجود ندارند، زیرا همه این ها را به طور خودکار می داند. هر چه داده ها در پایگاه داده بیشتر باشد، Ansible مفیدتر و انعطاف پذیرتر خواهد بود. طوری کار می کند که گویی به سادگی بارکد وضعیت سخت افزار را از پایگاه داده می خواند.
مدتی را صرف آشنایی با خط فرمان در Ansible کنید. برخی از دستورات سفارشی را برای تست اسکریپت سخت افزاری، نوشتن و اجرای چند اسکریپت ساده اما مفید playbook اجرا کنید، در صورت لزوم از الگوهای Jinja2 استفاده کنید. سعی کنید یک نقش و اسکریپت برای یک فرآیند پیچیده و چند مرحله ای با استفاده از یک پیکربندی سخت افزاری رایج و معمولی بنویسید. با این چیزها بازی کنید، تست کنید که چگونه کار می کند. به این ترتیب نحوه استفاده از ابزارهای ایجاد کتابخانه مورد استفاده در Tower را یاد خواهید گرفت. قبلاً گفته ام که حدود 3 ماه طول کشید تا برای انتقال آماده شوم. من فکر می کنم که بر اساس تجربه من، شما می توانید این کار را سریعتر انجام دهید. این زمان را هدر ندهید، زیرا بعداً تمام مزایای کار انجام شده را تجربه خواهید کرد.
در مرحله بعد، باید تصمیم بگیرید که از Ansible Tower چه انتظاری دارید، این سیستم دقیقاً چه کاری باید برای شما انجام دهد.
آیا شما نیاز به استقرار سیستم بر روی سخت افزار خالی، بر روی ماشین های مجازی خالی دارید؟ یا می خواهید شرایط عملیاتی و تنظیمات اولیه تجهیزات موجود را حفظ کنید؟ این یک جنبه بسیار مهم برای شرکت‌های عمومی است، بنابراین باید مطمئن باشید که می‌توانید Ansible را بر روی پیکربندی موجود خود مهاجرت و استقرار دهید. فرآیندهای اداری معمولی را که می خواهید خودکار کنید، شناسایی کنید. دریابید که آیا نیاز به استقرار برنامه‌ها و خدمات خاصی در سیستم جدید دارید یا خیر. فهرستی از کارهایی که می خواهید انجام دهید تهیه کنید و آن ها را اولویت بندی کنید.
سپس شروع به نوشتن کد اسکریپت و نقش هایی کنید که کارهایی را که قصد دارید تکمیل کنید را قادر می سازد. آنها را در پروژه ها، مجموعه ای منطقی از کتاب های بازی مرتبط، ترکیب کنید. بسته به اینکه از کدام مدیر کد استفاده می کنید، هر پروژه به یک مخزن Git جداگانه یا یک مخزن متفاوت تعلق دارد. می‌توانید با قرار دادن دستی آنها در Project Base Path در سرور Tower، اسکریپت‌های playbook و فهرست‌های راهنما را مدیریت کنید، یا با قرار دادن playbook در هر سیستم مدیریت کد منبع (SCM) پشتیبانی شده توسط Tower، از جمله Git، Subversion، Mercurial و Red Hat، مدیریت کنید. بینش ها در یک پروژه می توانید هر تعداد اسکریپت را که می خواهید قرار دهید. به عنوان مثال، من یک پروژه اساسی ایجاد کردم که در آن یک اسکریپت برای عناصر اصلی RedHat، یک اسکریپت برای هسته لینوکس و اسکریپت هایی برای بقیه خطوط پایه قرار دادم. بنابراین، در یک پروژه، نقش‌ها و سناریوهای مختلفی وجود داشت که از یک مخزن Git مدیریت می‌شدند.
اجرای همه این موارد از طریق خط فرمان راه خوبی برای آزمایش عملکرد آنها است. این شما را برای نصب برج آماده می کند.
بیایید کمی در مورد رمزگذاری مانیفست عروسکی صحبت کنیم، زیرا من زمان زیادی را صرف این کار کردم تا اینکه متوجه شدم واقعاً چه کاری باید انجام شود.
همانطور که قبلاً گفتم، Puppet تمام تنظیمات و گزینه های سخت افزاری را در یک مانیفست طولانی ذخیره می کند و این مانیفست هر کاری را که این SCM باید انجام دهد را ذخیره می کند. هنگام انتقال، نیازی نیست همه وظایف خود را در یک لیست جمع کنید؛ در عوض، به ساختار سیستم جدید فکر کنید: نقش‌ها، اسکریپت‌ها، برچسب‌ها، گروه‌ها و مواردی که باید در آنجا قرار گیرند. برخی از عناصر شبکه مستقل باید در گروه هایی دسته بندی شوند که می توان برای آنها اسکریپت ایجاد کرد. عناصر زیرساخت پیچیده‌تر که شامل تعداد زیادی منابع، از جمله کلاس‌های مستقل هستند، می‌توانند در نقش‌ها ترکیب شوند. قبل از مهاجرت، باید در این مورد تصمیم بگیرید. اگر نقش‌ها یا سناریوهای بزرگی را ایجاد می‌کنید که در یک صفحه قرار نمی‌گیرند، باید از برچسب‌ها استفاده کنید تا بتوانید بخش‌های خاصی از زیرساخت را ثبت کنید.
18:00
چند تبلیغ 🙂
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).
Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید
منبع: www.habr.com