در بخش اول, ما موفق شدیم تحریم رو دور بزنیم, سرویس ها رو با یک Network به هم متصل کنیم و اپلیکیشن رو اجرا کنیم. قبل از هرچیز باید مجدد تاکید کنم که هدف این مقاله این بود تا developer هایی که با تکنولوژی داکر مشکل دارند, خیلی سریع و مفید با این تکنولوژی آشنایی پیدا کنند و ممکنه که اطلاعات مطرح شده در این مقاله بهترین practice های محیط پروداکشن رو رعایت نکنه.
یکی از بخش های مهمی که در مقاله قبلی فرصت اشاره به اون رو نداشتیم بحث Volume ها بود.
یکی از مهمترین ویژگی های یک داکر کانتینر, امنیت اون هستش و طبیعتا کانتینری که ران شده باید از هر نوع دستبرد خارجی به دور بمونه و حداقل در زمان اجرا از مداخلات بیرونی ناخواسته در کانتینرها جلوگیری بشه. بله این موضوع کاملا درسته که میتونیم از طریق دستوراتی مثل Docker Exec تغییراتی رو در کانتینر بوجود بیاریم, ولی باید بخاطر بسپاریم که این دستور روش و راهی هستش که خود داکر پیش پای ما گذاشته تا مثلا پکیج هایی رو داخل کانتینر نصب کنیم و ...
اما اگر من بخوام فایل های ستینگ پروژه دات نتی که در قسمت 1 ایجاد کردیم رو تغییری بدم و نخوام که فرآیند Build و Deploy ایمیج و کانتینرم رو از اول پیگیری کنم چه کاری باید انجام بدم؟
باید از دستور Volume در فایل Docker-Compose ی که در قسمت قبلی ایجاد کردم استفاده میکردم. در واقع با این دستور قسمتی از فضای هارد محیط Host مون رو به درون Container ارتباط میدیم و اینکار برای منعطف کردن setting های برنامه مون مفید هستش.
به مثال خودمون بر میگردیم. من در فایل docker-compose بین فایل appsettings.json ی که در محیط پروژه خودم هست و همچنین فایل appsettings.json داخل کانتینر که فایل پابلیش شده پروژه هست , یک MountPoint ایجاد کردم و هر بار که فایل appsettings.json پروژه خودم رو آپدیت کنم, با ریستارت کردن کانتینر Setting جدید رو خواهم داشت. بدون این که کار دیگه ای رو انجام بدم.
در واقع فرمت به این صورت هستش. {Container}: {Host}
بعد از ساخت ایمیج جدید و اجرای اون, ما میتونیم با هربار عوض کردن setting خود پروژه و اجرای مجدد docker-compose up تنظیمات جدیدی رو داشته باشم.
