تعدادی رکورد RoleClaim در بانک اطلاعاتی موجود هستند. لیست جدیدی از طرف کاربر ارسال شدهاست. بررسی میشود که از این لیست کاربر، چه تعدادی در لیست موجود در بانک اطلاعاتی، وجود ندارند؛ بنابراین باید به صورت رکورد جدید ثبت شوند. سپس بررسی میشود از این لیست کاربر، چه تعداد رکورد بانک اطلاعاتی موجود، دیگر انتخاب نشدهاند و باید حذف شوند.
تا اینجا نحوهی اجرای برنامهها، وب سرورها و حتی بانکهای اطلاعاتی را توسط داکر بررسی کردیم. در این قسمت میخواهیم یک برنامه و بانک اطلاعاتی مخصوص آنرا داخل یک کانتینر اجرا کنیم و برای این منظور از ابزار ساده کنندهی docker-compose استفاده خواهیم کرد.
docker-compose چیست؟
فرض کنید برنامهی ما، از یک قسمت منطق خود برنامه و قسمت دیگر بانک اطلاعاتی آن تشکیل شدهاست. در این حالت برای توزیع آن توسط کانتینرها، نیاز به دو کانتینر مجزا خواهد بود؛ یکی برای برنامه و دیگری برای بانک اطلاعاتی:
تمام این دستورات را به همراه یک ` نیز مشاهده میکنید. این روشی است که از آن برای چندسطری کردن دستورات در PowerShell استفاده میشود.
- دستور اول مطابق توضیحات قسمت قبل، یک بانک اطلاعاتی 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 تعریف میشود:
همانطور که مشاهده میکنید، هرچند قالب آن اندکی متفاوت شدهاست، اما در اصل با دستورات docker ای که در ابتدا معرفی کردیم، تفاوتی ندارد. محتوای فوق را در یک فایل متنی ویژه به نام docker-compose.yml ذخیره و آنرا به ابزار خط فرمان دیگری به نام docker-compose معرفی میکنیم.
در ابتدای این فایل، شماره نگارش قالب YAML مورد استفاده، مشخص شدهاست. در این نگارش، به کانتینرها، services گفته میشود که در اینجا دو سرویس db و web را مشاهده میکنید. در فایلهای yml، فضاهای خالی و indentations مهم هستند و بر این اساس است که کانتینرها و سپس مشخصات این کانتینرها، تمیز داده میشوند.
راه اندازی TeamCity به کمک فایل docker-compose.yml آن
در اینجا محتویات فایل docker-compose.yml مخصوص راه اندازی TeamCity را مشاهده میکنید که از سه کانتینر تشکیل شدهاست و از بانک اطلاعاتی postgres استفاده میکند:
در این تنظیمات، پورت 8111 میزبان به پورت 8111 کانتینر teamcity نگاشت شدهاست. در ادامه teamcity-agent نیاز به IP این کانتینر را دارد (یک build-server است). زمانیکه چندین کانتینر را توسط فایل docker-compose.yml راه اندازی میکنیم، داکر یک شبکهی ایزوله (private network) را نیز برای اینکار مهیا میکند. داخل این شبکهی ایزوله، یک DNS سرور توکار نیز وجود دارد که امکان دسترسی به کانتینرهای مختلف را از طریق نام کانتینرهای آنها میسر میکند. به همین جهت است که مقدار TEAMCITY_SERVER، به http://teamcity:8111 تنظیم شدهاست و دقیقا از نام کانتینر teamcity برای یافتن IP آن استفاده میکند. همچنین باید دقت داشت در این آدرس، عدد 8111 به پورت داخل کانتینر teamcity اشاره میکند و نه به پورت میزبان. کانتینرها از طریق آدرس IP و پورت خودشان با هم در تماس هستند. پورت میزبان 8111، صرفا جهت فراخوانی 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 exec یک روش است برای دسترسی به shell این کانتینر در حال اجرا؛ روش دیگر، استفاده از خود docker-compse میباشد که در این حالت، کار با آن سادهتر است:
در اینجا نیازی به ذکر سوئیچ it نیست؛ چون مقدار پیشفرض آن است و همچنین دیگر نیازی به اجرای docker ps برای یافتن نام کانتینری هم نیست و مستقیما میتوان از نامهای سرویسهایی که در فایل docker-compose.yml تعریف شدهاند، استفاده کرد.
پس از دسترسی به شل، دستور زیر را اجرا کنید:
مشاهده خواهید کرد که این کانتینر میتواند کانتینر دیگری را صرفا با ذکر نام آن، ping کند.
یک نکته: اگر بخواهیم از وضعیت بانکهای اطلاعاتی postgres توسط برنامهی psql آن گزارش بگیریم نیز روش اجرای آن به همین صورت است:
اتصال یک کانتینر خارج از شبکهی مجازی ایجاد شدهی توسط docker-compose به آن
فرض کنید میخواهید کانتینر کم حجم لینوکس alpine را اجرا کنید و توسط آن به شبکهی مجازی ایجاد شدهی توسط docker-compose متصل شوید. روش آن به صورت زیر است:
در اینجا توسط سوئیچ net، میتوان نام شبکهی مجازی را که نیاز است به آن متصل شویم، ذکر کرد. نام teamcity_default نیز از طریق اجرای دستور docker netwrok ls بدست آمدهاست.
این دستور، کانتینر لینوکس 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، شبکهی مجازی مرتبط را نیز حذف خواهد کرد. سپس مجددا از وضعیت سیستم گزارش گیری شدهاست.
اجرای پروژهی ASP.NET Core Music Store توسط docker-compose
پروژهی معروف Music Store مایکروسافت را به همراه فایل docker-compose.windows.yml آن، در اینجا میتوانید مشاهده کنید. محتوای این فایل نیز به صورت زیر است:
در اینجا تعریف دو کانتینر را مشاهده میکنید:
- کانتینر 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. تهیه شدهاست:
روش اجرای آنرا نیز به صورت زیر بیان کردهاست:
البته باید دقت داشت که اجرای فرمان up، به صورت خودکار کار build را هم انجام میدهد. پس از اجرای آن، برنامه را بر روی پورت 5000 میتوانید مشاهده کنید.
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
در قسمت قبل، ساختار ابتدایی یک پروژهی Minimal API's مبتنی بر معماری Vertical slices را تشکیل دادیم. در ادامه موجودیتها و DbContext آنرا تشکیل میدهیم.
ایجاد مدلها و موجودیتهای برنامهی Minimal Blog
در مثال این سری، هر نویسنده میتواند بلاگ خاص خودش را داشته باشد و در هر بلاگ، تعدادی مقاله منتشر کند. هر مقاله هم میتواند تعدادی تگ یا گروه مرتبط را داشته باشد.
ساختار ابتدایی موجودیت نویسندگان مطالب بلاگ
این موجودیتها در پوشهی جدیدی به نام Model پروژهی MinimalBlog.Domain اضافه خواهند شد:
در اینجا تعاریفی مانند !default را هم مشاهده میکنید که مرتبط است با فعال بودن nullable reference types در این پروژه که در فایل Directory.Build.props به صورت سراسری به تمام پروژهها اعمال میشود. با تعریف !default به کامپایلر اعلام میکنیم که این خواص هیچگاه نال نخواهند بود. هدف اصلی از nullable reference types، بالا بردن قابلیت پیش بینی نال بودن، یا نبودن آنها است؛ تا برنامه نویس در قسمتهای مختلف برنامه بداند که آیا واقعال نیاز است هنگام کار با خاصیت FirstName، نال بودن آنرا پیش از استفاده بررسی کند یا خیر؟
ساختار ابتدایی موجودیت مقالات بلاگ
ساختار ابتدایی بلاگهای اختصاصی قابل تعریف
ساختار ابتدایی گروههای مقالات بلاگ
معرفی موجودیتهای تعریف شده به لایهی Dal
لایهی Dal جایی است که DbContext برنامه تعریف میشود و موجودیتها فوق توسط DbSetها در معرض دید EF-Core قرار میگیرند. به همین جهت ابتدا فایل MinimalBlog.Dal.csproj را به صورت زیر تغییر میدهیم:
در اینجا در ابتدا ارجاعی به پروژهی MinimalBlog.Domain.csproj اضافه شدهاست. سپس بستههای مورد نیاز از EF-Core نیز جهت تعریف DbSetها و اجرای Migrations، اضافه شدهاند.
به علاوه تعاریفی مانند ImplicitUsings و Nullable را هم مشاهده میکنید که با توجه به استفادهی از فایل Directory.Build.props غیرضروری و تکراری هستند؛ چون این فایل مخصوص به همراه این تعاریف سراسری نیز هست.
سپس به پروژهی Dal، کلاس جدید MinimalBlogDbContext را به صورت زیر اضافه میکنیم تا مدلهای برنامه را در معرض دید EF-Core قرار دهد:
در اینجا نیز تعاریف !default را مشاهده میکنید که خاصیت راهنمای کامپایلر را در حالت فعال بودن <Nullable>enable</Nullable> دارند و هدف از آن، اعلام نال نبودن این خواص، در حین استفادهی از آنها در قسمتهای مختلف برنامه است.
ایجاد و اجرای Migrations
پس از تعریف MinimalBlogDbContext، اکنون نوبت به ایجاد کلاسهای Migrations و اجرای آنها جهت ایجاد بانک اطلاعاتی متناظر با مدلهای برنامه است. برای این منظور در ابتدا به پروژهی Api مراجعه کرده و فایل appsettings.json را به صورت زیر تکمیل میکنیم:
در اینجا یک رشتهی اتصالی جدید را از نوع SQL Server LocalDB، تعریف کردهایم. سپس نیاز است تا این رشتهی اتصالی را به پروایدر SQL Server مخصوص EF-Core اضافه کنیم. برای اینکار ابتدا باید تغییرات زیر را به فایل MinimalBlog.Api.csproj اعمال کنیم:
که در آن ارجاعاتی به پروژههای Domain و Dal اضافه شدهاست و همچنین بستههای نیوگت EF-Core نیز افزوده شدهاند تا بتوان در فایل Program.cs، تنظیم زیر را اضافه کرد:
در اینجا با استفاده از متد الحاقی AddDbContext، کلاس Context برنامه به مجموعهی سرویسهای آن اضافه شده و همچنین رشتهی اتصالی با کلید Default هم از تنظیمات برنامه، دریافت و به متد UseSqlServer جهت استفاده ارسال شدهاست.
پس از این تنظیمات به پوشهی MinimalBlog.Dal وارد شده و فایل _01-add_migrations.cmd را اجرا میکنیم (این فایل به همراه پیوست قسمت اول، ارائه شدهاست). محتوای این فایل به صورت زیر است:
ابتدا، آخرین نگارش ابزار dotnet-ef را نصب کرده و سپس یکبار هم پروژه را build میکند تا اگر مشکلی باشد، در همینجا با اطلاعات بیشتری نمایش داده شود. سپس با اجرای دستور dotnet ef migrations، کلاسهای Migrations در پوشهای به همین نام تشکیل میشوند.
البته چون کدهای تولید شدهی به صورت خودکار الزاما با Roslyn analyzers برنامه سازگاری ندارند، آنها را توسط فایل مخصوص editorconfig. قرار گرفتهی در پوشهی MinimalBlog.Dal\Migrations، از لیست آنالیزهای برنامه خارج میکنیم. محتوای این فایل ویژه به صورت زیر است:
که سبب خواهد شد تا این پوشهی ویژه به عنوان کدهای به صورت خودکار تولید شده تشخیص داده شود و دیگر آنالیز نشود؛ چون کیفیت آن، مشکل ما نیست!
پس از ایجاد کلاسهای Migration، اکنون نوبت به اجرای آنها بر روی بانک اطلاعاتی است که در رشتهی اتصالی مشخص کردیم. برای اینکار فایل MinimalBlog.Dal\_02-update_db.cmd را اجرا میکنیم که چنین محتویاتی دارد:
در اینجا نیز ابتدا از نصب آخرین نگارش ابزارهای EF اطمینان حاصل میشود. یکبار دیگر نیز پروژه بر اساس فایلهای جدیدی که به آن اضافه شده، کامپایل شده و سپس کلاسهای مهاجرتها، اجرا و اعمال میشوند.
ایجاد مدلها و موجودیتهای برنامهی Minimal Blog
در مثال این سری، هر نویسنده میتواند بلاگ خاص خودش را داشته باشد و در هر بلاگ، تعدادی مقاله منتشر کند. هر مقاله هم میتواند تعدادی تگ یا گروه مرتبط را داشته باشد.
ساختار ابتدایی موجودیت نویسندگان مطالب بلاگ
این موجودیتها در پوشهی جدیدی به نام Model پروژهی MinimalBlog.Domain اضافه خواهند شد:
namespace MinimalBlog.Domain.Model; public class Author { public int Id { get; set; } public string FirstName { get; set; } = default!; public string LastName { get; set; } = default!; public string FullName => FirstName + " " + LastName; public DateTime DateOfBirth { get; set; } public string? Bio { get; set; } }
ساختار ابتدایی موجودیت مقالات بلاگ
namespace MinimalBlog.Domain.Model; public class Article { public Article() { Categories = new List<Category>(); } public int Id { get; set; } public string Title { get; set; } = default!; public string? Subtitle { get; set; } public string Body { get; set; } = default!; public int AuthorId { get; set; } public Author Author { get; set; } = default!; public DateTime DateCreated { get; set; } public DateTime LastUpdated { get; set; } public int NumberOfLikes { get; set; } public int NumberOfShares { get; set; } public ICollection<Category> Categories { get; set; } }
ساختار ابتدایی بلاگهای اختصاصی قابل تعریف
namespace MinimalBlog.Domain.Model; public class Blog { public Blog() { Contributors = new List<Author>(); } public int Id { get; set; } public string Name { get; set; } = default!; public string Description { get; set; } = default!; public DateTime CreatedDate { get; set; } public int AuthorId { get; set; } public Author Owner { get; set; } = default!; public ICollection<Author> Contributors { get; } }
ساختار ابتدایی گروههای مقالات بلاگ
namespace MinimalBlog.Domain.Model; public class Category { public Category() { Articles = new List<Article>(); } public int Id { get; set; } public string Name { get; set; } = default!; public string Description { get; set; } = default!; public ICollection<Article> Articles { get; set; } }
معرفی موجودیتهای تعریف شده به لایهی Dal
لایهی Dal جایی است که DbContext برنامه تعریف میشود و موجودیتها فوق توسط DbSetها در معرض دید EF-Core قرار میگیرند. به همین جهت ابتدا فایل MinimalBlog.Dal.csproj را به صورت زیر تغییر میدهیم:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <ImplicitUsings>enable</ImplicitUsings> <Nullable>enable</Nullable> </PropertyGroup> <ItemGroup> <ProjectReference Include="..\MinimalBlog.Domain\MinimalBlog.Domain.csproj" /> </ItemGroup> <ItemGroup> <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.2"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup> </Project>
به علاوه تعاریفی مانند ImplicitUsings و Nullable را هم مشاهده میکنید که با توجه به استفادهی از فایل Directory.Build.props غیرضروری و تکراری هستند؛ چون این فایل مخصوص به همراه این تعاریف سراسری نیز هست.
سپس به پروژهی Dal، کلاس جدید MinimalBlogDbContext را به صورت زیر اضافه میکنیم تا مدلهای برنامه را در معرض دید EF-Core قرار دهد:
using Microsoft.EntityFrameworkCore; using MinimalBlog.Domain.Model; namespace MinimalBlog.Dal; public class MinimalBlogDbContext : DbContext { public MinimalBlogDbContext(DbContextOptions options) : base(options) { } public DbSet<Article> Articles { get; set; } = default!; public DbSet<Category> Categories { get; set; } = default!; public DbSet<Author> Authors { get; set; } = default!; public DbSet<Blog> Blogs { get; set; } = default!; }
ایجاد و اجرای Migrations
پس از تعریف MinimalBlogDbContext، اکنون نوبت به ایجاد کلاسهای Migrations و اجرای آنها جهت ایجاد بانک اطلاعاتی متناظر با مدلهای برنامه است. برای این منظور در ابتدا به پروژهی Api مراجعه کرده و فایل appsettings.json را به صورت زیر تکمیل میکنیم:
{ "Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" } }, "AllowedHosts": "*", "ConnectionStrings": { "Default": "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=MinimalBlog;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=False;ApplicationIntent=ReadWrite;MultiSubnetFailover=False" } }
<Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>net6.0</TargetFramework> <Nullable>enable</Nullable> <ImplicitUsings>enable</ImplicitUsings> </PropertyGroup> <ItemGroup> <PackageReference Include="Swashbuckle.AspNetCore" Version="6.2.3" /> <PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.2"> <PrivateAssets>all</PrivateAssets> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> </PackageReference> </ItemGroup> <ItemGroup> <ProjectReference Include="..\MinimalBlog.Domain\MinimalBlog.Domain.csproj" /> <ProjectReference Include="..\MinimalBlog.Dal\MinimalBlog.Dal.csproj" /> </ItemGroup> </Project>
using Microsoft.EntityFrameworkCore; using MinimalBlog.Dal; var builder = WebApplication.CreateBuilder(args); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); var connectionString = builder.Configuration.GetConnectionString("Default"); builder.Services.AddDbContext<MinimalBlogDbContext>(opt => opt.UseSqlServer(connectionString));
پس از این تنظیمات به پوشهی MinimalBlog.Dal وارد شده و فایل _01-add_migrations.cmd را اجرا میکنیم (این فایل به همراه پیوست قسمت اول، ارائه شدهاست). محتوای این فایل به صورت زیر است:
For /f "tokens=2-4 delims=/ " %%a in ('date /t') do (set mydate=%%c_%%a_%%b) For /f "tokens=1-2 delims=/:" %%a in ("%TIME: =0%") do (set mytime=%%a%%b) dotnet tool update --global dotnet-ef --version 6.0.2 dotnet build dotnet ef migrations --startup-project ../MinimalBlog.Api/ add V%mydate%_%mytime% --context MinimalBlogDbContext pause
البته چون کدهای تولید شدهی به صورت خودکار الزاما با Roslyn analyzers برنامه سازگاری ندارند، آنها را توسط فایل مخصوص editorconfig. قرار گرفتهی در پوشهی MinimalBlog.Dal\Migrations، از لیست آنالیزهای برنامه خارج میکنیم. محتوای این فایل ویژه به صورت زیر است:
[*.cs] generated_code = true
پس از ایجاد کلاسهای Migration، اکنون نوبت به اجرای آنها بر روی بانک اطلاعاتی است که در رشتهی اتصالی مشخص کردیم. برای اینکار فایل MinimalBlog.Dal\_02-update_db.cmd را اجرا میکنیم که چنین محتویاتی دارد:
dotnet tool update --global dotnet-ef --version 6.0.2 dotnet build dotnet ef --startup-project ../MinimalBlog.Api/ database update --context MinimalBlogDbContext pause
نظرات مطالب
بازنویسی سطح دوم کش برای Entity framework 6
- کش سطح دوم نباید برای کش کردن اطلاعات خصوصی استفاده شود؛ یا کلا اطلاعاتی که نیاز به سطح دسترسی دارند. هدف آن کش کردن اطلاعات عمومی و پر مصرف است. اطلاعات خاص یک کاربر نباید کش شوند.
- در تمام سیستمها، برای مواردی که به کوئریهای آن دسترسی ندارید تا متد Cacheable را به آنها اضافه کنید، نتیجهی کوئریها را باید خودتان از طریق روشهای متداول کش کنید (مانند کلاس CacheManager مطلب یاد شده).
- در تمام سیستمها، برای مواردی که به کوئریهای آن دسترسی ندارید تا متد Cacheable را به آنها اضافه کنید، نتیجهی کوئریها را باید خودتان از طریق روشهای متداول کش کنید (مانند کلاس CacheManager مطلب یاد شده).
مقدمه
نوع داده با دقت - وابسته به طول
نوع داده - داده وابسته به طول
مثالی از کاربرد Sparse columns
مقدار null به معنی پوچ و هیچ میباشد اما زمانی که در مقدار دهی جداول از آن استفاده مینمایم با توجه به نوع آن ستون فضای متفاوتی اشتغال مینماید. شاید در پایگاه دادههای کوچک زیاد مطرح نباشد اما زمانی که حداقل چند گیگ حجم آن باشد و فرضا 20 تا 30 درصد آن از مقادیر null پر شده باشد فضای زیای از پوچ گرفته شده است این در حالی است که خیلی از توسعه دهندگان اصلا به اهمیت استفاده از null توجهی نمیکنند و از مقادیری غیر معتبری مثل 0 یا 1- در آن ستون به جای null استفاده میکنند.
SQL Server Sparce Columns
sparse column یا ستونهای تنک قابلیتی از که از SQL Server 2008 اضافه شده و به ستونهای عادی امکان استفاده بهینه از فضای ذخیره شده برای مقادیر null را میدهد. در واقع sparse column فضای مورد نیاز برای مقادیر null نسبت به مقادیر غیر null را کاهش میدهد. با استفاده از sparse column فضای ذخیره شده حداقل 20 تا 40 درصد کمتر خواهد شد.
ویژگیهای Sparse Columns
- SQL Server Database Engine از کلمه کلیدی SPARSE برای تعریف یک ستون که مقادیر آن میبایست بهینه شود استفاده مینماید.
- نمای Catalog جداول با ستون sparse شبیه جداول معمولی میباشد.
- مقدار برگشتی از تابع COLUMNS_UPDATED با ستون sparce متفاوت از ستون معمولی است.
geography | text |
geometry | timestamp |
image | user-defined data types |
ntext |
sparse column فضای بیشتری برای ذخیره دادههای غیر null نسبت به دادههای نشانه گذاری نشده با SPARSE لازم دارد و این فضا4 بایت بیشتر از ستون معمولی است. برآورد فضای ذخیره شده براساس نوع داده با طول ثابت در جدول زیر آورده شده است:
نوع داده | بایت بدون sparse | بایت sparse | درصد null |
bit | 0.125 | 5 | 98% |
tinyint | 1 | 5 | 86% |
smallint | 2 | 6 | 76% |
int | 4 | 8 | 64% |
bigint | 8 | 12 | 52% |
real | 4 | 8 | 64% |
float | 8 | 12 | 52% |
smallmoney | 4 | 8 | 64% |
money | 8 | 12 | 52% |
smalldatetime | 4 | 8 | 64% |
datetime | 8 | 12 | 52% |
uniqueidentifier | 16 | 20 | 43% |
date | 3 | 7 | 69% |
نوع داده | بایت بدون sparse | یابت sparse | درصد null |
(datetime(2 | 6 | 10 | 57% |
(datetime(2 | 8 | 12 | 52% |
(time(0 | 3 | 7 | 69% |
(time(7 | 5 | 9 | 60% |
(datetimetoffset(0 | 8 | 12 | 52% |
(datetimetoffset (7 | 10 | 14 | 49% |
(decimal/numeric(1,s | 5 | 9 | 60% |
(decimal/numeric(38,s | 17 | 21 | 42% |
(vardecimal(p,s |
نوع داده |
بایت بدون sparse | یابت sparse | درصد null |
sql_variant | 2* | 2* | 60% |
varchar or char | 2* | 4*+ | 60% |
nvarchar or nchar | 2* | 4* | 60% |
varbinary or binary | 2* | 4* | 60% |
xml | 2* | 4* | 60% |
hierarchyid | 2* | 4* | 60% |
محدویتهای استفاده از Sparse columns
- sparse column می بایست nullable باشد و نمیتواند ROWGUIDCOL یا IDENTITY باشد.
- sparse column مقدار پیش فرض نمیتواند داشته باشد
- ستون محاسبه ای نمیتواند sparse باشد
- sparse column نمیتواند بخشی از clustered index یا unique primary key index باشد
- sparse column نمی تواند بخشی از user-defined table باشد
CREATE TABLE Employees_sparse ( EMP_ID INT IDENTITY(5001,1) PRIMARY KEY, SSN CHAR(9) NOT NULL, TITLE CHAR(10) SPARSE NULL, FIRSTNAME VARCHAR(50) NOT NULL, MIDDLEINIT CHAR(1) SPARSE NULL, LASTNAME VARCHAR(50) NOT NULL, EMAIL CHAR(50) SPARSE NULL) GO
CREATE TABLE Employees ( EMP_ID INT IDENTITY(5001,1) PRIMARY KEY, SSN CHAR(9) NOT NULL, TITLE CHAR(10) NULL, FIRSTNAME VARCHAR(50) NOT NULL, MIDDLEINIT CHAR(1) NULL, LASTNAME VARCHAR(50) NOT NULL, EMAIL CHAR(50) NULL) GO
در این دو جدول یکی با سه ستون Sparse و دیگری بدون Sparse ایجاد شده و با 50000 ردیف داده پر شده است حال با رویه ذخیره شده sp_spaceused میتوان فضای ذخیره شده دو جدول را باهم مقایسه نمود.
sp_spaceused 'Employees' GO sp_spaceused 'Employees_sparse'
البته ذکر این نکته گفتی است که بهتر است از این تکنیک برای جداولی که تعداد زیادی ستون null دارند استفاده شود.
SqlDependency محدود هست به SQL Server ضمن اینکه تنظیم آن هم فقط در سمت برنامه نیست. یعنی شخص استفاده کننده باید دسترسی مدیریتی به سرور SQL داشته باشه تا بتونه اون رو تنظیم کنه. ولی زمانیکه با یک ORM کار میکنید، تا زمانیکه از API همون ORM استفاده میکنید، با عوض کردن پروایدر اون، میتونید یک روز از SQL Server و یک روز از اوراکل یا سایر بانکهای اطلاعاتی استفاده کنید. اینجا است که عدم نیاز به دسترسی مدیریتی و همچنین عمومیتر شدن راه حل یک مزیت مهم خواهد شد.
تا اینجا دو روش را برای آزمایش کلی یک سیستم Web API به همراه تمام زیر ساختهای آن، بررسی کردیم:
- استفاده از Postman برای آزمایش یک برنامهی Web API
- استفاده از strest برای آزمایش یک برنامهی Web API
روش سومی هم برای انجام اینکار وجود دارد که به صورت توکار از زمان ارائهی ASP.NET Core 2.1 به همراه TestServer آزمایشی آن میسر شد. این روش در نگارش 3.1، با تغییر روش تعریف فایل program.cs، جهت سازگاری آن با آزمونهای یکپارچگی/آزمایش کل سیستم، بهبود یافتهاست که خلاصهای از آن را در این مطلب بررسی میکنیم.
آزمونهای یکپارچگی در ASP.NET Core
آزمونهای یکپارچگی، برخلاف آزمونهای واحد که عموما از اشیاء تقلیدی استفاده میکنند، دقیقا بر روی همان سیستمی که قرار است به کاربر نهایی ارائه شود، اجرا میشوند. به همین جهت تنظیمات اولیهی آنها کمی بیشتر است و همچنین زمان اجرای آنها نیز به علت وابستگی به بانک اطلاعاتی واقعی، فایل سیستم، شبکه و غیره، نسبت به آزمونهای واحد بیشتر است.
برای ایجاد آزمونهای یکپارچگی در برنامههای ASP.NET Core، حداقل سه مرحله باید طی شوند:
الف) ایجاد یک class library که ارجاعی را به پروژهی اصلی دارد. این پروژه حاوی آزمایشهای ما خواهد بود.
ب) راه اندازی یک هاست وب آزمایشی برای ارسال درخواستها به آن و دریافت پاسخهای نهایی.
ج) استفاده از یک test runner (انواع و اقسام فریم ورکهای unit testing) برای اجرای آزمایشها
ایجاد یک پروژهی کتابخانه برای هاست و اجرای آزمایشهای یکپارچگی
فرض کنید میخواهیم برای همان پروژهی ایجاد JWTها، آزمایش یکپارچگی بنویسیم. پس از ایجاد یک پروژهی کتابخانهی جدید که قرار است هاست آزمایشهای ما شود، نیاز است محتوای فایل csproj آنرا به صورت زیر تغییر داد:
در اینجا، این نکات قابل مشاهده هستند:
1) TargetFramework آن باید به netcoreapp تنظیم شود.
2) باید ارجاع مستقیمی به کل پروژهی نهایی WebApp در آن وجود داشته باشد. چون در ادامه میخواهیم فایل Program.cs آنرا برای راه اندازی یک هاست وب آزمایشی، فراخوانی کنیم.
3) بستهی نیوگتی که کار راه اندازی هاست وب آزمایشی را انجام میدهد، Microsoft.AspNetCore.Mvc.Testing نام دارد. این بسته، کار کپی فایلهای پروژهی اصلی و همچنین تنظیم مسیر پروژه را به این مسیر جدید نیز انجام میدهد.
4) روش افزودن بستههای MSTest را مشاهده میکنید.
5) همچنین جهت سادهتر شدن بررسی نتایج آزمونهای انجام شده میتوان از fluentassertions نیز استفاده کرد.
راه اندازی هاست وب آزمایشی جهت انجام آزمونهای واحد
پس از انجام تنظیمات ابتدایی پروژهی آزمون یکپارچگی، نیاز است یک WebApplicationFactory سفارشی را ایجاد کرد:
در این تعریف، Program در <WebApplicationFactory<Program، دقیقا به همان کلاس Program برنامهی اصلی وب اشاره میکند. به همین جهت امضای این کلاس در نگارش 3.1 تغییر کردهاست تا با WebApplicationFactory بستهی Microsoft.AspNetCore.Mvc.Testing هماهنگ شود.
در ادامه روش سفارشی سازی WebApplicationFactory را مشاهده میکنید. برای مثال اگر خواستید سرویسها و تنظیمات پیشفرض برنامهی اصلی را تغییر دهید میتوانید متد CreateWebHostBuilder را بازنویسی کنید و یا اگر خواستید سرویس جدیدی را اضافه و یا حذف کنید، میتوان متد ConfigureWebHost را بازنویسی کرد.
استفاده از WebApplicationFactory سفارشی، جهت ایجاد یک HttpClient
هدف اصلی از ایجاد CustomWebApplicationFactory نه فقط راه اندازی یک هاست وب سفارشی است، بلکه توسط متد CreateClient آن میتوان به یک HttpClient دسترسی یافت که قابلیت ارسال اطلاعات را به برنامهی وبی که در پشت صحنه راه اندازی میشود، دارا است. کار CustomWebApplicationFactory شبیه به راه اندازی dotnet run در پشت صحنهاست. در اینجا دیگر نیازی نیست تا اینکار را به صورت دستی انجام داد. به همین جهت چون برنامهی وب اصلی به نحو متداولی در پشت صحنه اجرا میشود، عموما راه اندازی آن که شامل تنظیمات اولیه و یا حتی ایجاد بانک اطلاعاتی است، کمی کند است و اگر قرار باشد هربار اینکار صورت گیرد، به آزمونهای بسیار کندی خواهیم رسید. به همین جهت میتوان یک کلاس singleton را برای مدیریت تک وهلهی نهایی HttpClient آن به صورت زیر ایجاد کرد:
مزیت کار با این کلاس، عدم راه اندازی مجدد برنامه به ازای هر آزمون انجام شدهاست. چون به ازای هر آزمونی که خواهیم نوشت، نیاز است به HttpClient دسترسی داشته باشیم.
نوشتن اولین آزمون یکپارچگی
پس از تنظیم هاست وب آزمایشی و ایجاد یک HttpClient از پیش تنظیم شده که به آن اشاره میکند، اکنون میتوان اولین آزمون یکپارچگی را به صورت زیر نوشت:
توضیحات:
- در هر آزمونی نیاز است در ابتدا به TestsHttpClient.Instance، که همان HttpClient ساخته شدهی توسط CustomWebApplicationFactory است، دسترسی یافت و همانطور که عنوان شد، دسترسی به وهلهای از HttpClient که به هاست وب آزمایشی برنامهی اصلی اشاره میکند، عموما بسیار زمانبراست و برای مثال در دو آزمایش نوشته شدهی در اینجا اگر قرا باشد هربار اینکار از صفر انجام شود، زمان به اتمام رسیدن این آزمایشها بسیار طولانی خواهد شد. به همین جهت طول عمر TestsHttpClient را singleton تعریف کردیم تا فقط یکبار کار برپایی وب سرور آزمایشی در پشت صحنه انجام شود.
- سپس مابقی کار، همان روش استاندارد کار با HttpClient است. در ابتدا درخواستی را به سمت سرور آزمایشی که در پشت صحنه در حال اجرا است، ارسال میکنیم. چون HttpClient دریافتی توسط CustomWebApplicationFactory تنظیم شدهاست، دیگر نیازی به ذکر آدرس پایهی وب سایت مانند https://localhost:5001 نیست و آدرسهای ذکر شدهی در اینجا، نسبی هستند. سپس محتوای Response دریافتی از سرور را جهت تکمیل آزمایشات، بررسی خواهیم کرد.
یک نکته: اگر OpenAPI را در برنامههای Web API فعال کنید، میتوان با استفاده از ابزارهای تولید کد، کدهای مرتبط با HttpClient را نیز به صورت خودکار تولید و سپس از آنها در اینجا استفاده کرد.
اجرای آزمونهای یکپارچگی نوشته شده
چون ظاهر این آزمونها با آزمونهای واحد MSTest یا هر فریم ورک مشابه دیگری یکسان است، میتوان از امکانات IDEها برای اجرای آنها استفاده کرد و یا حتی میتوان دستور dotnet test را نیز در ریشهی این پروژهی جدید برای اجرای تمام آزمونهای نوشته شده، اجرا کرد:
کدهای کامل این مطلب را در اینجا میتوانید مشاهده کنید.
- استفاده از Postman برای آزمایش یک برنامهی Web API
- استفاده از strest برای آزمایش یک برنامهی Web API
روش سومی هم برای انجام اینکار وجود دارد که به صورت توکار از زمان ارائهی ASP.NET Core 2.1 به همراه TestServer آزمایشی آن میسر شد. این روش در نگارش 3.1، با تغییر روش تعریف فایل program.cs، جهت سازگاری آن با آزمونهای یکپارچگی/آزمایش کل سیستم، بهبود یافتهاست که خلاصهای از آن را در این مطلب بررسی میکنیم.
آزمونهای یکپارچگی در ASP.NET Core
آزمونهای یکپارچگی، برخلاف آزمونهای واحد که عموما از اشیاء تقلیدی استفاده میکنند، دقیقا بر روی همان سیستمی که قرار است به کاربر نهایی ارائه شود، اجرا میشوند. به همین جهت تنظیمات اولیهی آنها کمی بیشتر است و همچنین زمان اجرای آنها نیز به علت وابستگی به بانک اطلاعاتی واقعی، فایل سیستم، شبکه و غیره، نسبت به آزمونهای واحد بیشتر است.
برای ایجاد آزمونهای یکپارچگی در برنامههای ASP.NET Core، حداقل سه مرحله باید طی شوند:
الف) ایجاد یک class library که ارجاعی را به پروژهی اصلی دارد. این پروژه حاوی آزمایشهای ما خواهد بود.
ب) راه اندازی یک هاست وب آزمایشی برای ارسال درخواستها به آن و دریافت پاسخهای نهایی.
ج) استفاده از یک test runner (انواع و اقسام فریم ورکهای unit testing) برای اجرای آزمایشها
ایجاد یک پروژهی کتابخانه برای هاست و اجرای آزمایشهای یکپارچگی
فرض کنید میخواهیم برای همان پروژهی ایجاد JWTها، آزمایش یکپارچگی بنویسیم. پس از ایجاد یک پروژهی کتابخانهی جدید که قرار است هاست آزمایشهای ما شود، نیاز است محتوای فایل csproj آنرا به صورت زیر تغییر داد:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netcoreapp3.1</TargetFramework> <NoWarn>RCS1090</NoWarn> </PropertyGroup> <ItemGroup> <ProjectReference Include="..\ASPNETCore2JwtAuthentication.WebApp\ASPNETCore2JwtAuthentication.WebApp.csproj" /> </ItemGroup> <ItemGroup> <None Include="..\ASPNETCore2JwtAuthentication.WebApp\appsettings.json" CopyToOutputDirectory="PreserveNewest" /> </ItemGroup> <ItemGroup> <Service Include="{82a7f48d-3b50-4b1e-b82e-3ada8210c329}" /> </ItemGroup> <ItemGroup> <PackageReference Include="fluentassertions" Version="5.10.3" /> <PackageReference Include="Microsoft.AspNetCore.Mvc.Testing" Version="3.1.8" /> <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1" /> <PackageReference Include="MSTest.TestAdapter" Version="2.1.2" /> <PackageReference Include="MSTest.TestFramework" Version="2.1.2" /> </ItemGroup> </Project>
1) TargetFramework آن باید به netcoreapp تنظیم شود.
2) باید ارجاع مستقیمی به کل پروژهی نهایی WebApp در آن وجود داشته باشد. چون در ادامه میخواهیم فایل Program.cs آنرا برای راه اندازی یک هاست وب آزمایشی، فراخوانی کنیم.
3) بستهی نیوگتی که کار راه اندازی هاست وب آزمایشی را انجام میدهد، Microsoft.AspNetCore.Mvc.Testing نام دارد. این بسته، کار کپی فایلهای پروژهی اصلی و همچنین تنظیم مسیر پروژه را به این مسیر جدید نیز انجام میدهد.
4) روش افزودن بستههای MSTest را مشاهده میکنید.
5) همچنین جهت سادهتر شدن بررسی نتایج آزمونهای انجام شده میتوان از fluentassertions نیز استفاده کرد.
راه اندازی هاست وب آزمایشی جهت انجام آزمونهای واحد
پس از انجام تنظیمات ابتدایی پروژهی آزمون یکپارچگی، نیاز است یک WebApplicationFactory سفارشی را ایجاد کرد:
using ASPNETCore2JwtAuthentication.WebApp; using Microsoft.AspNetCore.Hosting; using Microsoft.AspNetCore.Mvc.Testing; using Microsoft.AspNetCore.TestHost; using Microsoft.Extensions.DependencyInjection.Extensions; using Microsoft.Extensions.Hosting; namespace ASPNETCore2JwtAuthentication.IntegrationTests { public class CustomWebApplicationFactory : WebApplicationFactory<Program> { protected override IWebHostBuilder CreateWebHostBuilder() { var builder = base.CreateWebHostBuilder(); builder.ConfigureLogging(logging => { //TODO: ... }); return builder; } protected override void ConfigureWebHost(IWebHostBuilder builder) { builder.ConfigureTestServices(services => { // Don't run `IHostedService`s when running as a test services.RemoveAll(typeof(IHostedService)); }); } } }
در ادامه روش سفارشی سازی WebApplicationFactory را مشاهده میکنید. برای مثال اگر خواستید سرویسها و تنظیمات پیشفرض برنامهی اصلی را تغییر دهید میتوانید متد CreateWebHostBuilder را بازنویسی کنید و یا اگر خواستید سرویس جدیدی را اضافه و یا حذف کنید، میتوان متد ConfigureWebHost را بازنویسی کرد.
استفاده از WebApplicationFactory سفارشی، جهت ایجاد یک HttpClient
هدف اصلی از ایجاد CustomWebApplicationFactory نه فقط راه اندازی یک هاست وب سفارشی است، بلکه توسط متد CreateClient آن میتوان به یک HttpClient دسترسی یافت که قابلیت ارسال اطلاعات را به برنامهی وبی که در پشت صحنه راه اندازی میشود، دارا است. کار CustomWebApplicationFactory شبیه به راه اندازی dotnet run در پشت صحنهاست. در اینجا دیگر نیازی نیست تا اینکار را به صورت دستی انجام داد. به همین جهت چون برنامهی وب اصلی به نحو متداولی در پشت صحنه اجرا میشود، عموما راه اندازی آن که شامل تنظیمات اولیه و یا حتی ایجاد بانک اطلاعاتی است، کمی کند است و اگر قرار باشد هربار اینکار صورت گیرد، به آزمونهای بسیار کندی خواهیم رسید. به همین جهت میتوان یک کلاس singleton را برای مدیریت تک وهلهی نهایی HttpClient آن به صورت زیر ایجاد کرد:
using System; using System.Threading; using System.Net.Http; namespace ASPNETCore2JwtAuthentication.IntegrationTests { public static class TestsHttpClient { private static readonly Lazy<HttpClient> _serviceProviderBuilder = new Lazy<HttpClient>(getHttpClient, LazyThreadSafetyMode.ExecutionAndPublication); /// <summary> /// A lazy loaded thread-safe singleton /// </summary> public static HttpClient Instance { get; } = _serviceProviderBuilder.Value; private static HttpClient getHttpClient() { var services = new CustomWebApplicationFactory(); return services.CreateClient(); //NOTE: This action is very time consuming, so it should be defined as a singleton. } } }
نوشتن اولین آزمون یکپارچگی
پس از تنظیم هاست وب آزمایشی و ایجاد یک HttpClient از پیش تنظیم شده که به آن اشاره میکند، اکنون میتوان اولین آزمون یکپارچگی را به صورت زیر نوشت:
using System.Net.Http; using System.Net.Http.Headers; using System.Text; using System.Text.Json; using System.Threading.Tasks; using FluentAssertions; using Microsoft.VisualStudio.TestTools.UnitTesting; namespace ASPNETCore2JwtAuthentication.IntegrationTests { [TestClass] public class JwtTests { [TestMethod] public async Task TestLoginWorks() { // Arrange var client = TestsHttpClient.Instance; // Act var token = await doLoginAsync(client); // Assert token.Should().NotBeNull(); token.AccessToken.Should().NotBeNullOrEmpty(); token.RefreshToken.Should().NotBeNullOrEmpty(); } [TestMethod] public async Task TestCallProtectedApiWorks() { // Arrange var client = TestsHttpClient.Instance; // Act var token = await doLoginAsync(client); // Assert token.Should().NotBeNull(); token.AccessToken.Should().NotBeNullOrEmpty(); token.RefreshToken.Should().NotBeNullOrEmpty(); // Act const string protectedApiUrl = "/api/MyProtectedApi"; client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token.AccessToken); var response = await client.GetAsync(protectedApiUrl); response.EnsureSuccessStatusCode(); // Assert var responseString = await response.Content.ReadAsStringAsync(); responseString.Should().NotBeNullOrEmpty(); var options = new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.CamelCase }; var apiResponse = JsonSerializer.Deserialize<MyProtectedApiResponse>(responseString, options); apiResponse.Title.Should().NotBeNullOrEmpty(); apiResponse.Title.Should().Be("Hello from My Protected Controller! [Authorize]"); } private static async Task<Token> doLoginAsync(HttpClient client) { const string loginUrl = "/api/account/login"; var user = new { Username = "Vahid", Password = "1234" }; var response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Post, loginUrl) { Content = new StringContent(JsonSerializer.Serialize(user), Encoding.UTF8, "application/json") }); response.EnsureSuccessStatusCode(); var responseString = await response.Content.ReadAsStringAsync(); responseString.Should().NotBeNullOrEmpty(); return JsonSerializer.Deserialize<Token>(responseString); } } }
- در هر آزمونی نیاز است در ابتدا به TestsHttpClient.Instance، که همان HttpClient ساخته شدهی توسط CustomWebApplicationFactory است، دسترسی یافت و همانطور که عنوان شد، دسترسی به وهلهای از HttpClient که به هاست وب آزمایشی برنامهی اصلی اشاره میکند، عموما بسیار زمانبراست و برای مثال در دو آزمایش نوشته شدهی در اینجا اگر قرا باشد هربار اینکار از صفر انجام شود، زمان به اتمام رسیدن این آزمایشها بسیار طولانی خواهد شد. به همین جهت طول عمر TestsHttpClient را singleton تعریف کردیم تا فقط یکبار کار برپایی وب سرور آزمایشی در پشت صحنه انجام شود.
- سپس مابقی کار، همان روش استاندارد کار با HttpClient است. در ابتدا درخواستی را به سمت سرور آزمایشی که در پشت صحنه در حال اجرا است، ارسال میکنیم. چون HttpClient دریافتی توسط CustomWebApplicationFactory تنظیم شدهاست، دیگر نیازی به ذکر آدرس پایهی وب سایت مانند https://localhost:5001 نیست و آدرسهای ذکر شدهی در اینجا، نسبی هستند. سپس محتوای Response دریافتی از سرور را جهت تکمیل آزمایشات، بررسی خواهیم کرد.
یک نکته: اگر OpenAPI را در برنامههای Web API فعال کنید، میتوان با استفاده از ابزارهای تولید کد، کدهای مرتبط با HttpClient را نیز به صورت خودکار تولید و سپس از آنها در اینجا استفاده کرد.
اجرای آزمونهای یکپارچگی نوشته شده
چون ظاهر این آزمونها با آزمونهای واحد MSTest یا هر فریم ورک مشابه دیگری یکسان است، میتوان از امکانات IDEها برای اجرای آنها استفاده کرد و یا حتی میتوان دستور dotnet test را نیز در ریشهی این پروژهی جدید برای اجرای تمام آزمونهای نوشته شده، اجرا کرد:
کدهای کامل این مطلب را در اینجا میتوانید مشاهده کنید.
برای دیتابیس چه کاری انجام میدید؟ یعنی برنامه ای که با EF6 نوشته شده بود میتونست خودش بانک اطلاعات ایجاد کنه. حالا dotnet core چه جایگزینی داره؟ نمیشه از همین دستورات EF Core در هاست هم کمک گرفت تا دیتابیس در آنجا ساخته شود؟
ارتقاء به EF Core 2.1:
مقدار دهی اولیهی جداول بانکهای اطلاعاتی
روشی که در مطلب جاری در مورد متد Seed گفته شدهاست، هنوز هم کار میکند. در نگارش 2.1 روش توکاری را برای این منظور در متد OnModelCreating معرفی کردهاند:
protected override void OnModelCreating(ModelBuilder modelBuilder) { modelBuilder.Entity<Blog>() .HasData(new Blog { BlogId = 1, Url = "http://sample.com" }); }
اگر موجودیت در حال ثبت نیاز به تعریف کلید خارجی داشته باشد، باید از یک anonymous class استفاده کرد:
modelBuilder.Entity<Post>().HasData( new {BlogId = 1, PostId = 1, Title = "First post", Content = "Test 1"}, new {BlogId = 1, PostId = 2, Title = "Second post", Content = "Test 2"});
اشتراکها