بالاخره رسیدیم به حضرت کوبرنتیز 😎 اما قبلش اول یه مروری بکنیم که تا الان چه پستهایی داشتیم و بعدش از مرور مفاهیم کانتینر و تاریخچه کوبر شروع میکنیم و قدم به قدم با هم پیش میریم.
خب یه مروری کنیم پستهای قبلی رو:
- دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
- مسیر شغلی دواپس اینجا در مورد مسیر شغلی دواپس و موارد پیرامون آن صحبت کردم.
- چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
- چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
- خودکارش کن، مشکلاتت حل میشه 🙂 در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
- در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
- در مسیر دواپس به داکر رسیدم. (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
- در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
- در مسیر دواپس اینبار: والیوم و نتورک داکر (قسمت سوم) توی این پست در مورد شبکه توی داکر و اینکه چطوری دیتای کانتینر رو میتونیم نگه داریم توضیح دادیم.
- در مسیر دواپس اینبار: داکر فایل ( قسمت چهارم ) توی این پست در مورد اینکه چطور با استفاده از داکر اپلیکیشن مون رو بیلد کنیم و ایمیج بسازیم توضیح دادیم.
- در مسیر دواپس اینبار: کامپوز فایل و داکر کامپوز (قسمت پنجم) توی این پست در مورد اینکه چطور روند دیپلوی کردن سرویسهامون و کانفیگ اونها رو به صورت کد داشته باشیم توضیح دادیم.
- در مسیر دواپس: اینبار داکر سوآرم (قسمت ششم) توی این پست در مورد داکر سوآرم و اینکه چطوری به کمک داکر چنتا سرور رو کلاستر کنیم، توضیح دادیم.
- در مسیر دواپس اینبار: دور و بری های داکر (قسمت هفتم) توی این پست در مورد ابزارهای جانبی که بهمون توی کار با داکر کمک میکنن توضیح دادیم.
- در مسیر دواپس: جمع بندی داکر (قسمت هشتم) توی این پست در مورد امنیت داکر توضیح دادیم و در آخر هم یه سری از بست پرکتیسها و تجربیات خودم رو گفتم.
- تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
- در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
- در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
- در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
- در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
- مسیر Observability (قسمت اول) توی این پست معرفی observability رو داشتیم و مقایسه اش با مانیتورینگ و یه توضیح مختصر هم در مورد اپنتلهمتری دادیم.
- در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
- در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
- در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
- در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
- در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسهاش کنیم.
- در مسیر Observability، میمیر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
- در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
- در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
- در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
توصیه میکنم که حتما این پستها رو هم مطالعه کنید. بریم که ادامه بدیم.
مرور مفهوم کانتینر:
کانتینر رو به نوعی میتونیم بگیم یه فرم مجازیسازی در سطح سیستمعامل گفت، از یه کانتینر میتونیم برای ران کردن برنامههای مختلف از یک میکروسرویس کوچیک تا پروسههای یه اپلیکیشن بزرگ، استفاده کرد.
داخل یک کانتینر تمام کدهای باینری، کتابخانهها و فایلهای کانفیگ و برنامههای اجرایی مورد نیاز اون پروسه وجود دارند، بنابراین کانتینر رو میتونیم هرجایی بالا بیاریم و مثل قبل برامون کار کنه.
نسبت به روشهای دیگه مثل ماشین مجازی و سرور و … کانتینرها سبکترند و راحتتر و با overhead کمتری میشه اونا رو جابجا کرد. توی پستهای داکر در مورد کانتینرها و مقایسه اونها با جزئیات بیشتری توضیح دادیم که میتونید برگردید مطالعه کنید.
ارکستریشن Orchestration:
حالا تا وقتیکه توی یک سرور هستیم با داکر و داکر کامپوز میتونیم به راحتی کانتینرهامون رو مدیریت کنیم ولی اگه ابعاد از چند تا سرور بیشتر بشه دیگه نیاز داریم که از ابزارهای ارکستریشن استفاده کنیم برای مدیریت کانتینرامون که مثل رهبر ارکستر بیایستن بالاسر سیستم ما تا صدای ساز کانتینرامون رو به خوبی بشنویم 🙃
ابزارهای ارکستریشن، ابزارهایی برای automated configuration, management, coordination اپلیکیشنها و سرویسها و سیستمهای کامپیوتری هستن. توی دنیای IT اونا به ما کمک میکنن تا تسکها و ورکفلوهای پیچیده رو به آسانی مدیریت کنیم.
مقایسه ابزارها:
مقایسه داکر و کوبر:
با اینکه این مقایسه به نوعی اشتباهه اما خیلی جاها میبینیم که این دوتا ابزار رو با هم مقایسه میکنن. چرا میگم این مقایسه اشتباهه؟! چونکه داکر یک پلتفرمی است که به با استفاده از یه Container Runtime به ما امکان این رو میده که لینوکس کانتینرها رو داشته باشیم. ولی کوبرنتیز ابزار Orchestration هست کار مدیریت رو انجام میده حتی میتونیم کانتینرهای خود داکر رو با استفاده از کوبرنتیز مدیریت کنیم.
در واقع داکر میتونه اپلیکیشنهای کانتینری رو روی یک نود به صورت پکیج شده نگهداری کنه در حالی که کوبرنتیز برای مدیریت کلاسترهای چند نوده طراحی شده. بنابراین اگر هم ما بخوایم کوبرنتیز و داکر رو مقایسه کنیم بهتره که کوبرنتیز رو با داکر سوآرم که ارکستریتور داکر هست، مقایسه کنیم که در ادامه میریم سراغش!
اگه بخوایم خلاصه طور روند پیشرفت نگهداری اپلیکیشنها رو یه بررسی بکنیم، مرحله اول به این صورت بود که روی همون سیستمعامل شروع میکردیم به نصب کردن فریمورکها و لایبرریهای مورد نیاز و توسعه اپلیکیشن و نهایتا اپلیکیشنمون در قالب یک سرویس روی سرور بالا میآوردیم.
مرحله دوم به این صورت هست که مستقیم روی سخت افزار یا روی سیستمعامل یک هایپروایزر نصب میکنیم که با استفاده از اون میتونیم مجازی سازی رو در سطح hardware انجام بدیم و منابعمون رو به صورت ایزوله شده و محدود به ماشینهای مجازی مختلف اختصاص بدیم و روی اون VM ها حالا اپلیکیشن خودمون رو راهاندازی کنیم. این همون مجازیسازی مرسوم است که خیلی پر استفاده و کاربردی میباشد.
در مرحله سوم با استفاده از ابزاری مثل داکر میاییم کرنل رو به اشتراک میذاریم اما در سطح پروسههای سیستم عامل مجازیسازی رو انجام میدیم و منابع رو به صورت ایزولهشده و مدیریت شده در اختیار کانتینرها میذاریم و سرویسهامون رو با کانتینرها بالا میاریم.
و حالا در مرحله چهارم این مسیر تکاملی مدیریت کانتینر هامون رو هم به یک ابزار کاربلد ارکستریشن میسپاریم تا بتونیم راحتتر اسکیل کنیم و ابعاد بزرگ رو مدیریت کنیم.
مقایسه داکر سوآرم و کوبر:
داکر سوآرم در واقع یه گروهی از چنتا سرور فیزیکی یا ماشینمجازی هست که داکر روی اونها نصب شده و کانفیگشون کردیم تا با هم کلاستر بشن و مدیریت این کلاستر رو ارکستریشن داکر یعنی سوآرم انجام میده.
بنابراین سوآرم به کانتینرها این امکان رو میده که روی کلاستری شامل چندین هاست بالا بیان و کار کنند و باهم ارتباط داشته باشند. این ارتباط رو خود ارکستریشن ایجاد میکنه.
به طور کلی سوآرم خیلی سادهتره از کوبرنتیز اما این سادگی در مقابل دست مارو هم میبنده خیلی جاها.
مثلا سوآرم به ما قابلیت Auto Scaling نمیده در حالیکه کوبر این امکان رو بهمون میده. سوآرم کامیونیتی خوبی داره اما کامیونیتی کوبر بسیار بزرگ و فعاله. سوآرم محدود به قابلیتهای api داکر هست در حالیکه توی کوبر خیلی بیشتر دستمون باز هست اما در مقابلش هم راه اندازی سوآرم به آسونی چنتا دونه کامند ساده هست ولی کوبرنتیز یه مقداری مشکله راهاندازیش. راهاندازی کوبرنتیز پیچیدهتر هست اما در کنارش اونقدر ابزار توسعه پیدا کرده که این کار رو برای ما خیلی ساده و روان کرده.
به نظرم برای سایزهای کوچیک سوآرم بعضا انتخاب مناسبتری هست از کوبرنتیز حتی … گاهی وقتا موقعیکه به شرکتا این پیشنهاد رو میدم برداشت اشتباه میکنن، میگن مثلا طرف کوبرنتیز بلد نیست که میگه سوآرم و … ولی واقعیتش اینه که توی یه اسکیلهای کوچیکی اصرار به داشتن کوبرنتیز اشتباهه. دیدم آدمایی رو که به زور واسه دوتا سرویس کوچیک کلاستر کوبر ستاپ کردن و با اون کلاسترشون پدر خودشون و شرکت و همه رو با هم در آوردن 😬 هر چیزی در جای خودش درسته. به نظر من اگر شما تیم نگهداری و پایش کلاستر ندارید و تعداد تغییراتتون کمه و قابلیتهای زیادی هم از ارکستریشن توقع ندارید سوارم راه حل منطقی برای شما هست. اما اگر یکی از این موارد نقض بشه دیگه سوارم نمیتونه جواب نیازمندی شما رو بده.
مقایسه نومَد و کوبر:
ابزار کمپانی hashicorp برای ارکستریشن یعنی Nomad یک ابزار ساده و منعطف برای ارکستریشن ورکلودهای مختلف هست. مزیت رقابتی که این ابزار نسبت به کوبرنتیز داره این هست که میتونه به صورت Automated لایف سایکل اپلیکیشنهای کانتینری و همچنین غیرکانتینری رو مدیریت کنه. به طورکلی اخلاق هشیکورپ این مدلیه که میره یه جایی از مارکت رو سعی میکنه پوشش بده که کمتر رفتن سمتش. مثلا با Nomad میشه یه اسکریپ بش رو هم توی کلاستر مدیریت کرد و لزومی نداره حتما کانتینری باشه.
از طرفی طراحی Nomad به شکلی هست که از اول برای هندل کردن پیاده سازیهای مالتی دیتاسنتر و یا حالا برای اونایی که به کلادهای درست حسابی دسترسی دارن مالتی region، طراحی شده.
کوبرنتیز به لحاظ کامیونیتی بسیار فعالتر هست و ساپورتی که از کامیونیتی میگیرید قابل مقایسه با Nomad نیست از طرفی Nomad استفاده و یادگیریش ساده تر هست. به طورکلی Nomad سعی کرده برای اسکیلهای خیلی بزرگ کارآمد باشه در عین رعایت کردن سادگی. اما کوبرنتز با اینکه پیچیده تر هست اما دستمون هم توش بیشتر باز هست و کامیونیتی قویتری هم داره. توی Nomad هم با کانتینرهای لینوکسی و هم ویندوزی میتونیم کار کنیم و نسبت به کوبرنتیز کمتر درگیر کانفیگهای متعدد میشیم و کمتر با چالشهای نتورکی مواجه هستیم.
اما اینکه آیا این مزیت رقابتی Nomad باعث میشه که در آینده بتونه مارکت رو بکشونه سمت خودش … سوالیه که باید منتظر جوابش بمونیم ولی حداقل فعلا که کوبرنتیز تو کار خودش یکهتاز هست.
مقایسه اوپنشیفت و کوبر:
پلتفرم متنباز RedHat برای منیج، دیپلوی و توسعه اپلیکیشنهای کانتینری OpenShift هست. اوپنشیفت میتونه یه IDE در اختیار دولوپر بذاره که اپلیکیشنش رو توسعه بده و دیپلوی کنه و مدیریتش روی کلاستر کوبر رو اوپن شیفت انجام بده.
شاید مثلا توی مواردی مثل اینتگریت شدن با یه سری ابزارهای جانبی اوپنشیفت بهتر باشه اما من میگم موقع کار با اوپنشیفت هم اول آخرش باید کوبرنتیز رو بلد باشی، پس دیگه این واسطه رو میشه برداشت و مستقیم رفت سراغ کار کردن با خود کوبرنتیز، اینجوری overhead یادگرفتن یه ابزار دیگه هم کم میشه و میتونی تمرکز بیشتری رو روی کار خودت و نگهداری کلاسترت بذاری.
یه نکتهی دیگهای هم که در مورد اپنشیفت دارم اینه که به صورت رایگان وقتی داری ازش استفاده میکنی یه مشکلاتی باهاش مواجه میشی که خیلی راه حل درست و منطقی براش پیدا نمیکنی و باید کلی بگردی و خودت به خوبی پیداشون کنی. بیشتر این موارد تو ساپورت داره حل میشه که خود ردهت داره ازش درآمد کسب میکنه و به همین راحتی نمیتونی بهش برسی. من پروژههای زیادی دیدم که رفتن سمت کوبرنتیز و مجبور شدن که اپنشیفت خودشون رو تغییر بدن.
خیله خب دیگه از مقایسهها بگذریم و بریم سراغ خود جناب کوبرنتیز 😎
کوبرنتیز Kubernetes :
کوبرنتیز یک پلتفرم متنباز برای مدیریت سرویسها و ورکلودهای کانتینری هست که کانفیگوریشن و اتومیشن رو به صورت توصیفی ساده سازی کرده و کامیونیتی و بزرگ و درحال رشدی هم داره.
طبق این مقاله از سایت کوبرنتیز، تجربه بیش از یک دهه نگهداری سرویسهای کانتینری در گوگل توی پروژههای مختلف، در قالب پروژه Borg متن باز شده که کوبرنتیز هم مسیر همون پروژه رو داره ادامه میده و بسیاری از توسعهدهندگان کوبرنتیز افرادی هستن که قبلا روی بورگ کار میکردن.
توصیه میکنم قسمت اول و قسمت دوم مستند کوبرنتیز که همروش زحمت زیرنویسش رو کشیده حتما ببینید، خیلی جالبه که ببینیم غولهای تکنولوژی برای موندن توی مارکت گاها چه تصمیماتی میگیرن.
اسم kubernetes یکم طولانی هست ازونجایی که هشت حرف بین k , s قراره داره بهش K8S هم میگن! و این ابزار ارکستریشن امروزه تبدیل شده به یکی از محبوبترین ابزارهایی که سازمانهای مختلفی دارن سمتش میرن و به اینکه مهاجرت کنن روی کوبر تا از امکانات بهرهمند بشن، جدیتر و بیشتر فکر میکنن.
اما چرا کوبر؟
توی مسیری که داریم با هم پیش میریم متوجه شدیم که کانتینرها راهحل خوبی برای اجرای اپلیکیشنها توی محیطهای پروداکشنی هستن، بنابراین ما نیاز داریم که بتونیم کانتینرهارو مدیریت کنیم و مطمئن بشیم که سرویسهامون پایدار هستن و اصطلاحا down time نداشته باشیم.
کوبرنتیز با امکاناتی از قبیل مواردیکه در ادامه براتون لیست میکنم رو در اختیار ما میذاره تا بتونیم با استفاده از اونها کانتینرهامون رو مدیریت کنیم و توی اسکیلهای بزرگ حتی بتونیم سرویسهای پایداری رو داشته باشیم.
- Service discovery and Load balancing
- Automated rollouts and rollbacks
- Automatic bin packing
- Self-healing
- Secret and configuration management
تصور کنید ابزاری در اختیار دارید که شما براش توضیح میدید و میگید مثلا از این ایجنت مانیتورینگ من توی هر سرورم یه دونه بیار بالا، از سرویس فرانتاند سایتم مثلا میخوام چهارتا دونه بالا باشه که هرکدومش حداقل فلان میزان cpu و فلان میزان ram رو باید داشته باشند و حتی بهش میگید که حواست باشه که از مصرف کانتینرهای این سرویس من بالا رفت مثلا اگه ۸۰ درصد ram شون زیرلود پر شد اونوقت تو شروع کن و خودت تعداد اونها ببر بالا مثلا تا سقف ۴۰ تا دونه!!! و بعدش که لود کمتر شد دوباره خودت این تعداد رو کم کن ولی دیگه از سه تا کمتر نشه و همیشه حداقل سه تا بالا باشه.
یا مثلا میخوایم آپدیت انجام بدیم من بهت میگم که مثلا دوتا دوتا از کانتینرهای سرویس قبلی بیار پایین و دوتا ازین نسخه جدید جایگزینش کن، یا نه اصلا اگه الان پنجاه تا دونه از نسخه قبلی بالا هست اشکالی نداره من منابع کافی در اختیارت میذارم تو پنجاه تا هم از نسخه جدید اول بیار بالا من تست بگیرم مطمئن که شدم بعد کلا لود مشتری رو جابجا کن روی این نسخه جدید …
میبینید؟ اگه تجربه نگهداری سرویسهای یه مقدار بزرگ توی پروداکشن رو داشته باشید متوجه میشید که اینا کارای بزرگی هستن و ابزاری که این توانایی هارو به ما بده، ابزار ارزشمندیه. کمکم داره معلوم میشه چرا کوبر سروصدا کرده 🙂
طبق گزارشهایی که داده شده درصد زیادی از کمپانیهایی که سرویسهای کانتینری نگهداری میکنن توی محیط پروداکشنشون هم از کوبرنتیز استفاده میکنند.
مدارک کوبرنتیز :
سه تا مدرک هست که برای کوبرنتیز هستن و مدارک معتبری هستن که CNCF با همکاری Linux Foundation اونها رو بعد از آزمونهایی که میگیره به افراد میده، به نام های CKAD, CKA, CKS که در ادامه بررسیشون میکنیم. دوتا مدرک دیگه هم هست KCNA و KCSA که اونا رو هم توضیح میدم. کوبرنتیز ابزار بسیار بزرگی هست که از زوایای مختلف میشه به اون نگاه کرد که این موضوع به خوبی تو مدرکهای کوبرنتیز قابل مشاهده است.
- Certified Kubernetes Administrator (CKA)
هدف این مدرک ارزیابی تواناییهای ادمین کلاستر کوبر هست که در قالب یک آزمون عملی انجام میشه و این مدرک برای افرادی هست که نگهداری کلاستر رو انجام میدن. این نگاه سمت administration خود کوبرنتیز است.
- Certified Kubernetes Application Developer (CKAD)
هدف این مدرک ارزیابی توانایی های افراد برای استفاده از کوبرنتیز برای build و مانیتور و Tshoot اپلیکیشنهایی که توسعه میده هست و مناسب افرادی هست که از ساید توسعهدهنده ها هستن اما اپلیکیشن اونا قراره روی کوبر مستقر بشه. اینجا نگاه سمت استفاده کننده کوبرنتیز است. یعنی شما به نگهداری کلاستر کاری ندارید و به عنوان مشتری دارید از خود کوبرنتیز استفاده میکنید.
- Certified Kubernetes Security Specialist (CKS)
افرادی که بخوان این مدرک رو بگیرن ابتدا باید CKA رو داشته باشند و بعد از اون میتونن سراغ این مدرک بیان که بیشتر هدفش تمرکز روی بستپرکتیس ها و امن کردن کانتینرها هست و دانش امنیتی افراد رو میسنجه. این نگاه برای افزایش امنیت در استفاده از کوبرنتیز است.
- Kubernetes and Cloud Native Associate (KCNA)
این هم یک مدرک دیگه هست برای افرادیکه کمتر حرفهای هستن که آشنایی اولیه با محیطهای کلاد نیتیو و اکوسیستم ابری رو میسنجه و آشنایی اولیه با کوبرنتیز که میتونی به نوعی برای آمادگی قبل از سه مدرک دیگه ازش استفاده بشه.
- Kubernetes and Cloud Native Security Associate (KCSA)
این هم مثل قبلیه اما واسه سکیوریتی !
به کسی هم که هر پنج مدرک رو با هم میگیره اصطلاحا Kubestronaut میگن که اینجا میتونید بیشتر در موردش بخونید.
ما تو ایران هستیم نمیتونیم این مدرکهای رو بگیریم و اونا ما رو تحریم کردن و بهمون نمیدن. البته ایرانیها میتونند بگیرن ولی اینکه تو کشور ایران هستیم نمیشه. دیدم که بعضیها با مسافرت تونستن بگیرن ولی نرمالی اگر فقط سفر کردی نرمالی بهت نمیدن. برای امتحانش هم یه نفر آنلاین میشه و بررسی میکنه که چیت نکنی و درست امتحان بدی. کلا مدرکهای معتبری هست که توصیه میکنم اگر امکانش رو داشتید حتما براش اغدام کنید. سایتهای زیادی هستن که کمکتون میکنند که این مدرکها رو بتویند به خوبی بگیرید که این سایت یکی از بهترینها هست و میتونید ازش استفاده کنید.
بسیار خب این میشه قدم اولمون در مسیر کوبرنتیز، تو پستهای بعدی میریم به سراغ این ابزار و بیشتر باهاش آشنا میشیم.
مراقب خودتون باشید. 🌹🐳🌹