هدف این فصل

در این فصل شبکه های دنیای کانتینرها و نحوه ی عملکرد container networking را باهم بررسی می کنیم، یادمیگیریم که container networking چه فرقی با Docker host networking دارد و چگونه باید Docker networking (container networking +Docker host networking ) را بکار بگیریم تا ارتباط سرویس های containerized خود با یکدیگر را برقرار کنیم. در پایان این فصل شما 4 شبکه ی اصلی bridge، overlay، macvlan و host را به خوبی می آموزید و یاد میگیرید که از هرکدام دقیقا کجا و چگونه استفاده کنید. ضمنا قبل از رسیدن به فصل 9ام در این فصل اولین docker swarm cluster خود را ایجاد میکنیم.

معرفی فصل

تا حالا در دوره مفاهیم مهمی از containerization ، معماری microservice و برنامه های Multi-tier را آموخته اید. یادگرفته اید که چطوری با encapsulating (کپسوله سازی!) برنامه ها، محیط های ایزوله برای اجرایشان ایجاد کنید و تمام مهارت های لازم برای شروع یادگیری پیاده سازی معماری های کاربردی و انعطاف پذیر، rapid deployment(دیپلویمنت سریع) و horizontal scaling سرویس هایتان در اختیار شماست. تنها مسئله ای که هنوز برای این کار در اختیار شما نیست دانش networking است. با استفاده از networking میتوانیم ارتباط بین instance های کانتینرها را به درستی و با reliable connectivity برقرار کنیم.

به صورت کلی وقتی در مورد container networking صحبت میکنیم در مورد 2 network صحبت می کنیم. اولی container host یا underlay networking است که شبکه درونی یک کانتینر است و دومی networking between containers یا overlay networking بین کانیتنرهای یک host یا چند cluster . خود Docker به صورت پیش فرض حدود 16 مدل مختلف تنظیمات network را پشتیبانی می کند که با بکار گیری آنها میتوانید از پس تمام استراتژی ها و توپولوژی های شبکه بر بیایید.

مطالعه ی بیشتر:

https://docs.docker.com/network/

نکته:

در کدهای قدیمی compose یا کدهای قدیمی CD (دستورات خام Docker CLI)برای networking ممکن است از link یا link-- استفاده شود. این دستور در نسخه های جدید منسوخ شده است و به زودی از کار خواهد افتاد و به جای آن Docker DNS در دسترس است. درک تفاوت استفاده از Docker DNS به جای link در این فصل بسیار مهم است و از هردوی آنها استفاده خواهیم کرد.

هر کانتینر یک IP address دارد که مخصوص خودش( unique to that container instance ) است. این IP addressها روی یکی زیر شبکه ی مجازی ( virtual subnet ) وجود دارند که این virtual subnet یک بار توسط هسته ی داکر و دفعات بعد توسط هر stack (فایل کامپوز up شده) تولید می شوند. در این subnet ابتدا ترافیک شبکه( network traffic ) رمزنگاری ( encrypted ) شده و سپس به شبکه ی اصلی سیستم ( host machine network interface ) منتقل می شود و پس از انتقال به مقصد( خود سیستم اصلی یا یک سیستم دیگر درون شبکه ی cluster) رمزگشایی( decrypted ) می شود. این ارتباط که پایه ای ترین ارتباط ما در دنیای کانتینرهاست توسط Docker با استفاده از mapping یک container name به container IP address آن انجام می شود. با این ویژگی وقتی که یک cluster با تعداد host های زیاد داشته باشیم زمانی که یک کانتینر از بین برود و روی یک host دیگر از cluster مجددا restart شود، حتی با تغییر container IP address سرویس هایی که با آن در تعامل هستند دوباره به آن دسترسی خواهند داشت.

در دنیای واقعی با چیزی بسیار ساده تر از networking mode بالا سر و کله خواهید زد. در حالت واقعی کانتینرهایی درون یک cluster یا یک standalone host پورتها یا آدرس های مشخصی را از طریق شبکه های تعریف شده در دسترس قرار میدهند تا network traffic را ارسال و دریافت کنند. کانتینرها هنوز IP addressهای خود را دارند ولی با توجه به mapping انجام شده توسط Docker برای ارتباط با آنها میتوانیم از نام و پورت بخصوصی از آنها استفاده کنیم یا حتی به سرویس هایی خارج از زیرساخت خود متصل شویم.

به صورت پیش فرض Docker در حالت bridge network mode شبکه ها را مدیریت می کند. در ابتدای راه اندازی Docker پس از نصب یک شبکه از نوع bridge network ایجاد می شود که به شبکه ی اصلی host متصل است و ارتباط virtual subnetها با سیستم اصلی را برقرار میکند. ترافیک ورودی( ingress ) و ترافیک خروجی ( egress ) بین virtual subnetها و سیستم اصلی از طریق این bridge network اولیه منتقل می شوند.

پس از نصب Docker در محیط لینوکس اگر دستور ifconfig را اجرا کنید بین network های بازگردانده شده docker0 را میبینید که همان bridge network گفته شده است.

همچنین یک private subnet نیز که شامل لیستی از رنج های IP addressهاست (معمولا 172.16.0.0/16 ) نیز برای این bridge network مشاهده می شود. مثلا اگر یک کانتینر با IP addressبرابر با 172.17.8.1 داشته باشیم و درون خود سیستم بخواهیم به آن درخواستی ارسال کنیم، این درخواست از طریق رابط docker0 bridge به کانتینر مورد نظر منتقل می شود. تنها در صورتی این ارتباط بدون واسطه ی docker0 bridge رخ خواهد داد که port بخصوصی از سیستم را برای کانتینر publish کرده باشیم. در این صورت امکان دسترسی به کانتینر دیگر با IP address آن ممکن نیست!

به فصل مثال ها و تمرین های طولانی خوش آمدید!