توییت های برنامه نویسی و طراحی وب :)
Admin:
@dvtwi
Hashtags:
devtwitter.t.me/5
DevBooks Channel:
https://t.me/+AYbOl75CLNYxY2U0
Github:
https://github.com/DevTwitter
X:
https://x.com/devtwittir
Post #12496
6.46K
بعد از آپدیت داکر نیاز بود که Docker Daemon ریستارت بشه. اما ریسک داشت و نمیشد اینکار رو کرد چون یکسری کانتینر حیاتی up بودن و نباید down میشدن.
یه سرچ زدم تا ببینم راهکار چیه؟
با مفهوم Live Restore آشنا شدم.
قابلیتی در داکر چه اجازه میده کانتینرها به فعالیت خودشون در شرایط restart یا stop شدن داکر دیمن ادامه بدن.
اومدم اول روی سیستم خودم تست گرفتم و کانفیگ زیر:
رو در فایل کانفیگوریشن داکر دیمن قرار دادم و ریستارتش کردم و خداروشکر هیچ کانتینری exited نشد.
روی سیستم خودم یه تست دیگه گرفتم و داکر دیمن رو به مدت چند ثانیه stop کردم و بعد دوباره start کردم و وضعیت کانتینرهارو چک کردم و دیدم درسته بازهم هیچ کانتینری down نشده.
اما برام سوال شد که، اگه داکر دیمن up نیست، پس کانتینرهارو کی داره مدیریت میکنه؟ و چطوری؟
داستان از اونجاست که به طور معمول وقتی داکر دیمن استاپ یا ریستارت میشه، یک سیگنال از طریق containerd به کرنل میده و میگه هر پروسسی که توسط Docker ران شده رو kill کن.
اما معماری داکر بخاطر decoupled (یعنی مجزا بودن بخش مدیریت کانتینر از ساخت کانتینر) بودنش این اجازه رو میده که وقتی داکر دیمن استاپ شد، همچنان کانتینرها توسط ContainerD مدیریت بشن.
یعنی چی؟ یعنی وقتی live restore رو enable می‌کنیم، داکر دیمن موقع stop شدن اون سیگنال رو به کرنل نمیرسونه.
حالا این ContainerD چطور مدیریت میکنه؟ با Containerd-Shim
چطور؟ ابزار ContainerD میاد برای هر کانتینر یک پروسه درست میکنه، کافیه دستور زیر رو بزنید تا ببینید پروسه‌های ContainerD-Shim سرور رو:
می‌بینید که به تعداد هر کانتینر شما یک پروسه Shim هم وجود داره.
این Shim کارش چیه؟ parent process اون child process های داخل کانتینر هست. یکی از دلایل وجودش و جداسازیش از ContainerD اینه که اگه خدایی نکرده Containerd استاپ یا ریستارت شد، کانتینرها از دست نرن.
@DevTwitter | <Hossein Alizadeh Dehnavi/>
یه سرچ زدم تا ببینم راهکار چیه؟
با مفهوم Live Restore آشنا شدم.
قابلیتی در داکر چه اجازه میده کانتینرها به فعالیت خودشون در شرایط restart یا stop شدن داکر دیمن ادامه بدن.
اومدم اول روی سیستم خودم تست گرفتم و کانفیگ زیر:
{
"live-restore": true
}رو در فایل کانفیگوریشن داکر دیمن قرار دادم و ریستارتش کردم و خداروشکر هیچ کانتینری exited نشد.
روی سیستم خودم یه تست دیگه گرفتم و داکر دیمن رو به مدت چند ثانیه stop کردم و بعد دوباره start کردم و وضعیت کانتینرهارو چک کردم و دیدم درسته بازهم هیچ کانتینری down نشده.
اما برام سوال شد که، اگه داکر دیمن up نیست، پس کانتینرهارو کی داره مدیریت میکنه؟ و چطوری؟
داستان از اونجاست که به طور معمول وقتی داکر دیمن استاپ یا ریستارت میشه، یک سیگنال از طریق containerd به کرنل میده و میگه هر پروسسی که توسط Docker ران شده رو kill کن.
اما معماری داکر بخاطر decoupled (یعنی مجزا بودن بخش مدیریت کانتینر از ساخت کانتینر) بودنش این اجازه رو میده که وقتی داکر دیمن استاپ شد، همچنان کانتینرها توسط ContainerD مدیریت بشن.
یعنی چی؟ یعنی وقتی live restore رو enable می‌کنیم، داکر دیمن موقع stop شدن اون سیگنال رو به کرنل نمیرسونه.
حالا این ContainerD چطور مدیریت میکنه؟ با Containerd-Shim
چطور؟ ابزار ContainerD میاد برای هر کانتینر یک پروسه درست میکنه، کافیه دستور زیر رو بزنید تا ببینید پروسه‌های ContainerD-Shim سرور رو:
ps aux | grep shim
می‌بینید که به تعداد هر کانتینر شما یک پروسه Shim هم وجود داره.
این Shim کارش چیه؟ parent process اون child process های داخل کانتینر هست. یکی از دلایل وجودش و جداسازیش از ContainerD اینه که اگه خدایی نکرده Containerd استاپ یا ریستارت شد، کانتینرها از دست نرن.
@DevTwitter | <Hossein Alizadeh Dehnavi/>
- ❤ 47
- 👍 12
