https://virgool.io/feed/@ariyanafshar15 fa 2026-06-16 13:28:31 https://files.virgool.io/upload/users/1597402/avatar/vUcbty.jpeg?height=120&width=120 https://virgool.io/@ariyanafshar15 https://virgool.io/@ariyanafshar15/%D9%85%D8%B2%D8%B1%D8%B9%D9%87-%D8%AD%DB%8C%D9%88%D8%A7%D9%86%D8%A7%D8%AA-a5i4bs15knwa تو دوران آموزشی سربازی دوستایه خوبی پیدا کردم که با دوتاشون بیشتر از بقیه صحبت میکردم و بچه ها بشدت اهل کتاب بودن مخصوصا ممد رضا که باعث شد من ۳ تا کتاب بخونم تو این دو ماه ( زیاده ) یه کتاب بهم معرفی کرد به نامه مزرعه حیوانات از جورج اورول ( که پیشنهاد میکنم شما هم بخونید )تویه این کتاب خوک ها برتری بیشتری نسبت به بقیه حیوانات دارن و حالا داستان چیه؟ این که خلاصه خوکا میان تو مزرعه انقلاب میکنن و میشن رهبر مزرعه و همه حیوانات عشق میکنندوتا خوک بودن که می شدند یه جورایی رهبر حیوانات که یکی ناپلئون بود و اسم دیگری اسنوبال…ناپلئون دنبال انقلاب بود و اسنوبل علاوه بر انقلاب میخواست حیوانات پیشرفت کنن و دلیل اصلی حمایت حیوانات از این انقلاب این بود که دیگه نمیخواستن غذاشون ،تخم مرغ هاشون، شیرشون و … توسط انسان ها مصرف بشهخلاصه اسنوبال همینجوری دنبال پیشرفت بود برای همه حیوانات برعکس ناپلئون …داستان اساسی از جایی شروع میشه که اسنوبال مکرر مقابل ناپلئون می ایسته و میگه این کارایی که داری میکنی اشتباهه ! مثل چی ؟ شروع میکنه دوباره تخم مرغ ها رو میفروشه به ادما و جیره غذایی رو همشو میده به خوکا و …اسنوبل میاد یه آسیاب بادی طراحی میکنه که همه حیوانات باهم بتونن درستش کنن و دیگه برای جمع کردن غلاتشون اذیت نشنشبش ناپلئون ۴ تا سگ دست آموز( البته بهتره بگم خوک آموز که جان بر کف ناپلئون هستن) میندازه دنبال اسنوبال و اسنوبال از ترس پا به فرار میزاره( بالاخره اسنوبل مخالف سیاست های ناپلئون بود )و از اینجا به بعدش جالبه ! که به حیوانات میگه اسنوبال خیانت کار بوده من خودم میخواستم اسیاب بادی رو بسازم اسنوبال طرح منو دزدیده و یا وقتی غلات و جیره زود تموم میشد میگفت اسنوبال شب که شما خواب بودین اومده از سوله دزدی کرده یا کلا هر اتفاق شوم و بدی رو مینداخت تقصیر اسنوبال که البته اخرشم خوده ناپلئون با ادما نشستو برخاست کرد …حالا علت اساسی حرفی که زدم چیه؟؟همه ما تویه یه سری شرکت کار میکنیم ( کاری ندارم که مملکت خودمون همین داستان مزرعه حیواناته ) که دقیقا این داستان داره پیاده میشه برای مثال به اقای ایکس میگی دوست عزیز من میخوام برم مرخصی یا سیستم من مشکل داره یا … بعد اون دوست عزیز میاد به شما میگه اره باید برم با فلانی صحبت کنم ببینم میشه کاری انجام داد یا نه ( همون مدیر بالادستیش)و بعدش میاد میگه اره گفت نمیشه تقصیره اونه من تمام تلاشمو کردم! در صورتی که حتی تا دمه در اتاق طرف هم شاید نرفته باشه یا یه مثال دیگه : طرف دومین روزه که یک سمت رو گرفته و چنتا کارمند داره و برای بدست اوردن این سمت دقیقا مثل ناپلئون رفتار کرده که اره بیام بهترینا میشه فلان میشه بهمان میشه در نتیجه وقتی به اون سمت رسید بد ترینا شد به جای بهترینا :) هر شخصی هم بگه من اینو تجربه نکردم قطعا که تو ایران یا کار نمیکنه یا جز 1 درصده خود من به شخصه جاتون خالی نباشه چندین بار در شرکتای گوناگون لمس کردم این موضوع رو ....در اخر هم خوکا هرچقد هم لایه گل باشن ، کثیف باشن و غذای نامطلوب بخورن داخل مزرعه برتری دارن در اخر حتما کتاب رو بخونید Arynishere Arynishere Sat, 22 Jul 2023 16:39:24 +0330 https://virgool.io/CodeLovers/kubernetes-%D8%A8%D9%87-%D8%B2%D8%A8%D8%A7%D9%86-%D8%B3%D8%A7%D8%AF%D9%87-tojx0gfi0goe کوبرنتیز چیست ؟در ابتدا باید راجب orchestrator و Containerization صحبت کنیم :Containerization به معنی این هست که ما یک image داشته باشیم و از روی اون یک containerبالا بیاریم و اون رو sandboxکنیم (stack tcp ip به لطف namespaceدر container ها از هم دیگر جدا هست و در sandbox تویه container ها endpoint ها قرار میگیرد که دارای mac/ipهستن )Orchestrator به این معانست که اگر ما چندین Node داشته باشیم و با هم cluster اشون کنیم و container روی آن ها بالا بیاریم ، k8s میاد به اونها task ها رو scheduleمیکنه و زمانی بندی میکند و علاوه بر اون load balance هم صورت میگیرد ولی خودش container ای run نمیکند .CRI چیست ؟Container runtime interface ، با توجه به صحبت بالا گفتیم که k8s خودش container بالا نمیاره و از طریقCRI این امر انجام میشه که ما CRI های مختلفی داریم از جمله CRI-O , CntainerD,Docker Engine که میتوان از انها استفاده کرد .Runtime class چیست ؟امکان این هست که ما روی هر node مون بیایم و CRI مختلف بیارم بالا که میتونیم بگیم برای این که container مد نظر رو بیاریم بالا از کدام cri استفاده کنهSWARM & K8Sما برای مقایسه ، باید به این موضوع بپردازیم که فرق Docker Swarm با K8S چیست ؟یکی از مواردی که مورد بحث است این هست که k8s cluster از ابزار 3 RD party استفاده میکند که این امر دسته واحد DevOps یا Operation رو باز تر میکنه چرا که swarm محدود به یک سری storage / network بود اما در k8s به لطف ابزار 3 RD party ما دستری بیشتری به عنوان network / storage ها داریم که مانند CRI این دو قسمت هم با CNI/CSI هندل میشود یعنی container network interface & container storage provider(interface)مثالی از network های 3 rd party میتوان به weave /flannel /calico و .. اشاره کرد و در کنار آن برای storage هم میتوان به ceph , nfs و ... اشاره کردControl plane and compute machine در کوبرنتیز :ما تویه Kubernetes cluster مون Node master ( control plane ) و node worker ( compute machine )داریم که راجبشون با توجه به عکس بالا صحبت میکنیم :داخل Node master ما 4 بخش مهم داریم :API servKube SchedulerKube Control ManagerEtcd DBو در Node worker هم 3 بخش مهم داریم :KubeletKube ProxyCRIنحوه کار master با worker به این شکل هست که زمانی که RQ میاد سمت master ابتدا API Server اون رو میگیره و پردازش میکنه سپس به Scheduler ارسال میشه و از اون سمت scheduler اون رو برای worker task میکنه و به kubelet ارسالش میکنه و زمانی که worker اون task رو به اتمام برسونه به kubelet یک response بر میگردونه و در این حین همزمان kube controller هم با kubelet روی worker در ارتباط هست که از stateپاد های روی workerمطلع بشه و اونا رو داخل endpoint برای سرویس دهی قرار بدهKuber proxy هم Packet های شبکه ای که میخواد بره سمت container ها رو دریافت میکنه و به container ها میدهدعلاوه بر اون ما روی master یک db key value داریم که موارد مهمی از جمله object ها داخل اون ذخیره میشه .نحوه دریافت Image و راه اندازی container در کوبرنتیز :در گذشته این امکان وجود نداشت که kubelet مستقیم به API های Docker INC متصل بشه چرا که Docker INC از Solution Cloud Native Foundation پشتیبانی نمیکرد و برای اتصال در این میان از یک wrapper استفاده میشد به اسم docker shim که یک RestAPI بود و درخواست درست Kubernetes رو به درخواست اشتباه تغییر میداد و به Container D ارسال و اون container بالا میومد ولی با گذر زمان این امکان فراهم شد که ارتباط مستقیم بین kubelet و container D با نصب مستفیم خوده container D رخ دهد .دوستان برای درک بهتر و مفهومی تر مطالب بالا پیشنهاد میکنم حتما youtube من رو داشته باشید و ویدیو که با این موضوع گذاشتم رو مشاهده کنید : کوبرنتیز به زبان ساده Arynishere Arynishere Mon, 20 Jun 2022 22:01:18 +0430 https://virgool.io/CodeLovers/%DA%86%D8%B1%D8%A7-cicd-%D8%A8%D9%87-%DA%A9%D8%A7%D8%B1%D9%85%D9%88%D9%86-%D9%85%DB%8C%D8%A7%D8%AF-%DA%86%DB%8C-%D9%87%D8%B3%D8%AA-kz3hdpxo0lrk چرا CI CD بوجود اومد ؟ چی کار میکنه حالا ؟این دو حرف یعنی CI/CD مخفف دو کلمه continuous integration و continuous delivery یا continuous deployment هست که البته این که کدوم باشه بستگی به شرایط داره !اولی با CI شروع میکنیم : ( برای درک بهتر تمام صحبتا حتما پیشنهاد میکنم روی لینک youtube کلیک کنید تا با ویدیو راحت تر بحث رو درک کنید ) تویه دوران قدیم ( در این لحظه صفحه سیاه سفید میشود :) ) تیم های Developer که کدهاشون رو مینوشتن بعد از این که develop میشد میدادن به یک تیم ای به نام integration ، که این تیم code ها رو بررسی میکرد و merge میزد و ماژول هایی که استفاده شده بود تویه هر کد رو بررسی میکرد که باهم اختلالی نداشته باشند و اگر داشت دوباره کد رو به تیم Developer بر میگردوند .بعد از اون اگر کد اوکی بود داده میشد به تیم operation برای build زدن و test کردن کد که بازم اگه اونجا مشکلی بود مجدد تیم operation اونو میداد به تیم developer برای بررسی مجدد کد و این loop تا زمان که build درست انجام بشه و یک app یا pkg یا هر نسخه ای که قابل نصب باشه داشته باشیم ادامه داشت ...بعد از دیدن این موضوعات بحث CI رو کار اومد که 2 تا مورد خیلی مهم رو از موارد زیر مجموعش هندل میکرد :1-کد ها زمانی که میان تویه Repository ما ( یا همون centralize repo ) خودشون به صورت automate اونجا merge بخورن و تویه یک جابه صورت یکپارچه نگهداری شوند. 2- کدهایی که merge میخورن و تویه central repo قرار میگیرن ، هر زمانی که بخوایم روی یک Build server اون رو build کنیم ( compile کنیم که در نهایت به ما یک نسخ مثل pkg بده ) و بعد از Build به صورت auto روی server ای که ما به عنوان تست تعریف کردیم pkg رو نصب کنه ( به واسطه task و pipeline ای که براش نوشته شده ) .پس در نتیجه CI :1-مرحله merge2-مرحله Build 3-مرحله Test رو به صورت auto هندل میکنه و اون sprint که تایید شده رو به راحتی pass میکنه و باعث ایحاد gap های طولانی مثل دوران قبلی نمیشه .حالا میخوایم راجب CD صحبت کنیم :مخفف continuous delivery/deployment میشه حالا چرا دوتا ؟ راجبش صحبت میکنیم .من این قسمت رو برای راحتی درک مطلب به سه بخش تقسیم :1-manual 2-automatic3-approvalاگر از manual شروع کنیم در اصل میشه همون بخش delivery حالا یعنی چی ؟زمانی که من بعد CI که یک pkg آماده نصب تویه env ام دارم ، اگر اون رو بیاد شخص/تیم ای نصب کنه مثلا operation یا DevOps به این عمل میگن manual .در وجه دیگه اگر این pkg مستفیم بعد CI بره تویه env نصب بشه میشه auto و هیچ نیرو انسانی توش دخیل نباشه بعد از مرحله CI ولی خب یک مشکلی که داره این هست که شما اینجا CAB ندارید ( CAB چی هست ؟ ) و علاوه بر اون وقتی من بعد CI بدون تست بیام بگم بره اون pkg رو نصب کنه دیگه خودتون تا آخرش رو میتونید دریابید:) احتمال ایجاد مشکل تویه prod امون خیلی میره بالا از نظر عدم down time و شکایت end user ها .و قسمت آخر هم approval میشه که یک شخص یا CAB یا مدیر یا هر شخص بالا دستی اون Deploy شدن تویه env prod مون رو تایید کنه و بعد از اون ، pkg وارد محیط مورد نظر میشه و نصب میشه و Up میشه و حالا که این اتفاق تویه تایمی میوفته که اکثریت از اون app استفاده نمیکنن ( عموما بامداد ) هم باعث میشه شکایت از app کاهش پیدا کنه هم اگر که pkg مشکل خورد راحت تر rollback انجام بشه .در آخر ما دو بحث دارم راجب 1-CICD Push Based2-CICD pull Basedکه تویه قسمت های بعدی راجبش صحبت میکینیم ولی پیشنهاد میکنم قبل از شروع حتما مقداری آشنایی با GIT و بحث Repository داشته باشید که راحت تر بتونید متوجه موضوعات بشید دمتون گرم . Arynishere Arynishere Thu, 19 May 2022 10:04:00 +0430 https://virgool.io/CodeLovers/%D8%AF%D8%A7%DA%A9%D8%B1-%D8%B1%D8%A7%D8%AD%D8%AA-%D9%88-%D8%AF%D9%88%D8%B3%D8%AA-%D8%AF%D8%A7%D8%B4%D8%AA%D9%86%DB%8C-jaeo78hns1tp مقدمهدقت کرده باشین از سال 2015 خیلی از افراد به سمت داکر رفتن و خیلی از شرکت ها هم تویه این cycle قرار گرفتنو رفتن جلو ! اصلا چی شد که داکر روی کار اومد ؟ اصلا چرا داکر ؟ اصلا خوده داکر چیه و .... قرار اینجا راجبش صحبت کنیم که البته توصیه میکنم اگه میخواین توش Deep تر بشین به youtube من سر بزنید. چرا داکر ؟اگه یادتون باشه قبل از روی کار اومدن داکر ، virtualization و بحث hypervisor بوجود اومده بود و قبل اون هم bare metal server ها بودن که راجبشون صحبت میکنیم :سرور های Bare metal :اون اوایل که سرور های Bara metal وجود داشت ، از لایه HW و OS و بعد اون هم app های که روشون قرار میگرفتن تشکل میشدن اما یه مشکلی اینجا وجود داشت ! اونم این بود که اصلا بحث isolate ای بین app هایی که میاوردیم بالا وجود نداشت یعنی مثلا app1 ، app2 رو به راحتی بهش access داشت و میتونست از اون استفاده کنه ! که این یعنی access کامل هر دو app به resource هم دیگه و همین باعث میشد که هر دوتاشون به هم دیگه access داشته باشن از جهتی من باید برای هر app مقدار زیادی resource استفاده میکردم که فقط برای اون app باشه که خب این اصلا نبست به سال 2022 که الان توشیم منطقی نبود ( البته اون موقع بود )مجازی سازی و virtualization :زمانی که مجازی سازی روی کار اومد تویه لایه os یک قسمت یا بهتر بگم یک feature قرار گرفت به اسم hyoervisor که باعث تغییر زیادی از زمان bare metal ها شد ! هم باعث شد app ها از هم isolate بشن و هم به هرکدوم از app ها resource جداگانه میداد اما یک مشکلی که داشت دقیقا همین قسمت resource بود اما چرا ؟!فرضاً من یک app دارم و نیاز به 30GB Storage داره ، تا اینجاش مشکلی نداره اما وقتی من این app رو نیاز ندارم اون 30GB آزاد نمیشه ! برای تست این موضوع بهتون پیشنهاد میکنم یک ubuntu نصب کنید روی vm و بهش 30GB فضا بدین و بعد ماشین که اومد بالا shutdown اش کنید ، حالا وارد drive c بشین ( اگر زمان assigned کردن storage اون location اش رو تغییر ندین خودش میره از drive c اون مقداری که شما میخواین رو بر میداره ) اگه دقت کنید با توجه به خاموش شدن ماشین هنوز هم اون فضا اشغال هست . جدا از این موضوع مصرف resource هنوز هم در این سناریو بالا بود و بهنیه مصرف نمیشد با این که hypervisor وظیفه مدیریت resource ها رو بین hardware و vm داشت .virtualization اوت bare metal و داکر و containerization :تقریباً از سال 2012/2015 containerization روی کار اومد که خیلی به صرفه تر بود : از نظر مصرف منابع ، isolate شدن مصرف resource بین app ، عدم write مستقیم app روی os .از موارد دیگه ای که باعث شد سمت containerization بریم ، بحثی مثل agile , resource consumption,zero down time و ... بود ساخنارش به چه شکل بود ؟ لایه containerization بین os و app ها قرار میگرفت بدین شکل که هیچ app ای با اون یکی app در ارتباط نبود مگر این که خودمون میخواستیم یا حتی اگر ما از یه app یا سرویس چنتا scale میکردیم ، فقط اندازه یکی استفاده میشد یعنی چی ؟ یعنی مثلا nginx مون 100MG فضا میخواست و اگه من از nginx ام 3 تا میوردم بالا بازم همون 100MG ای که یه بار use شده وجود داشت یعنی این مورد به 300MG ارتقاع پیدا نمیکرد .از جهتی با توجه به قابلیت COW روی Docker روی Image یا app مون ما هیچ write ای نداشتم و فقط read میکردین و اگه چیزی میخواستیم write کنیم روی directory که ایجاد شده بود به نام cow(copy on write ) نوشتن رو انجام میداد .bare metal & virtualization & containerizationکانتینر زمانی که ما داکر رو استفاده میکنیم در اصل داریم یک سری کانتینر میاریم بالا یعنی چی ؟ مثلا من به nginx نیاز دارم ، پس اول image اش رو باید بگیرم و بعد container رو از روی اون image میاریم بالا . حالا چرا container ؟ دقت کرده باشین یک سری افراد هستن خونه هاشون همیشه باهاشونه پشت ماشینشون ( تویه فیلما خیلی هست اگه دیده باشین ) این خونه ها اکثرا برق و گاز ندارن و باید به یه منبعی وصل بشن برای گاز، برق و آب . دقیقا container هم همینطوریه یعنی چی ؟ فقط باید بهش ram/cpu بدیم تا شروع به کار کردن کنه و اون سرویس یا مثلا ngixn که میخواستیم رو بیاره بالا و ما استفاده کنیم امیدوارم تا به اینجای مطالب براتون جذاب بوده باشه و اگر میخواین داکر رو به زبان ساده و روان یاد بگیرید حتما به channel youtube من سربزنید . در بخش های بعدی هم راجب image و بقیه موارد صحبت کنیم ... Arynishere Arynishere Mon, 18 Apr 2022 22:37:45 +0430