…az Amazonasba merni nem lehet! Megelégeltem azt, hogy 5€-t fizetek havonta a DigitalOcean-nak egy szerver bérléséért, amin ráadásul nekem kell a szoftvereket karbantartani, és naprakészen tartani. Külön szívás, hogy egy kernel update után még az admin felületen kell bohóckodni, hogy a megfelelő verzióval bootoljon.
Ezek után úgy döntöttem, hogy az Amazon AWS-be migrálom a blogot. Ennek eredményeként nem csak a hosting költséget sikerült havi 1€ alá szorítani, de az AWS-t is kipróbáltam végre.
Ennek mellékhatásaként újra felpezsdül a blog, sok tartalom van már a csőben!
A DigitalOcean tapasztalatok
A DigitalOcean egy IaaS szolgáltató. Sajnos az IT-ben még mindig sokan nem tudják, hogy mi is az a cloud. Ők valahogy így képzelik el azt. (Olvastam szélsőségesen fogalmatlan “szakemberektől” olyat is, akik a Dropbox vagy OneDrive szolgáltatást képzelték el a felhőnek). Nekem van már egy kis tapasztalatom az Azureból, illetve a Herokut is próbáltam már, és arra jutottam, hogy a DO eléggé fapad ezekhez képest. Cserébe elég olcsó, és nagyon sok helyen olvastam pozitív véleményeket róla.
Körülbelül egy éve egy előadást tartottam a munkahelyemen, hogy a kollégáknak bemutassam az Ansible-t, és egy demót is készítettem ebből az alkalomból. Abban a DigitalOcean API-ját próbáltam használni. Mivel cloud szolgáltató, van API-ja is a szolgáltatásnak. Ez már olyan funkció, amire azok akik a cloudot legfeljebb IaaS-nek képzelik webadmin felülettel, nem is gondolnak. Sajnos a pozitív értékeléseket is ilyen emberek írták, mivel az API 10-ből 7 alkalommal nem működött. Szerencsére a demón kivételesen igen, de ekkor döntöttem úgy, hogy a DO-t komoly dologra nem fogom sosem használni.
Akkoriban néhány naponta volt valami részleges szolgáltatáskiesésről tájékoztató a twitterjükön is, hónapokon át.
Előfordult, hogy a létrehozott VM-be nem injektálta az SSH kulcsaim, így nem tudtam belépni és a provizionálást befejezni.
Az is rendkívül amatőr hatást kelt, hogy a számlázás az options menüpontban van elrejtve az adminisztrációs felületen.
Csak IaaS szolgáltatást nyújtanak jelenleg, és nekem PaaS vagy SaaS-re van igényem, mivel a rendszergazdásdit nagyon régen kinőttem már.
A gépek amúgy maguk az elvárásoknak megfelelően működtek, ha már elindultak. Az egész kissé sufnituning érzést kelt, de ha elindult, akkor már működik.
Sok halogatás után a hétvégén végül nekiláttam hát az S3-ba migrálásnak.
Az AWS élmény
Az AWS S3 amellett, hogy adatot tárol, és http protokollon elérhetővé teszi, ezt úgy is tudja tenni, ami statikus adat kiszolgálását is lehetővé teszi (itt első sorban az index oldalak támogatására kell gondolni). Az első 1GB tartalom havonta 0,15€-ba kerül, így egy egyszerű honlap kiszolgálása nagyon olcsón megoldható.
Nekem azonban HTTPS-re is szükségem volt, mivel már korábban is úgy szolgáltam ki látogatóimat, mégpedig az iparági gyakorlatot vakon követve úgy, hogy aki korábban https-en megnyitotta már az oldalam, annál sima http-re downgradelni nem lehetett volna (HTTP 301 Permanent Redirect, HTTP Strict Transport Security header). Szerencsére az SNI képes kliensek számára ingyen ad tanúsítványt az Amazon a CloudFront CDN-jét használók számára, amit automatikusan megújít. Ezt az EFF-nek és a Let’s Encrypt-nek köszönhetjük. Mire nem jó egy kis verseny!
Összességében azonban AWS-be migrálás is egy kisebb vesszőfutás volt. A blogot jelenleg a Pretzel nevű Jekyll klónnal generálom, és az AWS Python kliensével szerettem volna feltölteni. Windows alatt a virtualenv és a pip eléggé gyenge élményt adnak. Az aws parancs egy nagyon furcsa batch file, ami egy GOTO :EOF után python scriptként folytatódik… Viszont a feltöltő batch fileom megőrült attól, hogy a cmd.exe a tcsh-val összemérhetően szar. A trükk ennyi volt: cmd /c aws kell a sima aws helyett. Ezen nehézségek után a feltöltés végre sikerült. Azért választottam ezt a klienst, mert kész van, és tud syncelni. Mint kiderült, csak file időbélyeg, illetve méret alapján tud szinkronizálni, az S3 által támogatott ETag-eket figyelmen kívül hagyja. Ezzel egyelőre együtt kell éljek. Később kénytelen leszek egy rendes klienst írni az AWS SDK felhasználásával.
Innentől az S3-ba feltöltés után már csak website kiszolgálást kellett beállítani. Ebben nagy segítségemre volt az AWS kiterjedt dokumentációja. Sajnos a dokumentációban tévedések, elavult dolgok voltak, illetve a varázslók is félrevezetőek voltak, több kárt okoztak, mint segítettek. :) Az AWS Console amúgy valami iszonyat.
Az egyik félrevezető elavult információ az volt, hogy a website bucket neve legyen domain.tld, de ha CloudFront-ból szeretnénk kiszolgálni, akkor legyen domain-tld. Ez butaság, mindig az első formát kell használni, és így http-n sima website bucketként is elérhető lesz az oldal!
A másik félrevezető dolog az volt, hogy CloudFront beállításánál felkínálja a bucketet. Ott nem szabad azt kiválasztani, mivel akkor S3 bucket cache lesz, nem pedig website cache lesz a létrejövő disztribúció. Ehelyett forrásként az S3 website-t kell beállítani, és így az elvárásoknak megfelelően fog működni.
A helyes megoldást amúgy ezen a blogon találtam.
Emellett az is zavaró volt, hogy a dokumentáció folyton azt sulykolta, hogy a domainem kezelését az AWS Route 53-be kellene átvinnem, de valójában csak a névfeloldást kellett delegálnom (mivel az apex CNAME bejegyzéseket nem támogatja a registrarom névszervere). Így jobban jártam anyagilag, ráadásul csak félig vagyok teljesen az Amazon jobbágya. :)
Jelenleg a CloudFrontról elérhető a blogom, 8 IP címen!!! De ez egy másik történet, amit hamarosan elmesélek! :)
Mivel a Route53-ben csak az S3 vagy CloudFront végpontokra mutató ALIAS bejegyzések kiszolgálása ingyenes, viszont szeretnék levelezést is a domainemre, így ezért is fizetni kell… nagyjából 0,5€-t havonta. Összességében az eredeti konfiguráció után nulla adminisztrációt igényelő statikus oldalt lehet kiszolgálni, csak http-n 0,15€-ból, https-en ~0,75€-ból. Extrém forgalom esetén ez természetesen ez mehet feljebb, de ez nem lesz slashdotted, míg egy legkissebb kolokált virtuális gép könnyen összereccsenhet. Nem kell a szoftverfrissítésekkel és a CVE-kkel bajlódnom, vagy attól tartanom, hogy én fizetem mások kártékony tevékenységét egy botnetben részvétellel. Persze Jeff Bezos “jótékonykodását” is ítélheti annak bárki.
