diff --git a/docs/devops/01-linux.md b/docs/devops/01-linux.md new file mode 100644 index 00000000..7e7dcd3e --- /dev/null +++ b/docs/devops/01-linux.md @@ -0,0 +1,216 @@ +--- +title: Linux +description: '' +--- + +![Tux - Linux mascot](./images/01-Tux.svg) + +لینوکس سیستم‌عاملی متن‌باز +(Open Source) +و رایگان است که به ثبات، امنیت و تطبیق‌پذیری بالا شهرت دارد. این سیستم‌عامل در سال 1991 توسط لینوس تروالدز که در آن زمان دانشجوی دانشگاه هلسینکی فنلاند بود ساخته شد. تروالدز در ابتدا این پروژه را به عنوان یک سرگرمی آغاز کرد ولی رفته‌رفته این پروژه رنگ و بوی جدی تر شدن به خود گرفت و تبدیل به یکی از بهترین و پرکاربردترین سیستم‌عامل‌های جهان شد. +به دلیل متن‌باز بودن این سیستم‌عامل که توسط جامعه اینترنتی مورد استقبال قرار گرفته بود؛ به تدریج توزیع‌های مختلفی از سوی کامیونیتی‌های مختلف برای آن عرضه شد که از جمله آن‌ها می‌توان به اوبونتو +(Ubuntu)، +فدورا +(Fedora)، +دبین +(Debian) +و ... اشاره کرد که هرکدام از آن‌ها ویژگی‌های مخصوص به خود را داشته و از جهاتی بر دیگر توزیع‌ها برتری دارند. +امروزه سیستم‌عامل لینوکس در طیف وسیعی از کاربرد‌ها از رایانه‌های شخصی و سرورها گرفته تا سیستم‌های نهفته +(Embedded Systems) +و تلفن‌های همراه استفاده می‌شود. استفاده گسترده از این سیستم‌عامل در حوزه مهندسی نرم‌افزار باعث می‌شود تا آشنایی با آن از الزامات ورود به دنیای مهندسی نرم‌افزار و باشد. + +:::info اطلاعات بیشتر +معمولا لینوکس را با نام گنو/لینوکس می‌شناسند زیرا لینوکس به تنهایی +یک هسته سیستم‌عامل است و در کنار ابزارهای گنو استفاده می‌شود. برای فهم بهتر این نام و +آشنایی بیشتر با تاریخ این سیستم‌عامل می‌توانید به +[کتاب لینوکس و زندگی](https://linuxbook.ir/chapters/gnulinuxhistory.html) +مراجعه کنید. +::: + +## ساختار سلسله مراتبی فایل‌سیستم لینوکس + +در سیستم‌عامل لینوکس استاندارد سلسله‌مراتبی فایل‌سیستم +(Filesystem Hierarchy Standard) +ساختار دایرکتوری‌ها را تعیین می‌کند. بدین شکل که فایل‌سیستم را می‌توان به درختی وارونه تشبیه کرد که یک ریشه داشته و تعدادی شاخه از آن خارج شده است. هر کدام از این شاخه‌ها یک دایرکتوری است که به ذخیره دسته خاصی از اطلاعات و فایل‌ها اختصاص یافته. این ساختار به صورت خلاصه در تصویر زیر قابل مشاهده است. +برای آشنایی بیشتر و عمیق‌تر با این ساختار می‌توانید از منبع زیر +استفاده کنید: + +- [Linux File Hierarchy Structure](https://www.geeksforgeeks.org/linux-file-hierarchy-structure/) + +![Linux Hierarchy Standard Picture](./images/01-linux-filesystem-hierarchy-standard.jpg 'Linux Hierarchy Standard Picture') + +## دستورات شل + +شل یا محیط خط فرمان لینوکس نرم‌افزاری است که به کاربران اجازه می‌دهد تا از یک طریق خط فرمان +(Command Line Interface) +با سیستم عامل لینوکس +تعامل کنند. با استفاده از ترمینال لینوکس، کاربر می‌تواند دستورات مختلفی را به سیستم عامل ارسال کرده و اعمال مختلفی مانند مدیریت فایل‌ها و پوشه‌ها، نصب و پاک کردن برنامه‌ها، کنترل کاربران و دستگاه‌های جانبی و… را انجام دهد. +با وجود اینکه در محیط گرافیکی لینوکس می‌توانیم همانند ویندوز با ماوس و کیبورد کار کنیم ولی خط فرمان لینوکس با حذف پیچیدگی‌های گرافیکی به ما اجازه می‌دهد که تمام کارهای خود را با نوشتن دستورات متنی انجام دهیم. با استفاده از خط فرمان می‌توانیم به طور مستقیم و با سرعت بالا با سیستم‌عامل در ارتباط بوده و با سرعت و جزئیات بیشتر به تمام دستورات دسترسی داشته باشیم. +برای آشنایی با مهم‌ترین دستورات ترمینال لینوکس می‌توانید به به منابع زیر مراجعه کنید. + +- [25 Basic Linux Commands For Beginners](https://www.geeksforgeeks.org/basic-linux-commands/) +- [60 Essential Linux Commands](https://www.hostinger.com/tutorials/linux-commands) (نیازی به تسلط بر روی تمامی این دستورات نیست اما خوب است که آن‌ها را بشناسید.) + +:::info اطلاعات بیشتر +در زمان اجرای شل، متغیرهای خاصی از پیش تعریف شده‌اند که اطلاعات مفیدی از جمله نام کاربری، مسیر فعلی و ... را در اختیار ما قرار می‌دهند. یکی از این متغیرها، متغیر +`$PATH` +است. این متغیر به شل می‌گوید که برای پیدا کردن فایل اجرایی یک دستور خاص باید چه دایرکتوری‌هایی را جست‌وجو کند. +::: + +## کنترل نحوه اجرای دستورات + +گاهی اوقات ممکن است که +بخواهیم یک دستور را به شرط اجرا یا اجرا نشدن یک دستور دیگر اجرا کنیم و یا خروجی یک دستور +را به عنوان ورودی به یک دستور دیگر بدهیم. +یکی از ویژگی‌های کاربردی خط فرمان لینوکس، که برای پاسخگویی به این نیاز طراحی شده، امکان کنترل نحوه اجرای دستورات است. برای آشنایی بیشتر با این قابلیت که به آن +Command Chaining +می‌گویند، می‌توانید از این منابع استفاده کنید: + +- [Chaining Commands in Linux](https://www.geeksforgeeks.org/chaining-commands-in-linux/) +- [Working with pipes on the Linux command line](https://www.redhat.com/sysadmin/pipes-command-line-linux) + پس از مطالعه منابع ذکر شده، سعی کنید با اجرای چندین دستور به شکل‌های مختلف، چیزهایی + که آموختید را تست کنید. + +## کنترل دسترسی توسط ترمینال + +یکی از مهم‌ترین نیازمندی‌های هر سازمانی امنیت اطلاعات است. لینوکس برای +مدیریت دسترسی به فایل‌هایی که بر روی دستگاه وجود دارد به ما اجازه می‌دهد که +برای هر فایل یک صاحب و یک گروه تعیین کرده و دسترسی‌های مختلفی را برای +صاحب فایل، گروه فایل و بقیه کاربران مشخص کنیم. به کمک این ویژگی می‌توانیم با ایجاد محدودیت‌هایی برای کاربران از سواستفاده آن‌ها از فایل‌ها و پوشه‌ها جلوگیری کنیم. برای آشنایی بیش‌تر با این امکان به +[Linux chmod and chown – How to Change File Permissions and Ownership in Linux](https://www.freecodecamp.org/news/linux-chmod-chown-change-file-permissions/) +مراجعه کنید. + +## نصب، بروزرسانی و حذف پکیج‌های خارجی در لینوکس + +معمولا در ابتدای نصب سیستم عامل لینوکس، بعضی از ابزار پرکاربرد نیز همراه با آن نصب می‌شوند تا به نیازهای کاربر پاسخ دهند اما هر کاربر متناسب با نیازهای خود به ابزارهایی نیاز دارد که لزوما پیش از این روی سیستم عامل نصب نشده اند. از این رو نیاز داریم که این پکیج‌ها را از طریق +Package manager +نصب و مدیریت کنیم. توزیع‌های مختلف از +Package manager +های منحصر به‌فردی استفاده می‌کنند. برای آشنایی مختصر با هر یک از این +Package managerها +و نحوه کار با آن‌ها می‌توانید از منبع زیر استفاده کنید: + +- [Understanding Package Managers and systemctl](https://www.geeksforgeeks.org/understanding-package-managers-and-systemctl/) + +## ویرایش فایل‌های متنی + +در زمان استفاده از یک سیستم‌عامل ممکن است به ایجاد یا تغییر فایل‌های متنی نیاز پیدا کنیم. در این مواقع است که نقش ویرایشگرهای فایل‌های متنی یا +Text Editor +پررنگ‌تر می‌شود. در سیستم‌عامل لینوکس طیف وسیعی از ویرایشگرهای متن وجود دارد که بر حسب نیاز و سلیقه می‌توانید آن‌ها را انتخاب کرده و استفاده کنید. از معروف‌ترین ویرایشگر‌های متن موجود برای سیستم‌عامل‌های مبتنی بر لینوکس می‌توان به +Vim, Emacs +و +Nano +اشاره کرد که به علت پیچیدگی نسبی ویرایشگرهای +Vim و Emacs +در اینجا تنها به توضیح ویرایشگر +Nano +بسنده می‌کنیم. +ویرایشگر +nano، +یک ویرایشگر رایگان، متن‌باز و مبتنی بر خط فرمان +(Command Line) +است که در ایجاد و ویرایش فایل‌های متنی به ما کمک می‌کند. +با استفاده از منبع زیر، این ویرایشگر را نصب کرده و با قابلیت‌های آن آشنا شوید: + +- [How to Install and Use Nano Text Editor: A Beginner’s Tutorial](https://www.hostinger.com/tutorials/how-to-install-and-use-nano-text-editor) + +# اسکریپت نویسی + +تا اینجای کار، با دستورات خط فرمان آشنا شده و کاربرد‌ها و قابلیت‌های آن‌ها را شناختید. گاهی لازم است یک فعالیت تکراری که شامل تعداد زیادی دستور است را در زمان‌های مختلفی اجرا کنیم. +در این مواقع می‌توانیم این دستورات را به صورت یک اسکریپت نوشته و اجرا کنیم. اسکریپت مجموعه‌ای از دستورات خط فرمان است که در یک فایل نوشته شده‌اند و قابلیت اجرا شدن دارند. + +## Shebang + +اسکریپت‌هایی که برای اجرا در شل می‌نویسیم مانند بقیه فایل‌های تکست هستند. برای همین برای +اجرای آن‌ها نیاز داریم که به خط فرمان بگوییم باید به چه زبانی اجرا شوند. +برای انجام این کار از دستور خاصی که به +Shebang +معروف است استفاده می‌کنیم. +Shebang +که با کاراکترهای +`#!` +نمایش داده می‌شود، +به شلی که فایل تکست را اجرا می‌کند می‌گوید که این فایل باید بوسیله چه ابزاری اجرا شود. برای مثال اگر بخواهیم اسکریپتی که نوشته‌ایم با شل +Bash +اجرا شود، می‌توانیم اسکریپت خود را اینگونه بنویسیم: + +```shell +#!/bin/bash +echo "Hello, CodeStar!" +``` + +:::tip نکته +شل‌ها برای پیدا کردن فایل اجرایی مشخص شده در +Shebang +تنها از آدرس‌های دقیق استفاده می‌کنند. در سیستم‌های مختلف ممکن است که آدرس فایل اجرایی شلی که برای اجرای اسکریپت +استفاده می‌شود متفاوت باشد. برای مثال +ممکن است آدرس شل +Bash +در یک سیستم +`/bin/bash` +و در سیستم دیگر +`/usr/bin/bash` +باشد. برای سازگاری اسکریپت‌هایمان با این آدرس‌های مختلف می‌توانیم از +`env` +که معمولا در آدرس +`/usr/bin/env` +قرار دارد استفاده کنیم. این دستور با خواندن مقدار +`$PATH` +می‌تواند دستور دلخواه ما را از آدرس صحیح پیدا کرده و اجرا کند. + +```shell +#!/usr/bin/env bash +echo "Hello, CodeStar!" +``` + +::: + +## آرگومان‌ها و متغیرها + +### متغیرها + +در شل برای تعریف متغیر ابتدا نام آن متغیر را نوشته و سپس با گذاشتن علامت مساوی مقدار مورد نظر +آن متغیر را تعریف می‌کنیم. همچنین برای خواندن متغیرها علامت +`$` +را در ابتدای نام آن‌ها قرار می‌دهیم. +برای مثال: + +```shell +name="CodeStar" +echo "Hello, $name!" +``` + +### آرگومان‌ها + +در هر اسکریپت می‌توان از آرگومان‌هایی که هنگام اجرای اسکریپت به آن داده می‌شود استفاده کرد. نکته قابل توجه آن است که متغیر 0 به صورت پیش‌فرض برابر با نام اسکریپت اجرا شده تعریف شده است. + +![Shell Arguments Table Picture](./images/01-linux-shell-arguments-table-picture.png 'Shell Arguments Table Picture') + +## عبارات شرطی + +همانند زبان‌های برنامه‌نویسی در اسکریپت‌نویسی نیز می‌توان از عبارات شرطی استفاده کرد و بنابر شرایط مختلفی که ممکن است در هنگام اجرای یک اسکریپت به وجود بیاید؛ تصمیمات مختلفی گرفت. + +![Shell Conditional Expressions Picture](./images/01-linux-shell-conditional-expressions-picture.png 'Shell Conditional Expressions Picture') + +## حلقه + +علاوه بر عبارات شرطی، حلقه‌ها نیز در اسکریپت‌نویسی قابل استفاده هستند و می‌توانیم برای انجام کارهایی که نیاز به تکرار دارند از آن‌ها استفاده کنیم. + +![Shell Loop Expression Picture](./images/01-linux-shell-loop-expressions-picture.png 'Shell Loop Expression Picture') + +برای بهتر یاد گرفتن اسکریپت‌نویسی در شل می‌توانید از منبع زیر کمک بگیرید: + +- [Bash Scripting Tutorial – Linux Shell Script and Command Line for Beginners](https://www.freecodecamp.org/news/bash-scripting-tutorial-linux-shell-script-and-command-line-for-beginners/) + +--- + +# تمرین + +- با استفاده از ابزارهایی که در این بخش با آن‌ها آشنا شدید، + معمای + [The Command Line Murders](https://github.com/veltman/clmystery) + را حل کنید. +- اسکریپتی بنویسید که با بررسی تمام برنچ‌های یک ریپازیتوری گیت و تمام فایل‌های درون + هر برنچ، فایل‌هایی که در آن‌ها کلمه + `TODO` + به کار رفته است را پیدا کرده و نام آن‌ها را به همراه مسیر و برنچ مربوطه چاپ کند. diff --git a/docs/devops/02-network.md b/docs/devops/02-network.md new file mode 100644 index 00000000..50ae4fed --- /dev/null +++ b/docs/devops/02-network.md @@ -0,0 +1,217 @@ +--- +title: Computer Networks +description: '' +--- + +امروزه شبکه‌های کامپیوتری در همه بخش‌های زندگی ما نقش داشته و اکثر محصولات و سرویس‌های کامپیوتری از طریق بزرگترین شبکه کامپیوتری موجود یا همان اینترنت به دست کاربرها می‌رسند. به همین خاطر شناخت این شبکه‌ها برای بهینه کردن خدمت‌رسانی به کاربرها اهمیت زیادی دارد. در ادامه، نگاهی به بخش‌های مختلف شبکه‌های کامپیوتری می‌اندازیم و بعد از آن با چند پروتکل‌ مهم لایه اپلیکیشن آشنا می‌شویم. + +# چرا شبکه‌های کامپیوتری؟ + +با بوجود آمدن کامپیوترها، آن‌ها وظیفه انجام کارهای تکراری و محاسبات پیچیده را بر عهده گرفته و انجام کارهایی که قبلا برای ما سخت بود را ساده کردند. با گسترش استفاده از آن‌ها، نیاز جدیدی بوجود آمد. داده‌های پردازش شده بر روی این کامپیوترها باید به اشتراک گذاشته شده و بر روی کامپیوترهای دیگر و بوسیله افراد جدید استفاده و احتمالا بهبود داده می‌شدند، و شبکه‌های کامپیوتری برای رفع این نیاز ایجاد شدند. + +احتمالا می‌دانید که می‌توان هر نوعی از داده را با ایجاد یک قرارداد خاص تبدیل به یک رشته باینری کرد. وظیفه شبکه‌های کامپیوتری انتقال این رشته‌های باینری بر روی واسط‌های مختلف و رساندن آن‌ها به دستگاه‌های دیگر است. اما چطور؟ + +:::info اطلاعات بیشتر +در این آموزش به دلیل پیچیدگی، به اینکه داده‌ها در لایه فیزیکی چطور بوسیله سیم یا به صورت بی‌سیم منتقل می‌شوند نمی‌پردازیم. برای سادگی می‌توانید فرض کنید که این انتقال با تغییر ولتاژ روی سیم، اتفاق می‌افتد. اما اگر دوست دارید که بیشتر درباره این موضوع بدانید می‌توانید سه ویدیوی اول پلی‌لیست +[Ben Eater - Networking tutorial](https://www.youtube.com/playlist?list=PLowKtXNTBypH19whXTVoG3oKSuOcw_XeW) +را مشاهده کنید. +::: + +## پروتکل + +زمانی که شما با یک فرد جدید ملاقات می‌کنید، اول سلام و احوالپرسی کرده و بعد از این، خودتان را معرفی می‌کنید. این رفتار شما یک قانون اجتماعی است. کامپیوترها هم برای ارتباط با هم به قوانینی نیاز دارند تا خودشان را معرفی کرده و سپس به انتقال داده بپردازند. به این قوانین که بوسیله مهندسان برق و کامپیوتر تعریف می‌شوند پروتکل گفته می‌شود. + +# لایه‌های شبکه + +انتقال اطلاعات بین کامپیوترها فرایندی پیچیده است که با بخش‌های مختلفی از کامپیوتر، مانند بخش‌های فیزیکی و نرم‌افزاری سر و کار دارد. در طراحی سیستم‌های پیچیده مانند این سیستم، برای +پنهان کردن برخی از پیچیدگی‌ها و ساده‌تر کردن روند استفاده از سیستم، سیستم را به چند لایه مختلف شکسته و برای هر لایه یک رابط استاندارد برای ارتباط با لایه‌های بالاتر و پایین‌تر خودش تعریف می‌کنند. با استفاده از این طراحی می‌توان نیازمندی‌ها و پیچیدگی‌های هر بخش را در همان بخش نگه داشته و به صورت ساده‌تری به مسائل نگاه کرد. + +## لایه Link + +تا اینجای کار متوجه شدیم که چرا به شبکه‌های کامپیوتری نیاز داریم و فرض کردیم که کامپیوترها می‌توانند بر روی یک سیم به اشتراک اطلاعات بپردازند. اما همه چیز به این سادگی نیست. مثلا اگر داده‌های ارسالی در میانه راه به دلیل نویز موجود در محیط دچار مشکل شوند چطور می‌توانیم متوجه این مشکل بشویم؟ علاوه بر این، اتصال دو کامپیوتر به هم با یک سیم کار چندان پیچیده‌ای نیست، اما چطور می‌توانیم چندین کامپیوتر را به هم متصل کنیم؟ + +:::note مسئله +درباره روش‌های ممکن برای اتصال چندین کامپیوتر به هم فکر کرده و درباره مزایا و معایب هر روش با هم‌گروهی خود صحبت کنید. +::: + +پروتکل‌های لایه لینک مثل +Ethernet، +برای پاسخ به این مشکلات +بوجود آمده‌اند. +برای شناخت این پروتکل، می‌توانید ویدیوی +[Ethernet (50th Birthday) - Computerphile](https://www.youtube.com/watch?v=TkOVgkcrvbg&ab_channel=Computerphile) +را تماشا کنید. + +:::note مسئله +وقتی که با پروتکل +Ethernet +آشنا شدید، +درباره +MAC Address +و شباهت آن با کد ملی خودتان فکر کنید. +::: + +## لایه Network + +فهمیدیم که پروتکل‌های لایه لینک مثل +Ethernet +با حل چالش‌هایی که در لایه فیزیکی برای ما بوجود می‌آیند و ایجاد یک ساختار مشخص به ما کمک می‌کنند که داده‌ها را بر روی یک واسط فیزیکی منتقل کنیم. اما با فهمیدن این موضوع، سوالات جدیدی برای ما بوجود می‌آیند: + +- مگر همه کامپیوترهای دنیا به صورت فیزیکی به هم متصل هستند و می‌توانند با استفاده از پروتکل + Ethernet + برای هم داده ارسال کنند؟ + +- با وجود یک + MAC Address + ثابت، چطور وقتی از یک مکان به مکان دیگری می‌رویم، کامپیوتر ما می‌تواند دوباره به راحتی به اینترنت متصل بشود و داده رد و بدل کند؟ (به این فکر کنید که اگر خانه خود را عوض کنیم، آیا کسی می‌تواند با داشتن کد ملی برای ما نامه ارسال کند؟) + +به این سوالات فکر کرده و سعی کنید راه حلی برای آن‌ها پیدا کنید. سپس با تماشای ویدیوی +[what is an IP Address?](https://www.youtube.com/watch?v=5WfiTHiU4x8) +با پروتکل +IP +آشنا شوید. + +:::note مسئله +از قبل می‌دانیم که دستگاه‌های درون یک شبکه می‌توانند با استفاده از پروتکل +Ethernet +برای یکدیگر داده ارسال کنند و همانطور که در ویدیو دیدیم، دستگاه‌های درون یک شبکه محلی می‌توانند بدون استفاده از روتر اصلی شبکه و با استفاده از آدرس +IP +برای هم داده ارسال کنند. +شاید این دو گزاره متناقض به نظر برسند، اگر داده با پروتکل +Ethernet +ارسال می‌شود چه نیازی به +IP +داریم و یا اگر از پروتکل +IP +استفاده می‌کنیم دیگر چه نیازی به +Ethernet +وجود دارد؟ +::: + +احتمالا تا الان حدس زده‌اید که داده‌ای که بسته +Ethernet +در درون خودش حمل می‌کند، همان داده‌ای است که با استفاده از +IP +ارسال شده. برای درک بهتر این موضوع +[این ویدیو](https://www.youtube.com/watch?v=IZ_PnVXtMeY&ab_channel=JimKurose) +را تماشا کنید. + +:::note مسئله +حالا که متوجه شدیم بسته‌های +IP +داخل شبکه‌های محلی با استفاده بسته‌های +Ethernet +جا به جا می‌شوند، به نظر شما چطور آدرس‌های +IP +را به آدرس‌های +MAC +تبدیل می‌کنیم؟ برای فهمیدن این مسئله، درباره پروتکل +ARP +جست‌وجو کنید. +::: + +:::tip اطلاعات بیشتر +تا اینجای کار فهمیدیم که اینترنت از شبکه‌های محلی کوچک‌تری تشکیل شده که بوسیله روترها به هم متصل شده‌اند. آدرس‌دهی به این شبکه‌های کوچک‌تر بوسیله سازمانی به نام +IANA +انجام شده و روترها با پروتکل‌های خاصی با هم صحبت کرده و آدرس‌های که خودشان دارند و یا می‌شناسند را با هم به اشتراک می‌گذارند تا بتوانند بسته‌ها را از شبکه‌های خود برای بقیه شبکه‌ها فرستاده و از بقیه شبکه‌ها بسته بگیرند. +::: + +## لایه Transport + +تا اینجای کار فهمیدیم که بسته‌ها چطور از یک دستگاه به دستگاهی در شبکه‌ای دیگر منتقل می‌شوند و +می‌توانیم درک کنیم که چرا اینترنت شبکه‌ای از شبکه‌ها است. اما +پیچیدگی زیاد اینترنت چالش جدیدی را برای ما ایجاد می‌کند. با وجود راه‌های زیاد رسیدن بسته‌ها به مقصد، ممکن است که این بسته‌ها در راه گم شده یا با ترتیب متفاوتی به مقصد برسند. علاوه بر این، می‌دانیم که یک دستگاه متصل به اینترنت فقط یک آدرس +IP +دارد اما معمولا همین یک دستگاه باید به چند اپلیکیشن مختلف خدمات شبکه ارائه بدهد و به راهی برای ایجاد تمایز بین بسته‌های هر اپلیکیشن نیاز داریم. (به شباهت این موضوع با کد پستی‌های مختلف یک آپارتمان بزرگ فکر کنید.) + +برای حل این چالش‌ها پروتکلی به نام +TCP +بوجود آمده. این پروتکل با استفاده از مفهومی به نام +Three way handshake +یک ارتباط همگام بین دو دستگاه بوجود آورده و با مکانیزم خاصی، رسیدن بسته‌ها به صورت صحیح و به ترتیب را تضمین می‌کند. علاوه بر این با استفاده از آدرسی به نام +Port، +اجازه می‌دهد چند اپلیکیشن بدون تداخل از شبکه استفاده کرده و بر روی آن داده فرستاده و دریافت کنند. برای آشنایی بیشتر با هر یک از مفاهیمی که گفته شد لینک‌های زیر را مشاهده کنید: + +- [?What Are TCP Ports and Why Are They Important](https://www.cbtnuggets.com/blog/technology/networking/what-is-a-tcp-port-and-why-they-are-important) +- [?What Is a Three-Way Handshake in TCP](https://www.youtube.com/watch?v=LyDqA-dAPW4&t=1s&ab_channel=Cisco) + +:::tip **معماری Client-Server** +حتما اسم +Server +را زیاد شنیده‌اید، اما این اسم واقعا به چه معناست؟ + +معمولا خدماتی که به کاربرها ارائه داده می‌شود، بوسیله یک برنامه خاص پشتیبانی می‌شود که منطق و داده‌های خاص خودش را دارد. خیلی وقت‌ها، این منطق و داده‌ها با کاربران به اشتراک گذاشته نمی‌شوند، بلکه بر روی یک یا چند کامپیوتر خاص که به آن‌ها سرور گفته می‌شود نگه‌داری شده و بوسیله شبکه‌های کامپیوتری به برنامه‌هایی که بر روی دستگاه‌های کاربر نصب شده، متصل شده و خدمات مورد نیاز را برای کاربرها فراهم می‌کنند. +::: + +## لایه Application + +تمام پروتکل‌هایی که در قسمت‌های قبل با آن‌ها آشنا شدیم برای رسیدن به اینجا طراحی شده‌اند. جایی که اپلیکیشن‌ها با اتصال به اینترنت به کاربرها خدمات می‌دهند. بر خلاف پروتکل‌های لایه پایین‌تر، پروتکل‌های لایه اپلیکیشن به شدت متنوع بوده و کارهای مختلفی را انجام می‌دهند. +به نظر شما چرا چنین تفاوتی بین پروتکل‌های لایه اپلیکیشن با پروتکل‌های لایه‌های پایین‌تر وجود دارد؟ + +در اینجا ما با دو تا از مهم‌ترین این پروتکل‌ها کمی بیشتر آشنا می‌شیم. + +### پروتکل DNS + +ما به عنوان یک کاربر عادی معمولا با آدرس‌های +IP +سر و کار نداریم و از آدرس‌های معناداری مثل +example.com +استفاده می‌کنیم. پروتکل +DNS +برای ترجمه این آدرس‌های انسانی به آدرس‌های +IP +که برای کامپیوترها معنادار هستند طراحی شده. برای درک بهتر کارکرد این پروتکل ویدیوی، +[DNS as Fast As Possible](https://www.youtube.com/watch?v=Rck3BALhI5c&ab_channel=Techquickie) +را تماشا کنید. + +:::note تسک +با مراجعه به سایت +[Mess with DNS](https://messwithdns.net/) +و انجام تمرین‌های آن، بیشتر با پروتکل +DNS +آشنا شوید. +برای بررسی رکوردهای +DNS +در خط فرمان، می‌توانید از ابزار +Dig +استفاده کنید. +::: + +### پروتکل HTTP + +امروزه خیلی از خدمات کاربردی بر روی وب و از طریق مرورگرها در اختیار ما قرار می‌گیرند پروتکل HTTP، +پروتکلی است که برای ارسال و دریافت داده بر روی وب طراحی شده و در پس خیلی از این خدمات قرار می‌گیرد. برای آشنایی بهتر با این پروتکل پر کاربرد، سری به +[Cloudflare - What is HTTP?](https://www.cloudflare.com/learning/ddos/glossary/hypertext-transfer-protocol-http/) +بزنید. + +# ابزارهای کار با شبکه + +حالا که با شبکه‌های کامپیوتری آشنا شدیم، نیاز داریم که با برخی از ابزارهایی که در کار مدیریت +شبکه از آن‌ها استفاده می‌شود نیز آشنا شویم. + +## Wireshark + +اولین ابزاری که به آن می‌پردازیم، +Wireshark +است. این ابزار به ما کمک می‌کنند بسته‌هایی که بر روی شبکه در حرکت هستند را مشاهده کرده و +آن‌ها را تحلیل کنیم. +:::info تسک +با مراجعه به وبسایت کتاب +[Computer Networking: a Top Down Approach](https://gaia.cs.umass.edu/kurose_ross/wireshark.php) +و انجام آزمایشگاه‌های اول و دوم وایرشارک آن سعی کنید با وایرشارک و نحوه کار با آن آشنا شوید. +::: + +## Netcat + +گاهی اوقات نیاز داریم که با استفاده از سوکت‌های +TCP +به صورت دستی به جایی متصل شویم یا سوکتی بسازیم تا از جای دیگری به آن متصل شوند. +ابزار +Netcat +به ما اجازه می‌دهد چنین کاری را انجام دهیم. +:::info تسک +با جست‌وجو در اینترنت با این ابزار آشنا شده و +سپس با نصب آن بر روی لینوکس خود در یک صفحه یک سوکت +TCP +ساخته و در صفحه دیگر به این سوکت متصل شوید. +::: diff --git a/docs/devops/03-nginx.md b/docs/devops/03-nginx.md new file mode 100644 index 00000000..02a29db5 --- /dev/null +++ b/docs/devops/03-nginx.md @@ -0,0 +1,4 @@ +--- +title: Nginx +description: '' +--- diff --git a/docs/devops/04-ha-concept.md b/docs/devops/04-ha-concept.md new file mode 100644 index 00000000..779bb4f7 --- /dev/null +++ b/docs/devops/04-ha-concept.md @@ -0,0 +1,138 @@ +--- +title: HA Concept +description: '' +--- + +## مقدمه +پس از شناسایی یک نیاز، طراحی و توسعه یک سیستم برای رفع آن نیاز به صورت کلی مسئله ما را حل نمی‌کند بلکه سیستم طراحی شده باید در اکثر اوقات و حتی در شرایط بد و پیش آمدن رخدادهای غیرمنتظره هم به درستی کار کند و در دسترس باشد. به همین دلیل است که مفهوم +High Availability +مفهومی بسیار مهم است که قصد داریم در این بخش با آن بیشتر آشنا شویم. +برای افزایش +Availablity +یک سیستم راهکارهای زیادی وجود دارند که تعدادی از مهم‌ترین آن‌ها در قالب یک مثال در این بخش ذکر شده اند. +تصور کنید شما به تازگی در یک شرکت بزرگ استخدام شده‌اید. این شرکت پلفترمی را به مشتریان خود ارائه می‌دهد که در بررسی و تحلیل داده‌های مختلف مورد استفاده قرار می‌گیرد. مشتریان شما شرکت‌ها و سازمان‌هایی هستند که با داده‌های حساس و حجیم سروکار دارند. از این رو قابل اعتماد بودن محصول شما و عملکرد درست آن در شرایط مختلف برای آن‌ها بسیار حائز اهمیت است. مسئولیت شما در این شرکت استقرار محصولات شرکت، برای مشتریان آن است. در سناریو ذکر شده چه راهکارهایی برای افزایش فاکتور +Availablity +در محصولات مستقر شده به نظرتان می‌رسد؟ +احتمالا با مطالعه نکات بالا به اهمیت مفهوم +Availablity +پی برده‌اید. این مفهوم توسط معیار زیر اندازه گیری می‌شود: + +![Operational Avaliablity Formula](./images/04-ha-concept-oprational-availablity-formula-picture.png "Operational Avaliablity Formula") + +با توجه به فرمول ذکر شده می‌توان بی‌نهایت سطح +Availablity +داشت. اما یک روش رایج تقسیم‌بندی این سطوح به پنج دسته است که با عنوان +The Five Nines +شناخته می‌شوند. در تصویر زیر این پنج سطح با یکدیگر مقایسه شده‌اند. + +![The Five Nines](./images/04-ha-concept-5-nines-picture.png "The Five Nines") + +برای آشنایی بیشتر با مفهوم +The Five Nines +می‌توانید از +[این لینک](https://www.cbtnuggets.com/blog/certifications/cloud/the-five-nines-how-to-measure-high-availability-uptime) +استفاده کنید. + +حال که اهمیت مفهوم +High Availablity +را بهتر درک کردید. وقت آن است که با تعدادی از راهکارهای افزایش این فاکتور آشنا شویم. +از رایج‌ترین راهکارهای موجود می‌توان به موراد زیر اشاره کرد: + +### Load Balancing +این فرایند به منظور توزیع ترافیک شبکه بین چندین سرور یا منبع محاسباتی انجام می‌شود. این کار باعث می‌شود که هیچ یک از سرورها بیش از حد بارگذاری نشوند و سیستم به صورت بهینه عمل کند. +استفاده از این مفهوم مزایای زیر را در پی دارد: +* افزایش عملکرد و سرعت پاسخ‌دهی سیستم. +* جلوگیری از بارگذاری بیش از حد یک سرور و در نتیجه کاهش احتمال خرابی. +* بهبود دسترسی به سرویس‌ها و افزایش ظرفیت سیستم برای پاسخگویی به تعداد بیشتری از کاربران. + +### Redundancy +مفهوم +Redundancy +یا افزونگی به معنای داشتن منابع اضافی یا پشتیبان است که در صورت خرابی منابع اصلی، بتوانند به عنوان جایگزین عمل کنند. که باعث افزایش قابلیت اطمینان و پایداری سیستم، کاهش زمان خرابی +(Down Time) +با استفاده از منابع پشتیبان و همچنین فراهم کردن توانایی بازیابی سریع و جلوگیری از از دست رفتن داده‌ها یا خدمات می‌شود. + +### Automatic Failover +فرایندی است که طی آن، به محض شناسایی خرابی در یک سیستم یا سرور، سیستم پشتیبان به صورت خودکار وارد عمل می‌شود و مسئولیت را بر عهده می‌گیرد. با اهمیت دادن به این مفهوم زمان خرابی‌ها به حداقل ممکن می‌رسد، اعتماد کاربران به سیستم افزایش می‌یابد و نیاز به مداخله دستی برای حل مشکلات سیستم نیز کاهش می‌یابد. + +### Single Point of Failure (SPoF) +در تعریف ساده نقطه شکست تکین به معنای یک جزء یا یک بخش از سیستم است که در صورت خرابی آن، کل سیستم دچار مشکل خواهد شد. شناسایی و حذف +SPoF +ها به افزایش پایداری سیستم کمک می‌کند. همچنین در طراحی و معماری سیستم باید به گونه‌ای باشد که هر جزئ دارای پشتیبان باشد تا از وقوع خرابی‌های بزرگ جلوگیری شود. برای آشنایی بیشتر با مفهوم +FailOver +می‌توانید از +[این لینک](https://www.techtarget.com/searchstorage/definition/failover) +استفاده کنید. + +### Observability +قابلیت مشاهده پذیری یکی دیگر از مفاهیمی می‌باشد که توجه به آن ما را قادر می‌سازد تا وضعیت داخلی یک سیستم را درک و اندازه‌گیری کنیم. اهمیت دادن به این مفهوم باعث می‌شود تا مشکلات را به راحتی تشخصی داده و شروع به برطرف کردن آن‌ها کنیم، عملکرد سیستم را بهبود بخشیم و حتی وقوع خرابی‌ها را در آینده پیش‌بینی کنیم و از رخ دادن آن‌ها جلوگیری کنیم. + + +## Disaster Recovery (DR) +یکی از مفاهیم مرتبط و گره‌خورده با مفهوم +High Availability +مفهوم +Disaster Recovery +می‌باشد. این مفهوم به فرایند بازگرداندن حالت کلی یک سیستم پس از رخ دادن یک حادثه اشاره می‌کند و راه‌حل‌های مختلفی برای آن ارائه می‌دهد. از جمله این راهکارها می‌توان به موارد زیر اشاره کرد: + +* پشتیبان گیری منظم و مستمر از پایگاه‌های داده +* استقرار سرورها در نقاط جغرافیایی مختلف +* مانیتورینگ و استفاده از سیستم‌های هشدار در هنگام بروز مشکلات مختلف +* استفاده از مفهوم +Containerization +و ابزارهایی مانند +Docker +و +Kubernetes + +پس از استفاده از راهکارهای معرفی شده جهت افزایش فاکتور +High Availability +و پیاده‌سازی سازوکارهای +Disaster Recovery +در سیستم، نیاز داریم تا میزان موثر بودن این راهکارها را بررسی کنیم. برای این کار روش‌های مختلفی وجود دارند که در این بخش به تفکیک برای هر موضوع تعدادی از این روش‌ها را معرفی می‌کنیم. +برای بررسی +High Availability +در یک سیستم می‌توانیم از آزمون‌های زیر استفاده کنیم: + +* Failover Testing (برای آشنایی بیشتر از +[این لینک](https://www.tutorialspoint.com/software_testing_dictionary/failover_testing.htm) +استفاده کنید.) +* Load Testing (برای آشنایی بیشتر از +[این لینک](https://www.tutorialspoint.com/software_testing_dictionary/load_testing.htm) +استفاده کنید.) +* Graceful Degradation Testing (برای آشنایی بیشتر از +[این لینک](https://www.techtarget.com/searchnetworking/definition/graceful-degradation#:~:text=Graceful%20degradation%20is%20the%20ability,is%20to%20prevent%20catastrophic%20failure.) +استفاده کنید.) + +همچنین برای بررسی +Disaster Recovery +در یک سیستم می‌توانیم از روش‌های زیر استفاده کنیم: +* Partial/Full Failover Testing +* A/B Testing (برای آشنایی بیشتر از +[این لینک](https://www.oracle.com/cx/marketing/what-is-ab-testing/) +استفاده کنید.) +* Network Partition Testing (در این مورد خطاهای یک شبکه با هدف بررسی عملکرد بخش‌های مختلف یک سیستم در حالتی که نمی‌توانند به درستی با بقیه اجزای آن ارتباط برقرار کنند بررسی می‌شود.) +* Chaos Engineering (برای آشنایی بیشتر از +[این لینک](https://www.opentext.com/what-is/chaos-engineering#:~:text=Chaos%20engineering%20is%20the%20practice,actual%20outage%20or%20other%20disruption.) +استفاده کنید.) + +و در نهایت می‌توانیم از مفهوم +Post Disaster Validation +برای بررسی کیفیت راهکارهای +Disaster Recovery +خودمان استفاده کنیم. این مفهوم بررسی می‌کند که آیا پس از رخ دادن یک حادثه و برگشتن به حالت عادی همچنان تمام بخش‌های سیستم قابل استفاده هستند و همچنین هیچ داده‌ای از بین نرفته باشد. +برای بررسی میزان +High Availablity +در یک سیستم نیز می‌توان از معیارهایی نظیر +Mean Time Between Failures (MTBF) +و +Mean Time to Repair (MTTR) +استفاده کرد. +### MTTR +به معنای متوسط زمان لازم برای تعمیر یک سیستم یا تجهیز پس از وقوع خرابی است. این معیار بیانگر مدت زمانی است که برای تشخیص، تعمیر و بازگرداندن سیستم به حالت عادی نیاز است و مقدار آن از تقسیم +Downtime +کل بر تعداد خرابی‌ها به دست می‌آید. +### MTBF +به معنای متوسط زمان بین دو خرابی متوالی یک سیستم یا تجهیز است. این معیار نشان‌دهنده قابلیت اطمینان سیستم و مدت زمان متوسطی است که سیستم بدون خرابی کار می‌کند و مقدار آن از تقسیم زمان عملکرد سیستم +(Total Operating Time) +بر تعداد خرابی‌ها به دست می‌آید. \ No newline at end of file diff --git a/docs/devops/05-golang.md b/docs/devops/05-golang.md new file mode 100644 index 00000000..60b771fe --- /dev/null +++ b/docs/devops/05-golang.md @@ -0,0 +1,4 @@ +--- +title: Go +description: '' +--- \ No newline at end of file diff --git a/docs/devops/06-test-concept.md b/docs/devops/06-test-concept.md new file mode 100644 index 00000000..05f97b3b --- /dev/null +++ b/docs/devops/06-test-concept.md @@ -0,0 +1,4 @@ +--- +title: Test Concept +description: '' +--- diff --git a/docs/devops/07-containerization.md b/docs/devops/07-containerization.md new file mode 100644 index 00000000..63393423 --- /dev/null +++ b/docs/devops/07-containerization.md @@ -0,0 +1,151 @@ +--- +title: Containerization +description: '' +--- + +به نظر شما هدف ما از توسعه نرم‌افزار چیست؟ +بدون توجه به پاسخی که به این سوال می‌دهید قدم مهمی در چرخه تولید نرم‌افزار وجود دارد: رسیدن نرم‌افزار به دست مشتری! +اما اینکار چطور انجام می‌شود؟ +می‌دانیم که کدهای یک نرم‌افزار بعد از نوشته شدن باید تست،‌ بیلد و مستقر شوند. +احتمالا حدس می‌زنید که استقرار نرم‌افزارهای بزرگ معمولا با پیچیدگی‌های مختلفی همراه است. اما به طور دقیق چه +پیچیدگی‌هایی؟ +بیاید با هم بعضی از این پیچیدگی‌ها را بررسی کنیم. + +- اولین مشکل در راه استقرار یک نرم‌افزار، مشخص نبودن روال بیلد شدن و محیط اجرای آن است. + معمولا توسعه‌دهنده‌ها تمام ابزارهای مورد نیاز برای تست و بیلد نرم‌افزاری که بر روی آن کار می‌کنند را بر روی دستگاه‌های + شخصی خود دارند + اما در زمان بیلد نرم‌افزار برای استقرار اصلی و اجرای آن باید چه کاری انجام بدهیم؟ + +- چالش دیگری که برای استقرار یک نرم‌افزار وجود دارد، وابستگی‌های آن است. معمولا نرم‌افزارهای ما به تنهایی کار نکرده و + برای اجرا شدن صحیح به کتابخانه‌ها و ابزارهای سیستمی نیاز دارند. + مشخص کردن و نگه‌داری این وابستگی‌ها به شکل منظم یکی از دیگر چالش‌های استقرار نرم‌افزارهای بزرگ است. + +- علاوه بر این، نرم‌افزارهای ما معمولا به تنهایی اجرا نشده و نیاز به ابزارهای جانبی مثل پایگاه‌داده و… دارند. + قرار دادن این نرم‌افزارها و ابزارها در کنار هم و اتصال آن‌ها به بقیه نیز چالش دیگری است که با آن روبرو هستیم. + +اما چطور باید به این چالش‌ها پاسخ داد؟ + +# ماشین‌های مجازی + +در گذشته، راه‌حلی که برای پاسخ به این چالش‌ها ارائه می‌شد ابزاری به اسم +Virtual Machine +یا ماشین مجازی بود. +ماشین‌های مجازی که از حالا به بعد آن‌ها را +VM +صدا می‌زنیم سعی می‌کردند با تقسیم یک سخت‌افزار فیزیکی به چند سخت‌افزار مجازی و اجرای سیستم‌عامل‌های مجزا بر روی این +سخت‌افزارهای مجازی، +محیط مورد نیاز یک نرم‌افزار رو به صورت کامل ایجاد و نگه‌داری کنند. +برای آشنایی بهتر با تکنولوژی مجازی‌سازی و +VMها +[این ویدیو](https://www.youtube.com/watch?v=FZR0rG3HKIk&pp=ygUMd2hhdCBpcyBhIHZt) +را تماشا کنید. + +# کانتینرها + +VMها، +به خوبی می‌توانستند نیازمندی‌های ما برای استقرار نرم‌افزار را پاسخ دهند اما این ابزارها یک مشکل بزرگ داشتند: +سربار زیاد منابع! +شرکت‌های تکنولوژی که علاقه‌ای به نابهینگی نداشته و همواره سعی در کمتر کردن مصرف منابع داشتند، برای حل این مسئله به +تکنولوژی کانتینر روی آوردند. + +## تفاوت کانتینر با VM + +![VM vs Container](./images/07-vm-vs-container.png) + +کانتینرها بسته‌هایی هستند که نرم‌افزار ما را به همراه تمام وابستگی‌هایی که دارد در خود نگه داشته +و به ما اجازه می‌دهند که آن‌ها را به صورت مجزا از هم، بهینه و بدون هزینه زیاد اجرا کنیم. اما چطور؟ +پیش از اینکه به سراغ این تکنولوژی جدید برویم بهتر است برای آشنایی بیشتر با تفاوت کانتینرها و +VMها +[این ویدیو](https://www.youtube.com/watch?v=eyNBf1sqdBQ&pp=ygUQdm0gYW5kIGNvbnRhaW5lcg%3D%3D) +را تماشا کنید. + +## Docker + + +برای مدیریت کانتینرها و استفاده از آن‌ها روش‌ها و ابزارهای زیادی وجود دارد. یکی از این روش‌ها که از روش‌های دیگر +مرسوم‌تر است، استفاده از +Docker +است. +داکر به ما اجازه می‌دهد ایمیج بسازیم، کانتینرهای مختلف را اجرا کرده و آن‌ها را مدیریت کنیم. +برای نصب داکر از آموزش اصلی آن در +[این لینک](https://docs.docker.com/engine/install/) +کمک بگیرید. + +## Image + +ایمیج‌ها مثل یک نقشه برای اجرای یک کانتینر بوده و هر کانتینر باید از روی یک ایمیج خاص ساخته و اجرا شود. +برای ساخت ایمیج‌ها ما باید آن‌ها را بوسیله یک زبان خاص توصیف کرده و با استفاده از آن توصیف ایمیج مورد نظر خود را بسازیم. +برای توصیف یک ایمیج زبان‌های مختلفی وجود دارد، با توجه به اینکه ما از داکر برای یادگیری تکنولوژی کانتینر استفاده +می‌کنیم، +برای ساخت ایمیج نیز از داکرفایل که روش تعریف مورد استفاده داکر است بهره می‌بریم. +برای آشنایی با داکرفایل و نحوه نوشتن آن، به +[این لینک](https://docs.docker.com/guides/docker-concepts/building-images/writing-a-dockerfile/) +سر زده و پس از ساخت ایمیج خود، با استفاده از +[این آموزش](https://docs.docker.com/guides/docker-concepts/building-images/build-tag-and-publish-an-image/) +آن را با استفاده از دستور زیر اجرا کنید: + +```bash +docker run {image_tag} +``` + +پس از یادگیری ساختار کلی داکرفایل می‌توانید برای آشنایی بیشتر با تمام دستورات آن +به +[Dockerfile reference](https://docs.docker.com/reference/dockerfile/) +مراجعه کنید. + +![Moby; Docker Mascot](./images/07-docker.webp) + +## ورودی و خروجی + +معمولا نرم‌افزارهای ما نیاز به ارتباط بر روی شبکه و ذخیره داده‌های فایلی دارند. + +### Volume + +داده‌های درون کانتینرهایی که بوسیله داکر ایجاد می‌شوند، ماندگار نبود و بعد از پاک شدن کانتینر، از بین می‌روند. داکر برای +حل این مسئله از +Volume +استفاده می‌کند. +Volume +ها به ما اجازه می‌دهند که قسمتی از فایل‌سیستم درون کانتینر را برای استفاده‌های بعدی، بر روی سیستم‌عامل میزبان ذخیره +کنیم. +برای آشنایی بیشتر با +Volumeها +و استفاده از آن‌ها به +[این لینک](https://docs.docker.com/guides/docker-concepts/running-containers/persisting-container-data/) +مراجعه کرده و تمرین آن را انجام دهید. + +### Network + +ذخیره داده تنها نیازمندی نرم‌افزارهای ما نیست، معمولا نرم‌افزارها نیاز دارند که علاوه بر ذخیره‌سازی، از طریق شبکه در +دسترس باشند +تا کاربرها بتوانند با آن‌ها ارتباط برقرار کرده و از خدماتشان استفاده کنند. +داکر در زمان اجرای کانتینر یک شبکه مجازی ایجاد و کانتینر را در درون آن قرار می‌دهد. +این شبکه مجازی از شبکه اصلی دستگاه ما جدا بوده و ما نمی‌توانیم در حالت عادی با آن ارتباط برقرار کنیم. +اما داکر به ما اجازه می‌دهد که بعضی از پورت‌های مورد استفاده کانتینر را به پورت‌های شبکه اصلی دستگاهمان متصل کرده و از +این پورت‌ها استفاده کنیم. +علاوه بر این ما می‌توانیم شبکه‌های مجازی مختلف و جدا از هم ایجاد و کانتینرهایمان را برای مدیریت بهتر در آن‌ها قرار +بدهیم. +برای آشنایی بیشتر با مدیریت شبکه در داکر به +[این لینک](https://docs.docker.com/guides/docker-concepts/running-containers/publishing-ports/) +سر بزنید. + +## اجرای چندین کانتینر مجزا + +گفتیم که یکی از نیازمندی‌های مهم ما در اجرای نرم‌افزارهای بزرگ، اجرای دیتابیس‌ها و ابزارهای جانبی است که نرم‌افزار ما به +آن‌ها نیاز دارد. یکی از راه‌های اجرای این ابزارها، استفاده از دستور +`docker run` +برای اجرای هر یک از کانتینرهاست. اما استفاده از این روش، به این دلیل که ممکن است دستورات اشتباه را بدون اینکه متوجه +بشویم وارد کنیم و یا دستورات درست رو فراموش کرده یا گم کنیم، +در طولانی مدت ما را دچار مشکل می‌کند. داکر برای حل این مسئله به ما اجازه می‌دهد که فایلی به نام +Docker Compose +بسازیم و تمامی نیازمندی‌های برنامه و ابزارهای جانبی مورد نیاز برای اجرا آن را در این فایل بنویسیم. +با داشتن این فایل و نگهداری آن در گیت هر بار که نیاز به اجرای نرم‌افزارمان داشتیم، با دادن این فایل به داکر، می‌توانیم +محیط مورد نیازمان را ایجاد و از آن استفاده کنیم. +برای یادگیری +Docker Compose +و روش استفاده از آن می‌توانید +[این آموزش](https://docs.docker.com/compose/gettingstarted/) +را دنبال کنید. +پس از این برای شناخت بیشتر این فایل و قابلیت‌های آن می‌توانید به +[Compose file reference](https://docs.docker.com/compose/compose-file/) +مراجعه کنید. diff --git a/docs/devops/08-kubernetes.md b/docs/devops/08-kubernetes.md new file mode 100644 index 00000000..7a3da43d --- /dev/null +++ b/docs/devops/08-kubernetes.md @@ -0,0 +1,252 @@ +--- +title: Kubernetes +description: '' +--- + +در بخش +Containerization +با کانتینرها و مزایای آن‌ها آشنا شدیم. با ورود کانتینرها، استقرار نرم‌افزارها بیش از گذشته ساده و سریع‌تر شد. این اتفاق +باعث توسعه سریع‌تر نرم‌افزارها و افزایش انتظار کاربران از سرویس‌های پر استفاده شد. با افزایش این انتظارات دیگر اجرای +نرم‌افزارها در یک محیط آماده و ایزوله کافی نبود. حالا از آن‌ها انتظار می‌رفت که بدون تاخیر و قطعی کار کرده، همواره و زیر +فشار بالا به درخواست‌های کاربران پاسخ داده و سریع به‌روز رسانی شوند. برای پاسخ دادن به این نیازمندی، دیگر اجرای +نرم‌افزارها بر روی یک سرور و رها کردن آن‌ها روش کارآمدی نبود و به همین خاطر نیاز بود ابزاری بوجود بیاید که نرم‌افزارها +را بر روی فضای ابری مدیریت کند. + +# کوبرنیتیز + +گفتیم که کانتینرها با ورود داکر، تبدیل به روش استاندارد استقرار نرم‌افزارها شدند، اما با پیچیده‌تر شدن نیازمندی‌های +بازار، کانتینرها به تنهایی نمی‌توانستند پاسخگوی نیازها باشند و نیاز به یک ابزار برای مدیریت آن‌ها در شرایط پیچیده حس +می‌شد. ابزارهایی که از دل این نیاز بوجود آمدند، +Orchestratorها +بودند. + +یکی از این +Orchestratorها +کوبرنیتیز بود. + +:::note اطلاعات بیشتر +ابزارهای دیگری مانند +Docker Swarm، +Hashicorp Nomad +و +Apache Mesos +نیز وجود دارند که شبیه به کوبرنیتیز عمل می‌کنند. اما کوبرنیتیز از سایر این ابزارها +محبوب‌تر است. +::: + +برای آشنایی بهتر با کوبرنیتیز بهتر است اول مشکلاتی که کوبرنیتیز قصد حل کردن آن‌ها را دارد را بشناسیم و سپس به روش کارکرد +آن بپردازیم: + +- مدیریت و استقرار خودکار برنامه‌ها: معمولا بررسی دستی منابع در دسترس و انتخاب بهینه سرورها برای اجرای نرم‌افزارها کاری + پیچیده و احتمالا غیرممکن است. به همین خاطر دوست داریم این انتخاب‌های بهینه بر اساس نیازمندی‌های ما به صورت خودکار + انجام شود. +- مدیریت خودکار ارتباط بین سرویس‌ها: در شرایط و معماری‌های پیچیده نرم‌افزارهای بزرگ، مدیریت شبکه و ارتباط بین آن‌ها چالش + آفرین بوده و بدون داشتن یک لایه ابسترکشن، حل مشکلات بسیار پیچیده می‌شود. +- خودترمیمی: نرم‌افزارهای ما ممکن است به دلایل مختلفی دچار مشکل شده و از دسترس خارج شوند، در چنین شرایطی باید سیستمی + وجود داشته باشد که آن‌ها را به صورت خودکار بازگردانی کرده و سعی کند مشکل را حل کند. +- به‌روزرسانی خودکار: به‌روزرسانی دستی نرم‌افزارها کاری پیچیده و مستعد خطاست، به همین علت به یک راه خودکار برای + به‌روزرسانی سریع و بدون مشکل نرم‌افزارها نیاز داریم. + +- در دسترس بودن: در بخش + High Availability + با این مفهوم و اهمیت آن در نرم‌افزار آشنا شدیم. به همین خاطر می‌دانیم که در نرم‌افزارهای + مدرن باید + SPoFهای + زیرساختمان را کم کرده و از + HA + بودن آن مطمئن شویم. + +- مقیاس‌پذیری: ممکن است که در زمان‌های خاصی تعداد کاربرهای نرم‌افزار ما بیشتر از حد مورد + عادی شود. در چنین شرایطی باید با افزایش تعداد کپی‌های نرم‌افزار و یا افزایش منابع در اختیار آن، به این بار بیش از حد عادی به سادگی پاسخ دهیم. + +کوبرنیتیز سکویی +(Platform) +متن‌باز برای حل این مشکلات و ایجاد یک راه‌حل خودکار برای مدیریت سیستم‌های کانتینری است. حالا که متوجه شدیم کوبرنیتیز +سعی در حل چه چالش‌هایی دارد راه خود را از دور به سمت شناخت این ابزار باز می‌کنیم. + +![Kubernetes Logo](./images/08-kubernetes-logo.png) + +## Promise Theory + +کوبرنیتیز بر اساس یک نظریه به نام +Promise Theory +کار می‌کند. برای شناخت این نظریه و اینکه چطور کوبرنیتیز با استفاده از آن به ما کمک می‌کند که نرم‌افزارهایمان را بهتر +مدیریت کنیم، بهتر است که یک مثال بزنیم. + +زمانی که شما می‌خواهید یک بسته پست کنید، به اداره پست نمی‌گویید که باید بسته شما با ماشین یا هواپیما جابه‌جا شود. شما +صرفا بسته خود را داخل یک جعبه گذاشته، مبدا و مقصد را مشخص می‌کنید و آن را به اداره پست می‌سپارید. در مقابل اداره پست به +شما قول می‌دهد که بسته شما تا یک زمان خاص به مقصد برسد. در چنین شرایطی برای شما مهم نیست که آب و هوا بد باشد یا وسیله +نقلیه‌ای که برای انتقال بسته شما استفاده شده چیست یا اگر این وسیله دچار مشکل شود چه اتفاقی می‌افتد. تنها چیزی که برای +شما اهمیت دارد رسیدن صحیح بسته به مقصد است که اداره پست این کار را برای شما انجام می‌دهد. + +کوبرنیتیز هم دقیقا مانند اداره پست عمل می‌کند. ما برنامه‌های خود را داخل کانتینرها قرار داده، نیازمندی‌های اجرای آن‌ها +را توصیف می‌کنیم و در مقابل کوبرنیتیز به ما قول می‌دهد که نیازمندی‌های نرم‌افزار ما را برآورده کند. + +## زیر پوست کوبرنیتیز + +تا اینجای کار دیدیم که کوبرنیتیز به چه نیازهایی پاسخ می‌دهد و از دور چطور این کار را انجام می‌دهد. حالا بیایید با هم +ببینیم که کوبرنیتیز واقعا چطور کار می‌کند. + +کوبرنیتیز یک سیستم توزیع‌شده است. این به این معنی است که شما کوبرنیتیز را بر روی یک سرور نصب نمی‌کنید، بلکه هر قسمت از +این ابزار را بر روی یک سرور مجزا نصب کرده و مدیریت این دستگاه‌ها را به کوبرنیتیز می‌سپارید. +:::info نکته +در فرهنگ لغت کوبرنیتیز به مجموعه سرورهای تحت مدیریت این ابزار، +Cluster +و به هر یک از این سرورها +Node +می‌گوییم. +::: +اگر بخواهیم با دقت بیشتری به +این دسته سرورها نگاه کنیم، دو دسته +Node +داریم. دسته اول +Workerها +هستند. این دسته از سرورها وظیفه اجرای کانتینرهای ما و اتصال به دیگر +Nodeها +برای ایجاد یک شبکه را دارند. در کنار این +Node +ها،‌ +Node +های +Control Plane +را داریم. وظیفه +Nodeهای +Control Plane +دریافت دستورات و خواسته‌های کاربر، ذخیره و کنترل کردن وضعیت کلاستر برای اجرای خواسته‌های کاربر است. + +برای آشنایی بیشتر با اجزای مختلفی که در نهایت کوبرنیتیز را می‌سازند،‌ می‌توانید +[این ویدیو](https://youtube.com/watch?v=n4zxKk2an3U&feature=share7) +را تماشا کنید. + +# اجرای کوبرنیتیز + +نصب و اجرای کوبرنیتیز به صورت آماده برای محیط‌های عملیاتی فرایندی تقریبا پیچیده است. برای این کار از +Kubeadm +یا ابزارهای دیگر استفاده می‌شود. در اینجا با توجه به اینکه نیازی به استفاده عملیاتی از این ابزار نداریم، می‌توانیم از +ابزارهایی که کوبرنیتیز را به صورت محلی و برای تست اجرا می‌کنند استفاده کنیم. دو تا از این ابزارها +Kind +و +Minikube +هستند. این ابزارها به ما اجازه می‌دهند با استفاده از داکر یا ابزارهای مجازی‌سازی کوبرنیتیز را بر روی دستگاه شخصی خودمان +اجرا کنیم. در ادامه راه برای استفاده از کوبرنیتیز ما از ابزار +Kind +استفاده می‌کنیم. + +پیش از اینکه به سراغ استفاده از کوبرنیتیز برویم، نیاز به ابزاری برای مدیریت کلاستر داریم. این ابزار +Kubectl +است که به ما اجازه می‌دهد از طریق محیط خط فرمان کلاستر خود را کنترل کنیم. ابتدا +[Kubectl](https://kind.sigs.k8s.io/) +و سپس +[Kind](https://kind.sigs.k8s.io/) +را نصب کرده و سعی کنید یک کلاستر با یک نود +Control Plane +و یک نود +Worker +بسازید. برای اطمینان از صحت کلاستر خود می‌توانید دستور زیر را اجرا کنید: + +```bash +kubectl get nodes +``` + +# اجرای نرم‌افزار بر روی کوبرنیتیز + +کوچک‌ترین شیء در دنیای کوبرنیتیز +Pod +یا پاد است. هر پاد متشکل از یک یا چند کانتینر است که برخی از منابع را به صورت اشتراکی و برخی دیگر را به صورت جدا استفاده +می‌کنند. در اینجا برای سادگی می‌توانیم فرض کنیم که پاد در دنیای کوبرنیتیز با کانتینرهای داکری تناظر یک به یک داشته و هر +پاد معادل یک کانتینر است. + +اشیا در کوبرنیتیز بوسیله ساختاری به نام منیفست توصیف می‌شوند. منیفست‌ها قطعات کدی مانند فایل‌های +Docker compose +هستند که در فاز قبلی با آن‌ها آشنا شدیم. منیفست زیر یک پاد را توصیف می‌کند. درباره هر یک از بخش‌های آن جست‌وجو کنید و +سعی کنید ساختار آن را درک کنید. + +برای مدیریت اشیا در کوبرنیتیز با استفاده از ابزار +kubectl +برای هر نوع شی دستوری با ساختار زیر را اجرا می‌کنیم: + +```bash +kubectl {verb} {resource} +``` + +مثلا برای مشاهده تمامی پادها از دستور + +```bash +kubectl get pods +``` + +استفاده می‌شود. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: Nginx + labels: + app: Nginx +spec: + containers: + - name: nginx-container + image: nginx +``` + +منیفست بالا را به صورت یک فایل +`yaml` +ذخیره کرده و با استفاده از دستور + +```bash +kubectl apply -f pod.yaml +``` + +آن را برای اجرا به کلاستر خود ارسال کنید. + +## Deployment + +همانطور که گفتیم یکی از مشکلاتی که با استفاده از کوبرنیتیز سعی در رفع آن‌ها داریم، مسئله خودترمیمی نرم‌افزارها است. با +توجه به این نیازمندی، می‌توان دید که اگر ما یک پاد را به صورت مستقل بر روی کوبرنیتیز اجرا کنیم، با پاک شدن آن پاد +نرم‌افزار ما دچار مشکل می‌شود. به همین خاطر به چیزی نیاز داریم که با توصیف نوع پادهای مورد نیازمان، کوبرنیتیز پادها را +به صورت خودکار ساخته و مدیریت کند. + +یکی از چیزهایی که می‌تواند این نیازمندی ما را رفع کند +Deployment +است. اطلاعات آن را از منابع اصلی کوبرنیتیز خوانده و سعی کنید یک +Deployment +برای پاد مرحله قبل بنویسید و بر روی کلاستر قرار دهید. + +بجز +Deployment +راه‌های دیگری مثل +Statefulset +و +Deamonset +نیز برای اجرای کانتینرها بر روی کوبرنیتیز وجود دارد. درباره +آن‌ها تحقیق کنید و تفاوت‌ها و شباهت‌های آن‌ها را مشخص کنید. + +## Service + +پس از اجرای دیپلویمنت بر روی کوبرنیتیز، نیاز به راهی برای ارتباط با پاد‌های مستقر شده داریم. کوبرنیتیز به صورت خودکار به +هر پاد یک آدرس +IP +منحصر به فرد اختصاص می‌دهد اما با توجه به اینکه ممکن است یک +Deployment +چندین پاد یکسان را مدیریت کند و +نیاز به تقسیم بار بر روی آن‌ها داشته باشیم نمی‌توان از آدرس اصلی پادها استفاده کنیم. علاوه بر این با حذف شدن پادها و +اجرای دوباره آن‌ها این آدرس ممکن است تغییر کند و از این جهت نیز استفاده از آن منطقی نیست. + +کوبرنیتیز برای رفع این مشکل از شی +Service +استفاده می‌کند. این شی به ما اجازه می‌دهد با یک آدرس +IP +مجازی، با یک گروه از +پادها ارتباط برقرار کنیم. همچنین این شی به صورت خودکار بار را بین این پادها تقسیم کرده و در زمان مشکل دار شدن یک پاد +درخواست‌های ما را به آن نمی‌فرستد. + +اطلاعات +Service +را از منابع اصلی کوبرنیتیز خوانده و سعی کنید یک سرویس از نوع +NodePort +و یک سرویس از نوع +ClusterIP +برای +Deployment +مرحله قبل بنویسید و بر روی کلاستر قرار دهید. تفاوت این دو نوع سرویس در چیست؟ diff --git a/docs/devops/09-everything-as-code-concept.md b/docs/devops/09-everything-as-code-concept.md new file mode 100644 index 00000000..4800fe69 --- /dev/null +++ b/docs/devops/09-everything-as-code-concept.md @@ -0,0 +1,4 @@ +--- +title: Everything as Code Concept +description: '' +--- \ No newline at end of file diff --git a/docs/devops/10-ansible.md b/docs/devops/10-ansible.md new file mode 100644 index 00000000..30d4b088 --- /dev/null +++ b/docs/devops/10-ansible.md @@ -0,0 +1,4 @@ +--- +title: Ansible +description: '' +--- \ No newline at end of file diff --git a/docs/devops/11-ci-cd-pipeline.md b/docs/devops/11-ci-cd-pipeline.md new file mode 100644 index 00000000..1351297e --- /dev/null +++ b/docs/devops/11-ci-cd-pipeline.md @@ -0,0 +1,169 @@ +--- +title: CI/CD Pipeline +description: '' +--- + +## مقدمه +فرض کنید به عنوان یک توسعه‌دهنده نرم‌افزار ساعت‌ها از وقت خود را برای توسعه یک نیازمندی مطرح شده و اضافه کردن آن فیچر به پروژه خود صرف کرده‌اید؛ کد توسعه داده شده توسط شما به درستی کار می‌کند، تست‌های نوشته شده پاس می‌شوند و همه چیز در شرایط مطلوب قرار دارد. به عنوان آخرین اقدام کاری امروز می‌خواهید برنچ توسعه جدید را +Push +کرده و در نهایت با +Merge +کردن به روز کاری خود پایان دهید. در چنین شرایطی احتمالا خطای +Merge Conflict +از سمت +Git +آخرین خطایی باشد که دوست داشته باشید ببینید چون برای حل آن و تمام کردن کار خود، باید تفاوت‌های موجود میان کد خودتان و آخرین نسخه کد روی برنچ مقصد را بررسی کنید، قسمت‌های درست را انتخاب کنید، تست‌ها را دوباره اجرا بگیرید و بعد از مطمئن شدن از پاس شدن تمام تست‌ها دوباره برای +Merge +کردن تلاش کنید. +رخ دادن چنین خطاها و مشکلاتی در پروژه‌های کوچک و درصورتی که به ندرت اتفاق بیفتند مشکل خاصی ایجاد نمی‌کند. اما تصور کنید یک تیم توسعه که با سرعت زیاد به اضافه‌کردن ویژگی‌های جدید و تغییر کدهای قدیمی مشغول هستند +(که به اقتضای سرعت زیاد نرخ رخ دادن این مشکلات هم بیشتر می‌شود) + چه هزینه‌های مالی و زمانی زیادی را ممکن است از این بابت متحمل شوند. + +رویکرد +CI/CD +برای حل کردن چنین مشکلاتی و بالا بردن بهروی و سرعت در توسعه‌نرم افزار پدید آمد. در ادامه به بررسی دقیق‌تر این مفهوم می‌پردازیم. + +## CI/CD چیست؟ +در عبارت +CI/CD +بخش +CI +به +Continous Integration +اشاره دارد و بخش +CD +به +Continous Delivery +که هدف آن اتوماتیک کردن و سرعت بخشیدن به فعالیت‌ها و کارهایی است که در گذشته به صورت دستی انجام می‌شد تا یک تکه کد از ادیتور توسعه‌دهنده به مرحله استقرار در محصول قابل استفاده توسط مشتری برسد. این مراحل می‌توانند شامل +بیلد، تست و استقرار باشند. استفاده کردن از این مفاهیم به وسیله طراحی و استفاده از پایپلاین‌های +CI/CD +ممکن می‌شود. +به عنوان یک فرد فعال در حوزه توسعه نرم‌افزار و به خصوص فردی که در حوزه دواپس فعالیت دارد انتظار می‌رود با این مفاهیم آشنا باشیم و به خوبی آن‌ها را درک کنیم. + +:::info نکته +در برخی از منابع +CD +به بحث +Continous Deployment +هم اشاره دارد که در ادامه توضیح داده شده است. +::: + + +![CI/CD Pipeline](./images/12-ci-cd-pipelines-pipeline.png "CI/CD Pipeline") + + +## CI (Continous Integration) +همانطور که گفته شد +CI +مخفف +Continous Integration +است. +CI +به موضوع انتقال کدهای جدید به +Code Base +مشترک پروژه، اجرای تست‌ها و بیلد گرفتن به صورت اتوماتیک و تحت شرایط مشخص اشاره دارد. برای مثال شما می‌توانید فرایند +CI +خود را به گونه‌ای تنظیم کنید که با ایجاد هر +pull request +روی برنچ اصلی ریپازیتوری، یک بار تست‌های برنچ پوش شده اجرا شوند، از آن بیلد گرفته شود و در صورت عدم بروز هرگونه مشکلی، امکان مرج برای توسعه‌دهنده آن برنچ فراهم شود. با استفاده از این مفهوم، مشکلات امنیتی و ارورهای موجود در کد بسیار زودتر از آن که بتوانند اختلالی در پروژه و کار تیم ایجاد کنند شناسایی و آماده رفع شدن می‌شوند. تحت این شرایط حتی اگر چندین توسعه‌دهنده مشغول کار روی یک قسمت از پروژه باشند؛ مشکلات و مسائلی مانند +merge conflict +به حداقل می‌رسند و سرعت توسعه و بازدهی تیم بسیار بهبود می‌یابد. + +## CD (Continous Delivery) +Continous Delivery +مفهومی است که به صورت پیوسته با مفهوم قبلی یعنی +CI +کار می‌کند. پس از اینکه کد توسط مراحل مختلفی که در +CI +وجود دارند تست و بیلد شد +CD، +کار خود را آغاز می‌کند و پروژه را با تمام نیازمندی‌ها و وابستگی‌هایش به صورت یک پکیج واحد در می‌آورد تا بتوان در هر زمانی و در هر محیطی فرایند استقرار آن را به راحتی شروع کرد. استقرار می‌تواند به صورت دستی و یا با استفاده از مفهوم +Continous Deployment +صورت گیرد. + +## Continous Deployment +Continous Deployment +تیم‌ها و سازمان‌های مختلف را قادر می‌سازد تا فرایند استقرار محصولات خود را به صورت کاملا اتوماتیک و بدون نیاز به دخالت انسانی، به روشی که در گذشته صورت می‌گرفت، انجام دهند. با استفاده از این مفهوم می‌توان فرایند رسیدن فیچرها و نیازمندی‌های جدید پیاده‌سازی شده را بهتر مدیریت کرد و آن‌ها را در بهترین حالت و در کمترین زمان ممکن به دست کاربران رساند. + +:::info نکته +شما می‌توانید در سیستم خود +Continous Integration +را بدون داشتن +Continous Delivery +یا +Continous Deployment +داشته باشید؛ اما داشتن +CD +بدون داشتن +CI +بسیار مشکل و عملا غیرممکن است چون شما برای رسیدن به اهداف +CD +به قابلیت‌هایی که رعایت اصول +CI +برای شما فراهم می‌کند مانند ادغام کدهای توسعه داده شده با برنچ اصلی ریپازیتوری و همچنین فرایندهای بیلد و تست اتوماتیک نیاز دارید. +::: + +## فواید CI/CD + +* تحویل سریع‌تر و بهینه‌تر نرم‌افزار از فاز توسعه به فاز استقرار. +* افزایش بهره‌وری تیم با اتوماتیک کردن فرایندهایی که نیاز به صرف زمان داشتند. +* تست کردن تمام تغییرات اعمال شده باعث کاهش ریسک‌های موجود در تحویل یک نیازمندی می‌شود. +* استاندارد و یک پارچه کردن فرایندهای توسعه نرم‌افزار با مشخص کردن گام‌هایی مانند بیلد و تست که با هر تغییر اجرا می‌شوند. + +## پایپلاین CI/CD +برای اعمال مفاهیم و اصول +CI/CD +از پایپلاین‌های +CI/CD +استفاده می‌کنیم. این پایپلاین‌ها با استفاده از ابزارهای مختلف قابل پیاده‌سازی و استفاده هستند و به ما امکان تعریف کردن فازهای مختلف چرخه حیات یک نرم‌افزار را می‌دهند. با این روش ما می‌توانیم پایپلاین‌های دلخواه خود را بر حسب نیازهای تیم طراحی کرده و از آن‌ها جهت افزایش بهره‌وری و راندمان سازمان استفاده کنیم. + +تعدادی از بهترین ابزارهای +CI/CD +در ادامه معرفی شده‌اند. برای آشنایی بیشتر با هرکدام می‌توانید روی نام آن‌ها کلیک کرده تا وارد سایت مربوطه شوید. + +* [Terraform](https://www.terraform.io) +* [Azure Devops](https://azure.microsoft.com/en-us/products/devops) +* [Jenkins](https://www.jenkins.io) +* [GitLab](https://about.gitlab.com) +* [GitHub Actions](https://github.com/features/actions) + +## GitHub Actions +از آنجایی که احتمالا با پلتفرم +GitHub +بیشتر از سایر پلتفرم‌ها آشنا هستید، در این مستند ابزار +GitHub Actions +برای آموزش و تمرکز بیش‌تر درنظر گرفته شده است. همانطور که پیش‌تر نیز توضیح داده شد این ابزار یکی از بهترین ابزارهایی است که می‌توانید با آن یک پایپلاین +CI/CD +برای پروژه خود ایجاد کنید. +سازگاری خوب این ابزار با +GitHub +را می‌توان یکی از بزرگترین نقاط قوت آن تلقی کرد. شما می‌توانید با استفاده از این ابزار به راحتی برای پروژه‌ای که روی +GitHub +دارید یک پایپلاین بسازید. ساختن این پایپلاین به این صورت است که شما با رفتن به تب +Actions +در صفحه اصلی ریپازیتوری مدنظر، می‌توانید پایپلاین خود را ساخته و حتی آن را با دیگران به اشتراک بگذارید. تعداد زیادی از تمپلیت‌های آماده برای کارهای رایج هم وجود دارند که توسط +GitHub +و با توجه به ماهیت پروژه شما در مرحله اول به شما پیشنهاد داده می‌شوند و شما می‌توانید با توجه به نیاز خود آن‌ها را انتخاب کرده و حتی تغییرشان دهید تا دقیقا مطابق نیاز‌های پروژه خودتان شوند. +فایل‌های +configuration +که برای تعریف پایپلاین به کار می‌روند ساختار تعریف شده‌ای دارند. برای آشنایی با این ساختار و همچنین آشنایی بیشتر با +GitHub Actions +و بخش‌های مختلف آن می‌توانید از +[این لینک](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions) +استفاده کنید. +همچنین برای درک عمیق‌تر این ابزار، +GitHub +مستندات بسیار خوبی ارائه داده است که از طریق +[این لینک](https://docs.github.com/en/actions) +می‌توانید به مجموعه‌ای از آن‌ها دسترسی داشته باشید. + +## تمرین +به عنوان تمرین این بخش، برای پروژه‌ای که در فاز +Go +پیاده‌سازی و در فاز +Containerization +داکرایز کرده‌اید؛ با استفاده از ابزار +GitHub Actions +یک پایپلاین بسازید که آن پروژه را بیلد کرده و نتیجه را در +Docker Hub +پوش کند. \ No newline at end of file diff --git a/docs/devops/12-gitops-concept.md b/docs/devops/12-gitops-concept.md new file mode 100644 index 00000000..f99b6b5c --- /dev/null +++ b/docs/devops/12-gitops-concept.md @@ -0,0 +1,4 @@ +--- +title: GitOps Concept +description: '' +--- \ No newline at end of file diff --git a/docs/devops/13-o11y.md b/docs/devops/13-o11y.md new file mode 100644 index 00000000..7d770c57 --- /dev/null +++ b/docs/devops/13-o11y.md @@ -0,0 +1,4 @@ +--- +title: Observability +description: '' +--- \ No newline at end of file diff --git a/docs/devops/14-databases.md b/docs/devops/14-databases.md new file mode 100644 index 00000000..59ed8c4a --- /dev/null +++ b/docs/devops/14-databases.md @@ -0,0 +1,4 @@ +--- +title: Databases +description: '' +--- \ No newline at end of file diff --git a/docs/devops/_category_.json b/docs/devops/_category_.json new file mode 100644 index 00000000..d2e2f611 --- /dev/null +++ b/docs/devops/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "DevOps", + "position": 5, + "link": { + "type": "generated-index", + "slug": "devops" + } +} diff --git a/docs/devops/images/01-Tux.svg b/docs/devops/images/01-Tux.svg new file mode 100644 index 00000000..6b558e7b --- /dev/null +++ b/docs/devops/images/01-Tux.svg @@ -0,0 +1,438 @@ + + + Tux + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/devops/images/01-linux-filesystem-hierarchy-standard.jpg b/docs/devops/images/01-linux-filesystem-hierarchy-standard.jpg new file mode 100644 index 00000000..77bb99c3 Binary files /dev/null and b/docs/devops/images/01-linux-filesystem-hierarchy-standard.jpg differ diff --git a/docs/devops/images/01-linux-shell-arguments-table-picture.png b/docs/devops/images/01-linux-shell-arguments-table-picture.png new file mode 100644 index 00000000..c841f417 Binary files /dev/null and b/docs/devops/images/01-linux-shell-arguments-table-picture.png differ diff --git a/docs/devops/images/01-linux-shell-conditional-expressions-picture.png b/docs/devops/images/01-linux-shell-conditional-expressions-picture.png new file mode 100644 index 00000000..a943328d Binary files /dev/null and b/docs/devops/images/01-linux-shell-conditional-expressions-picture.png differ diff --git a/docs/devops/images/01-linux-shell-loop-expressions-picture.png b/docs/devops/images/01-linux-shell-loop-expressions-picture.png new file mode 100644 index 00000000..cda32521 Binary files /dev/null and b/docs/devops/images/01-linux-shell-loop-expressions-picture.png differ diff --git a/docs/devops/images/04-ha-concept-5-nines-picture.png b/docs/devops/images/04-ha-concept-5-nines-picture.png new file mode 100644 index 00000000..363eda66 Binary files /dev/null and b/docs/devops/images/04-ha-concept-5-nines-picture.png differ diff --git a/docs/devops/images/04-ha-concept-oprational-availablity-formula-picture.png b/docs/devops/images/04-ha-concept-oprational-availablity-formula-picture.png new file mode 100644 index 00000000..a8aae4d3 Binary files /dev/null and b/docs/devops/images/04-ha-concept-oprational-availablity-formula-picture.png differ diff --git a/docs/devops/images/07-docker.webp b/docs/devops/images/07-docker.webp new file mode 100644 index 00000000..b29b95ec Binary files /dev/null and b/docs/devops/images/07-docker.webp differ diff --git a/docs/devops/images/07-vm-vs-container.png b/docs/devops/images/07-vm-vs-container.png new file mode 100644 index 00000000..3915d8bb Binary files /dev/null and b/docs/devops/images/07-vm-vs-container.png differ diff --git a/docs/devops/images/08-kubernetes-logo.png b/docs/devops/images/08-kubernetes-logo.png new file mode 100644 index 00000000..25439a60 Binary files /dev/null and b/docs/devops/images/08-kubernetes-logo.png differ diff --git a/docs/devops/images/12-ci-cd-pipelines-pipeline.png b/docs/devops/images/12-ci-cd-pipelines-pipeline.png new file mode 100644 index 00000000..22f98a0f Binary files /dev/null and b/docs/devops/images/12-ci-cd-pipelines-pipeline.png differ diff --git a/docs/devops/images/reverse_proxy.png b/docs/devops/images/reverse_proxy.png new file mode 100644 index 00000000..fd2a4243 Binary files /dev/null and b/docs/devops/images/reverse_proxy.png differ diff --git a/docs/devops/images/sdlc.png b/docs/devops/images/sdlc.png new file mode 100644 index 00000000..7de8bdf5 Binary files /dev/null and b/docs/devops/images/sdlc.png differ diff --git a/docs/devops/images/test_types.jpg b/docs/devops/images/test_types.jpg new file mode 100644 index 00000000..a9cbb398 Binary files /dev/null and b/docs/devops/images/test_types.jpg differ diff --git a/docs/devops/test_types.jpg b/docs/devops/test_types.jpg new file mode 100644 index 00000000..a9cbb398 Binary files /dev/null and b/docs/devops/test_types.jpg differ diff --git a/docusaurus.config.ts b/docusaurus.config.ts index c42c0657..822756cb 100644 --- a/docusaurus.config.ts +++ b/docusaurus.config.ts @@ -69,12 +69,17 @@ const config: Config = { { type: "doc", docId: "frontend", - label: "فرانت‌اند", + label: "Frontend", }, { type: "doc", docId: "software-engineering", - label: "بک‌اند", + label: "Backend", + }, + { + type: "doc", + docId: "devops", + label: "DevOps", }, { type: "doc",