Azok számára, akik első alkalommal vesznek részt a re:Invent-en, mint én is, egy ilyen méretű konferencián való eligazodás komplikált lehet. Ezt az útmutatót az útra való felkészülésem során nyert tapasztalataim valamint olyan tapasztalt AWS Community Builderek értékes tanácsai alapján állítottam össze, mint Pubudu Jayawardana és Niklas Westerstråhle, azért hogy segítsem a többi résztvevőt, abban, hogy a lehető legtöbbet tudják kihozni a re:Invent konferencia látogatásából.

Regisztráció

Minden a konferenciára való regisztrációval kezdődik. Minél korábban tesszük meg, annál több lehetőségünk van. A regisztráció jellemzően júniusban nyílik meg, ami bőséges időt biztosít a repülőjegy és szállás foglalására. A kiállítók az expón beszkennelhetik a belépőnket, ami később hírlevelek özönéhez vezethet. Ennek elkerülése érdekében javaslom, hogy dedikált e-mail címmel regisztráljunk, vagy címkézzük meg a re:Invent e-mailjeinket. Például, ha Google-t használunk, a „misi+reinvent2024@roadtoaws.com” címmel való regisztráció „reinvent2024” címkét ad minden releváns üzenethez.

Tartózkodás

Mielőtt lefoglaljuk a repülőjegyet és szállást, döntsük el, mennyi ideig tervezünk maradni. Bár a re:Invent az egész hetet felöleli, a legtöbb fontos előadás keddtől csütörtökig zajlik, péntek főleg az ismétléseknek van fenntartva. Ha péntekig maradunk, jobb esélyünk lehet bejutni a foglalásos előadásokra, mivel sok résztvevő már hazafelé tart. Azonban ha szoros az időbeosztásunk, egy két-három napos tartózkodás is lefedi a kulcsfontosságú eseményeket és bejelentéseket.

Repülőjáratok

A regisztráció után találhatunk kedvezményes repülőjegyeket. Idén az AWS a Delta Airlines-szal partnerségben kínál exkluzív kedvezményeket, de tapasztalatom szerint a repülőjegy-összehasonlító oldalak, mint a Momondo, kínálják a legjobb ajánlatokat. Június óta követtem a Budapest-Las Vegas járatok árait, és azt vettem észre, hogy az árak szeptember végéig stabilak maradnak, majd októberben észrevehető áremelkedés következik be. Ügyeljünk az időeltolódásra – Budapest 9 órával van Las Vegas előtt, így a jet lag intenzív lehet. Kerüljük a közvetlenül érkezés után előadásokat, mivel az új időzónához való alkalmazkodás időbe telik.

Szállás

Az AWS több hotellel is partneri viszonyban áll a konferenciahelyszínek közelében, kedvezményeket kínálva, de vegyük figyelembe, hogy ezek a foglalások gyakran nem teszik lehetővé az ingyenes lemondást. Ha a rugalmasság is fontos, a Booking.com vagy az Expedia platformokon keresztüli foglalás több lehetőséget kínálhat, beleértve az ingyenes lemondási időszakokat is. A Venetian szolgál a konferencia központjaként, itt zajlanak a kulcsfontosságú események és az expo, míg a közeli Wynn és Encore hotelek szintén népszerűek (269, illetve 279 dollár éjszakánként). Megfizethetőbb alternatívaként ajánlom a Treasure Island-et, amely csak feleannyi (133 dollár/éjszaka) de kényelmesen közel van a Venetianhoz. Tartsuk szem előtt, hogy az egyik hoteltől a másikig való közlekedés hosszabb időt vehet igénybe. – Készüljünk fel sok sétára!

Időjárás

Las Vegasban decemberben a napi hőmérséklet 4°C (39°F) és 15°C (58°F) között mozog. A reggelek és esték hidegek lehetnek, néha fagypont alá is süllyedhet a hőmérséklet, míg a délutánok viszonylag enyhék. Mivel Las Vegas sivatagi város, elengedhetetlen a megfelelő folyadékbevitel. Vigyünk magunkkal bőségesen vizet és rétegesen öltözködjünk.

Helyi közlekedés

A repülőtérről a szállodájához vagy az esemény helyszínére busszal, autómegosztó szolgáltatással vagy taxival juthatunk el. Ha a Strip déli végén szállunk meg, a ride-sharing szolgáltatások gyakran a legolcsóbb és leggyorsabb opciók, bár a forgalom néha problémát jelenthet. A repülőtérről induló taxiknak fix díjszabásuk van a Strip-ig, de készüljünk fel 3 dollár plusz díjra, ha kártyával fizetünk. A ride-sharing szolgáltatások, mint az Uber vagy a Lyft sorban állási ideje hosszú lehet, így néha a taxik gyorsabbak. Választhatjuk a buszokat is, de vegyük figyelembe, hogy az útvonalak változhatnak – például a CX busz most a Flamingónál áll meg a New York New York helyett.

A re:Invent több helyszínen zajlik a Strip mentén, így az előadások közötti utazási idő összeadódhat. A re:Invent shuttle buszok sűrűn közlekednek, de a forgalom késleltetheti őket. Gyorsabb opciókért vegyük fontolóra a Las Vegas Monorail használatát, amely összeköti a kulcsfontosságú helyszíneket, beleértve a Harrah’s, The LINQ, MGM Grand és a SAHARA (re:Play buli) hoteleket. A Mandalay Bay-ben tartott előadásokhoz kényelmes opció az Excaliburból induló ingyenes villamos.

Étkezés a re:Invent-en

Ingyenes reggeli hétfőtől péntekig 6:30 és 8:30 között érhető el, pénteken a Caesars Forum és a Venetian helyszíneken. Ingyenes ebédet hétfőtől csütörtökig 11:00 és 13:00 között kínálnak. A stockholmi csúcstalálkozón szerzett tapasztalataim alapján javaslom, hogy korán menjünk ebédelni, mert az étel elfogyhat, ha a résztvevők extra adagokat szednek maguknak. Ha jól szeretnénk étkezni, érdemes inkább étterembe vagy valamelyik partner által szervezett eseményre menni.

Expo

Az Expo csarnok hétfő délutántól csütörtökig tart nyitva, lehetőséget kínálva a partnerekkel való kapcsolatépítésre és némi ajándéktárgy beszerzésére. Ha el akarjuk kerülni a tömeget, próbáljunk meg kora reggel menni. Az Expo ad otthont a Lightning talks-oknak, amelyek gyors, 20 perces prezentációkat kínálnak ügyfél beszémolókról és termékbemutatókról.

Előadások

A látogatandó előadások programjának előzetes összeállítása kulcsfontosságú, különösen ha a legtöbbet szeretnénk kihozni a hétből. A helyfoglalásos eseményekre a regisztráció október 8-án nyílik meg, és gyorsan kell cselekednünk. Íme egy gyors áttekintés az előadástípusokról:

• Keynote: Itt történnek a fő bejelentések, de kihívást jelent jó helyet szerezni. Sok veterán 15 perccel korábban távozik, hogy elkerülje az esemény utáni tömeget.
• Breakout sessions: Ezek 1 órás, nem interaktív prezentációk, amelyeket rögzítenek. Bár érdekesek, sok résztvevő kihagyja őket, hogy az élő előadásokra koncentráljon.
• Builders sessions: Gyakorlati foglalkozások kis csoportokban. Ezeket a hét során ismétlik, így ha péntekig maradunk, növelhetjük esélyélyeinket a részvételre.
• Chalk talks: Rendkívül interaktív 1 órás beszélgetések, amelyek előadással kezdődnek és kérdés-válasz résszel zárulnak. Ezeket nem rögzítik, így népszerűek a tapasztalt résztvevők körében.
• Code talks: 300-as szintű és afölötti technikai előadások, mély kódolási témákra fókuszálva. A résztvevőket bátorítják a kérdezésre.
• Lightning talks: Rövid, 20 perces prezentációk az Expo csarnokban.
• Workshops: Irányított, gyakorlati laborok konkrét megoldások építésére. Sajnos az időkorlátok gyakran határt szabnak annak, hogy milyen mélyen lehet a témákba belemélyedni.

Egészség és biztonság

Mivel több ezer ember érkezik a re:Invent-re a világ minden tájáról, megnő a vírusok keveredésének esélye. Hozzunk magunkkal kézfertőtlenítőt, fontoljuk meg a maszk viselését, és rendszeresen mossunk kezet, az esemény alatt és után.

Főbb tanulságok

• Regisztráljunk dedikált vagy címkézett e-mail címmel a bejövő üzenetek kezelésére
• Hozzunk magunkkal kézfertőtlenítőt és maszkot a betegségek kockázatának csökkentésére
• Kerüljük az olyan egymást követő előadások látogatásának betervezését melyek különböző helyszíneken vannak – az utazási idő jelentős lehet
• Csomagoljunk kényelmes cipőt; sokat fogunk sétálni
• Vigyünk maunkkal tartalék akkumulátort, mivel a helyszínen nehéz konnektort találni. A helyi Wi-Fi megbízhatatlan lehet, ezért fontoljuk meg egy jó 5G adatcsomag beszerzését
• Legyen nálunk készpénz, mivel a taxisofőrök ezt preferálják, és a kaszinók ATM-jeiből történő készpénzfelvétel drága lehet

Jó re:Invent konferenciát kívánok és ha találkoznánk, köszönjük egymásnak!

A Az AWS re:Invent 2024 konferenciával kapcsolatos gyakorlati tudnivalók – Egy első alkalommal előadó útmutatója bejegyzés először Road to AWS-én jelent meg.

Az Amazon Bedrock az alábbi 13 AWS-régióban érhető el:

• US East (N. Virginia)
• US West (Oregon)
• Asia Pacific (Tokyo)
• Asia Pacific (Singapore – limited access)
• Asia Pacific (Sydney)
• Asia Pacific (Mumbai)
• Canada (Central)
• Europe (London)
• Europe (Frankfurt)
• Europe (Paris)
• Europe (Ireland – limited access)
• South America (São Paulo)
• AWS GovCloud (US-West)

Megjegyzés: Mivel Írországban, Szingapúrban és a GovCloudban korlátozott a hozzáférés, ezeket a régiókat kizártam az elemzésből, így 10 régió került összehasonlításra.

Az Anthropic a legkisebb modelljére a "Haiku", a középkategóriás változatára a "Sonnet", a csúcsmodellre pedig az "Opus" jelzőt használja.

2024. június 21-én az Anthropic bemutatta a Claude 3.5 Sonnet-et, mely az AWS szerint számos feladatban képes felvenni a versenyt az OpenAI GPT-4o vagy a Google Gemini rendszerével. Ez az új modell kizárólag az Anthropic API-n, az Amazon Bedrockon és a Google Cloud Vertex AI-n keresztül érhető el. Mivel ez egy új modell, a jelen blog írásának idejében ez a modell jelenleg csak az us-east-1-ből érhető el.

Az Amazon Bedrock esetében az AWS árképzésével és a szolgáltatás elérhetőségével kapcsolatos, eddig ismert ökölszabályok nem érvényesek. Eddig azt tapasztaltuk, hogy Európában a legtöbb szolgáltatással rendelkező régió Írország (eu-west-1), és hogy a legolcsóbb lehetőség általában Stockholm (eu-north-1).
A Bedrockkal mindez megváltozik. Az a régió, amely a legtöbb Anthropic FM-et kínálja Európában, Frankfurt (eu-central-1). Ha generatív mesterséges intelligenciával fejlesztünk Európában, akkor mostantól Frankfurt a legjobb választás.
Az Egyesült Államokban az ökölszabály továbbra is ugyanaz marad, az us-east-1 az a régió, amely a legtöbb funkcionalitást biztosítja. Érdekesség, hogy a legkomplexebb modell, a Claude 3 Opus viszont csak Oregonban érhető el.

Az Amazon Bedrock On-demand és Batch árazása régiónként egységes (pl. Oregonban és Kanadában ugyanannyit kell fizetni a Claude 3 Haikuért). Sőt, a Claude Sonnet 3 és a 3.5 is ugyanannyiba kerül. Ez az egységes árképzési stratégia aláhúzza az AWS elkötelezettségét amellett, hogy a fejlett generatív AI modelleket elérhetővé és megfizethetővé tegye a fejlesztők számára.

Provisioned Throughput árazás

A Provisioned Throughput árakat nézve, kevesebb választási lehetőséget látunk. Itt a Claude Instant és a Claude 2.0/2.1 modellekre korlátozódunk, és csak 4 régió közül választhatunk. Az árak tekintetében Frankfurt közvetlenül a vezető amerikai régiók mögött helyezkedik el, Tokió a legdrágább.

Összegzés

Az AWS több intézkedésével is bizonyítja a generatív mesterséges intelligencia iránti erős elkötelezettségét. Versenyképes árakat kínál az Anthropic modelljeihez, folyamatosan bővíti a Bedrock elérhetőségét új régiókra és azonnal elérhetővé teszi a legújabb alapmodelleket a felhasználók számára.

Ezek az árazási egyszerűsítések rávilágítanak az AWS elkötelezettségére a generatív mesterséges intelligencia fejlesztése és támogatása iránt. A fejlesztőknek a legújabb eszközöket kínálja megfizethető árakon.

A Amazon Bedrock – Egységes Anthropic FM árazás minden régióban bejegyzés először Road to AWS-én jelent meg.

A Lightsail egyik legnagyobb hátránya az EC2-vel szemben az, hogy nem lehet könnyen megváltoztatni a példány típusát. Jelenleg nincs egy kattintással elérhető lehetőség arra, hogy 512 MB memóriakészletről 1 GB memóriakészletre váltsunk. Az AWS tisztában van ezzel a problémával, és dolgozik egy olyan megoldáson, amely lehetővé teszi, hogy a jövőben nagyobb csomagra váltsunk. Addig is a nehezebb úton kell ezt megtennünk.

Hogyan kaphatok 1 vCPU-t ingyen?

Korábban az olcsóbb Lightsail csomagokat csak 1 vCPU-t kínálták. Ez azért volt így, mert az alapul szolgáló t2 példányok 1 vCPU-s opciókkal rendelkeztek. Most, hogy az AWS Lightsail áttért az új t3-as példánycsaládra, már nincs 1 vCPU-s opció, csak 2 vCPU-s. Bár a motorháztető alatt történt változás, az AWS megtartotta a Lightsail árazását, így a t3-as példánycsaládra való áttéréskor egy további ingyenes vCPU-t kaphatunk.

Lightsail példány frissítése

A Lightsail példány frissítéséhez manuális pillanatképet kell készíteni. A Snapshots (pillanatképek) menüpontban kattintsunk a Create Snapshot (pillanatkép létrehozása) gombra, és adjunk egy nevet a pillanatképnek. A pillanatkép létrehozása időbe telik, ezért legyünk türelmesek, amíg a pillanatkép elkészül.

A pillanatkép létrehozása közben lépjünk a Netowking (hálózat) fülre, és ha van IPv4-címünk, mindenképpen kattintsunk a Create static IP (statikus IP létrehozása) gombra. Ez lehetővé teszi, hogy megtartsuk jelenlegi nyilvános IPv4 címünket. Sajnos az IPv6 cím megtartására nincs lehetőség, így később frissítenünk kell a DNS-beállításainkat.

Az IPv4 Firewall (tűzfal) alatt jegyezzük fel vagy készítsünk képernyőképet a tűzfalszabályainkról, mivel ezek sem kerülnek átvitelre. Ha van IPv6-os hálózatunk, ugyanezt tegyük meg ezekkel a szabályokkal is, mivel előfordulhat, hogy különböző IPv4-es és IPv6-os tűzfalszabályaink vannak.

Mostanra valószínűleg már elkészült a pillanatfelvétel. Válasszuk a bal oldali menüben a Snapshots (pillanatképek) menüpontot, és látni fogjuk az újonnan létrehozott pillanatképet. Kattintsunk a három pontra, és válasszuk a Create New Instance (új példány létrehozása) lehetőséget. Itt kiválaszthatunk egy IPv6 csomagot, ha nincs szükségünk nyilvános IPv4 címre, vagy az új 2vCPU opciókat. Csak egy korlátozás van. Nem választhatunk alacsonyabb csomagot mint, amellyel rendelkezünk.

Ne feledjük, hogy a Lightsail példányok nevei egyediek, így nem nevezhetjük el az új példányt ugyanúgy, mint az előző példányt (és nincs lehetőség a példány nevének jövőbeli megváltoztatására sem). Én www. címet adtam a példányom elé.

Most, hogy az új példány már működik, először válasszuk le az IPv4-címét a régi példányáról, és csatoljuk az újhoz. Adjuk meg a korábban elmentett tűzfalszabályait is.

Ne felejtsük el frissíteni a DNS beállításokat az új nyilvános IPv6 címmel. Állítsuk le a régi példányt, és teszteljük az újat.

Tisztogatás

Miután meggyőződtünk arról, hogy az új példány teljesen működőképes, elvégezhetjük a manuális tisztítást. Először menjünk a Snapshots (pillanatképek) menüpontba, és töröljük a frissítéshez létrehozott pillanatképet. Az AWS 0,05 USD GB/hónap díjat számít fel a pillanatképekért, így ha nincs rá szükségünk, egyszerűen töröljük. A régi példányt is manuálisan törölnünk kell.

Az Amazon Lightsail a legegyszerűbb módja az AWS-sel való kezdésnek, a példányok bővítése ugyanakkor nem az. Amíg az AWS lefejleszti ezt a funkciót, addig a Lightsail példányainkat manuálisan tudjuk csak bővíteni.

A Amazon Lightsail példányok bővítése – további vCPU-t kaphatunk ingyen bejegyzés először Road to AWS-én jelent meg.

Láttam egy videót a YouTube-on arról, hogyan lehet a névjegykártyát egy egyszerű NFC matricával intelligenssé tenni. A probléma az, hogy bár a matricára be lehet programozni egy vCard-ot, az iOS készülékek még nem támogatják ezt a funkciót. Az egyetlen módja annak, hogy egy iPhone olvassa az NFC vCard-ot, hogy a vCard fájlt a weben tároljuk. Ekkor jutott eszembe. Miért ne lehetne a vCard-ot az AWS-en hosztolni, kizárólag ingyenes erőforrásokat használva.

A nyilvánvaló megoldás a Lambda és Lambda Function URL-ek voltak, mivel ezek teljesen ingyenesek. Ráadásul biztos lehetsz benne, hogy az AWS még 5 vagy 10 év múlva is létezni fog, így a digitális névjegykártyád még mindig működni fog.
Emellett nagyon könnyen frissíthetjük adatainkat, ha valami megváltozik, nem kell újat vásárolnunk. Ami a környezetnek is jót tesz!

A fejlesztés során olyan problémákba ütköztem, amelyek miatt extra házirendeket kellett létrehoznom, hogy működjön. Mivel a lehető legegyszerűbbé akartam tenni, hogy mindenki használhassa, létrehoztam egy CloudFormation sablont, amely létrehozza az összes erőforrást .
Ha pedig már nincs rá szükség, a CloudFormation képes törölni az összes felhasznált erőforrást. De miért is tennéd ezt, amikor ez teljesen ingyenes.

A kódot Node.js 18.x-ben írtam, és egy v. 3.0 vCardot készít. Megkérdezheted, hogy miért nem v. 4.0, és a válasz egyszerű. Az Apple nem támogatja, és én a lehető legkompatibilisebbé akartam tenni.
A másik probléma, amivel szembesültem, hogy a vCard specifikáció szerint egy kép URL-címét is összekapcsolhatjuk a fotónkkal, de az Apple készülékek ezt sem támogatják. A fényképnek Base64 kódolva kell lennie a vCard-ban.
Ezért a CloudFormation létrehoz egy S3 Bucket-et (tárolót), ahol tárolhatjuk a fényképet (avatar.jpeg), a Lambda függvény pedig Base64-be konvertálja, és beépíti a kártyájába.

Nem csak az Apple-nek, az AWS-nek is vannak furcsa dolgai. Például, amikor létrehozol egy FunctionURL-t a Lambda függvényhez, ez az URL nincs definiálva a Lambda környezeti változójában. Ahhoz, hogy megkapd a FunctionURL-t, a GetFunctionUrlConfig szerepkört kell engedélyezned a függvény URL-jének olvasásához. Mivel a vCard lehetővé teszi a vCard forrásának meghatározását, ahonnan mindig a legfrissebb verziót kapja meg, létre kellett hoznom egy házirendet, és azt a Lambda szerepkörhöz csatolnom, hogy a FunctionURL-t a vCard-ban szerepeltessem.

A másik probléma, amivel szembesültem, hogy bár a Lambda kódot a CloudFormation-be be lehet illeszteni, az index.mjs fájl helyett index.js fájlt hoz létre, ami Node.js 18.x-hez szükséges. Van megoldás arra, hogy a kódot egy S3 tárolóba helyezzük el, és a CloudFormation lekérdezi onnan a kódot, de akkor ottragadunk abban a régióban, ahol az S3 tároló van. Ezért létrehoztam két CloudFormation sablont .
Ha a legegyszerűbb telepítést szeretnénk, és nem akarjuk megváltoztatni a régiót, használjuk az alapértelmezett sablont. Ez az USA keleti részén (Észak-Virginia) fog futni. Ha a névjegykártyáját egy másik régióban szeretnénk elhelyezni, használjuk helyette a template-with-code.yaml-t, de a kód működéséhez az index.js állományt index.mjs-re kell átnevezni.

A teljes forráskód elérhető a GitHubon Apache 2.0 licenc alatt. Részletes telepítési információkért lásd a GitHub oldalt.
Használjuk a template.yaml fájlt, ha a legegyszerűbb telepítést szeretnénk.
Ha meg szeretnénk adni a régiót, amelyben az erőforrások létrejöjjenek, használjuk helyette a template-with-code.yaml, és nevezzeük át az index.js forrásfájlt index.mjs-re.

Remélem, hogy ez a kis kód olyan hasznos, mint amilyen szórakoztató volt megírni.

A Ingyenes és egyszerű csináld magad digitális névjegykártya bejegyzés először Road to AWS-én jelent meg.

A Mastodon-t választottam elsődleges platformnak, mert ez a legnépszerűbb az összes közül. Választhatsz mást is, mivel ezek a hálózatok zökkenőmentesen tudnak egymással kommunikálni, függetlenül attól, hogy milyen szervert futtatnak.

A Twitter (ma: X) kereskedelmi vállalatként jogosult korlátozni vagy kereskedelmi forgalomba hozni az API-ját, ami nehézséget jelenthet a startupok vagy kis fejlesztők számára. A Mastodon nemcsak ingyenes és nyílt forráskódú, hanem sokkal fejlesztőbarátabb is. Az egyik ilyen funkció a botfiókok támogatása. Ezek a fióktípusok nincsenek korlátozva, sőt, bátorítják a használatukat. A Mastodon-ban külön megjelölhetjük, hogy egy fiók bot-e, így mindenki számára átláthatóbbá válik.

Az első lépés mindig a legnehezebb, a Mastodon szerver kiválasztása. Rengeteg közül választhatunk, némelyik speciális közösségek számára van fenntartva, némelyik pedig földrajzilag korlátozott. Ha bizonytalan vagy, maradj a legrégebbi mellett: mastodon.social.

Hozzonunk létre egy fiókot itt, és jelöljük be a This is an automated account (ez egy automatizált fiók) négyzetet a profilunk alatt. Ez tudatja a többiekkel, hogy ez egy botfiók. Az Under Development (fejlesztés alatt) hozzunk létre egy új alkalmazást, és válasszuk ki a megfelelő jogosultságokat. Mivel az én botom csak publikálni fog, csak a write:statuses opciót választottam.

Egy korábbi blogbejegyzésemben létrehoztam egy honlapot a magyar techkonferenciáknak. Ezt fogom használni input forrásként. Jelenleg ez az oldal nem kínál egyszerű módot az információk exportálására, ezért módosítottam a Jekyll kódot, hogy CSV fájlt generáljon a közelgő eseményekről. Így könnyebben tudom felhasználni az adatokat.

A serverless megközelítés

A bejegyzés címéből valószínűleg kitaláltad, hogy serverless megközelítést fogok alkalmazni. Nem akarok biztonsági frissítésekkel és javításokkal foglalkozni. Csak azt szeretném, hogy ez a bot nagyon kevés karbantartással működjön.

Tipp: Válaszd az arm64-et Lambda architektúrát, mert annak olcsóbb a futtatása.

A Mastodonhoz egy maroknyi API kliens közül választhatunk. Mivel Node.js 18.x-et fogok használni, olyan klienst akartam találni, amely kompatibilis vele. A választásom a Masto.js-re esett, amelyet elég gyakran karbantartanak, és amely támogatja a Mastodon API legtöbb funkcióját.

A techconf.hu CSV-adatainak letöltéséhez az Axios-t fogom használni, mint a korábbi projektjeimben. A CSV adatok elemzésére a választásom a csv-pars-re esett (vigyázz, többféle CSV-parser létezik, egyes nevek csak kötőjellel különböznek egymástól). Ezután minden egyes funkcióhoz külön Layer-t hoztam létre, és csatoltam a Lambda függvényhez.

Az egészet működésre bírni

A kód nagyon egyszerű. Először letöltöm a CSV fájlt, és a csv-parse segítségével elemzem. Ezután beállítom a Tootot (a Mastodon kifejezése a Tweetre) és közzéteszem a Masto.js segítségével.

Az egyik probléma, amivel szembesültem, hogy a Mastodonban minden Tootnak van egy nyelvi változója. Ha nem állítod be külön, akkor a Mastodon fiókodban beállított nyelv lesz az alapértelmezett.

Tipp: Mivel a Fediverse annyira decentralizált, jó ötlet, ha minden hozzászólásodat megjelölöd.

import { parse } from 'csv-parse';
import { login } from 'masto';
import axios from 'axios';

export const handler = async(event) => {
    var tweet = "Upcoming Hungarian Tech Conferences 🇭🇺\n\n";
    var conferencesThisWeek = false;
    const currentDate = new Date();
    const endOfWeek = new Date(new Date().setDate(new Date().getDate() + 7));
    currentDate.setHours(0,0,0,0);
    endOfWeek.setHours(0,0,0,0);
    var conferenceDate;
    var csv;
    
    await axios({
        url: 'https://techconf.hu/conferences.csv',
        method: 'GET',
        responseType: 'blob'
    }).then((response) => {
        csv = response.data;
    });
    
    const parser = parse(csv, {
        delimiter: ",",
        from_line: 2
    });
    
    for await (const record of parser) {
        conferenceDate = new Date(record[3]);
        if (currentDate <= conferenceDate && conferenceDate <= endOfWeek) {
            tweet += '👉 ' +record[0] + ' (' + record[2] + ')\n📅 ' + record[3] + ' - ' + record[4] + '\n🔗 ' + record[1] + '\n\n';
            conferencesThisWeek = true;
        }
    }
    
    if (conferencesThisWeek) {
        tweet += '#Hungary #Technology #Conference';
        
        const masto = await login({
            url: 'https://mastodon.social/api/v1/',
            accessToken: ''
        });
    
        await masto.v1.statuses.create({
            status: tweet,
            visibility: 'public',
            language: 'en'
        });
    }
    
    // TODO implement
    const response = {
        statusCode: 200,
        body: JSON.stringify('Hello from Lambda!'),
    };
    return response;
};

Időzítés

A Lambda függvény ütemezésének legegyszerűbb módja az Amazon EventBridge Scheduler (ütemező) használata. Egyszerűen válasszuk ki az ütemezési mintát és a Lambda függvényt célként, és a megadott időpontban végrehajtja a kódot.

Végső gondolatok

Említettem már a legjobb részt? Mindez ingyen van. Az általam használt szolgáltatások mindegyike az AWS Free Tier (ingyenes) szolgáltatási körébe tartozik (jelen íráskor).

Nyugodtan hozzatok létre hasonló botokat, vagy segítsetek jobbá tenni a kódomat, vagy csak kövessétek a botomat a következő címen: https://mastodon.social/@techconf

A Serverless Mastodon bot bejegyzés először Road to AWS-én jelent meg.

Olyan technikai megoldást kerestem, amely nyílt forráskódú, és bárki hozzájárulhat hozzá. Az AWS munkatársaival való beszélgetés során kiderült, hogy más európai országok is hasonló problémákkal küzdenek, és ezeken a konferenciaoldalakon is van egy trend.
Amennyire le tudtam nyomozni, az egész az Android Study Group-pal kezdődött, amely létrehozott egy GitHub-oldalt az Android konferenciák számára. Spanyolország, Portugália, Olaszország és még Kanada is hamarosan követte őket. Rögtön rájöttem, hogy jó úton járok. A forráskód nyílt forráskódú, a GitHubon található, és bárki hozzájárulhat hozzá egy egyszerű Pull request-tel. Ez egy nagyszerű alap volt, de tudtam, hogy többet akarok.

Magyar fordítás

A fő probléma, amivel itt Magyarországon szembesülünk, az, hogy bár rengeteg esemény zajlik itt, de némelyik elsősorban angol nyelven. Valakinek, aki most kezdi az AWS-t, ez egy olyan plusz kihívás lehet, amit nem biztos, hogy be tud vállalni. Ezért az első fejlesztésem az volt, hogy lefordítottam a felületet magyarra. Nem akartam kizárni az angolul beszélőket sem, ezért kétnyelvűvé tettem a felületet. Így mindenki kényelmesen érezheti magát a weboldalon.

A másik javításom az volt, hogy egyértelműen kiemeltem a konferenciák nyelvezetét. Így tudok segíteni azoknak, akik az anyanyelvükön történő tartalmakat részesítik előnyben.

Létrehozás AWS-en

Nem hagyhatom figyelmen kívül azt a tényt, hogy AWS Community Builder vagyok, így nem volt kérdés, hogy ezt az AWS-en fogom megvalósítani. Egy domain regisztrálása és beállítása a Route 53-on volt az első lépés. Ezután megnéztem a hosztolás lehetőségeit. Az oldal Jeklly-ben íródott, és minden oldal külön-külön generálódik. A GitHub Actions segítségével minden új commit esetén újragenerálhatom a statikus oldalakat.
Egy statikus weboldal AWS-en történő hosztolása nem egy rakétatudomány. Az S3 statikus fájlok hosztolása olcsó és egyszerű megoldás. Csak meg kellett találnom a módját annak, hogyan tehetem közzé a fájljaimat az S3-on. Jake Jarvis létrehozott egy GitHub Action-t, amely képes szinkronizálni a fájlokat S3-al. Mindössze a megfelelő IAM-jogosultságokat kellett létrehoznom, és a fájlok az általam választott S3 tárolóba kerülnek. Onnan az AWS elvégzi a többit. Létrehoztam egy CloudFront disztribúciót, hogy HTTPS és gyors hozzáférést biztosítsak Magyarországról. Magyarországon jelenleg nincs AWS régió, de Budapesten van edge location, így az oldal onnan történő kiszolgálása gyors hozzáférést biztosít a magyar felhasználóknak.

Az eredmény

Az eredmény a techconf.hu, a magyarországi techkonferenciák közösség által összeállított listája. Őszintén remélem, hogy ez a projekt a magyar AWS közösség hasznára válik, és talán más, hasonló problémákkal küzdő országok is követni fogják. Boldog konferenciázást!

A Magyar technológiai konferenciák összefogása bejegyzés először Road to AWS-én jelent meg.

Az alapok: S3 statikus weboldal hosting

Statikus webhely tárhelyet még soha nem volt ilyen egyszerű létrehozni. Az Amazon S3 statikus tárhelyszolgáltatással egyszerűen feltölthetjük statikus oldalainkat egy S3 tárolóba, és engedélyezhetjük a nyilvános hozzáférést (az S3 tárhelyet mindenképpen nevezzük el a domain nevének megfelelően). Az interneten rengeteg cikket találhatunk, amelyek elmagyarázzák, hogyan kell beállítani az S3 statikus tárhelyet, ezért itt nem fogok további részletekbe bocsátkozni.

De vannak korlátok: Az S3 nem támogatja a HTTPS-t, ami a weboldalak tárhelyének de facto minimum feltétele. A HTTPS használatához be kell állítani az Amazon CloudFrontot. Ez rengeteg extra funkcióval jár, mint például GeoIP-korlátozás, gyorsítótárazás és ingyenes SSL-tanúsítvány. Arról nem is beszélve, hogy végre letilthatjuk az S3 nyilvános hozzáférését (ami biztonsági kockázatot jelenthet), és korlátozott hozzáférést adhatunk csak a CloudFrontnak (egy S3 házirenddel).

Pro tipp: Adjuk hozzá a CloudFront ListBucket engedélyeket az S3 tároló házirendjéhez, különben az ügyfél nem fog HTTP státuszkódokat kapni, beleértve a 404-es kódot is, amikor nem létező tartalomhoz próbál hozzáférni:

Mishi

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::roadtoaws.com",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        },
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::roadtoaws.com/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/AAAAAAAAAAAAA"
                }
            }
        }
    ]
}

A CloudFront gyorsítótárazása miatt nem ideális fejlesztéshez. Vagy helyben kell tesztelni a kódot, vagy a HTTPS engedélyezése nélkül. Ez a fő oka annak, hogy továbbra is jó lenne, ha az S3-ban is megjelenne a HTTPS-támogatás.

Legyen dinamikus

A statikus weboldalak már a múlté. Valószínűleg előbb-utóbb valamilyen dinamikus tartalomra lesz szükségünk. Bár sok olyan szolgáltatás létezik, amely olyan funkciókat biztosít, mint az e-mail küldés, a megjegyzések, amelyeket beilleszthetünk a statikus kódunkba, hogy dinamikussá tegye azt, valószínűleg saját kódot kell írniunk bizonyos funkciókhoz. Itt jönnek jól a Lambda Function URL-ek. Egy egyszerű Lambda függvénnyel kódot hajthatunk végre vagy más AWS-erőforrásokat használhatunk, amelyeket egy egyszerű HTTP-kérelemmel hívhatunk meg a böngésződben. De hogyan korlátozhatjuk ezt egy adott IP-re, tartományra vagy a CloudFrontra?

Az AWS az IAM-en keresztül történő hitelesítést ajánlja, és bár ez valóban biztonságos módszer, a fejlesztést kihívássá teszi. Az első dolog, amit láthatsz, az a CORS, ahol az eredetet egy tartományra állíthatod be. Sajnos ez nálam nem úgy működött, ahogy szerettem volna. Ez nem korlátozza a Lambdádat abban, hogy bármilyen IP-ről meg lehessen hívni. Itt beállíthatsz egy X-Custom fejlécet is, de ez sem igazán korlátozza a külső hozzáférést.

Ezután kerestem megfelelő IAM-engedélyeket, amelyeket a Lambda-funkciókhoz csatolhatok. A rendelkezésre álló házirendek között találtam az InvokeFunctionUrl-t, ahol hozzáadhatunk egy IP-címet, hogy a meghívást egy adott IP-re korlátozza. Ez remekül hangzik! Létrehozunk egy házirendet, és csatoljuk azt a Lambda Role-hoz. Sajnos ez sem korlátozza a Lambda hozzáférését.

Mi volt tehát a megoldásom?

1. Korlátozás kódban

Az első kézenfekvő megoldás a forrás IP-jének ellenőrzése a Lambda függvénnyel. Íme egy Node.js nyelvű mintakód (hasonló kódot más nyelvekhez is találhatsz az interneten):

const ipAddress = event.identity.sourceIP;

if (ipAddress === '52.84.106.111') {
  const error = {
      statusCode: 403,
      body: JSON.stringify('Access denied'),
  };
  
  return error;
} else {
  const hello = {
      statusCode: 200,
      body: JSON.stringify('Hello World!'),
  };
  
  return hello;
}

Bár ez nyilvánvalóan működik, extra kódot adsz hozzá egy olyan Lambda-funkcióhoz, amelynek elsődleges szerepe valami más elvégzése. Arról nem is beszélve, hogy ez növeli a futási időt és a Lambda által használt erőforrásokat. A legfontosabb, hogy hogyan lehetsz biztos abban, hogy a sourceIP változóban kapott IP valóban az az IP, ahonnan az ügyfél érkezik.

A legnagyobb gondom ezzel a megoldással az volt, hogy nem csak egy adott IP-re akartam korlátozni a funkcióimat, hanem az egész CloudFront disztribúcióra, így biztos lehetek benne, hogy az egyik statikus oldalamról hívják meg. Ezzel a módszerrel nagy gondot jelentene az összes CloudFront szerver naprakész listájának karbantartása.

2. reCAPTCHA

Igen, jól hallottad, Google reCAPTCHA. Ez elsőre furcsán hangozhat, de ez az a megoldás, amit én a munkám során megvalósítottam, és megoldást nyújt a fenti kihívásokra.

A reCAPTCHA kód beágyazása statikus weboldalakba jó ötlet. Valójában a Google azt javasolja, hogy a kódot minden oldalra építsük be – nem csak azokra, amelyeken szükség van rá, például az űrlapok érvényesítésére -, mert így az algoritmus hatékonyabban tudja felismerni a csalárd használatot. A lambda függvényen belül most már validálhatom, hogy a felhasználó valóban meghívta-e a statikus weboldalamról a lambda függvényem URL-címét. Íme a kód, amelyet a reCAPTCHA-kérés ellenőrzésére használok:

const gRecaptchaResponse = event.queryStringParameters["g-recaptcha-response"];
    
    var verificationUrl = "https://www.google.com/recaptcha/api/siteverify?secret=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&response=" + gRecaptchaResponse;
    const recaptchaResult = await getRequest(verificationUrl);
    
    if (false == recaptchaResult.success || 0.5 > recaptchaResult.score) {
      return error;
    }

Végezetül

Az S3 statikus weboldal hosting a legegyszerűbb módja a serverless utazás megkezdésének. Bár vannak akadályok, mindig találhatsz serverless megoldást.

A AWS Lambda Function URL-ek korlátozása CloudFronthoz bejegyzés először Road to AWS-én jelent meg.

Az AWS Well-Architected Framework hat pillérből áll:

• Operational excellence (üzemletetés)
• Security (biztonság)
• Reliability (megbízhatóság)
• Performance efficiency (teljesítményhatékonyság)
• Cost optimization (költségoptimalizálás)
• Sustainability (fenntarthatóság)

Az AWS nemcsak képzést és dokumentációt biztosít az AWS Well-Architected Framework-höz, hanem a felhőinfrastruktúra felügyeletéhez szükséges eszközöket is biztosítja.

Ebben a blogbejegyzésben bemutatok egy módszert arra, hogyan tesztelhetjük felhőkörnyezetünket az AWS Well-Architected Framework biztonsági és megbízhatósági pilléreivel szemben.

A Security pillar (biztonsági pillér) az információk, rendszerek és eszközök védelmére összpontosít, miközben kockázatértékelések és migrációs stratégiák révén üzleti értéket teremt.
A Reliability pillar (megbízhatóság pillér) a meghibásodásokból való helyreállítási képességre és az igények kielégítésére összpontosít az alapokban, a munkaterhelés architektúrájában, a változások és a hibák kezelésében.

Beállítás

Az AWS Systems Manager a legjobb hely az AWS fiókunk működésének betekintéséhez. Itt a Quick Setup (gyorsbeállítás) oldalon kiválaszthatjuk a Conformance Packs (megfelelőségi csomagokat). De ne szaladjunk ennyire előre, hiszen előbb elő kell készítenünk a környezetünket. Enélkül a tesztek egy nem túl hasznos hibaüzenettel fognak elbukni.

A környezetünk előkészítéséhez engedélyeznünk kell a Config Recordingot. Ezt az AWS Config menüpontban és a 1-click setup kiválasztásával tudjuk engedélyezni. Ez az összes erőforrást rögzíti (kivéve a globális erőforrásokat), beállít egy AWS Config szerepet és létrehoz egy S3 tárolót. Ha finomhangolni szeretnénk, hogy mely erőforrásokat szeretnénk rögzíteni, válasszunk vagy hozzunk létre egy adott szerepet, vagy válasszunk egy adott S3 tárolót és válasszuk helyette a Get started (kezdjük el) lehetőséget. Miután engedélyeztük a rögzítést, visszatérhetünk a Systems Manager-be.

A Conformance Packs konfigurációs képernyőn kiválaszthatjuk, hogy az AWS Well-Architected Framework Reliability vagy Security pillérének vagy mindkettőnek a legjobb üzemeltetési gyakorlatai szerint szeretnénk-e ellenőrizni. Beütemezhetjük a konfiguráció futtatásának időpontját, és kiválaszthatjuk a régiót. A csomag telepítése után a tesztek futtatása általában néhány percet vesz igénybe.

Eredmények

Az AWS Config az AWS-szolgáltatások szerint csoportosítva mutatja az eredményeket.

Egy problémára kattintva részletes magyarázat jelenik meg.

Árazás

Az árképzés a megfelelőségi csomagok értékelésének számától függ. Bár az AWS jelenleg nem mutatja, hogy hány értékelés van az egyes pillérekben, nehéz pontos számot kapni futtatás nélkül a tényleges árra. Jó lenne, ha az AWS fix árazással rendelkezne az Operational Best Practices megfelelőségi csomagok esetében. Az AWS Config honlapján van egy árképzési példa, amely a teljes konfigurációs számlát mutatja be.

Összegzés

Az AWS Well-Architected Framework az AWS nagyszerű és egyedi terméke, amely megkülönbözteti magát más felhőszolgáltatóktól, és nem értem, miért nem szerepel még mindig az AWS Free Tier-ben. Egy egészséges felhőkörnyezet az AWS-nek és az ügyfélnek is jót tesz.

A Bevált módszerek az AWS jól architektúrált keretrendszerének megfelelően bejegyzés először Road to AWS-én jelent meg.

Az Apple viszonylag egyszerűvé tette a végfelhasználók számára az Intelről az Apple silicon-ra való átállást. A Rosetta 2 csodálatos munkát végez a kizárólag x86-64-alapú processzorokra fordított alkalmazások Apple silicon-on történő futtatásához. Mivel az Apple silicon már egy ideje forgalomban van, sok fejlesztő Apple silicon-ra fordított bináris programokat biztosít. Valójában egyre kevesebb olyan nagy cég van, amelyik nem kínál Apple silicon-os verziót az alkalmazásából. Ez az oka annak, hogy néhányan – köztük én is – soha nem telepítik a Rosettát. Így garantálhatom, hogy minden alkalmazásom az új processzorra van optimalizálva.

Az AWS dokumentációja szerint a CLI háromféleképpen telepíthető Mac számítógépre:

• GUI Installer (grafikus telepítő)
• Command line installer – All users (parancssori telepítő – minden felhasználó)
• Command line – Current user (parancssor – aktuális felhasználó)

A szomorú hír az, hogy ezek a módszerek mind ugyanazt a macOS pkg fájlt használják. Ez a telepítő ebben a fájlban még nincs optimalizálva az Apple silicon-ra, de a mellékelt binárisok igen. Ez azt jelenti, hogy a Rosettát kell telepíteni csak azért, hogy telepíteni tudjuk egy Apple silicon-os alkalmazást. Valóban furcsa. Szerencsére van egy másik megoldás, amit a hivatalos dokumentáció nem említ, Brew.

A Homebrew a macOS hiányzó csomagkezelője. Valószínűleg már használod, ha olyan alkalmazásokat szeretnél telepíteni, mint a wget vagy az mc. A telepítés egyszerű és egyszerű, csak futtasd a következő parancsot a terminálban.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Ezután futtasd ezt a két parancsot, hogy a Brew-t hozzáadd a PATH-hoz:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

Az egyetlen hátránya a Brew-nak az, hogy adatokat küld a Google-nak. Erre figyelmeztet is, de nem mondja meg, hogyan lehet ezt kikapcsolni. Bár a Homebrew karbantartói azt mondják, hogy ezek az elemzések segítenek nekik a jövőbeli funkciókról való döntésben és a jelenlegi feladatok rangsorolásában – és azt ajánlják, hogy tartsuk bekapcsolva -, én még mindig nem vagyok a személyes adatok gyűjtésének híve, még ha névtelenül történik is ez. Ennek kikapcsolásához egyszerűen futtasd a következő parancsot:

brew analytics off

Most, hogy a Brew telepítve van, egyszerűen telepíthetjük az AWS CLI-t a következő parancs végrehajtásával:

brew install awscli

Voilá, az AWS CLI most már Rosetta nélkül telepítve van.

Meg kell jegyeznem, hogy ez a megoldás a cikk írásának idején volt szükséges, és az AWS valószínűleg javítani fogja a telepítőt, de addig csak használd a Brew-t.

A AWS CLI telepítése Apple silicon-ra bejegyzés először Road to AWS-én jelent meg.

Előnyök

Milyen előnyei vannak az AWS-re való áttérésnek?

Először is, globális lábnyoma van! Egy nagy tárhelyszolgáltatónak csak körülbelül 2-3 szerverterme van, ahol elhelyezhetjük a weboldalunkat. (A kicsiknek csak egy van). És nem mellesleg ezt a regisztráció során kell eldöntened, így életed végéig ezen a helyszínen lesz a weboldalad. Ezzel szemben az AWS-nél több tucatnyi helyszín (úgynevezett régió) közül választhatsz, és nem kell ragaszkodnod egyikhez sem. Lehet egy WordPress-oldalad Tokióban, egy másik pedig Szingapúrban. Ez több okból is jó: közelebb kerülhetsz az ügyfeleidhez (így gyorsabban elérhetik az oldaladat), valamint megfelelsz a helyi előírásoknak.

A másik előny a tárhelyszolgáltatókkal szemben a biztonság. Az AWS a biztonság szem előtt tartásával épült, és számíthatsz arra, hogy ha a WordPress webhelyed megfelelően van beállítva, akkor megbízhatóan fog működni. Ráadásul más felhasználók nem fogják befolyásolni webhelyed teljesítményét.

Az AWS képes alkalmazkodni az aktuális igényeidhez, és szükség esetén könnyen hozzáadhatunk vagy eltávolíthatunk erőforrásokat. Mi csak a felhasznált erőforrásokért fizetünk.

Végül, minden weboldalhoz ingyenes statikus IP-t kapunk, szemben a megosztott tárhelyekkel, ahol ugyanazt az IP-t osztjuk meg másokkal. Ez kiváló webshopok számára.

Bevezető

A szolgáltatás, amelyen végigvezetlek, az Amazon Lightsail nevű szolgáltatás. Más AWS-szolgáltatásokhoz képest egyszerűsített felhasználói felülettel rendelkezik, és fix havi árazással. A cikk középpontjában az áll, hogyan tudunk megbízható weboldalt üzemeltetni, de az elérhető legolcsóbb módon. A Let’s Encrypt ingyenes SSL-tanúsítványát fogjuk használni a Lightsail CDN-hez képest, amely jelenleg az első évben ingyenes (50 GB-ig), de később 2,50 USD/hó kerül. Arról nem is beszélve, hogy ha a látogatóid száma megnő, akkor 35 USD/hó kell fizetned. Ezért csak olyan szolgáltatásokat fogunk használni, amelyeknek fix díja van, még akkor is, így a költségek nem növekednek, ha a látogatóid száma nő.

AWS-fiók létrehozása

Ha még nincs AWS-fiókod, akkor létrehozhatsz egyet, ha ellátogatsz az AWS weboldalára, és a jobb felső sarokban található Create an AWS Account (AWS-fiók létrehozása) gombra kattintasz. Meg kell adni az e-mail címedet, jelszavadat, felhasználónevedet, személyes adataidat, beleértve a telefonszámodat és a hitelkártya adataidat. A kártyádat csak az általad igénybe vett szolgáltatásokért fogják megterhelni. Jó ötlet, ha a fiókodat rögtön a létrehozás után bitztonságossá teszeed. Olvasd el az Első dolgok beállítása az újonnan létrehozott AWS-fiókon című bejegyzésemet arról, hogyan engedélyezhetjük a többfaktoros hitelesítést a fiókon.

Amazon Lightsail

Jelentkezzünk be az AWS-fiókunkba, és ugorjunk be az Amazon Lightsailbe. A felső sávba írjuk be a lightsail szót, és válasszuk ki a Lightsail szolgáltatást, vagy kattintsunk erre a linkre, ha közvetlenül szeretnénk elindítani. Ha ez az első alkalom, akkor kiválasztjuk a nyelvet (sajnos egyenlőre magyar nyelv nincs). Válasszuk ki az English-t (angolt), és kattintsunk a Let’s get started (kezdjük el) gombra. Azonnal észre fogjuk venni, hogy a Lightsail sokkal barátságosabb felülettel rendelkezik.

A WordPress beállítása

Kezdjük egy új példány (weboldal) létrehozásával. A Lightsail automatikusan elvisz a példány beállításához egy üdvözlő üzenettel, hogy létrehozhassunk egy példányt. Később az Instances fül alatt, a Create instance (példány létrehozása) gombbal hozhatunk létre újat.

Új példány létrehozása

A Select your instance location (válassza ki a példány helyét) menüpontban az előbb vázolt paraméterek alapján választjuk ki a fizikai helyszínt. Az Amazon Lightsail jó tulajdonsága a többi AWS szolgáltatáshoz képest, hogy az árak minden régióban azonosak. (Ez más AWS szolgáltatásokra nem igaz.) Szabadon választhatunk régiót, és az árak nem változnak. Én a GDPR miatt a frankfurti régiót választom.

Ezután kiválasztjuk az operációs rendszert vagy szofvert. Mivel ez a cikk a WordPressről szól, a WordPress-t fogjuk kiválasztani.

Most jön a trükkös rész, amelyről lehet, hogy elfeledkeznél, ha nem olvasnád ezt a cikket.
Mindig jelöld be az Enable Automatic Snapshots (automatikus pillanatfelvételek engedélyezése) opciót. Az AWS nem garantálja, hogy a példányod nem fog meghibásodni, és ha meghibásodik, akkor az adataid elveszhetnek. Ezért engedélyezzük az automatikus pillanatképeket, hogy vészhelyzet esetén könnyen vissza tudjuk állítani az adatainkat.

Válasszunk ki egy árképzési opciót. Válasszuk ki az igényeinknek megfelelő és a költségvetésünkbe illeszkedő opciót.

Azonosítsuk a példányunkat egy barátságos névvel. Ez csak megjelenítési célokat szolgál; nincs hatása a példányra, de később nem változtathatjuk meg.

Kattintsunk a Create instance (példány létrehozása) gombra. Várjunk néhány percet, amíg a háttérben létrejön a példány. A példány létrehozása után az Instances (példányok) lapján a „Running” állapot fog megjelenni. A WordPress oldalad most már működik, de van még néhány fontos dolog, amit be kell állítanunk, mielőtt kávészünetre megyünk.

Statikus IP-cím csatolása

Kattintsunk a példány nevére, és válasszuk ki a Networking (hálózat) lapot. Válasszuk a Create static IP (statikus IP létrehozása) lehetőséget. Adjunk egy nevet a statikus IP-nek, és kattintsunk a Create (létrehozás) gombra. Felvetődik a kérdés, hogy miért fontos ez, ha már van egy IP-cím a példányához társítva. A probléma az, hogy ez az IP egy dinamikus poolból származik. Ez azt jelenti, hogy amikor később újraindítjuk a példányt, az IP-címe meg fog változni, és ezt nem szeretnénk. Egy statikus IP csatlakoztatásával az IP-címünk mindig ugyanaz marad.

DNS beállítása

Most itt az ideje, hogy összekapcsoljuk a domainünket ezzel az IP-címmel. Ha még nincs domained, javaslom, hogy regisztrálj egy .hu domaint, mert az országkód-specifikus végződések mindig kedvezőek; de ha szeretnél az AWS-nél maradni, akkor használhatod a Route 53-at is erre, viszont ott egyenlőre nincs .hu domain regisztrálási lehetőség.

A domain nevet a korábban létrehozott statikus IP címre kell irányítani. Ezt úgy tehetjük meg, hogy frissítjük az A rekordot ezzel az IP-vel.

Ha minden helyesen van beállítva, a böngészőbe beírva a domain nevet, megjelenik egy friss, új WordPress oldal.

SSL beállítása

Az SSL-tanúsítvány megléte manapság kötelező, és ezt többféleképpen is el lehet érni. Megmutatom, hogyan kell beállítani a Let’s Encryptet, amely ingyenes SSL tanúsítványt biztosít. Ehhez készítettem egy egyszerű szkriptet, amely elvégzi a nehéz munkát helyetted. Ezt a szkriptet a GitHubon találod. Az SSL beállításához először jelentkezz be a példányodba SSH-n keresztül. Ezt úgy teheted meg, hogy kiválasztod a Connect (kapcsolódás) fület a példányodon, és rákattintasz a Connect using SSH (SSH-n történő csatlakozás) gombra. Egy terminál ablakba fogsz kerülni, de ne aggódj, nem fogunk itt sok időt tölteni .

Egy új felugró ablak jelenik meg egy terminállal. A terminálba beillesztünk egy egyszerű szkriptet, vagy kézzel is beírhatjuk. Bármelyiket is szeretnénk.

A szkript beillesztéséhez az ablak jobb alsó sarkában találunk egy vágólap ikont. Kattintsunk rá, és illesszük be a következő szkriptet, majd kattintsunk a terminálra, és írjuk be a CONTROL + SHIFT + V (vagy COMMAND + V, ha Macen van) billentyűkombinációt.

wget -O - https://raw.githubusercontent.com/suhajda3/lightsail-ssl/main/lightsail-ssl.sh | sudo bash

A szkript megkérdezi a domain nevét és az e-mail címedet. Ha minden helyesen van beállítva, a szkript frissíti a rendszert, beállítja a Let’s Encryptet, és 90 naponként automatikusan megújítja azt, valamint megjeleníti a WordPress hitelesítő adataidat. Minden, amire szükségünk van.

Ezt a szkriptet bármikor futtathatod, amikor frissíteni szeretnéd a rendszert.

Jegyezzük fel a felhasználónevünket és jelszavunkat, mert később szükségünk lesz rá.

Írjuk be az exit-et a terminálból való kilépéshez és az ablak bezárásához.

A példány védelme (opcionális)

Mivel nincs szükségünk állandó terminál-hozzáférésre a példányhoz, érdemes letiltani az SSH-hozzáférést. Ehhez lépjünk át a Networking (hálózat) fülre, és kattintsunk az SSH sor mellett lévő szemetes ikonra. Győződjünk meg róla, hogy a HTTP és a HTTPS még mindig ott van, mert ezek nélkül nem tudnánk elérni az oldalunkat. Ha újra szeretnénk futtatni a szkriptet, vagy terminálhozzáférést szeretnénk, adjuk hozzá újra az SSH szabályt.

WordPress telepítés véglegesítése

A WordPress példányunk most már helyesen van beállítva. Jelentkezzünk be a WordPress oldalunkra úgy, hogy az URL-címünk végéhez hozzáadjuk a /wp-login.php címet. Itt bejelentkezhetünk az oldaladra azokkal a hitelesítő adatokkal, amelyeket a szkript korábban megjelenített.

Mielőtt elmész, még egy utolsó dolgot meg kell változtatnunk. A WordPress-ben a Settings, General, Site Language alatt válaszd ki a Magyar nyelvet.
Add hozzá az e-mail címedet arra az esetre, ha elveszítenéd a jelszavadat. A jobb felső sarokban válasszuk az Edit Profile (profil szerkesztése) lehetőséget, és változtassuk meg az Email címünket, majd kattintsunk a Update Profile (profil frissítése) gombra az oldal alján. Ezután kattintsunk a bal oldalon a Beállítások, Általános menüpontra, és változtassuk meg az Adminisztrációs e-mail címet is.

A WordPress webhelyed most már működik. Gratulálok!

A WordPress futtatása AWS-en – olcsón és egyszerűen bejegyzés először Road to AWS-én jelent meg.