Kun tuli aika ottaa sovellus käyttöön, kokeilin AWS:ää, mutta rehellisesti sanottuna olin aivan järkyttynyt niiden tarjoamien tietojen ja palveluiden määrästä, ja halusin todella nähdä sovellukseni siellä luonnossa. Joten törmäsin Verceliin. Tämän lisäksi olen oppinut Dockerista ja halunnut soveltaa tähän mennessä oppimaani käytännössä, tämä oli oikea tilaisuus. Vercel on tunnettu nollakonfiguraatiostaan. Voit ottaa sovelluksesi käyttöön vain muutamalla napsautuksella. Voit myös yhdistää arkistosi ja Vercel rakentaa ja ottaa projektisi käyttöön välittömästi jokaisen sitoumuksen jälkeen. Tämän kätevämpää ei voisi olla 😀 . Toinen syy, miksi valitsin Vercelin AWS:n sijaan, oli heidän "palvelinton"-toiminto, jota olen käyttänyt hahmontamaan asiakirjat tietokannastani Express API:n kautta. Rehellisesti sanottuna en voi valittaa heidän palvelustaan. Minulla ei ole koskaan ollut ongelmia projektini kanssa. Asia tässä on se, että halusin oppia lisää sovellukseni taustaohjelmasta ja ajattelin, että sen käyttöönoton ymmärtäminen voisi auttaa minua tässä. Olen nähnyt monien ihmisten valitsevan AWS:n Vercelin sijaan hinnoittelusuunnitelmansa vuoksi. Se ei päde minun tapauksessani, koska sovelluksellani ei ole niin paljon liikennettä ja käytän sitä pääasiassa opiskelutarkoituksiin. Mutta on hyvä mainita, että Vercelillä on "ongelma" hintojen nousun kanssa. Toronto Food Basket -sovellus voidaan jakaa kolmeen eri osaan: Verkkokaapija tiedon keräämiseen paikallisesta ruokakaupasta Express API, joka järjestää tiedot ja voi suorittaa matemaattisia operaatioita. React-sovellus, joka näyttää sovelluksen ja kaikki tarvittavat tiedot. Toistaiseksi otan vain Webscraperin käyttöön AWS:ssä, koska minun on vielä opittava lisää palvelimista ja reiteistä ottaakseni Express API:n ja React-sovelluksen käyttöön. Aluksi käynnistin AWS EC2 -esiintymän ja asetin budjettihälytyksen, joten aina kun instanssini menot ylittävät 0,01 dollaria, saan ilmoituksen – sain tietää, että vaikein tien sen jälkeen, kun minua on laskutettu DocumentDB-esiintymästä, jota minulla oli ollut tililläni joulukuusta lähtien. /2023 eikä minulla ollut aavistustakaan 😂. Amazon tarjoaa ilmaisia tasoja 750 tuntia t2.microa (tai t3.microa alueilla, joilla t2.micro ei ole saatavilla), 30 Gt EBS-tallennustilaa, 2 miljoonaa IO:ta, 1 Gt tilannekuvia ja 100 Gt kaistanleveyttä Internetiin. Opetellessani ottamaan käyttöön telakoituneen sovellukseni AWS:ssä tajusin, että on olemassa ainakin kaksi erilaista lähestymistapaa – niitä saattaa olla enemmän: rakenna telakointikontti paikallisesti ja lähetä vain kontti AWS:lle. lähetä kaikki AWS:lle ja rakenna konttini etänä. Olen valinnut toisen lähestymistavan, koska halusin saada kokemuksen täysin etätyöskentelystä sovelluksessani, jos minun oli pakko. En ole aina omalla tietokoneellani, ja sovellukseni EC2-instanssissa olisi todella kätevää näissä tilanteissa. Lisäksi minun olisi pakko työskennellä Vimin kanssa, mitä olen halunnut tehdä. Ennen tiedostojen lähettämistä EC2-esiintymääni valmistelin etäympäristöni asentamalla Node.js ja Docker. Lähettääkseni tiedostot EC2-esiintymääni käytin Secure Copy Protocol (scp) -protokollaa. Komento näytti suunnilleen tältä: scp -i ubuntu.pem -r LOCAL_DIRECTORY ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws : Tämä lippu määrittää identiteettitiedoston (yksityisen avaimen), jota käytetään julkisen avaimen todentamiseen. Tässä tapauksessa on yksityinen avaintiedosto, jota käytetään etäpalvelimen todentamiseen. -i ubuntu.pem ubuntu.pem : Tämä lippu osoittaa, että toiminnon tulee olla rekursiivinen, mikä tarkoittaa, että se kopioi hakemistot ja niiden sisällön rekursiivisesti. -r : Tämä on kohdemääritys. Se sisältää etäpalvelimen käyttäjätunnuksen ( ) ja IP-osoitteen ( ), jota seuraa hakemistopolku ( ), johon tiedostot kopioidaan. ubuntu@35.183.21.127:/home/ubuntu/downloads/webscraperdockeraws ubuntu 35.183.21.127 /home/ubuntu/downloads Kun kaikki tiedostot oli siirretty EC2-instanssiini, pystyin rakentamaan telakointikonttini. Ja tästä bugit alkoivat - jee! Webscraperin tärkein kirjasto on Puppeteer, joka tarjoaa korkean tason sovellusliittymän Chromen/Chromiumin ohjaamiseen DevTools-protokollan kautta. Puppeteer toimii päättömässä tilassa, mikä tekee sen suorittamisesta nopeampaa. Mutta kun yritin telakoida sovellustani, törmäsin joihinkin ongelmiin: Oletuksena, kun Puppeteer on asennettuna, se lataa Chrome for Testingin ja chrome-headless-shell-binaarin. Selain ladataan kansioon $HOME/.cache/puppeteer. Ongelmana on, että AWS ei sisällä $HOME/.cachea Ubuntu-esiintymäänsä. Löysin tämän ongelman tutkimuksen jälkeen, ja ratkaistakseni minun täytyi vain siirtää /.cache-kansio juurihakemistoon - tämä ongelma on dokumentoitu hyvin Puppeteersin npm-portaalissa. Yksi ilmeinen asia, jota en ole tajunnut, oli se, että tähän asti olin käyttänyt sovelluksiani käyttöjärjestelmissä, kuten Windowsissa ja MacO:issa. Mutta nyt olin tekemisissä Ubuntun kanssa. Ja koska se oli tyhjä ilmentymä, siihen ei ollut esiasennettu yhtään pakettia/sovellusta, tästä syystä asensin solmun ja dockerin heti, kun suoritin ilmentymän ensimmäistä kertaa. Mutta unohdin Webscraperille todella tärkeän sovelluksen: Google Chromen. Muistatko mitä sanoin Puppeteeristä aiemmin? Minun piti varmistaa, että instanssissani on oikea Chromium-versio. Jokainen Node.js:n pääversio on rakennettu Debian-version päälle, ja tuossa Debian-versiossa on vanha Chromium-versio, joka ei toisinaan ole yhteensopiva Puppeteerin uusimman version kanssa. Pienen tutkimuksen jälkeen sain selville, että minun oli lisättävä ohje Docker-tiedostooni, jotta oikea Chromiumin versio voidaan ladata ennen kuin Docker asentaa kaikki sovellukseni riippuvuudet ja suorittaa sen. Docker-tiedostoni näytti tältä: Edellisen ongelman korjaamisen jälkeen ilmaantui toinen. Nyt virheilmoitus sanoo: "Ei käytettävissä olevaa hiekkalaatikkoa". Korjatakseni asian minun piti vain vaihtaa koodini ja sisällyttää -no-sandbox-argumentti puppeteer.launch()-funktioon jokaiselle päivittäistavaratuotteelleni. Tehty. Nyt Webscraper toimii AWS EC2 -esiintymäni säilössä. Se ei kuitenkaan kaavi kaikkia 65 tuotetta. Viidennen tuotteen jälkeen sovellus kaatuu. Uskon, että sillä on jotain tekemistä käytettävissä olevien resurssien kanssa, jotka minulla on tässä tapauksessa - kohtasin saman ongelman, kun suoritin kaavinta github-toimintojen kanssa. Joka tapauksessa tavoitteeni oli käynnistää AWS EC2 -esiintymä ja saada sovellukseni toimimaan etänä, ja tein sen. Paljon tulossa!
