انتقل إلى المحتوى
use-cases / move-200gb-between-clouds-with-two-curls / hero
PIPE · هجرة عبر السحب

انقل 200 جيجابايت بين السحب بأمر curl واحد على كل طرف

نسخة احتياطيّة لـ Postgres بحجم 200 جيجابايت في فرانكفورت. صندوق جديد في سنغافورة. تتجاوز رحلة S3. أمر curl واحد يُمرِّر pg_dump إلى رابط Hoody Pipe؛ أمر curl على الجانب الآخر يبثّه مباشرةً إلى psql. البايتات في الطيران، لا في الراحة.

اقرأ توثيق Pipe
use-cases / move-200gb-between-clouds-with-two-curls / mechanism

ليس دلواً. إنّه موجِّه.

Hoody Pipe مسارٌ مُسمّى على خادم HTTP. المرسِل يُرسل بثّاً إليه بـ PUT، المستقبِل يطلب نفس المسار بـ GET، والخادم يصل الاثنين. لا شيء يُكتب على القرص؛ الأنبوب يحتفظ بصفر بايت بحكم التصميم.

البايتات بين أمرَي curlTTL 5 دقائق · لا طبقة تخزين
01 · المرسِل

PUT إلى المسار

من صندوق المصدر، pg_dump | gzip | curl -T - إلى رابط الأنبوب. جسم PUT يُبثّ بأقصى ما يسمح به الضغط العكسي لـ TCP. الخادم يحتفظ بالاتّصال حتى يظهر مستقبِل على نفس المسار.

PUT /api/v1/pipe/migration
02 · الموجِّه

وصل في الذاكرة

حين يصل GET المستقبِل إلى نفس المسار، Hoody يصل بايتات الرفع مباشرةً إلى استجابة التنزيل. لا ذاكرة وسيطة، لا قرص مرحلي، لا التزام غير متزامن — فقط بثّ مباشر بين مقبسَي HTTP.

0 بايت على القرص
03 · المستقبِل

GET كبثّ

من صندوق الوجهة، curl يطلب المسار ويُمرِّر الاستجابة عبر gunzip | psql. بثّ جانب المستقبل ينتهي لحظة وصول آخر بايت من المرسِل. لا إعادة محاولة، لا بيان، لا تنظيف.

GET /api/v1/pipe/migration

ترتيب الاتّصال غير مهمّ — يستطيع المستقبِل أن يُرسل curl أوّلاً وينتظر حتى يتّصل المرسِل (أو العكس)، حتى TTL الأنبوب البالغ 5 دقائق. الضغط العكسي يتدفّق من طرف لطرف: psql بطيء يخنق curl على المصدر. لا طابور يمكن أن يفيض لأنّه لا يوجد طابور.

use-cases / move-200gb-between-clouds-with-two-curls / commands

الأمران الفعليّان

هذه ليست شيفرة وهميّة. افتح طرفيتين على الخادمَين، شغّل أمراً واحداً على كلٍّ، وشاهد نسخة احتياطيّة 200 جيجابايت تغادر سحابة وتصل إلى أخرى.

frankfurt:~ · المرسِل
PUT · المرسِلفرانكفورت → الأنبوب
# 1. بث قاعدة البيانات الحية إلى الأنبوب$pg_dump --format=custom mydb | gzip \ | curl -T - https://pipe.containers.hoody.com/api/v1/pipe/migration# 2. الخادم يرد برسائل الحالة[INFO] انتظار 1 جهة استقبال للاتصال...[INFO] البث إلى 1 جهة استقبال...[INFO] Upload complete.[INFO] Transfer complete.
singapore:~ · المستقبِل
GET · المستقبِلالأنبوب → سنغافورة
# 1. الأنبوب مباشرة إلى قاعدة البيانات الجديدة$curl https://pipe.containers.hoody.com/api/v1/pipe/migration \ | gunzip | psql newdb# 2. Bytes hit psql as they leave FrankfurtCREATE TABLE okCOPY 4823918 okALTER TABLE ok

PUT (curl -T) مُفضَّل لأنّه الطريقة التي يريد بها curl رفع بثّ. POST يعمل بنفس الطريقة — نفس المسار، نفس رسائل الحالة. استخدم ?n=N على الجانبَين إن أردت تفرّع نفس النسخة إلى مستقبِلين كثر.

use-cases / move-200gb-between-clouds-with-two-curls / spectator
تقدّم · ?progress

رابط متفرِّج يستطيع الجميع مشاهدته

حاسوب محمول ثالث يفتح نفس رابط الأنبوب مع ?progress فيحصل على تغذية SSE فوريّة بالبايتات في الثانية والزمن المتبقّي والمستقبِلين المتّصلين. المشاهدة لا تستهلك خانة مستقبِل — خمسون زميلاً يستطيعون مشاهدة الهجرة دون تغيير قيمة n أو التدخّل في النقل.

  • لا خانة مستقبِل
  • حتى 50 متفرّجاً
  • بقاء 30 دقيقة
spectator.…hoody.com/migration?progress
SSE · text/event-streamبثّ مباشر
event: statedata: ["state":"streaming","receivers":1]event: progressdata: ["bytes":83_421_667_840, "speed":"412 MB/s", "eta":"4m 44s"]event: progressdata: ["bytes":118_295_117_824, "speed":"406 MB/s", "eta":"3m 21s"]↻ مباشر · خنق 250 ms
use-cases / move-200gb-between-clouds-with-two-curls / why

لماذا أمران curl يهزمان ست خطوات

رحلة S3 تبدو بسيطة على لوحة بيضاء. في الإنتاج إنّها كومة من القطع المتحرّكة، كلّها تتقاضى بالثانية. الأنبوب يطوي الكومة كلّها داخل النقل ذاته.

لا طبقة تخزين ثالثة

S3، GCS، Azure Blob — رحلة الذهاب والإياب موجودة فقط لأنّه لم يكن هناك مكان آخر لتركن البايتات. الأنبوب هو المسار. لا دلو يجب توفيره، لا قاعدة دورة حياة، لا تنظيف لاحق.

ادفع للطيران، لا للراحة

خروج عند الرفع، خروج عند التنزيل — مرّتان. مع الأنبوب، البايتات تغادر فرانكفورت وتصل سنغافورة في قفزة واحدة. أنت تدفع للثواني التي كان فيها الاتّصال مفتوحاً، لا لتخزين ستحذفه غداً.

HTTP حتى الأعماق

مراقبتك تفهم HTTP أصلاً. وكذلك VPN، وجدارك الناري، وسجلّ التدقيق. لا هويّة IAM جديدة، لا SDK جديد، لا وضع فشل جديد — إنّه أمر curl.

البُعدرحلة S3HOODY PIPE
  • الخطوات6 مراحلأمرا curl
  • قرص مُستخدَم200 جيجابايت0 بايت
  • أرجل الخروج2 × 200 جيجابايت1 × 200 جيجابايت
  • تنظيفقاعدة دورة حياةلا شيء

السرعة محدودة بأبطأ رابط من طرف لطرف (خروج فرانكفورت، دخول سنغافورة، نافذة TCP لديك). أنبوب Hoody يحتفظ بصفر بايت — لا تخزين على الخادم؛ الضغط العكسي يتدفّق مباشرةً بين الطرفين.

use-cases / move-200gb-between-clouds-with-two-curls / punchline

طرفيّتان، رابط واحد، لا طبقة تخزين ثالثة.

كل الهجرة لها نفس شكل cat file | wc -l. كون الأنبوبَين يقعان في مراكز بيانات مختلفة هو تفصيل تنفيذ للرابط.

  • صفر قفزات
  • صفر احتفاظ
  • رابط واحد
اقرأ API
use-cases / move-200gb-between-clouds-with-two-curls / replaces

ما يستبدله هذا

أيّ شيء وُجد فقط لأنّه لم يكن لدى أحد مسار HTTP يبثّ. الأنبوب يطوي حزمة هجرة البيانات بأكملها في أمر curl واحد على كل جانب.

  • نسخ AWS S3 عبر المناطقخروجان، دلو واحد، قواعد دورة حياة
  • نقل Dropbox200 جيجابايت تجلس على قرص شخص آخر أسبوعاً
  • تسليم Google Driveحدود حصص، روابط مشاركة، تنظيف يدوي
  • rsync عبر SSHSSH بين سحب عشوائيّة = حصون وتبديل مفاتيح
  • SCP + استئنافعمليّة واحدة، لا تفرّع، تنكسر مع روابط متذبذبة
  • أدوات هجرة بيانات من طرف ثالثبائع كامل لـ curl بخطوات إضافيّة
use-cases / move-200gb-between-clouds-with-two-curls / cta

تجاوز الدلو. النقل هو الرابط.

اقرأ Pipe API
use-cases / move-200gb-between-clouds-with-two-curls / related

اقرأ الآخرين