Kubernetes up and running
کوبرنتیز یک orchestrator اوپن سورس است که ابتدا توسط گوگل توسعه یافت و معرفی شد. تا سال ۲۰۱۴ یکی از معروف‌ترین ابزارهای open source در مارکت شده بود.
کوبرنتیز ثابت کرد که می‌تواند سیستم‌های توزیع شده را در تمام مقیاس‌ها مدیریت کند. از یک کلاستر رزبری‌پای تا یک دیتاسنتر مجهز و حرفه‌ای.
در دنیای distributed systems تمامی سرویس‌های ما باید reliable و scaleable باشند. اما این به چه معنی است؟
یک برنامه میکروسرویس را درنظر بگیریم که دارای سرویس‌های مختلفی است. کوبرنتیز وظیفه orchestrate کردن این پروژه را بر عهده گرفته است.
ما باید مطمئن باشیم که تمامی درخواست‌های ما در این شبکه بین سرویس‌ها جابجا میشود. پس در این بخش نیاز داریم که این شبکه قابل اعتماد(reliable) باشد.
اما این به تنهایی کافی نیست, ممکن است بخواهیم این سیستم را گسترس دهیم و به اصطلاح scale کنیم. کوبرنتیز این امکان را نیز برای ما مهیا کرده است.
مردم دلایل مختلفی برای استفاده از کوبرنتیز دارند, برای مثال:
• Development Velocity
• Abstracting your infrastructure
• Efficiency
• Cloud native ecosystem
در این پست می‌خواهیم اهمیت توسعه سریع با کوبرنتیز را مرور کنیم.
سال‌ها پیش که نرم‌افزارها روی CD ها ذخیره و به فروش می‌رسیدند, چندان مهم نبود که اپدیت‌ها در چه زمانی ریلیز می‌شوند, اما اکنون که برخی محصولات, به صورت روزانه اپدیت می‌دهند, بسیار مهم است که با کمترین downtime نسخه جدید را برای کاربران عرضه کنیم.
کوبرنتیز باعث میشود دیپلوی کردن اسان‌تر شود.
تصور کنید برای یک دیپلوی ساده, باید یکی از راه های زیر را دنبال کنید:
⁃ وارد کانتینر شوید و کد جدید را pull کنید
⁃ ایمیج را build کنید و کانترنر قدیمی را stop و با ایمیج جدید یک کانتینر بسازید
هردوی این کارها باعث میشود که ما downtime زیادی داشته باشیم. حال سناریو زیر را تصور کنید:
کوبرنتیز یک instance جدید با کد جدید بسازد و وقتی که مطمئن شدیم که کد درست بالا امده, با اینستنس قبلی جابجا کنیم.
جالب نیست؟ بنظر من که خیلی جالبه!
یکی دیگر از قابلیت‌های جذاب کوبرنتیز self healing بودن آن است.
کوبرنتیز مدام تلاش می‌کند که درصورت بروز هرگونه مشکل, سرویس شما down نشود.
برای مثال در گذشته باید افرادی استخدام می‌شدند که هرگاه یک alert دریافت می‌کردند, باید سریعا سرویس را repair می‌کردند, اما الان کوبرنتیز باعث شده که دیگر نیازی به این افراد نداشته باشیم.
در این درس ۲ مورد از قابلیت‌های کوبرنتیز را خواندیم. در درس های بعد کم کم به شناخت کوبرنتیز و کامپوننت‌های داخلی آن می‌پردازیم.
#kubernetes_up_and_running
@Code_Crafters
کوبرنتیز یک orchestrator اوپن سورس است که ابتدا توسط گوگل توسعه یافت و معرفی شد. تا سال ۲۰۱۴ یکی از معروف‌ترین ابزارهای open source در مارکت شده بود.
کوبرنتیز ثابت کرد که می‌تواند سیستم‌های توزیع شده را در تمام مقیاس‌ها مدیریت کند. از یک کلاستر رزبری‌پای تا یک دیتاسنتر مجهز و حرفه‌ای.
در دنیای distributed systems تمامی سرویس‌های ما باید reliable و scaleable باشند. اما این به چه معنی است؟
یک برنامه میکروسرویس را درنظر بگیریم که دارای سرویس‌های مختلفی است. کوبرنتیز وظیفه orchestrate کردن این پروژه را بر عهده گرفته است.
ما باید مطمئن باشیم که تمامی درخواست‌های ما در این شبکه بین سرویس‌ها جابجا میشود. پس در این بخش نیاز داریم که این شبکه قابل اعتماد(reliable) باشد.
اما این به تنهایی کافی نیست, ممکن است بخواهیم این سیستم را گسترس دهیم و به اصطلاح scale کنیم. کوبرنتیز این امکان را نیز برای ما مهیا کرده است.
مردم دلایل مختلفی برای استفاده از کوبرنتیز دارند, برای مثال:
• Development Velocity
• Abstracting your infrastructure
• Efficiency
• Cloud native ecosystem
در این پست می‌خواهیم اهمیت توسعه سریع با کوبرنتیز را مرور کنیم.
سال‌ها پیش که نرم‌افزارها روی CD ها ذخیره و به فروش می‌رسیدند, چندان مهم نبود که اپدیت‌ها در چه زمانی ریلیز می‌شوند, اما اکنون که برخی محصولات, به صورت روزانه اپدیت می‌دهند, بسیار مهم است که با کمترین downtime نسخه جدید را برای کاربران عرضه کنیم.
کوبرنتیز باعث میشود دیپلوی کردن اسان‌تر شود.
تصور کنید برای یک دیپلوی ساده, باید یکی از راه های زیر را دنبال کنید:
⁃ وارد کانتینر شوید و کد جدید را pull کنید
⁃ ایمیج را build کنید و کانترنر قدیمی را stop و با ایمیج جدید یک کانتینر بسازید
هردوی این کارها باعث میشود که ما downtime زیادی داشته باشیم. حال سناریو زیر را تصور کنید:
کوبرنتیز یک instance جدید با کد جدید بسازد و وقتی که مطمئن شدیم که کد درست بالا امده, با اینستنس قبلی جابجا کنیم.
جالب نیست؟ بنظر من که خیلی جالبه!
یکی دیگر از قابلیت‌های جذاب کوبرنتیز self healing بودن آن است.
کوبرنتیز مدام تلاش می‌کند که درصورت بروز هرگونه مشکل, سرویس شما down نشود.
برای مثال در گذشته باید افرادی استخدام می‌شدند که هرگاه یک alert دریافت می‌کردند, باید سریعا سرویس را repair می‌کردند, اما الان کوبرنتیز باعث شده که دیگر نیازی به این افراد نداشته باشیم.
در این درس ۲ مورد از قابلیت‌های کوبرنتیز را خواندیم. در درس های بعد کم کم به شناخت کوبرنتیز و کامپوننت‌های داخلی آن می‌پردازیم.
#kubernetes_up_and_running
@Code_Crafters
❤8
خب برید راجب socketify بخونید و بعدا هرکسی گفت پایتون واسه وب ضعیف و کند هستش، جواب دندان شکن بهش بدید
در کنارش هم تاسف برای دوستانی که با حرف بقیه در خصوص کند بودن فریمورک‌های پایتون، رفتن سمت گو
#موقت
در کنارش هم تاسف برای دوستانی که با حرف بقیه در خصوص کند بودن فریمورک‌های پایتون، رفتن سمت گو
#موقت
🔥13👎6❤1👍1
Kubernetes up and running - Lesson 2
هنگامی که محصول شما رشد می‌کند, شما باید هم محصول و هم تیم توسعه خود را scale کنید. خوشبختانه کوبرنتیز این قابلیت را به ما میدهد که به راحتی بتوانیم محصول خود را scale کنیم. اما چه چیزی باعث میشود که scale کردن در کوبرنتیز اینقدر ساده باشد؟
به سبب وجود داشتن معماری decoupled, کامپوننت‌ها مستقل هستند و به کمک api و service load balancer ها با هم ارتباط ایجاد می‌کنند.
کوبرنتیز به شما این اجازه را میدهد که از یک کانتینر چندین replica داشته باشید که برای اضافه یا کم کردن آن نیاز دارید فقط یک عدد را در فایل کانفیگ تغییر دهید. حتی می‌توانید این تصمیم گیری را بر عهده کوبرنتیز بگذارید که چند رپلیکا از اپلیکیشن داشته باشیم.
کوبرنتیز نه تنها محصول شما را scale می‌کند, بلکه می‌تواند تیم شما را نیز scale کند!
تحقیقات نشان داده است که یک تیم ایده‌ال باید ۶ الی ۸ عضو داشته باشد. به این تیم‌ها “two pizza team” نیز می‌گویند.
این تیم‌ها تصمیمات راحت‌تری می‌گیرند و عموما تسک‌ها سریع‌تر deliver می‌شوند چرا که کانفلیکت‌های کمتری در کد ایجاد میشود.
اگر یک کدبیس بزرگ داشته باشیم, قطعا هنگامی که کد را توسعه می‌دهیم به کانفلیکت‌های زیادی برمیخوریم. اما کوبرنتیز به کمک تیم‌ها امده و آنها را به توسعه با معماری میکروسرویس تشویق کرده.
کوبرنتیز برای توسعه میکروسرویس ابسترکشن و api های زیر را ارائه میدهد:
⁃ پاد (Pod): یک واحد توسعه که در خود یک یا چند کانتینر را جای میدهد
⁃ سرویس‌ها: سرویس‌ها به اما اجازه load balancing و ایزولیشن بین سرویس‌ها را ارائه میدهد
⁃ نیماسپیسها: نیماسپیسها سطح دسترسی یک سرویس را تعیین می‌کند. برای مثال می‌توانیم تعیین کنیم کدام سرویس‌ها می‌توانند به یک سرویس خاص دسترسی داشته باشند.
⁃ اینگرس (Ingress): این آبجکت‌ها می‌توانند چندین سرویس را به صورت یک Api ارائه دهند.
این دو درس تنها مقدمه‌ای بر دنیای کوبرنتیز بوده است. در درس‌های بعدی ما به مسائل پایه‌ای و سپس عمیق‌تر کوبرنتیز می‌پردازیم.
#kubernetes_up_and_running
@Code_Crafters
هنگامی که محصول شما رشد می‌کند, شما باید هم محصول و هم تیم توسعه خود را scale کنید. خوشبختانه کوبرنتیز این قابلیت را به ما میدهد که به راحتی بتوانیم محصول خود را scale کنیم. اما چه چیزی باعث میشود که scale کردن در کوبرنتیز اینقدر ساده باشد؟
به سبب وجود داشتن معماری decoupled, کامپوننت‌ها مستقل هستند و به کمک api و service load balancer ها با هم ارتباط ایجاد می‌کنند.
کوبرنتیز به شما این اجازه را میدهد که از یک کانتینر چندین replica داشته باشید که برای اضافه یا کم کردن آن نیاز دارید فقط یک عدد را در فایل کانفیگ تغییر دهید. حتی می‌توانید این تصمیم گیری را بر عهده کوبرنتیز بگذارید که چند رپلیکا از اپلیکیشن داشته باشیم.
کوبرنتیز نه تنها محصول شما را scale می‌کند, بلکه می‌تواند تیم شما را نیز scale کند!
تحقیقات نشان داده است که یک تیم ایده‌ال باید ۶ الی ۸ عضو داشته باشد. به این تیم‌ها “two pizza team” نیز می‌گویند.
این تیم‌ها تصمیمات راحت‌تری می‌گیرند و عموما تسک‌ها سریع‌تر deliver می‌شوند چرا که کانفلیکت‌های کمتری در کد ایجاد میشود.
اگر یک کدبیس بزرگ داشته باشیم, قطعا هنگامی که کد را توسعه می‌دهیم به کانفلیکت‌های زیادی برمیخوریم. اما کوبرنتیز به کمک تیم‌ها امده و آنها را به توسعه با معماری میکروسرویس تشویق کرده.
کوبرنتیز برای توسعه میکروسرویس ابسترکشن و api های زیر را ارائه میدهد:
⁃ پاد (Pod): یک واحد توسعه که در خود یک یا چند کانتینر را جای میدهد
⁃ سرویس‌ها: سرویس‌ها به اما اجازه load balancing و ایزولیشن بین سرویس‌ها را ارائه میدهد
⁃ نیماسپیسها: نیماسپیسها سطح دسترسی یک سرویس را تعیین می‌کند. برای مثال می‌توانیم تعیین کنیم کدام سرویس‌ها می‌توانند به یک سرویس خاص دسترسی داشته باشند.
⁃ اینگرس (Ingress): این آبجکت‌ها می‌توانند چندین سرویس را به صورت یک Api ارائه دهند.
این دو درس تنها مقدمه‌ای بر دنیای کوبرنتیز بوده است. در درس‌های بعدی ما به مسائل پایه‌ای و سپس عمیق‌تر کوبرنتیز می‌پردازیم.
#kubernetes_up_and_running
@Code_Crafters
❤7
درک یک پایان
رمانی به ظاهر ساده و کوتاه اما بشدت پیچیده و سنگین که محتوی فلسفه و روانشناختی و تحلیلی دارد
اخیرا به این فکر و باور بودم که 99 درصد زندگی یک انسان رو توهم تشکیل میدهد نه بیشتر، سعی داشتم با این دیدگاهم مقابله کنم
بطور اتفاقی با این کتاب آشنا شدم که صحه بر باورم گذاشت، ما در تعریف آگاهی به چند مورد اشاره میکنیم: گذشته فرد، سلامت فکری و روانی، درک او از محیط اطرافش و آنچه رخ میده
این کتاب با یک داستان ساده هر سه مورد ذکر شده راجب آگاهی رو نقض میکنه برای یک انسان و با این شرایط انسان رو وادار میکنه که نسبت به آنچه در زندگیش هست بازنگری کنه و اینکه با این اوصاف آیا انسان میتونه به پذیرش نسبت به مسائل برسه یا نه
آیا ما واقعا مسئولیم؟؟؟
@code_crafters
رمانی به ظاهر ساده و کوتاه اما بشدت پیچیده و سنگین که محتوی فلسفه و روانشناختی و تحلیلی دارد
اخیرا به این فکر و باور بودم که 99 درصد زندگی یک انسان رو توهم تشکیل میدهد نه بیشتر، سعی داشتم با این دیدگاهم مقابله کنم
بطور اتفاقی با این کتاب آشنا شدم که صحه بر باورم گذاشت، ما در تعریف آگاهی به چند مورد اشاره میکنیم: گذشته فرد، سلامت فکری و روانی، درک او از محیط اطرافش و آنچه رخ میده
این کتاب با یک داستان ساده هر سه مورد ذکر شده راجب آگاهی رو نقض میکنه برای یک انسان و با این شرایط انسان رو وادار میکنه که نسبت به آنچه در زندگیش هست بازنگری کنه و اینکه با این اوصاف آیا انسان میتونه به پذیرش نسبت به مسائل برسه یا نه
آیا ما واقعا مسئولیم؟؟؟
@code_crafters
❤4
Kubernetes in action - lesson 3
کوبرنتیز یک پلتفرم برای ساخت, دیپلوی و منیج کردن یک برنامه توزیع شده است. این برنامه‌ها در سایز و اشکال مختلفی می‌توانند باشند که روی یک یا چند سیستم به صورت‌های متفاوت به اجرا درامدند. تمامی این برنامه‌ها ورودی‌هایی را دریافت می‌کنند و می‌توانند خروجی‌هایی را ارسال کنند. قبل از اینکه وارد این موضوع شویم, ابتدا باید بدانیم که چطور می‌توانیم یک کانتینر اپلیکیشن بسازیم تا بتوانیم آن را در بستر این محیط به اجرا دربیاوریم.
برنامه‌ها عموما ترکیبی از کتابخانه‌ها و سورس کدها هستند که در مواقع مختلف روی کتابخانه‌های سیستم‌عاملی مانند libc و libssl نیز تکیه می‌کنند. این دیپندنسی‌ها می‌توانند گاهی مشکلاتی را بوجود بیاورند. برای مثال ممکن است یک کتابخانه روی لپتاپ برنامه‌نویس نصب باشد اما روی سرور پروداکشن این کتابخانه نصب نباشد. آنگاه به مشکلات مختلفی بر می‌خوریم.
این راه قدیمی که باید کل کد بیس روی یک ماشین با یک سیستم‌عامل مشخص و کتابخانه‌هایی با ورژن‌های مشخص اجرا شود, اکنون دیگر منقضی شده است. چرا که در تیم‌های بزرگ این رویکرد تنها پیچیدگی را زیاد کرده بود.
یکی از راه‌هایی که می‌توانیم در مقابل این مشکل بایستیم این است که کل برنامه را تبدیل به یک package کنیم و آن را یک‌جایی push کنیم تا دیگران آن را pull کنند و از آن استفاده کنند. Docker یکی از محبوب‌ترین ابزارها برای این کار است. با داکر می‌توانیم یک ایمیج executable بسازیم و سپس آن را روی یک رجیستری push کنیم تا دیگران بتوانند از آن استفاده کنند.
پس درواقع container image ها یک مجموعه‌ای از سورس کد و دیپندنسیهای آن هستند که در لایه‌های مختلفی از یک ایمیج ذخیره شده‌اند. معروف‌ترین فرمت این ایمیج‌ها, فرمت ایمیج‌های داکر است که توسط OCI, استداندارد سازی شده است.
خوشبختانه کوبرنتیز از فرمت‌های docker image format و OCI ساپورت می‌کند.
ایمیج کانتینرها تنها یک فایل نیستند, بلکه آنها پوینتری به فایل‌های دیگه هستند. ایمیج‌ها از لایه‌هایی تشکیل شده‌اند که این لایه‌ها ممکن است گاهی مدت‌ها پیش توسعه یافته باشد.
ایمیج‌ها معمولا با یک configuration file اجرا می‌شوند که در آن تنظیمات مربوط به نتورک, entrypoint command و syscall restriction کانفیگ می‌شوند.
کانتینرها به دو دسته تقسیم می‌شوند.
1- system containers
2- application containers
دسته اول به کانتینر‌هایی می‌‌گوییم که یک سیستم‌عامل کامل را نصب دارد که می‌توانیم در آن اقدامات زیادی انجام دهیم. اما این کانتینرها منابع بیشتری مصرف می‌کنند, پس برنامه‌نویس‌ها به دنبال یک راه بهتر و سبک تر رفتند و application containerها را پیدا کردند. این کانتینرها معمولا ایمیج‌های سبک‌تری دارند. چرا که این کانتینرها با یک سیستم‌عامل پایه‌ای و سبک بوت می‌شوند و تمرکز آنها بیشتر روی ابزاری است که توسعه می‌دهند.
اما یک ایمیج را چگونه می‌توانیم بهینه کنیم؟
۱- فایل‌های اضافی را در .dockerignore قرار دهیم.
سناریو زیر را درنظر بگیرید:
Layer 1: Contain a big file
Layer 2: Removes the big file
در سناریو بالا, خیلی بهتر میشد اگر از همان اول Big file را داخل .dockerignore قرار دهیم.
۲- به ترتیب اجرای دستورات دقت کنید.
به سناریوی زیر دقت کنید:
Dockerfile A:
Install big linux dependencies
Copy requirements.txt
Install reuirements
Dockerfile B:
Copy requirements.txt
Install reuirements
Install big linux dependencies
دو ایمیج بالا دقیقا یک کار را انجام می‌دهند, اما در ایمیج دومی هرگاه requirements.txt تغییر می‌کند, ما دیپندنسیهای سنگین را از نو نصب میکنیم! پس بهتر است این لایه‌های سنگین را در ابتدای فایل ایجاد کنیم.
در درس‌های بعد به مسائلی همچون multistage image build می‌پردازیم.
#kubernetes_up_and_running
@Code_Crafters
کوبرنتیز یک پلتفرم برای ساخت, دیپلوی و منیج کردن یک برنامه توزیع شده است. این برنامه‌ها در سایز و اشکال مختلفی می‌توانند باشند که روی یک یا چند سیستم به صورت‌های متفاوت به اجرا درامدند. تمامی این برنامه‌ها ورودی‌هایی را دریافت می‌کنند و می‌توانند خروجی‌هایی را ارسال کنند. قبل از اینکه وارد این موضوع شویم, ابتدا باید بدانیم که چطور می‌توانیم یک کانتینر اپلیکیشن بسازیم تا بتوانیم آن را در بستر این محیط به اجرا دربیاوریم.
برنامه‌ها عموما ترکیبی از کتابخانه‌ها و سورس کدها هستند که در مواقع مختلف روی کتابخانه‌های سیستم‌عاملی مانند libc و libssl نیز تکیه می‌کنند. این دیپندنسی‌ها می‌توانند گاهی مشکلاتی را بوجود بیاورند. برای مثال ممکن است یک کتابخانه روی لپتاپ برنامه‌نویس نصب باشد اما روی سرور پروداکشن این کتابخانه نصب نباشد. آنگاه به مشکلات مختلفی بر می‌خوریم.
این راه قدیمی که باید کل کد بیس روی یک ماشین با یک سیستم‌عامل مشخص و کتابخانه‌هایی با ورژن‌های مشخص اجرا شود, اکنون دیگر منقضی شده است. چرا که در تیم‌های بزرگ این رویکرد تنها پیچیدگی را زیاد کرده بود.
یکی از راه‌هایی که می‌توانیم در مقابل این مشکل بایستیم این است که کل برنامه را تبدیل به یک package کنیم و آن را یک‌جایی push کنیم تا دیگران آن را pull کنند و از آن استفاده کنند. Docker یکی از محبوب‌ترین ابزارها برای این کار است. با داکر می‌توانیم یک ایمیج executable بسازیم و سپس آن را روی یک رجیستری push کنیم تا دیگران بتوانند از آن استفاده کنند.
پس درواقع container image ها یک مجموعه‌ای از سورس کد و دیپندنسیهای آن هستند که در لایه‌های مختلفی از یک ایمیج ذخیره شده‌اند. معروف‌ترین فرمت این ایمیج‌ها, فرمت ایمیج‌های داکر است که توسط OCI, استداندارد سازی شده است.
خوشبختانه کوبرنتیز از فرمت‌های docker image format و OCI ساپورت می‌کند.
ایمیج کانتینرها تنها یک فایل نیستند, بلکه آنها پوینتری به فایل‌های دیگه هستند. ایمیج‌ها از لایه‌هایی تشکیل شده‌اند که این لایه‌ها ممکن است گاهی مدت‌ها پیش توسعه یافته باشد.
ایمیج‌ها معمولا با یک configuration file اجرا می‌شوند که در آن تنظیمات مربوط به نتورک, entrypoint command و syscall restriction کانفیگ می‌شوند.
کانتینرها به دو دسته تقسیم می‌شوند.
1- system containers
2- application containers
دسته اول به کانتینر‌هایی می‌‌گوییم که یک سیستم‌عامل کامل را نصب دارد که می‌توانیم در آن اقدامات زیادی انجام دهیم. اما این کانتینرها منابع بیشتری مصرف می‌کنند, پس برنامه‌نویس‌ها به دنبال یک راه بهتر و سبک تر رفتند و application containerها را پیدا کردند. این کانتینرها معمولا ایمیج‌های سبک‌تری دارند. چرا که این کانتینرها با یک سیستم‌عامل پایه‌ای و سبک بوت می‌شوند و تمرکز آنها بیشتر روی ابزاری است که توسعه می‌دهند.
اما یک ایمیج را چگونه می‌توانیم بهینه کنیم؟
۱- فایل‌های اضافی را در .dockerignore قرار دهیم.
سناریو زیر را درنظر بگیرید:
Layer 1: Contain a big file
Layer 2: Removes the big file
در سناریو بالا, خیلی بهتر میشد اگر از همان اول Big file را داخل .dockerignore قرار دهیم.
۲- به ترتیب اجرای دستورات دقت کنید.
به سناریوی زیر دقت کنید:
Dockerfile A:
Install big linux dependencies
Copy requirements.txt
Install reuirements
Dockerfile B:
Copy requirements.txt
Install reuirements
Install big linux dependencies
دو ایمیج بالا دقیقا یک کار را انجام می‌دهند, اما در ایمیج دومی هرگاه requirements.txt تغییر می‌کند, ما دیپندنسیهای سنگین را از نو نصب میکنیم! پس بهتر است این لایه‌های سنگین را در ابتدای فایل ایجاد کنیم.
در درس‌های بعد به مسائلی همچون multistage image build می‌پردازیم.
#kubernetes_up_and_running
@Code_Crafters
❤6
یکی از وحشتناکترین مسائلی که در خودشناسی باهاش روبرو میشید جایی از درونتون هستش که بهش میرسید و متوجه میشید که یک زمان کوتاهی یک آدمی اومده سراغتون، نه حتی با میل خودتون بلکه با اغواگری شدید خود اون فرد، یک آسیبی یک حس بدی از خودتون براتون جا گذاشته و بدون هیچ توضیح یا حرف ساده‌ای گذاشته رفته
ترسناکتر اینجاست که باز این حس که زنده میشه مجدد ازتون میخواد که برید سراغ همون آدم مریض و ازش توضیح بخواید
باید قبول کنیم جذابیت فردی در اولین نگاه از هر فردی یا شخصی به احتمال زیاد (نه بطور قطع) نشان از اختلال شخصی و بیماری روانی هستش
بخوام چندتا نمونه بهتون بگم
اختلال مرزی: در ابتدای آشنایی بشدت جذابیت اجتماعی داره براتون
اختلال خودشیفتگی: بشدت آدم حق به جانب و سطح بالایی بنظر میاد
اختلال شکاکیت: در ابتدای آشنایی بشدت آدمی هستش که بهتون اهمیت میده
جذابیت ابتدایی بالا میتونه نشونه یک بیماری روانی زمینه‌ای باشه که در برخورد اول قابل تشخیص نیست ولی منتها بشکل دیگه‌ای خودش رو نشون میده
#موقت
ترسناکتر اینجاست که باز این حس که زنده میشه مجدد ازتون میخواد که برید سراغ همون آدم مریض و ازش توضیح بخواید
باید قبول کنیم جذابیت فردی در اولین نگاه از هر فردی یا شخصی به احتمال زیاد (نه بطور قطع) نشان از اختلال شخصی و بیماری روانی هستش
بخوام چندتا نمونه بهتون بگم
اختلال مرزی: در ابتدای آشنایی بشدت جذابیت اجتماعی داره براتون
اختلال خودشیفتگی: بشدت آدم حق به جانب و سطح بالایی بنظر میاد
اختلال شکاکیت: در ابتدای آشنایی بشدت آدمی هستش که بهتون اهمیت میده
جذابیت ابتدایی بالا میتونه نشونه یک بیماری روانی زمینه‌ای باشه که در برخورد اول قابل تشخیص نیست ولی منتها بشکل دیگه‌ای خودش رو نشون میده
#موقت
👍5❤1