By default RavenDB allow anonymous access only for read requests (HTTP GET), and since we creating data, we need to specify a username and password. You can control this by changing the AnonymousAccess setting in the server configuration file. Enter your username and password of your Windows account and a sample data will be generated for you.
docker-compose چیست؟
فرض کنید برنامهی ما، از یک قسمت منطق خود برنامه و قسمت دیگر بانک اطلاعاتی آن تشکیل شدهاست. در این حالت برای توزیع آن توسط کانتینرها، نیاز به دو کانتینر مجزا خواهد بود؛ یکی برای برنامه و دیگری برای بانک اطلاعاتی:
dockerrun --name db` -d ` -p 3306:3306 ` -e MYSQL_ROOT_PASSWORD=my-secret-pw ` -v db:/var/lib/mysql` mysql dockerinspect db # extract ipaddress dockerrun --name web ` -d ` -p 8080:80 ` -e MY_DB_PORT=3306 ` -e MY_DB_HOST=? ` -v /my/php/app:/usr/share/nginx/html ` nginx
- دستور اول مطابق توضیحات قسمت قبل، یک بانک اطلاعاتی MySQL را در پس زمینه، با نام db که در آن، پورت 3306 میزبان به پورت 3306 کانتینر نگاشت شدهاست و همچنین بانک اطلاعاتی آن در یک volume نامدار به نام db با مسیر نگاشت شدهی به /var/lib/mysql/ داخل کانتینر ایجاد میشود، اجرا میکند.
- دستور دوم کار استخراج اطلاعات این کانتینر را انجام میدهد که شامل آدرس IP آن نیز میباشد. از این IP در برنامهی وب استفاده خواهیم کرد.
- دستور سوم مطابق توضیحات قسمت پنجم، یک وب سرور nginx را برای هاست یک برنامهی PHP که در آن پورت 8080 میزبان به پورت 80 کانتینر نگاشت شدهاست و همچنین فایلهای آن از مسیر /my/php/app/ میزبان به مسیر /usr/share/nginx/html/ داخل کانتینر نگاشت و تامین میشوند، اجرا میکند. در اینجا از پارامتر e برای تعریف یک سری متغیر محیطی مانند شمارهی پورت و IP کانتینر اجرا کنندهی mysql، استفاده شدهاست.
در این مثال دو کانتینر به هم وابسته را اجرا کردهایم و برای اجرای کانتینر دوم، نیاز است حداقل IP کانتینر اول را دانست و در قسمت MY_DB_HOST مقدار دهی کرد. روش دیگری نیز برای مدیریت سادهتر اجرای چندین کانتینر به هم وابسته توسط ابزاری به نام docker-compose وجود دارد. اگر از Dockerfile (که آنرا در قسمت پنجم معرفی کردیم) جهت ایجاد Imageهای سفارشی بکار میرود، فایل docker-compose.yml، کار خودکار سازی ایجاد و اجرای چندین کانتینر را انجام میدهد که با قالب YAML تعریف میشود:
version: '2' services: db: image: mysql ports: -3306:3306 environment: -MYSQL_ROOT_PASSWORD=my-secret-pw volumes: -db:/var/lib/mysql web: image: nginx ports: -8080:80 environment: -MY_DB_PORT=3306 -MY_DB_HOST=db volumes: -/my/php/app:/usr/share/nginx/html
در ابتدای این فایل، شماره نگارش قالب YAML مورد استفاده، مشخص شدهاست. در این نگارش، به کانتینرها، services گفته میشود که در اینجا دو سرویس db و web را مشاهده میکنید. در فایلهای yml، فضاهای خالی و indentations مهم هستند و بر این اساس است که کانتینرها و سپس مشخصات این کانتینرها، تمیز داده میشوند.
راه اندازی TeamCity به کمک فایل docker-compose.yml آن
در اینجا محتویات فایل docker-compose.yml مخصوص راه اندازی TeamCity را مشاهده میکنید که از سه کانتینر تشکیل شدهاست و از بانک اطلاعاتی postgres استفاده میکند:
version: '2' services: teamcity: image: sjoerdmulder/teamcity ports: - 8111:8111 teamcity-agent: image: sjoerdmulder/teamcity-agent environment: - TEAMCITY_SERVER=http://teamcity:8111 postgres: image: postgres environment: - POSTGRES_DB=teamcity
در ادامه برای کار با آن، ابتدا این محتویات را به صورت یک فایل متنی docker-compose.yml ذخیره کنید. سپس از طریق خط فرمان به پوشهی آن وارد شده و دستور docker-compose up را صادر کنید. docker-compose یکی دیگر از ابزارهای خط فرمان نصب شدهی به همراه داکر است و پارامتر up آن کار راه اندازی و اجرای کانتینرهای ذکر شدهی در فایل yml موجود را انجام میدهد. نام پوشهای که این فایل در آن قرار دارد، به عنوان نام پروژهی مشترک بین این کانتینرها در گزارشات آن مورد استفاده قرار میگیرد.
پس از صدور این فرمان، ابتدا تمام imageهای ذکر شدهی در فایل yml دریافت میشوند (سه image در اینجا) و هر سه کانتینر راه اندازی میشوند. اکنون میتوان در سیستم میزبان به آدرس http://localhost:8111 مراجعه کرد و از برنامهی teamcity استفاده نمود. البته صفحهی ابتدایی آن کار تنظیمات بانک اطلاعاتی آنرا انجام میدهد و جائیکه در مورد database type سؤال میپرسد میتوان postgres را انتخاب کرد و سپس در ذیل آن مقدار database host را نیز postgres وارد میکنیم. علت آنرا نیز پیشتر توضیح دادیم. postgres در اینجا نام کانتینر نیز هست و ذکر نام آن، با ذکر IP مرتبط با آن کانتینر، یکی است. نام بانک اطلاعاتی را teamcity وارد کنید (مطابق تنظیمات فایل yml فوق) و نام کاربری آن نیز postgres است؛ بدون کلمهی عبور. البته میشد در فایل yml فوق، متغیر محیطی POSTGRES_PASSWORD=xyz را نیز تنظیم کرد و سپس از آن در اینجا استفاده نمود.
docker-compose و ایجاد شبکههای ایزوله
توسط دستور docker network ls میتوان لیست شبکههای مجازی ایجاد شدهی توسط docker را مشاهده کرد (و همچنین سایر network adapters موجود). اگر این دستور را اجرا کنید، کارت شبکهی مجازی متناظر با شبکهی خصوصی teamcity_default را که پیشتر در مورد آن توضیح داده شد، میتوانید مشاهده کنید. این teamcity در اینجا همان نام پروژه و یا در اصل نام پوشهای است که فایل docker-compose را از آنجا اجرا کردیم.
برای دریافت اطلاعات بیشتری در مورد این کارت شبکهی به خصوص، میتوان دستور docker network inspect teamcity_default را صادر کرد. یکی از قسمتهای خروجی این گزارش، لیست کانتینرهایی است که هم اکنون به این شبکه متصل هستند؛ که در اینجا teamcity و بانک اطلاعاتی آن است.
مزیت ایجاد یک شبکهی خصوصی مخصوص کانتینرهای به هم پیوسته، علاوه بر سادگی تشکیل فایل docker-compose آنها با اشارهی به نام کانتینرها، بجای ذکر مستقیم آدرس IP هر کدام، ایزوله ساختن این شبکه، از شبکهی پیشفرض docker و بالا بردن میزان امنیت سایر کانتینرهایی است که هم اکنون از آن شبکه استفاده میکنند.
docker-compose و ایجاد DNS Server توکار
همانطور که عنوان شد، در این شبکهی خصوصی ویژهی کانتینرهای به هم پیوسته که توسط docker-compse اجرا و مدیریت شدهاند، میتوان از نام containerها بجای آدرس IP آنها استفاده کرد و این مورد با وجود یک DNS Server توکار در این شبکه میسر شدهاست. برای آزمایش بیشتر این قابلیت، ابتدا دستور docker ps را صادر میکنیم تا نام کانتینرهای در حال اجرا را بدست بیاوریم. سپس سعی میکنیم پروسهی bash shell داخل کانتینر بانک اطلاعاتی را اجرا کنیم:
docker ps docker exec -it teamcity_postgres_1 bash #exit
docker-compose exec postgres bash
پس از دسترسی به شل، دستور زیر را اجرا کنید:
#ping teamcity #exit
یک نکته: اگر بخواهیم از وضعیت بانکهای اطلاعاتی postgres توسط برنامهی psql آن گزارش بگیریم نیز روش اجرای آن به همین صورت است:
docker-compose exec postgres psql -U postgres postgres=#\l postgres=#\q
اتصال یک کانتینر خارج از شبکهی مجازی ایجاد شدهی توسط docker-compose به آن
فرض کنید میخواهید کانتینر کم حجم لینوکس alpine را اجرا کنید و توسط آن به شبکهی مجازی ایجاد شدهی توسط docker-compose متصل شوید. روش آن به صورت زیر است:
docker run --name apline -it --rm --net teamcity_default alpine sh
این دستور، کانتینر لینوکس alpine را در حالت interactive جهت اجرای shell آن، راه اندازی میکند. سپس به شبکهی مجازی teamcity_default متصل میشود. برای آزمایش این اتصال، در این shell راه اندازی شده، دستور ping teamcity را میتوان صادر کرد. همچنین از داخل کانتینر teamcity نیز میتوان این کانتینر را با نام آن ping کرد.
راه اندازی مجدد کانتینرها توسط docker-compose
اگر دستور docker-compose ps را دقیقا در پوشهای که فایل yml آن قرار دارد اجرا کنیم، میتوان گزارشی را صرفا از وضعیت کانتینرهای مرتبط با این فایل yml بدست آورد. دستور docker ps، لیست وضعیت تمام کانتینرهای در حال اجرای موجود را بر میگرداند. اکنون فرض کنید یکی از کانتینرهای اجرای شدهی توسط docker-compose، دیگر در حال اجرا نیست. برای راه اندازی مجدد آن میتوان از دستور docker-compose start teamcity-agent استفاده کرد. همچنین دستور docker-compose logs teamcity-agent، لیست آخرین لاگهای مرتبط با یک کانتینر را بر میگرداند که میتواند برای رفع اشکال بسیار مفید باشد.
حذف کانتینرهای به هم پیوستهی ایجاد شدهی توسط docker-compose
در ذیل ابتدا یک سری دستور را جهت مشاهدهی وضعیت سیستم مشاهده میکنید. سپس دستور docker-compose stop، کار متوقف کردن کانتینرهای مرتبط با فایل yml آنرا انجام میدهد. دستور docker-compose rm -v، علاوه بر حذف این کانتینرها، volumeهای بانکهای اطلاعاتی مرتبط را نیز حذف میکند. در آخر دستور docker-compose down، شبکهی مجازی مرتبط را نیز حذف خواهد کرد. سپس مجددا از وضعیت سیستم گزارش گیری شدهاست.
docker ps docker-compose ps docker volume ls docker network ls docker-compose stop docker-compose rm -v docker-compose down docker ps -a docker volume ls docker network ls
اجرای پروژهی ASP.NET Core Music Store توسط docker-compose
پروژهی معروف Music Store مایکروسافت را به همراه فایل docker-compose.windows.yml آن، در اینجا میتوانید مشاهده کنید. محتوای این فایل نیز به صورت زیر است:
version: '3' services: db: image: microsoft/mssql-server-windows-developer environment: sa_password: "Password1" ACCEPT_EULA: "Y" ports: - "1433:1433" # REMARK: This is currently required, needs investigation healthcheck: test: [ "CMD", "sqlcmd", "-U", "sa", "-P", "Password1", "-Q", "select 1" ] interval: 1s retries: 30 web: build: context: . dockerfile: Dockerfile.windows environment: - "Data:DefaultConnection:ConnectionString=Server=db,1433;Database=MusicStore;User Id=sa;Password=Password1;MultipleActiveResultSets=True" depends_on: - db ports: - "5000:5000"
- کانتینر db که بر اساس image مخصوص mssql-server-windows-developer راه اندازی میشود. تنظیمات آن نیز بسیار شبیه به مطلب «کار با Docker بر روی ویندوز - قسمت ششم - کار با بانکهای اطلاعاتی درون Containerها» است که پیشتر در مورد آن بحث کردیم.
- کانتینر web آن که از فایل Dockerfile.windows برای build سپس publish و در آخر run خودکار این برنامهی ASP.NET Core، کمک میگیرد. در اینجا context به پوشهی جاری اشاره میکند. در قسمت تنظیمات بانک اطلاعاتی آن، استفادهی از نام کانتینر db را در قسمت رشتهی اتصالی مشاهده میکنید. قسمت depends_on آن ترتیب اجرای این کانتینرها را مشخص میکند. یعنی ابتدا باید کانتینر db اجرا شود و سپس web.
محتوای فایل Dockerfile.windows آن نیز به صورت زیر است که بر اساس دستورات NET Core CLI. تهیه شدهاست:
FROM microsoft/dotnet-nightly:2.0-sdk-nanoserver SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"] ENV NUGET_XMLDOC_MODE skip ENV DOTNET_SKIP_FIRST_TIME_EXPERIENCE 1 RUN New-Item -Path \MusicStore\samples\MusicStore -Type Directory WORKDIR app ADD samples/MusicStore/MusicStore.csproj samples/MusicStore/MusicStore.csproj ADD build/dependencies.props build/dependencies.props ADD NuGet.config . RUN dotnet restore --runtime win10-x64 .\samples\MusicStore ADD samples samples RUN dotnet publish --output /out --configuration Release --framework netcoreapp2.0 --runtime win10-x64 .\samples\MusicStore FROM microsoft/dotnet-nightly:2.0-runtime-nanoserver WORKDIR /app COPY --from=0 /out . EXPOSE 5000 ENV ASPNETCORE_URLS http://0.0.0.0:5000 CMD dotnet musicstore.dll
docker-compose -f .\docker-compose.windows.yml build docker-compose -f .\docker-compose.windows.yml up
Docker for Windows چگونه از هر دوی کانتینرهای ویندوزی و لینوکسی پشتیبانی میکند؟
زمانیکه docker for windows را اجرا میکنیم، سرویسی را ایجاد میکند که سبب اجرای پروسهی ویژهای به نام com.docker.proxy.exe میشود:
هنگامیکه برای مثال فرمان docker run nginx را توسط Docker CLI اجرا میکنیم، Docker CLI از طریق واسط یاد شده، دستورات را به MobyLinuxVM منتقل میکند. به این صورت است که امکان اجرای Linux Containers، بر روی ویندوز میسر میشوند:
اکنون اگر به Windows Containers سوئیچ کنیم (از طریق کلیک راست بر روی آیکن Docker در قسمت Tray Icons ویندوز)، پروسهی dockerd.exe یا docker daemon شروع به کار خواهد کرد:
اینبار اگر مجددا از Docker CLI برای اجرای مثلا IIS Container استفاده کنیم، دستور ما از طریق واسطهای com.docker.proxy و dockerd، به کانتینر ویندوزی منتقل و اجرا میشود:
نگاهی به معماری Docker بر روی ویندوز سرور
داکر بر روی ویندوز سرور، تنها به همراه موتور مدیریت کنندهی Windows Containers است:
در اینجا با صدور فرمانهای Docker CLI، پیامها مستقیما به dockerd یا موتور داکر بر روی ویندوز سرور ارسال شده و سپس کار اجرا و مدیریت یک Windows Container انجام میشود.
نصب Docker بر روی ویندوز سرور
جزئیات مفصل و به روز Windows Containers را همواره میتوانید در این آدرس در سایت مستندات مجازی سازی مایکروسافت مطالعه کنید (قسمت Container Host Deployment - Windows Server آن). پیشنیاز کار با آن نیز نصب حداقل ویندوز سرور 2016 میباشد و بهتر است تمام به روز رسانیهای آنرا نیز نصب کرده باشید؛ چون تعدادی از بهبودهای کار با کانتینرهای آن، به همراه به روز رسانیها آن ارائه شدهاند.
برای شروع به نصب، نیاز است کنسول PowerShell ویندوز را با دسترسی Admin اجرا کنید.
سپس اولین دستوراتی را که نیاز است اجرا کنید، کار نصب موتور Docker و CLI آنرا به صورت خودکار بر روی ویندوز سرور انجام میدهند:
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force Install-Package -Name docker -ProviderName DockerMsftProvider Restart-Computer -Force
- به علاوه اگر دستور *get-service *docker را در کنسول PowerShell صادر کنید، مشاهده خواهید کرد که سرویس جدیدی را به نام Docker نیز نصب و راه اندازی کردهاست که به dockerd.exe اشاره میکند.
- و یا اگر در کنسول PowerShell دستور docker را صادر کنید، ملاحظه خواهید کرد که CLI آن، فعال و قابل استفادهاست. برای مثال، دستور docker version را صادر کنید تا بتوانید نگارش docker نصب شده را ملاحظه نمائید.
اجرای Image مخصوص NET Core. بر روی ویندوز سرور
تگهای مختلف Image مخصوص NET Core. را در اینجا ملاحظه میکنید. در ادامه قصد داریم tag مرتبط با nanoserver آنرا نصب کنیم (با حجم 802MB):
docker run microsoft/dotnet:nanoserver
docker run -it microsoft/dotnet:nanoserver
چرا حجم Image مخصوص NET Core. نگارش nanoserver آن حدود 800 مگابایت است؟
در مثال قبلی، دسترسی به command prompt مجزایی نسبت به command prompt اصلی سیستم، در داخل یک container، شاید اندکی غیر منتظره بود و اکنون این سؤال مطرح میشود که یک image، شامل چه چیزهایی است؟
یک image شاید در ابتدای کار صرفا شامل فایلهای اجرایی یک برنامهی خاص به نظر برسد؛ اما زمانیکه قرار است تبدیل به یک container قابل اجرا شود، شامل بسیاری از فایلهای دیگر نیز خواهد شد. برای درک این موضوع نیاز است لایههای نرم افزاری که یک سیستم را تشکیل میدهند، بررسی کنیم:
در این تصویر از پایینترین لایهای را که با سخت افزار ارتباط برقرار میکند تا بالاترین لایهی موجود نرم افزاری را مشاهده میکنید. دراینجا هر چیزی را که در ناحیهی کرنل قرار نمیگیرد، User Space مینامند. برنامههای قرار گرفتهی در User Space برای کار با سخت افزار نیاز است با کرنل ارتباط برقرار کنند و برای این منظور از System Calls استفاده میکنند که عموما کتابخانههایی هستند که جزئی از سیستم عامل میباشند؛ مانند API ویندوز. برای مثال MongoDB توسط Win32 API و System Calls، فرامینی را به کرنل منتقل میکند.
در روش متداول توزیع و نصب نرم افزار، ما عموما همان بالاترین سطح را توزیع و نصب میکنیم؛ برای مثال خود MongoDB را. در اینجا نصاب MongoDB فرض میکند که در سیستم جاری، تمام لایههای دیگر، موجود و آمادهی استفاده هستند و اگر اینگونه نباشد، به مشکل برخواهد خورد و اجرا نمیشود. برای اجتناب از یک چنین مشکلاتی مانند عدم حضور وابستگیهایی که یک برنامه برای اجرا نیاز دارد، imageهای docker، نحوهی توزیع نرم افزارها را تغییر دادهاند. اینبار یک image بجای توزیع فقط MongoDB، شامل تمام قسمتهای مورد نیاز User Space نیز هست:
به این ترتیب دیگر مشکلاتی مانند عدم وجود یک وابستگی یا حتی وجود یک وابستگی غیرسازگار با نرم افزار مدنظر، وجود نخواهند داشت. حتی میتوان تصویر فوق را به صورت زیر نیز خلاصه کرد:
به همین جهت بود که برای مثال در قسمت قبل موفق شدیم IIS مخصوص ویندوز سرور با تگ nanoserver را بر روی ویندوز 10 که بسیاری از وابستگیهای مرتبط را به همراه ندارد، با موفقیت اجرا کنیم.
به علاوه چون یک container صرفا به معنای یک running process از یک image است، هر فایل اجرایی داخل آن image را نیز میتوان به صورت یک container اجرا کرد؛ مانند cmd.exe داخل image مرتبط با NET Core. که آنرا بررسی کردیم.
کارآیی Docker Containers نسبت به ماشینهای مجازی بسیار بیشتر است
مزیت دیگر یک چنین توزیعی این است که اگر چندین container در حال اجرا را داشته باشیم:
در نهایت تمام آنها فقط با یک لایهی کرنل کار میکنند و آن هم کرنل اصلی سیستم جاری است. به همین جهت کارآیی docker containers نسبت به ماشینهای مجازی بیشتر است؛ چون هر ماشین مجازی، کرنل مجازی خاص خودش را نسبت به یک ماشین مجازی در حال اجرای دیگر دارد. در اینجا برای ایجاد یک لایه ایزولهی اجرای برنامهها، تنها کافی است یک container جدید را اجرا کنیم و در این حالت وارد فاز بوت شدن یک سیستم عامل کامل، مانند ماشینهای مجازی نمیشویم.
شاید مطابق تصویر فوق اینطور به نظر برسد که هرچند تمام این containers از یک کرنل استفاده میکنند، اما اگر قرار باشد هر کدام OS Apps & Libs خاص خودشان را در حافظه بارگذاری کنند، با کمبود شدید منابع روبرو شویم. دقیقا مانند حالتیکه چند ماشین مجازی را اجرا کردهایم و دیگر سیستم اصلی قادر به پاسخگویی به درخواستهای رسیده به علت کمبود منابع نیست. اما در واقعیت، یک image داکر، از لایههای مختلفی تشکیل میشود که فقط خواندنی هستند و غیرقابل تغییر و زمانیکه docker یک لایهی فقط خواندنی را در حافظه بارگذاری کرد، اگر container دیگری، از همان لایهی تعریف شده، در image خود نیز استفاده میکند، لایهی بارگذاری شدهی فقط خواندنی در حال اجرای موجود را با آن به اشتراک میگذارد (مانند تصویر زیر). به این ترتیب میزان مصرف منابع docker containers نسبت به ماشینهای مجازی بسیار کمتر است:
روش کنترل پروسهای که درون یک کانتینر اجرا میشود
با اجرای دستور docker run -it microsoft/dotnet:nanoserver ابتدا به command prompt داخلی و مخصوص این container منتقل میشویم و سپس میتوان برای مثال با NET Core CLI. کار کرد. اما امکان اجرای این CLI به صورت زیر نیز وجود دارد:
docker run -it microsoft/dotnet:nanoserver dotnet --info
بدیهی است در این حالت تمام فایلهای اجرایی داخل این container را نیز میتوان اجرا کرد. برای مثال میتوان کنسول پاورشل داخل این container را اجرا کرد:
docker run -it microsoft/dotnet:nanoserver powershell
هر کانتینر دارای یک File System ایزولهی خاص خود است
تا اینجا دریافتیم که هر image، به همراه فایلهای user space مورد نیاز خود نیز میباشد. به عبارتی هر image یک file system را نیز ارائه میدهد که تنها درون همان container قابل دسترسی میباشد و از مابقی سیستم جاری ایزوله شدهاست.
برای آزمایش آن، کنسول پاورشل را در سیستم میزبان (سیستم عامل اصلی که docker را اجرا میکند)، باز کرده و دستور \:ls c را صادر کنید. به این ترتیب میتوانید لیست پوشهها و فایلهای موجود در درایو C میزبان را مشاهده نمائید. سپس دستور docker run -it microsoft/dotnet:nanoserver powershell را اجرا کنید تا به powershell داخل کانتینر NET Core. دسترسی پیدا کنیم. اکنون دستور \:ls c را مجددا اجرا کنید. خروجی آن کاملا متفاوت است نسبت به گزارشی که پیشتر بر روی سیستم میزبان تهیه کردیم؛ دقیقا مانند اینکه هارد درایو یک container متفاوت است با هارد درایو سیستم میزبان.
این تصویر زمانی تهیه شدهاست که دستور docker run یاد شده را صادر کردهایم و درون powershell آن قرار داریم. همانطور که مشاهده میکنید یک Disk جدید، به ازای این Container در حال اجرا، به سیستم میزبان اضافه شدهاست. این Disk زمانیکه در powershell داخل container، دستور exit را صادر کنیم، بلافاصله محو میشود. چون پروسهی container، به این ترتیب خاتمه یافتهاست.
اگر دستور docker run یاد شده را دو بار اجرا کنیم، دو Disk جدید ظاهر خواهند شد:
یک نکته: اگر بر روی این درایوهای مجازی کلیک راست کرده، گزینهی change drive letter or path را انتخاب نموده و یک drive letter را به آنها نسبت دهید، میتوانید محتویات داخل آنها را توسط Windows Explorer ویندوز میزبان نیز به صورت یک درایو جدید، مشاهده کنید.
خلاصهای از ایزوله سازیهای کانتینرها تا به اینجا
تا اینجا یک چنین ایزوله سازیهایی را بررسی کردیم:
- ایزوله سازی File System و وجود یک disk مجازی مجزا به ازای هر کانتینر در حال اجرا.
- پروسههای کانتینرها از پروسههای میزبان ایزوله هستند. برای مثال اگر دستور get-process را داخل یک container اجرا کنید، خروجی آن با خروجی اجرای این دستور بر روی سیستم میزبان یکی نیست. یعنی نمیتوان از داخل کانتینرها، به پروسههای میزبان دسترسی داشت و دخل و تصرفی را در آنها انجام داد که از لحاظ امنیتی بسیار مفید است. هر چند اگر به task manager ویندوز میزبان مراجعه کنید، میتوان پروسههای داخل یک container را توسط Job Object ID یکسان آنها تشخیص دهید (مثال آخر قسمت قبل)، اما یک container، قابلیت شمارش پروسههای خارج از مرز خود را ندارد.
- ایزوله سازی شبکه مانند کارت شبکهی مجازی کانتینر IIS که در قسمت قبل بررسی کردیم. برای آزمایش آن دستور ipconfig را در داخل container و سپس در سیستم میزبان اجرا کنید. نتیجهای را که مشاهده خواهید کرد، کاملا متفاوت است. یعنی network stack این دو کاملا از هم مجزا است. شبیه به اینکه به یک سیستم، چندین کارت شبکه را متصل کرده باشید. اینکار در اینجا با تعریف virtual network adaptors انجام میشود و لیست آنها را در قسمت «All Control Panel Items\Network Connections» سیستم میزبان میتوانید مشاهده کنید. یکی از مهمترین مزایای آن این است که اگر در یک container، وب سروری را بر روی پورت 80 آن اجرا کنید، مهم نیست که در سیستم میزبان، یک IIS در حال سرویس دهی بر روی پورت 80 هم اکنون موجود است. این دو پورت با هم تداخل نمیکنند.
- در حالت کار با Windows Containers، رجیستری کانتینر نیز از میزبان آن مجزا است و یا متغیرهای محیطی اینها یکی نیست. برای مثال دستور \:ls env را در کانتینر و سیستم میزبان اجرا کنید تا environment variables را گزارش گیری کنید. خروجی این دو کاملا متفاوت است. برای مثال حداقل computer name، user nameهای قابل مشاهدهی در این گزارشها، متفاوت است و یا دستور \:ls hkcu را در هر دو اجرا کنید تا خروجی رجیستری متعلق به کاربر جاری هر کدام را مشاهده کنید که در هر دو متفاوت است.
- در حالت کار با Linux Containers هر چیزی که ذیل عنوان namespace مطرح میشود مانند شبکه، PID، User، UTS، Mount و غیره شامل ایزوله سازی میشوند.
دو نوع Windows Containers وجود دارند
در ویندوز، Windows Server Containers و Hyper-V Containers وجود دارند. در این قسمت تمام کارهایی را که بر روی ویندوز سرور انجام دادیم، در حقیقت بر روی Windows Server Containers انجام شدند و تمام Containerهای ویندوزی را که در قسمت قبل بر روی ویندوز 10 ایجاد کردیم، از نوع Hyper-V Containers بودند.
تفاوت مهم اینها در مورد نحوهی پیاده سازی ایزوله سازی آنها است. در حالت Windows Server Containers، کار ایزوله سازی پروسهها توسط کرنل اشتراکی بین کانتینرها صورت میگیرد اما در Hyper-V Containers، این ایزوله سازی توسط hypervisor آن انجام میشود؛ هرچند نسبت به ماشینهای مجازی متداول بسیار سریعتر است، اما بحث به اشتراک گذاری کرنل هاست را که پیشتر در این قسمت بررسی کردیم، در این حالت شاهد نخواهیم بود. ویندوز سرور 2016 میتواند هر دوی این ایزوله سازیها را پشتیبانی کند، اما ویندوز 10، فقط نوع Hyper-V را پشتیبانی میکند.
روش اجرای Hyper-V Containers بر روی ویندوز سرور
در صورت نیاز برای کار با Hyper-V Containers، نیاز است مانند قسمت قبل، ابتدا Hyper-V را بر روی ویندوز سرور، فعالسازی کرد:
Install-WindowsFeature hyper-v Restart-Computer -Force
docker run -it --isolation=hyperv microsoft/dotnet:nanoserver powershell
Windows
OS | Version | Architectures | Notes |
---|---|---|---|
Windows Client | 7 SP1+, 8.1 | x64, x86 | |
Windows 10 Client | Version 1607+ | x64, x86 | |
Nano Server | Version 1803+ | x64, ARM32 | |
Windows Server | 2012 R2+ | x64, x86 | |
See the Windows Lifecycle Fact Sheet for details regarding each Windows release lifecycle.
در نگارشهای قبلی، پس از اجرای برنامه، صرفا یک سطر زیر نمایش داده میشد:
Now listening on: http://localhost:5000
Now listening on: https://localhost:5001 Now listening on: http://localhost:5000
علت هدایت خودکار به آدرس HTTPS، به تغییرات فایل آغازین برنامه بر میگردد:
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); } else { app.UseExceptionHandler("/Home/Error"); app.UseHsts(); } app.UseHttpsRedirection();
اگر خواستید این شمارهی پورت را تغییر دهید، میتوانید به صورت زیر عمل کنید:
services.AddHttpsRedirection(options => options.HttpsPort = 5002);
services.AddHsts(options => { options.MaxAge = TimeSpan.FromDays(100); options.IncludeSubDomains = true; options.Preload = true; });
اما چرا برنامه در حالت HTTPS قابل مشاهده نیست؟
پس از نصب SDK نگارش جدید NET Core.، یک مجوز SSL توسعه نیز به سیستم عامل اضافه میشود:
ASP.NET Core ------------ Successfully installed the ASP.NET Core HTTPS Development Certificate.
برای مشاهدهی این مجوز، دستور certmgr.msc را در قسمت run ویندوز وارد کرده و enter کنید:
این مجوز پیش فرض در قسمت «Personal/Certificates» با نام «ASP.NET Core HTTPS development certificate» قابل مشاهدهاست که در حقیقت یک Self Signed Certificate است و به صورت پیش فرض توسط سیستم معتبر و قابل اطمینان شناخته نمیشود.
برای اعلام قابل اطمینان بودن این مجوز به سیستم، در همین کنسول مدیریت مجوزها، بر روی این مجوز کلیک راست کرده و آنرا کپی کنید. سپس آنرا در مسیر «Trusted Root Certification Authorities/Certificates» قرار دهید (paste کنید).
در این حالت صفحه دیالوگ فوق ظاهر میشود. آنرا تائید کنید تا این مجوز توسعه، به قسمت مجوزهای امن و معتبر سیستم اضافه شود.
روش دوم انجام اینکار، استفاده از دستور زیر است:
dotnet install tool dotnet-dev-certs -g --version 2.1.0-preview1-final dotnet dev-certs https --trust
پس از اینکار اگر مرورگر را ریفرش کنید، باز هم همان خطای قبلی نمایش داده میشود. برای رفع این مشکل باید یکبار مرورگر را کاملا بسته و مجددا اجرا کنید تا مجوز جدید را دریافت کند:
تنظیمات مخصوص IIS Express برای اجرای برنامههای ASP.NET Core 2.1
دستور «dotnet run» از IIS برای اجرا استفاده نمیکند و مبتنی بر وب سرور Kestrel است. تنظیمات IIS و IIS Express از فایل Properties\launchSettings.json خوانده میشوند که اینبار به صورت زیر تغییر کردهاست:
{ "iisSettings": { "windowsAuthentication": false, "anonymousAuthentication": true, "iisExpress": { "applicationUrl": "http://localhost:4929", "sslPort": 44313 } }, "profiles": { "IIS Express": { "commandName": "IISExpress", "launchBrowser": true, "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development", "ASPNETCORE_HTTPS_PORT": "44313" } }, "TestWebApp": { "commandName": "Project", "launchBrowser": true, "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development", "ASPNETCORE_URLS": "https://localhost:5001;http://localhost:5000" } } } }
Today Doug Mahugh, Senior Technical Evangelist for Microsoft Open Technologies Inc., announced the release of an Open XML SDK as an open source project through the MS Open Tech hub. Although the SDK has been available since 2007, this release includes full source code available under the Apache 2.0 license on GitHub, as well as the project will continue to grow under the stewardship of the .NET Foundation
jQuery 3.6.0 منتشر شد
jQuery 3.6.0 has been released! In jQuery 3.5.0, the major change was a security fix for the html prefilter. This release does not include a security fix, but does have some good bug fixes and improvements. We still have our eyes on a jQuery 4.0 release, but until then we will continue to support the 3.x branch and address important issues.
The current process creates friction for users. Finding an OTP within an SMS message, then copying and pasting it to the form is cumbersome, lowering conversion rates in critical user journeys. Easing this has been a long standing request for the web from many of the largest global developers. Android has an API that does exactly this. So does iOS and Safari