اجرای داکر در ARM: روش‌های اجرا و نحوه پیاده‌سازی

در این مقاله به بررسی روش‌های اجرای داکر در ARM می‌پردازیم؛ از نصب مستقیم روی دستگاه‌هایی مانند رزبری‌پای و مک‌های اپل‌سیلیکون گرفته تا استفاده از شبیه‌سازی برای تست ایمیج‌های arm روی سیستم‌های x86. با گسترش این معماری در لپ‌تاپ‌ها، سرورهای ابری و تجهیزات edge، شناخت تفاوت اجرای بومی و اجرای شبیه‌سازی‌شده برای هر کسی که با کانتینرها کار می‌کند اهمیت پیدا کرده است. در ادامه مسیرهای نصب روی پلتفرم‌های مختلف، نحوه ساخت ایمیج‌های چندمعماری با Buildx، و نکاتی که پیش از مهاجرت باید مدنظر قرار گیرد را بررسی می‌کنیم.

چرا اجرای داکر در ARM به یکی از گزینه‌های اصلی تبدیل شده؟

معماری ARM که زمانی تقریبا منحصر به گوشی‌های هوشمند و تجهیزات کوچک بود، حالا بخش قابل‌توجهی از دنیای سرور و دسکتاپ را هم در اختیار گرفته است. تراشه‌های اپل‌سیلیکون مک‌بوک‌ها را به‌طور کامل به ARM منتقل کردند، خانواده پردازنده‌های Graviton در آمازون وب سرویس برای بسیاری از بارهای کاری نسبت به نمونه‌های x86 تا حدود ۴۰ درصد نسبت قیمت به کارایی بهتری ارائه می‌دهند، و حتی ویندوز هم برای نصب داکر روی arm با Windows on Arm و پشتیبانی رسمی دسکتاپ از این لپ‌تاپ‌ها وارد میدان شده است.
در کنار این‌ها، رزبری‌پای همچنان گزینه‌ی محبوب علاقه‌مندان به هوم‌لب و پروژه‌های edge است. نتیجه این تغییرات ساده است: تیم‌های توسعه دیگر نمی‌توانند فرض کنند همه‌چیز فقط روی x86 اجرا می‌شود، و باید بدانند ایمیج‌هایشان روی ARM هم به همان شکل کار می‌کند یا نه.

دو مسیر متفاوت برای اجرای داکر روی ARM

وقتی صحبت از اجرای کانتینر روی پردازنده ARM می‌شود، دو رویکرد کاملا متفاوت وجود دارد که نتیجه و کارایی متفاوتی هم دارند.

اجرای بومی؛ وقتی خود سخت‌افزار ARM است

در این حالت، ایمیجی که برای معماری arm64 یا armv7 ساخته شده، مستقیما روی پردازنده ARM اجرا می‌شود؛ دقیقا مثل اجرای یک ایمیج amd64 روی پردازنده اینتل یا AMD. این روش سریع‌ترین و قابل‌اعتمادترین حالت است و در دستگاه‌هایی مثل رزبری‌پای، مک‌های اپل‌سیلیکون یا نمونه‌های Graviton در کلود استفاده می‌شود.

اجرای شبیه‌سازی‌شده با QEMU

اگر بخواهید روی یک سیستم x86 ایمیج ARM را اجرا یا تست کنید، داکر از طریق QEMU و مکانیزم binfmt دستورات را در لحظه به معماری میزبان ترجمه می‌کند. این کار روی داکر دسکتاپ به‌صورت پیش‌فرض فعال است؛ روی توزیع‌های لینوکسی هم با اجرای ایمیج tonistiigi/binfmt قابل فعال‌سازی است. این روش برای تست محلی مفید است، اما به دلیل سربار ترجمه دستورات، کندتر از اجرای بومی است و برای بار تولیدی پیشنهاد نمی‌شود.

مسیرهای نصب داکر روی دستگاه‌ها و سرویس‌های ARM

نصب روی رزبری‌پای

داکر روی Raspberry Pi OS از طریق اسکریپت رسمی نصب می‌شود که به‌صورت خودکار معماری دستگاه را تشخیص می‌دهد:

curl -fsSL https://get.docker.com -o get-docker.sh

sudo sh get-docker.sh

پس از نصب، کاربر باید به گروه docker اضافه شود تا نیازی به sudo برای هر دستور نباشد. برای استفاده طولانی‌مدت، نسخه ۶۴ بیتی Raspberry Pi OS توصیه می‌شود چون بسیاری از ایمیج‌های موجود در Docker Hub فقط نسخه arm64 دارند، نه armhf سی‌و‌دو بیتی. اگر داکر قرار است به‌صورت دائمی و با ترافیک نوشتاری بالا کار کند، بوت کردن سیستم از روی SSD یا NVMe به‌جای کارت حافظه به طول عمر سخت‌افزار کمک زیادی می‌کند.

داکر دسکتاپ روی مک اپل‌سیلیکون و ویندوز ARM

داکر دسکتاپ از ابتدای عرضه تراشه‌های اپل‌سیلیکون به‌صورت بومی از آن‌ها پشتیبانی کرده و تجربه‌ای یکسان با نسخه اینتلی ارائه می‌دهد. به‌تازگی این پشتیبانی به دستگاه‌های Windows on Arm هم رسیده و کاربران این لپ‌تاپ‌ها می‌توانند بدون نیاز به شبیه‌سازی، همان رابط و دستورات آشنای داکر را اجرا کنند.

ماشین‌های ARM در فضاهای ابری

سرویس‌هایی مثل AWS با خانواده پردازنده‌های Graviton گزینه‌ای جدی برای اجرای بارهای کاری کانتینری روی ARM ارائه کرده‌اند. برای استفاده از این نمونه‌ها کافی است یک AMI با معماری arm64 انتخاب شود و ایمیج‌های داکر هم نسخه ARM داشته باشند؛ در غیر این صورت کانتینر اصلا بالا نمی‌آید. بیشتر سرویس‌های مدیریتی مثل ECS و EKS هم از این نمونه‌ها پشتیبانی می‌کنند.

ساخت ایمیج چندمعماری با Docker Buildx

اگر هدف این است که یک ایمیج هم روی x86 و هم روی ARM کار کند، راه‌حل استاندارد استفاده از افزونه Buildx است که همراه نسخه‌های جدید داکر نصب می‌شود. این ابزار به‌جای ساخت یک ایمیج برای یک معماری، یک manifest list می‌سازد که نسخه‌های مختلف ایمیج برای هر پلتفرم را در خود نگه می‌دارد و در زمان pull، داکر به‌صورت خودکار نسخه مناسب سیستم را انتخاب می‌کند:

docker buildx build –platform linux/amd64,linux/arm64 -t myapp:latest –push .

برای زبان‌های کامپایل‌شده مثل Go یا Rust، استفاده از FROM –platform=$BUILDPLATFORM در مرحله build و سپس cross-compile کردن باینری، سرعت ساخت را به‌مراتب بالاتر می‌برد چون از شبیه‌سازی کند QEMU عبور می‌کند. پیش از استقرار هر ایمیج پایه هم می‌توان با دستور docker buildx imagetools inspect بررسی کرد که آیا نسخه arm64 دارد یا نه.

نکاتی که پیش از اجرای داکر روی ARM باید بدانید

• برخی ایمیج‌های قدیمی یا وابسته به کتابخانه‌های native فقط نسخه amd64 دارند؛ پیش از مهاجرت باید این موضوع بررسی شود.
• اجرای شبیه‌سازی‌شده با QEMU گزینه‌ی خوبی برای تست محلی است، اما به دلیل افت محسوس کارایی برای محیط تولید توصیه نمی‌شود.
• معماری‌های ۳۲ بیتی (armv7/armhf) و ۶۴ بیتی (arm64/aarch64) با هم متفاوت هستند و ایمیج باید دقیقا با معماری سیستم هماهنگ باشد.
• دستگاه‌های قدیمی‌تر مبتنی بر ARMv6 (مثل رزبری‌پای نسل اول یا Zero) دیگر توسط پکیج‌های رسمی داکر پشتیبانی نمی‌شوند.

جمع‌بندی

اجرای داکر در ARM امروزه دیگر یک سناریوی خاص یا آزمایشی نیست، بلکه بخشی طبیعی از کار با کانتینرها روی مک‌های اپل‌سیلیکون، لپ‌تاپ‌های ویندوز ARM، رزبری‌پای و نمونه‌های Graviton در کلود است. نکته کلیدی، تشخیص درست بین اجرای بومی -که سریع‌تر و پایدارتر است- و اجرای شبیه‌سازی‌شده با QEMU است که بیشتر برای تست محلی کاربرد دارد. ساخت ایمیج‌های چندمعماری با Docker Buildx این امکان را می‌دهد که یک تگ واحد، هم روی x86 و هم روی ARM به‌درستی اجرا شود، بدون نیاز به نگهداری دو نسخه جداگانه. در نهایت، بررسی پشتیبانی ایمیج‌های پایه از arm64 و توجه به محدودیت‌های سخت‌افزاری دستگاه‌هایی مثل رزبری‌پای، مهم‌ترین گام‌هایی است که پیش از هر مهاجرت یا استقرار باید برداشته شود.

سوالات متداول