WSL2 runs a real Linux kernel in Windows 10 and it's managing a virtual machine platform underneath (and not visible to) Hyper-V client tools, then why not just let WSL2 handle containers for us? That's exactly what the Docker Desklop WSL 2 Tech Preview aims to do.
NET Core 3 Preview 3. منتشر شد
روش نگاشت محتوای یک سایت استاتیک در یک Container که وب سرور است
فرض کنید یک سایت استاتیک بوت استرپی را تهیه کردهاید و قصد دارید آنرا توسط وب سرور nginx، هاست کنید. برای اینکار، چندین گزینه پیش روی ما هستند:
گزینهی اول: دریافت image مربوط به nginx، سپس ایجاد یک container از آن و در آخر با استفاده از «روش به اشتراک گذاری فایل سیستم میزبان با کانتینرها» که در قسمت قبل بررسی کردیم، این وب سایت را آمادهی اجرا و دسترسی میکنیم.
گزینهی دوم: کپی کردن فایلهای وب سایت از سیستم میزبان، به درون فایل سیستم خود container.
گزینهی سوم: ایجاد یک image سفارشی که از ابتدا به همراه فایلهای وب سایت استاتیک ما است و در این حالت تنها کافی است این image را تبدیل به container اجرایی کنیم.
روش اول: به اشتراک گذاری فایل سیستم میزبان با کانتینر وب سرور جهت هاست آن
در قسمت قبل، یک فایل tar ایجاد شدهی در سیستم میزبان ویندوزی را با یک کانتینر لینوکسی به اشتراک گذاشتیم تا بتوانیم محتویات آنرا استخراج کنیم. در اینجا قصد داریم پوشهی وب سایت استاتیک خود را که در سیستم میزبان ویندوزی قرار دارد، با وب سرور nginx که توسط یک container در حال اجرا است، به اشتراک بگذاریم تا آنرا هاست کند.
فرض کنید وب سایت استاتیک ما در مسیر c:\users\vahid\mysite سیستم میزبان قرار دارد که داخل آن یک فایل index.html و تعدادی فایل css و js آمادهی برای هاست شدن، وجود دارند. برای هاست آن توسط nginx، از دستور زیر استفاده خواهیم کرد:
docker run --rm -it -p 8080:80 -v c:\users\vahid\mysite:/usr/share/nginx/html nginx
- سوئیچ rm سبب میشود تا پس از خاتمهی کار nginx، این container نیز حذف شود.
- از سوئیچ it استفاده شدهاست تا با فشردن ctrl+c، بتوانیم پروسهی container را خاتمه دهیم و پس از آن، برنامهی nginx دیگر در background در حال اجرا نباشد (اجرای آن در foreground).
- سپس پورت 8080 سیستم میزبان، به پورت 80 وب سرور nginx نگاشت شدهاست. چون containerها دارای network stack خاص خودشان هستند (که آنرا در قسمت سوم بررسی کردیم)، پورت 80 آنها با پورت 80 سیستم میزبان تداخل نمیکند و اگر برای مثال بر روی پورت 80 سیستم جاری، IIS در حال اجرا باشد، سبب عدم اجرا شدن وب سرور nginx به دلیل تداخل پورتها نمیشود.
- در ادامه روش volume mount را مشاهده میکنید که در قسمت قبل بررسی کردیم. مسیر c:\users\vahid\mysite سیستم میزبان، به مسیر ویژهی /usr/share/nginx/html داخل container نگاشت شدهاست. این مسیر، یک مسیر استاندارد بوده و در مستندات docker hub این وب سرور، ذکر شدهاست.
- در آخر هم نام image این وب سرور را ذکر کردهایم.
پس از اجرای این دستور، اگر nginx پیشتر دریافت نشده باشد، image آن دریافت شده، یک container بر اساس آن ساخته میشود و سپس با پارامترهایی که توضیح دادیم، اجرا خواهد شد. اکنون اگر در سیستم میزبان، مسیر http://localhost:8080 را در مرورگر باز کنید، وب سایت استاتیک خود را مشاهده خواهید کرد.
روش دوم: کپی کردن فایلهای وب سایت از سیستم میزبان، به درون فایل سیستم خود container
همانطور که در قسمت سوم نیز بررسی کردیم، فایل سیستم مربوط به هاست، به طور کامل از فایل سیستم container، جدا و ایزوله است و بدون volume mount، یک container نمیتواند به فایلهای میزبان خود دسترسی پیدا کند. بنابراین گزینهی دیگری که در اینجا وجود خواهد داشت، کپی کردن فایلهای میزبان و انتقال آنها به container میباشد؛ شبیه به کپی کردن فایلها از یک کامپیوتر موجود در شبکه به کامپیوتر دیگری در آن.
برای این منظور ابتدا nginx را در پسزمینه اجرا میکنیم:
docker run -d -p 8080:80 --name nginx nginx
پس از اجرای این دستور و بازگشت به command prompt، جهت اطمینان حاصل کردن از اجرای آن در پس زمینه، دستور docker ps را صادر میکنیم که لیست آن، حاوی گزارشی از containerهای در حال اجرا است.
اکنون توسط دستور ویژهی docker exec، میخواهیم درون یک container در حال اجرا، پروسهای را اجرا کنیم. یعنی با اینکه پروسهی nginx داخل این container در حال اجرا است، برای مثال میخواهیم یک shell را نیز داخل آن اجرا کنیم:
docker exec -it nginx bash
cd /usr/share/nginx/html
ls mv index.html index2.html exit
docker cp c:\users\vahid\mysite nginx:/usr/share/nginx/html
docker exec nginx ls /usr/share/nginx/html
روش سوم: ایجاد یک image سفارشی که از ابتدا به همراه فایلهای وب سایت استاتیک ما است
در روش دوم، موفق شدیم که فایلهای مدنظر خود را به درون container در حال اجرا کپی کنیم. اکنون میخواهیم یک snapshot را از آن تهیه کنیم؛ شبیه به کاری که با ماشینهای مجازی نیز انجام میشود و این روشی است که از آن برای ساخت یک image سفارشی استفاده میشود. برای این منظور از دستور docker commit استفاده میشود تا تصویری را از وضعیت یک container در حال اجرا، در آن لحظه تهیه کنیم:
docker commit nginx mysite:nginx
اکنون پس از اجرای این دستور، با استفاده از فرمان docker images میتوان مشاهده کرد که image جدید mysite، با tag ای معادل nginx، ایجاد شدهاست.
در ادامه برای اجرای این image جدید، میتوان از دستور زیر استفاده کرد:
docker run -d -p 8090:80 --name mysite mysite:nginx
اکنون اگر در سیستم میزبان، مسیر http://localhost:8090 را در مرورگر باز کنید، وب سایت استاتیک خود را مشاهده خواهید کرد و یا توسط دستور زیر میتوانید فایلهای موجود در پوشهی html وب سرور nginx این container جدید در حال اجرا را ملاحظه نمائید:
docker exec mysite ls /usr/share/nginx/html
نگاهی به لایههای یک Image در مقایسه با یک Container
زمانیکه خواستیم image جدید و سفارشی خاص خود را ایجاد کنیم، با image اصلی nginx شروع کردیم. اولین لایهی موجود در این image، سیستم عاملی است که میتواند آنرا اجرا کند. برفراز این لایه، لایهی خود nginx قرار گرفتهاست. اگر خواستید تاریخچهی ایجاد یک image را مشاهده کنید، از دستور docker history nginx استفاده نمائید. خروجی آن لیست دستوراتی را نمایش میدهد که برای ساخت این image مورد استفاده قرار گرفتهاند. البته دستور docker history nginx --no-trunc، اطلاعات بیشتری را با نمایش لیست کامل و خلاصه نشدهی دستورات، ارائه میدهد. این دستورات را در صفحهی docker hub هر image نیز میتوان مشاهده کرد. در قسمت full description هر image، در ابتدای توضیحات، قسمتی است به نام supported tags and respective dockerfile links. در اینجا هر tag نامبرده شده، در حقیقت لینکی است به یک فایل که دقیقا همین دستورات را لیست کردهاست. به این فایل، docker file گفته میشود که روش ساخت یک image را توضیح میدهد. هدف آن، خودکار سازی اجرای دستوراتی است که سبب ساخت یک image میشوند.
در ادامه اگر از این image، یک container را ایجاد کنیم، این container هر دو لایهی OS و Framework را به همراه خواهد داشت؛ به علاوهی لایهی دیگری به نام Container/Run که میتوان فایلهای آنرا خواند و یا در آن نوشت. بنابراین لایهای که فایلهای وب سایت استاتیک ما در آن کپی شدند، دقیقا همین لایهاست.
و زمانیکه از یک container تصویری تهیه میشود، تغییراتی را که به فایل سیستم آن ایجاد کردهایم، به صورت یک لایهی جدید بر روی لایههای قبلی آن image، ظاهر و ثبت میشود. برای اثبات این موضوع، میتوان از دستور docker diff nginx استفاده کرد. در اینجا nginx نام container ای است که میخواهیم تغییرات آنرا با image قبلی که بر پایهی آن ایجاد شدهاست، مشاهده کنیم.
تبدیل دستورات docker به یک docker file
تا اینجا یک چنین دستوراتی را برای اجرای کانتینر nginx، کپی فایلها به آن و سپس تهیهی یک تصویر از آن، اجرا کردیم:
docker run -d -p 8080:80 --name nginx nginx docker cp c:\users\vahid\mysite nginx:/usr/share/nginx/html docker commit nginx mysite:nginx
بجای سطر اول، تنها نام image ای را که میخواهیم کار را بر مبنای آن انجام دهیم، ذکر میکنیم:
FROM nginx
COPY mysite /usr/share/nginx/html
سپس برای اجرای این فایل، بجای دستور docker commit آخر، از دستور زیر استفاده میکنیم:
docker build -f Dockerfile -t mysite:nginx-df .
docker build -t mysite:nginx-df .
تگ این image را نیز متفاوت با قبلیها انتخاب کردهایم؛ nginx-df بجای مقدار قبلی.
در این حالت اگر دستور آخر را اجرا کنیم، دستور docker images گزارش اضافه شدن این image جدید را ارائه خواهد داد.
مرجع کامل ساخت Dockerfileها را در اینجا میتوانید مطالعه کنید.
ساخت یک image سفارشی برای هاست یک وب سایت استاتیک در IIS
تا اینجا از وب سرور لینوکسی nginx برای هاست وب سایت استاتیک خود استفاده کردیم. در ادامه میخواهیم از وب سرور IIS برای اینکار استفاده نمائیم. بنابراین ابتدا نیاز است یا از ویندوز سرور استفاده کنیم و یا میتوان با کلیک راست بر روی آیکن Docker در قسمت Tray Icons ویندوز، به Windows Containers سوئیچ کرد و سپس به صورت زیر عمل نمود.
اینبار محتوای Dockerfile ای که کنار پوشهی mysite قرار میگیرد، به صورت زیر خواهد بود:
FROM microsoft/iis:nanoserver COPY mysite c:/inetpub/wwwroot
در ادامه با استفاده از دستور زیر و اجرای فایل Dockerfile، این image جدید را با tag ای به نام iis ایجاد میکنیم:
docker build -t mysite:iis .
به اشتراک گذاری imageهای سفارشی در Docker Hub
برای به اشتراک گذاری imageهای سفارشی خود در Docker Hub، نیاز است tag آنها را توسط دستور docker tag مطابق فرمت ویژهی docker hub ویرایش کرد:
docker tag mysite:nginx-df my_user_name/some_name:new_tag_name
و در آخر برای انتشار آن میتوان از دستور docker push استفاده کرد:
docker push my_user_name/some_name:new_tag_name
پس از پایان کار اگر به سایت docker hub و مخازن خود مراجعه کنید، این image جدید قابل مشاهده خواهد بود.
Visual Studio Code 1.34 منتشر شد
What’s Next in C#? - Mads Torgersen - Copenhagen DevFest 2023
NDC Conferences
Join Mads on a tour of upcoming language features in C#. While still very much in the works, C# 12 is starting to take shape. We touch on some of the ways, big and small, that C# is striving to make your life easier in the coming years.
بررسی اکوسیستم React در سال 2024
وقت خداحافظی از Docker است!
Bridge Network Driver
The bridge
networking driver is the first driver on our list. It’s simple to understand, simple to use, and simple to troubleshoot, which makes it a good networking choice for developers and those new to Docker. The bridge
driver creates a private network internal to the host so containers on this network can communicate. External access is granted by exposing ports to containers. Docker secures the network by managing rules that block connectivity between different Docker networks.
Overlay Network Driver
The built-in Docker overlay
network driver radically simplifies many of the complexities in multi-host networking. It is a swarm scope driver, which means that it operates across an entire Swarm or UCP cluster rather than individual hosts. With the overlay
driver, multi-host networks are first-class citizens inside Docker without external provisioning or components. IPAM, service discovery, multi-host connectivity, encryption, and load balancing are built right in. For control, the overlay
driver uses the encrypted Swarm control plane to manage large scale clusters at low convergence times.
MACVLAN Driver
The macvlan
driver is the newest built-in network driver and offers several unique characteristics. It’s a very lightweight driver, because rather than using any Linux bridging or port mapping, it connects container interfaces directly to host interfaces. Containers are addressed with routable IP addresses that are on the subnet of the external network.
As a result of routable IP addresses, containers communicate directly with resources that exist outside a Swarm cluster without the use of NAT and port mapping. This can aid in network visibility and troubleshooting. Additionally, the direct traffic path between containers and the host interface helps reduce latency. macvlan
is a local scope network driver which is configured per-host. As a result, there are stricter dependencies between MACVLAN and external networks, which is both a constraint and an advantage that is different from overlay
or bridge
.
We kindly ask you for your valuable input on the priorities for modernizing investments that the WPF team should focus on, as outlined in the roadmap document for 2023.
Please use thumbs up (no other emoji responses will be considered to avoid duplication) on options below which you would like us to prioritize.