docs

DOCS INDEX

نوامبر 13, 2019مارس 31, 2020

مصاحبه چارلز اندرسون با جیمز ترنبل درباره داکر – Docker

مصاحبه چارلز اندرسون با جیمز ترنبل درباره Docker

در این مصاحبه که در تابستان 2014 ضبط شده و در ابتدای سال 2015 منتشر شده است چارلز اندرسون با جیمز ترنبل ، در مورد Docker صحبت می‌کند. Docker یا داکر ابزاری است که با وجود عمر کوتاه خود، خصوصاً در محیط‌های استقرار مستمر و در معماری‌های مبتنی بر ریزسرویس‌ها، توجه زیادی به خود جلب کرده است. جیمز ترنبل یک نویسنده مستقل نرم‌افزار‌های متن‌باز، متخصص امنیت و توسعه‌دهنده نرم‌افزار است. او نایب‌رییس شرکت Docker است. او نقش‌های مشابهی در PuppetLabs و Venmo داشته است. همچنین کتاب‌هایی در مورد Docker ، Puppet ، Logstash ، مدیریت سیستم‌های لینوکس و امنیت نوشته است.

منبع: www.se-radio.net

ترجمه: www.se-topics.ir

جیمز، به SE Radio خوش آمدید.

ممنون، خوشحالم که اینجا هستم.

خیلی سطح بالا و بصورت خلاصه، داکر یا Docker چیست؟

داکر یک تکنولوژی مجازی‌سازی محفظه (Container Virtualization) است. مانند یک ماشین مجازی خیلی سبک است.

علاوه بر ساختن محفظه‌ها ما چیزی که آن را جریان کاری توسعه‌دهنده (Developer Workflow) می‌نامیم را نیز فراهم می‌کنیم که در واقع درباره کمک کردن به افراد برای ساختن محفظه‌ها و تولید برنامه‌ها داخل محفظه‌ها و بعد، به اشتراک گذاشتن آنها در بین هم‌تیمی‌هایشان است.

بسیار خوب، چه مسأله‌ای را حل می‌کند؟

چند مسأله را بطور خاص می‌توانیم مطرح کنیم.

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

مشکل دومی که می‌خواهیم به آن نگاهی بیاندازیم این است که ما متوجه این مسئله شده‌ایم که برای اغلب افراد، مهمترین دارایی IT، همان کدهایی است که توسعه می‌دهند و این کد بر روی ایستگاه‌های کاری (Workstation) توسعه‌دهنده‌ها یا لپتاپ‌هایشان یا محیط DevOps قرار گرفته است اما این کدها تا زمانی که به دست مشتری نرسد برای شرکت، هیچ ارزشی تولید نکرده است. و رویه‌ای که به دست مشتری برسد یک جریان کاری شامل توسعه، تست، قرارگرفتن در سکو و استقرار در محیط عملیاتی است که یکی از پراصطکاک‌ترین کارها در IT است. به عنوان مثال کل جریان DevOps از این حقیقت و مشکل کلاسیک در بسیاری از سازمان‌های معظم IT نشأت گرفت که توسعه‌دهنده‌ها برنامه‌ها را توسعه می‌دادند و به تیم عملیات می‌دادند اما آنها متوجه می‌شدند که آن برنامه‌ها در محیط عملیاتی اجرا نمی‌شوند. همان مشکل کلاسیک که بر روی ماشین من اجرا می‌شود اما تیم عملیات با آن مشکل دارد!

بنابراین ما قصد داریم که یک تکنولوژی سبک محاسباتی بسازیم که کمک کند افراد کدها و برنامه‌هایشان را داخل منابع محاسباتی‌شان (Computing Resource) قرار داده و مجموع آنها قابل انتقال به گروه تست و عملیات باشند و همه‌اش در محیط عملیاتی قابل نمونه‌سازی باشد با این فرض که آنچه می‌سازید و اجرایش می‌کنید و تستش می‌کنید همان چیزی است که در محیط عملیاتی اجرا خواهید کرد.

بسیار خوب، ما بعداً برخی جزییات را مطرح می‌کنیم اما اکنون بگویید که چه موارد کاربرد خوب یا مرسومی برای یک توسعه‌دهنده یا مدیرسیستم برای استفاده از Docker وجود دارد؟

چندین مورد کاربرد واقعاً جدی دارد. مورد اول، کاربرد در دنیای یکپارچه‌سازی مستمر (Continuous Integration) و استقرار مستمر (Continuous Deployment) است. Docker خیلی سبک است که به این معناست که توسعه‌دهنده‌های زیادی داریم که پشته‌هایی از محفظه‌های Docker را بر روی لپ‌تاپ‌هایشان ایجاد می‌کنند و کپی‌هایی از محیط عملیاتی می‌سازند مثلاً LAMP Stack و محیط‌های چندلایه‌ای [را می‌سازند]. آنها می‌توانند برنامه‌شان را بر روی این پشته (Stack) تولید و اجرا کنند که به این معناست که خیالشان کاملاً راحت است که آنچه اجرا می‌کنند مانند محیط عملیاتی است و بعد تست‌‌ها را اجرا می‌کنند و تست پذیرش مشابه با محیط عملیاتی خواهد بود. از آنجاییکه بعداً می‌توانید این محفظه‌ها را جابجا کنید و قابل انتقال هستند، بعداً می‌توانید در محیط‌های استقرار مستمر، خیلی سریع‌تر کار کنید. مثلاً فرض کنیم که یک محیط استقرار مستمرِ Jenkins دارید، در این حالت به ماشین‌های مجازی متکی بوده و مجبوریم که ماشین‌های مجازی را بسازیم و همه نرم‌افزارها را نصب کرده و برنامه و کدها را نصب کرده و بعد تست‌ها را اجرا کنیم و بعد دوباره همه‌ی آن‌ها را پاک‌سازی کنید چرا که ممکن است فرآیند تست، وضعیت VM را خراب کرده باشد و مجبور شویم این چرخه را تکرار کنیم. شاید در این فرآیند CI (مخفف Continuous Integration)، ساختن این ماشین‌های مجازی 10 دقیقه طول بکشد اما درعوض، در دنیای Docker این ماشین‌های مجازی یا اصطلاحاً محفظه‌ها را در چندثانیه می‌سازید که به این معناست که فرآیند تولید و تست شما، 10 دقیقه کوتاه می‌شود که یک صرفه‌جویی شگفت‌انگیز در هزینه است. شما به سرعت، تعدادی محفظه می‌سازید و بعد تست‌هایتان را اجرا می‌کنید و براساس نتایج تست ممکن است به انجام تغییراتی و تکرار فرآیند تست نیاز داشته باشید.

مورد دیگر، چیزی است که ما به نوعی آن را ظرفیت بالا می‌نامیم؛ ماشین‌های مجازی سنتی، Hypervisor دارند. Hypervisor، ده تا پانزده درصد ظرفیت (ماشینِ) میزبان را می‌گیرد. خیلی از مشتری‌ها هستند که برایشان ده تا پانزده درصد خیلی پرهزینه است و تصمیم می‌گیرند آن را کنار گذاشته و با یک میزبان Docker جایگزینش کنند تا بتوانند محفظه‌های خیلی بیشتری اجرا کنند و مقیاس بالایی از محفظه‌ها را بر روی یک میزبان راه بیاندارند. بعلت فقدان Hypervisor و اینکه محفظه‌ها مستقیماً بر روی سیستم‌عامل قرار می‌گیرند، خیلی خیلی سریع هستند. سال گذشته تحقیقاتی انجام شد که نشان داد در سیستم‌های مبتنی بر تراکنش، بطور متوسط محفظه‌ها، 25% سریع‌تر از یک ماشین مجازی عمل می‌کنند که کاملاً شگفت‌انگیز است.

——————————————————————————————

بله، شگفت‌انگیز است. Docker توسعه را سریع‌تر (به قول شما چابک‌تر) می‌کند و وقتی به مرحله عملیات برسد، تأثیرش بیشتر هم خواهد شد.

بله.

بسیار خوب. بیایید کمی در این مورد عمیق‌تر شویم که Docker کارهایش را چگونه انجام می‌دهد.

Docker مبتنی بر محفظه‌ است. محفظه‌ها، محیط‌های ایزوله برای کدهای مُد کاربر (User Mode) فراهم می‌کنند. برخی از شنوندگان ما احتمالاً با سیستم‌های محفظه‌ای قدیمی‌تر از قبیل Solaris Zones و یا FreeBSD Jails یا حتی اگر عقب‌تر برویم از نسخه 7 یونیکس به بعد با فراخوانی سیستمی chroot ، آشنا هستند. کدی که در یک محفظه اجرا می‌شود، فایل‌سیستم ایزوله خود را دارد و تنها می‌تواند پروسس‌های در همان محفظه را ببیند.

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

یکی از تکنولوژی‌های دیگر که Docker به آن متکی است، مفهومی است که ما به آن کپی کردن به هنگام نوشتن (Copy on Write) می‌گوییم. فایل‌سیستم‌های متعددی هستند که این قابلیت را فراهم می‌کنند. Btrfs ، AUFS و نگاشت‌گرهای Device، عملکردی دارند که تدارکات سبک (Thin Provisioning) نامیده می‌شود، ویژگی مشترک همه آنها نوعی از مدل کپی کردن به هنگام نوشتن است. همان چیزی که توسعه‌دهنده‌های کرنل به آن فایل‌سیستم مجتمع (Union File System) می‌گویند. آنچه رخ می‌دهد این است که لایه‌هایی از فایل‌سیستم را می‌سازید. هر محفظه Docker بر روی چیزی که ما آن را تصویر (Image) می‌نامیم ساخته می‌شود. تصویرهای Docker همانند فایل‌سیستم‌های از پیش‌ساخته هستند. آنها شامل لایه نازکی از کتابخانه‌ها و فایل‌های اجرایی هستند که برای به کار انداختن برنامه مورد نیاز است. احتمالاً هر برنامه‌ای، نیاز به تعدادی پکیج‌های پشتیبان دارد مثلاً ممکن است LAMP Stack را نیاز داشته باشد یا سرور Apache یا … . این تصویر، بر روی اصطلاحاً لایه خودش (لایه فایل‌سیستم) ذخیره می‌شود. اگر بخواهیم تغییری بر روی این تصویر ایجاد کنیم مثلاً پکیج دیگری را نصب کنیم فرضاً سیستم را بوت کرده و بخواهیم PHP را نصب کنیم و فرمان apt-get install php را بزنیم، آنچه Docker انجام می‌دهد این است که یک لایه بر روی لایه موجود می‌سازد و فقط چیزهایی که تغییر کرده‌اند را در آن اضافه می‌کند یعنی در اینجا فقط همین پکیج را اضافه می‌کند.

این تولید لایه به لایه به این معنی است که به یک فایل‌سیستم فقط خواندنی (Read Only) می‌رسیم که شامل لایه‌های مختلفی است. می‌توانید آنها را مانند کامیت‌های Git (یا هر ابزار کنترل کد دیگر) در نظر بگیرید. در نتیجه، به یک سیستم خیلی سبک می‌رسیم که تنها، چیزهایی که می‌خواهیم بر روی آن قرار دارد و وقتی به عنوان مثال می‌خواهیم آنها را دوباره بسازیم، Docker می‌فهمد که من از قبل PHP را نصب کرده‌ام و قرار نیست تغییری بر روی این محیط ایجاد کنم و قرار نیست چیزی بنویسم و فقط می‌خواهم چیزهای موجود در لایه PHP را استفاده کنم. بعنوان مثال اگر تغییری در سورس‌کدهای خود بدهید، برخلاف کاری که برای ماشین مجازی می‌کردید که یک ماشین مجازی می‌ساختید، در اینجا Docker تغییراتی که قرار است در سورس‌کدها انجام شود را به تصویر (Image) می‌افزاید که شاید مثلاً تنها 10 کیلوبایت باشد، بنابراین Docker فقط همان چیزهایی که قرار است تغییر کند را درفایل‌سیستم می‌نویسد. در نتیجه خیلی سبک است و واقعاً خیلی سریع ساخته می‌شود و با کش کردن، دوباره‌سازی آن نیز فوق‌العاده سریع خواهد بود.

بسیار خوب، لایه‌ها کمی مانند تصاویر مقطعی (Snapshot) در ماشین‌های مجازی هستند.

بله، خیلی مشابه آنها هستند با این تفاوت که بخاطر ماهیت فقط خواندنی خود، احتمالاً منعطف‌تر از آنها هستند، اگر شما یک تصویر مقطعی را دوباره بکار بگیرید تضمینی وجود ندارد که در همان وضعیت اجرایی (Running State) قرار بگیرد؛ کتابخانه‌ها و فایل‌های اجرایی در آنها فقط وضعیت‌های داخل حافظه نیستند بلکه [بر روی] فایل‌سیستم هستند. اما یکی از فایل‌سیستم‌هایی که ما استفاده می‌کنیم، نگاشت‌گر Device است، ما از قابلیت تدارکات سبک (Thin Provisioning) استفاده می‌کنیم که بصورت منطقی یک ابزار برای گرفتن تصاویر مقطعی را طراحی می‌کند.

بسیار خوب، من همینطور اشاره کردم که پروسس‌های داخل یک محفظه فقط می‌توانند پروسس‌های داخل همان محفظه را ببینند. توضیح دهید این چطور کار می‌کند؟

Docker به شدت متکی به دو مورد از تکنولوژی‌های کرنل لینوکس است. اولی، فضای نام (Namespace) خوانده می‌شود. فرض کنید شما پروسس جدیدی در کرنل لینوکس اجرا می‌کنید. در اینصورت شما یک فراخوانی سیستمی به فضای نام پروسس‌ها می‌کنید که می‌خواهید یک پروسس جدید بسازید، همینطور اگر بخواهید یک واسط شبکه جدید بسازید یک فراخوانی به فضای نام شبکه می‌کنید و کرنل فضای نام خودتان را تخصیص می‌دهد که پروسس و همه منابع دیگری که خواسته‌اید مثلاً دسترسی به شبکه، دسترسی به بخش‌هایی ازفایل‌سیستم و دسترسی به حافظه یا CPU را در خود دارد.

وقتی ما یک محفظه Docker می‌سازیم، تعدادی فراخوانی به کرنل لینوکس داریم که بدینوسیله از آن می‌خواهیم که یک جعبه (Box) برایمان بسازد و می‌خواهیم که آن جعبه دسترسی به فایل سیستم مشخصی، دسترسی به حافظه و CPU، دسترسی به شبکه را داشته باشد و بایست داخل فضای نام همین پروسس باشد. شما کاملاً درست گفتید، در داخل این فضای نام نمی‌توانید هیچ فضای نام پروسسی که خارج از آن قرار گرفته را مشاهده کنید.

تکنولوژی دیگری که بکار گرفته‌ایم گروه‌های کنترلی یا CGroup ها هستند. گروه‌های کنترلی به عنوان مثال به شما این امکان را می‌دهد که بگویید فلان محفظه ، فقط 120 مگابایت از RAM را داشته باشد یا فلان محفظه دسترسی به شبکه نداشته باشد. شما می‌توانید بر اساس نیاز این قابلیت‌‌ها را اضافه و حذف کنید. این خیلی قدررتمند است از این جهت که می‌توانید کنترل دقیقی بر روی محفظه‌ها به همان طریقی که در واسط VMware دارید، داشته باشید که بگویید فلان کارت شبکه را بگیر، فلان هسته CPU را بگیر، فلان حافظه و دسترسی به فلان فایل‌سیستم مربوط به CD_ROM مجازی را داشته باش و … . سطح یکسانی از تکنولوژی را دارد.

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

بله، آنچه رخ می‌دهد به این صورت است که هر شبکه، واسط شبکه خود را دارد که یک واسط مجازی شبکه است. شما می‌توانید داخل هر محفظه پروسس‌هایی را اجرا کنید که به پورت‌های داخل آن محفظه دسترسی داشته باشند. به عنوان مثال می‌توانم 10 محفظه Apache داشته باشم که داخل هرکدام یک سرویس بر روی پورت 80 اجرا شده باشد، همینطور می‌توانم این پورت‌ها را به خارج از محفظه عرضه کنم. اگر بخواهم می‌توانم پورت 80 (داخل محفظه) را روی پورت 80 (خارج از محفظه) عرضه کنم که می‌توانم یک بار (برای یکی از آنها) این کار را بکنم اما به صورت پیش‌فرض، کاری که Docker انجام می‌دهد این است که یک پورت تصادفی با شماره بالا را انتخاب می‌کند مثلاً پورت 80 داخل محفظه را روی پورت 49154 سیستم میزبان عرضه می‌کند. بنابراین پروسس‌های Apache ام بر روی پورت‌های مختلف اجرا خواهند شد و بعد می‌توانم یک ابزار کشف سرویس (Service Discovery Tool) یا یک تعدیل‌کننده بار (Load Balancer) یا نوعی پروکسی را جلوی آن قرار دهم. HAProxy خیلی متداول است، برخی‌ها هم از nginx استفاده می‌کنند. برخی ابزارهای کشف سرویس از قبیل ZooKeeper و Etcd و Consul نیز استفاده می‌شود.

این قابلیت را می‌دهد که بتوانید بگویید من می‌خواهم فلان برنامه (جهت یافتن سرویس مورد نظر خود) از آن برنامه خاص کشف سرویس پرس و جو کند و اینکه مثلاً پروسس Apache به آن 10 محفظه تعلق داشته باشد و بتوانید یکی از آن 10 پورت را برای اتصال به پروسس Apache انتخاب کنید. بنابراین یک مدل کاملاً منعطف و مقیاس‌پذیری وجود دارد که برای اجرای برنامه‌های پیچیده طراحی شده است.

بسیار خوب، Docker همینطور امکان برقرار کردن اتصال بین محفظه‌ها را هم فرآورده می‌کند. برای مثال می‌توانم یک سرور Apache داشته باشم و یک سرور برنامه‌های جاوا (Java Application Server) داشته باشم و بین آنها اتصال برقرار کنم. درست است؟

درست است. چون که Docker بصورت پیش‌فرض، بسته است زیرا ما فکر می‌کنیم امن‌ترین راهش این است که شما کسی باشید که تصمیم بگیرید کدام پورت‌ها به معرض گذاشته شوند. بعنوان مثال انواع مختلفی از محفظه‌ها مثلاً محفظه‌های پایگاه داده و محفظه‌های سرور‌های برنامه (Application Server) هستند که هیچگاه نباید در معرض مشتری قرار بگیرند و تنها باید در معرض محفظه‌هایی قرار بگیرند که منابعشان را مصرف می‌کنند.

به عنوان مثال می‌توانم یک محفظه پایگاه داده را اجرا کرده و به آن یک اسم بدهم مثلاً می‌توانم آن را پایگاه داده MySQL شماره 1 بنامم و بعد می‌توانم یک محفظه وب هم راه بیاندازم، در این حالت کاری که باید بکنید این است که (از محفظه وب) به آن (محفظه پایگاه داده MySQL شماره 1) لینک بزنید که به این معنی است که بر روی یک پورت خاص، یک تونل رمزگذاری شده بین محفظه وب و محفظه پایگاه داده مقصد ایجاد کنید و اطلاعاتی در داخل محفظه خود فراهم کنید به این ترتیب که تعدادی مدخل‌های میزبان DNS و تعدادی متغیرهای محیطی (Environment Variable) در محفظه مورد نظر ایجاد می‌شود تا برنامه از آنها استفاده کرده و بفهمد که پایگاه داده کجا قرار گرفته است. بنابراین آدرس IP که ممکن است آن را ندانید را هاردکد نخواهید کرد و بعد از آن، آنچه رخ می‌دهد این است که اکنون محفظه پایگاه داده و محفظه وب با هم اتصال دارند. فقط آنها می‌توانند با هم صحبت کنند، شما نمی‌توانید پایگاه داده را پینگ کنید یا جستجویش کنید مگر آنکه همان محفظه‌ای باشید که روی پورت خاص با آن صحبت می‌کنید.

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

بله، این قطعاً راحت‌تر و کمی سطح بالاتر از سوار شدن بر روی یک IP و پورت خاص است.

Docker به دنیا به شکل معماری خیلی سرویس‌گرایی می‌نگرد. ما به شدت درگیر دیدگاه SOA یا سرویس‌گرا از دنیا هستیم که بر طبق آن، نباید درباره چیزهایی مانند آدرس IP و پورت نگران باشید، بلکه باید بتوانید سرویس‌ها را خطاب قرار دهید، باید بتوانید بگویید که «من می‌دانم که سرویسی با نام MySQL وجود دارد و این برنامه می‌خواهد از آن استفاده کند. من می‌خواهم که زیرساخت‌ها، به جزییات این کار رسیدگی کنند. من نباید مجبور باشم که به سراغ کسی بروم تا یک قاعده بر روی فایروال برایم ایجاد کند یا یک پورت را برایم باز کند و … . سرویس من باید بتواند با سرویس‌های دیگر صحبت کند و کنترل مطلوب و سطح دسترسی مطلوب را داشته باشد»

بله، کاملاً منطقی است.
بصورت پیش‌فرض، حافظه ذخیره‌سازی محفظه‌ها، موقتی هستند و وقتی محفظه از بین می‌رود حافظه ذخیره‌سازی هم از بین می‌رود. فضاها (Docker Volume) مکانیزمی برای داشتن حافظه ذخیره‌سازی پایا و به اشتراک گذاری بین محفظه‌ها ایجاد می‌کنند. ممکن است در این مورد توضیح دهید.

قبلاً در مورد تصویر محفظه (Container Image) و لایه‌ها (Layers) صحبت کردیم. وقتی یک محفظه را اجرا می‌کنید، یک لایه دیگر بر روی آن می‌سازید که یک لایه با حق دسترسی فقط خواندن است و تا زمانی که کاری برای ذخیره‌سازی این اطلاعات نکنید، ناپایا (Ephemeral) هستند و وقتی از محفظه خارج می‌شوید، از بین می‌روند.

در اینجا ما مفهوم Volume را داریم. آنها خودشان بخشی از فایل‌سیستم هستند. آنها تا حدودی مانند آدرس‌های سوارشده (Mounted) هستند. شما می‌توانید یک محفظه بسازید و بخشی از آن محفظه را بصورت Volume در دسترس قرار دهید. یک مثال کلاسیکش می‌تواند این باشد که یک محفظه Apache اجرا کنید و یک Volume بر روی فلان دایرکتوری‌اش، سوار کنید و داخل آن، سورس کد برنامه‌تان را داشته باشید.

دو نوع Volume می توان ایجاد کرد: یکی اینکه از روی فایل‌سیستم دستگاه میزبان نگاشت را انجام دهید. به عنوان مثال می‌توانید بگویید که در سیستم میزبان به فلان دایرکتوری رفته و آن را بر روی محفظه من نگاشت کن. با این روش می‌توان سورس‌کد را بر روی یک مخزن (Repository) نگاه داشت و محفظه را بر روی آن اجرا نمود. این بدان معناست که وقتی تغییری بر روی کد انجام دهم می‌توانم به محفظه رفته و تغییرات را در آنجا ببینم.

نوع دوم Volume به این روش است که می‌توانید بین محفظه‌ها اشتراک بگذارید. مثالش می‌تواند این باشد که یک محفظه پایگاه داده داشته باشید و دایرکتوری MySQL را بعنوان یک Volume در دسترس قرار دهید و آن زمان، محفظه دیگری را اجرا کنید و آن Volume را برروی آن سوار کنید. به عنوان مثال ممکن است بخواهید نسخه‌برداری (Replication) یا پشتیبان‌گیری (Backup) یا ذخیره لاگ یا کارهای مشابه آن داشته باشید. برای این منظور محفظه MySQL را اجرا کرده و سپس به عنوان مثال یک محفظه پشتیبان‌گیری را اجرا می‌کنم که Volume حاوی دایرکتوری MySQL بر رویش سوار شده است و بنابراین قادر خواهم بود که از داده‌های آن پایگاه داده نسخه پشتیبان گرفته، و جایی داخل محفظه ذخیره کنم.

به این ترتیب قادر خواهید بود که برنامه‌های چندرده‌ای (Multi-tier) و چندسکویی (Multi-stage) داشته باشید. ما خیلی روی این موضوع تمرکز داریم که هر محفظه واقعاً یک کار انجام دهد مثلاً یک محفظه، یک پروسس وب را اجرا کند یا سرور برنامه‌های وب را اجرا کند یا پشتیبان‌گیری کند یا لاگ بزند و … که همان مدل معماری سرویس‌گرای ریزسرویس‌ها است.

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

قطعاً. تصاویر Docker بصورت کلی از چیزهایی که Dockerfile خوانده می‌شوند ساخته می‌شوند. یک Dockerfile ، لیستی از دستورها است که برای تولید تصویر، اجرا می‌شود. هر تصویر Docker از یک تصویر که ما آن را تصویر مبنا (Base Image) می‌نامیم آغاز می‌شود. تصویر مبنا همان چیزی است که من در موردش صحبت کردم و یک پوسته خیلی نازک از فایل‌های کتابخانه‌ای و اجرایی است که چیزی مشابه با یک سیستم‌عامل را می‌سازد. یک تصویر مبنا می‌تواند چیزی مانند Ubuntu باشد. ممکن است بر مبنای نسخه خاص 14.04 از Ubuntu باشد و شامل مینیمم امکانات سیستم‌عامل Ubuntu باشد که برای اجرا و تعامل با کرنل و انجام کارهای ابتدایی لازم است. بعنوان مثال شامل libc و ابزار apt-get برای مدیریت پکیج و ابزارهای مدیریت سیستم از قبیل systemd و چیزهای مشابه آن است. اما شامل چیزهایی از قبیل vim (ابزار ویرایش متن) و X (کتابخانه‌های گرافیکی) و … نیست. تنها شامل حداقل‌های مورد نیاز برای اجرای سیستم‌عامل است. می‌توان آن را یک ساختار حداقلی و لاغر در نظر بگیرید. در مقایسه با ماشین‌های مجازی که چند گیگابایت حجم دارند، اینها غالباً خیلی سبک هستند مثلاً ما یک تصویر مبنای Docker داریم که مبتنی بر یک توزیع BusyBox از لینوکس است که فوق‌العاده کوچک است و حدود 24 مگابایت حجم دارد. تصور کنید که فرضاً بتوانید LAMP Stack را بر روی سیستم‌عاملی که 24 مگابایت حجم دارد اجرا کنید! از لحاظ سرعت و حجم، خیلی شگفت‌انگیز است.

بر روی تصویر مبنا فرضاً بر روی تصویر مبنایی که Ubunto 14.04 باشد، می‌توانم چندین گام ساخت (Build Step) داشته باشم. به عنوان مثال این گام‌ها می‌تواند شامل این باشد که: « Apache را نصب کن» یا می‌تواند این باشد که: «برخی کدهای برنامه یا فایل‌های پیکربندی را داخل تصویر، اضافه کن» و بعد می‌تواند اعمال تنظیماتی از این قبیل باشد که: «دایرکتوری جاری (Working Directory) داخل تصویر را مقداردهی کن یا کاربری که باید برنامه‌ها با آن Run as شوند را تنظیم کن» و بعد احتمالاً مقداری تنظیمات شبکه خواهید داشت مثلاً اینکه: «این تصویر باید پورت شماره 80 را به معرض بگذارد». در نهایت، هنگامیکه می‌خواهیم محفظه را از روی تصویر اجرا کنیم خواهیم گفت که برنامه پیش‌فرضی که باید در محفظه اجرا شود کدام است، در مثال Apache احتمالاً خواهم گفت که اجرای Apache Daemon کار پیش‌فرضی است که باید انجام بدهی!

بنابراین، ابتدا یک دستور با عنوان docker build را اجرا می‌کنیم که یک Dockerfile را می‌گیرد و دستورات داخل آن را اجرا کرده و در انتها، چیزی را به شما می‌دهد که ما به آن تصویر می‌گوییم و تصویر، یک مشخصه (Identifier) دارد که یک رشته بلند شبیه SHA است و در عین حال می‌توانید به آن یک نام هم بدهید. مثلاً می‌توانم اسم آن را jamesturnbull/apache بگذارم. این [روش نامگذاری] کاملاً مشابه با نگرشی است که Git هم دارد که اول نام کاربر مالک می‌آید و بعد نامی که می‌خواهیم به مخزن (Repository) بدهیم که در اینجا apache است.

بعد می‌توانم یک دستور دیگر را اجرا کنم که docker run نامیده می‌شود و تصویر jamesturnbull/apache را برایش مشخص کنم تا وب سرور Apache را از آن تصویر راه‌اندازی کند. و اگر بخواهم تغییری در آن بدهم، آن را متوقف کرده و دوباره docker build را اجرا می‌کنم و از آنجاییکه همه چیز Cache می‌شود، تنها تغییرات مورد نیاز ذخیره می‌شود.

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

بله، یکی از موارد واقعاً جذابی که در موردش صحبت کردم، قابلیت انتقال است. تصاویر Docker را براحتی می‌توان منتقل کرد. ما یک محصول نرم‌افزار به عنوان سرویس (Software as a Service) با عنوان DockerHub داریم که خیلی مشابه با Git Hub است با این تفاوت که برای تصاویر Docker است. یک نسخه اختصاصی آن را هم داریم که آن هم متن باز است و مشابه با Git Hub Enterprise است و پشت فایروال قرار می‌گیرد.

بنابراین یکی از رویه‌های مرسوم می‌تواند این باشد که یک توسعه‌دهنده در تیم یک تصویر برای نرم‌افزارش بسازد و تستش کند، آنگاه برای اینکه آن را با دیگر اعضاء تیم به اشتراک بگذارد با دستور docker push و ذکر نام تصویر مورد نظر آن را به DockerHub بفرستد. DockerHub همانند Git Hub، مخزن‌های خصوصی هم دارد و اگر بخواهید آن را برای همگان به اشتراک نگذارید می‌توانید تیمی از افرادی داشته باشید که به آن مخزن خصوصی دسترسی داشته باشند. آنگاه می‌توانید به دیگر اعضاء تیم بگویید که یک تصویر جدید آماده شده است و اعضاء دیگر تیم، با دستور docker pull همانند کاری که در Git Hub می‌کنند تصویر جدید را بردارند.

از آنجاییکه اینجا نیز از مکانیزم کپی به هنگام نوشتن (Copy on Write) استفاده می‌شود و Cache می‌شود تنها، تغییراتی که برای بروزرسانی تصویر شما به نسخه آخر مورد نیاز است را می‌آورد. مدت زیادی برای بروزرسانی طول نمی‌کشد و حجم زیادی از فضای دیسک شما را نمی‌گیرد. همه اعضاء تیم بر روی یک تصویر یکسان کار می‌کنند که فوق‌العاده است چرا که یکی از مشکلات کلاسیک در محیط‌های توسعه نرم‌افزار این است که وقتی افراد جدید به شرکت می‌پیوندند، باید یک محیط پاک و مناسب تحویل بگیرند اما به علت آشفتگی‌هایی که وجود دارد و تغییراتی که رخ می‌دهد، در نهایت به 4-5 نفر در تیم می‌رسید که هر کدام محیط توسعه متفاوتی دارند! مثلاً وقتی بیل به تیم ملحق شده ما یک نسخه از JVM را داشته‌ایم و او اخیراً نسخه James را بروزرسانی نکرده و وقتی جیم به تیم ملحق شده نسخه JVM متفاوتی را استفاده می‌کرده‌ایم و … . [اما با استفاده از محفظه‌ها] از این مشکلات اجتناب می‌کنید زیرا می‌توانید خیلی سریع و راحت توزیع داشته باشید و لازم نیست که کل یک ماشین مجازی را توزیع کنید یا حتی یک اسکریپت Build را اجرا کنید، یا اینکه حتی تصویر ماشین مجازی را داخل فلش گذاشته و با آن در اتاق‌ها چرخ بزنید، من واقعاً اگر ببینم که هنوز هم کسی چنین کاری را می‌کند شوکه می‌شوم اما این‌ها، واقعاً رخ می‌دهد.

شما قصد مقایسه با Git Hub را داشتید. اگر بگوییم که محفظه‌ها، ماشین‌های مجازی سبک هستند آنگاه DockerHub ، روشی برای به اشتراک گذاشتن، بهبود دادن و استفاده کردن از این ماشین‌های مجازی است همانطور که با Git Hub همین کارها را با سورس‌کدها می‌کنیم.

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

اخیراً من با یک مدیرسیستم صحبت می‌کردم. او می‌گفت: ماه گذشته خیلی متعجب شده است که تیم توسعه‌دهنده‌ها دیگر از او درخواست ماشین مجازی جدید نمی‌کنند. او گفت من نمی‌دانسته‌ام چه شده است، با خود گفتم شاید به سراغ [سرویس‌های ماشین‌ مجازی] آمازون رفته‌اند یا مشکلی برایشان رخ داده است، اما وقتی آنها را دیدم و علت را پرسیدم گفتند: «آیا به خاطر داری که هفته پیش یک ماشین مجازی قوی گرفتیم؟» گفتم: بله، و آنها گفتند که: «ما روی آن Docker را نصب کردیم و برای نرم‌افزارهای مختلف، تعدادی تصویر ساختیم و حالا تنها یک ماشین مجازی داریم و محفظه‌ها را از روی آن تصاویر می‌سازیم و ما واقعاً خوشحالیم. این قطعاً در زمان‌ شما هم صرفه‌جویی می‌کند زیرا دیگر مجبور نیستید که برخی تدارکات را ببینید و تصاویر و ماشین‌های مجازی را برای ما نگهداری و راه‌اندازی کنید» در اینجا مدیر سیستم متوجه شد که دیگر مجبور نیست این کارها را انجام دهد، به جای آن می‌تواند انبوهی از کارها که واقعاً قصد داشته را انجام بدهد، کارهایی که در واقع ارزش‌ بیشتری تولید می‌کنند. تیم توسعه هم دیگر مجبور نبودند که درخواست جدیدی برای دریافت منابع ثبت کنند و یا منتظر [آماده شدن] ماشین‌های مجازی بشوند یا آنها را دوباره بسازند یا اینکه نگران این باشند که آیا ماشین مجازی که تحویل می‌گیرند، مشابه با سیستم محیط عملیاتی هست یا خیر و … . من فکر می‌کنم این ارزش خارق‌العاده‌ای برای تیم توسعه و هم تیم عملیات فراهم می‌کند.

بله، این مثال خوبی بود از ارزش‌آفرینی که برای توسعه‌دهنده‌ها و همینطور مدیرسیستم‌ها ایجاد می‌شود.
Docker خودش بر روی یک میزبان لینوکس اجرا می‌شود زیرا محفظه‌ها از فایل‌سیستم لایه‌ای و فضاهای نام (Namespace) و دیگر مواردی که شما اشاره کردید، بهره می‌برند. بنابراین از لحاظ تئوری، سیستم‌های مکینتاش و ویندوز نمی‌توانند Docker را اجرا کنند. اما ابزاری با نام Boot2Docker وجود دارد که این امکان را فراهم می‌کند. آیا ممکن است مختصری در مورد آن صحبت کنید؟

قطعاً، در حال حاضر، Docker خیلی بر لینوکس استوار است و متکی بر کرنل لینوکس است اما قرار نیست همیشه این طور بماند. باگفتن این حرف رازی را فاش نمی‌کنم، [قبلاً] افراد در مورد آن صحبت کرده‌اند: نسبتاً ساده خواهد بود که با استفاده از چیزهایی از قبیل FreeBSD Jails بتوانیم Docker را بصورت یک شهروند بومی (Native Citizen) بر روی Apple یا FreeBSD اجرا کنیم. همین طور برای داشتن محفظه‌های بومی بر روی پلتفرم ویندوز هم تکنولوژی‌های سبکی (Thin) مانند پروژه Hyper-V و چیزهای مشابهی مطرح هستند. اما در این اثناء در حالی که این‌ها هنوز اهداف آرمانی هستند، ما ابزاری با عنوان Boot2Docker را هم داریم. فکر می‌کنم Boot2Docker یک ماشین مجازی خیلی کوچک است. در واقع، یک کلاینت Docker بهمراه یک ماشین مجازی کوچک به نام DockerHost است که با یک برنامه نصب ساده برای ویندوز و مَک ارائه می‌شود که می‌توانید آن را دانلود کرده و نصب و اجرا کنید. در این صورت، با استفاده از خط فرمان خود می‌توانید با آن ماشین مجازی تعامل کنید. ما به نوعی وانمود می‌کنیم که DockerHost یک برنامه‌ی محلی است. هنوز چالش‌هایی در مورد آن وجود دارد، هنوز مخفی نیست، شما مجبورید که برخی پیکربندی‌های شبکه و … را انجام دهید، البته ما اغلب آنها را برایتان انجام می‌دهیم. Boot2Docker یک تجربه کاملاً بومی نیست اما چنانچه نرم‌افزارهایتان متکی بر ویندوز یا مک باشد، استفاده محلی از Docker را خیلی آسان‌تر می‌کند.

بله، قطعاً مواردی کاربرد جدیدی برای کاربرانی که در لینوکس توسعه نمی‌دهند، فراهم می‌کند.
ما اطلاعات کمی در ارتباط با مبانی Docker بیان کردیم. چنانچه شنوندگان می‌خواهند جزییات بیشتری بدانند، به آنها قویاً کتاب Docker ای که جیمز نوشته است را توصیه می‌کنم.
بیایید کمی به سراغ این برویم که چگونه از محفظه‌های Docker استفاده کنیم؟ شما کمی به آن وارد شدید، هر محفظه Docker یک دستور (Command) را اجرا می‌کند که به نوعی توصیه می‌کند که هر محفظه Docker تنها یک سرویس را اجرا کند. آیا این دلیل خاصی دارد؟ شما به معماری سرویس‌گرا و ریزسرویس‌ها اشاره کردید. منظور سئوال من این است که آیا دلیل فنی داشته یا نوعی دلیل فلسفی بوده که شما فکر می‌کنید توسعه‌دهنده‌ها باید به روش معماری سرویس‌گرا و ریزسرویس‌ها کار کنند؟

در واقع، دلیل فنی نیست و بیشتر به دلیل فلسفی می‌ماند. چیزی جلوی شما را نگرفته است که چندین پروسس را بر روی یک محفظه Docker اجرا کنید، شما می‌توانید از ابزارهای مدیریت سرویس مانند systemd یا Supervisor یا چیزهای مشابه آن استفاده کنید تا بتوانید مثلاً کل Stack LAMP را اجرا کنید یعنی Apache، MySQL و PHP همگی را داخل یک محفظه Docker اجرا کنید اما در این صورت نرم‌افزار‌ها پیچیده و پیچیده‌تر می‌شوند و ارتباط بین آنها -مواردی از قبیل پورت‌های باز شده، انواع مختلف کنترل دسترسی‌ها، پیکربندی‌ها، یکپارچه‌سازی‌ها و …- پیچیده‌تر می‌شود.

مشکلات زیرساخت‌های بزرگ که خلال چند سال گذشته، با آن روبرو بوده‌ایم به علت این بوده است که افراد نمی‌دانستند نرم‌افزارهای‌شان چطور با هم تعامل دارند. خصوصاً در سیستم‌ها معظم (Enterprise)، افرادی که نرم‌افزار اصلی را نوشته‌اند دیگر در شرکت کار نمی‌کنند و [به جای آن] مقداری دانش به ارث برده شده و حجمی از داده‌های مستندشده وجود دارد و بخش عمده اشکالزدایی مشکل تنها مربوط به شناسایی این است که هم‌اکنون نرم‌افزارها چطور کار می‌کند و چطور با هم صحبت می‌کنند.

فکر می‌کنم در دنیای معماری‌ سرویس‌گرا و ریزسرویس‌ها، می‌توانید بگویید: من در نرم‌افزارم 10 محفظه دارم، من راهی برای بازرسی آنها و مشاهده چگونگی متصل شدن آنها به هم دارم – ما قبلاً در مورد لینک بین محفظه‌ها و باز کردن پورت‌ها صحبت کردیم- من می‌توانم همه این‌ها را عمل‌گرایانه واکاوی کنم و ببینم که بله، من 10 محفظه دارم که فلان پورت‌هایشان باز شده است، فلان محفظه و فلان محفظه و فلان محفظه به فلان شکل به هم لینک شده‌اند و …، به این طریق، می‌توانم متوجه اساس معماری نرم‌افزارم بشوم و بفهمم فلان محفظه است که باعث مشکل شده است فکر می‌کنم این نوع تجربه‌های خطازدایی خیلی ساده‌تر است. من دارم از قول کسی می‌گویم که در چند سال گذشته بیشتر بر روی برطرف کردن مشکلات عملیاتی (Operational) تمرکز داشته است. همچنین فکر می‌کنم دیدگاه معماری سرویس‌گرا، از لحاظ تولید نرم‌افزارها و تقلید (Mocking) و تست کردن آنها و همینطور از لحاظ قابلیت دیگر افراد برای تعامل برقرار کردن با آن‌ها، کار را خیلی ساده‌تر می‌کند. مثال‌های تامه‌ای برای آن وجود دارد مثلاً Amazon یک نمونه کلاسیک آن است. گروه توسعه‌دهنده‌های Amazon، API ها را به این روش منتشر می‌کنند که همه چیزهای داخل آن برای توسعه‌دهنده‌های گروه‌های دیگر به نوعی، جعبه‌سیاه است و تنها بیان مشخصات API (API Spec.) منتشر می‌شود و گروه‌های دیگر سرویس‌هایشان را برآن اساس می‌نویسند. این شاید کمی افراطی باشد اما به نظر من، خیلی از نرم‌افزارها و سرویس‌ها وجود دارند که با این جهت‌دهی، ساختن آنها و مدیریت کردن و تست آنها، خیلی ساده‌تر است، یعنی چنانچه [تنها] بیان مشخصاتی از API، سرویس یا فرمت داده‌ها و یا فرمت Protobuf آنها منتشر شود و دیگران برآن اساس، مصرفش کنند. این دلیل بوده است که Docker را به این نوع نگاه هدایت کرده است.

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

این ناحیه‌ای [از نیازمندی‌ها] است که خیلی سریع در حال توسعه است. در حال حاضر Docker کمی بیش از یک سال عمر دارد. فکر می‌کنم یک سال و نیم باشد. (زمان ضبط این مصاحبه، تابستان سال 2014 بوده است -مترجم) بنابراین مثل نطفه‌ای می‌ماند که بر روی انواع مختلفی از تکنولوژی‌ها ایستاده است. اعضای اولیه‌ی آن روی بخش‌های پردازشی [متمرکز] بوده‌اند و اکنون مرحله بعدی که ما به آن فکر می‌کنیم ماجرای هم‌نواسازی (Orchestration) است. شما مثال کلاسیکش را گفتید که یک وب‌سرور را می‌خواهید راه بیاندازید اما به این نیاز است که اول پایگاه داده راه انداخته شود. این مثال ساده‌اش است، می‌توان مثال‌های پیچیده‌تری داشت که مثلاً چندین پایگاه داده در نواحی مختلف جغرافیایی قرار گرفته باشد یا چندین لایه برنامه داشته باشیم و … . ما در اکوسیستم Docker، متوجه نیاز به ابزار Config شدیم. Config یک ابزار سازماندهی است که به شما اجازه می‌دهد که مجموعه‌ای از محفظه‌ها تعریف کنید. در آن گفته می‌شود که یک سرویس از فلان محفظه و فلان محفظه ساخته شده است و آنها را به این ترتیب اجرا کن و به هم لینکشان کن. بنابراین، این [ابزار] برخی از این گونه مشکلات را حل خواهد کرد. در نتیجه آن حجم زیادی از ابزارها، به اکوسیستم اضافه خواهد شد که شامل یکپارچه‌سازی با چیزهایی از قبیل ZooKeeper و ابزارهای مرتبط با کشف سرویس هم خواهد بود. بنابراین یکی از گام‌های جذاب بعدی تولید همین ابزارهای هم‌نواسازی و مدیریت‌های شخصی‌سازی شده خواهد بود.

و آیا قرار است امکان اجرای محفظه‌ها بر روی چندین میزبان هم اضافه شود؟ تا الان ما داشتیم در مورد اجرای Docker بر روی یک میزبان کوچک و منفرد صحبت می‌کردیم. درسته؟

ما یک پروتوتایپ ابزار با نام libswarm منتشر کرده‌ایم. این ابزار در واقع برای این طراحی شده است تا پروتوتایپی در مورد نحوه صحبت کردن میزبان‌های Docker با همدیگر باشد. در حال حاضر محفظه‌هایی که بر روی یک میزبان Docker قرار گرفته‌اند باید از شبکه برای صحبت با یکدیگر استفاده کنند اما واقعاً باید یک کانال ارتباطی پشتی برای این منظور می‌داشتند. ما باید به امر تعاملات بین Docker ها فائق بیاییم. اینکه یک میزبان Docker بتواند بگوید که: «من یک میزبان Docker هستم و یک سرویس وب Apache دارم» و یک میزبان دیگر بگوید: «من هم یک پایگاه داده دارم که باید Apache آن را بیابد. آیا می‌توانی یکی از محفظه‌های خود را به یکی از محفظه‌های من لینک کنی؟»

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

Docker چطور با جنبش زیرساخت‌های تغییرناپذیر (Immutable Infrastructure) در DevOps تطبیق پیدا می‌کند؟ آیا Docker جایگزین یا رقیبی برای ابزارهایی از قبیل Chef و Puppet است؟

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

Puppet و Chef و همینطور Ansible و Salt همگی برای مدیریت این آشفتگی‌ها و تغییرات تدریجی در پیکربندی بوجود آمده‌اند. [اگر از محفظه‌ها استفاده کنید] احتمالاً نیاز کمتری به استفاده از آنها خواهید داشت زیرا محفظه‌ها خیلی خیلی کو‌تاه‌عمرتر هستند و تغییرناپذیر (Immutable) هستند. خیلی ارزان‌تر خواهد بود که به جای استفاده از Puppet و Chef ، یک محفظه را به حالت قبلی خود بازسازی کنید. ممکن است از آنها فقط برای این منظور استفاده کنید که محفظه‌ها را از بین برده و نمونه‌های جدید از آنها بسازید. در این صورت Puppet و Chef نقش مکمل را خواهند داشت به این معنا که میزبان Docker به جای مدیریت شدن نیاز به تدارک دیده شدن دارد. به این ترتیب که تصاویر بعدی Docker باید تولید شود. شما داخل ماژول Puppet یا دستورالعمل Chef احتمالاً اطلاعات مفیدی درباره چگونگی ساختن برنامه خود را دارید. وقتی بخواهید آنها را برای Docker بکار ببرید، دیگر نیازی نیست که بخش نگهداری مبتنی بر امور بلندمدت را داشته باشید و تنها اگر بخواهید، آنها [محفظه‌ها] را نابود و دوباره‌سازی می‌کنید.

بله، قطعاً می‌توانم یک جنبه مکمل بودن را در آنها ببینم.
من شنیده‌ام که محفظه‌های Docker به محفظه‌های موجود در صنعت حمل و نقل در کشتی‌ها، قطارها و کامیون‌ها، تشبیه می‌شود. آیا ممکن است کمی آن را توضیح دهید.

این تشبیه Docker به بنادر و محفظه‌ها و اصطلاحات این صنعت چیزی است که ما آن را هنگام توسعه‌ی زبان خیلی بسط نمی‌دادیم. پیش از محفظه‌های چند منظوره (محفظه‌های بزرگ فولادی که با آن آشنا هستید و در کشتی‌های باربری قرار می‌گیرند) کاری که انجام می‌شد این بود که یک صندوق‌دار یا تحویل‌دار در کشتی وجود داشت. کار آن‌ها این بود که کالاها را تحویل گرفته و طوری در کشتی قرار دهند که از ظرفیت تجاوز نکند، باروت کنار کبریت نباشد و تمام مراقبت‌های دیگری که مثلاً برای نگهداری ادویه‌های گران‌بها لازم است را انجام می‌دادند. این‌ها فرآیند بارگذاری و تخلیه را کاملاً دشوار می‌کرد. اغلب روزها طول می‌کشید تا کشتی را بادقت بار بزنند. این به آن خاطر آن بود که اگر در سفر مشکلی پیش می‌آمد مثلاً اگر آب وارد چیزی می‌شد احتمال زیادی وجود داشت که بخشی از محموله خود را از دست بدهید. این، سربار قابل توجهی به فرآیند حمل و نقل می‌افزود تا اینکه محفظه‌ها مطرح شدند و فردی آمد و گفت: چطور است که جعبه‌هایی بسازیم که همگی یکسان باشند؛ همگی قلاب‌ها سیستم برچسب‌گذاری یکسانی داشته باشند تا یک سیستم یکپارچه‌‌ی شناسایی داشته باشیم. در آنصورت دیگر اهمیت نخواهد داشت که چه چیزی را داخل آنها بار بزنیم زیرا از هم تفکیک شده‌اند و کاملاً قابل حمل خواهند بود. می‌توانید آنها را از کشتی تخلیه کنید و در کامیون بگذارید و نیازی نیست به عنوان بخشی از این فرآیند حتی محفظه‌ها را باز کنید.

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

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

چیزی که به آن اشاره نکردم این بود که بعد از اینکه محفظه‌های چند منطوره معرفی شد، زمان حمل و نقل 70 درصد کاهش یافت. در مورد هزینه‌اش هم دقیقاً نمی‌دانم، من در دهه 40 زندگی‌ام هستم و این مربوط به قبل از تولد من است اما پدر و مادرم به خاطر دارند که مثلاً ارسال یک کالای مصرفی از استرالیا به انگلیس یک کار کاملاً پرهزینه و غیرمتعارف بوده است و ممکن بود 6 تا 8 هفته منتظر می‌شدید تا یک بسته از لندن به سیدنی برسد. فرآیند محفظه‌های چند منظوره به شدت تجارت و حمل و نقل بین‌المللی را تسریع کرد و در واقع، روش تجارت افراد را تغییر داد. به همین خاطر است که ما از این تشبیه استفاده می‌کنیم. ما فکر می‌کنیم این ظرفیت وجود دارد که این [استفاده از محفظه‌ها] باعث تغییرات اساسی در روش تولید، مدیریت و انجام امور عملیات نرم‌افزارها شود و روش آتی در انجام پردازش‌ها و کارها باشد.

بنابراین خیلی دشوار است که همان مرتبه از بهبود حاصل شود…

واضح است که هنوز چالش‌هایی وجود دارد اما فکر می‌کنم لازم است افراد به خاطر بیاورند که چه تاریخچه مختصری در این مورد داریم. خود ماشین‌های مجازی تکنولوژی نسبتاً جدیدی به حساب می‌آید، اولین چیزی که واقعاً تجاری شد، VMWare بود که حدود 10-11 سال عمر دارد و به عنوان یک تکنولوژی، به نسبت نوپا است.

به وضوح ماشین‌های مجازی، به شدت نحوه کار با زیرساخت‌ها را دگرگون کرده است. در واقع، آنها سرویس‌های ابری را ممکن ساختند؛ بدون ماشین‌های مجازی سرویس‌های ابری و برخی موارد دیگر، وجود نداشت. این‌ها در مدت زمان کوتاهی رخ داد. اکنون که به مفهوم سرویس‌های ابری نگاه می‌کنیم، تبدیل به یک چیز عادی شده است. مثلاً این‌که که سروری داشته باشید که 100 ماشین مجازی را اجرا می‌کند، 20 سال پیش جزء بیشتر به معجزه شبیه بود. و من کارم را در دنیای MainFrameها شروع کردم که در آن چیزهایی مثل پارتیشن‌بندی منطقی (Logical Partitioning) مطرح بود که مثل یک مجسمه‌ی یادبود یک میلیون دلاری بود. بنابراین فکر می‌کنم طی 10-12 سال گذشته تغییرات جذابی در مورد مدیریت زیرساخت‌ها را دیده‌ایم، امیدوارم Docker، ادامه راه تغییرات بعدی خلال 4-5 سال آینده باشد.

قطعاً، کاملاً منطقی به نظر می‌رسد. آیا به نظر شما Docker، یک جایگزین برای روش‌های سنتی مجازی‌سازی سخت‌افزار است؟

فکر می‌کنم در محیط‌های پلتفرم به عنوان سرویس (Platform as a Service) و زیرساخت به عنوان سرویس (Infrastructure as a Service) مانند OpenStack و CloudFoundry و Amazon ماشین‌های مجازی در واقع منابع ایده‌آلی برای پردازش نیستند. آنها کاملاً سنگین هستند و سربار چشمگیری به زیرساخت‌های شرکت اضافه می‌کنند. فکر می‌کنم برای انواع مشخصی از کارهایی که در فضای سرویس‌های ابری به آن علاقه نشان داده می‌شود، [بکارگیری] محفظه‌ها خیلی منطقی‌تر است. شما به زیرساخت‌های تغییرناپذیر (Immutable Infrastructure) و پردازش‌های با کارایی بالا اشاره کردید، این‌ها طبیعتاً با Docker سازگاری دارند. همینطور برای هرکسی که معماری سرویس‌گرا یا ریزسرویس داشته باشد و یا گذرگاه سرویس و چیزهای مشابه داشته باشد، Docker ایده‌آل است. من قویاً توصیه می‌کنم که نگاهی به آن بیاندازند. Docker به طور طبیعی کمک می‌کند که با یک روش کاملاً سالم به معماری خود بیاندیشید. البته واضح است که برخی سرورهای فیزیکی یا کارهای خاص یا میراثی (Legacy) هم وجود دارند که نمی‌توانید به سمت این نوع معماری بروید. من اخیراً به شرکتی رفتم که نرم‌افزارهای گسترده‌ای بر روی کوبول داشتند و جایگزین کردن آن با محفظه‌های Docker واقع‌بینانه نبود. همینطور الان Docker خیلی متمرکز بر لینوکس است. اما خصوصاً در دنیای توسعه و تست که در مورد یکپارچه‌سازی مستمر (Continuous Integration) می‌اندیشیم و نگرانی‌های اصلی‌مان مساعی و همکاری در کارها، مدت زمان رسیدن محصول به بازار (Time to Market) و انتقال کد از محیط توسعه به محیط عملیات است، Docker یک زمینه جذاب است.

ابزارهای زیادی داخل و حول Docker به وجود آمده است. ما به تعدادی از آنها اشاره کردیم. شما به Fig اشاره کردید. موارد خیلی زیادی هست مثلاً CoreOs ، Messos ، Panamax و … . فکر می‌کنید چرا اکنون Docker این حد پرطرفدار شده است و این همه فعالیت را به خود جذب کرده است؟

شما قبلاً کمی درباره Solar Zones و FreeBSD Jails صحبت کردید. قبل از Docker در دنیای لینوکس، محفظه‌های LXC اجرا می‌شد که محفظه‌های لینوکس هم خوانده می‌شدند و ما برخی از ایده‌های خود را از آن تکنولوژی برگرفتیم. فکر می‌کنم مشکل بزرگ همه این تکنولوژی‌ها این بود که استفاده کردن آنها به واقع ساده نبود.

Solar Zone ، FreeBSD Jails ، LXC ، chroot این‌ها، همگی به یک مدیر سیستم زیرک یا یک مهندس زیرک‌تر برای توسعه نیاز داشتند تا بتوان با آن کار کرد. بنابراین اولین چیزی که ما به دنبالش بودیم این بود که Docker رویه‌ای داشته باشد که توسعه‌دهنده‌هایی که هیچ چیزی در مورد زیرساخت‌ها نمی‌دانند بتوانند از آن استفاده کنند. هر زمانی که می‌خواستیم چیز [جدیدی] بسازیم، باز به این توجه می‌کردیم که منجر به افزایش پیچیدگی نشود که بخواهد مانع استفاده از آن ابزار توسط یک مهندس جلوکار (Front-end Engineer) بشود که هیچ اطلاعی در مورد ماشین‌های مجازی، مجازی‌سازی و پشته‌ای که برنامه بر روی آن اجرا شده، ندارد. تمرکز ما بر این بوده است و عامل حجم چشمگیری از استنتاج‌ها همین بوده است. این واقعیت [مهمی است] که توسعه‌دهنده‌ها می‌توانند در مدت زمان خیلی کوتاهی، Docker را اجرا و استفاده کنند و نیازی نیست که هیچ چیزی در مورد کرنل لینوکس و نحوه کارکرد فضاهای نام (Namespace) و گروه‌های کنترلی (CGroup) بدانند، نیازی نیست هیچ چیزی در مورد زیرساخت‌ها بدانند و تنها به دانستن تعدادی دستورات خیلی ابتدایی و امور شبکه‌ای خیلی ابتدایی نیاز دارند مثلاً اینکه فلان پورت به فلان پورت دیگر نگاشت یافته است. این‌ها، چیزهای واقعاً ساده‌ای هستند.

من قبلاً این مثال را زدم که دیگر نیاز نیست با مدیرسیستم صحبت کنید تا یک منبعی دریافت کنید. این برای توسعه‌دهند‌ه‌ها، چیز مهمی است. دیگر مجبور نخواهند بود که یک تیکت درخواست ثبت کنند که من یک کپی از پایگاه داده محیط عملیاتی را می‌خواهم که بر روی یک ماشین مجازی در محیط تست ایجاد شود و کلی منتظرش شوید، نه به خاطر اینکه مدیر سیستم وقت را تلف می‌کند بلکه به خاطر اینکه آنها علاوه براینکه سعی می‌کنند سرویس‌های فعال باشمد به هزارها تیکت مانند آن جواب می‌دهند. به این طریق، کمک می‌شود این نوع تعاملات ترسناک کاهش ‌یابد. به همین خاطر است که توسعه‌دهنده‌ها عاشق آن هستند. افراد تیم عملیات هم، آن را دوست دارند زیرا به طبیعت مقیاس‌پذیر جذاب آن می‌نگرند، برخی از آنها صورتحساب‌های خیلی سنگینی، به شرکت‌هایی مانند VMWare پرداخت می‌کرده‌اند و ماشین‌های مجازی و لایسنس‌های زیادی خریداری کرده بودند. به این ترتیب امیدوارند مقداری از این هزینه‌ها کاسته شود و مدیریت کارها راحت‌تر شود یا اینکه از برخی بحث‌های بین آنها و توسعه‌دهنده‌ها کاسته شود که توسعه دهنده بگوید بر روی ماشین من کار می‌کند و فرد عملیاتی بگوید اما در محیط عملیاتی برای مشتری‌ها کار نمی‌کند. من 25 سال به عنوان مهندس در تیم عملیات مشغول بوده‌ام. می‌توانم مثال‌های بی‌شماری از بحث‌هایی بزنم که در محوطه پردیس و اغلب در ساعت 4 صبح داشته‌ام که برخی توسعه‌دهنده‌ها [به نشان ناامیدی] دستشان را بالا می‌برند و می‌گویند که وقتی من آن را build کردم برایم کار می‌کرد، مشکل تو چیه؟ تو احمقی! و متأسفانه این گونه تعاملات متداول است و خوشایند نیست. اگر بتوانید ذره‌ای از آن بکاهید ارزش مالی خیلی زیادی دارد؛ از لحاظ زمان فعال بودن [سرویس] و روحیه و همکاری [افراد] و سایر چیزها. به همین خاطر به نظر من خیلی هیجان‌انگیز است.

چه چیزهایی برای آینده Docker در نظر گرفته شده است؟ شما به نوعی به آن‌چه ممکن است اتفاق بیفتد اشاره کردید.

بله، ما داریم خیلی سخت روی محصول DockerHub کار می‌کنیم که امکانات خیلی بیشتری در آن قرار دهیم تا اعتبارسنجی بهتری در ارتباط با مفاهیمی از قبیل تیم و سازمان و مخزن‌های خصوصی و عمومی داشته باشد. این‌ها این امکان را خواهد داد که افراد بتوانند به همان طریقی که مثلاً از GitHub استفاده می‌کنند با آن کار کنند.

[مورد دیگر] این است که به GitHub قلاب بخورد و بتوانید برآن اساس کارهایی را انجام دهید مثلاً اگر سورس‌کدهای خود را در GitHub داشتید و تغییراتی در سورس‌کدهای خود در GitHub دادید تصاویر Docker بصورت خودکار بروزرسانی شود. این می‌تواند خیلی جالب باشد. ما بدنبال گسترش آن هستیم. ما یک محصول متن باز داریم که بخشی از این عملکرد را فراهم می‌کند. ما می‌خواهیم کل DockerHub را به صورت در-محل (On-premises) ارائه کنیم. احتمالاً ابتدای سال آینده این کار را خواهیم کرد. همه کسانی که در مورد ارسال اطلاعات خصوصی خود به خارج از فایروال خود ناراحت بودند می‌توانند دقیقاً مانند GitHub Enterprise آن را بصورت داخلی مدیریت کنند.

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

چیزی که شما الان اشاره کردید اما من صراحتاً به آن اشاره نکرده بودم این است که Docker یک ابزار متن‌باز است و هرکسی آزاد است که از آن استفاده کند. Docker همینطور نام شرکت پشت سر پروژه Docker هم هست. مدل تجاری این شرکت چگونه است؟ آیا نواحی مشخصی از این اکوسیستم و محوطه [ابزارهای مرتبط با Docker] هست که شرکت برای خود مدنظر قرار داده است؟

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

مدل تجاری ما برپایه چند چیز است. یکی در پروژه DockerHub است، [در آنجا] باید بابت مخزن‌های اختصاصی که به آنها اشاره کردم پرداخت کنید، دقیقاً مشابه با خرید مخزن‌های اختصاصی در Git Hub است. همینطور ما سرویس‌هایی بر روی آن داریم (فکر می‌کنم 4 سرویس باشد) که فکر می‌کنیم برای خیلی از افراد جذاب باشد [و این سرویس‌های اضافی پولی است].

به علاوه ما خدمات آموزشی مرتبط با ابزار متن‌باز Docker ارائه می‌کنیم، کمک می‌کنیم که کار با Docker را شروع کنید، ما کلاس‌های آموزشی داریم، کلاس‌های عمومی دوروزه و ….، خدماتی داریم که کمک‌تان می‌کنیم برخی مفاهیم قدیمی را با Docker اجرا کنید و آن را راه بیاندازید. و همینطور، خدمات پشتیبانی ارائه می‌دهیم، اگر مشکلی داشته باشید می‌توانید از ما بپرسید.

در آینده، قرار است محصولات بیشتری در این زنجیره ارزش توسعه دهیم. ما فکر می‌کنیم افراد حاضرند بابت این محصولات، پرداخت داشته باشند. یکی از چیزهایی که البته فقط مربوط به دنیای محفظه‌ها نیست، بلکه حوزه‌اش وسیع‌تر است، یک ابزار واقعاً قدرتمند همنواسازی (Orchestration) و یک ابزار واقعاً قدرتمند مدیریت سرویس (Service Management) است. فکر می‌کنم این ابزارها در دسترس عموم نیست یا خیلی خیلی گران هستند. BMC یا HPOpenView یا حتی محصولات VMWare که اخیراً به جریان افتاده و … همگی نیاز به استعدادهای مهندسی قوی دارند. مثلاً ZooKeeper واقعاً ابزار فوق‌العاده‌ای است اما نیاز به تجربه‌های خیلی بالغ مهندسی دارد و مهندسی خیلی قوی نیاز است تا بتوانید آن را با محیط خود تطبیق دهید، این‌ها ابزارهای آماده مصرف نیستند. بنابراین ما فکر می‌کنیم اگر بتوانیم ابزارهای هم‌نوایی و مدیریت واقعاً قوی داشته باشیم که با تمرکز بر روی Docker باشد اما با این امید که بتوانیم با ابزارهای دیگر هم یکپارچه شویم، افراد حاضر خواهند شد که برایش پول بدهند.

آیا فکر می‌کنید مطلبی هست که پوشش نداشته باشیم و شنوندگان بخواهند در موردش بدانند؟

فکر می‌کنم تقریباً همه چیز را پوشش دادیم. فکر می‌کنم به قدری تشریح کردیم که افراد را تشویق کرده باشد که Docker را یک امتحانی بکنند، به مقدار کافی پوشش دادیم.

برای امتحان کردن آن، افراد کجا می‌توانند اطلاعات بیشتری در مورد آن بدست بیاورند و شما را دنبال کنند؟

آدرس وب‌سایت، www.docker.com است. در آن جا، خودآموز‌های خیلی ساده‌ای وجود دارد. فکر می‌کنم در بالای صفحه لینکی با عنوان Try it! وجود دارد که شما را به یک خودآموز 5 دقیقه‌ای هدایت می‌کند که یک آشنایی خیلی ساده ایجاد می‌کند و بعد برای شما تعدادی لینک برای دسترسی به مستندات، نحوه نصب و نحوه شروع به کار قراهم می‌کند. من همینطور کتابی با عنوان کتاب Docker نوشته‌ام که از آدرس www.dockerbook.com در دسترس است که واقعاً یک آشنایی ساده فراهم می‌کند و هیچ پیش‌فرضی در مورد دانش شما ندارد و کمک‌تان می‌کند که از صفر تا کارهای به اصطلاح کاملاً پیچیده را انجام دهید. من از بی‌اطلاعی کامل از Docker شروع کرده و از نصب Docker، ساختن تصاویر Docker، انجام امور خیلی ابتدایی Docker تا کارهای پیچیده کشف سرویس با معرفی ابزارهایی مانند Fig و Consul و … و همینطور گسترش دادن Docker توسط خودتان و یکپارچه شدن با Docker از طریق API یکپارچه‌سازی را بحث کرده‌ام. این کتاب از ماه جولای [سال 2014] در دسترس قرار گرفته است. این کتاب خیلی ارزان است (9.99 دلار). و در ارتباط با خودم، می‌توانید من را در توییتر به آدرس @kartar بیابید، وب سایتی هم به آدرس kartar.net دارم که تعدادی مطلب‌های بلاگ و برخی مقالات مورد علاقه من آن‌جا وجود دارد.

جیمز، از اینکه به مصاحبه آمدید، تشکر می‌کنم.

خیلی ممنون که دعوتم کردید، خیلی خوش گذشت.

اکتبر 23, 2018جولای 24, 2020

تاریخچه و داستان دوآپس | DevOps Story and History

چه مشکلی باعث شد رویکرد جدیدی به نام دوآپس(DevOps) مطرح شود؟

سال 2007 میلادی آقای پاتریک دبوآ (Patrick Debois) درگیر پروژه ی جایی دیتاسنتر دولت بلژیک شد و با یک چالش مواجه شد: سیستم ادمین ها و توسعه دهندگان در تعامل با هم به مشکلاتی برمیخوردند که تاثیر منفی در روند اجرای کار داشت.

آگوست 2008 در کنفرانس سالانه چابک که در تورنتو کانادا برگزار شد(Agile 2008 Conference)، آقای اندرو شفر (Andrew Shafer) پیشنهاد نشستی با عنوان زیرساخت چابک (Agile Infrastructure) را می دهد که تقریبا با استفبال هیچکسی مواجه نمی شود به جز یک نفر و آن یک نفر کسی نبود به جز Patrick Debois ! به دلیل استقبال کمی که صورت گرفت، Andrew از برگزاری اون نشست صرف نظر میکنه. بعد از آن Patrick به دنبال Andrew در یک گفتگوی سرپایی راجع به این موضوع صحبت می کنند و گروه Agile System Administration را در google group ایجاد می کنند.

ژون 2009 در کنفرانس O’Reilly Velocity 2009، آقایان John Allspaw و Paul Hammond سخنرانی معروفی تحت عنوان “10 استقرار در روز: نتیجه همکاری توسعه و عملیات در فلیکر” داشتند. پاتریک که از راه دور این کنفرانس را تماشای می کرد، در توییتر ابراز تاسف کرد که نتوانسته به صورت حضوری شرکت کند. Paul Nasrat در پاسخ به این توییت پیشنهاد برگزاری کنفرانس در بلژیک را به Patrick Debois می دهد.

10 Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw

کلمه DevOps برای اولین بار در کجا و توسط چه کسی مطرح شد؟

اکتبر 2009 Patrik به توصیه John عمل کرد و به فکر برگزاری یک کنفرانس در بلژیک افتاد. اول از همه باید یک اسم مناسب برای این کنفرانس انتخال می کرد. سه حرف Development و سه حرف از Operations به اضافه کلمه days چیزی بود که نام این کنفرانس را تشکیل داد “DevOpsDays”. این کنفرانس در 30 اکتبر با مجموعه قابل توجهی از توسعه دهندگان، sys admin ها، متخصصان ابزار و سایر افراد تشکیل شد. بعد از پایان کنفرانس مباحث در توییتر ادامه پیدا کرد. Patrik به هشتگ #DevOps را برای ادامه بحث انتخاب کرد تا خلاصه تر و راحت تر باشد. از آن زمان تا به حال، این جنبش را به نام DevOps (دوآپس) می شناسیم. (در نحوه نوشتن کلمه دوآپس توافق جامعی وجود ندارد و هر سه حالت DevOps و Devops و devops استفاده می شود)

آوریل 2012 Patrik Debois در یک مصاحبه ویدیویی در سال 2012 اذغان کرد که نامگذاری این جنبش به اندازه ای که به نظر می رسد خیلی عمدی نبوده. (به نظر میرسه منظور اینه که خیلی دقیق و فکر شده نیست). در ادامه Patrik میگوید: “من به این دلیل اسم DevOpsDays را در راستای همکاری تیم های توسعه و عملیات انتخاب کردم که اسم “Agile System Administration” طولانی بود و هیچ وقت برنامه ی بزرگی برای دنیایی به نام DevOps وجود نداشته.

سال 2013 موسسه Puppet Labs اولین نظرسنجی وضعیت دوآپس (State of DevOps) را برگزار کرد تا یک ارزیابی ای از روند رشد و عملکرد این حوزه به دست بیاید.

تاریخچه دوآپس به روایت تصویر

رشد دوآپس در سال های اخیر به روایت تصویر

ممنون که ما را دنبال می کنید.

ژوئن 9, 2018مارس 31, 2020

مزایای دواپس چیست؟ چرا DevOps تا این اندازه اهمیت دارد؟

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

در مطالب قبلی راجع به مفهوم DevOps صحبت کردیم (اینجا و اینجا). همچنین راجع به چارچوب CALMS در دواپس نوشتیم و در جایی دیگر راجع به کج فهمی هایی که در باره DevOps وجود دارد صحبت شد. در ادامه ی این سری مطالب قصد داریم راجع به اهمیت دواپس و مزایای دواپس بنویسیم. لطفا با ما همراه باشید.

چرا دِوآپس تا این اندازه اهمیت دارد؟

1. همه ما با چالش هایی مواجه هستیم، با همکاری هم آن ها را رفع کنیم

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

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

همکاری با یکدیگر در سایه ی ارتباط موثر به شما اجازه می دهد که راه کارهایی را ایجاد کنید که بتواند از حادثه های مشابه در آینده جلوگیری کند.

2. بهبود سرعت ارائه به بازار | Improve Speed to Market

Speed to Market

با بهبود سرعت رسیدن به بازار می توانید مزیت رقابتی در بازاری را بدست آورید که نرم افزارها در آن عمر کمی دارند و خیلی زود به زود کهنه می شوند.

معرفی یک راهکار DevOps شما را قادر می سازد تا در یک دوره زمانی کوتاهتر از روش سنتی از یک مفهوم اولیه به یک محصول قابل قبول برسید. همچنین شما فرصت خواهید داشت منابع را زودتر آزاد کنید و بر بهبود نرم افزار و زیرساخت ها تمرکز کنید. به این معنی که شما با تحویل سریعتر ویژگی ها و قابلیت های جدید نرم افزاری می توانید رقبای خود را پشت سر بگزارید.

3. یکپارچه سازی و تحویل مستمر | CI / CD

Continuous Integration and Delivery

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

تحویل مستمر رویکردی در مهندسی نرم افزار است که تیم ها را قادر می سازد نرم افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می شود و شامل بیلد، تست، پیکربندی و انتشار می شود. (اطلاعات بیشتر: Continuous Delivery).

فرایند های CI و CD توسعه دهندگان را قادر می سازد تا مشکلات را هر چه سریعتر شناسایی و رفع کنند. شناسایی سریع مشکلات به معنی پیچیدگی کمتر و نیاز به کار کمتر برای رفع آن و فرایند دیباگ است. از ابزارهای رایجی که برای انجام عملیات CI و CD وجود دارند می توان به Jenkins، Team City و TFS یا Team Foundation Server اشاره کرد.

بنا به گزارش سالانه Puppet Labs در سال 2014، سازمان های فناوری اطلاعات با کارایی بالا که از روش های DevOps استفاده می کنند، بسیار چابک تر و قابل اطمینان تر از رقیبان خود هستند. گزارش سال 2015 همین موسسه نشان می دهد که روش های دوآپس و فرهنگ دوآپس سازمان ها را قادر می کند که بتوانند اپلیکیشن های خود را 30 برابر بیشتر منتشر کنند، همچنین زمان اعمال یک تغییر یا رفع یک مشکل 200 برابر سریعتر از سایر سازمان ها باشد. در چنین سازمانی بهره وری و تولید محصولات بهتر نرم افزاری، بارها بیشتر از سایر سازمان ها است.

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

4. محیط های عملیاتی پایدار تر | More Stable Operating Environment

Stability

به طور سنتی، نگهداری از سرورها و سخت افزارها و محیط های عملیاتی، بر عهده ی تیم IT Operation (عملیات) و افرادی که آن ها را با نام System Administrators می شناسیم بوده است.

کار کردن به عنوان یک تیم واحد با اعضای چند-عملکردی (cross-functional) شامل مدیران پایگاه داده (DBAs)، تحلیلگران کسب و کار، توسعه دهندگان، تضمین کنندگان کیفیت، و مهندسان عملیاتی و مهندسان DevOps، مزایای بسیاری را به همراه می آورد.

یک تیم به وسیله DevOps، علاوه بر عملکردها (functionality) به پایداری (stability) هم اهمیت می دهد. هر یک از اعضای تیم خود را مالک و مسوول اهداف کسب و کار می داند. تناوب و تکرار انتشارها، تغییرات کوچک، و ابزارهای پایش مانند New-Relic و Boundary به پیشرفت و بهبود محیط های عملیاتی، زیرساخت ها و پایداری سورس-کد ها کمک می کنند.

یکی از سنجه های ویژه در اهمیت به پایداری، تناوب و تکرار انتشارها است. دِوآپس، به مهندسان این امکان را می دهد که بتوانند سریعتر عیب یابی کنند و خطاها را برطرف کنند. این دسته از تمرین ها باعث کاهش شاخص MTTR می شوند. Mean-Time-To-Recover یک متریک بسیار مهم به این معنی است که نشان می دهد سرعت برگشت به وضعیت پایدار در زمان وقوع یک حادثه چقدر است. بنابراین بعد از یک failure در زیرساخت، بسیار سریعتر می توان پایدار را به سرویس بازگرداند.

نرم افزارهای مانیتورینگ اپلیکیشن ها و سرورها مانند New Relic و Boundary با فراهم کردن دسترسی مهندسان به اطلاعات حیاتی نرم افزار و محیط عملیاتی، به شناسایی خطاها کمک می کنند تا پایداری را حفظ کنند.

ترکیب همه ی این ابزارها و به-روش ها (Best Practices) همراه با خودکارسازی (automation) به تیم های DevOps اجازه می دهند تا پایداری کلی سرویس را بهبود ببخشند و خرابی های بحرانی زیرساختی را کاهش دهند. علاوه بر این، آن ها را قادر می سازد تا در آن هنگام سریعتر و چابک تر رفتار کنند.

5. تعمیرات سریعتر و آسان تر | Faster and Easier Fixes

Faster and Easier Fixes
ماهیت سریع و چابک تیم های DevOps تیم ها را قادر می سازد تا قابلیت های جدید را در قالب گسترش‌های کوچک تر و ماژولارتر معرفی کنند. از آنجا که این استقرارها بیشتر هدفمند و ایزوله هستند، شناسایی باگ ها آسانتر است، رفع آن ها سریع تر انجام می گیرد و پیاده سازی آن ها نیز آسان است. فقط لازم است که تیم ها آخرین تغییراتی کد را مجددا بررسی کنند تا بتوانند مشکلات را رفع کنند.

این رویکرد مزایای قابل توجهی هم برای کسب و کارها دارد. امکان رفع سریع تر خطاها باعث رضایت مشتریان شده و منابع ارزشمند را آزاد می کند و می توان این منابع را بر اعمال دیگری مثل طراحی، توسعه و استقرار عملکردهای و ویژگی های جدید متمرکز کرد. استفاده ترکیبی از سیستم های کنترل نسخه(Version-Control)، یکپارچه سازی مستمر (Continuous-Integration)، ابزارهای استقرار خودکار (Deployment-Automation-Tools) و توسعه مبتنی بر تست (TDD) به تیم های DevOps این امکان را داده است که تغییرات را در بخش های کوچکتر و به صورت افزایشی (incremental) اعمال کنند.
به دلیل این پیاده سازی های ماژولارتر، تیم های DevOps می توانند زودتر مشکلات مربوط به پیکربندی، کدهای اپلیکیشن و زیرساخت را کشف کنند؛ زیرا بعد از اتمام کدنویسی، مسئولیت به تیم دیگری محول نمی شود.
به دلیل اعمال تغییرات به صورت کوچکتر و تدریجی، مشکلات، پیچیدگی کمتری داشته و تصمیم گیری برای رعفع آن ها سریع تر انجام می شود زیرا مسئولیت خطایابی و رفع مشکلات فقط متوجه یک تیم خاص می شود.
گزارش State of DevOps که هر ساله توسط Puppet Labs منتشر می شود، در سال 2015 نشان می دهد که، شرکت های IT با عملکرد و بهره وری بالاتر نسبت به رقبای خود با عملکرد ضعیف تر، بعد از fail شدن، 168 بار سریع تر قادر به جبران آن و بهبود وضهیت هستند.

6. تجزیه سیلوهای کاری | Breaking Down Silos

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

7. صرفه جویی هزینه ها و منابع | Resource & Cost Reduction

[عکس کاهش هزینه ها]
با پیاده سازی یک رویکرد DevOps می توانید هزینه ها و منابع مورد نیاز در پیاده سازی های سنتی IT را کاهش دهید. IT به صورت سنتی به عنوان یک مرکز ایجاد هزینه تلقی می شد اما پیاده سازی DevOps نشان داد که این رویکرد ارزش های کاری واقعی ایجاد می کند. وقتی از رویکردهای مدیریت ناب و ارائه مستمر استفاده می کنید، نتایج کیفی بالاتر و طول چرخه ها کوتاه تر می شود و در نهایت هزینه ها نیز کاهش می یابند. این رویکرد به کاهش منابع مورد نیاز از نظر سخت افزار و نیروی انسانی نیز ادامه می دهد. یک معماری ماژولار از اجزایی تشکیل شده که بخوبی بسته بندی شده و ارتباط کمی با هم دارند و به سازمان ها اجازه می دهد که از رایانش ابری به صورت موثر و کارآمد استفاده کنند.
رایانش ابری از طریق استفاده از فرایندهای خودکار و طراحی قوی، سرویس ها و محصولاتی را فراهم کرده که توانایی تطبیق با نیازهای مشاغل را دارند. مزایای رایانش ابری بی شمار هستند و همه این مزایا به کاهش هزینه ها کمک می کنند. هر چند DevOps و رایانش ابری نه متقابلا منحصربفرد و نه مستقیم به هم مرتبط هستند، اما در صورتیکه با هم ترکیب شوند یکدیگر را تقویت می کنند.
انعطاف پذیری ایجاد شده توسط فناوری ابری، تیم های DevOps را قادر به تامین سریع تر نیازهای مشاغل و مشتریان می کند. اگر نیاز به منابع بیشتر یا یک دیتابیس جدید و یا سرورهای تعادل بار باشد، فناوری ابری امکان تحویل خودکار این نیازها را در عرض چند دقیقه فراهم می کند.
همچنین سرویس های رایانش ابری در مواقع بازیابی از حادثه کمک کننده هستند؛ زیرا بیشتر مشکلات توسط ارائه دهنده سرویس مدیریت می شوند.
همچنین، بروزرسانی های خودکار نرم افزار و زیرساخت، که به صورت سنتی درخانه انجام می شد، به ارائه دهندگان ابری محول می شود. در نتیجه زمان و منابع مورد نیاز در قسمت‌های دیگر آزاد می شود.
مزایای دیگری که به کاهش الزامات مربوط به هزینه ها و منابع کمک می کنند، عبارتند از: حداقل شدن هزینه های شروع و هزینه های عملیاتی انجام پروژه، افزایش مشارکت، افزایش دسترس پذیری و دسترسی به داده ها و بهبود امنیت.

8. افزایش کارایی | Increased Performance

[عکس افزایش کارایی]
در محیط های سنتی IT، زمان و منابع زیادی به هدر می روند. معمولاً برای انتظار جهت تکمیل کارها توسط دیگران یا حل چندین باره‌ی یک مشکل، زمان زیادی هدر می رود و این امر باعث سرخوردگی و ایجاد هزینه های مالی می شود.

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

پیچیدگی یا نوع سیستم هایی که این شیوه ها به آن ها اعمال می شود، فاکتور چندان مهمی نیست. مادامی که معماری نرم افزار با در نظر گرفتن قابلیت تست و قابلیت استقرار ایجاد شود، امکان افزایش کارایی بیشتر می شود.

در گزارش “2015 State of DevOps Report” به چند نکته کلیدی اشاره شده که نشان می دهد تیم هایی با رویکرد Devops نسبت به رقیبانشان، از کارایی بالایی برخوردار بودند.

30 برابر استقرار کدهای نرم افزاری بیشتر است
200 برابر استقرار نرم افزار سریعتر است
پایداری سیستم بیشتر شده است
60 درصد شکست های (failure) کمتری دارند
168 برابر سریعتر می توانند بعد از مشکلات، بهبود یابند (MTTR)

فکر میکنم شما هم موافق باشید که این افزایش قابل ملاحظه ای در عملکرد تیم ها است!

9. خلاقیت و نوآوری | Innovation & Creativity

[عکس خلاقیت و نوآوری]

همانطور که در بالا اشاره شد، معرفی ادغام مستمر/یکپارچه سازی مستمر/CI، استاندارد سازی محیط های تولید و استقرارهای خودکار/CD، کارشناسان را قادر می سازد تا بر جنبه های مبتکرانه و خلاقانه تر نقش شان بیشتر تمرکز داشته باشند. زمان و منابع بیشتری که صرف آزمایش و نوآوری می شود، به تیم ها امکان توسعه و انتشار نرم افزارهای بهبود یافته را داده و این امر مستقیما به رسیدن به اهداف بیزنسی ترجمه می شود. محیط و فرهنگی که DevOps به ایجاد و پرورش آن کمک می کند، به درک عمیق تر و پیاده سازی به-روش ها کمک می کند.

10. رضایت شغلی | Job Satisfaction

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

اما دلیل اهمیت رضایت شغلی چیست؟
طبق گزارش سال 2014 Sate of DevOps “رضایت شغلی عامل شماره یک پیش بینی عملکرد (کارایی) سازمانی است.” یعنی رضایت اعضای تیم در انجام نقش شان عامل بسیار مهمی در افزایش کارایی شرکتی است.
شیوه ها و فرهنگ DevOps رضایت کارمندان را افزایش می دهد و این امر منجر به نتایج شغلی بهتر می شود.

11. شکست های کمتر | Fewer Failures

[عکس شکست های کمتر]
داده های گزارش سال 2014 State of DevOps نشان داد که سازمان هایی که عملکرد خوبی دارند تعداد شکست هایشان (خرابی هایشان) 50 درصد کمتر است. این روند ادامه پیدا کرد و گزارش سال 2015 نشان داد که سازمان هایی که طرزتفکر و فرهنگ DevOps را اتخاذ کرده اند نسبت به آن هایی که رویکرد DevOps را پیاده سازی نکرده اند 60 برابر کمتر دچار شکست (خرابی) می شوند. این اطلاعات بسیار واضح هستند و مزایای عظیم DevOps را به عنوان یک طرز تفکر و فرهنگ برای مشاغل و البته افراد، مشخص کردند. شکست کمتر به معنی زمان بیشتر عملکرد سرویس و نیاز به منابع کمتر برای حل مشکلات است؛ در نتیجه به شما امکان می دهد که تمرکز بیشتری بر بهبودهای بیشتر و ابتکارات خلاقانه داشته باشید.

منبع: متن فوق برگرفته از سایت purplegriffon می باشد.

نتیجه گیری

امیدوارم که توانسته باشم مزایای یک رویکرد DevOps را مشخص کرده باشم. فرهنگ فناوری اطلاعات مدام در حال تغییر است و روش های سنتی مدیریتِ انتشار محصولات، اغلب ناکارآمد، هزینه بر و زیانبخش هستند.
شاید کلمه DevOps، واژه‌ای باشد که تازه باب شده است ولی قرار است ماندگار شود و در حال متحول کردن صنعت فناوری اطلاعات است.
افزایش کارایی، کاهش هزینه ها و تولید نرم افزار بهتری که شکست های (failure) کمتری داشته باشد مواردی هستند که تمام فروشنده های حوزه فناوری اطلاعات باید سعی به دستیابی به آن‌ها داشته باشند. با استفاده از یک رویکرد DevOps این موارد قابل دستیابی تر هستند.
برای کسب اطلاعات بیشتر درباره DevOps و اینکه سازمان شما چطور می تواند تغییری فرهنگی به سمت پیاده سازی بهترین روش های DevOps داشته باشد با ما در ارتباط باشید.

ژانویه 27, 2018مارس 31, 2020

یازده شاخص کلیدی عملکرد دواپس | 11 DevOps KPI

شاخص های کلیدی عملکردی دواپس یا DevOps KPI که قبلا به چهار دسته سرعت، کیفیت، بهره وری و امنیت تقسیم کردیم را چطور ارزیابی می‌کنید؟ در این مطلب یازده شاخص کلیدی عملکرد، اصول و پایه های لازم برای ارزیابی موفقیت DevOps را معرفی و بررسی کرده ایم.

شاخص های سرعت دواپس | DevOps Velocity KPI

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

1. فرکانس استقرار | Frequency of deployment

مفهوم: مشخص می‌کند که هر چند وقت یکبار نسخه جدیدی از یک محصول یا سرویس ارائه می‌شود. و به صورت تعداد استقرارها در ماه، هفته، روز یا ساعت ارزیابی می شود.

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

همچنین این معیار به سایر حوزه های استقرار نرم افزار که عملکرد درستی دارند هم اشاره می کند:

طراحی بهتر معماری در فازهای ابتدایی‌تر DevOps: ماژولار کردن، امکان استقرار مکرر و پی در پی را فراهم می کند.
پوشش بهتر تست: اگر تولیدات بیشتری را مورد استفاده قرار دهید، عوامل مربوطه حس می کنند که می توانند محصولات را با فرکانس بالاتری مستقر کنند.

قبلا دو مطلب در رابطه با استقرار نرم افزار منتشر کردیم که خواندن آن خالی از لطف نیست :

2. سرعت استقرار | Speed of deployment

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

دلیل اهمیت: در روش های سنتی، سیستم های شرکتی اتصال تنگاتنگی دارند(tightly coupled هستند)؛ هر زمان چیزی مستقر می شود، ممکن است در نهایت نیاز به استقرار مجدد کل اپلیکیشن باشد. یک دهه پیش، این امر قابل قبول بود – می توانستید از کار افتادگی پنج ساعته‌ی ویندوز را برای نیمه شب زمانبندی کنید، بدون این که این از کار افتادگی تاثیر منفی برای بیزینس داشته باشد. اما مشاغل امروزه جهانی هستند – مثلاً وقتی در امریکا نیمه شب است، در آسیا روز است – و اکثر شرکت ها در همه اوقات مشتریانی دارند که بیدار هستند. بنابراین سریع بودن استقرار امری حیاتی است.

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

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

3. سرعت تایید بیلد ها | Speed of build verification (QA)

مفهوم: کل زمان حرکت یک محصول در چرخه QA

دلیل اهمیت: اکثر اوقات QA تبدیل به یک تنگنا می شود. ارزیابی زمان سپری شده برای یک محصول تولیدی در QA اطلاعات کلیدی درباره اینکه با چه سرعت و فرکانسی می توانید یک محصول یا سرویس ارائه دهید، در اختیارتان قرار می دهد. وقتی مقدار این سنجه بالا باشد، متوجه می شوید که می توانید فرکانس را بدون اینکه QA تبدیل به تنگنا شود، افزایش دهید. اگر این مقدار پایین باشد، نشان می دهد که نیاز به پیاده سازی تکنیک هایی مثل اتوماسیون تست در خط لوله‌ی انتشار محصول دارید (release pipeline).

4. فرکانس تایید بیلد ها | Frequency of build verification (QA)

مفهوم: تعداد تولیداتی که یک تیم QA می تواند در یک دوره خاص به مصرف برساند.

دلیل اهمیت: افزایش تعداد تولیداتی که QA می تواند به صورت مثبت مورد مصرف قرار دهد تاثیر مثبتی بر زمانبندی انتشار دارد. ممکن است سرعت استقرار بالا باشد، اما بدون ادغام مستمر (Continuous Integration) باید تولیدات را به صورت دستی مدیریت کنید که این کار باعث کند شدن خط لوله انتشار (DevOps Pipeline) می شود. به طور مشابه، بدون Continuous Testing، حین فرایند تست زمان هدر می رود. نتیجه این است که تیم QA نمی تواند حداکثر تعداد تولیدات را در هر چرخه به مصرف برساند و پوشش تست – همچنین اطمینان از حرکت به مرحله بعد – دچار مشکل است.

ادغام و تست مستمر می تواند فرکانس اعتبار سنجی تولید را افزایش دهد – در بعضی موارد می تواند آن را در هر ماه تقریبا دو برابر کند. وقتی که مقدار این عدد بالا باشد، نشان دهنده پوشش بهتر تست، نشان دهنده ی اطمینان بیشتر برای حرکت به مرحله بعد تولید و سرعت بیشتر تولید است.

شاخص های کیفیت دواپس | DevOps Quality KPI

پیرو مطلب قبلی با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” که در آن به دلیل اندازه گیری و ارزیابی کیفیت اشاره کردیم، در ادامه به سه تا از شاخص عملکرد کلیدی کیفیت در دواپس می پردازیم.

5. نرخ موفقیت استقرار | Deployment success rate

مفهوم: درصد استقرارهایی که بعد از اعتبار سنجی موفق تلقی شده اند. در اینجا موفقیت به این معنا است که بعد از استقرار، در فاصله ی کوتاهی مجبور به استقرار مجدد یا انتشار patch نشیم.

دلیل اهمیت: نرخ موفقیت بالا هنگام استقرار در سرورهای غیرتولیدی، دلالت بر کیفیت بالا در مراحل قبلی دارد. نرخ موفقیت پایین حاکی از ضعف کیفی کدنویسی است. در خیلی از شرکت ها، ممکن است System Integration Test و QA نرخ موفقیت بالایی داشته باشند ولی در عین حال در محیط پیش عملیات (Staging) موفق نباشند. این معیار می تواند به شما کمک کند تا مشکلات موجود در مرحله استقرار را هدف گرفته و از بین ببرید. نرخ موفقیت باید به مرور زمان افزایش پیدا کند.

در سازمان هایی که عملکرد خیلی خوبی دارند، مقدار این معیار باید به دلیل حذف مشکلات در پیش عملیات (Staging) – یا بهتر از آن، پیشگیری از این مشکلات – بالا باشد. اما خیلی از سازمان ها در این حوزه دچار چالش هستند و باید انتشارها (یا نسخه ها) را به عقب برگردانند. پایین بودن نرخ موفقیت بعد از یک فاز پیمایش موفق می تواند نشان دهنده چندین مشکل باشد:

فقدان سازگاری بین محیط های مختلف | Lack of consistency across environments
فقدان مدیریت مناسب داده های تست | Lack of good test data management
پوشش و کیفیت پایین تست | Low testing quality and coverage

6. میزان حوادث/نقایص | Incident/defect volumes

مفهوم: تعداد حوادث و نقایص گزارش شده در یک نسخه خاص از یک محصول یا سرویس در محیط عملیاتی

دلیل اهمیت: حوادث و نقایص نشان دهنده از دست دادن زمان، پول و فرصت است. بالا بودن عدد این معیار نشان دهنده وجود مشکلاتی در حوزه های زیر است:

کیفیت نیازمندی ها | Quality of the requirements
کیفیت توسعه | Quality of development
کیفیت تست از جمله قابلیت مدیریت داده های تست | Quality of testing, including test data management capability
سطح همکاری بین استقرار، QA و عملیات (مثلاً اشتباه در درک نیازمندی ها) | Level of collaboration between development, QA, and operations

7. نرخ پوشش نیازمندی ها | Requirements coverage ratio

مفهوم: درصد قابلیت ردیابی (traceability) بین نیازمندی ها و تست ها (منظور امکان ارتباط دادن این دو به هم است).

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

وقتی که نیازمندی ها و test case ها با هم هماهنگی داشته باشند، تغییر در نیازمندی ها منجر به قابلیت مشاهده موارد متناظر در پوشش test case می شود. بروز رسانی هر یک از test case به نیازمندی ربط پیدا می کند. وجود ارتباط، تاثیر مثبت و مستقیمی بر کیفیت نرم افزار دارد. بالا بودن میزان این ارتباط نشان دهنده افزایش کیفیت نرم افزار؛ تناقض و ناسازگاری کمتر بین تحلیل گران، توسعه دهندگان و تیم QA؛ و بهره وری بالاتر است.

شاخص های بهره وری دواپس | DevOps Productivity KPI

گروه دیگر از شاخص هایی که در مطلب قبلی با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” اشاره شد، بهره وری یا Productivity بود. در این خصوص نیز دو شاخص عملکرد کلیدی وجود دارد که شرح خواهیم داد.

8. میزان استفاده از ویژگی‌ها | Feature usage

مفهوم: تعداد یا درصد ویژگی های استفاده نشده از یک محصول یا سرویس خاص وقتی که تولید شده است.

دلیل اهمیت: DevOps یک چرخه بازخوردی است (feedback loop) که شامل بیزنس، توسعه، تست، عملیات و کاربران می شود. پایین بودن میزان استفاده از ویژگی‌ها به این معناست که بخش فناوری اطلاعات (IT) مشغول توسعه ویژگی ها و امکاناتی است که یا مورد تقاضا نیستند (بازخورد ضعیف از سوی بیزنس به بخش توسعه)، یا مورد نیاز نیستند (بازخورد ضعیف از طرف کاربران به بیزنس) یا به صورت ضعیف ساخته شده اند (مشکل در بازخورد از سوی بخش IT). هزینه ویژگی ها و امکاناتی که مورد استفاده قرار نمی گیرند، می تواند بسیار زیاد باشد، بنابراین مهم است که علت این امر شناسایی شود. بالا بودن تعداد ویژگی هایی که در یک محصول خاص استفاده نشده اند نشان دهنده منفی بودن میزان اثربخشی مدیریت و توسعه نیازمندی ها است.

9. میانگین زمان لازم برای بازیابی سرویس | Mean time to restore service (MTTRS)

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

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

بعلاوه، MTTRS می تواند مشخص کننده مشکلاتی در سازمان باشد از جمله:

وضعیت سلامت چرخه بازخورد بین بیزنس، بخش های توسعه، QA، عملیات و کاربران نهایی.
سطح چابکی شرکت و این که شرکت با چه سرعتی می تواند به تغییرات ایجاد شده توسط یک فرد، فرایند و تکنولوژی‌های آینده واکنش نشان دهد.
بهره وری و اثربخشی کلی

The health of the feedback loop between the business, development, QA, operations, and end users
The level of enterprise agility and how quickly the enterprise can react to changes from a people, process, and technology perspective
Overall productivity and effectiveness

شاخص های امنیت دواپس | DevOps Security KPI

سرعت، کیفیت و بهره وری بدون امنیت می تواند کل سرویس را به خطر بیاندازد. در مطلب قبل با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” به اهمیت اندازه گیری امنیت در دواپس اشاره کردیم و در ادامه دو تا از KPI های مهم در این خصوص را شرح خواهیم داد.

10. میزان قبول شدن تست امنیت | Security test pass rate

مفهوم: نسبت شکست در مقایسه با موفقیت در گذراندن اسکن امنیتی کدهای بعد از بیلد کردن محصول در یک دوره زمانی خاص.

دلیل اهمیت: مشخص شدن آسیب پذیری های امنیتی در مرحله تولید، به این موضوع را تضمین می کند که همیشه قبل ورود به سایر بخش های DevOps Pipeline، محصولاتی سبز و خوب تولید می شوند.

11. نرخ تشخیص اسکن کدها | Code scanning detection rate

مفهوم: تعداد اسکن های امنیتی که در یک بازه زمانی یا فاز پردازش خاص، مشکلی را مشخص می کنند همراه تعداد مشکلات.

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

تحلیل مناسب اعداد و ارقام

DevOps این قابلیت را دارد که زنجیره ارائه نرم افزار را به ماشینی با تفکر ناب، سریع و به شدت موثر تبدیل کند تا آنچه کاربران تقاضا دارند را عرضه کند. این تبدیل اهمیت بسیار زیادی دارد. طبق یکی از نظر سنجی های شرکت Forrester Consulting که در سال 2015 انجام شده، 64 درصد از پاسخ دهندگان بر این باورند که نرم افزار یکی از عوامل کلیدی توانمندساز مشاغل است و موفقیت مشاغل بستگی به اپلیکیشن هایی با کیفیت بالا دارد که مناسب با مدل های بیزنسی مدرن باشد.

DevOps has the potential to transform the software delivery chain into a lean, fast, highly effective machine that delivers what users want.

شرکت نرم افزاری HPE با کمک داده های حجیم معیارهایی را از منابع مختلف در سیستم های IT مختلف جمع آوری کرده است تا این 11 شاخص کلیدی عملکرد و موارد دیگر را تولید کند. ابتکار شرکت نرم افزاری HPE دیدگاهی واحد از معیارهای DevOps فراهم می کند که به شما برای بدست آوردن اطلاعات و بینش هایی درباره مسیر حرکت DevOps کمک می کند؛ به طوری که می توانید به شیوه ای موثر و کارآمد تبدیل و تحول DevOps را مدیریت کنید.

مسیرهای آتی برای شاخص های کلیدی عملکرد DevOps

وقتی که شروع به استفاده از شاخص های کلیدی عملکرد برای ارزیابی موفقیت DevOps کردید، راه های زیادی برای گسترش داشبورد معیارهای دواپس و متناسب کردن آن با سایر سطوح سازمان خواهید داشت. برای گسترش معیارهای DevOps به سمت بالا و حوزه بیزنس، داشبورد KPIی DevOps را می توان به صورت یک داشبورد مخصوص مدیر ارشد فناوری اطلاعات درآورد که دیدگاهی سطح بالا از تشکیلات IT و همچنین میزان پیشرفت در فعالیت های عمده فراهم کند. (DevOps Dashboard)

یکی از شاخص های کلیدی عملکرد که در حال حاضر مشاغل علاقه زیادی به آن دارند، میزان استفاده از ویژگی ها است اما می توانید در کنار آن، زمان چرخه را هم نظارت کنید که نشان می دهد تولید یک ویژگی خواسته شده و استقرار آن در یک محصول چقدر زمان می برد. البته شاخص های کلیدی عملکرد از نوعِ اقتصادی نیز همیشه برای مشاغل متناسب و مهم هستند – که یکی دیگر از راه های گسترش داشبورد را تشکیل می دهند.

بعلاوه می توانید داشبورد DevOps را به سمت پایین هم گسترش دهید تا فعالیت های روزمره‌ی افراد را تحت پوشش قرار دهد.

استفاده از معیارها برای ادامه مسیر حرکت DevOps

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

“تشکیلات IT باید این امر را به رسمیت بشناسند که DevOps قابلیت تحول و تغییر را دارد و بر این اساس باید در جنبه های فردی و فرایندی تلاش هایشان سرمایه گذاری زمانی و پولی کنند. مدیران IT نباید بیش از حد بر فناوری تاکید کنند و در نتیجه حوزه های دیگر را تحت تاثیرات منفی قرار دهند.”

منبع : “Hewlett Packard Enterprise, “Measuring DevOps success

دسامبر 31, 2017مارس 31, 2020

ارزیابی میزان موفقیت عملکرد DevOps با DevOps KPI

مدیریت DevOps با استفاده از معیارهای ارزیابی

امروزه و در عصر DevOps، پیوسته لازم است که شاخص های کلیدی عملکرد (KPI) را ارزیابی کنید تا میزان موفقیت DevOps مشخص شده و امکان تغییرات بیشتر فراهم شود.

DevOps بدون tradeoff

DevOps در اصل از طریق جنبش چابک (Agile Movement) رشد پیدا کرد و در واقع راهکاری برای افزایش سرعت ارائه نرم افزار توسط تیم های توسعه نرم افزار به مشتریان است. در حال حاضر DevOps دربرگیرنده همه بخش های فرایند ارائه نرم افزار است از برنامه ریزی گرفته تا ایمن سازی، نظارت و بروز رسانی اپلیکیشنی که از قبل تولید شده است.

امروزه، DevOps به طور گسترده برای build، تست و ارائه نرم افزار توسط کسب و کارهای مختلف پذیرفته شده است. در این دنیای رقابتی، پرتحرک و همیشه متصل، DevOps شرکت ها را قادر ساخته که از طریق از بین بردن سیلوهای توسعه (Dev) و عملیات (Operation)، با خواسته ی کاربران در مورد تحویل و ارائه سریع همگام شوند.

این شرایط اهمیت کیفیت نسبت به گذشته را دوچندان کرده است؛ در نتیجه کسب و کارها نمی توانند صرفا برای ارائه سریع نرم افزار به بازار، کیفیت را نادیده بگیرند. با ارائه ی یک اپلیکیشن با عملکرد ضعیف در یک فروشگاه اپلیکیشنی (app store) که کاربران نظرات منفی زیادی در آن درج می کنند، به سرعت می توان شهرت و خوشنامی یک برند را از بین برد. با استفاده از DevOps، بهینه سازی کارها در جهت افزایش سرعت، همزمان با حفظ کیفیت و کاهش خطرها قابل انجام است. Batchهای کوچک، سریع تر ارائه شده و به صورت ذاتی مشکلات مربوط به کیفیت و امنیت را کاهش می دهد.

افزایش سرعت در توسعه نرم افزار به روش سنتی، اغلب اوقات باعث کاهش کیفیت و افزایش آسیب پذیری می شود. همچنین در روش های سنتی افزایش سرعت، کیفیت و امنیت عاملی برای افزایش هزینه ها محسوب می شود. اما ابتکارات DevOps می تواند واقعا منجر به بهبود در تمام این چهار بُعد شود: سرعت، کیفیت، بهره‌وری و امنیت. کلید کار اتخاذ چارچوبی برای معیارها است که مشخص کند چه جاهایی در حال پیشرفت هستید و چه جاهایی هنوز نیاز به بهبود دارید.

وجود معیارهای ارزیابی ضروری است

اکثر سازمان ها DevOps را به دلیل یک نیاز بیزینسی خاص مثل بهبود زمان بازاریابی، کاهش نقایص یا تراز کردن بهتر ابتکارات IT با استراتژی بیزینسی پیاده سازی می کنند. اما از آنجا که DevOps هیچ فریم ورک رسمی ندارد، روش های زیادی برای ارزیابی موفقیت DevOps وجود ندارد، در حالیکه این ارزیابی حیاتی است. از آنجا که خیلی از سازمان ها DevOps را به صورت تدریجی پیاده سازی می کنند – اول در یک پروژه و بعد آرام آرام آن را در سراسر سازمان گسترش می دهند – چند پروژه اول باید موفقیت آمیز باشند؛ طوریکه بتوانند پشتیبانی انحصاری برای DevOps ایجاد کنند. همانطور که مشتریان ما به ما گفته اند: “هر چیزی که ارزیابی شود، بهبود پیدا می کند.”

وجود معیارهایی که نشان دهنده موفقیت آمیز بودن یک آزمایش باشند، می تواند به غلبه بر مقاومت های داخلی در برابر پذیرش DevOps کمک کند. یکی از نظرسنجی های شرکت Gartner از مدیران مشاغل² و بخش IT مشخص کرد که “people issue” (موارد مربوط به افراد) بزرگترین چالشی است که سازمان ها در پذیرش DevOps با آن روبرو هستند و 43 درصد پاسخ دهندگان مقاومت در برابر تغیرات را بزرگترین مانع دانسته اند. از آنجا که DevOps نیاز به تحول فرهنگی و تغییرات فرایند و فناوری دارد، وجود پشتیبانی و حمایت انحصاری از آن ضروری است.

بعلاوه، DevOps به عنوان یک سیر تکاملی شناخته شده است که نیاز به بهبود مستمر (Continuous Improvement) دارد. اما اگر نتایج را ارزیابی نکنید، متوجه نمی شوید که DevOps را چطور درون سازمانتان تکامل دهید.

ارزیابی در مسیر تکامل DevOps بسیار ضروری و حیاتی است. اما چطور می توان موفقیت DevOps را ارزیابی کرد؟ چه چیزی باعث عملکرد فوق العاده‌ی یک سازمان می شود؟ کدام شاخص های کلیدی عملکرد (KPI) این قابلیت را دارند که مشخص کنند چه چیزی برای شما خوب کار می کند و چه چیزی خیر – و اطلاعاتی برای توضیح علت (علت کار نکردن بعضی روش ها) فراهم کنند؟ چه چیزهایی را ارزیابی می کنید، چطور آن ها را ارزیابی می کنید و این اعداد دقیقا چه چیزی را نشان می دهند؟

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

معیارهای ارزیابی DevOps در چهار بعد

برای تعیین بهترین شاخص های کلیدی عملکرد (KPI) جهت ارزیابی DevOps، شرکت Hewlett Packard Enterprise Software Services (به اختصار HPE) در ابتدا بزرگترین چالش های ارائه نرم افزار را که مشتریان گزارش شده بود را بررسی کرده است:

کند بودن زمان عرضه به بازار | Slow time to market
ایجاد تجربیات ضعیف برای کاربران | Poor user experience
هزینه های بالا | High cost
پیش پینی پذیری ضعیف | Poor predictability
آسیب پذیری و ریسک | Vulnerabilities and risk

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

شرکت HPE ریشه این مشکلات را چهار حوزه متفاوت می داند:

سرعت | Velocity
کیفیت | Quality
بهره‌وری | Productivity
امنیت | Security

DevOps می تواند تمام این چهار مورد را بدون از دست رفتن هیچکدام برآورده کند. موفقیت در هر یک از این چهار حوزه می تواند زمان عرضه به بازار، تجربیات کاربر، هزینه، پیش بینی پذیری و امنیت را کاملاً بهبود ببخشد.

شرکت HPE، رهبری تعریف معیارهایی که شرکت های امروزی باید ارزیابی و نظارت کنند را بر عهده گرفته است. بعضی از بزرگترین مشتریان DevOps در حال حاضر این فریم ورک را قبول و پیاده سازی کرده‌اند.

سرعت (Velocity) : نرخ ارائه تغییرات نرم افزاری توسط یک سازمان را ارزیابی می کند.
کیفیت (Quality) : ارزیابی می کند که تغییرات نرم افزاری ارائه شده چقدر نیازهای کسب و کار را برآورده و در جهت رضایت عمل می کنند.
بهره وری (Productivity) : ظرفیت و کارایی یک سازمان در تحویل تغییرات نرم افزاری را ارزیابی می کند.
امنیت (Security) : آسیب پذیری هایی که هنگام تحویل تغییرات نرم افزاری نمایان می شوند را ارزیابی می کند.

سرعت، کیفیت، بهره وری و امنیت به یکدیگر وابسته اند. بهبود یک حوزه منجر به بهبود در سه حوزه دیگر می شود بدون این که نیازی به tradeoff باشد.

چرا اندازه گیری و ارزیابی سرعت مهم است؟

مهم ترین ویژگی DevOps سرعت است. DevOps به عنوان راهی برای عرضه سریع امکانات جدید توسط توسعه دهندگان در پاسخ به تقاضای کاربران برای محتوای سریع تر و بهتر، ایجاد شده است. و با توجه به اینکه سرعت، امری نسبی است –احتمالا همیشه می خواهید که سریع تر و سریع تر از قبل باشید– بیشتر تیم های توسعه دهنده فراموش می کنند که به دنبال چه هدفی هستند.

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

سرعت زیاد در تحویل نرم افزار، علاوه بر ایجاد مزیت رقابتی برای شرکت، نحوه تعامل کسب و کار با بخش IT را هم بهبود می بخشد.

چرا اندازه گیری و ارزیابی کیفیت مهم است؟

طبق نظرسنجی ای¹ که شرکت Forrester Consulting از تصمیم گیرندگان IT امریکایی و اروپایی انجام داده است، 78 درصد از پاسخ دهندگان بهبود کیفیت را یکی از خواسته های اصلی گروه های بیزینسی اعلام کرده اند.

با DevOps نیازی به قربانی کردن کیفیت برای رسیدن به سرعت بیشتر نیست. برای افزایش سرعت می توانید ارائه نرم افزار را به واحدهای کوچکتری تقسیم کنید، به طوریکه در واقع تعدادی micro service با وابستگی حداقلی یا بدون هیچ وابستگی ارائه خواهید کرد. unitهای کوچکتر یعنی تحویل سریع تر به همراه کیفیت بالاتر و ریسک کمتر.

بعلاوه DevOps از طریق ایجاد فرهنگی برتر و ابزارهایی برای پشتیبانی از آن، کیفیت را وارد تمامی مراحل زنجیره ارائه نرم افزار می کند.
از نظر فرهنگی، DevOps بر مسئولیت های مشترک، انتظار کیفیت از توسعه دهندگان، تست کنندگان، اعضای تیم امنیت و عملیات و همه افراد بین آن ها تاکید دارد. از نظر تکنیکی، DevOps مستلزم حداکثر میزان ممکن اتوماسیون برای سرعت بخشیدن به فرایندها و کاهش خطاهای انسانی است. و استفاده از یک رویکرد Shift-left در تست، امنیت و مانیتورینگ به بهبود کیفیت کمک می کند.

shift left testing رویکردی در تست نرم افزار یا سیستم است که بر انجام تست در مراحل اولیه چرخه حیات تاکید دارد (moved left on project timeline). این نیمه اول قاعده کلی تست نرم افزار است: “تست زودتر و پر تکرار” (Test Early and Often)

کیفیت چیزی نیست که قابل حدس زدن باشد. بلکه باید آن را توسط معیارهای خاص تعریف و بر این اساس بر آن نظارت کرد.

چرا اندازه گیری و ارزیابی بهره وری مهم است؟

همه ی هدف و تمرکز DevOps این است که به سازمان های فناوری اطلاعات کمک کند تا ارزش بیشتری برای بیزینس ایجاد کند. اما در صورتیکه تلاش های شما بخوبی با بیزینس هماهنگ نشده باشد، هر چقدر هم سریع بتوانید نرم افزارهایی با کیفیت عرضه کنید، این امر (ایجاد ارزش برای بیزینس) میسر نمی شود.

در صورتیکه DevOps درست اعمال شود، سازمان ها شاهد افزایش سرعت و کیفیت بدون افزایش هزینه ها خواهند بود. در حقیقت با کوتاه کردن چرخه ها، شما شاهد افزایش ارزش های کسب و کاری خواهید بود. ارزیابی و نظارت بر معیارهای بهره وری، یک چرخه‌ی بازخورد (feedback loop) برای بخش IT ایجاد می کند. بدین ترتیب تمرکز خود را بر ایجاد ویژگی هایی که مورد استفاده کاربران است می گذارید و در نتیجه اتلاف منابع کمتر صورت می گیرد و و ارزش بیزینسی افزایش می یابد.

چرا اندازه گیری و ارزیابی امنیت مهم است؟

سرعت اهمیت زیادی در DevOps دارد اما در دنیای امروزی، اهمیت امنیت هم به همین اندازه زیاد است. تیم ها باید اطمینان داشته باشند که حین عملیات، باعث آسیب پذیر شدن سیستم نمی شوند.

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

امنیت هم مثل کیفیت به رویکردهای تست shift-left نیاز دارد که با استفاده از این رویکرد مشخص کردن زود هنگام آسیب پذیری ها با هزینه های کمتر (هم از نظر زمانی هم از نظر هزینه های مالی) قابل انجام است. وقتی که تست shift-left را انجام دهید، تست امنیت در ابتدای چرخه توسعه انجام می شود. ارزیابی زود هنگام آسیب پذیری های امنیتی این اطمینان را ایجاد می کند که تولیدات قبل از این که به مرحله بعدی خط انتشار وارد شوند، پایدار و باثبات می شوند.

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

در مطلب بعد یازده شاخص کلیدی عملکرد DevOps را معرفی و بررسی خواهیم کرد.

برگرفته از “Hewlett Packard Enterprise, “Measuring DevOps success
سایر منابع :

¹Source: Forrester Consulting, “Application Delivery Speed Drives Success: How Mastering DevOps Enables Speed With Quality and Low Cost”
²–³Source: Gartner, “Survey Analysis: DevOps Adoption Survey Results,” September 2015

نوامبر 11, 2017مارس 31, 2020

AXELOS برنامه خود را جهت به روز رسانی ITIL، در کنفرانس itSMF USA Fusion 2017 اعلام کرد

به روز رسانی این چارچوب در سال 2018 صورت خواهد گرفت. با وجود هسته پایه ای از بهترین شیوه های موجود در راهنمای ITIL# ، این به روز رسانی، محتوای تمرین جدید و صریحی را با تمرکز بر ادغام بهینه ی ITIL با شیوه های تکمیلی مانند DevOps ، و Agile و Lean ارائه میدهد.

تکامل این چارچوب، از تجارب واقعی هزاران متخصص و کارشناس حاصل خواهد شد. در حال حاضر همکاران انجمن جهانی ITSM شامل برندهای بین المللی، SMEs، دولت ها، دانشگاهیان، سازمان های آموزشی و جوامع حرفه ای هستند. در حال حاضر بیش از 650 متخصص در سراسر جهان در برنامه تحقیقاتی ITIL مشارکت دارند.

‏Peter Hepworth ، مدیر عامل شرکت #AXELOS، در سخنرانی کنفرانس ItSMF USA Fusion 2017 اظهار داشت:
‏ITIL یک ابتکار عمل مبتنی بر جامعه است . من هم اکنون درحال تشویق متخصصان فناوری اطلاعات جهت پیوستن به برنامه تحقیقات جهانی خود هستم. این کار فرصتی برای همکاری خواهد بود.
تحقیقات وسیع AXELOS در میان جامعه مدیریت خدمات جهانی نشان داده است که چارچوب اثبات شده و آزمایش شده ITIL همچنان ستون فقرات شیوه های کسب و کار امروز است و به طور قابل توجهی باعث تسهیل تحول در کسب و کار می شود. بیش از یک میلیون متخصص فناوری اطلاعات در ایالات متحده به راهنمایی بهروش های ITIL برای به دست آوردن موفقیت در کسب و کار تکیه کرده اند و هر ساله سازمان ها، در اتخاذ ITIL، انطباق آن با نیازهای خود و بالا بردن مهارت هایشان با شرایط ITIL به طور قابل توجهی سرمایه گذاری می کنند. به عنوان بازتابی از این امر، این به روز رسانی شامل اصول هسته ای پذیرفته شده ITIL، که در حال حاضر ارزش واقعی را برای سازمان ها در سراسر جهان ارائه می دهد، خواهد بود.

انعطاف پذیری و چابکی در سال های اخیر تبدیل به یک اولویت شده است، زیرا سازمان ها ، فناوری ها و روش های کار جدیدی مانند cloud و سطح بالایی از اتوماسیون و تحول دیجیتال را اتخاذ می کنند. این جنبش وابسته به به روز رسانی ITIL است : این امر اطمینان حاصل خواهد کرد که متخصصان مدیریت خدمات IT در جهان با اطمینان می توانند دانش لازم ITIL خود را با این روش های کسب و کار جدید ادغام کنند.

‏Peter Hepworth ادامه داد:

“طی 18 ماه گذشته، AXELOS با صدها نفر از متخصصان در انجمن مدیریت خدمات مشغول به فعالیت بوده است. آنها تأیید کرده اند که ITIL، با چارچوب اثبات شده خود، همچنان باقی خواهد ماند. با استفاده از این به روز رسانی، می توانیم از این نقاط قوت بهره ببریم و ITIL را پاسخگو تر، شفاف تر و سریع تر کنیم. ”

این تحقیق AXELOS ، ارزشی را که این گواهی نامه ها برای متخصصان ITSM داشته اند را نشان میدهد. این گواهینامه ها به عنوان صنایع شناخته شده اند و به عنوان پیش نیاز برای بسیاری از حرفه ای های فناوری اطلاعات درنظر گرفته شده است. با این شناخت ، AXELOS اطمینان خواهد داد که شرایط فعلی ITIL در طرح جدید معتبر بماند.

‏Cathy Kirch ، رئیس شرکت itSFM ایالات متحده آمریکا، برگزار کننده FUSION 2017 و از پیشگامان چارچوب حرفه ای متخصصان مدیریت خدمات فناوری اطلاعات در ایالات متحده، اظهار داشت:
‏ITIL قوی ترین چارچوب ITSM در زیرساخت سازمان های بزرگ و پیچیده است و بسیاری از آنها و یا دست کم 500 شرکت از آن استفاده می کنند. در حال حاضر، ITIL و دیگر شیوه های تکمیلی مانند DevOps، Agile و Lean ، در ارتباط با یکدیگر به طور موفق مورد استفاده قرار می گیرند، هرچند تکامل بعدی ITIL، همکاری دینامیکی را ترویج و پایه گذاری می کند.

‏” itSMF ایالات متحده آمریکا ، این بروز رسانی را فعالانه پشتیبانی می کند. ما اهمیت تحول ITIL را به رسمیت می شناسیم: برای اطمینان از این امر که همان گونه که محیط کسب و کار با افزایش سرعت تغییر می کند، متخصصان مدیریت خدمات نیز در حال کسب مهارت های حیاتی جهت رسیدگی به فن آوری های در حال ظهور و اتخاذ شیوه های جدید هستند.”

“ما مشتاق هستیم که اعضایمان این برنامه تحقیق جهانی ITIL را پیش ببرند. این امر بستگی به نقش آنها در ایجاد ITIL برای آینده دارد، چارچوبی که پرورش متخصصان ITSM را با منابعی که در قلب دگرگونی های کسب و کار باقی بمانند، ادامه خواهد داد. ”

Ref: AXELOS website

اکتبر 29, 2017مارس 31, 2020

چارچوب CALMS در DevOps چیست و چه کمکی می کند؟

پایه و اساس DevOps ، تغییر است. Keep CALMS !

به وسیله DevOps، کسانی که با آخرین ابزارهای توسعه کار میکنند، محتاطانه عمل نمی کنند. DevOps علاوه بر افراد و فرایند ها، به ابزارها هم اهمیت می دهد و روش های مختلفی برای گرد هم آوردن این سه مجموعه در کنار هم ایجاد می کند.

کافی است تا عبارت “DevOps” را در google جستجو کنید تا دیاگرام ها و متدولوژی های بسیاری را پیدا کنید که هر کدام از آن ها جنبه ی متفاوتی را برجسته کرده اند. اما می توان گفت که همه ی آن ها در موارد زیر با هم مشترک اند:

فرهنگ سازی | Culture
خودکارسازی | Automation
تفکر ناب | Lean thinking
اندازه گیری همه چیز | Measurement
اشتراک گذاری | Sharing

به این چهار مورد اصول یا چارچوب CALMS در DevOps می گویند.

چارچوب CALMS در DevOps چیست ؟

چارچوب CALMS را می توان در پنج واژه ی فرهنگ سازی، خودکارسازی، تفکر ناب، اندازه گیری و اشتراک گذاری برشمرد. (این موضوع در برخی مطالب با عنوان “اصول CALMS در DevOps چیست” مطرح شده است که چارچوب صحیح تر است، در آینده در مطلبی جداگانه اصول DevOps را معرفی خواهم کرد)

Culture | فرهنگ

همه میدانیم فرهنگ چیزی نیست که یک نفر بتواند آن را پیاده سازی کند. فرهنگ در یک محیط طبیعی که شامل سرتاسر تیم تولید نرم افزار می شود وجود دارد. منظور از سرتاسر همه ی افراد است از جمله توسعه دهندگان (Development)، تضمین کنندگان کیفیت (QA) و تیم های عملیات (Operation) و … . در چنین اکوسیستمی که متشکل از مجموعه ای از افراد و ابزارها است، برای رفع موانع و تسهیل همکاری برای دستیابی به اهداف نهایی، یک کار فرهنگی لازم است.

هیچ چیز زشت درباره فرهنگ وجود ندارد.

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

Automation | خودکارسازی :

هنگامی که فرهنگ سازی در سازمان انجام شد، می توانید بر خودکارسازی یا اتوماسیون تمرکز کنید. اتوماسیون تنها به نوشتن Script ها و استفاده از Unit Test ها یا Functional Test ها محدود نمی شود. خودکارسازی شامل همه قسمت ها از جمله Continuous-Integration ، Continuous-Delivery/Deployment، Infrastructure-Automation و هر جای دیگری می شود.

با راه اندازی Automation می توانید برای همه چیز برنامه ریزی کنید.

فرایند های دستی بسیار کند و مستعد خطای انسانی هستند. راهی برای رهبری تمامی ابتکارات جدید به وسیله اتوماسیون پیدا کنید و برای رسیدن به مقیاس های بزرگتر به طور مستمر به اتوماسیون فکر کنید.

Lean | ناب:

بعد از راه اندازی اتوماسیون، به یاد داشته باشید که همچنان ناب بمانید و اصول تولید ناب نرم افزار را رعایت کنید.

اجرای Lean به معنی نگه داشتن همه چیز در حداقل است.

ابزارها، جلسات و حتی iteration ها و همه چیز دیگر باید Lean باشد یعنی در حداقل ممکن باشد. تفکر ناب یعنی ارزش محور بودن فعالیت ها و کاهش فعالیت های اضافه و در حداقل نگه داشتن همه چیز. این هم بخشی از فرهنگ DevOps است. وقتی شما ناب هستید، برای هر ابزار، و روشی که انتخاب می کنید، هدفی دارید.

ناب بودن تنها به یک یا چند فرد محدود نمی شود و شامل همه ی تیم ها و افراد می شود.

باید تیم را در اندازه ای نگه داشت که بیشترین کارایی را داشته باشد. یک آشپزخانه با آشپزهای بیش از حد، بازده کمی خواهد داشت. اگر پیچیدگی اپلیکیشن به گونه ای باشد که نیاز به تیم های بزرگ باشد، تیم را به زیرگروه های کوچکتر تقسیم کنید، همانطور که سازمان های بزرگ این کار را می کنند. (spotify یکی از موفق ترین مثال ها در این زمینه است)

Measurement | اندازه گیری :

اندازه گیری مانند چسبی است که همه چیز را در کنار هم قرار می دهد. زمانی شما یک سازمان چابک و ناب هستید که همه چیز را اتوماتیک می کنید، ممکن است که توانایی به خاطر سپردن و مستند سازی را از دست بدهید.

اگر تیمی در همه موارد شفافیت لازم را نداشته باشد و کارها اندازه گیری نشوند، در نهایت اشتباهات بزرگی رخ خواهد داد.

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

با این وجود نمی توانید با یک excel ساده این کار را انجام داد. در یک سازمان ناب، شما فرصت ندارید که همه چیز را به صورت دستی و غیر اتوماتیک ثبت کنید. این کار بسیار زمان گیر و مستعد خطای انسانی است.

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

Sharing | به اشتراک گذاری :

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

ایجاد جریان اطلاعات دوطرفه یکی از مزیت های شکستن دیوار بین تیم ها می باشد و باعث جلوگیری از انداختن توپ در زمین تیم دیگر می شود. با این وجود اگر اطلاعات به صورت proactive و فعالانه به اشتراک گذاشته نشوند، ارزشی نخواهند داشت.

Sharing و Reporting کاملا با هم متفاوت هستند، Sharing تنها گزارش واقعیات نیست، بلکه مبادله ی ایده ها در سر تا سر تیم ها و به طور دائمی است. Reporting معمولا به صورت انفعالی (reactive) اتفاق می افتد در حالی که Sharing به صورت فعالانه و proactive می باشد.

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

چارچوب CALMS در DevOps برای آزادسازی خلاقیت ها است نه ردیابی عملکرد افراد

تمامی جریان های DevOps از جمله CALMS، مانند یک نقشه راه هستند، نه تعریف تمامی گام های لازم برای رسیدن به هدف. اگر با راهنما پیش بروید، حتما به هدف خواهید رسید، هر چند با راهکارها و گام های متفاوت.

چیزی که در توصیف CALMS از DevOps منحصر به فرد است، تاکید بر بعد فرهنگی DevOps است.

از CALMS برای رها سازی جهت بروز خلاقیت ها استفاده کنید، نه برای ردیابی عملکرد افراد

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

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

برخی از موارد که در چارچوب CALMS به آن اشاره نشده است

داشتن iteration و ضرب آهنگ منظم و همچنین نتیجه گرا بودن، از موارد مهمی هستند که در CALMS به آن ها اشاره نشده است و می تواند مکمل CALMS باشند. از موارد دیگری که در CALMS به آن اشاره نشده، Security و امنیت محصول است، اما قطعا DevOps امنیت محصول را بهبود می دهد. تمامی موارد اشاره شده شامل بعد فرهنگی و فناوری می باشند.

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

این تمرین مهم است نه به این دلیل که CALMS باید به یک استاندارد تبدیل شود یا نه، به این دلیل که زمانی که جنبش های جدیدی به وجود می آیند (مانند جنبش DevOps)، باید مسیری از عادت به عملکرد فعالانه وجود داشته باشد. CALMS به کسانی که با Operations زندگی کرده اند و همچنین کسانی که حتی نمی دانند Operations چیست کمک می کند.

تفاوت CALMS و ITSM

کسانی است که با ITSM آشنایی دارند ممکن است دچار این چالش ذهنی بشوند که تفاوت DevOps و ITSM چیست؟ آیا DevOps یک راهکار جایگزین برای ITSM است؟

اگر با مشاهده مثال ها و اسناد ITSM تفاوت ها به وضوح مشخص نبود، کلمه ی اختصاری CALMS در یک نگاه سریع به تشریح تفاوت های این روش ها کمک می کند. همانطور که مشاهده می کنید، فرهنگ اولین گام است، با مشاهده گزینه های بعدی، به سرعت مشخص می شود که نمی توان هیچ مقایسه ی مورد به موردی برای ITSM و DevOps داشت.

ITSM به طور کلی بر مستندسازی، کنترل تغییرات، و تکرارپذیری تمرکز دارد، در حالی که DevOps بر افرادی که این نتایج را بدیت می آورند تمرکز دارد. یک مولفه اصلی در ITSM، تکرارپذیر بودن است، اما ساختار و فرایند ها اهداف اصلی نیستند.

جولای 23, 2017مارس 31, 2020

استراتژی پیشرفته استقرار نرم افزار | Advanced Software Deployment Strategy

در این مطلب قصد دارم به استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد فراوانی دارند، بپردازم. در پست قبلی به تعریف استراتژی و استراتژی استقرار نرم افزار پرداختیم، همچنین دو تا از استراتژی های پایه استقرار نرم افزار (Recreate Deployment و Rolling Deployment) را معرفی و بررسی کردیم.

Blue-Green Deployment Strategy

Blue-Green Deployment یکی دیگر از استراتژی های استقرار است که به طور خلاصه شامل نگه داشتن همزمان دو نسخه از سرویس در محیط عملیاتی می شود که ریسک انتشار را به شدت کم می کند. نسخه قبلی (Blue) و نسخه ای که جدیدا منتشر شده و در دسترس قرار گرفته (Green). این روش معمولا از یک load balancer برای هدایت ترافیک به نسخه ی green می شود. اگر Monitoring یک رخداد (Incident) را شناسایی کرد، ترافیک به طور اتوماتیک به نسخه ی قبلی یعنی blue هدایت خواهد شد.

هدف Blue-Green Deployment ، حذف DownTime و کاهش ریسک های ناشی از Deployment وامکان Rollback بسیار سریع است.

روش انجام Blue-Green Deployment: در این روش علاوه بر محیط عملیاتی (سبز)، یک محیط کاملا مشابه اما جداگانه وجود دارد(آبی). نسخه ی قدیم اپلیکیشن در محیط سبز نصب شده و 100% از ترافیک عملیاتی به این محیط هدایت می شود. نسخه ی جدید اپلیکیشن روی محیط آبی نصب، راه اندازی و تست می شود، سپس در یک لحظه 100% از ترافیک عملیاتی به محیط آبی هدایت می شود. در این روش در هر زمان تنها یکی از نسخه ها عملیاتی است و نسخه ی دیگر غیر فعال است.

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

مثال: شکل زیر نشان دهنده ی این استراتژی به صورت کلی است.
مرحله اول: 100% ترافیک عملیاتی به محیط آبی که نسخه ی قدیمی در آن نصب شده هدایت می شود و نسخه ی جدید در محیط آبی نصب و راه اندازی می شود.
مرحله دوم: بعد از راه اندازی کامل نسخه ی جدید در محیط آبی، 100% ترافیک عملیاتی به محیط آبی هدایت می شود.

استراتژی قناری | Canary Deployment Strategy

انتخاب این نام از داستان “قناری در معدن زغال سنگ” گرفته شده است. در گذشته معدنچیان با خود یک قناری در قفس به معدن می بردند، در چنین شرایطی اگر میزان گازهای سمی (متان یا مونو اکسید کربن) در معدن به حدی برسد که برای انسان خطر جدی ایجاد کند، قناری جان خود را از دست می داد و بدین ترتیب معدن چیان از وجود گازهای سمی باخبر می شدند.

روش انجام Canary Deployment: در استراتژی استقرار به روش قناری، نسخه ی جدید اپلیکیشن روی تعداد کمی از نودهای عملیاتی منتشر می شود و درصد کمی از ترافیک عملیاتی به نسخه ی جدید هدایت می شود. در این روش دو نسخه قدیم و جدید به طور همزمان عملیاتی هستند. نسخه ی جدید، نقش یک قناری را بازی می کند تا بدون اینکه ریسکی متوجه اکثریت کاربران شود، متوجه شویم که وضعیت در عملیات چطور خواهد بود (از نظر integration با سایر اپلیکیشن ها، CPU، Mamory، disk Usage و …). در صورت رضایت بخش بودن می توان سایر نود ها را هم به روزرسانی کرد، در غیر اینصورت می توان تصمیم به fail کردن استقرار یا Rollback گرفت.

استراتژی قناری بر اساس این واقعیت به وجود آمده است که با وجود همه ی تست هایی که در محیط های قبلی انجام شده، باز هم ممکن است تعدادی باگ ها به عملیات منتقل شود. در این صورت و با استفاده از این روش، تعداد کمتری از کاربران با باگ مواجه می شوند و با دریافت سریع بازخوردها می توان تصمیم به Fail کردن استقرار یا Rollback گرفت تا برای اکثریت کاربران ریسکی ایجاد نشود.

Dark Launch Strategy

Dark launching فرایندی است که در آن Featureهای جدید نرم افزار به نحوی تدریجی یا مخفیانه ریلیز می شود و در یک زمان مشخص، یا برای گروه های کاربری مشخصی، فعال و قابل استفاده می شود. با این روش می توان بازخورد بخشی از کاربران را دریافت کرد و در محیط عملیاتی بدون اینکه اکثر کاربران تحت تاثیر قرار گیرند، Performance Test انجام داد. با این روش دیگر نیازی نیست که انتشار Feature های تکمیل شده به دلیل یک یا چند Feature تکمیل نشده به تعویق بیافتد و می توان کدهای تکمیل نشده را (با در نظر گرفتن ملاحظاتی) بدون تاثیر در عملکرد کلی اپلیکیشن منتشر کرد.

روش انجام Dark Launch Strategy: این کار با به کارگیری یک تکنیک در توسعه نرم افزار به نام Feature Flag یا Feature Toggle انجام می شود. در این تکنیک، پیکربندی هایی برای هر Feature یا مجموعه ای از آن ها افزوده می شود، همچنین تکه کدهایی در ابتدای هر ویژگی استفاده می شود که با توجه به پیکربندی، آن ویژگی را در زمان خاصی، یا برای گروهی از کاربران فعال می کند.

Google، Facebook، و بسیاری از غول های فناوری اطلاعات برای ریلیز تدریجی و تست ویژگی های جدید توسط گروه کوچکی از کاربرانشان، از Dark Launching استفاده می کنند. بدین ترتیب قبل از ریلیز عمومی، این فرصت را پیدا می کنند تا میزان علاقه ی کاربران را شناسایی کنند و همچنین تاثیر تغییرات جدید را روی کارایی کل سیستم اندازه گیری کنند. ابزاری که Facebook برای این کار استفاده می کند، “Gatekeeper” نام دارد.

A/B Deployment Strategy

به این معنی است که دو (یا چند) نسخه مختلف از اپلیکیشن/کانفیگ به طور همزمان به منظور تست در حال اجرا باشند. آسان ترین راه استفاده از این روش، تقسیم ترافیک عملیاتی بین دو شاخه همگن (شاخه A و شاخه B) می باشد به طوری که در شاخه A، نسخه ی یکسانی از اپلیکیشن و کانفیگ ها وجود داشته (نسخه A) باشد و در نودهای شاخه ی دیگر، یک نسخه ی دیگر (نسخه B).

یک مثال پیچیده تر شامل یک proxy یا load-balancer تخصصی که ترافیک را بر اساس کاربران یا اپلیکیشن ها بین شاخه های A و B تقسیم می کند. تمامی تستر ها به شاخه B هدایت می شوند و سایر کاربران به شاخه A.

A/B Deployment می تواند به عنوان A/B Testing در نظر گرفته شود، اگر چه یک استقرار A/B نشان دهنده چندین نسخه از کد و پیکربندی است، در صورتی که A/B Testing اعلب از یک کد با چک های خاص برنامه تشکیل شده است.

چه موقع از A/B Deployment استفاده کنیم ؟

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

جولای 10, 2017مارس 31, 2020

استراتژی استقرار نرم افزار | Software Deployment Strategy

در این مطلب به ابتدا به تعریف استراتژی (Strategy)، استقرار نرم افزار (Software Deployment) اشاره شده و در ادامه دو تا از استراتژی های پایه استقرار نرم افزار معرفی و بررسی شده است.

در این صفحه به مطالب زیر می پردازیم :

استراتژی چیست ؟ | What is Strategy ?
دیپلویمنت چیست ؟ | What is Deployment ?
استقرار نرم افزار | Software Deployment
استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ?
اهداف استراتژی های استقرار نرم افزار کدامند ؟
معایب استقرار به روش های قدیمی چیست ؟
رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟
Immutable Server چیست ؟
استراتژی های پایه استقرار نرم افزار
- Recreate Deployment Strategy
  - چه موقع از Recreate Deployment استفاده کنیم ؟
- Rolling Deployment Strategy
  - چه موقع از Rolling Deployment استفاده کنیم ؟

در مطلب بعدی موارد زیر معرفی و بررسی خواهند شد

استراتژی های پیشرفته استقرار نرم افزار
- Canary Deployment Strategy
- Blue-Green Deployment Strategy
- Dark Launch Strategy
- A/B Deployment Strategy

استراتژی چیست ؟ | What is Strategy ?

تعاریف مختلفی از استراتژی وجود دارد اما به نظرم سه تعریف زیر در کنار هم دید خوبی از مفهوم استراتژی به ما می دهد.

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

همانطور که از تعاریف مشخص است، استراتژی برنامه ای با جزئیات دقیق و کاملا قابل پیش بینی نیست. تاکید یک استراتژی خوب بر آن است که در برخی از توانایی های رقابتی خاص پیشرفت حاصل شود. برای دستیابی و رسیدن به اهداف یک استراتژی، نیاز است برنامه هایی (Plans) قابل پیش بینی و با جزئیات، تعریف و اجرا شود.

دیپلویمنت چیست ؟ | What is Deployment ?

دیپلویمنت یعنی گسترش دادن، استفاده، یا سازماندهی برای رسیدن آگاهانه به یک هدف. (Merrian Webster – Definition of Deploy)

استقرار نرم افزار چیست ؟ | What is Software Deployment ?

Software Deployment یا استقرار نرم افزار شامل تمام فعالیت هایی است که یک نرم افزار را برای استفاده ی کاربران نهایی آماده می کند. از آنجایی که هر سیستم نرم افزاری شرایط و ویژگی های منحصر به فردی دارد، فرایند ها و روش های استقرار آن باید به طور خاص و دقیق برای همان سیستم تعریف شود. بنابراین استقرار نرم افزار، یک فرایند کلی است که باید با توجه به شرایط و خصوصیات هر سیستم نرم افزاری به صورت دقیق تعریف شود. (ویکی پدیا)

(در ادامه ی این متن، از واژه ی “استقرار” به جای “Software Deployment” یا “استقرار نرم افزار” استفاده شده است.)

استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ؟

Software Deployment Strategy یا استراتژی استقرار نرم افزار، یک استراتژی در جهت گسترش، استفاده، و یا سازماندهی، برای استقرار به صورت آگاهانه است. به عبارت ساده تر فرایندی است که نحوه ی استقرار و پیکربندی اپلیکیشن و سرورها را مشخص می کند. هر اپلیکیشن یا سرور برای استقرار، نیازمندی ها و ملاحظات متفاوتی دارد که برای انجام آن باید از یک استراتژی مناسب استفاده کرد. از جمله این نیازمندی ها می توان به دسترس پذیری اپلیکیشن، مدت زمان استقرار و بسیاری موارد دیگر اشاره کرد.

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

اهداف استراتژی های استقرار نرم افزار کدامند ؟

از جمله اهدافی که استراتژی های استقرار به دنبال دستیابی به آن ها هستند، می توان به این موارد اشاره کرد:

به حداقل رساندن DownTime یا به صفر رساندن آن
کاهش ریسک ناشی از استقرار
کاهش ریسک عملیاتی کردن نسخه ی جدید
شناسایی سریع مشکلات نسخه ی جدید بعد از عملیاتی شدن
سرعت بخشیدن به امکان Rollback به نسخه ی قبلی

معایب استقرار به روش های قدیمی چیست ؟

استفاده از روش های استقرار قدیمی و غیر اتوماتیک در نگهداری سرور ها و استفاده از آن ها برای مدت زمان طولانی (چندین ماه یا چند سال) باعث مشکلات زیادی می شود. حتی اگر شما تمامی patch ها و update ها را به درستی روی سرور و اپلیکیشن نصب کرده باشید، بعد از مدتی با یک سرور حساس و شکننده با پیکربندی منحصر به فرد مواجه خواهید شد که نمی توانید آن را تعویض کنید یا سروری مشابه آن ایجاد کنید. (به چنین سروهایی در اصطلاح “Snowflake Servers” می گویند). دلایل مختلفی وجود دارد که نیاز می شود یک سرور جدید راه اندازی کنید، از جمله تغییر دیتاسنتر، اضافه کردن سرورهای fail-over، اضافه کردن سرور برای مقیاس پذیری بیشتر، مشکلات امنیتی و … که در چنین شرایطی امکان آن وجود نخواهد داشت یا با ریسک بسیار بالا و صرف زمان زیادی همراه خواهد بود.

رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟

از اصطلاح Configuration Drift یا “رانش پیکربندی” مواقعی استفاده می شود که تغییرات پیکربندی به صورت موردی، با توجه کم و بدون مستند سازی روی سرورها اعمال می شود عملا سرور را به یک سرور منحصر به فرد تبدیل می کند که محدودیت ها و مشکلاتی را به همراه خود دارد.

برخی از این مشکلات که در بالا اشاره شد، با به کار گیری ابزارهای مدیریت پیکربندی نظیر Chef و Puppet و Ansible برطرف می شوند. اگر پیکربندی ها با استفاده از این ابزارها انجام شود، از پدیده ی Configuration Drift جلوگیری می شود. اما نکته ی مهم این است که در این روش تنها پیکربندی هایی که صراحتا از طریق ابزار اعمال شده انجام خواهد شد و اگر مواردی خارج از آن به محیط یا سرور اعمال شود، ابزار مطلع نمی شود.

Immutable Server چیست ؟

استراتژی ای وجود دارد که در آن به صورت دوره ای سرورها را حذف مب کنند و یک سرور جدید به جای آن ایجاد می کنند و با استفاده از ابزارهایی که در بالا معرفی شد، به صورت اتوماتیک، پیکربندی می کنند. این کار باعث جلوگیری از Configuration Drift می شود. با این روش، با هر تغییر در پیکربندی، بلافاصله قادر به راه اندازی یک سرور جدید خواهیم بود. این استراتژی با نام Immutable Server شناخته می شود از رانش پیکربندی و Snowflake Server ها جلوگیری می کند. از این استراتژی می توان در کنار Recreate Deployment Strategy که در ادامه توضیح خواهم داد استفاده کرد.

انواع استراتژی استقرار نرم افزار | Deployment Strategies

در ادامه به معرفی استراتژی های پایه استقرار نرم افزار می پردازیم. در مطلب بعدی “استراتژی های پیشرفته استقرار نرم افزار” را بررسی خواهم کرد. لازم به ذکر است که این استراتژی ها را می توان با هم ترکیب کرد و استراتژی جدیدی ایجاد کرد. در ادامه مطالب زیر بررسی خواهد شد :

استراتژی های پایه استقرار نرم افزار
- Recreate Deployment Strategy
  - چه موقع از Recreate Deployment استفاده کنیم ؟
- Rolling Deployment Strategy
  - چه موقع از Rolling Deployment استفاده کنیم ؟
استراتژی های پیشرفته استقرار نرم افزار (در پست بعدی معرفی و بررسی خواهند شد)
- Canary Deployment Strategy
- Blue-Green Deployment Strategy
- Dark Launch Strategy
- A/B Deployment Strategy

Recreate Strategy | Recreate Deployment

استراتژی Recreate Deployment یکی از استراتژی های پایه استقرار نرم افزار می باشد. روش انجام این استراتژی دقیقا شبیه به زمانی است که یک اپلیکیشن برای اولین بار نصب و راه اندازی می شود. همه چیز مرحله به مرحله و از ابتدا باید انجام شود. همچنین نیازی نیست که کدهای جدید و قدیم در کنار هم کار کنند.

این استراتژی به دلیل اینکه در یک بازه زمانی هیچ نمونه ای از اپلیکیشن در حال اجرا و سرویس دهی نیست، منجر به DownTime خواهد شد. درنتیجه برای محیط های عملیاتی مناسب نیست.

چه موقع از Recreate Deployment استفاده کنیم ؟

زمانی که قبل از راه اندازی نسخه ی جدید، نیاز است یک مهاجرت ( Migration ) در سطح دیتا یا سرور انجام شود
زمانی که نیازی نیست تا نسخه های جدید و قدیم اپلیکیشن به طور همزمان با هم کار کنند
زمانی که از یک RWO volume ای استفاده می کنید که قابلیت به اشتراک گذاری بین چند نسخه را ندارد [openshift.org]

مثال: در شکل زیر مراحل انجام این روش برای محیطی با سه نود نمایش داده شده است.

مرحله اول: قبل از شروع کار، ترافیک به سرور که نسخه ی قدیمی اپلیکیشن را دارد، هدایت می شود.

مرحله دوم: تمامی نود ها از مدار خارج می شود و دیگر ترافیک عملیاتی به سمت آن هدایت نمی شود و سپس به روزرسانی می شوند. در این زمان DownTime خواهیم داشت.

مرحله سوم: همه ی نودها به روزرسانی شده اند و به مدار باز میگردند.

Rolling Strategy | Rolling Deployment

Rolling Deployment یکی دیگر از استراتژی های پایه استقرار نرم افزار است و هدف آن به حداقل رساندن یا حذف DownTime و کم کردن ریسک های وابسته به استقرار می باشد. Rolling Deployment برای محیط هایی عملیاتی که نیاز است به روزرسانی در آن ها بدون DownTime انجام شود، مناسب است. این استراتژی معمولا در محیط هایی با تعداد نود(سرور)های زیاد به کار گرفته می شود و برخلاف برخی دیگر از استراتژی ها نیاز به منابع اضافه ندارد و با استفاده از سرورها و منابع جاری قابل اجرا است.

روش انجام Rolling Deployment : در این روش یکی از (یک گروه از) نودها از دسترس خارج شده و نسخه ی جدید اپلیکیشن با نسخه ی قبلی جایگزین می شود، سپس ترافیک عملیات به آن هدایت می شود و نوبت به نود بعدی می رسد. این کار تا به روزرسانی همه ی نود ها ادامه می یابد.

مثال: در شکل زیر مراحل انجام این استراتژی برای محیطی با سه نود (سرور) نشان داده شده است. این مثال یک محیطی با عملیاتی است که ترافیک ورودی توسط یک Router یا Load-Balancer به سرورهای مشابه هدایت می شوند.

مرحله صفر : قبل از شروع کار، ترافیک به هر سه سرور که نسخه ی قدیمی اپلیکیشن را هاست کرده اند، هدایت می شود.

مرحله اول: یکی از نود ها از مدار خارج می شود و از آن پس ترافیک عملیاتی به سمت آن هدایت نمی شود. در همین حین نودی که از مدار خارج شده، به روزرسانی می شود.

مرحله دوم: نودی که به روزرسانی شده به مدار باز میگردد و نود دیگری از مدار خارج و به روزرسانی می شود.

مرحله سوم: مرحله دوم برای تمامی نودهای باقیمانده (در اینجا یک نود) تکرار می شود.

مرحله چهارم: در این مرحله تمامی نودها به مدار بازگشته و ترافیک به آن ها هدایت می شود.

چه موقع از Rolling Deployment استفاده کنیم ؟

زمانی که میخواهیم در حین استقرار یا به روزرسانی اپلیکیشن، DownTime نداشته باشیم
زمانی که اپلیکیشن می تواند به طور همزمان با نسخه ی جدید و قدیم کار کند

استفاده از این روش به این معنی است که اپلیکیشن باید بتواند با نسخه ی قدیم و جدید به طور همزمان کار کند. در این روش ممکن است دیتایی توسط نسخه ی جدید ذخیره شود و توسط نسخه ی قدیمی خوانده شود (و بالعکس). در نتیجه اپلیکیشن باید به گونه ای طراحی شده باشد تا بدون اینکه مشکلی پیش بیاید این کار را انجام دهد. این موضوع در جاهای مختلفی باید رعایت شود، از جمله برای دیتاهایی که در فایل ذخیره می شوند، دیتاهایی که در پایگاه داده ذخیره می شوند، دیتاهایی که به طور موقت در cache ذخیره می شوند، یا دیتاهایی که سمت کلاینت و در مرورگر کاربران ذخیره می شوند. نکته ای بسیار مهم که در به کارگیری این روش وجود دارد این است که اپلیکیشن برای این کار تست باید طراحی و تست شده باشد.

جمع بندی

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

امیدوارم این مطب مورد استفاده شما دوستان واقع شده باشه. در مطلب بعدی که سعی میکنم کمتر از یک هفته دیگه منتشر کنم، استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد دارند را بررسی خواهم کرد.