Калі прыйшоў час разгортваць прыкладанне, я паспрабаваў AWS, але, шчыра кажучы, быў у захапленні ад колькасці інфармацыі і паслуг, якія яны прадастаўляюць, і мне вельмі хацелася ўбачыць сваё прыкладанне ў дзікай прыродзе. Так я наткнуўся на Vercel. У дадатак да ўсяго, я вывучаў Docker і хацеў прымяніць на практыцы тое, што я даведаўся да гэтага часу, гэта была правільная магчымасць. Vercel добра вядомы сваім разгортваннем без канфігурацыі. З дапамогай усяго некалькіх пстрычак мышы вы можаце разгарнуць сваё прыкладанне. Вы таксама можаце падключыць свой рэпазітар, і Vercel будзе імгненна ствараць і разгортваць ваш праект пасля кожнай фіксацыі. Гэта не можа быць больш зручным, чым гэта 😀. Яшчэ адной прычынай, па якой я абраў Vercel замест AWS, была іх бессерверная функцыя, якую я выкарыстаў для візуалізацыі дакументаў з маёй базы дадзеных праз Express API. Шчыра кажучы, я не магу паскардзіцца на іх абслугоўванне. У мяне ніколі не было праблем з маім праектам. Справа ў тым, што я хацеў даведацца больш пра бэкэнд майго прыкладання, і я палічыў, што разуменне яго разгортвання можа дапамагчы мне ў гэтым. Я бачыў шмат людзей, якія выбіралі AWS замест Vercel з-за іх цэнавага плану. Гэта не адносіцца да майго выпадку, бо мая праграма не мае такога вялікага трафіку, і я выкарыстоўваю яе ў асноўным для навучальных мэтаў. Але варта адзначыць, што Vercel мае «праблему» з эскалацыяй цэнаўтварэння. Дадатак Toronto Food Basket можна падзяліць на тры розныя часткі: Webscraper для збору інфармацыі з мясцовай прадуктовай крамы Express API, які арганізуе інфармацыю і можа выконваць для гэтага матэматычныя аперацыі. Прыкладанне React, якое адлюстроўвае прыкладанне і ўсю неабходную інфармацыю. На дадзены момант я толькі разгортваю Webscraper у AWS, бо мне яшчэ трэба даведацца больш пра серверы і маршруты для разгортвання Express API і праграмы React. Для пачатку я запусціў асобнік AWS EC2 і ўсталяваў будзільнік бюджэту, таму кожны раз, калі выдаткі на мой экземпляр перавышаюць 0,01 даляра, я атрымліваю апавяшчэнне - даведаўся, што цяжкі шлях пасля таго, як мне выставілі рахунак за асобнік DocumentDB, які працаваў у маім уліковым запісе са снежня /2023 і паняцця не меў 😂. Amazon прадастаўляе бясплатныя ўзроўні з 750 гадзінамі t2.micro (або t3.micro у рэгіёнах, у якіх t2.micro недаступны), 30 ГБ сховішча EBS, 2 мільёнамі IO, 1 ГБ здымкаў і 100 ГБ прапускной здольнасці да Інтэрнэту. Вывучаючы, як разгортваць сваё дакерызаванае прыкладанне на AWS, я зразумеў, што ёсць як мінімум два розныя падыходы - іх можа быць больш: стварыць кантэйнер докераў лакальна і адправіць толькі кантэйнер у AWS. адправіць усё ў AWS і стварыць свой кантэйнер выдалена. Я абраў другі падыход, таму што хацеў атрымаць вопыт цалкам аддаленай працы над сваім дадаткам, калі б мне гэта спатрэбіцца. Я не заўсёды карыстаюся ўласным камп'ютарам, і ў такіх сітуацыях было б вельмі зручна размясціць маё прыкладанне на асобніку EC2. Акрамя таго, я быў бы вымушаны працаваць з Vim, і гэта тое, што я хацеў зрабіць. Перш чым адправіць файлы ў свой асобнік EC2, я падрыхтаваў аддаленае асяроддзе, усталяваўшы Node.js і Docker. Для адпраўкі файлаў на мой асобнік EC2 я выкарыстаў пратакол бяспечнага капіравання (scp). Каманда выглядала прыкладна так: scp -i ubuntu.pem -r LOCAL_DIRECTORY ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws : Гэты сцяг вызначае файл ідэнтыфікацыі (закрыты ключ), які будзе выкарыстоўвацца для аўтэнтыфікацыі з адкрытым ключом. У гэтым выпадку - гэта файл закрытага ключа, які выкарыстоўваецца для аўтэнтыфікацыі на аддаленым серверы. -i ubuntu.pem ubuntu.pem : Гэты сцяг паказвае, што аперацыя павінна быць рэкурсіўнай, гэта значыць яна будзе капіраваць каталогі і іх змесціва рэкурсіўна. -r : Гэта спецыфікацыя прызначэння. Ён уключае імя карыстальніка ( ) і IP-адрас ( ) аддаленага сервера, а затым шлях да каталога ( ), куды будуць скапіяваны файлы. ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws ubuntu 35.183.21.127 /home/ubuntu/downloads Пасля таго, як усе файлы былі перададзены ў мой асобнік EC2, я змог стварыць свой докер-кантэйнер. І тут пачаліся багі - ура! Самая важная бібліятэка майго Webscraper - Puppeteer, якая забяспечвае API высокага ўзроўню для кіравання Chrome/Chromium праз пратакол DevTools. Puppeteer працуе ў рэжыме без галавы, што робіць яго выкананне больш хуткім. Але пры спробе зрабіць докерызацыю майго прыкладання я сутыкнуўся з некаторымі праблемамі: Па змаўчанні, калі Puppeteer усталяваны, ён спампоўвае Chrome для тэставання і двайковы файл chrome-headless-shell. Браўзэр спампоўваецца ў тэчку $HOME/.cache/puppeteer. Праблема ў тым, што AWS не ўключае $HOME/.cache у свой асобнік Ubuntu. Я выявіў гэтую праблему пасля некаторага даследавання, і для вырашэння ўсё, што мне трэба было зрабіць, гэта перамясціць тэчку /.cache у каранёвы каталог - гэтая праблема добра задакументавана на партале npm Puppeteers. Адна відавочная рэч, якую я не разумеў, гэта тое, што дагэтуль я запускаў сваё прыкладанне ў такіх АС, як Windows і MacOs.. Але цяпер я меў справу з Ubuntu. І паколькі гэта быў пусты асобнік, на ім не было папярэдне ўсталяванага пакета/праграмы, вось чаму я ўсталяваў node і docker, як толькі запусціў асобнік у першы раз. Але я забыўся пра вельмі важную праграму для працы майго Webscraper: Google Chrome. Памятаеце, што я казаў пра Puppeteer раней? Што ж, мне трэба было пераканацца, што ў мяне патрэбная версія Chromium на маім асобніку. Кожная асноўная версія Node.js створана на аснове версіі Debian, і гэтая версія Debian пастаўляецца са старой версіяй Chromium, якая часам несумяшчальная з апошняй версіяй Puppeteer. Пасля некаторага даследавання я даведаўся, што мне трэба ўключыць інструкцыю ў мой файл Docker, каб правільную версію Chromium можна было загрузіць, перш чым Docker усталюе ўсе залежнасці майго прыкладання і запусціць яго. Мой файл Docker выглядаў прыкладна так: Пасля выпраўлення папярэдняй праблемы ўзнікла яшчэ адна. Цяпер паведамленне пра памылку абвяшчае: «Не прыдатная пясочніца». Каб выправіць гэта, мне трэба было толькі змяніць свой код і ўключыць аргумент –no-sandbox у функцыю puppeteer.launch() для кожнага з маіх прадуктовых прадуктаў. Гатова. Цяпер мой Webscraper працуе ў кантэйнеры на маім асобніку AWS EC2. Аднак ён не будзе саскрабаць усе 65 прадуктаў. Пасля пятага прадукту праграма выходзіць з ладу. Я лічу, што гэта звязана з даступнымі рэсурсамі, якія я маю на гэтым экзэмпляры - я сутыкнуўся з той жа праблемай пры запуску скрабка з дзеяннямі github. У любым выпадку, маёй мэтай было запусціць асобнік AWS EC2 і запусціць маё прыкладанне выдалена, і я гэта зрабіў. Шмат яшчэ наперадзе!
