App Platform, pag-deploy ng web app gamit ang Git at Docker image

Una, itakda ang source ng app. Pagkatapos mag-order, sabihin sa support page ang GitHub o GitLab repository, o ang address ng container image, at ikokonekta ito ng team namin. Sa repository, awtomatikong natutukoy ang paraan ng build mula sa wika; kung may Dockerfile, susundin ang file na iyon, at ang image na nagawa na ay agad pinapatakbo mula sa address nito.

Susunod, sabihin ang run settings. Ipadala ang port na pinakikinggan ng app, environment variable tulad ng database connection address, at start command, at ilalagay ito ng team namin. Ang password at API key ay inilalagay bilang naka-encrypt na environment variable kaya hindi naiiwan sa code repository. Pagkatapos ng settings, magsisimula ang build, at kapag bumukas ang app, ibibigay namin ang base address.

Panghuli, ikonekta ang sarili mong domain. Sabihin ang domain na gagamitin, ibibigay namin ang record value na ilalagay, at kapag naidagdag mo ang isang record na iyon sa domain management screen, awtomatikong ilalabas at ire-renew ang HTTPS certificate. Pagkatapos noon, tuwing mag-push ng code sa default branch ng repository, mabi-build ang bagong bersyon at ililipat ang access kapag handa na, kaya tuloy tuloy ang serbisyo para sa customer kahit habang nagde-deploy.

Ang pinakamaliit na sukat, App L, ay $25.00 kada buwan na may 2 vCPU at 4GB memory. Ang App XL na may 4 vCPU at 8GB memory ay $45.00, at ang App 2XL na may 8 vCPU at 16GB memory ay $85.00.

Piliin ang laki batay sa memory na ginagamit ng iyong app. Sapat na ang App L para sa Telegram bots at maliliit na API, at ang mga web app na gumagamit ng framework ay bagay sa App XL o App 2XL na may 4GB. Para sa mga serbisyo na maraming user o memory-heavy app tulad ng image processing, piliin ang App 3XL. Maaari mong baguhin ang laki sa ibang pagkakataon batay sa paggamit sa pamamagitan ng pag-request sa support page kapag nakumpirma na ang iyong unang bayad.

Ang pagbabayad ay nangyayari sa bawat billing date. Ang unang buwan ay sisingilin kapag nag-order ka, at ang parehong halaga ay awtomatikong kukunin sa bawat billing date para i-renew. Kung nagpapatakbo ka ng ilang app, ang bawat isa ay may sariling billing date, kaya ang pagkansela lamang ng hindi ginagamit na app sa support page ay hihinto lamang sa bayad ng app na iyon.

Inihahanda ulit ang disk ng app platform tuwing magde-deploy ng bagong bersyon. Kaya ang data na kailangang manatili nang matagal tulad ng member info, order history at file na in-upload ng customer ay karaniwang sine-save sa managed database at object storage. Sa ganitong paghihiwalay, nananatili ang data kahit ilang beses i-deploy ulit ang app.

Ilagay ang mga secret value sa environment variable mula sa simula. Kapag hiwalay ang database address para sa development at production, maide-deploy mo ang parehong code sa test app at production app habang may sariling data ang bawat isa. Kahit magpalit ng key, hindi kailangang baguhin ang code: ipadala ang bagong value sa support page at environment variable lang ang papalitan namin at magre-redeploy.

Mas ligtas ang deploy kung may isang health check address. Kapag nagsimula ang bagong bersyon, tinitingnan ng platform ang address na iyon, at kapag may normal na response, saka ililipat ang access ng customer sa bagong bersyon. Humihinto ang bersyong mali ang settings bago malipat ang access, kaya patuloy na ginagamit ng customer ang dating bersyon.

Kapag may problema, magsimula sa runtime logs. Mag-request sa support page pagkatapos ma-kumpirma ang unang bayad at ipapadala namin ayon sa pagkakasunod ng oras ang mga record na isinulat ng app sa standard output, kaya mabilis mong mahahanap kung aling request ang nag-error. Kung madalas mapuno ang memory at nagre-restart ang app, lumipat sa isang laki na mas malaki. Naitatabi rin ang build logs, kaya kapag pumalya ang deploy, sasabihin din namin kung saang package install ito huminto.