Դիզայնը նկարագրված է docs/architecture/23-ops.md փաստաթղթի 6-րդ բաժնում։
Workers-ը գործարկում է վեբ շերտի սահմանափակ տարբերակը։ Workers-ում
հնարավորությունների ամբողջական համապատասխանությունը նախատեսված չէ (PRD-ի
12-րդ բաժին)․ այս թիրախում չաջակցվողը գործարկման պահին մերժվում է՝ ըստ անվան։
Այս թողարկման վիճակը
Կարգավորումն առկա է (apps/web/wrangler.jsonc, Nitro-ի
cloudflare-module նախադրված տարբերակը, Hyperdrive կամուրջը և մեկնարկի
ստուգումները)։ Worker-ին անհրաժեշտ է R2-ի համար S3-ին համատեղելի պահեստ
(QUIRE_STORAGE_DRIVER=s3), հարցումներում աշխատող իրական ժամանակի վարորդ
(QUIRE_REALTIME_DRIVER=durable_objects կամ centrifugo), համատեղ
օգտագործվող քեշ (QUIRE_CACHE_DRIVER=postgres կամ valkey) և HTTP էլ․ փոստի
ծառայություն։ Առանց դրանց Worker-ը մերժում է գործարկվել, և մատյանում նշվում է
յուրաքանչյուր կարգավորում։ Durable Objects վարորդը իրական ժամանակի Worker-ի
հաճախորդն է apps/realtime-worker-ում (ալիքի համար մեկ Durable Object՝
տարածման, ներկայության և պատմության համար, և անձի համար մեկ օբյեկտ՝ կապի
անջատումների համար)․ տեղակայեք այն վեբ շերտի հետ միասին՝ ստորև նշված կարգով,
կամ օգտագործեք Centrifugo։
Բաղադրիչներ
Բաղադրիչ
Cloudflare-ում
web
Worker՝ nodejs_compat աջակցությամբ
Postgres
Արտաքին՝ Hyperdrive-ի միջոցով․ HYPERDRIVE՝ հավելվածի դերի, իսկ REPORT_HYPERDRIVE՝ նույն ֆիզիկական բազայի հաշվետվությունների դերի համար։ Վեբ շերտը մեկնարկելիս կապի յուրաքանչյուր տող պատճենում է DATABASE_URL և QUIRE_REPORT_DATABASE_URL փոփոխականներում
Ֆայլեր
R2՝ իր S3 API-ի միջոցով (S3_ENDPOINT=https://<account>.r2.cloudflarestorage.com)․ FILES կապը միացնում է պահեստը
Ֆոնային աշխատանքներ
pg-boss՝ Hyperdrive-ի միջոցով, երբ գրառումը պետք է հերթ դրվի գրելու գործողության հետ։ Ուղեկից աշխատողի վրա QUIRE_QUEUE_DRIVER=cloudflare արժեքի դեպքում թեթև աշխատանքները (չդասակարգված ծանուցումների և վեբհուքների առաքումները) դրա փոխարեն անցնում են Cloudflare Queues-ով, ուստի Postgres-ը դրանց համար չի հարցվում։ Ուղեկից աշխատողը երկուսն էլ գործարկում է
Իրական ժամանակ
Իրական ժամանակի Worker՝ apps/realtime-worker, Durable Objects-ով
REPORT_HYPERDRIVE-ը տրամադրում է հաշվետվությունների դերը HYPERDRIVE-ով
նշված ֆիզիկական բազայի համար։ Այս թիրախը չի սպասարկում լրացուցիչ ֆիզիկական
տվյալների բազաներին ամրագրված հաճախորդների, ինչպես նկարագրված է ստորև։
Ինչ չի կարող անել այս թիրախը
Գործարկման պահին մերժվում են բոլոր խնդիրները, և դրանք թվարկվում են միասին․
Տեղային սկավառակ չկա։QUIRE_STORAGE_DRIVER-ը պետք է նշի օբյեկտների պահեստ։
Նույն գործընթացում իրական ժամանակ կամ քեշ չկա։ Workers-ի հարցումները
ընդհանուր հիշողություն չունեն, ուստի QUIRE_REALTIME_DRIVER=inprocess և
QUIRE_CACHE_DRIVER=memory արժեքները մերժվում են։
Worker-ում ClamAV, Gotenberg կամ ffmpeg չկա։ Worker-ի վրա սահմանված
CLAMAV_URL, GOTENBERG_URL և FFMPEG_PATH արժեքները մերժվում են․ դրանք
սահմանեք ուղեկից աշխատողի վրա։
Նվիրված տվյալների բազայով կազմակերպություններ չկան։ Worker-ի Hyperdrive
կապերը ամրագրվում են տեղակայման պահին, ուստի սեփական բազա ունեցող
կազմակերպության համար ցուցադրվում է հստակ «այստեղ անհասանելի է» էջը։
Սպասարկեք նրան Compose-ից կամ Vercel-ից։
Կա նաև մի բան, որը չի մերժվում, բայց պետք է իմանաք․ նախնական render-ն ու
ինկրեմենտալ ստատիկ վերակառուցումը Workers-ում չեն աշխատում՝ անկախ շրջանակի
փաստաթղթերի պնդումներից։ Յուրաքանչյուր ուղի render է արվում ամեն հարցման
ժամանակ։
Այս թիրախում գործարքները կարճ պահեք և երբեք մի պահեք ցանցային կանչի ընթացքում․
Hyperdrive-ը կապը խումբ վերադարձնելիս վերականգնում է աշխատաշրջանի վիճակը,
ուստի հաճախորդի համատեքստը սահմանվում է յուրաքանչյուր գործարքի համար։
Տեղակայում
Ստեղծեք ռեսուրսները․
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-filesbun run --bun wrangler queues create quire-jobs
Hyperdrive-ի երկու ID-ներն էլ տեղադրեք apps/web/wrangler.jsonc ֆայլում։
Սահմանեք գաղտնի արժեքները՝ մեկ առ մեկ գործարկելով
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-ում։
Կառուցեք և տեղակայեք apps/web թղթապանակից․
NITRO_PRESET=cloudflare-module bun run buildbun run --bun wrangler deploy
Տեղակայեք իրական ժամանակի Worker-ը՝ վեբ շերտի
QUIRE_REALTIME_WORKER_SECRET-ով և դրա token-ի գաղտնի բանալին որպես
QUIRE_REALTIME_TOKEN_SECRET։ Վեբ շերտը ստորագրում է իրական ժամանակի
token-ներն իր սեփական QUIRE_REALTIME_TOKEN_SECRET-ով կամ, եթե այն
սահմանված չէ, QUIRE_SECRET_KEY-ով․ օգտագործեք դրանցից այն մեկը, որն այն
օգտագործում է։ Վեբ շերտում QUIRE_REALTIME_WORKER_URL-ը սահմանեք այդ
ծառայության հասցեով․
cd apps/realtime-workerbun run --bun wrangler secret put QUIRE_REALTIME_WORKER_SECRETbun run --bun wrangler secret put QUIRE_REALTIME_TOKEN_SECRETbun run --bun wrangler deploy
Cloudflare Queues-ում թեթև աշխատանքների համար ստեղծեք մեկ հերթ՝ ըստ
թեթև հերթի տեսակի, և սահմանեք դրանք ուղեկից աշխատողի վրա (հերթերը կարդալու
ու գրելու իրավունքով API token)․
bun run --bun wrangler queues create quire-events-notificationsbun run --bun wrangler queues create quire-events-notifications-deadbun run --bun wrangler queues create quire-events-webhooksbun run --bun wrangler queues create quire-events-webhooks-dead
Սահմանեք QUIRE_QUEUE_DRIVER=cloudflare, CLOUDFLARE_ACCOUNT_ID,
CLOUDFLARE_QUEUES_TOKEN և QUIRE_QUEUE_PREFIX, եթե այն quire- չէ։
Գործարկեք ուղեկից հոսթը ըստ Vercel-ի ուղեցույցի, 3-րդ քայլի։
Միգրացիաներն այնտեղ են գործարկվում՝ Worker-ի յուրաքանչյուր տեղակայումից
առաջ։
Մերժված կազմաձևումը երևում է bun run --bun wrangler tail հրամանի ելքում՝ «The web tier did not start on cloudflare» տողով, որին հաջորդում են փոխելու ենթակա բոլոր կարգավորումները։