https://virgool.io/feed/@Arman.Mollaei fa 2026-06-17 07:16:09 https://files.virgool.io/upload/users/1581659/avatar/2JbnYB.jpg?height=120&width=120 https://virgool.io/@Arman.Mollaei https://virgool.io/@Arman.Mollaei/devsecops-b2exs2chbmkq مفهوم DevSecOps چیست؟DevSecOps تکامل یافته است تا نیاز به ایجاد امنیت به طور مداوم در سراسر SDLC را برطرف کند تا تیم های DevOps بتوانند برنامه های ایمن را با سرعت و کیفیت ارائه دهند. ترکیب آزمایش، تریاژ، و کاهش ریسک زودتر در گردش کار CI/CD از عواقب زمان بر و اغلب پرهزینه ایجاد یک تعمیر پس از تولید جلوگیری می کند. این مفهوم بخشی از «تغییر به چپ» است، که آزمایش امنیتی را به سمت توسعه‌دهندگان سوق می‌دهد و آنها را قادر می‌سازد تا مسائل امنیتی را در کد خود در زمان واقعی به جای «پیچ کردن روی امنیت» در پایان SDLC برطرف کنند. DevSecOps کل SDLC را شامل می شود، از برنامه ریزی و طراحی گرفته تا کدنویسی، ساخت، آزمایش و انتشار، با حلقه های بازخورد مداوم و بینش در زمان واقعی.DevOps رویکردی برای توسعه نرم افزار است که بر سه رکن متمرکز است: فرهنگ سازمانی، فرآیند و فناوری و ابزار. هر سه به منظور کمک به تیم‌های توسعه و عملیات فناوری اطلاعات برای ایجاد، آزمایش و انتشار نرم‌افزار به شیوه‌ای سریع‌تر، چابک‌تر و تکراری‌تر از فرآیندهای توسعه نرم‌افزار سنتی، به طور مشترک کار می‌کنند.به گفته The DevOps Handbook، «در DevOps ایده‌آل، توسعه‌دهندگان بازخورد سریع و دائمی در مورد کار خود دریافت می‌کنند که به آنها امکان می‌دهد به سرعت و مستقل کد خود را پیاده‌سازی، ادغام و اعتبارسنجی کنند و کد را در محیط تولید مستقر کنند.»به زبان ساده، DevOps در مورد از بین بردن موانع بین دو تیم سنتی است. در یک مدل DevOps، تیم‌های توسعه و عملیات در کل چرخه عمر نرم‌افزار، از توسعه و آزمایش تا استقرار و عملیات، با هم کار می‌کنند.DevSecOps در مقابل DevOpsادغام امنیت: DevOps معمولاً بر توسعه و ادغام عملیات متمرکز است، در حالی که DevSecOps یک بعد امنیتی به هر مرحله اضافه می کند.مسئولیت های تیم: در یک مدل DevOps، امنیت اغلب یک فرآیند جداگانه است که پس از مرحله ساخت به وجود می آید. DevSecOps امنیت را به عنوان مسئولیت همه تلقی می کند که در تمام مراحل خط لوله ضروری است.ابزارها و روش‌ها: در حالی که هم DevOps و هم DevSecOps از اتوماسیون و یکپارچه‌سازی ابزار استفاده می‌کنند، DevSecOps از ابزارها و شیوه‌هایی متمرکز بر امنیت مانند تجزیه و تحلیل کد پویا، مدل‌سازی تهدید و نظارت بر انطباق استفاده می‌کند.اهداف تجاری: هدف DevOps تحویل سریع و قابل اعتماد نرم افزار است و DevSecOps محدودیتی را برای انجام این کار بدون به خطر انداختن امنیت اضافه می کند.هدف نهایی DevSecOps این است که اطمینان حاصل شود که امنیت فقط یک افزونه نیست، بلکه بخشی ذاتی از فرآیندهای توسعه و استقرار است، به جای پس از شناسایی تهدید یا نقض، مسائل امنیتی بالقوه را در زمان وقوع آنها رسیدگی می کند. این موضع پیشگیرانه در مورد امنیت به خوبی با ماهیت چابک و پاسخگو شیوه های DevOps مطابقت دارد.مقایسه DevSecOps و SecDevOps:DevSecOpsSecDevOpsچرا DevSecOps؟1. استاندارد در پیاده سازی امنیت برنامه است2. دید بالایی برای تهدیدات امنیتی فراهم می کند3. محاسبات ابری را ایمن تر می کند4. چرخه های توسعه را کوتاه می کند5. به مشتری شما سود می رساندچرخه عمر نرم افزار DevSecOpsروی DevSecOps تمرکز بیشتری دارید؟یکپارچه سازی امنیتی: DevSecOps امنیت را در هر مرحله از چرخه عمر توسعه نرم افزار، از طراحی اولیه تا توسعه، آزمایش، استقرار و تحویل نرم افزار یکپارچه می کند. این یک روش در DevSecOps است که در آن امنیت زودتر به فرآیند توسعه وارد می شود ("shift left" به انتقال یک مرحله به نقطه اولیه در جدول زمانی فرآیند اشاره دارد). هدف این است که آسیب‌پذیری‌ها و مسائل امنیتی را در اسرع وقت شناسایی کنیم، در حالی که معمولاً هزینه کمتری دارند و رسیدگی به آنها آسان‌تر است.امنیت مستمر: امنیت یک نگرانی مستمر است و با فعالیت‌های در حال انجام مانند مدل‌سازی تهدید، ارزیابی ریسک و تست امنیتی خودکار در خط لوله توسعه مورد توجه قرار می‌گیرد.اتوماسیون وظایف امنیتی: فرآیندهای امنیتی خودکار و در خطوط لوله یکپارچه سازی/تحویل پیوسته (CI/CD) تعبیه شده اند. بررسی های امنیتی خودکار در چندین مرحله از خط لوله انجام می شود تا اطمینان حاصل شود که امنیت سازگار است و به نظارت دستی وابسته نیست.همکاری و فرهنگ: تشویق یک فرهنگ مشارکتی که در آن امنیت یک مسئولیت مشترک بین تمام تیم های درگیر در چرخه عمر توسعه نرم افزار، از جمله توسعه دهندگان، عملیات و پرسنل امنیتی است.آموزش و آموزش: تلاش های پیشگیرانه برای آموزش اعضای تیم در مورد بهترین شیوه های امنیتی و توانمندسازی آنها برای اجرای موثر اقدامات امنیتی.انطباق و حاکمیت: اطمینان از مطابقت همه کدها، زیرساخت ها و فرآیندها با قوانین، مقررات و استانداردهای امنیتی مربوطه در طول فرآیند توسعه.یکپارچه سازی ابزار امنیتی: استفاده از ابزارهای امنیتی مختلف برای خودکار کردن اسکن آسیب پذیری ها، بررسی های انطباق و ارزیابی وضعیت امنیتی. این ابزارها در سیستم های کنترل نسخه، سرورهای ساخت و فرآیندهای استقرار یکپارچه شده اند.مدیریت حادثه و واکنش: ایجاد و تمرین رویه‌های واکنش به حوادث امنیتی که امکان اقدام سریع و مؤثر در هنگام وقوع حوادث امنیتی را فراهم می‌کند.حلقه‌های بازخورد: پیاده‌سازی مکانیزم‌های بازخورد قوی برای بهبود مستمر شیوه‌های امنیتی مبتنی بر داده‌های عملیاتی، نتایج تست‌های امنیتی و پاسخ‌گویی به حادثه در دنیای واقعی.مدیریت پیکربندی: کنترل تغییرات در پیکربندی سیستم، و استفاده از زیرساخت به عنوان کد (IaC) برای مدیریت و ارائه زیرساخت به روشی ثابت و تکرارپذیر، اطمینان از اعمال تنظیمات امنیتی به صورت جهانی.ایمن سازی زنجیره تامین: DevSecOps فراتر از محیط توسعه فوری گسترش می یابد تا زنجیره تامین گسترده تر، از جمله کتابخانه های شخص ثالث، ابزارها و سایر اجزایی که به محصول نهایی کمک می کنند را در بر بگیرد.مسئولیت های هر تیم در DevSecOpsتیم توسعهکدنویسی ایمن: نوشتن کد با در نظر گرفتن بهترین شیوه های امنیتی برای جلوگیری از آسیب پذیری ها.تجزیه و تحلیل کد: استفاده از ابزارهای تجزیه و تحلیل استاتیک و پویا برای بررسی کدها برای مسائل امنیتی.همکاری: همکاری نزدیک با تیم های امنیتی و عملیاتی برای درک الزامات و استانداردهای امنیتی.آموزش و آموزش: یادگیری مداوم در مورد تهدیدات امنیتی جدید و ادغام جلسات متمرکز بر امنیت در شیوه های توسعه.تیم امنیتییکپارچه سازی: تعبیه شیوه های امنیتی در خط لوله CI/CD.انتخاب و مدیریت ابزار: انتخاب و نگهداری ابزارهای امنیتی مورد استفاده در چرخه عمر توسعه.مدیریت آسیب‌پذیری: شناسایی، طبقه‌بندی، اولویت‌بندی، اصلاح و کاهش آسیب‌پذیری‌های نرم‌افزار.آموزش امنیتی: ارائه آموزش به تیم های توسعه و عملیات برای افزایش مهارت های امنیتی آنها.پاسخ به رویداد: رهبری پاسخ به حوادث امنیتی و اطمینان از اینکه درس های آموخته شده به فرآیند توسعه بازخورد داده می شود.تیم عملیاتاستقرار امن: اطمینان از ایمن بودن خط لوله استقرار و اینکه پیکربندی ها آسیب پذیری ایجاد نمی کنند.مدیریت محیط: ایمن نگه داشتن محیط های تولید، آزمایش و توسعه.نظارت و پاسخ: پیاده‌سازی ابزارها و شیوه‌هایی برای پایش بلادرنگ سیستم‌ها و برنامه‌ها برای شناسایی و پاسخ به تهدیدات امنیتی.کنترل دسترسی: مدیریت دسترسی برای اطمینان از اینکه فقط افراد مجاز به منابع خاصی دسترسی دارند، به ویژه در محیط های تولید.تیم تضمین کیفیت (QA).تست امنیت: ترکیب تست متمرکز بر امنیت در فرآیندهای تضمین کیفیت.تست اتوماسیون: شامل موارد تست امنیتی در مجموعه تست خودکار برای شناسایی آسیب‌پذیری‌ها قبل از استقرار.خلاصه DevSecOpsبه طور خلاصه، DevSecOps یک استراتژی سازمانی است که برای موفقیت به ترکیبی از مسئولیت مشترک، یکپارچگی فرآیند و بهبود مستمر نیاز دارد. این روش تفکر سازمان ها و مدیریت امنیت را تغییر می دهد و از همان ابتدا آن را به یک جزء اساسی از سیستم ها و نرم افزار تبدیل می کند. آرمان ملایی آرمان ملایی Sun, 14 Jan 2024 16:00:23 +0330 https://virgool.io/@Arman.Mollaei/top-8-docker-image-best-practices-jzebk7wvdni0 پذیرش Docker به طور مداوم افزایش می‌یابد و بسیاری با آن آشنا هستند، اما هنوز هم خیلی‌ها به بهترین شکل از روش‌های داکر استفاده نمی‌کنند.چرا باید از روش‌های ایده آل Docker استفاده کنیم؟در این مقاله قصد داریم 8 روش را به شما نشان دهیم که با کمک آن‌ها می‌توانید از Docker به شیوه‌ای درست در پروژه‌های خود استفاده کنید:● بهبود امنیت● بهینه سازی اندازه تصویراز برخی از ویژگی‌های مفید Docker بهره ببرید و همچنین Dockerfiles تمیز‌‌تر و قابل نگهداری تری بنویسید.روش اول - استفاده از تصویر رسمی‌ و تایید شده Dockerبه عنوان تصویر پایههر زمانی که امکان داشت، از یک تصویر رسمی‌ و تایید شده Docker به عنوان تصویر پایه استفاده کنید.فرض کنید در حال توسعه یک برنامه Node.jsهستید و می‌خواهید آن را به عنوان یک تصویر Docker بسازید و اجرا کنید.به جای گرفتن تصویر از سیستم عامل پایه و نصب node.js، npm و هر ابزار دیگری که برای برنامه خود نیاز دارید، از تصویر رسمی‌ نود برنامه خود استفاده کنید.بهبودها:پاک کننده Dockerfileتصویر رسمی‌ و تایید شده، که در حال حاضر با بهترین شیوه‌ها ساخته شده است.روش دوم - استفاده نسخه‌های خاص تصویر داکرتا الان ما تصویر پایه را انتخاب کرده‌ایم، اما اکنون وقتی تصویر برنامه‌های خود را از این Dockerfile می‌سازیم، همیشه از آخرین تگ تصویر نود استفاده می‌کند.چرا این مشکل ایجاد می‌شود؟● ممکن است نسخه تصویر متفاوتی را که قبلا ساخته شده است، دریافت کنید.● نسخه جدید تصویر ممکن است چیزهایی را خراب کند.● آخرین برچسب غیر قابل پیش بینی است و باعث رفتار غیرمنتظره ای شده است.بنابراین به جای استفاده از آخرین تگ تصویر به صورت تصادفی، شما می‌توانید یک نسخه را فیکس کرده و همان طور که دوست دارید، برنامه خود را با کمک نسخه خاصی که می‌خواهید از تصویر رسمی‌ آن استفاده کنید، گس‌‌ترش دهید. قانون مهم این است: هر چه خاص ‌‌تر، بهترروش بهبود :ایجاد شفافیت برای این که بدانید دقیقا از چه نسخه‌ای از تصویر پایه استفاده می‌کنید.روش سوم - استفاده از تصاویر رسمی‌ با اندازه کوچکهنگامی‌ که یک تصویر Node.js را انتخاب می‌کنید، می‌بینید که در واقع چندین تصویر رسمی‌وجود دارد. نه تنها با شماره نسخه‌های مختلف، بلکه توزیع‌های سیستم عامل مختلفحالا سوال مهم این است، شما کدام را انتخاب می‌کنید و چرا این موضوع اهمیت دارد؟● اندازه تصویراقدام نادرست : اگر تصویر بر اساس یک توزیع سیستم‌عامل کامل مانند Ubuntu یا Centos باشد، شما از قبل مجموعه‌ای از ابزارها برای تصاویر را خواهید داشت. بنابراین اندازه تصویر بزرگ‌‌تر خواهد بود، اما شما به اکثر این ابزارها در تصاویر برنامه خود نیاز ندارید.اقدام درست : داشتن تصاویر کوچک‌‌تر به این معنی است که شما به فضای ذخیره سازی کم‌‌تری در repository تصویر و استقرار سرور نیاز دارید و همچنین می‌توانید هنگام pull یا push آن‌ها از repository، تصاویر را سریع‌‌تر انتقال دهید.● مشکل امنیتیاقدام نادرست : با نصب تعدادی زیادی از ابزارها در داخل سیستم، شما باید حتما جنبه امنیت را نیز در نظر داشته باشید. زیرا تصاویر پایه معمولاً حاوی صدها نقطه آسیب پذیری شناخته شده هستند و به این ‌‌ترتیب شما در عمل، سطح بزرگ‌‌تری برای اتک تصویر را در برنامه ایجاد می‌کنند.به این ‌‌ترتیب شما از ابتدا مشکلات امنیتی غیر ضروری را برای تصویر مشخص می‌کنید.اقدام درست : در مقایسه با حالت قبلی، از تصاویر کوچک‌‌تر با توزیع‌های سیستم‌عامل کم‌‌تر، که فقط سیستم لازم را بسته‌بندی می‌کند؛ استفاده کنید. با کمک ابزارها و کتابخانه‌ها، سطح حمله را به حداقل رسانده و مطمئن می‌شوید که تصاویر امن‌‌‌تری می‌سازید.بنابراین بهترین روش در اینجا انتخاب یک تصویر، با یک نسخه خاص بر اساس توزیع سیستم عامل ضعیف‌‌‌تر مانند alpine است.Alpine همه چیزهایی را که برای شروع برنامه خود در یک container مورد نیاز است، دارد، اما بسیار سبک‌‌‌تر است و برای اکثر تصاویری که در داکر‌هاب نگاه می‌کنید، یک تگ نسخه با توزیع Alpine در آن خواهید دید.که یکی از رایج ‌‌ترین و محبوب ‌‌ترین تصاویر پایه برای کانتینرهای Docker است.روش چهارم - بهینه سازی کش (cache) برای لایه‌های تصویر هنگام ساخت یک تصویرلایه‌های تصویر چیست و کش لایه تصویر به چه معناست؟1) لایه‌های تصویر چیست؟یک تصویر Docker بر اساس یک Dockerfile ساخته شده است و در Dockerfile هر دستور یا دستورالعمل یک لایه تصویر ایجاد می‌کند:وقتی از یک تصویر پایه node alpine مانند مثال بالا استفاده می‌کنیم، این تصویر از قبل یکسری لایه دارد، چون قبلاً با استفاده از Dockerfile ساخته شده است. به علاوه، در Dockerfile ما چند دستور دیگر داریم که هر کدام یک لایه جدید به این تصویر اضافه می‌کنند.2) در مورد کش کردن چطور؟هر لایه توسط Docker ذخیره می‌شود. بنابراین وقتی تصویر خود را بازسازی می‌کنید، اگر Dockerfile شما تغییر نکرده باشد، Docker فقط از لایه‌های کش برای ساخت تصویر استفاده می‌کند.مزایای لایه‌های تصویر کش شده:● ساخت سریع‌‌تر تصویر● pull و push سریع‌‌تر نسخه‌های جدید تصویراگر یک نسخه تصویری جدید از همان برنامه را pull کنیم و فرض کنیم 2 لایه جدید، در نسخه جدید اضافه شده است. در این موقع فقط لایه‌های جدید اضافه شده، دانلود می‌شوند، بقیه قبلاً به صورت local توسط Docker ذخیره شده‌اند.3) بهینه‌‌سازی cacheبرای بهینه‌سازی کش، باید در نظر گرفت، هنگامی‌ که یک لایه تغییر می‌کند، تمام لایه‌های بعدی یا پایین دستی نیز باید دوباره ایجاد شوند. به عبارت دیگر، هنگامی‌ که محتویات یک خط را در Dockerfile تغییر می‌دهید، کش تمام خطوط یا لایه‌های زیرین شکسته و باطل می‌شوند.بنابراین در این جا قانون و بهترین اقدام این است:دستورات خود را در Dockerfile از کم‌‌ترین تا متداول‌‌‌ترین دستورات در حال تغییر مرتب کنید تا از مزایای کش استفاده کرده و از این طریق سرعت ساخت تصویر را بهینه کنید.روش پنجم - استفاده از فایل .dockerignoreبه طور معمول وقتی یک تصویر را می‌سازیم، برای اجرای داخلی اپلیکیشن به همه چیزهایی که در پروژه است، مانند فولدرهای خود ساخته، اهداف یا فولدر ساخت یا فایل‌های readme و … نیاز نداریم.شاید این سوال برای شما پیش بیاید که چگونه می‌توان از قرار گرفتن چنین محتوایی در تصویر نهایی اپلیکیشن جلوگیری کرد؟پاسخ ساده به این سوال، استفاده از فایل dockerignore. است.در حقیقت ما فقط فایل .dockerignore را ایجاد می‌کنیم و تمام فایل‌ها و پوشه‌هایی را که می‌خواهیم نادیده گرفته شوند، را لیست می‌کنیم و در هنگام ساخت تصویر، داکر به محتویات فایل نگاه کرده و هر چیزی را که در داخل آن مشخص شده است نادیده می‌گیرد.روش بهبود:● کاهش حجم تصویرروش ششم - استفاده از ساخت‌های چند مرحله‌ایفرض کنید در پروژه شما محتویاتی (مانند توسعه، ابزارهای آزمایش و کتابخانه‌ها) وجود دارد که در طول فرایند، برای ساختن تصویر به آن‌ها نیاز دارید اما در خود تصویر نهایی برای اجرای برنامه به آن‌ها نیاز ندارید.اگر این artifact‌ها را در تصویر نهایی خود نگه دارید، حتی اگر برای اجرای برنامه کاملاً غیر ضروری باشند، باز هم منجر به افزایش اندازه تصویر و افزایش سطح اتک می‌شود.پس چگونه مرحله ساخت را از مرحله اجرا جدا کنیم؟به عبارت دیگر، چگونه می‌توانیم وابستگی‌های ساخت را از تصویر حذف کنیم، در حالی که هنوز آن‌ها را در حین ساخت تصویر در دسترس داریم؟خوب، برای انجام این کار می‌توانید از روشی که به آن ساخت‌های چند مرحله‌ای می‌گویند، استفاده کنیدویژگی ساخت چند مرحله‌ای به شما این امکان را می‌دهد که از چندین تصویر موقت در طول فرایند ساخت استفاده کنید، اما تنها آخرین تصویر به عنوان artifact نهایی نگه دارید.روش هفتم - استفاده حداقلی از کاربر خاصوقتی این تصویر را ایجاد کرده و در نهایت آن را به عنوان یک کانتینر اجرا می‌کنیم، از کدام کاربر سیستم عامل برای راه اندازی اپلیکیشن در داخل استفاده می‌شود؟به طور پیش فرض، زمانی که یک Dockerfile، یک کاربر را مشخص نمی‌کند، از یک کاربر root استفاده می‌کند. اما در واقعیت و در بیش‌‌تر مواقع دلیلی برای اجرای کانتینرهایی با امتیازات روت وجود ندارد.این موضوع در حقیقت یک مشکل امنیتی را معرفی می‌کند، زیرا هنگامی‌که کانتینر روی‌ هاست راه‌اندازی می‌شود، به طور بالقوه دسترسی روت در‌ هاست Docker خواهد داشت.بنابراین اجرای یک برنامه در داخل کانتینر با کاربر روت یک امتیاز مضاعف بر روی‌ هاست است که کار را برای اتکر آسان‌‌‌تر می‌کند.and basically get hold of the underlying host and its processes, not only the container itself Especially if the application inside the container is vulnerable to exploitation.برای جلوگیری از این موضوع، بهترین کار این است که به سادگی یک کاربر و یک گروه اختصاصی در تصویر Docker ایجاد کنید تا برنامه را اجرا کرده و همچنین برنامه را در داخل کانتینر با همان کاربر اجرا کنید.شما می‌توانید از دستورالعملی به نام USERبا نام کاربری استفاده کرده و بعد از آن برنامه را به راحتی راه‌اندازی کنید.نکته: برخی از تصاویر از قبل دارای یک دسته کاربر عمومی‌هستند که می‌توانید از آن استفاده کنید. بنابراین نیازی به ایجاد یک مورد جدید ندارید. برای مثال تصویر node.js قبلاً یک کاربر عمومی‌به نام node رادسته‌بندی می‌کنید و بعد به سادگی می‌توانید، از آن برای اجرای برنامه در داخل کانتینر استفاده کنید.روش هشتم - اسکن تصاویر برای آسیب‌پذیری‌های امنیتیدر نهایت، شما چگونه می‌توانید، مطمئن شوید که تصویری که می‌سازید، چند آسیب‌پذیری امنیتی دارد؟بهترین پیشنهاد به عنوان یک راه حل نهایی و ایده آل، این است که پس از ساختن تصویر، آن را از نظر آسیب پذیری‌های امنیتی با استفاده از دستور dockerscanاسکن کنید.در پس‌زمینه، Docker در واقع از سرویسی به نام snyk برای اسکن آسیب‌پذیری تصاویر بهره می‌برد و برای اسکن از پایگاه داده‌ای آسیب پذیری‌ها استفاده می‌کند، که به صورت مدام بروزرسانی می‌شود.نمونه خروجی دستور اسکن docker به شکل زیر است:همان طور که در تصویر بالا مشاهده می‌کنید، مواردی مانند فهرست زیر مشخص شده است:1) نوع آسیب پذیری2) یک URL برای اطلاعات بیش‌‌تر3) نکته‌ قابل توجه این است، که مشخص شده است، کدام نسخه از کتابخانه مربوطه می‌تواند، آسیب پذیری را برطرف کند. بنابراین شما می‌توانید با بروزرسانی کتابخانه‌های خود، از شر این مشکلات خلاص شوید.خودکار کردن اسکنعلاوه بر اسکن دستی تصاویر با دستور docker scanدر یک CLI، شما می‌توانید Docker Hub را برای اسکن خودکار تصاویر، زمانی که به repository،push می‌شوند، پیکربندی کنید. همچنین شما می‌توانید در هنگام ساخت تصاویر Docker، آن‌ها را در پایپ‌لاین‌های CI/CD خود ادغام کنید.جمع بندیدر این مقاله به 8 تا از بهترین روش‌هایی که امروزه می‌توانید برای ساخت تصاویر Docker کم‌‌‌تر و ایمن‌‌‌تر استفاده کنید، اشاره کردیم. امیدواریم این روش‌ها برای بعضی از شما کاربردی باشند. البته روش‌های بسیار بیش‌‌تری در رابطه با Docker وجود دارد، اما به نظر می‌رسد که استفاده از روش‌های اشاره شده در این مقاله بتواند نتایج بسیار مثبتی، هنگام استفاده از Docker در تولید (محصول) برای شما داشته باشد. اگر در مورد این مقاله نظری داشتین یا موارد دیگه ای داشتین خوشحال میشم تا آن‌ها را در کامنت به اشتراک بگذارید. آرمان ملایی آرمان ملایی Wed, 06 Apr 2022 14:16:38 +0430