Nang dumating ang oras upang i-deploy ang application sinubukan ko ang AWS, ngunit sa totoo lang ay medyo nabigla ako sa dami ng impormasyon at serbisyong ibinibigay nila, at talagang gusto kong makita ang aking aplikasyon doon sa ligaw. Kaya naabutan ko si Vercel. Higit pa rito, natututo ako tungkol sa Docker at gusto kong isabuhay ang natutunan ko sa ngayon, ito ang tamang pagkakataon. Kilala ang Vercel sa kanilang zero config deployment. Sa ilang pag-click lang maaari mong i-deploy ang iyong application. Maaari mo ring ikonekta ang iyong repository at agad na bubuo at ide-deploy ng Vercel ang iyong proyekto pagkatapos ng bawat commit. Hindi na ito maaaring maging mas maginhawa kaysa doon 😀 . Ang isa pang dahilan kung bakit pinili ko ang Vercel kaysa sa AWS ay ang kanilang 'serverless' function, na ginamit ko upang i-render ang mga documento mula sa aking database sa pamamagitan ng isang Express API. Sa totoo lang, hindi ako makapagreklamo sa kanilang serbisyo. Hindi ako nagkaroon ng anumang mga isyu sa aking proyekto kahit ano pa man. Ang bagay dito ay gusto kong matuto nang higit pa tungkol sa backend ng aking aplikasyon at naisip ko na ang pag-unawa sa deployment nito ay makakatulong sa akin sa bagay na iyon. Nakita ko ang maraming tao na pinipili ang AWS kaysa sa Vercel dahil sa kanilang plano sa pagpepresyo. Hindi ito nalalapat sa aking kaso dahil ang aking aplikasyon ay walang gaanong trapiko at higit sa lahat ay ginagamit ko ito para sa mga layunin ng pag-aaral. Ngunit magandang banggitin na ang Vercel ay may "isyu" na may pagtaas pagdating sa pagpepresyo. Ang application ng Toronto Food Basket ay maaaring hatiin sa tatlong magkakaibang bahagi: Webscraper para sa pangangalap ng impormasyon mula sa isang lokal na grocery store Express API na nag-aayos ng impormasyon at maaaring magsagawa ng mga mathematical operations para magawa ito. React app na nag-render ng application at lahat ng kinakailangang impormasyon. Sa ngayon, idini-deploy ko lang ang Webscraper sa AWS dahil kailangan ko pang matuto nang higit pa tungkol sa mga server at ruta para i-deploy ang Express API at ang React app. Upang magsimula, naglunsad ako ng isang instance ng AWS EC2 at nagtakda ng alarma sa badyet upang anumang oras na lumampas sa $0.01 ang paggastos sa aking instance ay nakakatanggap ako ng notification - nalaman ko na ang mahirap na paraan pagkatapos masingil para sa isang DocumentDB instance na pinatakbo ko sa aking account mula noong Disyembre /2023 at walang ideya 😂. Nagbibigay ang Amazon ng mga libreng tier na may 750 oras ng t2.micro (o t3.micro sa Mga Rehiyon kung saan hindi available ang t2.micro), 30Gib ng EBS storage, 2 milyong IO, 1 GB ng mga snapshot at 100 GB ng bandwidth sa internet. Habang natututo kung paano i-deploy ang aking dockerized na application sa AWS napagtanto ko na mayroong hindi bababa sa dalawang magkaibang mga diskarte - maaaring mayroong higit pa: buuin ang docker container nang lokal at ipadala lamang ang container sa AWS. ipadala ang lahat sa AWS at buuin ang aking lalagyan nang malayuan. Pinili ko ang pangalawang diskarte dahil gusto kong magkaroon ng karanasan sa paggawa ng ganap na malayo sa aking aplikasyon kung kailangan ko. Hindi ako palaging nasa sarili kong computer at ang pagkakaroon ng aking aplikasyon sa isang EC2 instance ay talagang madaling gamitin sa mga sitwasyong iyon. Gayundin, mapipilitan akong magtrabaho kasama si Vim, na isang bagay na matagal ko nang gustong gawin. Bago ipadala ang mga file sa aking EC2 instance inihanda ko ang aking malayong kapaligiran sa pamamagitan ng pag-install ng Node.js at Docker. Upang maipadala ang mga file sa aking EC2 instance ginamit ko ang Secure Copy Protocol (scp). Ang utos ay mukhang ganito: scp -i ubuntu.pem -r LOCAL_DIRECTORY ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws : Tinutukoy ng watawat na ito ang file ng pagkakakilanlan (pribadong key) na gagamitin para sa pagpapatunay ng pampublikong key. Sa kasong ito, ay ang pribadong key file na ginamit upang patotohanan sa malayong server. -i ubuntu.pem ubuntu.pem : Ang flag na ito ay nagpapahiwatig na ang operasyon ay dapat na recursive, ibig sabihin ay kokopyahin nito ang mga direktoryo at ang kanilang mga nilalaman nang recursively. -r : Ito ang detalye ng patutunguhan. Kabilang dito ang username ( ) at ang IP address ( ) ng remote server, na sinusundan ng path ng direktoryo ( ) kung saan kokopyahin ang mga file. ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws ubuntu 35.183.21.127 /home/ubuntu/downloads Kapag nailipat na ang lahat ng file sa aking EC2 instance, nagawa kong buuin ang aking docker container. At dito nagsimula ang mga bug - yay! Ang pinakamahalagang library ng aking Webscraper ay Puppeteer, na nagbibigay ng mataas na antas ng API para makontrol ang Chrome/Chromium sa DevTools Protocol. Tumatakbo ang Puppeteer sa mode na walang ulo, na ginagawang mas mabilis ang pagpapatupad nito. Ngunit nang sinusubukan kong i-dockerize ang aking aplikasyon ay nakatagpo ako ng ilang mga isyu: Bilang default, kapag na-install ang Puppeteer, dina-download nito ang Chrome for Testing at isang chrome-headless-shell binary. Ang browser ay dina-download sa $HOME/.cache/puppeteer folder. Ang problema ay ang AWS ay hindi kasama ang isang $HOME/.cache sa Ubuntu instance nito. Nalaman ko ang isyung ito pagkatapos ng ilang pananaliksik, at para malutas ang kailangan ko lang gawin ay ilipat ang /.cache folder sa root directory - ang isyung ito ay mahusay na naidokumento sa npm portal ng Puppeteers. Isang halatang bagay na hindi ko napagtanto ay na hanggang ngayon ay pinapatakbo ko ang aking aplikasyon sa OS tulad ng Windows at MacOs.. Ngunit ngayon ay nakikipag-ugnayan ako sa Ubuntu. At dahil isa itong walang laman na instance wala itong na-pre-install na package/app, ito ang dahilan kung bakit nag-install ako ng node at docker sa sandaling patakbuhin ko ang instance sa unang pagkakataon. Ngunit nakalimutan ko ang isang talagang mahalagang application para gumana ang aking Webscraper: Google Chrome. Tandaan ang sinabi ko tungkol sa Puppeteer dati? Kaya, kailangan kong tiyakin na mayroon akong tamang bersyon ng Chromium sa aking instance . Ang bawat pangunahing bersyon ng Node.js ay binuo sa isang bersyon ng Debian, at ang bersyon ng Debian na iyon ay may kasamang lumang bersyon ng Chromium, na kung minsan ay hindi tugma sa pinakabagong bersyon ng Puppeteer. Pagkatapos ng ilang pananaliksik, nalaman kong kailangan kong magsama ng pagtuturo sa aking Dockerfile upang ma-download ang tamang bersyon ng Chromium bago i-install ng Docker ang lahat ng mga dependency ng aking app at patakbuhin ito. Ang aking Docker file ay mukhang ganito: Matapos ayusin ang nakaraang isyu ay may isa pang lumabas. Ngayon ang mensahe ng error ay nagsasaad: "Walang magagamit na sandbox". Para ayusin ang kailangan ko lang gawin ay baguhin ang aking code at magsama ng –no-sandbox argument sa puppeteer.launch() function para sa bawat isa sa aking mga produktong grocery. Tapos na. Ngayon ang aking Webscraper ay tumatakbo sa isang lalagyan sa aking AWS EC2 instance. Hindi nito masisira ang lahat ng 65 na produkto.. Pagkatapos ng ikalimang produkto, nag-crash ang app. Naniniwala ako na ito ay may kinalaman sa mga magagamit na mapagkukunan na mayroon ako sa pagkakataong ito - nahaharap ako sa parehong problema kapag pinapatakbo ang scraper na may mga pagkilos na github. Anyway, ang layunin ko ay maglunsad ng isang AWS EC2 instance at patakbuhin nang malayuan ang aking application, at ginawa ko. Maraming darating!
