Løsning af 'Det virker på min maskine'-problemet

Da det blev tid til at implementere applikationen, prøvede jeg AWS, men ærligt talt var jeg lidt ramt af mængden af information og tjenester, de leverer, og jeg ville virkelig gerne se min applikation derude i naturen. Så jeg stødte på Vercel. Oven i det har jeg lært om Docker og ville omsætte det, jeg har lært indtil videre, i praksis. Dette var den rigtige mulighed.

Vercel er kendt for deres nulkonfigurationsinstallation. Med blot et par klik kan du få din applikation implementeret. Du kan også forbinde dit lager, og Vercel vil øjeblikkeligt bygge og implementere dit projekt efter hver commit. Det kunne ikke blive mere praktisk end det 😀 . En anden grund til, at jeg har valgt Vercel frem for AWS, var deres 'serverløse' funktion, som jeg har brugt til at gengive dokumenter fra min database gennem en Express API. For at være ærlig kan jeg ikke klage over deres service. Jeg har aldrig haft problemer med mit projekt overhovedet. Sagen her er, at jeg ville lære mere om backend af min applikation, og jeg regnede med, at forståelsen af implementeringen af den kunne hjælpe mig med det. Jeg har set mange mennesker vælge AWS frem for Vercel på grund af deres prisplan. Det gælder ikke for mit tilfælde, da min ansøgning ikke har så meget trafik, og jeg primært bruger den til studieformål. Men det er godt at nævne, at Vercel har et "problem" med eskalering, når det kommer til prissætning.

Toronto Food Basket-applikationen kan opdeles i tre forskellige dele:

• Webskraber til indsamling af information fra en lokal købmand

• Express API, der organiserer informationen og kan udføre matematiske operationer for at gøre det.

• React-app, der gengiver applikationen og alle de nødvendige oplysninger.

  
  

I øjeblikket implementerer jeg kun Webscraper til AWS, da jeg stadig mangler at lære mere om servere og ruter for at implementere Express API og React-appen. Til at starte med lancerede jeg en AWS EC2-instans og indstillede en budgetalarm, så hver gang udgifterne til min instans går over 0,01 USD, får jeg en meddelelse - lærte, at jeg på den hårde måde efter at være blevet faktureret for en DocumentDB-instans havde kørt på min konto siden december /2023 og anede ikke 😂. Amazon tilbyder gratis niveauer med 750 timers t2.micro (eller t3.micro i de regioner, hvor t2.micro ikke er tilgængelig), 30 Gib EBS-lagerplads, 2 millioner IO'er, 1 GB snapshots og 100 GB båndbredde til internettet.

Mens jeg lærte at implementere min dockeriserede applikation på AWS, indså jeg, at der er mindst to forskellige tilgange - der kan være flere:

1. byg docker-containeren lokalt og send kun containeren over til AWS.

2. send alt til AWS og byg min container eksternt.

   
   

Jeg har valgt den anden tilgang, fordi jeg gerne ville have oplevelsen af at arbejde helt fjernt på min applikation, hvis jeg skulle. Jeg er ikke altid på min egen computer, og at have min applikation på en EC2-instans ville være rigtig praktisk i disse situationer. Jeg ville også blive tvunget til at arbejde med Vim, hvilket er noget, jeg har ønsket at gøre. Før jeg sendte filerne til min EC2-instans, forberedte jeg mit fjernmiljø ved at installere Node.js og Docker.

For at sende filerne over til min EC2-instans brugte jeg Secure Copy Protocol (scp). Kommandoen så nogenlunde sådan ud:

scp -i ubuntu.pem -r LOCAL_DIRECTORY [email protected]:/home/ubuntu/downloads/webscraperdockeraws

• -i ubuntu.pem : Dette flag angiver identitetsfilen (privat nøgle), der skal bruges til offentlig nøglegodkendelse. I dette tilfælde er ubuntu.pem den private nøglefil, der bruges til at godkende til fjernserveren.
• -r : Dette flag angiver, at operationen skal være rekursiv, hvilket betyder, at den vil kopiere mapper og deres indhold rekursivt.
• [email protected]:/home/ubuntu/downloads/webscraperdockeraws : Dette er destinationsspecifikationen. Det inkluderer brugernavnet ( ubuntu ) og IP-adressen ( 35.183.21.127 ) på fjernserveren, efterfulgt af biblioteksstien ( /home/ubuntu/downloads ), hvortil filerne vil blive kopieret.

Når alle filer var overført til min EC2-instans, var jeg i stand til at bygge min docker-container. Og her startede fejlene - yay! Det vigtigste bibliotek i min Webscraper er Puppeteer, som giver en API på højt niveau til at styre Chrome/Chromium over DevTools-protokollen. Puppeteer kører i en hovedløs tilstand, hvilket gør dens udførelse hurtigere. Men da jeg forsøgte at dockerisere min applikation, stødte jeg på nogle problemer:

• Som standard, når Puppeteer er installeret, downloader den Chrome til test og en chrome-headless-shell binær. Browseren downloades til mappen $HOME/.cache/puppeteer. Problemet er, at AWS ikke inkluderer en $HOME/.cache i sin Ubuntu-instans. Jeg fandt ud af dette problem efter lidt research, og for at løse alt, hvad jeg skulle gøre, var at flytte /.cache-mappen til rodmappen - dette problem er veldokumenteret på Puppeteers' npm-portal.

  
  

• En indlysende ting, jeg ikke har indset, var, at jeg indtil nu kørte min applikation i OS som Windows og MacOs. Men nu havde jeg at gøre med Ubuntu. Og fordi det var en tom forekomst, var der ingen pakke/app forudinstalleret, det er derfor, jeg installerede node og docker, så snart jeg kørte forekomsten for første gang. Men jeg glemte en virkelig vigtig applikation for min webskraber til at fungere: Google Chrome. Kan du huske, hvad jeg sagde om Puppeteer før? Nå, jeg var nødt til at sikre mig, at jeg havde den rigtige version af Chromium på min instans . Hver større version af Node.js er bygget over en version af Debian, og denne Debian-version kommer med en gammel version af Chromium, som nogle gange ikke er kompatibel med den nyeste version af Puppeteer. Efter noget research fandt jeg ud af, at jeg var nødt til at inkludere en instruktion i min Dockerfile, så den rigtige version af Chromium kunne downloades, før Docker installerer alle afhængigheder af min app og kører den. Min Docker-fil så sådan her ud:

  
  

• Efter at have rettet det forrige problem dukkede et andet op. Nu siger fejlmeddelelsen: "Ingen brugbar sandkasse". For at rette op på det var alt, hvad jeg skulle gøre, at ændre min kode og inkludere et –no-sandbox-argument på puppeteer.launch()-funktionen for hver eneste af mine dagligvareprodukter.

  
  

Færdig. Nu kører min webskraber i en container på min AWS EC2-instans. Det vil dog ikke skrabe alle 65 produkter. Efter det femte produkt går appen ned. Jeg tror, det har noget at gøre med de tilgængelige ressourcer, jeg har i denne instans - jeg stod over for det samme problem, da jeg kørte skraberen med github-handlinger. Under alle omstændigheder var mit mål at starte en AWS EC2-instans og få min applikation til at køre eksternt, og det gjorde jeg. Masser i vente!