រំលងទៅមាតិកា

ស្រទាប់ web លើ Cloudflare Workers

ដំណើរការស្រទាប់ web របស់ Quire ដែលបានកាត់បន្ថយលើ Cloudflare Workers។

មើលជា Markdown

រចនាសម្ព័ន្ធស្ថិតនៅ docs/architecture/23-ops.md ផ្នែក 6។ Workers ដំណើរការស្រទាប់ web ដែលបានកាត់បន្ថយ។ ភាពស្មើគ្នានៃមុខងារលើ Workers នៅក្រៅវិស័យ (PRD ផ្នែក 12)៖ អ្វីដែលគោលដៅនេះមិនអាចធ្វើបានត្រូវបានបដិសេធនៅពេលវាចាប់ផ្តើម ដោយឈ្មោះ។

សភាពក្នុងកំណែនេះ

ការរៀបចំនៅកន្លែង (apps/web/wrangler.jsonc preset cloudflare-module របស់ Nitro ស្ពាន Hyperdrive និងការពិនិត្យការចាប់ផ្តើម)។ Worker ត្រូវការការផ្ទុកឆែកឆេងជាមួយ S3 សម្រាប់ R2 (QUIRE_STORAGE_DRIVER=s3) អ្នកបញ្ជូនផ្ទាល់ឆ្លងកាត់សំណើ (QUIRE_REALTIME_DRIVER=durable_objects ឬ centrifugo) cache ចែករំលែក (QUIRE_CACHE_DRIVER=postgres ឬ valkey) និងអ្នកផ្តល់អ៊ីមែល HTTP។ គ្មានពួកគេ Worker បដិសេធការចាប់ផ្តើម ហើយកំណត់ត្រារបស់វាដាក់ឈ្មោះការកំណត់នីមួយៗ។ អ្នកបញ្ជូន Durable Objects ជាអតិថិជននៃ Worker ផ្ទាល់ក្នុង apps/realtime-worker (Durable Object មួយក្នុងមួយ channel សម្រាប់ការបែងចែក វត្តមាន និងប្រវត្តិ មួយក្នុងមួយនាក់សម្រាប់ការផ្ដាច់)។ ដាក់ស្តារវាជាប់ ដូចខាងក្រោម ឬប្រើ Centrifugo។

ផ្នែកទាំងនេះ

ផ្នែក លើ Cloudflare
web Worker ជាមួយ nodejs_compat
Postgres ខាងក្រៅ ឈានដល់តាម Hyperdrive៖ HYPERDRIVE សម្រាប់តួនាទីកម្មវិធី REPORT_HYPERDRIVE សម្រាប់តួនាទីរបាយការណ៍លើមូលដ្ឋានទិន្នន័យរូបវ័ណ្ឌតែមួយនោះ។ ស្រទាប់ web ចម្លងខ្សែតភ្ជាប់នីមួយៗទៅ DATABASE_URL និង QUIRE_REPORT_DATABASE_URL នៅពេលវាចាប់ផ្តើម
ឯកសារ R2 តាម API S3 របស់វា (S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com)។ binding FILES ភ្ជាប់ bucket
ការងារក្រោយកម្មវិធី pg-boss តាម Hyperdrive នៅពេលការងារត្រូវដាក់ក្នុងបញ្ជីជាមួយការសរសេរ។ ជាមួយ QUIRE_QUEUE_DRIVER=cloudflare លើ worker ជួយ ការងារស្រាល (ការជូនដំណឹង និង webhooks ដែលមិនរៀបចំលំដាប់) ឆ្លងកាត់ Cloudflare Queues ជំនួស ដូច្នេះ Postgres មិនត្រូវបានសួរសម្រាប់ពួកវា។ worker ជួយដំណើរការទាំងពីរ
ផ្ទាល់ក្នុងពេលវេលា Worker ផ្ទាល់ក្នុងពេលវេលា apps/realtime-worker ជាមួយ Durable Objects
worker, scheduler, collab, content, ClamAV, Gotenberg, ffmpeg ម៉ាស៊ីន container ជួយ។ Worker មិនអាចដំណើរការពួកវាបានទេ
ការតាមដាន ការអាចមើលឃើញរបស់ Workers ដែលបើកក្នុង wrangler.jsonc

REPORT_HYPERDRIVE ផ្តល់តួនាទីរបាយការណ៍សម្រាប់មូលដ្ឋានទិន្នន័យរូបវ័ណ្ឌដែល HYPERDRIVE ដាក់ឈ្មោះ។ គោលដៅនេះមិនបម្រើ tenant ដែលខ្ទាស់ទៅមូលដ្ឋានទិន្នន័យរូបវ័ណ្ឌបន្ថែម ដូចដែលបានពិពណ៌នាខាងក្រោម។

អ្វីដែលគោលដៅនេះមិនអាចធ្វើបាន

បដិសេធនៅពេលចាប់ផ្តើម ជាមួយបញ្ហាទាំងអស់រាយក្នុងពេលតែមួយ៖

  • គ្មាន SMTP។ ប្រើអ្នកផ្តល់ HTTP ក្នុង QUIRE_EMAIL_PROVIDER_CONFIG។
  • គ្មានថាសក្នុងស្រុក។ QUIRE_STORAGE_DRIVER ត្រូវតែដាក់ឈ្មោះការផ្ទុកវត្ថុ។
  • គ្មានផ្ទាល់ក្នុងដំណើរការ ឬ cache។ Workers មិនចែករំលែកអង្គចងចាំរវាងសំណើ ដូច្នេះ QUIRE_REALTIME_DRIVER=inprocess និង QUIRE_CACHE_DRIVER=memory ត្រូវបានបដិសេធ។
  • គ្មាន ClamAV, Gotenberg ឬ ffmpeg ក្នុង Worker។ CLAMAV_URL, GOTENBERG_URL និង FFMPEG_PATH ដែលបានកំណត់លើ Worker ត្រូវបានបដិសេធ។ កំណត់ពួកវាលើ worker ជួយជំនួស។
  • គ្មានអង្គការមូលដ្ឋានទិន្នន័យលាក់។ binding Hyperdrive របស់ Worker ជាក់លាន់នៅពេលដាក់ស្តារ ដូច្នេះអង្គការដែលមានមូលដ្ឋានទិន្នន័យផ្ទាល់ទទួលទំព័រ “unavailable here” ច្បាស់។ បម្រើវាពី Compose ឬ Vercel។

ហើយមួយរឿងដែលមិនបានបដិសេធតែត្រូវដឹង៖ ការរៀបចំជាមុន និងការសង់ឡើងវិញឋិតថេរបន្តបន្ទាប់ (incremental static regeneration) មិនដំណើរការលើ Workers ទោះបីឯកសារគំរូនិយាយអីក៏ដោយ។ ផ្លូវនីមួយៗរចនាតាមសំណើ។

លើគោលដៅនេះរក្សា transaction ខ្លី ហើយមិនដែលកាន់មួយឆ្លងកាត់ការហៅបណ្តាញ៖ Hyperdrive កំណត់ឡើងវិញសភាព session នៅពេលការតភ្ជាប់ត្រឡប់ទៅ pool ដូច្នេ់បរិបទ tenant ត្រូវបានកំណត់ក្នុងមួយ transaction។

ការដាក់ស្តារ

  1. បង្កើតធនធាន៖
    bun run --bun wrangler hyperdrive create quire-app --connection-string="postgres://quire_app:...@db.example.com:5432/quire"
    bun run --bun wrangler hyperdrive create quire-report --connection-string="postgres://quire_report:...@db.example.com:5432/quire"
    bun run --bun wrangler r2 bucket create quire-files
    bun run --bun wrangler queues create quire-jobs
    ដាក់ id Hyperdrive ពីរចូល apps/web/wrangler.jsonc។
  2. កំណត់សំណង់ មួយម្តងៗជាមួយ bun run --bun wrangler secret put <NAME> ពី apps/web៖ QUIRE_SECRET_KEY, QUIRE_MASTER_KEY, QUIRE_EMAIL_PROVIDER_CONFIG, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, QUIRE_COLLAB_SIGNING_KEY, QUIRE_REALTIME_WORKER_SECRET។ ការកំណត់ធម្មតា (QUIRE_APP_ORIGIN, QUIRE_CONTENT_ORIGIN, QUIRE_PLATFORM_DOMAINS, QUIRE_DATABASE_ID, S3_ENDPOINT, S3_BUCKET, QUIRE_COLLAB_URL) ចូលក្នុង vars។
  3. សង់ និងដាក់ស្តារពី apps/web៖
    NITRO_PRESET=cloudflare-module bun run build
    bun run --bun wrangler deploy
  4. ដាក់ស្តារ Worker ផ្ទាល់ក្នុងពេលវេលា ជាមួយ QUIRE_REALTIME_WORKER_SECRET នៃស្រទាប់ web និងសំណង់ថូខេនរបស់វាជា QUIRE_REALTIME_TOKEN_SECRET (ស្រទាប់ web ហត្ថលេខាថូខេនផ្ទាល់ក្នុងពេលវេលាជាមួយ QUIRE_REALTIME_TOKEN_SECRET ផ្ទាល់របស់វា ឬជាមួយ QUIRE_SECRET_KEY នៅពេលនោះមិនបានកំណត់ ដូច្នេះប្រើមួយណាដែលវាប្រើ) ហើយកំណត់ QUIRE_REALTIME_WORKER_URL លើស្រទាប់ web ទៅអាសយដ្ឋានរបស់វា៖
    cd apps/realtime-worker
    bun run --bun wrangler secret put QUIRE_REALTIME_WORKER_SECRET
    bun run --bun wrangler secret put QUIRE_REALTIME_TOKEN_SECRET
    bun run --bun wrangler deploy
  5. សម្រាប់ការងារស្រាលលើ Cloudflare Queues បង្កើត queue មួយសម្រាប់ជញ្ជាំងស្រាលនីមួយៗ ហើយកំណត់ទាំងនេះលើ worker ជួយ (ថូខេន API ជាមួយសិទ្ធិអាន និងសរសេរ Queues)៖
    bun run --bun wrangler queues create quire-events-notifications
    bun run --bun wrangler queues create quire-events-notifications-dead
    bun run --bun wrangler queues create quire-events-webhooks
    bun run --bun wrangler queues create quire-events-webhooks-dead
    QUIRE_QUEUE_DRIVER=cloudflare, CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_QUEUES_TOKEN និង QUIRE_QUEUE_PREFIX បើមិនមែន quire-។
  6. ដំណើរការម៉ាស៊ីនជួយដូចក្នុងមគ្គុទ្ទេស Vercel ជំហាន 3។ ការផ្លាស់ប្តូរដំណើរការនៅទីនោះ មុនការដាក់ស្តារ Worker នីមួយៗ។

ការរៀបចំដែលបានបដិសេធបង្ហាញក្នុង bun run --bun wrangler tail ជា “The web tier did not start on cloudflare” បន្ទាប់ដោយការកំណត់នីមួយៗដែលត្រូវផ្លាស់ប្តូរ។

ការរុករក

វាយដើម្បីស្វែងរក…

↑↓ រុករក↵ ជ្រើសរើសEsc បិទ