Docker Container’s Filesystem Demystified
موضوعی که میخواهیم باهم بررسی کنیم، کانسپتی هست تحت عنوان Storage Driver ها در اکوسیستم داکر !! تمام هدف این است که داکر بتواند نوعی فایل سیستم مناسب برای کانتینر ما فراهم آورد. درایوری که داکر در حال حاظر از آن استفاده میکند، در اصل نوعی Union FS تحت عنوان OverlayFS است. گرچه موارد مشابهی نیز مانند aufs و devicemapper و ... نیز وجود داشته و دارند اما داکر با اضافه کردن تغییراتی در این فایل سیستم بخصوص برای مثال اضافه کردن و بهبود قابلیتهایی چون Page Caching و ... نسخهای تحت عنوان overlay2 را ایجاد نموده و در نسخ جدید از آن استفاده میکند. درک درست سازوکار نهفته در این نوع فایل سیستمها برای مثال عملیات CoW و ... میتواند در بالا بردن پرفورمنس سرویس هایی چون OSS و ... بسیار مفید و حیاتی باشد. در ادامه چندین مقاله مفید و بنچمارک های مختلف آورده شده است که میتوانید از آنها استفاده کنید.
Main Links:
◾️Link 1 Link 2 Link 3 Link 4
Benchmark Links:
◾️Link 1 Link 2 Link 3
#container #docker #opensource #devops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx
موضوعی که میخواهیم باهم بررسی کنیم، کانسپتی هست تحت عنوان Storage Driver ها در اکوسیستم داکر !! تمام هدف این است که داکر بتواند نوعی فایل سیستم مناسب برای کانتینر ما فراهم آورد. درایوری که داکر در حال حاظر از آن استفاده میکند، در اصل نوعی Union FS تحت عنوان OverlayFS است. گرچه موارد مشابهی نیز مانند aufs و devicemapper و ... نیز وجود داشته و دارند اما داکر با اضافه کردن تغییراتی در این فایل سیستم بخصوص برای مثال اضافه کردن و بهبود قابلیتهایی چون Page Caching و ... نسخهای تحت عنوان overlay2 را ایجاد نموده و در نسخ جدید از آن استفاده میکند. درک درست سازوکار نهفته در این نوع فایل سیستمها برای مثال عملیات CoW و ... میتواند در بالا بردن پرفورمنس سرویس هایی چون OSS و ... بسیار مفید و حیاتی باشد. در ادامه چندین مقاله مفید و بنچمارک های مختلف آورده شده است که میتوانید از آنها استفاده کنید.
Main Links:
◾️Link 1 Link 2 Link 3 Link 4
Benchmark Links:
◾️Link 1 Link 2 Link 3
#container #docker #opensource #devops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx
A Comparison Of Linux Container Images❗️
چند وقته پیش به نوشته جالبی از آقای Scott McCarty برخورد کردم گفتم بزارم شاید دوستان هم استفاده کردند. موضوع مورد بحث این هست که ایشون یک مقایسه بسیار جالب از تمام Container Image های Base انجام دادهاند و از جهاتی چون موارد زیر آنهارو مقایسه کردهاند:
Architecture
Security
Binary Hardening
Performance
نکته جالبی هم راجب بحث ایمیج های DistroLess ارائه دادند که خوندنش خالی از لطف نبوده و دید نسبتا خوب و کاملی در انتخاب یک Base ایمیج متناسب با کارتون به شما میدهد.
ضمنا ایشون Content های به شدت پرمحتوایی در زمینه Container Internals و Container Standards ها دارن که میتونید در چنل یوتیوبشون اونهارو هم مطالعه کنید و استفاده کنید.
Link:
◾️
◾️
〰️〰️〰️〰️〰️〰️
© @DevOpsEx
چند وقته پیش به نوشته جالبی از آقای Scott McCarty برخورد کردم گفتم بزارم شاید دوستان هم استفاده کردند. موضوع مورد بحث این هست که ایشون یک مقایسه بسیار جالب از تمام Container Image های Base انجام دادهاند و از جهاتی چون موارد زیر آنهارو مقایسه کردهاند:
Architecture
Security
Binary Hardening
Performance
نکته جالبی هم راجب بحث ایمیج های DistroLess ارائه دادند که خوندنش خالی از لطف نبوده و دید نسبتا خوب و کاملی در انتخاب یک Base ایمیج متناسب با کارتون به شما میدهد.
ضمنا ایشون Content های به شدت پرمحتوایی در زمینه Container Internals و Container Standards ها دارن که میتونید در چنل یوتیوبشون اونهارو هم مطالعه کنید و استفاده کنید.
Link:
◾️
https://crunchtools.com/comparison-linux-container-images/
Youtube Channel:◾️
https://www.youtube.com/channel/UCkWQhDzOxooYHp5LrTqnkdg
#container #docker #opensource #devops 〰️〰️〰️〰️〰️〰️
© @DevOpsEx
همیشه برام جالب بود که دلیل اصلی اینکه پلتفرم هایی مثل کوبرنتیز و یا داکر سرویس هایی رو تحت عنوان docker-proxy و kube-proxy نوشتن و هدف نهایی پشت این سرویس ها چی بوده و از چه مشکلاتی جلوگیری می کنن؟
کار مهمی که امروزه این سرویسها انجام میدن این هست که بقولی ما بتونیم حتی از طریق Local Network به اون پاد یا کانتینر مد نظرمون برسیم ( مشخصا این سرویس ها وظایف دیگهای رو هم بر عهده دارند! ) چیزی که به شکل دیفالت در لینوکس ممکن نیست چرا که کرنل با پکت هایی که از شبکه داخلی آمده باشن 127.0.0.1/8 به شکلی خاصی رفتار میکنه چیزی که به ظاهر از RFC 1122 مقرر شده اینگونه باشه. به زبانی ساده تر، یک نود در شبکه هیچوقت پکتی که آدرس Destination اون 127.0.0.1 رو نمیتونه Transmit بکنه و به اصطلاح اون رو Drop میکنه.
ولی خب چیزی که همیشه مد نظرم بود ما بجای اینکه سرویسهایی بنویسیم مثل همون Proxy ها میتونیم به راحتی با ست کردن یک متغیر sysctl به نام route_localnet و یکمی بازی با IPTables مشکل رو حل کنیم یا دور بزنیم و به کانتینر مد نظرمون از طریق Localhost برسیم.
و خب بعد از حدود یک هفته تحقیق فهمیدم که در سال 2020 یک CVE-2020-8558 تحت همین سناریو بیرون آمد که اگر داکر یا کوبر با این متغیر کار بکنن چه مشکلی پیش میاد.
A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.
و چقدر اون موقع به شکل راحتی سرویسهایی که به 127.0.0.1 به اصطلاح Bind شدن بدون هیچگونه Authentication و یا Encryption ای میتونن Expose بشن به خودی خود! که خب همین عامل باعث شد که داکر و یا کوبر سرویس هایی رو برای مدیریت بهتر این مشکلات بنویسن چرا که لینوکس به شکل دیفالت حتی Rule های IPTables رو برای پکت های Local Network در نظر نمیگیره !!
CVE-2020-8558:
◾️Link 1 Link 2
For More Info:
◾️Link 3
#container #docker #opensource #devops #devsecops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx
کار مهمی که امروزه این سرویسها انجام میدن این هست که بقولی ما بتونیم حتی از طریق Local Network به اون پاد یا کانتینر مد نظرمون برسیم ( مشخصا این سرویس ها وظایف دیگهای رو هم بر عهده دارند! ) چیزی که به شکل دیفالت در لینوکس ممکن نیست چرا که کرنل با پکت هایی که از شبکه داخلی آمده باشن 127.0.0.1/8 به شکلی خاصی رفتار میکنه چیزی که به ظاهر از RFC 1122 مقرر شده اینگونه باشه. به زبانی ساده تر، یک نود در شبکه هیچوقت پکتی که آدرس Destination اون 127.0.0.1 رو نمیتونه Transmit بکنه و به اصطلاح اون رو Drop میکنه.
ولی خب چیزی که همیشه مد نظرم بود ما بجای اینکه سرویسهایی بنویسیم مثل همون Proxy ها میتونیم به راحتی با ست کردن یک متغیر sysctl به نام route_localnet و یکمی بازی با IPTables مشکل رو حل کنیم یا دور بزنیم و به کانتینر مد نظرمون از طریق Localhost برسیم.
و خب بعد از حدود یک هفته تحقیق فهمیدم که در سال 2020 یک CVE-2020-8558 تحت همین سناریو بیرون آمد که اگر داکر یا کوبر با این متغیر کار بکنن چه مشکلی پیش میاد.
A flaw was found in Kubernetes that allows attackers on adjacent networks to reach services exposed on localhost ports, previously thought to be unreachable. This flaw allows an attacker to gain privileges or access confidential information for any services listening on localhost ports that are not protected by authentication.
و چقدر اون موقع به شکل راحتی سرویسهایی که به 127.0.0.1 به اصطلاح Bind شدن بدون هیچگونه Authentication و یا Encryption ای میتونن Expose بشن به خودی خود! که خب همین عامل باعث شد که داکر و یا کوبر سرویس هایی رو برای مدیریت بهتر این مشکلات بنویسن چرا که لینوکس به شکل دیفالت حتی Rule های IPTables رو برای پکت های Local Network در نظر نمیگیره !!
CVE-2020-8558:
◾️Link 1 Link 2
For More Info:
◾️Link 3
#container #docker #opensource #devops #devsecops
〰️〰️〰️〰️〰️〰️
© @DevOpsEx
Dustin Specker
iptables: How Docker Publishes Ports
The next question to answer after writing How do Kubernetes and Docker create IP Addresses?! is “How does Docker handle publishing ports?”
In the previous post, we created our own network namespaces, virtual interfaces, and assigned IP addresses to these…
In the previous post, we created our own network namespaces, virtual interfaces, and assigned IP addresses to these…
سلام عزیزان، امیدوارم حالتون خوب باشه
اول از همه بابت استقبالی که در طول این ۲ سال از دوره های داکر برای همه و Gitlab CI/CD برای توسعه دهندگان تنبل داشتید صمیمانه سپاسگزارم. این دوره ها تقریبا ۲ سال پیش ضبط شدند و اخیرا باتوجه به درخواستهای متعدد دوستان مبنی بر پایینتر بودن کیفیت دورهها نسبت به ویدئوهای آموزشی یوتوب، تصمیم به حذف این دوره ها از وبسایت گرفتیم تا درآینده با کیفیت بالاتری بتونیم در خدمتتون باشیم.
این اطلاع رسانی به این منظور است که دوستان زیادی از این کانال با بنده آشنا شدند و دورههارا تهیه کردند. بنابراین دورههای آموزشی “داکر برای همه” و “Gitlab CI/CD برای توسعه دهندگان تنبل” طی ۴۸ ساعت آینده از وبسایت حذف خواهند شد و فقط برای عزیزانی که دورههارو تهیه کرده بودند در پنل کاربری قابل دسترس خواهد بود.
دوره های ذکرشده در متن 👇
دوره داکر برای همه
https://boby.cloud/docker-for-everybody-course
دوره Gitlab CI/CD
https://boby.cloud/gitlab-cicd-course
ممنون از اینکه برای رشد خودتون ارزش قائل هستید و حمایت میکنید. 🙏🌷
#docker #gitlabci
〰️〰️〰️〰️〰️
© @DevOpsEx
اول از همه بابت استقبالی که در طول این ۲ سال از دوره های داکر برای همه و Gitlab CI/CD برای توسعه دهندگان تنبل داشتید صمیمانه سپاسگزارم. این دوره ها تقریبا ۲ سال پیش ضبط شدند و اخیرا باتوجه به درخواستهای متعدد دوستان مبنی بر پایینتر بودن کیفیت دورهها نسبت به ویدئوهای آموزشی یوتوب، تصمیم به حذف این دوره ها از وبسایت گرفتیم تا درآینده با کیفیت بالاتری بتونیم در خدمتتون باشیم.
این اطلاع رسانی به این منظور است که دوستان زیادی از این کانال با بنده آشنا شدند و دورههارا تهیه کردند. بنابراین دورههای آموزشی “داکر برای همه” و “Gitlab CI/CD برای توسعه دهندگان تنبل” طی ۴۸ ساعت آینده از وبسایت حذف خواهند شد و فقط برای عزیزانی که دورههارو تهیه کرده بودند در پنل کاربری قابل دسترس خواهد بود.
دوره های ذکرشده در متن 👇
دوره داکر برای همه
https://boby.cloud/docker-for-everybody-course
دوره Gitlab CI/CD
https://boby.cloud/gitlab-cicd-course
ممنون از اینکه برای رشد خودتون ارزش قائل هستید و حمایت میکنید. 🙏🌷
#docker #gitlabci
〰️〰️〰️〰️〰️
© @DevOpsEx
✔️ داکر به زبان ساده چیست؟
چرا داکر امروزه محبوب شده؟
🖥 مشاهده در یوتوب:
👉 Link: https://www.youtube.com/watch?v=FU--oBJZTMs
#docker #داکر #docker_image #کانتینر #کانتینر_پلتفرم #container #یوتوب_فارسی #bobycloud
〰️〰️〰️〰️〰️
©️ @DevOpsEx | @AI_Python
چرا داکر امروزه محبوب شده؟
🖥 مشاهده در یوتوب:
👉 Link: https://www.youtube.com/watch?v=FU--oBJZTMs
#docker #داکر #docker_image #کانتینر #کانتینر_پلتفرم #container #یوتوب_فارسی #bobycloud
〰️〰️〰️〰️〰️
©️ @DevOpsEx | @AI_Python