Syntax | سینتکس

ران کردن پرایوت داکر رجیستری بصورت سلف هاست خیلی ساده و راحت: https://github.com/syntaxfa/docker-registry #docker @Syntax_fa

قدیمی ترین وب سایت هایی که هنوزم آنلاینن! #fun @Syntax_fa

دوستان این کتاب دارای مطالبی هست که توی منابع فارسی پیدا نمیشه.. حتی اگر جنگو رو فول هستین بازم نیم نگاهی بهش بندازید🔥 @Syntax_fa

درود خدمت رفقای سینتکسی بنا به درخواست شما دوستان عزیز از منابع برای یادگیری مبتدی تا پیشرفته django و django api , ترجمه فارسی این سه کتاب : django for professionals django in production django for api's در چنل قرار گرفت. # توجه: کتاب ها توسط گوگل ترنسلیت به فارسی ترجمه شده و چون برای استفاده شخصی بوده از مرتب کردن ترجمه قسمت های ساده و بسیار پایه, شاید در برخی موارد خودداری شده باشه!(در جایی از اینترنت پیدا نمیشه)❌ بهتون توصیه میشه درکنار این ترجمه ها برای قسمت هایی که ترجمه نشدن کتاب اصلی رو هم داشته باشین تا دچار سردگمی نشین.. قسمت های اصلی و مهم کتاب ترجمه شدن! امیدوارم مفید واقع باشه🙏🏻

این Swap Memory خبیث چیه و چرا بهتره غیرفعالش کنیم؟ در سیستم‌عامل‌های لینوکسی (و سایر سیستم‌های مشابه)، Swap Memory به عنوان یک حافظه‌ی مجازی مورد استفاده قرار می‌گیرد. وقتی رم (RAM) سیستم پر می‌شود، سیستم از بخشی از فضای دیسک (HDD یا SSD) به عنوان حافظه‌ی موقت استفاده می‌کند. این فضای موقت همان Swap است. اگرچه این ویژگی در مواقع خاص مفید است، اما در برخی موارد می‌تواند مشکلاتی ایجاد کند که به همین دلیل به Swap Memory خبیث مشهور شده است. چرا Swap Memory مشکل‌ساز می‌شود؟ 1. کندی عملکرد سیستم وقتی سیستم به جای رم از Swap استفاده می‌کند، سرعت به شدت کاهش می‌یابد. دلیل این امر این است که هارد دیسک یا SSD به مراتب کندتر از رم است. به همین دلیل، اجرای برنامه‌ها و پردازش‌ها به شدت کند می‌شود. 2. افزایش فشار بر هارد دیسک یا SSD استفاده مداوم از Swap باعث فشار زیاد بر دیسک می‌شود. در مورد SSD، این موضوع می‌تواند عمر دیسک را به شدت کاهش دهد. 3. مدیریت نامناسب حافظه در برخی موارد، سیستم به جای آزاد کردن رم‌های غیرضروری به Swap منتقل می‌شود. این موضوع می‌تواند باعث شود که حتی وقتی رم کافی دارید، سیستم همچنان کند عمل کند. آیا باید Swap Memory را غیرفعال کنیم؟ در سیستم‌هایی که رم کافی دارند (مثلاً 12 گیگابایت یا بیشتر)، معمولاً نیازی به Swap نیست و می‌توان آن را غیرفعال کرد. با این کار، سیستم مجبور می‌شود مدیریت حافظه را بهینه‌تر انجام دهد و از منابع رم به شکل بهتری استفاده کند. اما اگر سیستم شما رم محدودی دارد (مثلاً کمتر از 12 گیگابایت)، غیرفعال کردن Swap می‌تواند باعث کرش برنامه‌ها در صورت پر شدن رم شود. در این حالت، باید با احتیاط عمل کنید. چطور Swap Memory را غیرفعال کنیم؟ برای غیرفعال کردن Swap Memory در سیستم‌های لینوکسی، می‌توانید مراحل زیر را دنبال کنید: 1. بررسی وضعیت فعلی Swap ابتدا بررسی کنید که آیا Swap فعال است یا خیر:

swapon --show

اگر خروجی نمایش داده شود، یعنی Swap فعال است. 2. غیرفعال کردن موقتی Swap برای غیرفعال کردن موقتی Swap (تا زمان بوت بعدی):

sudo swapoff -a

این دستور تمام Swapهای فعال را غیرفعال می‌کند. 3. غیرفعال کردن دائمی Swap برای غیرفعال کردن دائمی، باید Swap را از فایل تنظیمات سیستم حذف کنید. مراحل زیر را انجام دهید: - فایل /etc/fstab را ویرایش کنید:

sudo nano /etc/fstab

- خط مربوط به Swap را پیدا کنید. معمولاً چیزی شبیه به این است:

/swapfile none swap sw 0 0

- آن خط را کامنت کنید (با اضافه کردن # در ابتدای خط) یا حذف کنید:

#/swapfile none swap sw 0 0

- فایل را ذخیره کنید و خارج شوید. در نهایت پس از ریبوت، بررسی کنید که دیگر Swap فعال نیست:

swapon --show

#swap_memory @Syntax_fa

می‌خوام راجب این صحبت کنم (از پروفایل خودم). من پیغمبر مخالفت با اهمیت تعداد کامیت بودم و هستم؛ حداقل ۳-۴ ساله دارم این حرف رو میزنم و دلیلش رو هم گفتم (اینکه چندتا گیت‌هاب خودم به اینو اون دادم و ...) ولی یک جو احمقانه توی لینکدین و توییتر راه افتاده ضد این بخش؛ ببین از من که گذشته ولی این صحبت‌های احمقانه برای کل جامعه برنامه‌نوبسی بد هست چند مورد : ۱- کسی که پروفایلش انقدر کامیت داره؛ حرفه‌ای نیست چون شرکت‌های بزرگ خودشون گیت‌لب دارند و ... همینجا جواب این رو میدم: احمق جون تو تازه‌کاری گیت‌لب زمانی به یک سری باگ‌ها خورد (توی یوتیوب سرچ کنید) که خیلی شرکت‌ها برگشتند روی گیت‌هاب و نسخه organization رو خرید زدند. خیلی از فعالیت‌های گیت‌هاب من ازونجا شروع شد. ۲- اینا همش ادا بازیه و ... حماقت محض هست این حرف؛ اگر به اینجا رسیدی که این حرف رو زدی (شما تا حالا کسی رو دیدی عکس این کاشی‌کاری رو توی رزومه‌اش بذاره ؟) هیچ شرکت و یا شخص با سوادی رو نمی‌شناسم که حتی ۱ درصد این موزاییک براش مهم باشه (مگر بچه‌هایی که روش نقاشی می‌کشند. اونم کل کل برنامه نویسی هست البته) و چیزهای از این دست. در نهایت اینکه؛ من خودم بیشتر کامیت‌های گیت‌هابم برای کارهای شخصی (اسکریپت؛ ایده؛ داکیومنت؛ کانفیگ و حتی تمرین هست) از این 2176 تا کامیت شاید 700-800 تاش برای شرکت‌هایی هست که روی گیت‌هاب هستند؛ باقیش کارهای خودمه؛ و حتی اگر یک روز تا ۱۰ شب هم سرکار باشم هرطور شده باید تا آخر شب ۲-۳ تا مطلب کتابی که خوندم رو برای خودم تمرین کنم (این بدترین حالت هست). ولی خیلی وقتا تیکه کدی زده شده توی شرکت که بنظرم راه خوبی نبوده و باگ میخوره؛ روی گیت‌هاب خودم یک سناریو مشابه براش درست می‌کنم و سعی می‌کنم اون مشکل رو حل کنم یا پروفایلینگ براش بگیرم و اپتیمایز کنم چون من خالق همه پروژه‌های شرکت‌ها نیستم و خیلی وقتا بیزینس بهم اجازه نمیده روش رو تغییر بدم. خلاصه که وظیفه ما : هشدار دادن راجب افراد سودجو بود؛ که نیروی HR به این کاشی کاری گیت‌هاب اهمیتی نده برای دعوت به مصاحبه. اما این موج تخریب افراد تازه‌کار و با انگیزه بالا هم کاری بس کثیف‌تر هست که مطمئنم از جامعه توسعه دهنده شروع نشده. مثال از خودم زدم برای حمایت از تمام دولوپرهای تازه‌کار و با انگیزه دمتون گرم ❤️

می‌خوام راجب این صحبت کنم (از پروفایل خودم). من پیغمبر مخالفت با اهمیت تعداد کامیت بودم و هستم؛ حداقل ۳-۴ ساله دارم این حرف رو میزنم و دلیلش رو هم گفتم (اینکه چندتا گیت‌هاب خودم به اینو اون دادم و ...) ولی یک جو احمقانه توی لینکدین و توییتر راه افتاده ضد این بخش؛ ببین از من که گذشته ولی این صحبت‌های احمقانه برای کل جامعه برنامه‌نوبسی بد هست چند مورد : ۱- کسی که پروفایلش انقدر کامیت داره؛ حرفه‌ای نیست چون شرکت‌های بزرگ خودشون گیت‌لب دارند و ... همینجا جواب این رو میدم: احمق جون تو تازه‌کاری گیت‌لب زمانی به یک سری باگ‌ها خورد (توی یوتیوب سرچ کنید) که خیلی شرکت‌ها برگشتند روی گیت‌هاب و نسخه organization رو خرید زدند. خیلی از فعالیت‌های گیت‌هاب من ازونجا شروع شد. ۲- اینا همش ادا بازیه و ... حماقت محض هست این حرف؛ اگر به اینجا رسیدی که این حرف رو زدی (شما تا حالا کسی رو دیدی عکس این کاشی‌کاری رو توی رزومه‌اش بذاره ؟) هیچ شرکت و یا شخص با سوادی رو نمی‌شناسم که حتی ۱ درصد این موزاییک براش مهم باشه (مگر بچه‌هایی که روش نقاشی می‌کشند. اونم کل کل برنامه نویسی هست البته) و چیزهای از این دست. در نهایت اینکه؛ من خودم بیشتر کامیت‌های گیت‌هابم برای کارهای شخصی (اسکریپت؛ ایده؛ داکیومنت؛ کانفیگ و حتی تمرین هست) از این 2176 تا کامیت شاید 700-800 تاش برای شرکت‌هایی هست که روی گیت‌هاب هستند؛ باقیش کارهای خودمه؛ و حتی اگر یک روز تا ۱۰ شب هم سرکار باشم هرطور شده باید تا آخر شب ۲-۳ تا مطلب کتابی که خوندم رو برای خودم تمرین کنم (این بدترین حالت هست). ولی خیلی وقتا تیکه کدی زده شده توی شرکت که بنظرم راه خوبی نبوده و باگ میخوره؛ روی گیت‌هاب خودم یک سناریو مشابه براش درست می‌کنم و سعی می‌کنم اون مشکل رو حل کنم یا پروفایلینگ براش بگیرم و اپتیمایز کنم چون من خالق همه پروژه‌های شرکت‌ها نیستم و خیلی وقتا بیزینس بهم اجازه نمیده روش رو تغییر بدم. خلاصه که وظیفه ما : هشدار دادن راجب افراد سودجو بود؛ که نیروی HR به این کاشی کاری گیت‌هاب اهمیتی نده برای دعوت به مصاحبه. اما این موج تخریب افراد تازه‌کار و با انگیزه بالا هم کاری بس کثیف‌تر هست که مطمئنم از جامعه توسعه دهنده شروع نشده. مثال از خودم زدم برای حمایت از تمام دولوپرهای تازه‌کار و با انگیزه دمتون گرم ❤️

فایل داکر کمپوز «ساختار پروژه سینتکس» رو آپدیت کردیم: https://github.com/syntaxfa/django-structure/blob/main/compose.yml میشه بعضی قسمت هارو خیلی کوتاه ترش کرد مثل تعریف والیوم ها ولی از وربوس بودن بیشتر خوشم میاد و با چند خط بیشتر کد زدن مشکلی ندارم. همچنین بعضی ویژگی هایی که تعریف شده جنبه آموزشی داره مثل lables هایی که برای سرویس ها تعریف شده. میشه داخل Dockerfile هم اینکار رو انجام داد. #docker @Syntax_fa

interpolation vs concatenation Interpolation در برنامه‌نویسی، "interpolated" به معنای "درون‌گذاری" است و به تکنیکی اشاره دارد که در آن مقادیر متغیرها یا عبارات درون یک رشته (string) قرار می‌گیرند. این تکنیک به برنامه‌نویسان این امکان را می‌دهد که به راحتی مقادیر متغیرها را درون رشته‌ها قرار دهند بدون اینکه نیاز به استفاده از عملگرهای الحاق (concatenation) باشد. به عنوان مثال، در زبان‌های برنامه‌نویسی مانند Python، می‌توان از f-strings برای درون‌گذاری استفاده کرد:

name = "ممد"
age = 22
greeting = f"سلام، نام من {name} است و من {age} سال دارم."
print(greeting)

در این مثال، مقادیر متغیرهای name و age به طور مستقیم درون رشته قرار می‌گیرند و خروجی به صورت زیر خواهد بود:

سلام، نام من ممد است و من 22 سال دارم.

در زبان‌های دیگر نیز تکنیک‌های مشابهی برای درون‌گذاری وجود دارد، مانند استفاده از fmt.PrintF در Go یا Template Literals در JavaScript. Concatenation به معنای ترکیب دو یا چند رشته (string) به یک رشته واحد است. در این روش، معمولاً از عملگر + یا متدهای خاصی برای Concatenation استفاده می‌شود. به عنوان مثال، در زبان Python می‌توان به این شکل عمل کرد:

name = "ممد"
age = 22
greeting = "سلام، نام من " + name + " است و من " + str(age) + " سال دارم."
print(greeting)

در این مثال، رشته‌ها با استفاده از عملگر + به هم متصل شده‌اند. تفاوت‌ها: 1. خوانایی: -ا Interpolation معمولاً خواناتر است، زیرا مقادیر متغیرها به وضوح درون رشته قرار می‌گیرند و نیازی به استفاده از عملگرهای concatenation نیست. - در concatenation ممکن است رشته‌ها به هم چسبیده شوند و خوانایی کمتری داشته باشند. 2. عملکرد: -ا Interpolation معمولاً بهینه‌تر است، زیرا در بسیاری از زبان‌ها، موتور زبان می‌تواند به طور بهینه‌تری رشته‌ها را پردازش کند. - در concatenation به ویژه اگر تعداد زیادی رشته را به هم متصل کنید، ممکن است عملکرد کاهش یابد، زیرا هر بار که یک رشته جدید ایجاد می‌شود، حافظه جدیدی تخصیص داده می‌شود. #tips @Syntax_fa

داکیومنت داکر اینو میگه: internal By default, Compose provides external connectivity to networks. internal, when set to true, lets you create an externally isolated network. برای حل این مسئله، می‌توانیم از شبکه‌های داخلی (internal network) در Docker Compose استفاده کنیم. شبکه داخلی یک شبکه‌ای است که داکر فراهم می‌کند و ارتباط سرویس‌ها فقط در داخل همان شبکه امکان‌پذیر است. به این ترتیب، سرویس‌ها کاملاً ایزوله می‌شوند و هیچ ارتباطی با خارج از شبکه داکر (مانند هاست یا اینترنت) برقرار نمی‌کنند، حتی اگر به اشتباه پورت‌هایی در فایل Compose تعریف شود. 1. ایجاد شبکه داخلی در فایل `docker-compose.yml`: در فایل Docker Compose، می‌توانید یک شبکه داخلی تعریف کنید. در این شبکه، سرویس‌ها فقط می‌توانند با یکدیگر ارتباط برقرار کنند و هیچ ارتباطی با شبکه هاست یا اینترنت ندارند. مثال:

   version: '3.9'
   services:
     service1:
       image: my-image-1
       networks:
         - internal_network
     service2:
       image: my-image-2
       networks:
         - internal_network

   networks:
     internal_network:
       internal: true
   

توضیحات: - در بخش networks`، یک شبکه به نام `internal_network تعریف شده و ویژگی internal: true به آن اضافه شده است. - این شبکه فقط برای ارتباط داخلی بین سرویس‌های تعریف‌شده در Docker Compose در دسترس است. - هیچ پورت خارجی (حتی اگر در بخش ports تعریف شده باشد) از خارج شبکه داکر قابل دسترسی نخواهد بود. #docker #docker_compose @Syntax_fa

سوال درباره داکر و داکر کمپوز سوال: فرض کنید ما چند سرویس داریم که در یک پروژه با استفاده از Docker Compose مدیریت می‌شوند. این سرویس‌ها نیازی به ارتباط با خارج از شبکه داخلی داکر (مانند شبکه هاست یا اینترنت) ندارند و فقط باید به‌صورت داخلی با یکدیگر ارتباط برقرار کنند. حتی اگر به اشتباه پورت‌هایی برای آن‌ها در فایل Docker Compose تعریف شود (مانند ports)، نباید این پورت‌ها از بیرون شبکه داکر در دسترس باشند. چگونه می‌توانیم چنین محدودیتی اعمال کنیم و اطمینان حاصل کنیم که سرویس‌ها کاملاً ایزوله هستند و فقط در شبکه داخلی داکر قابل دسترسی‌اند؟ (جواب و راه حلی پیشنهادی پست بعدی گذاشته میشه) #docker #docker_compose @Syntax_fa

چند نکته درباره Dockerfile ۱. بدون دسترسی روت: - اجرای کانتینر با کاربر غیر روت برای امنیت بیشتر ۲. ساخت چند مرحله‌ای (Multistage Build): - کاهش حجم نهایی ایمیج - جداسازی محیط build از محیط اجرا مثال:

FROM golang:1.23 AS build
WORKDIR /src
COPY main.go .
RUN go build -o /bin/hello ./main.go

FROM scratch
COPY --from=build /bin/hello /bin/hello

CMD ["/bin/hello"]

۳. استفاده از Distroless یا From Scratch: - حذف ابزارهای غیرضروری برای کاهش سطح حمله - استفاده از ایمیج‌های پایه حداقلی مثال:

FROM gcr.io/distroless/nodejs
COPY --from=builder /app/dist .
CMD ["app.js"]

۴. استفاده از ایمیج‌های مطمئن: - استفاده از ایمیج‌های رسمی از Docker Hub - بررسی منبع و تاریخچه ایمیج‌ها ۵. به‌روزرسانی منظم ایمیج: - به‌روزرسانی مرتب پایه ایمیج برای دریافت پچ‌های امنیتی - استفاده از CI/CD برای ساخت خودکار ایمیج‌های جدید ۶. پورت‌های در معرض (Exposed Ports): - فقط پورت‌های ضروری را expose کنید - مستندسازی پورت‌های مورد نیاز مثال:

EXPOSE 8080

۷. عدم قرار دادن کلیدها و رمزها در Dockerfile - استفاده از secrets یا متغیرهای محیطی مثال:

# bad idea
ENV DB_PASSWORD=secretpass

# recommended
ARG DB_PASSWORD

۸. مدیریت لایه‌ها (Layer Sanity): - ترکیب دستورات مرتبط برای کاهش تعداد لایه‌ها - حذف فایل‌های موقت در همان لایه مثال:

RUN apt-get update && \
    apt-get install -y package1 package2 && \
    rm -rf /var/lib/apt/lists/*

۹. برچسب‌های متادیتا: - افزودن اطلاعات مفید درباره ایمیج مثال:

LABEL maintainer="email@example.com"
LABEL version="1.0"
LABEL description="Application description"

نکات تکمیلی: - همیشه از .dockerignore برای ایگنور شدن فایل‌های غیرضروری استفاده کنید - دستورات را به ترتیب بهینه قرار دهید (از کمترین تغییر به بیشترین) - از کش Docker به درستی استفاده کنید #docker @Syntax_fa

این ویدیو از آتیش سوزی لس آنجلس رو اگه از یه کانال اطلاع رسانی بازی میدیدیم فک میکردم با آنریل انجین برای سری جدید Resident Evil ساختن @normal_developer

در وینوز خبیث چگونه داکر که یک linux container هستش اجرا میشه؟ قبل از 2016: در ابتدا، Docker فقط برای Linux طراحی شده بود و روی Windows قابل اجرا نبود🫠. در آن زمان، توسعه‌دهندگان Windows برای استفاده از Docker مجبور بودند: 1. یا از یک ماشین مجازی Linux جداگانه استفاده کنند 2. یا از ابزارهایی مثل VirtualBox استفاده کنند 3. یا تصمیم عاقلانه میگرفتن لینوکسی میشدن 2016 - معرفی Docker for Windows: در سال 2016، Docker یک راهکار رسمی برای Windows ارائه کرد که شامل دو بخش اصلی بود: 1. Docker Desktop for Windows: - یک نرم‌افزار یکپارچه که شامل تمام اجزای مورد نیاز برای اجرای Docker بود - از Hyper-V (مجازی‌ساز رسمی Microsoft) استفاده می‌کرد - یک Moby VM (ماشین مجازی سبک Linux) را به صورت خودکار مدیریت می‌کرد 2. معماری دو لایه: - لایه Windows: شامل Docker Client که رابط کاربری و CLI را در اختیار کاربر قرار می‌داد - لایه Linux (Moby VM): شامل Docker Daemon که مسئول اصلی مدیریت کانتینرها بود نحوه کار: 1. کاربر در Windows دستورات Docker را اجرا می‌کند 2. Docker Client این دستورات را به Moby VM منتقل می‌کند 3. Docker Daemon در Moby VM دستورات را پردازش کرده و کانتینرها را مدیریت می‌کند 4. تمام کانتینرهای Linux در این VM اجرا می‌شوند و از kernel آن استفاده می‌کنند مزایای این معماری: - کانتینرهای Linux دقیقاً مثل Linux اصلی کار می‌کنند - مدیریت منابع بهتر و کارایی بالاتر نسبت به استفاده از VirtualBox - یکپارچگی بهتر با Windows - نصب و راه‌اندازی ساده‌تر تغییرات بعدی: بعد از 2016، Docker قابلیت‌های جدیدی اضافه کرد: 1. Windows Containers: امکان اجرای کانتینرهای native ویندوزی 2. WSL2 Integration: یکپارچگی با Windows Subsystem for Linux نسخه 2 3. Hyper-V Isolation: لایه امنیتی اضافه برای جداسازی بهتر کانتینرها در نمودار بالا هم دقیقاً همین معماری نشان داده شده: - سمت چپ: محیط Windows که Docker Client در آن قرار دارد - سمت راست: Moby VM که Docker Daemon و کانتینرهای Linux را میزبانی می‌کند - ارتباط بین این دو از طریق یک پروتکل شبکه انجام می‌شود توضیحات مایکروسافت خبیث #docker @Syntax_fa

توی پایتون بجای isinstance از singledispatch استفاده کن! ۱. ابتدا دو کلاس با استفاده از @dataclass تعریف میکنیم:

@dataclass
class UserCanceledSubscription:
    username: str

@dataclass
class UserSubscribed:
    username: str

این‌ها دو نوع ایونت هستند: یکی برای زمانی که کاربر مشترک می‌شود و دیگری برای زمانی که اشتراکش را لغو می‌کند. ۲. روش اول با استفاده از isinstance:

def process(event):
    if isinstance(event, UserSubscribed):
        print(f"Enable access to user {event.username}")
    elif isinstance(event, UserCanceledSubscription):
        print(f"Disable access to user {event.username}")

در این روش، برای هر نوع رویداد یک شرط if نوشته شده که نوع رویداد را چک می‌کند. ۳. روش دوم با استفاده از singledispatch:

@singledispatch
def process(event):
    pass

@process.register(UserCanceledSubscription)
def _(event):
    print(f"Disable access to user {event.username}")

@process.register(UserSubscribed)
def _(event):
    print(f"Enable access to user {event.username}")

در این روش، برای هر نوع رویداد یک تابع جداگانه تعریف می‌شود که فقط برای آن نوع خاص اجرا می‌شود. مزایای استفاده از singledispatch: ۱. کد تمیزتر: به جای زنجیره‌ای از `if/elif`، هر منطق در یک تابع جداگانه قرار می‌گیرد. ۲. قابلیت توسعه بهتر: اضافه کردن نوع جدید فقط نیاز به اضافه کردن یک تابع جدید دارد، نه تغییر کد موجود. ۳. جداسازی مسئولیت‌ها: هر تابع فقط مسئول پردازش یک نوع خاص است. ۴. کاهش پیچیدگی: به جای یک تابع بزرگ با شرط‌های متعدد، چندین تابع کوچک و ساده داریم. نحوه کار: - @singledispatch یک تابع پایه تعریف می‌کند - @process.register() توابع مختلف را برای انواع مختلف ورودی ثبت می‌کند - در زمان اجرا، بر اساس نوع ورودی، تابع مناسب فراخوانی می‌شود کاربرد این الگو در مواردی مثل: - پردازش انواع مختلف پیام‌ها یا رویدادها - تبدیل داده‌ها بین فرمت‌های مختلف - اعمال عملیات‌های متفاوت روی انواع مختلف داده - پیاده‌سازی الگوی Observer یا Event Handler نمونه استفاده نهایی:

events = [
    UserSubscribed(username="johndoe"),
    UserCanceledSubscription(username="johndoe"),
]

for event in events:
    process(event)

این کد به طور خودکار تابع مناسب را برای هر نوع رویداد فراخوانی می‌کند. #python #singledispatch @Syntax_fa

سوال مصاحبه ای درباره ذاکر با توضیح کامل چرا وقتی یک کانتینر از یک ایمیجی رو بالا میاریم، نمیتونیم اون ایمیج رو پاک کنیم؟ زمانی که شما یک کانتینر را از یک ایمیج (Image) در Docker بالا می‌آورید، امکان حذف آن ایمیج تا زمانی که کانتینر مرتبط با آن در حال اجرا یا وجود داشته باشد امکان پذیر نیست. این رفتار به دلیل معماری Docker و نحوه مدیریت داده‌ها از طریق مکانیزم‌هایی مانند Copy-on-Write (COW) و UnionFS اتفاق می‌افتد. در Docker، ایمیج‌ها به‌عنوان قالب‌های فقط خواندنی (Read-Only) عمل می‌کنند که شامل تمام فایل‌ها، نرم‌افزارها و تنظیمات مورد نیاز برای اجرای یک برنامه هستند. وقتی یک کانتینر از یک ایمیج بالا می‌آید: - ایمیج به‌عنوان پایه (Base) عمل می‌کند. - کانتینر یک لایه نوشتنی (Writable Layer) به بالای ایمیج اضافه می‌کند. این لایه نوشتنی به کانتینر اجازه می‌دهد تغییراتی مانند ایجاد فایل‌ها یا تغییر تنظیمات را انجام دهد، بدون اینکه لایه‌های فقط خواندنی ایمیج اصلی تغییر کنند. Copy-on-Write (COW) داکر برای مدیریت تغییرات کانتینر از مکانیزم Copy-on-Write (COW) استفاده می‌کند. به این معنا که: - تا زمانی که نیازی به تغییر داده‌ها نباشد، کانتینر از لایه‌های موجود در ایمیج به‌صورت مستقیم استفاده می‌کند. - وقتی تغییری در یک فایل لازم باشد، آن فایل از لایه فقط خواندنی ایمیج به لایه نوشتنی کانتینر کپی می‌شود و سپس تغییرات اعمال می‌گردد. این روش باعث صرفه‌جویی در منابع می‌شود، زیرا تا زمانی که نیازی به تغییر نباشد، ایمیج و کانتینر از همان نسخه داده‌ها استفاده می‌کنند. UnionFS سیستم فایل UnionFS (Union File System) برای ترکیب چندین لایه سیستم فایل در یک نمای واحد (Single View) استفاده می‌شود. Docker از UnionFS برای ساخت ایمیج‌ها و کانتینرها استفاده می‌کند. نحوه کار به این صورت است: - ایمیج‌ها از چندین لایه تشکیل شده‌اند. - این لایه‌ها فقط خواندنی هستند و هر لایه تغییرات و افزوده‌هایی نسبت به لایه قبلی دارد. - وقتی یک کانتینر ایجاد می‌شود، یک لایه نوشتنی به بالای این لایه‌های فقط خواندنی اضافه می‌شود. بنابراین، از دید کانتینر، تمام این لایه‌ها به‌صورت یک سیستم فایل یکپارچه دیده می‌شوند. اما در واقعیت، لایه نوشتنی و لایه‌های فقط خواندنی جدا از هم هستند. https://en.wikipedia.org/wiki/UnionFS چرا ایمیج حذف نمی‌شود؟ وقتی یک کانتینر از یک ایمیج ایجاد می‌شود، آن کانتینر به لایه‌های ایمیج وابسته است. به همین دلیل، تا زمانی که کانتینر وجود دارد (حتی اگر متوقف شده باشد): - لایه‌های فقط خواندنی ایمیج در حال استفاده هستند. - اگر ایمیج حذف شود، کانتینر نمی‌تواند به لایه‌های مورد نیاز خود دسترسی پیدا کند و در نتیجه خراب می‌شود. Docker برای جلوگیری از این مشکل، اجازه حذف ایمیج‌هایی که در حال استفاده هستند را نمی‌دهد و در نهایت فقط میتوانید تگ آن را حذف کنید نه بادی ایمیج را. ارتباط Copy-on-Write و UnionFS - UnionFS امکان استفاده از چندین لایه سیستم فایل را فراهم می‌کند و باعث می‌شود ایمیج‌ها و کانتینرها به‌صورت مؤثری مدیریت شوند. - Copy-on-Write تضمین می‌کند که تنها زمانی تغییرات در داده‌ها ایجاد شوند که واقعاً لازم باشد، بدون تغییر لایه‌های اصلی (فقط خواندنی) ایمیج. این دو مکانیزم با هم کار می‌کنند تا Docker بتواند ایمیج‌ها و کانتینرها را به‌صورت کارآمد مدیریت کند. چگونه ایمیج را حذف کنیم؟ اگر بخواهید یک ایمیج را حذف کنید، ابتدا باید تمام کانتینرهای وابسته به آن را حذف کنید. مراحل کلی عبارتند از: 1. لیست کانتینرهای وابسته به ایمیج:

   docker ps -a --filter ancestor=<image_name_or_id>
   

2. حذف کانتینرهای وابسته:

   docker rm <container_id>
   

3. حذف ایمیج:

   docker rmi <image_name_or_id>
   

#docker #copy_on_write #union_file_system @Syntax_fa