چگونه ویژگی‌های HTTP/2 به سطح حمله تبدیل شد؟

پروتکل HTTP/2 با هدف بهبود عملکرد وب و کاهش سربار ارتباطات معرفی شد. قابلیت‌هایی مانند فشرده‌سازی هدرها (HPACK) و کنترل جریان (Flow-Control Window) باعث افزایش سرعت و کاهش مصرف پهنای باند شده‌اند، اما این دو ویژگی در حمله HTTP/2 Bomb توسط مهاجم به ابزار افزایش مصرف حافظه سرور تبدیل می‌شوند. موفقیت HTTP/2 Bomb به این دلیل است که یکی از این قابلیت‌ها حافظه را تخصیص می‌دهد و دیگری مانع آزاد شدن آن می‌شود. نتیجه، انباشت تدریجی حافظه و کاهش پاسخ‌دهی سرور است.

HPACK: یک الگوریتم فشرده‌سازی وضعیت‌دار است که رشته‌های هدر را در یک جدول داینامیک ذخیره می‌کند. در درخواست‌های بعدی، به جای ارسال کامل هدر، تنها یک index ارسال می‌شود. این مکانیزم باعث کاهش سربار هدرها می‌شود، اما در ترکیب با کنترل جریان، مهاجم می‌تواند حافظه زیادی روی سرور رزرو کند.

کنترل جریان (Flow-Control Window): به گیرنده امکان می‌دهد میزان داده قابل دریافت را محدود کند. مهاجم می‌تواند با ارسال داده کم و نگه داشتن اتصال باز، حافظه رزرو شده را آزاد نکند و در نتیجه باعث افزایش مصرف حافظه، کاهش کارایی و افت پاسخ‌دهی سرور شود.

این دو مکانیزم دقیقا موتور اصلی HTTP/2 Bomb هستند. در بخش بعد، سازوکار دقیق حمله و ترکیب دو تکنیک را مرحله به مرحله بررسی می‌کنیم.

کالبدشکافی حمله؛ HTTP/2 Bomb چگونه کار می‌کند؟

هسته حمله از ترکیب دو قابلیت داخلی HTTP/2 ساخته شده است که هر یک به تنهایی برای بهبود عملکرد وب استفاده می‌شدند، اما کنار هم مسیر جدیدی برای حمله DoS ایجاد کرده‌اند.

HPACK Bomb: وقتی یک بایت به هزاران بایت تبدیل می‌شود

HPACK هدرها را در جدول داینامیک ذخیره می‌کند. مهاجم ابتدا یک هدر را ثبت و سپس هزاران بار تنها با یک index به آن ارجاع می‌دهد. حجم داده ارسالی کم است، اما سرور برای هر ارجاع باید اطلاعات مربوط به هدر را در حافظه ایجاد کند. برخلاف نسخه‌های قدیمی HPACK Bomb، حتی هدرهای کوچک یا خالی باعث مصرف حافظه قابل توجه می‌شوند. همچنین محدودیت‌های قدیمی روی حجم هدرهای Decode شده در برابر این روش بی‌اثر هستند.

Flow Control: چگونه حافظه آزاد نمی‌شود؟

کنترل جریان HTTP/2 به سرور امکان می‌دهد میزان داده قابل دریافت را محدود کند. مهاجم پس از ایجاد تخصیص حافظه، اندازه پنجره را روی صفر قرار داده و با ارسال WINDOW_UPDATE کوچک، اتصال را باز نگه می‌دارد. حافظه اشغال‌شده برای مدت طولانی باقی می‌ماند و سرور تحت فشار قرار می‌گیرد.

در یک حمله واقعی، هدف مهاجم لزوماً رساندن فرایند به وضعیت OOM (مخفف Out-of-Memory) نیست؛ وضعیتی که در آن سیستم به دلیل کمبود حافظه، برخی پردازش‌ها را به‌طور اجباری متوقف می‌کند. اگر در حالت OOM، پردازش توسط OOM Killer متوقف شود، معمولاً Worker به‌سرعت مجدداً راه‌اندازی می‌شود و بخشی از اثر حمله از بین می‌رود. راهبرد مؤثرتر این است که مصرف حافظه درست در آستانه فعال شدن OOM نگه داشته شود؛ به‌طوری که سیستم ناچار به استفاده گسترده از حافظه Swap شود. در این وضعیت، اگرچه سرویس کاملاً از دسترس خارج نمی‌شود، اما زمان پاسخ‌دهی به‌شدت افزایش می‌یابد و عملکرد سایر درخواست‌ها نیز به‌طور محسوسی کاهش پیدا می‌کند.

اثر واقعی HTTP/2 Bomb روی سرورها

HTTP/2 Bomb فقط یک ایده تئوریک نیست. محققان Calif این حمله را روی چند مورد از پرکاربردترین سرورهای وب آزمایش کرده‌اند و نتایج نشان می‌دهد که پیاده‌سازی HTTP/2 در هر محصول، تاثیر مستقیمی بر شدت حمله دارد.

نتایج این آزمایش‌ها در جدول زیر خلاصه شده است:

منظور از ضریب بزرگنمایی (Amplification Ratio) این است که هر یک بایت داده‌ای که مهاجم ارسال می‌کند، چه مقدار حافظه روی سرور اشغال می‌شود. هرچه این عدد بزرگ‌تر باشد، مهاجم با پهنای باند کمتر می‌تواند فشار بیشتری به سرور وارد کند.

نتایج آزمایش‌ها نشان می‌دهد که Envoy و Apache httpd بیشترین تاثیر را از این حمله می‌پذیرند. در سمت مقابل، nginx و Microsoft IIS ضریب بزرگنمایی کمتری دارند، اما همچنان در برابر حمله HTTP/2 Bomb آسیب‌پذیر هستند. به‌طورکلی، جلوگیری از حمله HTTP/2 Bomb نیازمند شناخت دقیق همین تفاوت‌ها در پیاده‌سازی سرورهاست.

محققان تفاوت نتایج را به جزئیات پیاده‌سازی HPACK و نحوه مدیریت حافظه در محصولات مختلف نسبت می‌دهند. در Apache httpd و Envoy، بازسازی هدرها و ساختارهای داخلی مرتبط با آن‌ها حافظه بیشتری مصرف می‌کند، در حالی که nginx و IIS سربار کمتری دارند. به همین دلیل ضریب بزرگنمایی حمله در آنها متفاوت است.

تکنیک‌های دور زدن محدودیت‌ها (Bypass Techniques)

یکی از دلایل خطرناک‌تر بودن HTTP/2 Bomb نسبت به HPACK Bomb کلاسیک، توانایی آن در دور زدن مکانیزم‌های دفاعی موجود است. در ادامه، دو تکنیک اصلی این حمله برای عبور از محدودیت‌های حجم و تعداد هدرها را بررسی می‌کنیم.

عبور از محدودیت حجم هدرها

پس از معرفی HPACK Bomb در سال ۲۰۱۶، بسیاری از پیاده‌سازی‌های HTTP/2 محدودیتی برای Total Decoded Header Size در نظر گرفتند تا از بازسازی هدرهای بسیار بزرگ جلوگیری کنند.

در HTTP/2 Bomb، هدرها می‌توانند بسیار کوچک یا تقریبا خالی باشند و بخش عمده مصرف حافظه از metadata و ساختارهای داخلی HPACK ناشی می‌شود. در نتیجه محدودیت حجم هدرهای Decode شده عملا اثرگذار نیست و دفاع طراحی‌شده برای نسخه‌های قدیمی‌تر، کارایی خود را از دست می‌دهد.

دور زدن محدودیت تعداد هدرها با Cookie Crumbs

برخی پیاده‌سازی‌ها مانند Apache httpd و Envoy علاوه بر محدودیت حجم، تعداد Header Fieldها را هم کنترل می‌کنند تا مهاجم نتواند با ارسال تعداد زیادی هدر کوچک، منابع سرور را مصرف کند.

HTTP/2 امکان تقسیم یک Cookie بزرگ به چند Cookie Header کوچک‌تر (Cookie Crumbs) را فراهم می‌کند (RFC 9113). این قابلیت برای بهبود فشرده‌سازی طراحی شده است، اما در آزمایش‌ها مشخص شد که در برخی شرایط، این Crumbها در Apache و Envoy در شمارش محدودیت تعداد هدرها لحاظ نمی‌شوند.

در نتیجه، مهاجم می‌تواند بدون فعال شدن محدودیت تعداد هدر، تعداد زیادی Cookie Crumb ایجاد کند و هر Crumb هم ورودی جدیدی در HPACK ایجاد می‌کند و سربار حافظه را افزایش می‌دهد.

وضعیت وصله‌ها در سرورهای مختلف

پس از افشای حمله HTTP/2 Bomb، مهم‌ترین سوال برای مدیران سیستم و مهندسان امنیت این است که سرورهای ما ایمن هستند؟ چه اقداماتی برای جلوگیری از حمله HTTP/2 Bomb باید انجام داد؟

محققان Calif قبل از انتشار عمومی، آسیب‌پذیری را به تیم‌های توسعه گزارش کردند. با این حال، وضعیت وصله‌ها (پچ‌ها) در زمان انتشار برای سرورهای مختلف متفاوت بود. جدول زیر خلاصه‌ای از وضعیت هر سرور را نشان می‌دهد:

راهکارهای کاهش آسیب (Mitigation Strategies)

چند اقدام موثر برای جلوگیری از حمله HTTP/2 Bomb وجود دارند که می‌توانید آن‌ها را اجرا کنید. این اقدامات را می‌توان در چند سطح اصلی اجرا کرد:

ارتقا به نسخه وصله‌شده

نصب سریع وصله‌های رسمی اولین و مهم‌ترین گام است. برای سرورهایی که وصله منتشر شده، نسخه‌ها باید به‌روزرسانی شوند:

• انجین‌اکس: نسخه 1.29.8+
• آپاچی httpd: نسخه mod_http2 v2.0.41

غیرفعال کردن موقت HTTP/2

در سرورهایی که وصله در دسترس نیست یا قصد آصب وصله را ندارید، غیرفعال کردن پروتکل HTTP/2 و بازگشت به HTTP/1.1، می‌تواند به عنوان راهکار موقت عمل کند:

استفاده از Reverse Proxy یا CDN

قرار دادن سرور پشت یک Reverse Proxy یا CDN که وصله شده یا به‌طور ذاتی محافظت دارد، می‌تواند حمله را قبل از رسیدن به سرور اصلی متوقف کند. برای مثال:

• استفاده از Cloudflare که به صورت خودکار محافظت ارائه می‌کند
• استفاده از nginx وصله‌شده به عنوان پروکسی جلوی سرورهای آسیب‌پذیر، محافظت ایجاد می‌کند.

اعمال محدودیت روی هدرها و Streamها

به‌طور کلی، «حداکثر اندازه هدرهای Decode شده» و «حداکثر تعداد هدرها» دو محدودیت متفاوت هستند و هر سرور باید هر دو را اعمال کند. هر سرویس یا مؤلفه‌ای که ترافیک HTTP/2 را دریافت و پردازش می‌کند (مانند وب‌سرورها، Reverse Proxyها، لود بالانسرها و API Gatewayها)، باید تعداد فیلدهای هدر در هر درخواست را (از جمله Cookie Crumbها) مستقل از اندازه کلی آن‌ها محدود کند. همچنین، مدت‌زمان مجاز برای باز ماندن یک stream متوقف‌شده را بدون توجه به فعالیت WINDOW_UPDATE مشخص و محدود سازد.

محدودیت حافظه (Memory Limits)

اگر در حال حاضر امکان اعمال این کنترل‌ها را ندارید، بهتر است برای هر ورکر محدودیت حافظه تعریف کنید؛ برای مثال با استفاده از cgroups، دستور ulimit -v یا محدودیت‌های حافظه در کانتینرها. این محدودیت‌ها باید به اندازه‌ای سخت‌گیرانه باشند که در صورت وقوع حمله، ورکر آسیب‌دیده پیش از آنکه کل سیستم را وارد Swap کند، توسط OOM Killer متوقف و مجدداً راه‌اندازی شود. یک ورکر معمولاً به چندین گیگابایت حافظه نیاز ندارد؛ بنابراین متوقف شدن زودهنگام یک ورکر، سناریوی بسیار بهتری نسبت به این است که مهاجم بتواند کل سرور را برای مدت طولانی در آستانه ۹۵ درصد مصرف حافظه نگه دارد.

محدودیت نرخ (Rate Limiting)

کنترل نرخ ایجاد اتصال‌ها یا استریم‌ها به ازای هر IP می‌تواند سرعت اجرای حمله را کاهش دهد و فرصت واکنش برای تیم امنیتی فراهم کند. این اقدام به تنهایی کافی نیست اما موثر است.

نقش هوش مصنوعی در کشف حمله (Codex Effect)

HTTP/2 Bomb توسط تیم امنیتی Calif با کمک OpenAI Codex شناسایی شد. در این پژوهش، Codex دو تکنیک شناخته‌شده یعنی HPACK Bomb و سوءاستفاده از HTTP/2 Flow Control را کنار هم قرار داد و اثر ترکیبی آن‌ها را آشکار کرد.

این یافته نشان می‌دهد مدل‌های هوش مصنوعی می‌توانند در تحلیل RFCها، مستندات فنی و رفتار پروتکل‌ها به کشف سناریوهای حمله جدید کمک کنند. با این حال، هوش مصنوعی در این پژوهش نقش یک ابزار کمکی برای تحلیل و کشف الگوها را داشت و جایگزین پژوهشگران امنیتی نشد.

جمع‌بندی

HTTP/2 Bomb یک آسیب‌پذیری جدید در پروتکل HTTP/2 نیست، بلکه روشی برای ترکیب دو قابلیت استاندارد این پروتکل یعنی HPACK و Flow Control است. همین موضوع باعث شد مکانیزم‌هایی که سال‌ها برای مقابله با HPACK Bomb یا محدود کردن اندازه هدرها طراحی شده بودند، در برخی پیاده‌سازی‌ها نتوانند از این حمله جلوگیری کنند.

نتایج آزمایش‌ها نشان می‌دهد شدت تأثیر HTTP/2 Bomb به نحوه پیاده‌سازی HTTP/2 در هر محصول وابسته است. هرچند nginx ،Apache httpd ،Envoy و Microsoft IIS همگی تحت تأثیر این تکنیک قرار گرفته‌اند، اما میزان مصرف حافظه و ضریب بزرگنمایی حمله در آن‌ها یکسان نیست.

برای کاهش ریسک و جلوگیری از حمله HTTP/2 Bomb، اولین اقدام باید ارتقا به نسخه‌های وصله‌شده باشد. در محیط‌هایی که امکان به‌روزرسانی فوری وجود ندارد، محدود کردن تعداد هدرها، کنترل طول عمر Streamها، اعمال محدودیت حافظه برای Workerها و استفاده از Reverse Proxyها یا CDNهای محافظت‌شده می‌تواند اثر حمله را کاهش دهد.

شاید مهم‌ترین درس HTTP/2 Bomb این باشد که در امنیت نرم‌افزارها، همیشه مشکل از یک قابلیت منفرد نیست. گاهی ترکیب چند رفتار کاملاً استاندارد و قانونی می‌تواند به یک روش حمله جدید تبدیل شود که سال‌ها از دید پژوهشگران پنهان مانده است.

The post حمله HTTP/2 Bomb چیست؟ کالبدشکافی حمله، تأثیر بر nginx و راهکارهای مقابله appeared first on بلاگ هم‌روش.

ابزار Wiki.js چیست و چه ویژگی‌هایی دارد؟

Wiki.js یک نرم‌افزار ویکی سازمانی متن‌باز و Self-Hosted است که برای مدیریت دانش، مستندسازی سازمانی و ایجاد ویکی داخلی سازمان استفاده می‌شود. این پلتفرم بر پایه Node.js توسعه یافته و از دیتابیس PostgreSQL برای ذخیره‌سازی داده‌ها استفاده می‌کند.

سازمان‌ها می‌توانند Wiki.js را روی سرور اختصاصی، ماشین مجازی یا کانتینرهای Docker اجرا کنند و مدیریت مستندات، دسترسی کاربران و زیرساخت نرم‌افزار را در محیط خود انجام دهند. همچنین این پلتفرم از روش‌های مختلف احراز هویت، ویرایش محتوا و یکپارچه‌سازی با ابزارهای توسعه، پشتیبانی می‌کند. برخی از قابلیت‌های اصلی Wiki.js عبارت‌اند از:

• ویرایشگرهای چندگانه: پشتیبانی از Markdown، ویرایشگر بصری (WYSIWYG) و HTML برای گروه‌های مختلف کاربران
• همگام‌سازی با Git: امکان اتصال به مخازن Git برای نسخه‌بندی و نگهداری مستندات
• احراز هویت سازمانی: پشتیبانی از LDAP ،SAML و OAuth2 برای مدیریت دسترسی کاربران
• معماری ماژولار: امکان فعال یا غیرفعال کردن ماژول‌های مختلف بر اساس نیاز سازمان

چرا شرکت‌ها به Wiki داخلی نیاز دارند؟

ویکی داخلی سازمان ابزاری برای ثبت و نگهداری دانش سازمانی، مستندات فنی و فرایندهای کاری است. استفاده از این ابزارها به تیم‌ها کمک می‌کند دانش و مستندات سازمانی به افراد وابسته نباشد و در یک پایگاه دانش متمرکز نگهداری شود. رایج‌ترین کاربردهای یک نرم‌افزار ویکی سازمانی عبارت‌اند از:

• ثبت Runbookها و دستورالعمل‌های عملیاتی برای عیب‌یابی و مدیریت رخدادها
• مستندسازی معماری سیستم، سرویس‌ها، تنظیمات و فرایندهای فنی
• تسهیل فرایند آنبوردینگ نیروهای جدید از طریق دسترسی به مستندات متمرکز
• مدیریت سیاست‌ها، رویه‌ها و سطوح دسترسی در بخش‌های مختلف سازمان

مزایای Wiki.js چیست؟

ابزار Wiki.js به‌عنوان یک نرم‌افزار ویکی سازمانی، امکانات موردنیاز تیم‌های فنی و کاربران غیرفنی را در یک پلتفرم واحد ارائه می‌کند. بررسی مزایای زیر به خوبی نشان می‌دهد که دلیل محبوبیت ویکی جی اس چیست:

• ویرایشگرهای چندگانه: Wiki.js از Markdown، ویرایشگر بصری (WYSIWYG) و HTML پشتیبانی می‌کند. این موضوع باعث می‌شود کاربران فنی و غیرفنی بتوانند با روش موردنظر خود مستندات را ایجاد و ویرایش کنند.
• همگام‌سازی با Git: امکان اتصال به مخازن GitHub و GitLab برای نسخه‌بندی و نگهداری مستندات فراهم است. این قابلیت به تیم‌های فنی کمک می‌کند تاریخچه تغییرات مستندات را مدیریت کنند، از محتوا نسخه پشتیبان داشته باشند و در صورت نیاز، مستندات را بین زیرساخت‌ها یا محیط‌های مختلف جابه‌جا کنند.
• احراز هویت سازمانی: Wiki.js از LDAP ،SAML ،OAuth2 و احراز هویت دو عاملی (2FA) پشتیبانی می‌کند و امکان یکپارچه‌سازی با زیرساخت‌های هویتی سازمان را فراهم می‌کند.
• نصب و استقرار ساده: نصب Wiki.js با Docker و Docker Compose به‌سادگی انجام می‌شود و فرایند راه‌اندازی آن روی بسیاری از محیط‌های لینوکسی از جمله نصب Wiki.js روی Ubuntu هم پیچیدگی زیادی ندارد.
• عملکرد سبک: این پلتفرم بر پایه Node.js توسعه یافته و برای اجرا به منابع سخت‌افزاری محدودی نیاز دارد.
• پشتیبانی از دیاگرام و مستندات فنی: امکان استفاده از ابزارهایی مانند draw.io ،Mermaid و PlantUML برای ایجاد فلوچارت‌ها، نمودارها و مستندات معماری وجود دارد.
• معماری ماژولار: مدیر سیستم می‌تواند برخی قابلیت‌ها و ماژول‌ها را بر اساس نیاز سازمان فعال یا غیرفعال کند.
• پشتیبانی از زبان‌های مختلف و RTL: ویکی جی اس از زبان‌های مختلف پشتیبانی می‌کند و با زبان‌های راست‌به‌چپ نیز سازگار است. این قابلیت برای ایجاد یک ویکی داخلی سازمان به زبان فارسی کاربردی است.
• مدیریت دسترسی: امکان تعریف سطوح دسترسی مبتنی بر گروه‌ها و مسیر صفحات (Path-based Permissions) برای کنترل دسترسی کاربران وجود دارد.
• موتور جستجو: سیستم جستجوی داخلی مبتنی بر PostgreSQL امکان جستجوی متن کامل در مستندات را فراهم می‌کند و در برخی سناریوها قابلیت استفاده از Elasticsearch نیز وجود دارد.
• شخصی‌سازی و چندسکویی: این ابزار از حالت روشن و تاریک پشتیبانی می‌کند و امکان استفاده از CSS و JavaScript سفارشی را در اختیار مدیران قرار می‌دهد. همچنین روی لینوکس، ویندوز و macOS قابل اجرا است.

معایب ویکی جی اس چیست؟

برای انتخاب هوشمندانه یک نرم‌افزار، شناخت مزایا کافی نیست و باید بدانید چالش‌ها و معایب Wiki.js چیست. مهم‌ترین نقاط ضعف این ابزار عبارتند از:

• وضعیت نسخه v3: توسعه نسخه سوم Wiki.js طی چند سال گذشته ادامه داشته است، اما تا سال ۲۰۲۶ نسخه v2 همچنان نسخه اصلی و پایدار محسوب می‌شود. به همین دلیل بهتر است ارزیابی فنی بر اساس قابلیت‌های موجود انجام شود.
• عدم پشتیبانی از ویرایش هم‌زمان: Wiki.js قابلیت ویرایش هم‌زمان یک صفحه توسط چند کاربر را مشابه ابزارهایی مانند Confluence یا Google Docs ارائه نمی‌کند.
• وابستگی به PostgreSQL: هرچند پشتیبانی از چند پایگاه داده در برخی بخش‌ها مطرح شده است، اما PostgreSQL همچنان مهم‌ترین و رایج‌ترین گزینه برای استفاده از قابلیت‌های اصلی پلتفرم محسوب می‌شود.
• برخی قابلیت‌های محدود یا در حال توسعه: بخش‌هایی مانند سیستم نظرات یا برخی قابلیت‌های ویرایشگر بصری ممکن است نسبت به برخی رقبا امکانات کمتری در اختیار کاربران قرار دهند.
• نبود سیستم Template داخلی: برای ساخت صفحات تکرارشونده، قابلیت قالب‌سازی داخلی محدودی وجود دارد و در برخی سناریوها لازم است ساختار صفحات به‌صورت دستی ایجاد شود.
• منحنی یادگیری API: رابط برنامه‌نویسی کاربردی (API) مبتنی بر GraphQL انعطاف‌پذیری بالایی ارائه می‌دهد، اما ممکن است برای تیم‌هایی که تجربه کار با GraphQL ندارند به زمان بیشتری برای یادگیری نیاز داشته باشد.

مقایسه Wiki.js با Confluence ،BookStack و MediaWiki

انتخاب ابزار مناسب برای مستندسازی سازمانی بستگی به نیازهای فنی، ساختار تیم، بودجه و نحوه استقرار زیرساخت دارد. برای درک بهتر اینکه تفاوت Wiki.js با سایر راهکارهای مطرح چیست، می‌توان آن را در کنار Confluence ،BookStack و MediaWiki بررسی کرد.

کانفلوئنس یک پلتفرم تجاری است که به‌صورت گسترده در سازمان‌ها برای همکاری تیمی، مدیریت دانش و مستندسازی استفاده می‌شود. در سمت مقابل، Wiki.js به‌عنوان یک نرم‌افزار ویکی سازمانی متن‌باز، امکان استقرار روی زیرساخت اختصاصی سازمان را فراهم می‌کند و هزینه لایسنس ندارد.

BookStack هم یک راهکار متن‌باز برای مستندسازی سازمانی است که از ساختار سلسله‌مراتبی مشخص (قفسه، کتاب، فصل و صفحه) استفاده می‌کند. این ساختار برای تیم‌هایی که به دنبال سازمان‌دهی ساده‌تر محتوا هستند می‌تواند مناسب باشد.

MediaWiki که هسته اصلی ویکی‌پدیا را تشکیل می‌دهد، برای مدیریت پایگاه‌های دانش بزرگ و محتوای مشارکتی توسعه یافته است. در مقابل، Wiki.js تمرکز بیشتری بر استقرار سازمانی، یکپارچه‌سازی با Git و پشتیبانی از روش‌های مختلف احراز هویت دارد. برای مقایسه دقیق‌تر، فاکتورهای کلیدی این چهار ابزار در جدول زیر آورده شده است.

راهنمای نصب Wiki.js با Docker

استفاده از Docker و Docker Compose، یکی از رایج‌ترین روش‌ها برای راه‌اندازی Wiki.js به شمار می‌آید. این روش روی اکثر توزیع‌های لینوکس (مخصوصا برای نصب Wiki.js روی Ubuntu Server)، بسیار رایج و پایدار است. البته قبل از هرکاری باید پیش‌نیازهای زیر را فراهم کنید:

• سرور لینوکس با نصب Docker و Docker Compose نصب‌شده. می‌توانید راهنمای آموزش نصب داکر و نصب Docker Compose استفاده کنید.
• حداقل ۱ گیگابایت رم (۲ گیگابایت توصیه می‌شود).
• دامنه اختصاصی برای دسترسی در محیط پروداکشن (اختیاری).
• یک مخزن Git برای همگام‌سازی محتوا (اختیاری).

گام اول: ایجاد ساختار پوشه پروژه

ابتدا باید پوشه‌های مورد نیاز را برای ماندگاری داده‌های دیتابیس (Data Persist) ایجاد کنید و وارد آن شوید:

mkdir -p ~/wikijs/{db,config}

cd ~/wikijs

mkdir -p ~/wikijs/{db,config}

cd ~/wikijs

گام دوم: ایجاد فایل docker-compose.yml

یک فایل با نام docker-compose.yml در همان پوشه بسازید و کانفیگ زیر را در آن قرار دهید:

version: "3.8"
services:
  db:
    image: postgres:16-alpine
    container_name: wikijs-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: wikijs
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: YOUR_STRONG_PASSWORD
    volumes:
      - ./db:/var/lib/postgresql/data
    networks:
      - wikijs-net
  wikijs:
    image: ghcr.io/requarks/wiki:2
    container_name: wikijs
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "3000:3000"
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: YOUR_STRONG_PASSWORD
      DB_NAME: wikijs
    networks:
      - wikijs-net
networks:
  wikijs-net:
    driver: bridge

version: "3.8"
services:
  db:
    image: postgres:16-alpine
    container_name: wikijs-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: wikijs
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: YOUR_STRONG_PASSWORD
    volumes:
      - ./db:/var/lib/postgresql/data
    networks:
      - wikijs-net
  wikijs:
    image: ghcr.io/requarks/wiki:2
    container_name: wikijs
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "3000:3000"
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: YOUR_STRONG_PASSWORD
      DB_NAME: wikijs
    networks:
      - wikijs-net
networks:
  wikijs-net:
    driver: bridge

حتما مقدار YOUR_STRONG_PASSWORD را با یک رمز عبور مناسب جایگزین کنید. این مقدار باید در تنظیمات PostgreSQL و Wiki.js یکسان باشد تا اتصال به دیتابیس برقرار شود. همچنین مراقب باشید که فاصله‌ها و ساختار خطوط در فایل YAML تغییر نکند.

گام سوم: اجرا و بررسی لاگ‌ها

برای بالا آوردن کانتینرها در پس‌زمینه، دستور زیر را اجرا کنید:

docker compose up -d

docker compose up -d

برای بررسی وضعیت سرویس، لاگ‌ها را مشاهده کنید

docker compose logs -f wikijs

docker compose logs -f wikijs

در صورت مشاهده پیام “Listening on port 3000″، سرویس با موفقیت راه‌اندازی شده است. سپس می‌توانید آدرس زیر را در مرورگر باز کنید:

http://<SERVER-IP>:3000

در اولین ورود، صفحه راه‌اندازی اولیه Wiki.js نمایش داده می‌شود.

گام چهارم: تنظیم اولیه (Setup Wizard)

در اولین ورود، صفحه راه‌اندازی اولیه ظاهر می‌شود که اطلاعات زیر را از شما می‌خواهد:

• Administrator Account: ایمیل و رمز عبور مدیر ارشد سیستم را تعیین کنید.
• Site URL: آدرس نهایی دسترسی به ویکی را وارد کنید (مانند (https://wiki.your-domain.com ).
• Telemetry: وضعیت ارسال آمار ناشناس استفاده از ابزار را مشخص کنید.

پس از تکمیل این فرم، به‌طور مستقیم وارد داشبورد مدیریت می‌شوید.

نکته: اگر Wiki.js را در محیط پروداکشن اجرا می‌کنید، بهتر است سرویس را پشت یک Reverse Proxy مانند Nginx یا Traefik قرار دهید. این روش امکان مدیریت گواهی SSL، استفاده از دامنه اختصاصی، هدایت ترافیک HTTPS و اعمال تنظیمات امنیتی را فراهم می‌کند. هرچند Wiki.js به‌صورت مستقیم روی پورت ۳۰۰۰ اجرا می‌شود، اما در بسیاری از استقرارهای سازمانی دسترسی کاربران از طریق Reverse Proxy انجام می‌شود. 

گام پنجم: تنظیم همگام‌سازی با Git 

همگام‌سازی با Git (یا Git Sync) یکی از قابلیت‌های Wiki.js برای نسخه‌بندی و نگهداری مستندات در مخازن Git است. این قابلیت امکان مدیریت تاریخچه تغییرات، نگهداری نسخه‌های قبلی و بکاپ‌گیری از محتوای صفحات را فراهم می‌کند. برای فعال‌سازی این قابلیت مراحل زیر را انجام دهید:

مرحله اول: به مسیر Administration > Storage بروید.

مرحله دوم: روی گزینه Git کلیک کرده و آن را فعال کنید.

مرحله سوم: تنظیمات مخزن را در Wiki.js وارد کنید:

Authentication Type: SSH
Repository URL: git@github.com:your-org/wiki-content.git
Branch: main
SSH Private Key: (Deploy Key)
Sync Direction: Bi-directional
Sync Schedule: Every 5 minutes

Authentication Type: SSH
Repository URL: git@github.com:your-org/wiki-content.git
Branch: main
SSH Private Key: (Deploy Key)
Sync Direction: Bi-directional
Sync Schedule: Every 5 minutes

بازه زمانی همگام‌سازی را تنظیم کنید (مثلا هر ۵ دقیقه).

مرحله چهارم: یک Deploy Key ایجاد کنید:

ssh-keygen -t ed25519 -f ~/wikijs/git-deploy-key -N ""

ssh-keygen -t ed25519 -f ~/wikijs/git-deploy-key -N ""

مرحله پنجم: کلید عمومی ایجادشده را به‌عنوان Deploy Key در مخزن GitHub یا GitLab خود و با دسترسی write اضافه کنید.

نکته: همگام‌سازی با Git می‌تواند نسخه‌ای از محتوای صفحات را در مخزن Git نگهداری کند، اما جایگزین بکاپ کامل Wiki.js نیست. از آنجا که اطلاعات اصلی پلتفرم در PostgreSQL ذخیره می‌شوند، توصیه می‌شود به‌صورت منظم از پایگاه داده و فایل‌های پیوست نسخه پشتیبان تهیه کنید. در محیط‌های عملیاتی، استفاده از بکاپ خودکار برای دیتابیس و فضای ذخیره‌سازی می‌تواند ریسک از دست رفتن اطلاعات را کاهش دهد.

گام آخر: به‌روزرسانی Wiki.js

برای آپدیت پلتفرم به آخرین نسخه پایدار، کافیست کانتینرها را مجدداً Pull کنید تا فرایند مهاجرت دیتابیس (Migration) هم به طور خودکار انجام شود:

docker compose pull wikijs
docker compose up -d wikijs

docker compose pull wikijs
docker compose up -d wikijs

اجرای Wiki.js روی Cloud

با افزایش تعداد کاربران، حجم مستندات و نیازهای عملیاتی، معمولا نگهداری Wiki.js روی یک سرور واحد، چالش‌هایی مانند مدیریت بکاپ، به‌روزرسانی، دسترس‌پذیری و مقیاس‌پذیری را ایجاد کند. بسیاری از سازمان‌ها برای اینکه با این چالش‌ها مواجه نشوند، این پلتفرم را روی زیرساخت‌های ابری اجرا می‌کنند تا بخشی از مدیریت زیرساخت و نگهداری سرویس ساده‌تر شود. معمولا برای استقرار Wiki.js در محیط ابری از دو الگوی رایج استفاده می‌شود:

راه‌اندازی روی سکوهای ابری (PaaS)

در این سناریو، نیازی به مدیریت سیستم‌عامل لینوکس یا پیکربندی دستی Docker ندارید و می‌توانید با استفاده از ایمیج رسمی Wiki.js، سرویس را روی سکوی ابری مستقر کنید. همچنین برخی سکوهای ابری هم قابلیت‌هایی مانند مقیاس‌پذیری خودکار را در اختیار شما قرار می‌دهند.

معماری ابری مدیریت‌شده (Managed Services)

برای تضمین امنیت و پایداری در محیط‌های پروداکشن، پلتفرم ابری خود را بر پایه فاکتورهای زیر پیکربندی کنید:

• دیتابیس ابری مدیریت‌شده (Managed PostgreSQL): به‌جای اجرای PostgreSQL درون کانتینر، می‌توانید Wiki.js را به یک سرویس دیتابیس مدیریت‌شده متصل کنید تا مدیریت بکاپ، به‌روزرسانی و نگهداری پایگاه داده ساده‌تر شود.
• ذخیره‌سازی ابری فایل‌ها (Object Storage): می‌توانید از طریق مسیر `Administration > Storage` سرویس‌های ذخیره‌سازی سازگار با S3 را برای نگهداری تصاویر و فایل‌های پیوست مستندات پیکربندی کنید.
• همگام‌سازی با Git: اتصال Wiki.js به مخازن GitHub یا GitLab، امکان نسخه‌بندی و نگهداری مستندات در یک مخزن مجزا را فراهم می‌کند.

راه‌اندازی Wiki.js بدون مدیریت زیرساخت

برای راه‌اندازی سریع‌تر Wiki.js، می‌توانید از نسخه آماده این نرم‌افزار در بازارچه هم‌روش استفاده کنید. در این روش، نصب Docker، استقرار و به‌روزرسانی سرویس و بخشی از مدیریت زیرساخت به‌صورت خودکار انجام می‌شود تا تیم‌ها بتوانند به‌جای صرف زمان برای پیکربندی و نگهداری، روی تولید و مدیریت مستندات تمرکز کنند.

چه سروری برای Wiki.js مناسب است؟

نیازمندی‌های Wiki.js به تعداد کاربران، حجم مستندات و نحوه استفاده از پلتفرم بستگی دارد. در این بخش از آموزش Wiki.js، مهم‌ترین نیازمندی‌های سخت‌افزاری و نرم‌افزاری این نرم‌افزار ویکی سازمانی را بررسی می‌کنیم.

نیازمندی‌های سخت‌افزاری (Hardware)

میزان مصرف منابع در Wiki.js به تعداد کاربران هم‌زمان، حجم داده‌ها و سرویس‌های جانبی مورد استفاده بستگی دارد. برای بسیاری از سناریوهای سازمانی، منابع زیر قابل استفاده هستند:

• پردازنده (CPU): ویکی جی اس روی یک هسته پردازنده هم  قابل اجرا است، اما برای پردازش‌های پس‌زمینه و بارهای کاری بیشتر، استفاده از حداقل دو هسته CPU توصیه می‌شود.
• حافظه رم (RAM): حداقل ۱ گیگابایت رم برای اجرا موردنیاز است. البته در سناریوهای عملیاتی و استفاده طولانی‌مدت، تخصیص رم بیشتر می‌تواند پایداری و عملکرد بهتری فراهم کند.
• فضای ذخیره‌سازی (Storage): حجم موردنیاز به تعداد مستندات و فایل‌های بارگذاری‌شده بستگی دارد. برای راه‌اندازی اولیه، استفاده از فضای ذخیره‌سازی SSD توصیه می‌شود.

نیازمندی‌های نرم‌افزاری و شبکه (Software & Network)

علاوه بر سخت‌افزار، باید زیرساخت نرم‌افزاری هم با نیازهای Wiki.js سازگار باشد.

• پایگاه داده: استفاده از دیتابیس PostgreSQL نسخه 11 یا بالاتر الزامی است، زیرا تمرکز اصلی توسعه نسخه‌های جدید Wiki.js روی PostgreSQL قرار دارد و این دیتابیس، انتخاب استاندارد و پایدار این پلتفرم محسوب می‌شود.
• محیط اجرا (Runtime): این پلتفرم بر پایه Node.js توسعه یافته است، اما در صورت استفاده از Docker نیازی به نصب مستقیم Node.js روی سرور خود ندارید. در واقع این پلتفرم به صورت پیش‌فرض درون ایمیج داکر قرار دارد.
• وب‌سرور و شبکه: Wiki.js می‌تواند بدون Nginx یا Apache اجرا شود، اما در بسیاری از محیط‌های پروداکشن از Reverse Proxy برای مدیریت SSL، مسیریابی درخواست‌ها و تنظیمات شبکه استفاده می‌شود. همچنین استفاده از یک دامنه یا زیر دامنه اختصاصی برای استقرار ویکی داخلی سازمان، مدیریت و دسترسی به سرویس را ساده‌تر می‌کند.

جمع‌بندی

اگر به دنبال یک سیستم مستندسازی self-hosted هستید که هم با Git یکپارچه شود و هم روی زیرساخت اختصاصی شما اجرا شود، Wiki.js یکی از گزینه‌های جدی پیش‌رو است. Wiki.js در عمل بین دو نیاز مهم تعادل ایجاد می‌کند: از یک طرف سادگی استقرار و استفاده (به‌خصوص با Docker) و از طرف دیگر امکانات فنی مثل همگام‌سازی با گیت، احراز هویت سازمانی و کنترل دسترسی دقیق. به همین دلیل برای تیم‌های DevOps، تیم‌های توسعه نرم‌افزار و سازمان‌هایی که رویکرد زیرساخت‌محور دارند، انتخاب مناسبی محسوب می‌شود.

با این حال، این ابزار برای سناریوهایی که نیاز به همکاری هم‌زمان پیشرفته، جریان‌های کاری پیچیده یا اکوسیستم یکپارچه سازمانی (در حد ابزارهایی مثل Confluence) دارند، ممکن است محدودیت‌هایی داشته باشد. بنابراین انتخاب Wiki.js زمانی منطقی است که اولویت شما «کنترل، سادگی زیرساخت و انعطاف‌پذیری» باشد، نه یک پلتفرم کاملاً enterprise با همه امکانات همکاری بلادرنگ.

The post Wiki.js چیست؟ مقایسه با رقبا و راهنمای نصب appeared first on بلاگ هم‌روش.

RBAC در کوبرنتیز چیست؟

RBAC مخفف Role-Based Access Control یا «کنترل دسترسی مبتنی بر نقش» است. این مکانیزم امنیتی در کوبرنتیز مشخص می‌کند که هر کاربر، سرویس یا برنامه چه عملیاتی را روی کدام منابع کلاستر می‌تواند انجام دهد.

در کوبرنتیز، تمام درخواست‌ها از طریق API Server پردازش می‌شوند و سیستم RBAC کوبرنتیز وظیفه دارد سطح دسترسی این درخواست‌ها را کنترل کند. به‌کمک این مکانیزم می‌توان تعیین کرد که یک هویت مشخص چه منابعی را مشاهده کند، چه عملیاتی انجام دهد و این دسترسی در کدام Namespace یا در سطح کل کلاستر معتبر باشد. برای مثال، با استفاده از RBAC در کوبرنتیز می‌توان به یک توسعه‌دهنده فقط اجازه مشاهده Podها در Namespace توسعه (Dev) را داد؛ بدون اینکه به منابع محیط Production دسترسی داشته باشد.

سیستم RBAC کوبرنتیز فقط برای کاربران انسانی استفاده نمی‌شود و برنامه‌ها و Podهای داخل کلاستر نیز از طریق Service Accountها با همین مکانیزم احراز دسترسی می‌شوند.

به‌طور کلی، RBAC استانداردترین روش مدیریت دسترسی کاربران در کوبرنتیز است و نقش مهمی در پیاده‌سازی اصل Least Privilege یا «حداقل سطح دسترسی» دارد.

تفاوت Authentication و Authorization در Kubernetes

برای درک جایگاه RBAC در کوبرنتیز، ابتدا باید تفاوت Authentication (احراز هویت) و Authorization (تعیین سطح دسترسی) را بدانید. هر درخواستی که به API Server کلاستر ارسال می‌شود، ابتدا هویت فرستنده را بررسی می‌کند و سپس سطح دسترسی او را می‌سنجد.

مرحله اول، Authentication: کوبرنتیز مشخص می‌کند درخواست از طرف چه کاربری، سرویس یا برنامه‌ای ارسال شده است. این فرایند معمولاً با استفاده از توکن‌ها، Client Certificateها یا سرویس‌های هویت خارجی انجام می‌شود. اگر هویت فرستنده تأیید نشود، درخواست با خطای HTTP 401 Unauthorized رد خواهد شد.

مرحله دوم، Authorization: پس از تأیید هویت، مرحله Authorization یا آغاز می‌شود. در این مرحله، کوبرنتیز بررسی می‌کند که آیا این هویت، اجازه انجام عملیات موردنظر را دارد یا خیر. اینجاست که RBAC کوبرنتیز وارد عمل می‌شود و بر اساس Roleها و Bindingهای تعریف‌شده، مجوز دسترسی را صادر یا رد می‌کند. در صورت نداشتن مجوز کافی، درخواست با خطای HTTP 403 Forbidden مواجه می‌شود.

برای درک بهتر تفاوت این دو لایه امنیتی، جدول زیر را ببینید:

اجزای اصلی RBAC در کوبرنتیز

سیستم RBAC در کوبرنتیز از چند جزء اصلی تشکیل شده است که در کنار هم مشخص می‌کنند چه هویتی چه عملیاتی را روی کدام منابع می‌تواند انجام دهد. این اجزا عبارت‌اند از:

Role

Role مجموعه‌ای از مجوزهاست که دسترسی به منابع را در یک Namespace در کوبرنتیز تعریف می‌کند. با استفاده از Role می‌توان مشخص کرد که یک کاربر یا Service Account چه عملیاتی را روی منابع کوبرنتیز انجام دهد.

ClusterRole

ClusterRole نیز مجموعه‌ای از مجوزها را تعریف می‌کند، اما در سطح کل کلاستر قابل استفاده است و محدود به یک Namespace مشخص نیست.

RoleBinding

RoleBinding یک Role را به یک کاربر، گروه یا Service Account متصل می‌کند. این اتصال فقط در همان Namespace معتبر است و مشخص می‌کند چه هویتی از مجوزهای تعریف‌شده در Role استفاده کند.

ClusterRoleBinding

ClusterRoleBinding یک ClusterRole را در سطح کل کلاستر به کاربران، گروه‌ها یا Service Accountها متصل می‌کند. این نوع Binding معمولاً برای دسترسی‌های سراسری استفاده می‌شود.

Subjects

Subjects همان هویت‌هایی هستند که مجوزها به آن‌ها اختصاص داده می‌شود. این هویت‌ها می‌توانند کاربران، گروه‌ها یا Service Accountهای داخل کلاستر باشند.

در تنظیمات RBAC کوبرنتیز، هر Role یا ClusterRole معمولاً شامل فیلدهایی برای تعیین منابع و نوع دسترسی است. برای مثال، فیلد verbs مشخص می‌کند یک هویت چه عملیاتی مانند get ،list ،create یا delete را می‌تواند انجام دهد.

همچنین فیلد apiGroups برای تعیین گروه API مربوط به هر منبع استفاده می‌شود. در منابع اصلی کوبرنتیز مانند Pod و Service معمولاً مقدار آن به‌صورت رشته خالی "" نوشته می‌شود، اما برای منابعی مانند Deployment در کوبرنتیز از گروه‌هایی مانند apps استفاده می‌شود.

تفاوت Role و ClusterRole؛ مرز میان Namespace و کلاستر

اصلی‌ترین تفاوت Role و ClusterRole در Kubernetes، محدوده دسترسی یا Scope آن‌هاست. Role فقط در یک Namespace مشخص معتبر است و مجوزهای تعریف‌شده در آن خارج از همان Namespace اعمال نمی‌شوند. برای مثال، اگر کاربری در Namespace مربوط به محیط توسعه (dev) اجازه مشاهده پادها را داشته باشد، این دسترسی در Namespace محیط Production معتبر نخواهد بود.

در مقابل، ClusterRole در سطح کل کلاستر عمل می‌کند و به یک Namespace محدود نیست. این نوع Role معمولاً برای منابعی استفاده می‌شود که وابسته به Namespace نیستند؛ مانند نودها یا PersistentVolumeها. همچنین می‌توان از ClusterRole برای تعریف دسترسی‌های یکسان در چند Namespace مختلف استفاده کرد.

در عمل، Role و RoleBinding بیشتر برای مدیریت دسترسی‌های محدود در یک Namespace استفاده می‌شوند، درحالی‌که ClusterRole و ClusterRoleBinding برای دسترسی‌های سراسری در سطح کلاستر کاربرد دارند.

نحوه عملکرد RBAC در Kubernetes

سیستم RBAC در کوبرنتیز برای بررسی دسترسی‌ها، هر درخواست را به‌صورت مرحله‌به‌مرحله ارزیابی می‌کند. زمانی که یک کاربر، Service Account یا برنامه درخواستی را به API Server ارسال می‌کند، کوبرنتیز مراحل زیر را برای تصمیم‌گیری طی می‌کند:

گام ۱: شناسایی هویت درخواست‌کننده

در ابتدا کوبرنتیز مشخص می‌کند درخواست از طرف چه هویتی ارسال شده است. این هویت می‌تواند یک کاربر، گروه یا Service Account باشد.

گام ۲: بررسی Rol‍eها و ClusterRoleها

پس از شناسایی هویت، کوبرنتیز Roleها و ClusterRoleهای تعریف‌شده را بررسی می‌کند تا مشخص شود چه مجوزهایی برای آن هویت وجود دارد.

گام ۳: بررسی Bindingها

در ادامه، کوبرنتیز بررسی می‌کند که آیا Role یا ClusterRole موردنظر از طریق RoleBinding یا ClusterRoleBinding به آن کاربر یا Service Account متصل شده است یا خیر.

گام ۴: تطبیق درخواست با مجوزها

در این مرحله، کوبرنتیز نوع عملیات درخواستی (مانند get ،list یا delete) و منبع هدف (مانند Pod یا Service) را با قوانین تعریف‌شده در RBAC تطبیق می‌دهد.

گام ۵: صدور نتیجه نهایی

اگر مجوز لازم وجود داشته باشد، درخواست تأیید می‌شود و کاربر به منبع موردنظر دسترسی پیدا می‌کند. در غیر این صورت، کوبرنتیز درخواست را با خطای 403 Forbidden رد می‌کند.

آموزش عملی پیاده‌سازی RBAC در کوبرنتیز (به همراه کد)

در این مثال، یک Service Account ایجاد می‌کنیم که فقط اجازه مشاهده Serviceها و ConfigMapها را در یک Namespace مشخص داشته باشد.

گام ۱: ایجاد Namespace و Service Account

ابتدا یک Namespace و سپس یک Service Account اختصاصی ایجاد می‌کنیم:

kubectl create namespace random-numbers
kubectl create sa random-numbers-sa -n random-numbers

kubectl create namespace random-numbers
kubectl create sa random-numbers-sa -n random-numbers

گام ۲: تعریف Role

در این مرحله، یک Role در فایلی به نام فایل به نام role.yaml می‌سازیم که فقط دسترسی get و list را روی Serviceها و ConfigMapها داشته باشد.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: random-numbers
  name: client-access-role
rules:
- apiGroups: [""]
  resources:
    - configmaps
    - services
  verbs:
    - get
    - list

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: random-numbers
  name: client-access-role
rules:
- apiGroups: [""]
  resources:
    - configmaps
    - services
  verbs:
    - get
    - list

برای اعمال این Role روی کلاستر، دستور زیر را اجرا کنید:

kubectl apply -f role.yaml

kubectl apply -f role.yaml

گام ۳: ایجاد RoleBinding

اکنون باید Role تعریف‌شده را به Service Account متصل کنیم. فایل yaml زیر با نام rolebinding.yaml را ایجاد کنید:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: client-access-role-binding
  namespace: random-numbers
subjects:
- kind: ServiceAccount
  name: random-numbers-sa
  namespace: random-numbers
roleRef:
  kind: Role
  name: client-access-role
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: client-access-role-binding
  namespace: random-numbers
subjects:
- kind: ServiceAccount
  name: random-numbers-sa
  namespace: random-numbers
roleRef:
  kind: Role
  name: client-access-role
  apiGroup: rbac.authorization.k8s.io

برای اعمال RoleBinding دستور زیر را اجرا کنید:

kubectl apply -f rolebinding.yaml

kubectl apply -f rolebinding.yaml

گام ۴: راه‌اندازی پاد تست با سرویس‌اکانت اختصاصی

در ادامه یک پاد می‌سازیم تا بتوانیم درخواست‌های امنیتی را از داخل کلاستر تست کنیم. برای انجام این کار فایلی به نام pod-test.yaml بسازید و کد زیر را در آن قرار دهید:

apiVersion: v1
kind: Pod
metadata:
  name: curlo
  namespace: random-numbers
spec:
  serviceAccountName: random-numbers-sa
  containers:
  - name: curlo
    image: curlimages/curl
    command: ["sleep","999999"]

apiVersion: v1
kind: Pod
metadata:
  name: curlo
  namespace: random-numbers
spec:
  serviceAccountName: random-numbers-sa
  containers:
  - name: curlo
    image: curlimages/curl
    command: ["sleep","999999"]

پاد را اجرا کنید:

kubectl apply -f pod-test.yaml

kubectl apply -f pod-test.yaml

گام ۵: بررسی سطح دسترسی

ابتدا وارد Pod شوید:

kubectl exec -it curlo -n random-numbers -- /bin/sh

kubectl exec -it curlo -n random-numbers -- /bin/sh

سپس توکن Service Account را برای ارسال درخواست به API Server تنظیم کنید:

export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

آزمایش اول: بررسی دسترسی مجاز (مشاهده سرویس‌ها)

یک درخواست به آدرس API سرویس‌های این Namespace می‌فرستیم:

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/services

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/services

در صورت موفقیت، Kubernetes اطلاعات Serviceها را با پاسخ 200 OK برمی‌گرداند.

آزمایش دوم: بررسی دسترسی غیرمجاز

اکنون درخواست مشاهده Podها را ارسال می‌کنیم:

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/pods

curl -k --header "Authorization: Bearer $TOKEN" \
https://kubernetes.default.svc/api/v1/namespaces/random-numbers/pods

چون در Role تعریف‌شده مجوز دسترسی به Podها وجود ندارد، Kubernetes پاسخ 403 Forbidden را برمی‌گرداند:

{
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:random-numbers:random-numbers-sa\" cannot list resource \"pods\" in the namespace \"random-numbers\"",
  "reason": "Forbidden",
  "code": 403
}

{
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:random-numbers:random-numbers-sa\" cannot list resource \"pods\" in the namespace \"random-numbers\"",
  "reason": "Forbidden",
  "code": 403
}

بهترین روش‌ها (Best Practices) برای پیاده‌سازی RBAC

پیاده‌سازی صحیح RBAC در کوبرنتیز نقش مهمی در کاهش ریسک‌های امنیتی و کنترل دسترسی کاربران دارد. مهم‌ترین راهکارهای این حوزه عبارت‌اند از:

اصل حداقل دسترسی (Least Privilege)

دسترسی‌ها باید فقط بر اساس نیاز واقعی کاربران و سرویس‌ها تعریف شوند. بهتر است از اعطای مجوزهای گسترده یا استفاده از وایلدکارد * در بخش منابع و عملیات‌ها خودداری شود.

استفاده از Role و RoleBinding در سطح Namespace

در بیشتر سناریوها، بهتر است دسترسی‌ها در سطح Namespace مدیریت شوند. استفاده از Role و RoleBinding باعث می‌شود دامنه دسترسی محدود بماند و ایزوله‌سازی بین محیط‌هایی مانند dev و prod حفظ شود.

محدود کردن استفاده از ClusterRole و ClusterRoleBinding

ClusterRole و ClusterRoleBinding فقط باید برای دسترسی‌های سراسری یا منابع cluster-scoped استفاده شوند. استفاده غیرضروری از آن‌ها می‌تواند سطح دسترسی کاربران را بیش از حد افزایش دهد.

استفاده از Service Account اختصاصی

بهتر است هر Pod یا برنامه از Service Account اختصاصی خود استفاده کند و به Service Account پیش‌فرض Namespace وابسته نباشد. این کار باعث می‌شود دسترسی سرویس‌ها از یکدیگر جدا شود.

همچنین در صورت عدم نیاز، می‌توان قابلیت mount خودکار توکن Service Account را با تنظیم automountServiceAccountToken: false غیرفعال کرد.

بازبینی و حساب‌رسی دوره‌ای

تنظیمات RBAC باید به‌صورت دوره‌ای بررسی شوند تا دسترسی‌های قدیمی، RoleBindingهای بلااستفاده یا مجوزهای غیرضروری حذف شوند. همچنین دسترسی‌های حساس، به‌ویژه اعضای گروه system:masters، باید به‌صورت مستمر کنترل شوند.

اشتباهات رایج در مدیریت RBAC کوبرنتیز

در پیاده‌سازی RBAC، بسیاری از مشکلات امنیتی نه به دلیل ضعف ابزار، بلکه به خاطر تنظیمات نادرست رخ می‌دهند. مهم‌ترین اشتباهات رایج عبارت‌اند از:

استفاده از ClusterRoleBinding به‌جای RoleBinding

یکی از خطاهای رایج، استفاده بی‌دلیل از ClusterRoleBinding است. این کار می‌تواند باعث شود کاربری که باید فقط در یک Namespace محدود باشد، به منابع سایر Namespaceها نیز دسترسی پیدا کند.

استفاده از وایلدکارد در دسترسی‌ها

دادن دسترسی * در منابع یا عملیات‌ها عملاً تمام محدودیت‌های RBAC را از بین می‌برد و باعث ایجاد دسترسی‌های غیرقابل‌کنترل می‌شود.

استفاده از حساب cluster-admin برای کارهای روزمره

حساب cluster-admin دسترسی کامل به کل کلاستر دارد. استفاده روزمره از آن ریسک خطای انسانی را به‌شدت افزایش می‌دهد و می‌تواند منجر به تغییرات مخرب در کل سیستم شود.

اضافه کردن کاربران به گروه system:masters

عضویت در این گروه باعث دور زدن کامل RBAC می‌شود. این سطح دسترسی عملاً معادل دسترسی روت در کل کلاستر است و باید به‌شدت محدود شود.

استفاده از Service Account پیش‌فرض

استفاده از Service Account پیش‌فرض یک Namespace برای همه پادها باعث می‌شود سرویس‌های مختلف، یک سطح دسترسی مشترک داشته باشند. این موضوع ریسک نفوذ را افزایش می‌دهد.

فعال‌سازی تنظیمات ناامن در API Server

فعال کردن گزینه‌هایی مانند --insecure-port یا --anonymous-auth می‌تواند لایه احراز هویت و کنترل دسترسی را عملاً بی‌اثر کند.

عدم بازبینی دوره‌ای دسترسی‌ها

اگر Roleها و RoleBindingها به‌صورت دوره‌ای بررسی نشوند، دسترسی‌های قدیمی و غیرضروری باقی می‌مانند و به مرور زمان سطح حمله (Attack Surface) را افزایش می‌دهند.

نادیده گرفتن تغییرات سازمانی

تغییر نقش افراد در سازمان یا خروج آن‌ها باید بلافاصله در RBAC اعمال شود. عدم به‌روزرسانی دسترسی‌ها می‌تواند باعث انباشت مجوزهای اضافی شود.

محدودیت‌های سیستم RBAC در کوبرنتیز

سیستم RBAC در کوبرنتیز ابزار اصلی کنترل دسترسی است، اما به‌تنهایی برای پوشش تمام سناریوهای امنیتی کافی نیست و محدودیت‌های مشخصی دارد:

۱. عدم کنترل روی محتوای منابع

RBAC فقط مشخص می‌کند چه کسی به یک resource دسترسی دارد، اما روی محتوای آن کنترل ندارد. برای مثال، اگر کاربری اجازه دسترسی به Secrets را داشته باشد، می‌تواند به محتوای رمزگذاری‌شده آن‌ها دسترسی پیدا کند، بدون اینکه RBAC بتواند سطح جزئی‌تری از محدودیت اعمال کند.

۲. عدم جلوگیری از Privilege Escalation در سطح Pod

در صورتی که کاربر اجازه ایجاد پاد داشته باشد، می‌تواند از طریق اتصال Service Accountهای دارای سطح دسترسی بالاتر، به مجوزهای بیشتری دست پیدا کند. RBAC به‌تنهایی جلوی این نوع ارتقا سطح دسترسی را نمی‌گیرد.

۳. محدودیت در کنترل منابع زیرساختی

RBAC فقط دسترسی به ایجاد یا مدیریت منابع را کنترل می‌کند، اما نمی‌تواند نوع یا رفتار دقیق برخی منابع را محدود کند. برای مثال، کاربر می‌تواند در صورت داشتن مجوز، نوع PersistentVolume را به شکلی انتخاب کند که ریسک امنیتی ایجاد کند.

۴. عدم کنترل روی عملیات‌های حساس خاص

برخی عملیات مانند impersonate ،bind و escalate می‌توانند منجر به دور زدن سیاست‌های دسترسی شوند. RBAC این عملیات‌ها را در سطح منطقی کنترل می‌کند، اما سوءاستفاده از آن‌ها در صورت داشتن مجوز، همچنان امکان‌پذیر است.

۵. محدودیت در برابر حملات سطح کلاستر

RBAC توانایی محدود کردن رفتارهایی مانند ایجاد حجم بالای resource و مصرف بیش از حد etcd یا CPU را ندارد. برای این موارد باید از مکانیزم‌های مکمل مانند ResourceQuota و LimitRange استفاده شود.

جمع‌بندی

RBAC در کوبرنتیز یکی از مهم‌ترین لایه‌های امنیتی برای مدیریت دسترسی کاربران و سرویس‌ها در کلاستر است. این مکانیزم بر پایه تعریف نقش‌ها (Role و ClusterRole)، اتصال آن‌ها به هویت‌ها (RoleBinding و ClusterRoleBinding) و اعمال سیاست‌های دسترسی در سطح API Server عمل می‌کند.

در سطح عملی، RBAC به شما اجازه می‌دهد دسترسی‌ها را به‌صورت دقیق و محدود در سطح Namespace یا کل کلاستر کنترل کنید و اصل Least Privilege را پیاده‌سازی کنید. با این حال، این سیستم به‌تنهایی کافی نیست و باید در کنار سایر مکانیزم‌های امنیتی مانند ResourceQuota، LimitRange و سیاست‌های امنیتی تکمیلی استفاده شود.

همچنین بیشترین خطاها در پیاده‌سازی RBAC معمولاً ناشی از استفاده بیش از حد از دسترسی‌های سراسری، بی‌توجهی به Service Accountها و عدم بازبینی دوره‌ای مجوزهاست. در نهایت، RBAC یک ابزار پایه و ضروری برای امنیت Kubernetes است، اما ارزش واقعی آن زمانی مشخص می‌شود که به‌درستی طراحی، محدود و در کنار سایر لایه‌های امنیتی استفاده شود.

The post RBAC در کوبرنتیز چیست؟ آشنایی با اجزا و روش‌های پیاده‌سازی appeared first on بلاگ هم‌روش.

برای بررسی جزئیات تغییرات و آشنایی با هزینه منابع و سرویس‌ها، می‌توانید جدول‌های زیر را مشاهده کنید. کلیه هزینه‌ها، بر اساس دوره ماهانه سرویس‌ها ذکر شده‌اند. همچنین صفحه قیمت‌گذاری هم‌روش از ابتدای خرداد با اعمال تغییرات به‌روزرسانی شده‌ است.

منابع

هزینه منابع کلاسترهای سرویس‌ها (اختصاصی و عمومی) بر اساس جدول زیر محاسبه می‌شود.

پلتفرم ابری دارکوب

دارکوب یک پلتفرم ابری بر پایه کوبرنتیز است که به سازمان‌ها این امکان را می‌دهد تا بدون مواجه شدن با دشواری‌های مسائل زیرساخت و نگهداری کوبرنتیز، پروژه‌های خود را به سادگی و با سرعت بالا روی اینترنت بارگذاری و اجرا کنند. هزینه سرویس دارکوب بر اساس منابع ذکر شده در جدول بالا محاسبه می‌شود. همچنین امکان فعال کردن سرویس مانیتورینگ عمومی برای اپلیکیشن‌های پلتفرم دارکوب با قیمت ۱،۴۰۰،۰۰۰ تومان فراهم شده است.

در میان سرویس‌هایی که در کنسول هم‌روش،‌ در این بخش قابل مشاهده هستند، هزینه موارد زیر بر اساس جدول‌های جداگانه‌ای محاسبه می‌شود که در ادامه این مطلب، در بخش مربوط به هر سرویس ذکر شده‌اند:

• اپلیکیشن‌های بازارچه
• دیتابیس مدیریت‌شده (شامل دیتابیس‌های PostgreSQL و MySQL)
• جیرا
• کانفلوئنس
• گیت‌لب رانر

کوبرنتیز مدیریت‌شده

کوبرنتیز مدیریت‌شده، عمده فرایندهای مرتبط با زیرساخت را خودکارسازی می‌کند و علاوه بر کاهش هزینه‌های عملیاتی، بهبود کیفیت و افزایش مشاهده‌پذیری را برای سازمان‌ها به همراه می‌آورد. هزینه منابع این کلاستر بر اساس هزینه منابع جدول بالا به‌علاوه هزینه مدیریت کلاستر بر اساس جدول زیر محاسبه می‌شود.

دیتابیس مدیریت‌شده

دیتابیس مدیریت‌شده به کسب‌وکارها این امکان را می‌دهد که بدون دغدغه‌‌های مرتبط با مدیریت زیرساخت، سرویس دیتابیس را راه‌اندازی کرده و بر توسعه محصول خود تمرکز کنند. هزینه دیتابیس مدیریت‌شده بر اساس منابع به شرح زیر است.

آبجکت استورج

سرویس آبجکت استورج هم‌روش، راهکاری مقیاس‌پذیر برای ذخیره‌سازی بهینه انواع آبجکت‌‌ها را ارائه می‌کند. این سرویس امکان توسعه و سازگاری با نیازهای آینده سازمان‌ها را فراهم می‌آورد و می‌تواند به عنوان راهکار اصلی ذخیره‌سازی داده‌های حیاتی یا مکمل زیرساخت موجود، در بهینه‌سازی و افزایش کارایی، نقش کلیدی داشته باشد. هزینه این سرویس در جدول زیر ذکر شده است.

بکاپ

سرویس بکاپ هم‌روش امکان پشتیبان‌گیری مستمر و خودکار از اپلیکیشن‌ها و دیسک‌ها را بر اساس سیاست‌های پشتیبان‌گیری متنوع ارائه می‌کند. هزینه سرویس بکاپ بر اساس جدول زیر محاسبه می‌شود.

بازارچه هم‌روش

بازارچه هم‌روش امکان راه‌اندازی سریع برنامه‌های آماده را بدون پیکربندی پیچیده ارائه می‌کنند. هزینه سرویس‌های بازارچه به شرح زیر است.

در میان سرویس‌های بازارچه که در کنسول هم‌روش قابل مشاهده هستند، هزینه سرویس‌های مدیریت‌شده زیر بر اساس جدول‌های جداگانه‌ای محاسبه می‌شود که در ادامه این مطلب، در بخش مربوط به هر سرویس ذکر شده‌اند:

• جیرا
• کانفلوئنس
• n8n

جیرا

سرویس جیرا هم‌روش یک راهکار آماده و بدون پیچیدگی برای سازمان‌هایی است که به یک راهکار قدرتمند و منعطف برای مدیریت پروژه‌های تیم‌ها نیاز دارند. پلن‌های این سرویس به شرح زیر هستند.

کانفلوئنس

سرویس کانفلوئنس هم‌روش یک بستر متمرکز و قابل اعتماد برای مستندسازی، اشتراک دانش و همکاری تیمی در مقیاس سازمانی فراهم می‌کند. پلن‌های این سرویس در جدول زیر ذکر شده‌اند.

n8n

سرویس n8n هم‌روش راهکاری پایدار و مقیاس‌پذیر برای پیاده‌سازی اتوماسیون سازمانی و یکپارچه‌سازی سرویس‌ها در بستر ابری را فراهم می‌کند. این سرویس به تیم‌ها امکان می‌دهد workflowهای پیچیده میان APIها و سیستم‌های داخلی را بدون محدودیت اتصال و با عملکردی بهینه اجرا کنند. پلن‌های این سرویس در جدول زیر ذکر شده‌اند.

سنتری

سرویس Sentry هم‌روش، راهکاری برای تیم‌های دواپس است که به مانیتورینگ جامع و تحلیل عمیق خطاها در محیط‌های امن و مقیاس‌پذیر نیاز دارند. هزینه‌ این سرویس بر اساس تعداد spanها و errorها به شرح زیر محاسبه می‌شود.

در گذشته، هزینه سرویس سنتری بر اساس میزان error و transaction محاسبه می‌شد اما از این پس بر مبنای error و span در نظر گرفته می‌شود. در مبنای محاسبه جدید، هر یک transaction سابق معادل متوسط ۲۰ عدد span در نظر گرفته شده است. همچنین در طرح جدید سرویس، تعداد بسته‌های قابل انتخاب برای span و error افزایش یافته است.

گیت‌لب رانر

گیت‌لب رانر هم‌روش با بهره‌گیری از بستر کوبرنتیز و در تعامل با هم‌گیت یا گیت‌لب اختصاصی سازمان‌ها، امکان اجرای jobها و ساخت imageهای نرم‌افزارهای سازمان‌ها را به‌صورت خودکار و بدون دغدغه‌ تحریم فراهم می‌کند. پلن‌های سرویس گیت‌لب رانر در جدول زیر ذکر شده است.

لود بالانسر اختصاصی

سرویس لود بالانسر اختصاصی هم‌روش امکان ایزوله کردن درخواست‌‌‌های HTTP اپلیکیشن‌های سازمان‌ها از دیگر مشتریان کلاستر را فراهم می‌کند. با لود بالانسر اختصاصی سازمان‌ها می‌توانند لاگ‌ها و متریک‌ها را از طریق فعال‌سازی سرویس مانیتورینگ و لاگ جمع‌آوری کنند. لود بالانسر هم‌روش همچنین از SSL termination و health check پشتیبانی می‌کند. هزینه لود بالانسر اختصاصی در جدول زیر مشخص شده است.

پشتیبانی سازمانی

سرویس پشتیبانی سازمانی هم‌روش راهکاری حرفه‌ای برای کسب‌‌وکارهایی است که زیرساخت ابری را بخشی حیاتی از عملیات خود می‌دانند. این سرویس به کسب‌وکارها کمک می‌کند با تمرکز بیشتر روی توسعه محصول،‌ پشتیبانی سرویس‌های ابری را به تیم متخصص بسپارند. با پشتیبانی سازمانی، تیکت‌ها با بالاترین اولویت بررسی می‌شوند، اکانت منیجر اختصاصی به سازمان اختصاص می‌یابد و مانیتورینگ آپ‌تایم و اندپوینت‌های حیاتی توسط هم‌روش انجام می‌شود.

هزینه سرویس‌ پشتیبانی سازمانی به این صورت محاسبه می‌شود که پس از محاسبه هزینه‌های سرویس، به میزان ۸ درصد از مبلغ کل فاکتور، تحت هزینه پشتیبانی سازمانی، به مبلغ افزوده می‌شود و حداقل هزینه پشتیبانی سازمانی ۴۸،۰۰۰،۰۰۰ تومان در نظر گرفته شده است.

سایر راهکارهای هم‌روش

علاوه بر سرویس‌هایی که اشاره شد، راهکارهای اختصاصی زیر نیز توسط هم‌روش ارائه می‌شوند.

مهاجرت ابری

سازمان‌هایی که قصد مهاجرت به زیرساخت ابری هم‌روش را دارند می‌توانند از خدمات مشاوره مهاجرت بهره‌مند شوند. در این خدمات، راهکارهای طراحی و پیاده‌سازی معماری cloud native و مایکروسرویس، dockerize کردن سرویس‌ها و راه‌اندازی CI/CD ارائه می‌شود.

گیت‌لب عمومی (هم‌گیت)

هم‌گیت، سرویس گیت‌لب رایگان است که برای کاربران هم‌روش امکان بارگذاری امن ریپوها را با حفظ حریم خصوصی فراهم می‌کند. هم‌گیت، برخلاف گیت‌لب مشکلات مرتبط با تحریم را ندارد و به صورت مستمر، توسط هم‌روش نگهداری و به‌روزرسانی می‌شود.

گیت‌لب اختصاصی

سرویس راه‌اندازی گیت‌لب اختصاصی هم‌روش بر پایه گیت‌لب، به سازمان‌ها کمک می‌کند تا یک بستر اختصاصی و یکپارچه برای مدیریت کد و چرخه کامل توسعه نرم‌افزار در اختیار داشته باشند. این سرویس با استقرار در زیرساخت ابری اختصاصی، امکان مدیریت مخازن کد، پیاده‌سازی CI/CD، کنترل دسترسی‌های سازمانی و اجرای خودکار فرایندهای توسعه را فراهم می‌کند.

جیتسی مدیریت‌شده

سرویس Jitsi مدیریت‌شده هم‌روش یک بستر امن، پایدار و مقیاس‌پذیر برای برگزاری جلسات ویدئویی و ارتباطات آنلاین را در اختیار سازمان‌ها قرار می‌دهد. این سرویس با استقرار در زیرساخت ابری اختصاصی، امکان برقراری تماس‌های صوتی و تصویری با کیفیت بالا، مدیریت دسترسی کاربران و کنترل کامل بر داده‌ها را فراهم می‌کند.

سرویس GPU

سرویس GPU هم‌روش راهکاری پیشرفته برای سازمان‌هایی است که قصد دارند بدون نیاز به سرمایه‌گذاری در زیرساخت سخت‌افزاری، از قدرت پردازشگرهای گرافیکی پیشرفته و به‌روز برای پردازش‌های سنگین حوزه هوش مصنوعی (AI) و یادگیری ماشین (ML) استفاده کنند.

سرویس Vault

سرویس Vault مدیریت‌شده هم‌روش (مبتنی بر Hashicorp Vault)، راهکار مدیریت متمرکز و امن اطلاعات حساس را در بستر ابر به سازمان‌ها ارائه می‌کند. این سرویس امکان ذخیره‌سازی، کنترل دسترسی و استفاده ایمن از کلیدهای API، رمزهای عبور، توکن‌ها و سایر داده‌های محرمانه را فراهم می‌کند و با اعمال سیاست‌های دسترسی مبتنی بر نقش، از دسترسی غیرمجاز جلوگیری می‌کند.

اعتبار هدیه

هم‌روش در ابتدای ثبت‌نام در کنسول، مبلغی به عنوان هدیه را برای مشتریان در نظر می‌گیرد. این مبلغ که تا پیش از این ۱۰۰،۰۰۰ تومان بوده، از ابتدای خرداد ماه به ۵۰۰،۰۰۰ تومان افزایش یافته است.

اگر سوالی درباره به‌روزرسانی تعرفه خدمات دارید، می‌توانید با واحد فروش، به شماره ۹۲۰۰۹۲۴۰-۰۲۱ – داخلی ۲، در ارتباط باشید یا درخواست خود را در صفحه درخواست مشاوره ثبت کنید.

The post به‌روزرسانی تعرفه خدمات هم‌روش از ابتدای خرداد ۱۴۰۵ appeared first on بلاگ هم‌روش.

تغییر نحوه دریافت گواهی SSL برای اپلیکیشن‌های دارکوب

برای صدور گواهی SSL به روش ثبت رکورد DNS، مراحل زیر را دنبال کنید.

مرحله ۱ و ۲: ابتدا به منوی دارکوب کنسول هم‌روش بروید و سپس روی اپلیکیشن مورد نظر خود کلیک کنید.

مرحله ۳: از منوی سمت راست روی گزینه «آدرس دامنه» کلیک کنید.

مرحله ۴: در قسمت «تنظیم گواهی SSL» گزینه «DNS» را انتخاب کنید.

مرحله ۵: در قسمت «Host Address»، آدرس دامین مورد نظر خود را مشاهده می‌کنید. از صحت این آدرس اطمینان حاصل کنید. همچنین می‌توانید در صورت نیاز این آدرس را تغییر دهید.

مرحله ۶ و ۷: پس از اطمینان از آدرس، باید به پنل ارائه‌دهنده سرویس DNS مرتبط با دامین خود مراجعه کرده و یک رکورد از نوع CNAME با مشخصات زیر ایجاد کنید:

• در این رکورد، مقدار ساب‌دامین نمایش داده شده در گزینه ۶ تصویر (در این مثال acme-challenge_) را وارد کنید. توجه داشته باشید که اگر آدرس وارد شده در مرحله ۵، شامل ساب‌دامین (مثلا a.example.ir) باشد، مقدار این گزینه نیز شامل ساب‌‌دامین (مثلا acme-challenge.a_) خواهد بود.
• Value را نیز مطابق با عبارت نمایش داده شده در گزینه ۷ تصویر وارد کنید.
• در نهایت این مقادیر را در پنل ارائه‌دهنده سرویس DNS خود ذخیره کنید و به کنسول هم‌روش بازگردید.

مرحله ۸: حتما در کنسول هم‌روش، روی «ذخیره تغییرات» کلیک کنید.

نکته: توجه داشته باشید که اعمال رکورد CNAME در پنل ارائه‌دهنده سرویس DNS و فرایند Propagation رکورد ممکن است تا ۲ ساعت زمان ببرد.

تغییر نحوه دریافت گواهی SSL برای اپلیکیشن‌های بازارچه

برای صدور گواهی SSL به روش ثبت رکورد DNS، مراحل زیر را دنبال کنید.

مرحله ۱ و ۲: برای تعریف رکورد CNAME اپلیکیشن‌های بازارچه ابتدا به منوی بازارچه در کنسول هم‌روش بروید سپس روی اپلیکیشن مورد نظر خود کلیک کنید.

مرحله ۳ و ۴: از منوی سمت راست روی گزینه «دامنه» کلیک کنید و سپس در مقابل دامنه خود، روی علامت چرخ‌دنده کلیک کنید.

مرحله ۵: در پنجره‌ای که باز می‌شود گزینه «dns01» را انتخاب کنید.

مرحله ۶ و ۷: حالا باید به پنل ارائه‌دهنده سرویس DNS مرتبط با دامین خود مراجعه کرده و یک رکورد از نوع CNAME با مشخصات زیر ایجاد کنید:

• در این رکورد، مقدار ساب‌دامین نمایش داده شده در گزینه ۶ تصویر (در این مثال acme-challenge_) را وارد کنید. توجه داشته باشید که اگر آدرس وارد شده در مرحله ۵، شامل ساب‌دامین (مثلا a.example.com) باشد، مقدار این گزینه نیز شامل ساب‌‌دامین (مثلا acme-challenge.a_) خواهد بود.
• Value را نیز مطابق با عبارت نمایش داده شده در گزینه ۷ تصویر وارد کنید.
• در نهایت این مقادیر را در پنل ارائه‌دهنده سرویس DNS خود ذخیره کنید و به کنسول هم‌روش بازگردید.

مرحله ۸: حتما در کنسول هم‌روش، روی «ذخیره تغییرات» کلیک کنید.

نکته: توجه داشته باشید که اعمال رکورد CNAME در پنل ارائه‌دهنده سرویس DNS و فرایند Propagation رکورد ممکن است تا ۲ ساعت زمان ببرد.

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

The post اطلاعیه مهم؛ تغییر فرایند دریافت گواهی SSL برای اپلیکیشن‌‌های بازارچه و دارکوب appeared first on بلاگ هم‌روش.

طی مدت حادثه صفحه «وضعیت سرویس‌های هم‌روش» در حال به‌روزرسانی بود تا کاربران در جریان آخرین وضعیت دیتاسنتر و سرویس‌ها قرار بگیرند.

روند زمانی حادثه و اقدامات انجام شده

• ۲۲:۴۰ – ۱۰ فروردین ۱۴۰۵: هشدار افزایش دمای سرورها دریافت شد و به سرعت تعدادی از سرورها از دسترس خارج شدند. با پیگیری از دیتاسنتر مشخص شد که حادثه ناشی از اختلال برق و از کار افتادن سیستم‌های سرمایش دیتاسنتر بوده است. در ادامه به منظور جلوگیری از آسیب بیشتر به سخت‌افزارها، سایر سرورها نیز خاموش شدند.
• ۲۲:۴۵ – ۱۰ فروردین ۱۴۰۵: دسترسی هم‌روش به دیتاسنتر قطع شد. با پیگیری از دیتاسنتر مشخص شد که بخشی از کابل‌های تامین برق دچار آتش‌سوزی شده و دیتاسنتر به‌صورت کامل از دسترس خارج شده است. پس از مهار آتش‌سوزی، فرایند تعویض کابل‌ها توسط تیم تاسیسات دیتاسنتر آغاز شد.
• ۱۲:۰۵ – ۱۱ فروردین ۱۴۰۵: تیم فنی هم‌روش اطمینان پیدا کرد که ساختمان دیتاسنتر آسیبی ندیده و فرایند بازیابی سرویس‌ها را آغاز کرد.
• ۱۹:۱۵ – ۱۱ فروردین ۱۴۰۵: جریان برق دیتاسنتر، مجدد برقرار و شارژ شدن یو‌پی‌اس‌ها آغاز شد.
• ۱۹:۵۳ – ۱۱ فروردین ۱۴۰۵: فرایند روشن شدن سرورها شروع شد. البته سرورهایی که به دلیل دمای بالا خاموش شده بودند همچنان خاموش باقی ماندند. برخی از سرویس‌ها مجدد در دسترس قرار گرفتند.
• ۲۱:۵۷ – ۱۱ فروردین ۱۴۰۵: برق دیتاسنتر بار دیگر به دلیل مشکل در ورودی برق شهری قطع و فرایند بازیابی و راه‌اندازی سرویس‌ها متوقف شد.
• ۲۲:۲۴ – ۱۱ فروردین ۱۴۰۵: جریان برق برقرار شد و سرورها روشن شدند. تیم فنی هم‌روش اطمینان پیدا کرد که همه سخت‌افزارهای سرورها سالم هستند ولی برخی از استورج‌های SSD در اثر شوک ناشی از قطع برق آسیب دیده‌اند. در ادامه، فرایند راه‌اندازی و بازیابی سرویس‌ها مجدد از سر گرفته شد.
• ۲۳:۰۰ – ۱۱ فروردین ۱۴۰۵: در ۳۶ دقیقه پس از وصل مجدد برق، تمام سرویس‌های عمومی هم‌روش به‌طور کامل در دسترس کاربران قرار گرفت.
• ۰۰:۰۵ – ۱۲ فروردین ۱۴۰۵: فرایند بازیابی داده‌های استورج‌های معیوب شروع شد. همچنین استورج‌های SSD خراب که دچار شوک ناشی از حادثه شده بودند تعویض شدند.
• ۰۶:۰۰ – ۱۲ فروردین ۱۴۰۵: سرویس‌های تمام مشتریان به‌صورت پایدار در دسترس قرار گرفت.

طی این حادثه، حداکثر میزان از دست رفتن داده‌ها مربوط به بازه ۲۴ ساعته و محدود به تعداد کمی از مشتریان بود که سرویس‌های آن‌ها با مشکل آسیب استورج‌های SSD مواجه شد. همچنین سرویس «دیتابیس مدیریت‌شده» با استفاده از مکانیزم PITR و بر پایه آخرین base backup و لاگ‌های تراکنش، تا نقطه‌ای کمتر از ۳۰ ثانیه قبل از زمان وقوع حادثه بازیابی شد.

The post گزارش حادثه عمومی زون c13 هم‌روش در ۱۰ فروردین ۱۴۰۵ appeared first on بلاگ هم‌روش.

معماری serverless چیست؟

معماری serverless مدلی از رایانش ابری است که به کمک آن توسعه‌دهندگان می‌توانند برنامه‌های خود را بدون نیاز به مدیریت سرورها، سیستم‌عامل و زیرساخت اجرا کنند و این مسئولیت‌ها را بر عهده ارائه‌دهنده خدمات ابری بگذارند.

در این نوع رایانش ابری، کماکان برنامه‌ها روی سرورها اجرا می‌شوند، اما بخش مدیریت و نگه‌داری زیرساخت، بر عهده‌ شرکت ارائه‌دهنده‌ خدمات ابری است. این ویژگی باعث می‌شود توسعه‌دهندگان بیشتر بر توسعه قابلیت‌های نرم‌افزار و منطق کسب‌وکار تمرکز کنند.

معماری serverless چطور کار می‌کند؟

در روش‌های سنتی، تیم‌های فنی باید زیرساخت سرور، به‌روزرسانی‌های امنیتی، مقیاس‌پذیری و نگه‌داری سیستم را مدیریت کنند. با به‌کارگیری خدمات serverless، توسعه‌دهندگان می‌توانند این مسئولیت‌ها را به یک ارائه‌دهنده خدمات ابری محول کرده و بر وظایف اصلی خود تمرکز کنند.

یکی از محبوب‌ترین معماری‌های بدون سرور، Function as a Service (به اختصار FaaS) است که در آن توسعه‌دهندگان کد برنامه خود را به‌عنوان مجموعه‌ای از فانکشن‌ها می‌نویسند. هر فانکشن هنگامی‌که توسط یک رویداد فراخوانی شود، کار خاصی را انجام می‌دهد. پس از مراحل مرسوم تست، توسعه‌دهندگان فانکشن‌های خود را روی یک ارائه‌دهنده ابری مستقر می‌کنند.

هنگامی که یک تابع فراخوانی می‌شود، ارائه‌دهنده خدمات ابری، تابع را روی یک محیط فعال اجرا می‌کند، یا اگر محیط فعالی برای اجرای تابع وجود نداشته باشد، ارائه‌دهنده خدمات ابری یک محیط جدید، معمولاً به شکل کانتینر یا microVM (ماشین مجازی بسیار سبک) ایجاد کرده و کد تابع را در آن اجرا می‌کند. این فرایند در پس‌زمینه انجام می‌شود و برای توسعه‌دهندگانی که بر نوشتن و استقرار کد تمرکز دارند، شفاف است و تأثیری بر روند کار آن‌ها ندارد.

مزایا و معایب استفاده از معماری serverless چیست؟

استفاده از معماری serverless در سال‌های گذشته رشد چشمگیری داشته است. طیف وسیعی از سازمان‌های کوچک و بزرگ و استارت‌‌آپ‌ها به استفاده از این معماری برای برنامه‌های خود روی آورده‌اند. این استقبال از معماری بدون سرور به دلایل زیر اتفاق افتاده است:

• هزینه‌ کمتر: ارائه‌دهندگان خدمات ابری صرفا برای منابعی که استفاده می‌شوند از کاربر هزینه دریافت می‌کنند. در معماری رایانش بدون سرور، معمولاً هزینه‌ها بر اساس میزان استفاده از منابع مانند مدت زمان پردازش و مصرف حافظه محاسبه می‌شوند؛ هرچند برخی ارائه‌دهندگان خدمات serverless ممکن است هزینه‌های پایه یا محدودیت‌های خاص را نیز در نظر بگیرند.
• افزایش بهره‌وری: رایانش بدون سرور به تیم‌های توسعه این امکان را می‌دهد که به جای مدیریت زیرساخت، بر نوشتن کد تمرکز کنند. در نتیجه توسعه‌دهندگان زمان بیشتری برای نوآوری و بهینه‌سازی منطق کسب‌وکار و عملکرد بخش‌های فرانت‌اند برنامه خواهند داشت.
• توسعه با هر زبان برنامه‌نویسی: محیط‌های خدمات serverless معمولاً چندزبانه هستند و به توسعه‌دهندگان اجازه می‌دهند با زبان‌ها و فریم‌ورک‌هایی که با آن‌ها راحت‌تر هستند کار کنند؛ مانند Java ،Python ،JavaScript یا محیط اجرایی Node.js.
• ساده‌تر شدن فرایندهای توسعه و DevOps: رایانش serverless فرایند استقرار را ساده‌تر و چرخه‌های DevOps را بهینه می‌کند؛ زیرا توسعه‌دهندگان نیازی ندارند زیرساخت لازم برای یکپارچه‌سازی، تست، تحویل و استقرار نسخه‌های نرم‌افزار در محیط تولید را به‌طور دستی تعریف و مدیریت کنند.
• کارایی مقرون‌به‌صرفه: برای برخی بارهای کاری خاص مانند پردازش‌های کاملاً موازی، پردازش جریان داده یا برخی وظایف پردازش داده، رایانش بدون سرور می‌تواند هم سریع‌تر و هم مقرون‌به‌صرفه‌تر از سایر مدل‌های پردازشی باشد.
• کاهش تأخیر (Latency): در برخی پلتفرم‌های serverless امکان اجرای کد در نزدیکی کاربر نهایی وجود دارد. این موضوع می‌تواند باعث کاهش زمان تأخیر در پاسخ‌دهی سیستم شود.

البته استفاده از معماری بدون سرور سراسر مزیت نیست. این معماری که به کمک سازمان‌های مختلف آمده، معایبی هم دارد که عبارت‌اند از:

• کنترل کمتر: در رایانش بدون سرور، سازمان‌ها کنترل سرورها را به یک ارائه‌دهنده خدمات ابری واگذار می‌کنند. در نتیجه مدیریت سخت‌افزار و محیط‌های اجرایی در اختیار ارائه‌دهنده قرار می‌گیرد و توسعه‌دهندگان کنترل مستقیم کمتری بر زیرساخت دارند.
• نیاز به برقراری امنیت دقیق: در بسیاری از پلتفرم‌های serverless، کد کاربران مختلف ممکن است روی زیرساخت مشترک اجرا شود و اگر تنظیمات به‌درستی انجام نشوند، احتمال بروز آسیب‌پذیری‌های امنیتی یا دسترسی غیرمجاز به داده‌ها وجود دارد. با این حال ارائه‌دهندگان ابری معمولاً با استفاده از فناوری‌هایی مانند ایزولیشن کانتینر یا microVM امنیت و جداسازی محیط‌های اجرایی را تضمین می‌کنند.
• تأثیر بر عملکرد: در محیط‌های بدون سرور، اگر مدتی هیچ درخواستی برای یک تابع ارسال نشود، پلتفرم ابری ممکن است محیط مربوط به آن را متوقف کند تا منابع آزاد شوند. در این حالت، هنگام فراخوانی مجدد تابع، سیستم باید محیط اجرایی را دوباره آماده کند. این فرایند باعث ایجاد یک تاخیر اولیه در پاسخ‌دهی می‌شود که به استارت سرد (Cold Start) معروف است.
• پیچیدگی در تست و اشکال‌زدایی: در رایانش serverless فرایند اشکال‌زدایی و تست یکپارچگی می‌تواند پیچیده‌تر باشد، زیرا توسعه‌دهندگان دید شفاف و کاملی نسبت به زیرساخت و فرایندهای پشت‌صحنه ندارند.
• هزینه بیشتر برای پردازش‌های طولانی‌مدت: مدل اجرای رایانش serverless برای اجرای طولانی‌مدت کد طراحی نشده است. بنابراین در برخی موارد، اجرای پردازش‌های طولانی ممکن است نسبت به استفاده از سرور اختصاصی یا ماشین مجازی هزینه بیشتری داشته باشد.
• محدودیت تأمین‌کننده: هر ارائه‌دهنده خدمات ابری قابلیت‌ها و ویژگی‌های خاص خود را در سرویس‌های serverless ارائه می‌دهد که معمولاً با سرویس‌های سایر ارائه‌دهندگان سازگار نیستند. این موضوع می‌تواند مهاجرت به ارائه‌دهندگان دیگر را دشوار کند.

به‌طور کلی شرکت‌هایی که می‌خواهند در سریع‌ترین زمان ممکن وارد بازار شوند و برنامه‌های مقیاس‌پذیر و سبک بسازند، می‌توانند از مزایای معماری بدون سرور بهره‌مند شوند.

اما اگر برنامه‌های کسب‌وکار شامل تعداد زیادی فرایند مداوم و طولانی‌مدت است، ماشین‌های مجازی یا کانتینر ابری ممکن است انتخاب بهتری باشند. در یک زیرساخت ترکیبی، توسعه‌دهندگان ممکن است از کانتینرها یا ماشین‌های مجازی برای پاسخ به اکثر درخواست‌ها استفاده کنند، اما برخی از تسک‌های کوتاه‌مدت مانند پردازش تصاویر، ارسال ایمیل، پردازش رویدادها یا اجرای وظایف پس‌زمینه می‌توانند با استفاده از رایانش بدون سرور انجام شوند.

موارد استفاده از معماری serverless چیست؟

معماری serverless معمولاً برای بارهای کاری رویدادمحور (event-driven)، پردازش‌های مقطعی و سناریوهایی با ترافیک متغیر یا غیرقابل پیش‌بینی بسیار مناسب است. علاوه بر این، معماری serverless در موارد زیر کاربرد دارد:

• برنامه‌های مبتنی بر رویداد (Trigger-based): هر برنامه‌ای که با فعالیت کاربران یا رخدادهای مشخصی فعال شود، می‌تواند به‌صورت serverless پیاده‌سازی شود.
• ساخت APIهای RESTful: با استفاده از گیت‌وی‌های API مانند Amazon API Gateway، می‌توان APIهایی ساخت که با تقاضا مقیاس‌پذیر باشند و فقط زمانی منابع مصرف کنند که فراخوانی می‌شوند.
• پردازش ناهمزمان (Asynchronous Processing): توابع بدون سرور می‌توانند وظایف پس‌زمینه مانند پردازش اطلاعات محصولات یا رمزگذاری ویدیوها پس از آپلود را بدون ایجاد تأخیر انجام دهند.
• پشتیبانی از بررسی‌های امنیتی: توسعه‌دهندگان می‌توانند توابعی برای اسکن کانتینرها یا بررسی پیکربندی‌ها و آسیب‌پذیری‌ها فراخوانی کنند. همچنین این توابع می‌توانند در فرایندهای احراز هویت مانند تأیید SSH یا احراز هویت دو مرحله‌ای نقش ایمن‌تری ایفا کنند.
• یکپارچه‌سازی و تحویل مداوم (CI/CD): معماری رایانش بدون سرور می‌تواند در پایپ‌لاین‌های CI/CD برای خودکارسازی وظایفی مانند تست، پردازش رویدادها و استقرار سرویس‌ها به کار رود.

تفاوت معماری مایکروسرویس با معماری serverless چیست؟

مایکروسرویس‌ها به نحوه طراحی و ساختار سیستم اشاره دارند، در حالی که رایانش بدون سرور مدلی برای اجرا و استقرار برنامه‌ها محسوب می‌شود.

برنامه‌های بدون سرور می‌توانند بر اساس اصول معماری مایکروسرویس طراحی شوند و در بسیاری از موارد، این رویکرد توصیه می‌شود. با این حال، استفاده از رایانش Serverless برای مایکروسرویس‌ها الزامی نیست و ممکن است برخی یا همه سرویس‌های یک سیستم مایکروسرویس بدون بهره‌گیری از معماری رایانش بدون سرور پیاده‌سازی شوند. به عبارت دیگر، Serverless یک مدل اجرایی است و مایکروسرویس‌ها یک سبک طراحی؛ بنابراین می‌توانند مستقل از هم یا همراه با هم پیاده‌سازی شوند.

جمع‌بندی

در این مطلب بررسی کردیم که معماری Serverless چیست و چگونه کار می‌‌کند. معماری رایانش بدون سرور رویکردی نوین در توسعه و اجرای نرم‌افزار است که با واگذاری مدیریت زیرساخت به ارائه‌دهندگان خدمات ابری، به توسعه‌دهندگان اجازه می‌دهد تمرکز خود را بر طراحی قابلیت‌ها و منطق کسب‌وکار قرار دهند. این مدل با ویژگی‌هایی مانند مقیاس‌پذیری خودکار، پرداخت بر اساس میزان مصرف و ساده‌تر شدن فرایندهای استقرار، به گزینه‌ای جذاب برای بسیاری از سازمان‌ها و استارت‌آپ‌ها تبدیل شده است. با این حال، محدودیت‌هایی مانند وابستگی به ارائه‌دهنده، پیچیدگی در تست و احتمال بروز تأخیر در اجرای اولیه نیز باید در نظر گرفته شود.

در نهایت، انتخاب استفاده از رایانش serverless به نوع بار کاری، نیازهای فنی و مقیاس سیستم بستگی دارد و در بسیاری از پروژه‌ها می‌تواند در کنار معماری‌های دیگر مانند کانتینرها یا ماشین‌های مجازی، بخشی از یک زیرساخت ترکیبی باشد.

The post رایانش Serverless چیست؟ آشنایی با کاربردهای معماری بدون سرور appeared first on بلاگ هم‌روش.

کش‌رجیستری‌های در دسترس

در حال حاضر، پنج کش‌رجیستری زیر قابل استفاده هستند که شامل تعداد قابل توجهی از ایمیج‌های پراستفاده می‌باشند:

hub.hamdocker.ir

mcr.hamdocker.ir

gcr.hamdocker.ir

quay.hamdocker.ir

elastic.hamdocker.ir

این رجیستری‌ها به‌ترتیب به‌عنوان میرور رجیستری‌های معروف (Docker Hub، Microsoft Container Registry، Google Container Registry، Quay و Elastic) عمل می‌کنند.

مشاهده و جست‌وجوی ایمیج‌ها

برای مشاهده‌ ایمیج‌های موجود در هر رجیستری، می‌توانید از رابط کاربری وب استفاده کنید.

مثال: Docker Hub (هم‌داکر)

برای مشاهده‌ی ایمیج‌های موجود در Docker Hub هم‌داکر، به آدرس زیر مراجعه کنید:

https://hub.hamdocker.ir/ui/packages

پس از باز شدن صفحه:

1. روی آیکون ضربدر در گوشه‌ی بالا و سمت راست کلیک کنید.
2. سپس می‌توانید از طریق نوار جستجو، ایمیج مورد نظر خود را پیدا کنید.

سایر رجیستری‌ها

برای سایر رجیستری‌ها نیز ساختار آدرس مشابه است و تنها کافی است /ui/packages را به انتهای دامنه اضافه کنید. به عنوان مثال:

https://mcr.hamdocker.ir/ui/packages

ساختار استفاده از ایمیج‌ها

ایمیج‌های متعلق به یک کاربر مشخص

برای ایمیج‌هایی که متعلق به یک یوزر خاص هستند، از قالب زیر استفاده کنید:

hub.hamdocker.ir/{username}/{imagename:tag}

ایمیج‌های عمومی (Library)

برای ایمیج‌های عمومی Docker Hub، از قالب زیر استفاده می‌شود:

hub.hamdocker.ir/library/{imagename:tag}

مثال:

hub.hamdocker.ir/library/nginx:latest

جایگزینی رجیستری‌ها

برای سایر رجیستری‌ها، کافی است دامنه‌ی اصلی را با معادل هم‌داکر جایگزین کنید.

مثال:

به‌جای:

mcr.microsoft.com/dotnet/aspnet:9.0

از:

mcr.hamdocker.ir/dotnet/aspnet:9.0

استفاده کنید.

کش‌رجیستری پکیج‌ها (repo.hmirror)

علاوه بر ایمیج‌های داکر، کش‌رجیستری repo.hmirror برای مدیریت و دریافت پکیج‌ها نیز ایجاد شده است. در حال حاضر، این کش برای موارد زیر در دسترس است:

npm: repo.hmirror.ir/npm

Python: repo.hmirror.ir/python/simple

Go: repo.hmirror.ir/go

NuGet: repo.hmirror.ir/nuget

Maven:  repo.hmirror.ir/maven

Alpine: repo.hmirror.ir/apk

Debian: repo.hmirror.ir/debian

Ubuntu: repo.hmirror.ir/ubuntu

با استفاده از این میرورها، وابستگی پروژه به منابع خارجی کاهش یافته و پایداری بیلد افزایش می‌یابد.

نحوه استفاده از میرورها در پروژه‌ها و Dockerfile

به‌صورت کلی، هر زبان یا ابزار مدیریت پکیج، یک متغیر محیطی (Environment Variable) یا فایل تنظیمات (Config) برای تعریف میرور دارد. لازم است این تنظیمات در Dockerfile یا کانفیگ پروژه اعمال شوند تا در زمان بیلد، وابستگی‌ها از طریق میرورهای داخلی دریافت شوند.

مثال: (Python pip)

برای پایتون، می‌توان از متغیر محیطی PIP_INDEX_URL استفاده کرد.

استفاده در Dockerfile:

در این حالت، تمامی پکیج‌های پایتون از طریق میرور repo.hmirror.ir دریافت می‌شوند.

FROM python:3.11-slim
#تنظیم میرور pip
ENV PIP_INDEX_URL=https://repo.hmirror.ir/python/simple/
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

FROM python:3.11-slim
#تنظیم میرور pip
ENV PIP_INDEX_URL=https://repo.hmirror.ir/python/simple/
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

نکات مهم درباره‌ فرایند بیلد و دیپلوی

• در صورتی که پروژه دارای وابستگی به اندپوینت‌های خارجی باشد و از میرورها استفاده نشده باشد، فرایند بیلد با خطا مواجه خواهد شد.
• اگر دیپلوی خودکار (Auto Deploy) فعال باشد:
  • هر بیلد، منجر به دیپلوی مجدد اپلیکیشن می‌شود.
  • در صورت شکست بیلد، کانتینر متوقف شده و ممکن است اختلال در سرویس ایجاد شود.
• در صورتی که دیپلوی خودکار غیرفعال باشد:
  • خطای بیلد باعث از کار افتادن اپلیکیشن در حال اجرا نخواهد شد.

بنابراین، توصیه می‌شود پیش از فعال‌سازی دیپلوی خودکار، اطمینان حاصل کنید که تمامی وابستگی‌ها از طریق کش‌رجیستری‌ها و میرورها تأمین می‌شوند.

منابع تکمیلی

برای آشنایی بیشتر با نحوه‌ بیلد اپلیکیشن‌ها در شرایط اختلال اینترنت، مطالعه‌ مستند زیر پیشنهاد می‌شود:

راهنمای بیلد اپلیکیشن در زمان اختلال اینترنت

جمع‌بندی

استفاده از کش‌رجیستری‌ها و میرورهای هم‌داکر و هم‌روش، نقش مهمی در افزایش پایداری، امنیت و سرعت بیلد و دیپلوی اپلیکیشن‌ها دارد. با رعایت ساختارهای معرفی‌شده در این مستند و جایگزینی منابع خارجی، می‌توانید از بروز خطاهای بیلد و اختلال در سرویس جلوگیری کنید.

The post راهنمای استفاده از کش‌رجیستری‌ها و میرورها در شرایط قطعی اینترنت appeared first on بلاگ هم‌روش.

Supabase با تکیه بر PostgreSQL و رویکرد متن‌باز، به‌عنوان یک جایگزین جدی برای Firebase مطرح شده و به‌ویژه برای پروژه‌هایی که به داده‌های رابطه‌ای و کنترل بیشتر روی بک‌اند نیاز دارند، کاربرد زیادی دارد.

Supabase چه نیازی را برطرف می‌کند؟

سوپابیس دقیقاً برای جایی ساخته شده که سرعت توسعه به یک مزیت رقابتی تبدیل می‌شود. زمانی که تیم‌ها نمی‌خواهند هفته‌ها درگیر پیاده‌سازی و نگه‌داری بک‌اند شوند، Supabase مسیر را کوتاه می‌کند. با آماده بودن زیرساخت‌های اصلی، تمرکز از «چطور بسازیم» به «چی بسازیم» منتقل می‌شود. نتیجه، لانچ سریع‌تر محصول و حرکت چابک‌تر در مسیر رشد است.Supabase در عین حال که برای بالا آوردن یک MVP سریع است. برای محصولات جدی و مقیاس‌پذیر، نیز یک انتخاب آینده‌نگرانه است.

ویژگی‌های کلیدی Supabase

۱- پایگاه داده PostgreSQL

مهم‌ترین مزیت Supabase این است که هسته‌ آن PostgreSQL است که یکی از محبوب‌ترین دیتابیس‌های جهان می‌باشد

مزایای کلیدی:

• SQL واقعی: کوئری‌های پیچیده، JOIN، Subquery و Viewها
• روابط (Relationships) بین جداول به‌صورت Native
• اگر Postgres بلد باشید، Supabase را بلدید
• قابل مهاجرت: دیتای شما قفل یک فرمت اختصاصی نیست

۲- احراز هویت (Authentication)

Supabase از پروژه‌ی متن‌باز GoTrue برای احراز هویت استفاده می‌کند و امکانات زیر را ارائه می‌دهد:

• ثبت‌نام و ورود با ایمیل/پسورد
• Google and Github Auth
• JWT-based Auth
• یکپارچگی آن با فیچر RLS یا Row-Level Security

با RLS می‌توانید مستقیماً در دیتابیس مشخص کنید چه کسی به کدام ردیف داده دسترسی دارد؛ بدون نیاز به نوشتن Middlewareهای پیچیده، این امکان در اختیار شما است.

۳- Real-time

Supabase می‌تواند به تغییرات دیتابیس گوش دهد و آن‌ها را به‌صورت Real-time به کلاینت ارسال کند.

کاربردها:

• چت آنلاین
• داشبوردهای زنده
• Notification سیستم‌ها

این قابلیت از طریق replication و WebSocket پیاده‌سازی شده و مستقیماً به Postgres متصل است.

۴- Storage و Edge Functions

• Storage:
  مدیریت فایل‌ها (عکس، ویدئو، PDF و …) با API ساده و کنترل دسترسی مبتنی بر Auth و RLS
• Edge Functions:
  اجرای توابع Serverless نزدیک به کاربر، مناسب برای:
  • Logicهای سبک
  • اعتبارسنجی و پردازش سریع

۴- Log and Monitoring

نسخه‌ Supabase همچنین این امکان را فراهم می‌کند که لاگ تمامی کامپوننت‌ها به‌صورت متمرکز در داشبورد اختصاصی Supabase قابل مشاهده باشند؛ به‌طوری‌که توسعه‌دهندگان بتوانند به‌راحتی لاگ‌ها را بررسی، عیب‌یابی و پایش کنند.

مقایسه Supabase با Firebase

سوپابیس One-click هم‌روش

در حالی‌که نسخه‌های Self-Hosted و Cloud سوپابیس هرکدام مزایا و محدودیت‌های خود را دارند، نسخه‌ one-click هم‌روش تلاش می‌کند بهترین ویژگی‌های هر دو را در یک راه‌حل یکپارچه ارائه دهد. در این مدل، Supabase روی زیرساخت پایدار و اختصاصی هم‌روش و در بستر Kubernetes اجرا می‌شود؛ به همین دلیل پایداری، مقیاس‌پذیری و در دسترس‌بودن سرویس به‌صورت تضمین شده است.
برای تیم‌هایی که می‌خواهند از Supabase در محیط پروداکشن استفاده کنند و در عین حال دغدغه‌ پایداری سرویس را نداشته باشند، سوپابیس هم‌روش یک انتخاب آماده و مطمئن است. اجرای سرویس روی Kubernetes تضمین می‌کند که حتی در شرایط بار بالا یا خطاهای مقطعی، سرویس در دسترس باقی بماند و تیم‌ها بتوانند تمام تمرکز خود را نه در مدیریت زیرساخت بلکه روی توسعه‌ محصول بگذارند.

The post  Supabase چیست و چه کاربردی دارد؟ appeared first on بلاگ هم‌روش.

در ادامه، نگاهی می‌اندازیم به این‌که چگونه n8n از یک ابزار هابی فراتر می‌رود و به بخشی واقعی از زیرساخت تولید و تصمیم‌گیری در شرکت‌ها تبدیل می‌شود.

از تست تا پروداکشن؛ تغییر معماری در استقرار n8n

اجرای n8n در محیط تست، معمولاً ساده و سریع است. چند دستور نصب، یک کانتینر Docker، و جریان‌ها آماده اجرا هستند. در این مرحله، تمرکز روی تجربه اولیه و اثبات ایده است؛ اگر چیزی از کار بیفتد یا داده‌ای از بین برود، تأثیر جدی بر کسب‌وکار ندارد.

اما استقرار در محیط پروداکشن داستان دیگری دارد. اینجا هدف فقط «بالا آمدن» سرویس نیست؛ پایداری، امنیت، قابلیت بازیابی و مقیاس‌پذیری به اولویت‌های اصلی تبدیل می‌شوند. هر گردش‌کاری (workflow) که پیش‌تر آزادانه و بدون محدودیت اجرا می‌شد، حالا باید تحت سیاست‌های امنیتی و ساختارهای کنترلی مشخص پیاده شود.

این تغییر پارادایم یعنی تصمیمات اجرایی از جنس مهندسی زیرساخت می‌شوند: معماری باید قبل از نصب طراحی شود، پایگاه داده و ذخیره‌ساز باید جداگانه و ایمن نگه‌داری شود و مکانیزم‌های مانیتورینگ و پشتیبان‌گیری از روز اول فعال باشد. در غیر این صورت، n8n همچنان در همان نقش آزمایشگاهی باقی می‌ماند و ورودش به سطح سرویس سازمانی به تأخیر می‌افتد.

از این نقطه به بعد، n8n دیگر یک ابزار شخصی برای توسعه‌دهنده نیست. بخشی از زیرساخت کسب‌وکار محسوب می‌شود. سرویسی که باید درست مثل دیگر اجزای حیاتی سیستم، مراقبت شود، به‌روزرسانی منظم داشته باشد و در فرایند نگه‌داری سازمانی جای بگیرد. همین تغییر زاویه نگاه است که مسیر اتوماسیون را از سطح آزمایش به سطح تولید واقعی می‌برد. مسیری که در ادامه با مهم‌ترین پایه‌ آن، یعنی معماری استقرار درست، سراغش می‌رویم.

معماری استقرار در محیط پروداکشن: از تک‌سرور تا مقیاس سازمانی

هرچند شروع کار با n8n ساده است، اما رسیدن به سطح پایداری و امنیت لازم برای کسب‌وکار، نیاز به نگاهی کاملاً متفاوت دارد. اینجا دیگر صحبت از نصب روی یک VPS یا حتی یک Docker ساده نیست؛ باید بتوان معماری‌ای پیاده کرد که قابلیت اطمینان، توسعه‌پذیری و مقیاس‌پذیری را تضمین کند.

در نگاه حرفه‌ای، چهار اصل کلیدی در معماری سطح پروداکشن n8n خودش را نشان می‌دهد:

۱. جداسازی اجزای حیاتی
در نسخه‌های ساده n8n، دیتابیس (معمولاً PostgreSQL) و ذخیره‌سازی فایل اغلب روی یک سرور اجرا می‌شود. اما در محیط پروداکشن، این رویکرد ریسک بزرگی دارد: کافی‌ست یکی از سرویس‌ها دچار مشکل شود، کل سرویس n8n مختل می‌شود یا داده‌ای از دست می‌رود. معماری اصولی یعنی جداسازی کامل اجزا؛ دیتابیس باید روی سرور اختصاصی یا سرویس مدیریت‌شده باشد، ذخیره‌سازی فایل‌ها به سمت ذخیره‌ساز مقاوم (مثل S3 یا MinIO) هدایت شود و هر جزء به‌صورت قابل نظارت و ایمن اجرا شود.

۲. انتخاب مدل استقرار: Docker Compose یا Kubernetes

بسته به اندازه سازمان و نرخ رشد نیازها، مدل استقرار فرق می‌کند. برای سازمان‌های کوچک یا تیم‌های توسعه‌، Docker Compose اغلب کفایت می‌کند: راه‌اندازی ساده، مدیریت اجزای اصلی و حداقلی از مقیاس‌پذیری. اما از جایی به بعد، مثلا وقتی حجم کار یا حساسیت دیتا بالا می‌رود، باید به Kubernetes فکر کرد. اینجا، مقیاس‌پذیری، ایزولیشن محیط‌ها، مدیریت خودکار پادها و استفاده از ابزارهایی مثل Helm اهمیت حیاتی پیدا می‌کند.

۳. لایه‌ پراکسی و مدیریت دسترسی

در محیط پروداکشن، قرار نیست n8n مستقیماً از طریق اینترنت در دسترس باشد. راه‌اندازی پراکسی معکوس (مثل Nginx یا Traefik) حیاتی است تا هم بتوان مدیریت ترافیک ورودی را دقیق‌تر انجام داد و هم امکاناتی مثل SSL و محدودیت IP پیاده کرد. لایه پراکسی فرصتی است تا مدیریت session، احراز هویت یکپارچه (SSO) و فیلترهای امنیتی در سطح سازمان پیاده شود.

۴. متغیرهای محیطی و تکرارپذیری استقرار

در محیط پروداکشن، هر تنظیم باید قابل ردیابی و بازتولید باشد. تعریف پارامترهای کلیدی به‌صورت Environment Variables (مثل مسیر ذخیره‌سازی، کلیدهای API، آدرس دیتابیس یا تنظیمات امنیتی) باعث می‌شود پیکره‌بندی سرویس شفاف و تکرارپذیر باشد. به‌جای اعمال تنظیمات دستی در سیستم، نگه‌داری متغیرها در فایل‌های مستند یا سیستم مدیریت پیکره‌بندی (ConfigMap در Kubernetes یا فایل env در Compose) اطمینان می‌دهد هر زمان لازم شد، بتوان همان محیط را سریع و بدون خطا بازسازی کرد. این اصل، ریشه‌ پایداری و انطباق‌پذیری در هر معماری سطح پروداکشن است.

پایداری سرویس و مدیریت محیط اجرایی

وقتی معماری پایه‌ای طراحی و پیاده شد، قدم بعدی حفظ پایداری سرویس در عمل است. در محیط پروداکشن، n8n دیگر یک فرایند ساده Node.js نیست؛ بلکه بخشی از اکوسیستم عملیاتی سازمان است، و باید بتواند مانند هر سرویس حیاتی دیگر در شرایط مختلف پاسخ‌گو باقی بماند.

پایداری یعنی سیستم نه فقط «بالا» بماند، بلکه رفتار قابل پیش‌بینی داشته باشد: اگر خطایی رخ داد، مشخص باشد چه اتفاقی افتاده. اگر بار زیاد شد، منابع مناسب اختصاص داده شود. و اگر محیط نیاز به نگه‌داری داشت، بدون توقف کامل بتوان تغییرات را اعمال کرد. برای رسیدن به این سطح از اطمینان، چند اصل کلیدی وجود دارد که در همه مدل‌های استقرار جدی n8n مشترک‌اند:

۱. پایش سلامت و رفتار سرویس

اولین گام در حفظ پایداری، مانیتورینگ دقیق است. n8n در محیط پروداکشن باید مدام پایش شود: از مصرف CPU و حافظه گرفته تا تعداد گردش‌کارهای (workflow) فعال، مدت زمان اجرای هر job و خطاهای احتمالی. ابزارهایی مثل Prometheus یا Grafana برای جمع‌آوری و مصورسازی این داده‌ها مؤثرند.

به کمک این پایش، تیم می‌تواند قبل از آنکه سرویس دچار بحران شود، نشانه‌های فشار یا ناپایداری را شناسایی کند. در واقع، مانیتورینگ صرفا ابزار گزارش‌گیری نیست، بلکه بخشی از فرهنگ نگه‌داری سرویس است.

۲. مدیریت منابع و مقیاس‌پذیری

n8n با رشد تعداد گردش‌کارها (workflow) و بخش‌های متصل به آن، به‌سرعت مصرف منابع را افزایش می‌دهد. در محیط‌هایی که بر پایه‌ Docker یا Kubernetes طراحی شده‌اند، باید منابع CPU و RAM به‌صورت کنترل‌شده تخصیص داده شوند و محدودیت‌ها (resource limits) مشخص باشد.

در Kubernetes، می‌توان با سیاست‌های Autoscaling سرویس را به شکل انعطاف‌پذیر گسترش داد. این یعنی هر زمان بار کاری افزایش یابد، سیستم خود به‌صورت خودکار پادهای اضافی ایجاد کند و پس از افت بار دوباره جمع شود. به این ترتیب، سرویس از نظر هزینه بهینه می‌شود و در برابر رشد ترافیک ناگهانی هم افت چشمگیری نخواهد داشت.

۳. مکانیزم‌های پشتیبان‌گیری و بازیابی

پایداری واقعی بدون Backup و Disaster Recovery معنایی ندارد. n8n داده‌های حساس ذخیره می‌کند. هر نوع اختلال در پایگاه داده یا فایل‌های ذخیره‌شده می‌تواند کل سرویس را فلج کند.

بنابراین، سیاست پشتیبان‌گیری منظم و آزموده‌شده باید از روز اول فعال باشد. نسخه‌برداری دوره‌ای از دیتابیس Postgres و Sync فایل‌های ذخیره‌شده به فضای امن (S3 یا ذخیره‌ساز آفلاین) ضروری است.

فراتر از گرفتن Backup، باید فرایند بازیابی هم مستند و تست‌شده باشد؛ یعنی تیم بداند اگر حادثه‌ای رخ دهد، دقیقاً چه گام‌هایی لازم است تا سرویس در حداقل زمان ممکن دوباره بالا بیاید.

۴. مدیریت به‌روزرسانی و نسخه‌ها

در محیط پروداکشن، هیچ به‌روزرسانی نباید «در لحظه و بر اساس حدس» انجام شود. هر تغییر نسخه، هر آپدیت Node یا Image جدید، باید از قبل در محیط staging بررسی شود. نسخه‌های جدید n8n معمولاً قابلیت‌های تازه یا تغییرات در ساختار داده دارند، و استقرار غیراصولی آن ممکن است جریان‌های قبلی را بشکند یا رفتار jobها را تغییر دهد.

رویکرد حرفه‌ای این است که فرایند استقرار نسخه جدید به‌صورت تدریجی و قابل بازگشت باشد. ابزارهایی مثل Docker tags یا Helm Releases این کار را راحت می‌کنند.

در مجموع، پایداری یعنی n8n را همچون یک سرویس زنده اداره کنیم، نه یک برنامه‌ نصب‌شده و رهاشده. پایداری حاصل مجموعه‌ای از رفتارهای مداوم است: پایش، نگه‌داری، پشتیبان‌گیری و به‌روزرسانی آگاهانه. سازمان‌هایی که از همان ابتدا این فرهنگ عملی را در تیم خود ایجاد می‌کنند، معمولاً نیمی از چالش‌های پروداکشن را پشت سر گذاشته‌اند.

امنیت: محافظت از قلب زیرساخت اتوماسیون

پایداری بدون امنیت زیربنای محکمی ندارد. اگر معماری و عملیات روزمره‌ n8n بر بستر ناامن اجرا شوند، یک نشتی کوچک می‌تواند کسب‌وکار را به توقف کامل بکشاند. در محیط پروداکشن، امنیت فقط انجام چند کار کوچک فنی نیست؛ امنیت یعنی شناخت تهدیدها، مدیریت دسترسی، و کاهش سطح حمله تا حد ممکن.

۱. احراز هویت و کنترل دسترسی

به‌طور پیش‌فرض، n8n یک مکانیزم احراز هویت داخلی دارد، اما این برای سازمان‌ها کافی نیست. باید دسترسی‌ها بر اساس نیاز واقعی افراد تنظیم شوند (اصل Least Privilege).

در ساختارهای سازمانی، پیاده‌سازی Single Sign-On (SSO) یا اتصال به سرویس‌های احراز هویت متمرکز (LDAP، Keycloak) کمک می‌کند تا مدیریت کاربران یکپارچه شود. علاوه بر این، ایجاد حساب‌های جداگانه برای هر کاربر و ثبت فعالیت‌ها (Audit Log) باعث می‌شود ردگیری تغییرات و اقدامات ساده‌تر و مطمئن‌تر باشد.

2. ایمن‌سازی لایه انتقال داده

تمام ارتباطات با n8n باید از طریق HTTPS با گواهی معتبر انجام شوند. گواهی‌های Let’s Encrypt برای آغاز کار رایگان و عملیاتی‌اند، اما در زیرساخت سازمانی بهتر است فرایند صدور و تمدید گواهی‌ها خودکار باشد.

همچنین، اگر سرویس بین چند محیط (dev، staging، prod) داده مبادله می‌کند، باید مجرای ارتباطی از طریق شبکه‌های خصوصی (VPN یا VPC Peering) انجام شود تا اطلاعات حساس از مسیر اینترنت عمومی عبور نکنند.

3. حفاظت از داده‌های حساس

n8n در پیکره‌بندی خود اطلاعات حساسی ذخیره می‌کند: کلیدهای API، توکن‌های OAuth، اطلاعات دسترسی به دیتابیس‌ها و… . در محیط تولید، این داده‌ها باید به‌صورت رمزنگاری‌شده نگه‌داری شوند.

ذخیره این متغیرها ترجیحاً در Secret Managers (مثل Vault, یا Kubernetes Secrets) انجام شود، نه صرفاً در فایل .env روی سرور. به این ترتیب حتی اگر بخشی از زیرساخت نفوذپذیر شود، اطلاعات حیاتی همچنان محفوظ می‌ماند.

4. محدودسازی سطح حمله

یکی از مزیت‌های اجرای n8n پشت پراکسی معکوس، امکان محدود کردن محل و نوع دسترسی است. با بستن مسیرهای غیرضروری، محدود کردن محدوده IPهای مجاز، و فعال کردن Rate Limiting می‌توان بخشی از حملات brute-force یا موارد دیگر را بی‌اثر کرد.

علاوه بر این، غیرفعال کردن endpointهای پیش‌فرض یا ماژول‌هایی که استفاده نمی‌شوند باعث کاهش تعداد نقاط بالقوه تهدید می‌شود.

5. به‌روزرسانی‌های امنیتی و Patch Management

نسخه‌های جدید n8n نه فقط ویژگی‌های تازه، بلکه اصلاحات امنیتی نیز دارند. در پروداکشن، فاصله بین انتشار آسیب‌پذیری و وصله (Patch) آن باید حداقل شود. برای این کار، فرایند به‌روزرسانی باید مستند، آزمایش‌شده در staging و زمان‌بندی‌شده باشد تا بدون ایجاد downtime ناخواسته اجرا شود.

همین اصل برای وابستگی‌ها (dependencies) و زیرساخت میزبانی هم صادق است؛ گاهی آسیب‌پذیری در Docker base image یا پکیج‌های Node.js پنهان مانده و به‌روزرسانی آن‌ها به همان اندازه حیاتی است که آپدیت خود n8n.

نکته‌ای که باید در خاطر داشته باشید این است که امنیت یک فاز یک‌باره نیست؛ فرایندی مداوم است که با رشد کسب‌وکار و پیچیده‌تر شدن گردش‌کارها باید توسعه یابد. هر گاه امنیت را به‌عنوان بخشی از DNA معماری و عملیات ببینیم، n8n می‌تواند با آرامش خاطر در قلب اتوماسیون سازمانی کار کند.

جمع‌بندی

در نهایت، مسیری که طی کردیم از آماده‌سازی معماری تا امنیت و پایداری، تصویر روشنی از الزامات اجرای n8n در سطح تولید به‌دست می‌دهد. وقتی این اجزا درست کنار هم قرار بگیرند، سرویس نه‌فقط اجرا می‌شود، بلکه قابل اعتماد و قابل نگه‌داری باقی می‌ماند.

برای تیم‌هایی که ترجیح می‌دهند این مجموعه تصمیم‌ها و نگه‌داری روزمره توسط زیرساختی آماده انجام شود، نسخه‌ مدیریت‌شده‌ n8n هم‌روش همان پیاده‌سازی با همان منطق فنی است. اما در قالبی یکپارچه، با امنیت و مانیتورینگ از پیش تنظیم‌شده.

هدف، چه در استقرار مستقل و چه در نسخه‌ مدیریت‌شده، یکی است: داشتن محیطی پایدار و قابل پیش‌بینی برای اجرای اتوماسیون سازمانی، بدون از بین رفتن سادگی و انعطاف‌پذیری اصلی n8n.

The post n8n؛ از دستیار شخصی تا زیرساخت اتوماسیون سازمانی appeared first on بلاگ هم‌روش.

اما نتیجه‌ این تنوع ابزارها، معمولاً چیزی جز پراکندگی جریان کار نیست. نرم‌افزارهایی که قرار بود کار را ساده‌تر کنند، حالا خودشان به مسئله‌ تازه تبدیل شده‌اند؛ سیستم‌هایی جدا از هم که برای اتصالشان باید زمان و انرژی زیادی صرف کنیم.

درست همین‌جا است که خودکارسازی جریان کار (Workflow Automation) معنا پیدا می‌کند؛ اتوماسیون جریان کار (Workflow) راهی برای کنار زدن کارهای تکراری و ساختن اکوسیستم واحدی است میان تمام ابزارهایی که از آن‌ها استفاده می‌کنیم.

یکی از ابزارهایی که این کار را می‌تواند به بهترین شکل ممکن انجام دهد n8n است. n8n پلتفرمی برای خودکارسازی جریان کار است که به شما کمک می‌کند بین سرویس‌های مختلف ارتباط بسازید و کارهای تکراری را به‌صورت خودکار انجام دهید.

در این بلاگ‌پست با n8n آشنا می‌شویم و می‌بینیم چطور این ابزار می‌تواند قطعات پراکنده‌ کار روزانه را به یک جریان یکپارچه تبدیل کند.

n8n چیست؟

n8n ابزاری قدرتمند و متن‌باز برای خودکارسازی جریان کار (Workflow) است. این ابزار به شما کمک می‌کند تا میان برنامه‌های مختلف ارتباط برقرار کنید، کارهای تکراری را خودکار انجام دهید و عملیات روزمره‌تان را بدون نیاز به کدنویسی گسترده ساده‌تر کنید. اگر نام سرویس‌هایی مثل Zapier را شنیده‌اید، درک کاری که n8n انجام می‌دهد برای‌تان آسان‌تر است.

n8n ابزاری است که تقریبا به کار همه می‌آید. نویسندگان، توسعه‌دهندگان، متخصصان مارکتینگ و بسیاری از حوزه‌های دیگر. محیط بصری و مبتنی بر نود (Node) در n8n باعث می‌شود کار با آن بسیار ساده باشد. تصور کنید دارید با لگوهای دیجیتال کار می‌کنید: نودهای مختلف را که هرکدام نمایانگر یک برنامه یا یک اکشن هستند، می‌کشید و رها می‌کنید و بعد آن‌ها را به‌هم وصل می‌کنید تا جریان کاری دلخواهتان ساخته شود.

مفاهیم کلیدی در کار با n8n

برای شروع کار با n8n فقط کافی است چند مفهوم کلیدی را بشناسید. این‌ها همان بلوک‌های سازنده‌ هر جریان کاری در n8n هستند.

نودها (Nodes): نود، واحد پایه در n8n است. هر نود می‌تواند نمایانگر یک اپلیکیشن باشد (مثل Google Sheets، Telegram یا WordPress)، یا یک ابزار درونی (مثل تابعی برای ویرایش داده یا افزودن شرط منطقی)، یا یک تریگر. شما نودها را به مسیر کاری خود اضافه می‌کنید تا عمل خاصی را انجام دهند.

اتصالات (Connections): خطوطی هستند که بین نودها رسم می‌کنید. این خطوط مسیر جریان داده را مشخص می‌کنند. داده از یک نود خارج می‌شود و به‌عنوان ورودی نود بعدی عمل می‌کند؛ به این ترتیب می‌توانید چندین عمل را پشت سر هم زنجیره کنید.

جریان‌ها (Workflows): یک Workflow همان بوم (canvas) کامل است که مجموعه‌ای از نودها و اتصالات را در خود دارد. این تصویر تمامِ فرایند خودکارشده از آغاز تا پایان است. شما می‌توانید در n8n چندین Workflow‌ مختلف داشته باشید که هرکدام وظیفه مستقلی را انجام می‌دهد.

تریگرها (Triggers): نود تریگر نقطه‌ شروع یک Workflow است. رویدادی است که کل فرایند را آغاز می‌کند. تریگرها می‌توانند زمان‌بندی باشند (مثلاً «این جریان را هر دوشنبه ساعت ۹ صبح اجرا کن»)، ورود داده‌ جدید در بانک اطلاعاتی، یا دریافت اطلاعات از یک Webhook.

اعتبارسنجی‌ها (Credentials): برای اینکه n8n بتواند به داده‌های شما در اپلیکیشن‌های دیگر دسترسی داشته باشد (مانند ارسال پیام در کانال Telegram یا افزودن ردیفی به Google Sheet خصوصی‌تان)، باید دسترسی امنی در اختیارش بگذارید. n8n این کلیدها و اطلاعات ورود را به‌صورت رمزنگاری‌شده ذخیره می‌کند تا بتوانید در تمام Workflowهای خود از آن‌ها دوباره استفاده کنید.

کاربردهای n8n

n8n می‌تواند از ساده‌ترین خودکارسازی‌ها تا پیچیده‌ترین یکپارچه‌سازی‌ها را انجام دهد. این ابزار در حوزه‌های مارکتینگ، فروش، عملیات، توسعه، پشتیبانی مشتریان، مالی و موارد دیگر کاربرد دارد.

اتوماسیون مارکتینگ

اتصال میان CRMها، ابزارهای ایمیل، آنالیتیکس و شبکه‌های اجتماعی را برقرار کنید. مثلاً انتشار پست جدید در WordPress می‌تواند به‌صورت خودکار در شبکه‌های اجتماعی سازمان‌تان به اشتراک گذاشته شود.

اتوماسیون فروشگاه‌های آنلاین (eCommerce)

تأیید سفارش‌ها، به‌روزرسانی موجودی و اعلام وضعیت ارسال را خودکار کنید. برای مثال با تکمیل خرید در فروشگاهتان، n8n می‌تواند داده‌های این خرید را در Google Sheets به‌روزرسانی کند و تیم مسئول ارسال را در کانال Telegram مطلع سازد.

هماهنگ‌سازی فروش و CRM

ورود لیدها را به شکل خودکار ثبت کنید. مثلاً پر شدن یک فرم در Typeform می‌تواند منجر به ساخت کانتکت در CRM، ذخیره داده در Google Sheets و ارسال اعلان به کارشناس فروش در Telegram شود.

جریان‌های کاری توسعه‌دهندگان (Developer Workflows)

GitHub را با ابزارهای مدیریت پروژه پیوند دهید. مثلاً ایجاد یک issue جدید در GitHub می‌تواند به‌صورت خودکار کارت مربوطه را در Jira بسازد و در Telegram پیام اطلاع‌رسانی ارسال کند.

پایپ‌لاین‌های داده و فرایندهای ETL

استخراج، فیلتر و بارگذاری داده‌ها را خودکار کنید. مثلاً داده‌های نظرسنجی در Google Sheets را تمیز کنید و در پایگاه داده PostgreSQL ذخیره نمایید.

اتوماسیون پشتیبانی مشتریان

با استفاده از n8n در پلتفرم پشتیبانی کسب‌وکارتان می‌توانید به‌صورت خودکار تیکت‌ها را به اوپراتور مربوطه اختصاص دهید و اعلان‌های مربوط به آن را در Telegram برای تیم مناسب بفرستید.

اتوماسیون مالی و اداری

هنگامی‌که پرداختی انجام شد، به‌طور خودکار فاکتور ایجاد و ارسال شود و سپس نسخه‌ای از آن در Google Drive ذخیره گردد.

وظایف زمان‌بندی‌شده و هشدارها

گزارش‌ها و یادآوری‌ها را زمان‌بندی کنید. مثلاً هر دوشنبه گزارش هفتگی فروش ایجاد و از طریق ایمیل ارسال شود.

یکپارچه‌سازی SaaS و جریان‌های کاری محصول

فرایند آغاز همکاری (Onboarding) کاربران را خودکار کنید. ثبت‌نام جدید می‌تواند ورودی دیتابیس بسازد، ایمیل خوش‌آمد ارسال کند، وضعیت را در Notion به‌روزرسانی کند و تیم موفقیت مشتری را باخبر سازد.

کاربرد در آموزش و پروژه‌های شخصی

درس‌ها و فایل‌های آموزشی را سازمان‌دهی کنید؛ مثلاً پیوست‌های ایمیل با برچسب خاص به‌صورت خودکار در Google Drive ذخیره شوند.

همان‌طور که می‌بینیم، n8n تقریباً در هر بخش از کسب‌وکار جای خودش را باز می‌کند. حالا بیایید ببینیم چطور می‌توانیم از آن در عمل استفاده کنیم.

چطور از n8n استفاده کنیم؟

برای شروع کار با n8n دو روش اصلی وجود دارد: نسخه سلف‌‌هاست (Self‑Hosted) و نسخه ابری (Cloud).

نسخه Self‑Hosted:

در این حالت، شما n8n را روی سرور یا محیط دلخواه خود نصب می‌کنید — از Docker گرفته تا VPS یا حتی محیط محلی. کنترل کامل داده‌ها، تنظیمات امنیتی و نحوه اجرا در دست شماست. این گزینه برای تیم‌هایی مناسب است که دوست دارند اتوماسیون‌ها را در بستر داخلی خودشان اجرا کنند.

نسخه Cloud:

اگر به‌دنبال شروع سریع‌تر و بدون دردسر مدیریت سرور هستید، نسخه n8n Cloud بهترین گزینه است. تنها با ساخت حساب کاربری می‌توانید جریان‌های کاری خود را طراحی، اجرا و مانیتور کنید، بدون آن‌که درگیر پیکربندی یا به‌روزرسانی فنی شوید. البته با توجه به مشکلات مربوط به تحریم یا قطعی اینترنت، این گزینه ممکن است در شرایط خاص مشکلاتی برای کسب‌وکار شما پیش بیاورد.

در بخش بعدی، به n8n مدیریت‌شده‌ی هم‌روش می‌پردازیم؛ راه‌حلی که مزایای سلف‌‌هاست را با سادگی و اطمینان نسخه ابری ترکیب می‌کند.

n8n مدیریت‌شده هم‌روش

در حالی‌که نسخه‌های Self‑Hosted و Cloud هرکدام مزایای خود را دارند، نسخه‌ n8n مدیریت‌شده‌ هم‌روش تلاش می‌کند بهترین ویژگی‌های هر دو را در یک راه‌حل ترکیب کند. در این مدل، n8n روی زیرساخت اختصاصی و پایدار هم‌روش اجرا می‌شود، اما همچنان کنترل و انعطاف نسخه‌ سلف‌ هاست را حفظ می‌کند.

تیم هم‌روش تمام نگه‌داری، به‌روزرسانی و امنیت سرور را بر عهده دارد؛ یعنی بدون درگیر شدن با تنظیمات فنی، همیشه به آخرین نسخه‌ پایدار و امن n8n دسترسی دارید. در عین حال می‌توانید جریان‌های کاری خود را دقیقاً مانند نسخه سلف‌‌هاست طراحی، ویرایش و گسترش دهید.

برای تیم‌هایی که می‌خواهند تأثیر اتوماسیون را در محیط پروداکشن تجربه کنند، بدون هزینه‌های فنی نگه‌داری زیرساخت، n8n مدیریت‌شده‌ هم‌روش گزینه‌ای مطمئن و آماده برای اجراست. یک محیط انعطاف‌پذیر، امن و همیشه در دسترس؛ مخصوص تیم‌هایی که می‌خواهند فقط روی ساخت جریان‌های کاری تمرکز کنند، نه روی مدیریت سرورها.

The post n8n چیست و چطور کار می‌کند؟ appeared first on بلاگ هم‌روش.

در ادامه، بسته به وضعیت و نیاز شما، راهکارهایی برای هر دو دسته اپلیکیشن‌های آماده و اپلیکیشن‌های مبتنی بر گیت یا داکر ارائه شده است.

توصیه مهم: قبل از اعمال هرگونه تغییر، حتماً از سرویس و داده‌های خود بکاپ کامل تهیه کنید تا در صورت بروز مشکل بتوانید به وضعیت قبلی بازگردید.

اپلیکیشن‌های آماده

ایمیج‌های آماده‌ کنسول هم‌روش از سوی تیم فنی هم‌روش اصلاح می‌شود. فقط اگر از MySQL و یا MariaDB استفاده می‌کنید، لازم است وارد اپ شوید و ذخیره تغییرات را بزنید تا ایمیج‌های بیت‌نامی اصلاح شود.

اپ‌های گیتی و داکری

اگر اپلیکیشن‌های شما بر پایه ایمیج‌های گیتی یا داکری است، می‌توانید از دو روش زیر استفاده کنید:

استفاده از ایمیج‌های Bitnami Legacy 

بر اساس اطلاع‌رسانی بیت‌نامی اکثر ایمیج‌ها برای همیشه ذیل bitnamilegacy در دسترس هستند. برای این حالت نیاز است آدرس ایمیج خود را از bitnami به bitnamilegacy تغییر دهید. در این حالت برای مثال ایمیج bitnami/mongodb به ایمیج bitnamilegacy/mongodb تغییر می‌کند.

این روش ساده است و نیازی به تغییر بیشتری ندارد. اما نکنه منفی پیرامون آن این است که دیگر این ایمیج‌ها هیچ آپدیتی دریافت نمی‌کنند(چه از نوع فیچر و چه امنیتی) و در صورتی که آسیب‌پذیری امنیتی حادی گزارش شود با مشکل روبه‌رو می‌شویم.

مهاجرت به ایمیج‌های غیر Bitnami

راهکار دوم، استفاده از ایمیج‌های جایگزین (غیر Bitnami) است. در این حالت لازم است برخی تغییرات در محیط و مسیرهای داده انجام شود:

• بازبینی متغیرهای محیطی (Environment Variables):

 ایمیج‌های جدید معمولاً ساختار متفاوتی برای تنظیمات دارند. باید مقادیر موجود را با داکیومنتیشن ایمیج جدید تطبیق دهید.

• بررسی و تغییر مسیرهای داده (Data Path):

مسیر ذخیره‌سازی داده‌ها در ایمیج‌های جایگزین با Bitnami تفاوت دارد. لازم است مسیر قدیمی را شناسایی کرده و داده‌ها را به مسیر جدید منتقل کنید. برای انجام این کار مراحل زیر را به‌ترتیب انجام دهید:

• گرفتن بکاپ قبل از اعمال تغییرات
• شناسایی مسیر جدید ذخیره دیتا بر اساس ایمیج جدید
• افزودن پارتیشن مربوط به مسیر جدید و پرسیست کردن آن
• تغییر ایمیج اجرایی به sleep با آرگومان یک زمان زیاد
• کپی کردن دیتا از مسیر قدیمی به جدید
• تغییر ایمیج

• بررسی و تغییر پرمیشن‌های مسیرهای داده :

مسیر ذخیره‌سازی داده‌ها در ایمیج‌های جایگزین با Bitnami ممکن است پرمیشن متفاوتی داشته باشند که در صورت لزوم باید آن را اعمال کنید.

جمع‌بندی

اگرچه ایمیج‌های Bitnami مدت‌ها یکی از محبوب‌ترین انتخاب‌ها برای توسعه‌دهندگان بوده‌اند، اما با توجه به توقف پشتیبانی رسمی از ایمیج‌های رایگان، ادامه استفاده از آن‌ها می‌تواند ریسک‌زا باشد. ما به شما توصیه می‌کنیم در کوتاه‌مدت از Bitnami Legacy و در بلندمدت با برنامه‌ریزی مناسب به ایمیج‌های غیر Bitnami مهاجرت کنید تا از امنیت و پایداری سرویس‌های خود اطمینان داشته باشید.

The post نحوه انتقال از ایمیج‌های Bitnami به گزینه‌های جایگزین appeared first on بلاگ هم‌روش.

در هم‌روش راهکارهایی برای مواجه با چنین شرایطی در نظر گرفته‌ایم. در ادامه این مقاله به بررسی این راه‌حل‌ خواهیم پرداخت.

۱. مخزن کدتان را به شبکه داخلی انتقال دهید

طبیعتا در زمان قطعی اینترنت بین‌الملل برای ارتباط با ریپازیتوری کدتان باید مخزن کد را به داخل انتقال دهید. بنابراین پیشنهاد ما این است که در گام اول ریپازیتوری خود را به سرویس گیت‌لب هم‌روش (هم‌گیت) انتقال دهید.

۲. دارکوب را به هم‌گیت خود متصل کنید

پس از انتقال ریپازیتوری به هم‌گیت، باید هم‌گیت‌تان را به دارکوب متصل کنید تا فرایند بیلد اپ از روی هم‌گیت انجام شود. برای انجام این کار وارد قسمت ساخت اپ در دارکوب شوید.
اگر فرایند اتصال را درست طی کرده باشید، لیست این ریپازیتوری‌ها از قسمت هم‌گیت در هنگام ساخت اپ گیتی در دارکوب برای‌تان قابل مشاهده خواهد بود.

۳. در اپلیکیشن مورد نظر، آدرس ریپازیتوری را تغییر دهید

برای تغییر ریپازیتوری، در صفحه تنظیمات اپ یا تب CI/CD آن، ابتدا روی گزینه مداد کنار اسم ریپو کلیک و سپس نسبت به تغییر آدرس اقدام کنید. نهایتا برای اعمال تغییرات جدید، روی گزینه ذخیره تغییرات کلیک کنید.

۴. تغییرات موردنیاز را بر روی داکرفایلتان اعمال کنید

هم‌زمان با تغییر ریپازیتوری اپلیکیشن از سمت پشتیبانی هم‌روش، شما می‌توانید تغییرات مدنظرتان را بر روی داکر فایل موجود در هم‌گیت خود اعمال کنید. در اینجا منظور از تغییرات،‌ حذف بخش‌هایی است که برای اجرا در مرحله بیلد به اینترنت بین‌الملل وابسته است.

همان‌طور که می‌دانید در اغلب بیلدها ما به نصب پکیچ‌های مشخص نیاز داریم. برای رفع این نیاز در شرایط حاضر می‌توانید از راهکار زیر استفاده کنید:

۴.۱. در ابتدا کامند‌های مربوط به نصب پکیج در داکرفایل را کامنت کنید.

۴.۲. برای تامین پکیج‌های موردنیاز از پکیج‌های موجود در بیلدهای قدیمی‌تر استفاده کنید.

برای انجام این کار ابتدا به اپ مورد نظرتان در دارکوب مراجعه کنید.

در قسمت اطلاعات عمومی اپ دارکوبی‌تان، در باکس ایمیج داکری، اطلاعات مربوط به ایمیجی را که در حال حاضر بر روی دارکوب پیاده شده مشاهده می‌کنید. نام ایمیج را به همراه تگ آن از قسمت آبی رنگ، باید به‌عنوان ایمیج پایه در Dockerfile و جلوی کلیدواژه FROM استفاده کنیم. تصویر زیر شروع یک داکرفایل برای اپ پایتونی را قبل و بعد از این تغییرات نشان می‌دهد:

۴.۳. در قدم آخر فقط باید مطمئن شویم که تغییرات کد به‌درستی و کامل روی کد قبلی ایمیج پایه overwrite می‌شود.

نهایتا قبل و بعد یک داکرفایل پایتونی به‌عنوان مثال می‌تواند به این شکل باشد:

قبل از اعمال تغییرات:

بعد از اعمال تغییرات:

در انتها پس از انتقال ریپو و حذف وابستگی‌ها از خارج انتظار داریم که بیلد‌ها با موفقیت و سرعت انجام شوند و تغییرات کد روی اپ‌ها به درستی اعمال شود.

در طول این فرایند، در هر مرحله‌ای اگر نیاز به راهنمایی داشتید یا هر دغدغه‌ای در این زمان با توجه به شرایط داشتید، حتما با پشتیبانی هم‌روش در ارتباط باشید.

The post راهکار build گرفتن از اپ‌ها در شرایط اختلال شبکه بین‌الملل appeared first on بلاگ هم‌روش.

در پی رویدادهای اخیر در کشور عزیزمان، ما در هم‌روش با تمام توان در کنار جامعه فناوری ایران هستیم و همدلی خود را با شما ابراز می‌کنیم. با توجه به شرایط فعلی چند نکته را در خصوص سرویس‌های مستقر در هم‌روش را با شما به اشتراک می‌گذاریم:

بک‌آپ گرفتن

جهت اطمینان از صحت داده‌ها، حتماً امکان بکاپ را از طریق کنسول هم‌روش برای سرویس‌های خود فعال نمایید تا نسخه‌های بکاپ به صورت خودکار تهیه و ذخیره گردند.همچنین در کنسول هم‌روش، امکان دریافت نسخه‌های مختلف بکاپ به صورت مستقیم برای شما فراهم شده است. پیشنهاد اکید ما دریافت نسخه‌های بکاپ و نگهداری به صورت local است تا در صورت بروز مشکل، آخرین نسخه از داده‌های خود را در اختیار داشته باشید. در خصوص استفاده از این امکان، مستنداتی تهیه شده که آن را می‌توانید در بلاگ هم‌روش از این لینک مشاهده نمایید. با این حال، می‌توانید به‌صورت مستقل از ابزارهایی مانند «pgdump»یا «mysqldump» برای تهیه بک‌آپ از دیتابیس‌های خود استفاده کنید.

اختلالات بین‌المللی

در پی بروز برخی اختلالات شبکه‌ای که خارج از کنترل ماست (خصوصاً اتصال به اینترنت بین‌الملل) در روزهای پیش‌رو و با هدف پیش‌گیری از پایین آمدن سرویس، اکیداً پیشنهاد می‌کنیم تا هر گونه وابستگی سرویس‌های خود به سرویس‌های خارج از کشور (نظیر DNS، مخازن کد و فرآیندهای build و دریافت image و موارد مشابه) را بررسی و اولویت‌بندی نموده و در اولین فرصت نسبت به رفع آنها (با انتقال سرویس‌ها به داخل کشور یا رفع وابستگی به سرویس خارجی) اقدام نمایید. در صورت بروز اختلالات گسترده‌ی شبکه یا قطعی دسترسی به اینترنت بین‌الملل از سمت دیتاسنترها یا شرکت ارتباطات زیرساخت، پیگیری برای برقراری مجدد ارتباط با توجه به شرایط فعلی کشور امری دشوار و عملاً خارج از کنترل ما خواهد بود. همچنین، با دنبال کردن صفحه وضعیت شبکه (Status Page) ما، می‌توانید به‌صورت فعالانه و به‌روز از آخرین شرایط شبکه مراکز داده‌ی هم‌روش مطلع شوید. 

اختلالات مرتبط با فرایند build اپلیکیشن

همان‌طور که پیش از این اشاره شد، هنگام قطع اینترنت بین‌الملل پیش آمدن مشکلاتی در فرایند بیلد اپلیکیشن دور از انتظار نیست. برای حل این مشکل تیم فنی هم‌روش راهکاری در نظر گرفته است. برای کسب اطلاعات بیشتر درباره نحوه حل این مشکل می‌توانید بلاگ پست «راهکار بیلد گرفتن از اپ‌ها در شرایط اختلال اینترنت» را مطالعه کنید.

امنیت

همکاران ما در هم‌روش فعالانه در حال بررسی تهدیدها و اقدام برای رفع آن‌ها هستند. اما با توجه به ریسک فزاینده‌ی موجود لطفا رمزهای عبور را تغییر دهید، دسترسی‌ها را بازبینی کنید، سناریوهایی که ممکن است آسیب جدی به کسب و کار شما وارد شود را بررسی کنید و در صورتی که از امنیت سیستم‌های حساس خود مطمئن نیستید برای خاموش کردن آن‌ها در صورت مواجهه با تهدیدها آماده باشید.حتماً توصیه‌ها و مسائل مرتبط با امنیت سرویس، داده‌ها و دسترسی‌ها را بر روی تمامی سرویس‌های خود بررسی و ارزیابی نموده و وضعیت را مرتباً از طریق پایش Logها یا سایر ابزارها و اطلاعات مرتبط امنیتی زیر نظر داشته باشید.

پشتیبانی

در آخر، اطمینان داشته باشید که ما همراه شما و کسب‌وکار شما در این شرایط هستیم و از هیچ کوششی برای کمک و رفع دغدغه‌هایتان دریغ نخواهیم کرد. از این رو هر مشکل یا درخواستی را از طریق سیستم تیکت (console.hamravesh.com/ticketing) با ما در میان بگذارید تا در اولین فرصت بررسی و رسیدگی گردد.

به امید روزهای بهتر برای وطن عزیزمان، ایران

روابط عمومی هم‌روش

The post راهنمای نجات در شرایط بحران appeared first on بلاگ هم‌روش.

دانلود بک‌آپ اپ‌های دیسک‌دار از کنسول هم‌روش

برای دانلود بکاپ دیسک‌های خود مراحل زیر را طی کنید:

۱. ابتدا از طریق کنسول هم‌روش وارد بخش بکاپ شوید.

۲. در این صفحه لیست همه بکاپ‌های خود را می‌توانید مشاهده کنید. این لیست شامل بکاپ اپ‌های دیسک‌دار دارکوبی و دیتابیس‌های عادی است. بکاپ مورد نظر را از داخل لیست پیدا کنید و روی آن کلیک کنید تا وارد صفحه آن بکاپ شوید. (در این جا به صورت نمونه وارد بکاپ دیتابیس postgres-data می‌شویم)

۳. در صفحه مربوط به بکاپ مورد نظر، روی گزینه دانلود بکاپ‌ها کلیک کنید.

۴. حال از داخل باکس زیر، روی «محل ذخیره‌سازی بکاپ‌ها» کلیک کنید. در صفحه‌ی جدید بازشده، برای ورود از نام کاربری و پسورد نمایش‌ داده‌ شده در باکس زیر استفاده کنید.

توجه: لطفا توضیحات داخل باکس زیر را به دقت بخوانید.

۵. در داخل محل ذخیره‌سازی بکاپ‌هافایل‌بروزر لیست بکاپ‌های دیسک مورد نظر نمایش داده شده است. نام هر پوشه زمان بکاپ‌گیری را نشان می‌دهد. بکاپ مورد نظر خود را انتخاب کنید و روی دکمه دانلود که در قسمت بالا‌راست صفحه قرار دارد کلیک کنید.

۶. در آخرین گام فرمت مد نظر خود را انتخاب کنید. با این کار دانلود بکاپ شما آغاز می‌شود.

نکات تکمیلی:

• در نظر داشته باشید که بکاپ‌ هر سرویس شما در دیتاسنتری متفاوت با دیتاسنتر خود سرویس، ذخیره‌سازی می‌شوند.
• هر چند همان طور که از دو تصویر آخر مشخص است شما می‌توانید به پوشه‌های بالاتر (به طور مثال hamravesh-c11) بروید و از این طریق اقدام به دانلود بکاپ‌ها خود بکنید. اما در نظر داشته باشید که مرجع اصلی و لیست کامل بکاپ‌های شما داخل بخش بکاپ در کنسول هم‌روش است. فلذا در صورت عدم مشاهده بکاپ مورد نظر خود در محل ذخیره‌سازی (به علت حضور آن بکاپ در یک محل ذخیره‌سازی دیگر)، مجددا  گام‌های ۱ تا ۶ را جهت دانلود بکاپ مورد نظر خود انجام دهید. 
• پیشنهاد می‌کنیم به صورت همزمان اقدام به دانلود چند بکاپ نکنید.

بک‌آپ‌گیری از دیتابیس‌های PostgreSQL

مقدمه

برای گرفتن بک‌آپ از داده‌های MySQL از ابزار pg_dump  که در پکیج postgresql-client ارائه می‌شود استفاده می‌کنیم. برای نصب این ابزار از این راهنما می‌توانید استفاده کنید.

گرفتن بک‌آپ از دیتابیس‌ها

برای این کار، با در دست داشتن آدرس خارجی سرور دیتابیس، می‌توانید یک دیتابیس خاص را بک‌آپ گرفته و فایل‌های آن را به صورت محلی ذخیره کنید:

علاوه بر آن می‌توانید به صورت زیر از تمام دیتابیس‌های موجود بک‌آپ بگیرید:

در صورتی که قصد بک‌آپ‌گیری از چند تیبل خاص در یک دیتابیس را دارید به صورت زیر عمل کنید:

فشرده‌سازی داده‌ها

توصیه می‌شود برای اینکه داده‌ها حجم کم‌تری را اشغال کنند، آن‌ها را به صورت فشرده ذخیره‌سازی کنید. از روش‌ها و ابزارهای متعددی برای این کار می‌توان استفاده کرد اما معمول‌ترینِ این روش‌ها استفاده از gzip می‌باشد:

بک‌آپ‌گیری از دیتابیس‌های MySQL

مقدمه

برای گرفتن بک‌آپ از داده‌های MySQL از ابزار mysqldump  که در پکیج mysql-client ارائه می‌شود استفاده می‌کنیم. برای نصب این ابزار از این راهنما می‌توانید استفاده کنید.

گرفتن بک‌آپ از دیتابیس‌ها

برای این کار، با در دست داشتن آدرس خارجی سرور دیتابیس، می‌توانید یک دیتابیس خاص را بک‌آپ گرفته و فایل‌های آن را به صورت محلی ذخیره کنید:

علاوه بر آن می‌توانید به صورت زیر از تمام دیتابیس‌های موجود بک‌آپ بگیرید:

در صورتی که قصد بک‌آپ‌گیری از چند تیبل خاص در یک دیتابیس را دارید به صورت زیر عمل کنید:

همچنین می‌توانید با استفاده از یک کوئری، بخشی از داده‌ها را انتخاب کرده و صرفا همان‌ها را در فایل بک‌آپ ذخیره کنید:

mysqldump -h [remote host] -u [username] -p [database name] [table1] --where="WHERE CLAUSE" > [local file name]

mysqldump -h [remote host] -u [username] -p [database name] [table1] --where="WHERE CLAUSE" > [local file name]

فشرده‌سازی داده‌ها

توصیه می‌شود برای اینکه داده‌ها حجم کم‌تری را اشغال کنند، آن‌ها را به صورت فشرده ذخیره‌سازی کنید. از روش‌ها و ابزارهای متعددی برای این کار می‌توان استفاده کرد اما معمول‌ترینِ این روش‌ها استفاده از gzip می‌باشد:

mysqldump -h [remote host] -u [mysql user] -p [database name] | gzip > [local file name]

mysqldump -h [remote host] -u [mysql user] -p [database name] | gzip > [local file name]

The post راهنمای دانلود و گرفتن بک‌آپ‌ appeared first on بلاگ هم‌روش.