میگوئل والدز فائورا، مدیرعامل و یکی از بنیان‌گذاران شرکت Bonitasoft می‌گوید: «به‌کارگیری الگوی تحویل مستمر (Continuous Delivery) و استفاده از فناوری‌های مرتبط با کانتینرها (همچون داکر و کوبرنتیس) در سازمان‌های بزرگ، به‌طور فزاینده‌ای افزایش استفاده از میکروسرویس‌ها و زیرساخت‌های چند-ابری را به همراه خواهد داشت. سازمان‌هایی که استراتژی راهبردی آن‌ها بر پایه زیرساخت‌های تغییرناپذیر و فناوری‌هایی برای مدیریت سرویس‌ها و گسترش نرم‌افزارهای متمرکز است از توسعه مستمر کاملا خودکار استقبال خواهند کرد و در نتیجه زنجیره کامل یکپارچگی پیوسته (Continuous Integration)، تحویل مستمر
ا (Continuous Delivery) و گسترش پیوسته مبتنی بر اتوپایلوت (Continuous Deployment On Autopilot) را کنار خواهند گذاشت. در نتیجه سال 2019 میلادی شاهد گسترش بهتر و دقیق‌تر رویکردهای مبتنی بر تحویل پیوسته خواهیم بود.»
مارک کرفی، مدیر استراتژی شرکت CA Veracode می‌گوید: «تقریبا 30 درصد رخنه‌های شناسایی‌شده در ارتباط با آسیب‌پذیری‌هایی هستند که در لایه کاربردی قرار دارد. به همین دلیل، سازمان‌ها و شرکت‌ها از فرایند توسعه نرم‌افزار پخته‌تر و امن‌تر استفاده خواهند کرد. یکی از بهترین راه‌ها برای ایمن کردن کامل برنامه‌های کاربردی توجه به مقوله امنیت از همان ابتدای چرخه حیات توسعه نرم‌افزار است. اما این کار تنها از طریق همکاری نزدیک تیم‌های امنیت و توسعه امکان‌پذیر خواهد بود. دواپس نقش بسیار مهمی را در یکپارچه‌سازی امنیتی ایفا می‌کند. توجه به مباحث امنیتی از همان ابتدای چرخه توسعه نرم‌افزار باعث می‌شود تا تیم‌های توسعه بتوانند کدهای ایمن را در کوتاه‌ترین زمان ارائه کنند، به دلیل این‌که دواپس آن‌ها را ملزم می‌کند تا آزمایش کدها را به شکل مستمر انجام دهند. این رویکرد درست نقطه مقابل الگویی است که بسیاری از تیم‌ها بر مبنای آن عمل می‌کنند و یک نرم‌افزار را در مراحل پایانی تولید به لحاظ مباحث امنیتی آزمایش می‌کنند. مزیت دیگر این رویکرد صرفه‌جویی در زمان شناسایی و برطرف کردن رخنه‌ها است.»
تیم اوسترمن، سرپرست ارشد راهکارهای بازاریابی شرکت BMC Software می‌گوید: «متخصصان دواپس ثابت کرده‌اند، در دنیای امروز که دگرگونی‌های دیجیتالی کسب‌وکار با سرعت زیادی رخ می‌دهد، نقش کلیدی و حساسی را می‌توانند ایفا ‌کنند. اما بخش تولید، ناحیه‌ای است که تیم‌های دواپس همچنان در آن با مشکل روبه‌رو هستند، چرا؟ زیرا بخش تولید هنوز بیش از اندازه دستی و سنتی است و برای حل این مشکل بخش تولید باید یک تغییر جدی پیدا کند. به همین دلیل معتقدم، سال 2019 میلادی شاهد شکل‌گیری مفهومی به نام «شغل‌ها به‌عنوان کد» (Jobs-As-Code) خواهیم بود. مفهومی که به یکی از جریان‌های اصلی چرخه عمر تحویل نرم‌افزار در حوزه فرانت‌اند افزوده خواهد شد. استفاده از این رویکرد ساده و قدرتمند در خودکارسازی کدنویسی در کنار منطق کسب‌وکار، زیرساخت با کد و سپس اجرای آن‌ها در طول زنجیره CI/CD به تیم‌های دواپس کمک می‌کند تا سرعت فاز تولید را افزایش دهند. علاوه براین، سال 2019 شاهد ‌خواهیم بود که رهبری بازار در زمینه ارائه ابزارهایی در این حوزه به چند شرکت اصلی محدود خواهد شد که دلیل آن بسیار ساده است: تیم‌های دواپس انتخاب را دوست دارند و با توجه به پیشرفت و بلوغ ابزارها، آن‌ها متوجه می‌شوند هر ابزاری مفید نبوده و ابزارهایی را جست‌وجو خواهند کرد که بالاترین قابلیت را با انعطاف‌پذیری کامل در اختیارشان قرار دهند. در نتیجه، شرکت‌های فعال در این زمینه سود قابل‌توجهی به دست خواهند آورد.»
بِرَد میکلی، مدیر ارشد واحد Developer Business شرکت Rad Hat می‌گوید: «بدون شک، متخصصان آینده دواپس تفاوت‌های زیادی با همتایان خود در گذشته خواهند داشت. کانتینرها به مولفه‌ای کلیدی در اجرای برنامه‌ها تبدیل می‌شوند. در کنار کانتینرها، ما با مقوله دیگری به نام Serverless Function که معنای تحت‌اللفظی آن تابع به‌عنوان سرویس است، سروکار خواهیم داشت. مقوله‌ای که در تعامل با میکروسرویس‌ها، یک معماری کاربردی انعطاف‌پذیر و قدرتمند را به وجود خواهند آورد. تغییراتی که در این مدت رخ می‌دهد باعث می‌شود تا تغییر در ابزارهای DevOps و جریان‌های کاری اجتناب‌ناپذیر شود. توسعه‌دهندگان دیگر به نصب ابزارها یا نوشتن کد در ماشین‌های محلی تمایلی نخواهند داشت. در نتیجه، محیط‌های توسعه یکپارچه مبتنی بر وب که از طریق SaaS عرضه می‌شوند، به‌پیش‌فرض جدید تبدیل می‌شوند.»

سایمون گالبریث، مدیرعامل شرکت Redgate Software می‌گوید: «گزارش سال جاری موسسه DORA با عنوان Accelerate State of DevOps نشان داد که توسعه بانک‌های اطلاعاتی برای اولین‌بار به یک مفهوم فنی کلیدی تبدیل شده که قادر است کارایی دواپس را به میزان قابل‌توجهی افزایش دهد. این گزارش نشان می‌دهد، تیم‌هایی که تحویل مداوم را به‌خوبی انجام می‌دهند، به‌خوبی می‌توانند از ابزارهای کنترل نسخه به‌منظور رصد و کنترل کردن تغییرات اعمال‌شده روی پایگاه داده و مدیریت آن استفاده کنند. درست به همان شکلی که ما از ابزارهای کنترل نسخه در ارتباط با تغییراتی که روی نرم‌افزارهای کاربردی به وجود می‌آید، استفاده می‌کنیم. علاوه بر این، یکپارچه‌سازی توسعه پایگاه داده در تعامل با تحویل نرم‌افزار باعث افزایش کارایی و عملکرد می‌شود؛ به دلیل این‌که اعمال تغییرات روی بانک‌ اطلاعاتی سرعت فرایندها را کاهش نداده و در زمان استقرار(نصب نرم‌افزارها) باعث بروز مشکلات مختلف نمی‌شود. علاوه بر این، به میزان قابل‌توجهی، مشکلات مربوط به نشتی اطلاعات و نقص‌های داده‌ای را کاهش می‌دهد. خوشبختانه، رویکرد به کار گرفته‌شده از سوی تیم‌های دواپس در ارتباط با دنبال کردن تغییرات می‌تواند به‌محافظت از اطلاعات قابل‌شناسایی شخصی در سرتاسر فرایند توسعه پایگاه داده کمک کند.»
جواهر مالهوترا، مدیر ارشد مهندسی شرکت HackerRank می‌گوید: «دنیای CI/CD توسط کانتینرها و فناوری‌هایی که برای مدیریت کانتینرها به کار گرفته می‌شوند، به‌لرزش درآمده است. در سال 2019، سیستم‌های مدیریت پیکربندی مانند Chef ، Puppet و Ansible به‌طور عمده توسط ابزارهایی همچون Docker ، Kubernetes و Helm Charts جایگزین می‌شوند. ابزار Docker فواید بسیاری برای اپلیکیشن‌ها به همراه خواهد داشت، درحالی‌که Kubernetes برای مدیریت بهتر و دقیق‌تر کانتینرهای بزرگ ضروری خواهد بود. اگر این کار به‌درستی انجام شود، ابزار مدیریت کانتینرها می‌تواند پیچیدگی کار با زیرساخت‌ها را ساده‌سازی کند. مهندسان DevOps باید خودشان را با این زنجیره ابزارهای جدید تطبیق دهند.»
دیو اسمیت، قائم مقام مهندسی شرکت DigitalOcean می‌گوید: «در سال جاری شاهد به‌کارگیری Kubernetes توسط شرکت‌ها در اندازه‌های مختلف بودیم که از کانتینرها برای اجرای اپلیکیشن‌های بومی ابری استفاده کردند. اما در سال 2019 شاهد آغاز جایگزینی بسیاری از ابزارهای رایج در حوزه دواپس خواهیم بود. این مسئله یک تغییر و دگرگونی اساسی در دنیای DevOps به وجود می‌آورد. با توجه به این‌که صنعت به‌سوی چارچوب‌های استاندارد شده برای مدیریت نرم‌افزار پیش می‌رود، میزان کار مورد نیاز برای پیکربندی و برپایی چارچوب‌های نرم‌افزاری به سمت کمینه شدن متمایل خواهد شد و در نتیجه DevOpsهای حرفه‌ای زمان بیشتری برای تمرکز روی نوآوری‌های کارآمد خواهند داشت و درعین‌حال با نیروی بیشتری بر چالش مدیریت کلاسترهای کاربردی بزرگ و پیچیده متمرکز خواهند شد.»
#devops @unixmens

ا DevOps (دِواپس) ترکیبی از دو کلمه توسعه (Development) و عملیات (Operation) است. کار تیم توسعه مشخص است؛ مجموعه مهندسان سعی دارند قابلیت‌های محصول را افزایش دهند. در مقابل تیم عملیات سعی در ثابت نگه‌داشتن وضعیت سرویس‌ها دارد. برای درک بهتر این دو تیم از یکدیگر مفهوم دواپس به وجود آمد که طی فرایند تولید نرم‌افزار تاکید زیادی بر همکاری این دو تیم می‌شود. دواپس به ما می‌آموزد که ویژگی‌های عملیاتی، اهمیت بالایی دارد و باید مانند دیگر خصوصیات موردتوجه قرار گیرد. بهترین راه برای اطمینان از این اتفاق، تقویت یک فرهنگ قوی همکاری بین تیم‌های توسعه و عملیات است. البته چگونگی دستیابی به این همکاری یک سوال دیگر است و مدل‌های دواپس کاملا متفاوت هستند. مثلا آمازون رویکرد «شما آن را ساختید، آن را اجرا می‌کنید» را در پیش گرفته و در برخی تیم‌های گوگل رویکرد «دواپس به‌عنوان یک پلتفرم» مطرح می‌شود.
در چند سال گذشته تفکر چابک و دواپس در کنار هم زندگی کرده‌اند و بحث‌های زیادی در مورد رابطه بین این دو وجود دارد. بعضی افراد دواپس را به‌عنوان یک زیرمجموعه از چابک می‌بینند و بعضی دیگر آن را به‌عنوان مجموعه‌ای از شیوه‌های خودکارسازی در نظر می‌گیرند. این‌ها همه به تعریف شما از دواپس بستگی دارد. اما صرف‌نظر از دیدگاه‌ها، هدف نرم‌افزار کاری این است که بتواند مدیریت، نگهداری، مقیاس‌پذیری، پشتیبانی و به‌روزرسانی را با سهولت انجام دهد و این چیزی است که جهان نرم‌افزار به‌شدت به آن نیاز دارد.
راه‌هایی که نرم‌افزار از طریق آن اجرا می‌شود نسبت به‌روزهایی که تفکر چابک تازه اختراع‌شده بود، تغییرات زیادی داشته است. اسکرام در سال 1993 شروع به کار کرد، کتاب XP در سال 1999 و DSDM (روش توسعه سامانه‌های پویا) در سال 1994 منتشر شد. اجرا، نگهداری و عملیات مواردی نبودند که توسعه‌دهندگان نرم‌افزار در هر شرایطی درگیر آن باشند. اما تغییرات بزرگی اتفاق افتاد و در حال حاضر توسعه‌دهندگان به‌طور فعال در عملیات و پشتیبانی از سیستم‌های خود مشارکت دارند. اکنون ما به دنبال چهارچوبی هستیم که این تغییرات را در نحوه کار ما ایجاد کند. ترکیب دواپس و تفکر چابک می‌تواند باعث این کار شود.
ضد الگوها در دوآپس

تمرکز اصلی دواپس این است که با کاهش فاصله بین تیم توسعه و عملیات، قابلیت‌هایی مانند توسعه‌پذیری، مقیاس‌پذیری، نظارت و پشتیبانی ساده‌تر انجام شود. بااین‌اوصاف می‌بینیم که الگوهای نادرستی در حال ظهور هستند که شکاف بین این دو تیم را افزایش می‌دهند. از دیدگاه عملی مشکل این است که اطلاعات بسیار کمی در مورد چگونگی ترکیب توسعه چابک با این روش جدید دواپس وجود دارد. چه شیوه‌ای را باید اتخاذ کنیم و از کدام شیوه‌ها باید جلوگیری کنیم؟ چگونه می‌توانیم شروع کنیم؟ چه نقش‌هایی باید در تیم داشته باشیم؟ این سوالات عمدتا بدون پاسخ هستند.
در این الگوهای نادرست، تمام مراحل متدولوژی چابک و بسیاری از عملیات‌های دواپس اتفاق می‌افتد و باید گفت که عملیات هنوز هم پس از تفکر زیاد و بررسی‌ها انجام می‌شود، اما نتیجه قابل‌قبول نیست. راه‌حل این است که عملیات‌های دواپس از همان ابتدای کار به‌خوبی اجرا شوند و برخی اصلاحات در چهارچوب‌های چابک ما ایجاد شود.
به‌روز‌رسانی شیوه‌های چابک

چگونه می‌توانیم اطمینان حاصل کنیم درحال‌توسعه نرم‌افزار به شیوه چابک هستیم، درحالی‌که ارائه و نگهداری از محصولات و خدمات مطابق با آخرین و بزرگ‌ترین بخش‌های دواپس باشد؟ پاسخ آسان است. با اضافه کردن
وظایف/داستان‌های عملیاتی به داستان‌های کاربری برای رسیدن به موفقیت. البته برای رسیدن به این هدف به نظر ساده باید به چند نکته مهم توجه داشت: کسانی که روی این وظایف یا داستان‌ها کار می‌کنند، بهترین تمرینات دواپس، مدیریت مالک و نوشتن داستان عملی.
تیم‌ها: بیشتر تیم‌های چابک که با آن‌ها کار می‌کنیم شامل عملیات، پشتیبانی یا متخصصان زیرساخت نیستند. ممکن است بگویید کهدر هر تیم چابک تقاضای کافی برای وجود چنین تخصص‌هایی وجود ندارد و شاید هم درست باشد اما فراموش نکنید که این صحبت دقیقا در مورد تست‌کننده‌ها، معماران و مهندسان پایگاه داده، UX و ... نیز گفته می‌شد. اگر ارائه، پشتیبانی، به‌روزرسانی، مقیاس‌پذیری و نگهداری محصول برای شما مهم است، پس به این مهارت‌ها در تیم خود نیاز دارید.
پشتیبانی: اگر تیم‌هایی داریم که در حال کار روی محصولات هستند، پس باید تیمی هم برای پشتیبانی داشته باشیم و دیدگاه سنتی را فراموش کنیم و به رویکردهای تازه رو آوریم که با آغوش باز جنبه‌های عملیاتی را می‌پذیرد. شاید بهترین واژه برای روشن شدن مفهوم، واژه «خدمات» باشد. خدمات محصولاتی هستند که باید به کار گرفته شوند و بعد از ارائه محصول برای پشتیبانی ارائه می‌شوند. وقتی از پشتیبانی صحبت می‌کنیم باید بتوانیم پاسخ‌گوی موارد زیر باشیم:
• مقیاس‌پذیری محصول یا سرویس (در داخل یا خارج؟ و چه زمانی؟)
• قابلیت گسترش (آیا این مورد بدون این‌که وقفه‌ای در کار سیستم ایجاد کند، انجام‌شده است؟)
• نظارت بر سرویس (چه جنبه‌هایی به نظارت نیاز دارند؟ چگونه با هر تغییری نحوه نظارت کردن را به‌روزرسانی کنیم؟)
• ورود به سیستم (چه اطلاعاتی باید وارد شود؟ چرا؟ و این کار به چه روشی انجام شود؟)
• هشدار (چه کسی؟ چه وقتی؟ چطور؟)
• تست‌پذیر بودن خدمات
• جنبه‌های امنیتی مانند مدل‌های رمزنگاری، حفاظت از داده‌ها، قوانین داده‌ها و ... .
• عملکرد عملیاتی.

محبوب‌ترین چهارچوب تفکر چابک، یعنی اسکرام برای زمانی طراحی شد که تیم‌ها نگران مشکلات عملیاتی نبودند. به‌طورکلی، تفکرات چابک زمانی استفاده می‌شوند که ممکن است تمرکز کمتری روی جنبه‌های عملیاتی صورت گیرد. در این بین می‌توان از دواپس کمک گرفت. حداکثر ارزش تفکر چابک و دواپس زمانی به دست می‌آید که برخی از اصول دواپس در همان ابتدای توسعه، پیاده‌سازی شوند. دواپس باید در همان لحظه‌ای که اعضای تیم انتخاب می‌شوند، مد نظر قرار گیرد. البته باید در نظر گرفت بسیاری از تیم‌ها توانسته‌اند تمرینات چابک را با دوآپس هم‌تراز کنند اما نمی‌توان برای همه از همان روش‌ها استفاده کرد. تنها چیزی که وجود دارد مجموعه‌ای از الگوهای مناسب است.

داستان‌های کاربری (User Stories)

داستان‌های کاربری، راهی عالی برای به دست آوردن نیازمندی‌های محصولات هستند. در این راه، توسعه‌دهنده خود را به‌جای کاربر نهایی قرار می‌دهد و از دید او به مشکلات نگاه می‌کند. به این ترتیب، به‌جای پیروی ساده از دستورالعمل‌ها تمرکز خود را بر راه‌حل مشکلات واقعی قرار می‌دهد. داستان‌های کاربری به‌جای توجه به «چگونه» به روی «چه چیز» تمرکز می‌کند. فرمت داستان‌های کاربری طوری است که معمولا با عبارت‌های «من می‌خواهم...»، «به این دلیل که...»، «برای این‌که...» و مانند آن آغاز می‌شوند.
برنامه‌ریزی برای سرعت بیشتر در اجرای کار
اگر بخواهید به کار سرعت بیشتری بدهید باید برای آن برنامه‌ریزی کنید. برای رسیدن به یک دیدگاه دواپس باید کارهای زیر انجام شود:
• دعوت از افراد پشتیبان، زیرساخت و عملیاتی برای جلسه‌های برنامه‌ریزی
• صحبت در مورد ویژگی‌های عملیاتی، علاوه بر ویژگی‌های فنی محصول
• تعیین یک روند منطقی و قابل دسترس
• توجه به زمان و تلاشی که صرف وقفه‌ها می‌شود (برای مثال، رفع اشکالات برنامه‌نویسی).
تعریف اتمام کار

یک کار با گذراندن برخی آزمایش‌ها و ایجاد استانداردها به اتمام نمی‌رسد. زمانی می‌گوییم یک کار به پایان رسیده که مقیاس‌پذیری، امنیت، کارایی و توسعه‌پذیری انجام‌شده باشد. درصورتی‌که تمامی این موارد انجام نشده باشد، تمام‌شده تلقی نمی‌شود.
مالکیت محصول

در محیطی که دواپس و چابک با یکدیگر ترکیب شده‌اند، مالک محصول باید اهمیت عملیات را به‌خوبی درک کند. در محیط‌های بدون سرور، SaaS و PaaS ارزش‌های نهفته زیادی وجود دارد. این ارزش‌ها نشان‌دهنده نحوه کار سرویس، صرفه‌جویی در زمان، صرفه‌جویی در پول، افزایش بهره‌وری، کاهش ریسک و قابلیت اتکای بیشتر هستند. مالک محصول باید این موارد را بداند.

و اما openshift :

کمپانی Red Hat پس از به‌دست آوردن CoreOS در اوایل امسال، در کنفرانس Red Hat Summit 2018 خود برخی از نقاط تاریک استراتژی کانتینر خود را روشن ساخت. در طی چند ماه آینده، توزیع Kubernetesی که توسط CoreOS ساخته شده است یعنی Tectonic، با توزیع Kubernetesی که لینوکس Red Hat در محیط (OpenShift (PaaS خود گنجانده است، تلفیق خواهد شد. علاوه‌براین، نرم‌افزار Operators که توسط CoreOS و برای تسهیل مدیریت کلاسترهای Kubernetes ایجاد شده است نیز به OpenShift راه پیدا خواهد کرد. همچنین Red Hat PaaS برروی Container Linux که یک نسخه‌ی سبک‌وزن توزیع لینوکسی توسعه یافته شده توسط CoreOS میباشد نیز منتشر خواهد شد. Red Hat اعلام کرد که توزیع Atomic لینوکس که ساخته‌ی همین کمپانی است نیز با Container Linux تلفیق خواهد شد.

ا Red Hat به ارائه‌ی راهنمای کاملی درخصوص ادغام دو نمونه‌ی Kubernetes تا پایان سال متعهد شده است که پشتیبانی ممتد از Quay Container Registry که توسط CoreOS ایجاد شده را نیز شامل می‌شود. تمام کاربران کنونی Tectonic به مرور به کاربران OpenShift مبدل خواهند شد. همچنین Red Hat اذعان داشت که نسخه‌ی Containerizeشده‌ای از سرور برنامه‌ی کاربردی Red Hat Fuse که پبیشتر با نام JBoss شناخته می‌شد، به‌زودی برای OpenShift دردسترس خواهد بود.

تفاوت‌های #OpenShift و #Kubernetes

مفهوم Kubernetes

در CoreOS، در واقع Kubernetes را هسته‌ی سیستم‌های توزیع شده در نظر گرفته می‌شود. یک برنامه‌ی زمانبندی کارها که به خوبی طراحی شده باشد، در چندین ماشین کار کند و قادر به هماهنگی وضعیت کارهای مدیریت شده نیز باشد، همانند تاثیری که هسته‌‌ی لینوکس برای بار کاری برنامه ریزی شده بر روی یک Host دارد، به طور طبیعی همکاری را افزایش می‌دهد. با همین منطق، RedHat می‌دانست که تمایزی که کاربران میان محصولات قائل می‌شوند، بر اساس اهمیت‌شان خواهد بود.

این همان هسته‌ی لینوکس است که در بسیاری از گوشی‌ها، لپ تاپ‌ها، سرورها و حتی Raspberry Pi اجرا می‌شود، و تفاوتشان در وجود Patchهای گوناگونی است که برای پشتیبانی از سخت افزارهایی که هسته به طور مستقیم بر روی آن‌ها استقرار دارد، منتشر می‌شوند. این مدل نیز به همان ترتیب است. به طوری که Kubernetes در توزیع‌های مختلف Kubernetes مشابه است، با این تفاوت که برای پشتیبانی از لایه‌ای که Kubernetes بر روی آن مستقر است، Patchهای مختلفی وجود دارند.
بررسی OpenShift

تیم OpenShift مفتخر است که توزیعی از Kubernetes را با هدف بهبود تجربه توسعه دهندگان نسل بعدی برنامه‌های کاربردی بومی ‌Cloud تولید کرده است. تیم Tectonic (توزیع CoreOS از Kubernetes) بر روی تجربه مدیران و تیم‌های عملیاتی که نیاز داشتند به سرعت به مسائل مربوط به سیستم عامل و Kubernetes رسیدگی کنند، متمرکز بود. با انتشار نسخه‌ی OpenShift 4.0 که به زودی عرضه خواهد شد، برای هر دو نوع مخاطب، رابط‌های کاربری ارائه خواهد شد تا به نیازهای خاص هر دو پاسخ داده شود.

با این که همه می‌توانند لینوکس را از ابتدا با انتخاب هر قطعه و جمع آوری آن‌ها را به روش دلخواه خود بسازند، بیشتر کاربران این کار را نمی‌کنند. سطح جداسازی‌ای که اغلب کاربران انتخاب می‌کنند بدین معنی است که آن‌ها از مدیریت و یا حتی دانش در مورد تفاوت بین Util-Linux نسخه 2.31 و 2.33 بهره‌ی زیادی نمی‌برند. اگر بخواهیم یک قدم جلوتر برویم، باید گفت که کاربران به حداقل سطح عملکرد و پس از آن به لیست ویژگی‌های ارائه شده اهمیت می‌دهند. حداقل سطح عملکرد به عنوان مثال دانستن این است که کدام دستورات و یا APIها پس از کدام نسخه در دسترس هستند.

این بسیار شبیه OpenShift است. Kubernetes با ابزارهای اضافی مهم و تقاضا شده توسط کاربران تجهیز شده است. همانند CoreOS و CentOS که شامل مجموعه‌هایی مختلف از ابزارها هستند که به نیازهای کاربران مختلف پاسخ می‌دهند، توزیع‌های Kubernetes نیز به این صورت می‌باشند. در Red Hat تمرکز بر روی در دسترس قرار دادن ابزارهایی که به توسعه دهندگان و تیم‌های عملیاتی کمک می‌کند است. به عنوان مثال به همین دلیل است که تکنولوژی Istio به صورت پیش نمایش در OpenShift گنجانده شده است. Istio ابزاری است که بسیاری از کاربران ممکن است به آن تکیه کنند و بنابراین باید در توزیع پایه قرار گیرد.
ا OKD در مقابل Red Hat OpenShift

آیا OpenShift نرم افزاری متن باز است؟ بله! تمام اجزای موجود در OpenShift درون جامعه متن باز توسعه داده شده و می‌توان آن‌ها در GitHub مشاهده کرد. در GitHub می‌توانید تعداد زیادی Repository پیدا کنید که پاسخگوی بسیاری از نگرانی‌ها در مورد فعال نگه داشتن Clusterهای Kubernetas می‌باشند. اجزای نرم افزاری مورد نیاز برای اجرای Kubernetes درون یک پروژه بسته بندی می‌گردند. این پروژه‌ی توزیع Kubernetas که قبلا Origin خطاب می‌شد، OKDنام دارد. به این ترتیب، Kubernetes و OKD از این نظر شبیه یکدیگر هستند که هر دوی آن‌ها پروژه‌های متن باز می‌باشند و Kubernetes یکی از پروژه‌های رده‌بالاتر (Upstream (OKD است. همانطور که هسته‌ی لینوکس، GNU Bash، GCC و سرور httpd Apache، رده‌بالاهای توزیع لینوکس Fedora می‌باشند. هنگامی‌که قرار است به بهبود یا افزودن ویژگی‌ها در OpenShift پرداخته شود، در صورتی که این کار در Kubernetes روی دهد، کار در رده‌های بالاتر انجام می‌گردد و در زمان ایجاد OpenShift با استفاده از نسخه‌های Kubernetes کار انجام می‌شود.

سپس Red Hat پروژه OKD را همراه با تعدادی از پروژه‌های دیگر مانند Maistra، اپراتورهای مختلف و دیگر منابع درون محصول Red Hat OpenShift Container Platform بسته بندی می‌کند. پس از اینکه آماده‌سازی انتشار Kubernetes به پایان می‌رسد، کار بسته بندی OKD و سپس OpenShift آغاز می‌شود.

ا Red Hat OpenShift بر همه‌ی این جوانب استوار است و تحت آزمایشات داخلی گسترده قرار می‌گیرد تا اطمینان حاصل گردد که تمام اجزا یکپارچه، و تیم‌ها آماده هستند تا از نیازهای مشتریانی که نرم افزار در دست تولید را اجرا می‌نمایند، پشتیبانی کنند. این توانمندسازی داخلی یکی از دلایل وجود فاصله بین انتشار رده‌های بالاتر و انتشار متعاقب نسخه‌ی آماده برای استفاده شرکتی OpenShift می‌باشد. مشتریان شرکت Red Hat می‌خواهند بر روی شانه‌های تخصص این شرکت بایستند، و می‌دانند که آن‌ها می‌توانند به صورت End to End از اجزایی که با OpenShift ارائه می‌دهند پشتیبانی نمایند.

همانطور که می‌توان لینوکس را از ابتدا ساخت، می‌توان به روش سخت‌تر پیش از نصب Kubernets بهینه‌سازی را انجام داد، اما بهتر است این کار را به افرادی با زمان، صبر و درجه ریسکی که نیازی به پشتیبانی سازمانی نخواهند داشت، واگذار نمود. برای کسانی که بر روی کارکردهای خود تمرکز دارند و می‌خواهند بر روی شانه‌های Red Hat بایستاند، انتخاب Red Hat OpenShift Platform توصیه می‌شود.

نیم نگاهی به OpenShift
در دنیای امروز با رشد سریع اطلاعات و بزرگ شدن داده ها در سازمان ها مدیران سیستم نیز نیاز به بروز کردن دائم دانش خود همگام با بستر های اطلاعاتی دارند. در این میان رشد ابزار های مدیریت سیستم ها نحوه ی مدیریت بستر ها و هماهنگی آن ها را با رشد و توسعه ی تجارت در سازمان ها هماهنگ می گردد تا توانایی پاسخ گویی حجم عظیم درخواست ها در کوتاهترین مدت زمان ممکن را دارا باشد. فارغ از بستر های زیرساختی چون cloud‌ می توان به ابزار هایی چون Chef، Puppet،‌ Ansible و Saltstack در حوزه ی مدیریت حجم عظیم ماشین ها و یا Vagrant برای مدیریت ماشین های مجازی یا Containerهایی مانند Docker اشاره کرد که با حضور خود دنیای فناوری اطلاعات را برای مدیران سیستم جذاب تر نموده اند. حال به معرفی یکی از نرم افزار هایی که می تواند موجب خودکار شدن و سرعت بخشیدن به فرآیند های مدیریتی سیستم ها می شود می پردازیم این نرم افزار در واقع سرویس PaaS را برروی بسترهای مجازی می تواند ارائه کند.

مدیران فناوری اطلاعات و OpenShift
مدیریت فناوری اطلاعات یک سازمان یکی از جذاب ترین و در عین حال سخت ترین شغل های دنیای تجارت امروز می باشد. مدیران فن‌آوری اطلاعات با نگاهی به اطراف خود حجم فناوری هایی که آن‌ها را احاطه کرده است می بینند و می بایست بر این اساس سازمان خود را در مسیر پیشرفت قرار دهند. هر بخش از فناوری اطلاعات توسط یک شرکت طراحی، تولید، توسعه و پشتیبانی می شود، بنابراین مدیران فناوری اطلاعات تنها مسول مدیریت فناوری های تولیدی سازمان خود نیستند. با توجه به سرعت و شدت تغییرات در دنیای فناوری اطلاعات مدیران فناوری اطلاعات به شدت تحت فشار برای تعیین خط مشی و یافتن راه برای هماهنگی با این سرعت رشد قرار می گیرند. حال به شرح چگونگی راحت تر شدن این مسیر با استفاده از OpenShift خواهیم پرداخت. سامانه های نرم افزاری گسترده مانند OpenShift بسیار پر اهمیت هستند زیرا این نرم افزار با درک بازار، کسب و کار های معمول را گسترش داده است. با این راه کار جدید نرم افزارها یا ارائه ی راحت تر خدمات مشتریانی که از خدمات سنتی استفاده می نمایند به خدمات مناسب تر و قابل دسترس تر دست خواهند یافت. حقیقت این است که این نرم افزار تعیین می کنند که یک شرکت چگونه فرصت های جدید در کسب و کار را پیدا کرده و خدمات ارزشمندتری به مشتریان خود ارائه نماید.

این تفکر که «کسب و کار یک شرکت فناوری نیست پس این موارد در شرکت من هیچ تاثیری نخواهد داشت» حقیقتا اشتباه است.
شرکت هایی مانند Amazon، Uber، Netflix و غیره به ما نشان داده اند که صنایع معمول مانند خرده فروشی، حمل‌و‌نقل و رسانه می توانند به یک شرکت جدید و چابکتر تبدیل شوند. یک نکته ی دیگر که می تواند مسیر ما را روشن کند اتفاقی است که برای شرکت Kodak می توانست اتفاق بی افتد اگر شرکتی بود که Instagram‌ را ابداع کرده بود. آن ها می توانستد از ورشکستگی خود جلوگیری کنند اگر برروی رسانه های اجتماعی تمرکز می کردند می توانستند جایگاه تجاری خود را حفظ کنند. همه ی این موارد تنها با تصمیم گیری صحیح و قرار دادن نرم افزار در مدل تجاری هر سازمان می تواند رخ دهد. در هر حال ساختن ایده ی جدید کار آسانی نیست و مدیران هنگامی که بیشتر زمان خود را درگیر اختصاص منابع محدود سازمان و یافتن راهی برای بهبود ROI/ROA نظارت بر پیاده سازی فناوری ها نمایند چگونه باید نوآوری کنند؟

جواب این سوال بسیار ساده است.

در واقع OpenShift‌ به توسعه ی نرم افزار ها با در برگرفتن ابزار هایی در شرکت ها که نیاز به چابکی و کارایی دارند کمک می‌کند. با OpenShift سازمان شما می تواند به سرعت نرم افزار ها را پیاده سازی، کمتر ذخیره کند و تعاملی تر بوده و میزان همکاری ها را افزایش دهد. و در دنیای رقابتی امروز شما با سرعت بیشتری می توانید از ایده ها به تولیدات برسید. در ادامه بررسی بیشتر مزایایی این نرم افزار و توانمندی ها و نقش آن در بهبود بستر فناوری اطلاعات می پردازیم.

دانلود کتاب devops with openshift #openshift #devops #redhat #linux #container @unixmens

پیاده سازی مفهوم DevOps با OpenShift :

برای بسیاری از سازمان ها، بخش بزرگی از درخواست DevOps، اتوماسیون نرم افزاری است که با استفاده از تکنیک های زیرساختی قابل پیاذه سازی است این کتاب ارائه دهنده ها، معماران، و مهندسین مابقی را با یک گزینه عملی تر ارائه می دهد. شما خواهید آموخت که چگونه یک رویکرد کانتینر از OpenShift می تواند به تیم شما کمک کند تا از طریق نمایه خدمات خود از زیرساخت IT به نرم افزارهای با کیفیت برسید .
🌈🌈🌈سه کارشناس OpenShift در Red Hat توضیح می دهند که چگونه نرم افزار Docker و مدیر خوشه ای Kubernetas را با ابزار توسعه و عملیاتی OpenShift پیکربندی کنید. کشف این که چگونه این پلتفرم مدیریت ظرفیت زیرساختی-اگنوستیک میتواند به شرکتها کمک کند تا به ناحیه تاریک که در آن زیرساختها به عنوان کد پایان مییابد و برنامه های کاربردی از آن شروع شود کمک کند.
در این کتاب می خوانید :
دیدگاه برنامه کاربردی برای اتوماسیون را بدست آورید و درک کنید که چرا مهم است
پیاده سازی خطوط یکپارچه پیوسته با قابلیت Jenkins OpenShift
کاوش مکانیزم برای جداسازی و مدیریت پیکربندی از نرم افزار زمان اجرا استاتیک
یاد بگیرید چگونه با استفاده از قابلیت Open-Shift سفارشی کنید
و ...

درباره نویسندگان
استفانو پیکززینی

استفانو پیکززینی پلت فرم Red Hat را به عنوان یک راه حل سرویس (PaaS) در سراسر استرالیا و نیوزلند هدایت می کند. او متخصص در پلت فرم کانتینر OpenShift Red Hat است.
مایک هپبورن

مایک هپبورن، متخصص موضوع ANZ PaaS در Red Hat، زمینه ای در معماری نرم افزار و ادغام و عملیات میان افزار دارد.
نوئل اوکانر

نوئل اوکانر مشاور و معمار اصلی در Red Hat است. او دارای تجربه گسترده ای در پیشبرد و ارائه پروژه های کلیدی مشتری برای مشتریان Red Hat در سراسر اروپا و مناطق آسیا اقیانوس آرام است.
https://www.dropbox.com/s/sy3iaoh65qke54c/Devops_With_Openshift.pdf?dl=0
#openshift #container #linux #devops @unixmens

کتاب Docker for Sysadmins Linux Windows VMware Technet24 #docker #linux @unixmens

This is a book about Docker, hand-crafted for system administrators. No prior
knowledge required!
But what about developers and DevOps?
If you’re a developer with no interest in operations then this book is not for you. If
you’re into DevOps then I think you’ll get a lot form the book.
To keep things short... the book is not about showing you how to develop microser-
vice apps with Docker. The book is about how the core Docker plumbing works.
You’ll learn the how and the why - the commands and the deep-dives. I really want
to set you on your way to being as good at Docker as you already are at Linux,
Windows or VMware.
Why should I read this book or care about
Docker?
Docker is coming and there’s no hiding from it. Developers are all over it. In IT Ops,
we need to get ready to support Dockerized apps in our business critical production
environments.
Isn’t Docker just for developers?
Hell no!!!
All of those Dockerized apps that developers are creating need a solid Docker
infrastructure to run on. And that’s where IT Ops comes into the picture... IT
Ops will be asked to build and run high performance and highly available Docker
infrastructures to support business applications. If we’re not skilled-up on Docker,
we’re going to struggle.

کتاب docker cookbook #docker #linux #container @unixmens

و اما lxc :

داکر یا در اصطلاح اصلی آن Docker ، یک پلت فرم متن باز برای ساخت ، ارسال و اجرای هر اپلیکیشنی بدون وابستگی به مکان می باشد . شامل ۴ مولفه اصلی است : موتور داکر ( قابلیت حمل دارد بازمان اجرای خیلی کم) ، یک هاب داکر ،ابزارهای بسته بندی و یک سرویس ابری برای به اشتراک گذاشتن اپلیکیشن ها و خودکار سازی جریان کار . داکر اپلیکیشن ها را قادر می سازد به سرعت از اجزایشان اسمبل شوند و اصطکاک مابین توسعه ، QA و محیط تولید را حذف کند .

کاربرد اصلی داکر برای توسعه دهندگان و ادمین سیستم ها است . چرا؟

برای توسعه دهندگان ، با داکر توسعه دهنده می تواند هراپلیکیشنی با هر زبانی بسازد . اپلیکیشن های Dockerized قابل حمل اند و هر جایی می توانند اجرا شوند در دیتا سنترها ، لپ تاپ ها و اوبونتو سرورهای ابری .