Magento AWS hoszting – a teljes útmutató [+INFOGRAFIKA]

Napjainkban több mint 12 ezer Magento webáruház mögött van az Amazon felhőalapú szolgáltatása. A Magento AWS hoszting megoldás egyre népszerűbb. Nézzük meg részletesen, mi is ez, és milyen tulajdonságokkal rendelkezik.



Ezekről a témákról lesz szó:

 

Cloud Computing és az AWS Kinek ajánljuk a felhőt? Feltételek Telepítés Mi a menedzselt hosztolás? Tárgyalás a szolgáltatóval Biztonságos az AWS? AWS EC2 Instance-ok Magento telepítési útmutató

 

Cloud Computing és az AWS

 

felhő alapú számítástechnika (angolul: cloud computing) a számítástechnika egy ágazata. Többféle felhő alapú szolgáltatást különböztethetünk meg, a közös bennük az, hogy a szolgáltatásokat nem egy dedikált hardvereszközön üzemeltetik, hanem a szolgáltató eszközein elosztva, ezért

  • a szolgáltatás üzemeltetési részleteit a felhasználónak nem kell ismernie,
  • nincsen szükség az infrastruktúra kezeléséhez szükséges kompetenciára,
  • a technológia használata, az erőforrások elérése a lényeg.

 

Ezekhez a szolgáltatásokhoz a felhasználók hálózaton keresztül csatlakoznak.

Az elérés szempontjából megkülönböztetünk publikus és privát felhőt.

A felhőnket az interneten keresztül, és helyi hálózaton is elérhetjük, de a különbség elsősorban abban áll, hogy a hálózat kinek a birtokában van. Gyakorlatilag privát felhőnek nevezhetjük azt az infrastruktúrát, amelynek minden eleme saját kezelésben van és csak 1 ponton (tűzfal) csatlakozik a nyilvános hálózathoz.
 

Az érthetőség kedvéért, nagyon leegyszerűsítve: a felhő alapú szolgáltatás az, ha a szolgáltatást a saját környezetünkben vesszük igénybe, lokálisan, de a szolgáltatás nyújtásáért felelős infrastruktúra nem cégen belül működik, illetve nem helyben vannak üzemeltetve a szerverek.

Sőt, azok nem is a mi tulajdonunkban vannak, sok esetben nem is tudjuk, hogy pontosan mi és hol helyezkedik el, viszont pontosan definiálva van, hogy mit nyújtanak, milyen rendelkezésre állással, biztonsággal és természetesen mennyiért.

 

A „cloud” számítástechnika a 2000-es évek közepe óta az IT világ egyik fő irányának számít.

Hogy honnan, és mikortól eredeztethető a szemlélet, és a megvalósításra tett kísérletek, arról egy jó áttekintést olvashatunk az IBM oldalán. Mindenestre J. C. R. Licklider fejéből már a hatvanas években kipattant az ötlet, egy mindent behálózó computer-hálózatról, melynek erőforrásait annak használói „távolról” érik el (J. C. R. Licklider informatikus és pszchiológus volt, az ARPANET fejlesztéséért felelős személy.)

Az Amazon 2006 óta aktív a felhőszolgáltatások terén.

 

A szolgáltatások három fő csoportra oszthatók:

 

 

Számtalan kisebb-nagyobb vállalat nyújt felhő-alapú szolgáltatásokat ügyfelei számára, azonban a piacot döntően uraló 4 cégóriás infrastruktúrája mellett a többiek szinte eltörpülnek. E négy gigász

  • az Amazon, aki az AWS-t (Amazon Web Services) nyújtja,
  • a Microsoft az Azure szolgáltatáscsomagjaival,
  • az IBM (IBM Cloud),
  • valamint a Google aki egyszerűen a Google Cloud-dal szállt versenybe az ügyfelek kegyeiért.

 

Magento alapú webshopunk igényeinek tökéletes kiszolgálása érdekében – amennyiben annak megbízható és zavartalan működését tartjuk szem előtt – kötelességünk azt a legmegfelelőbb hardware-es környezetben futtatnunk.

Mi az AionHill-nél hosztolt Magento-s oldalakat az AWS szolgáltatásait igénybe véve futtatjuk. Ezek között vannak oldalak, amelyek hibrid környezetben, egy részük AWS-ben és egy részük a saját vagy az ügyfelünk privát felhőjében fut.

Rengetegen használják már ezt a technológiát, köztük a legnagyobb cégek, és tartalomszolgáltatók, mint például a

  • Netflix,
  • Dropbox,
  • HTC,
  • Hitachi,
  • de nem elhanyagolható a NASA,
  • a Soundcloud,
  • a Spotify vagy
  • a SAMSUNG jelenléte sem.

Az sem egy szem elől tévesztendő tény, hogy az AWS-nek – akárcsak másik három, nagy vetélytársának – robusztus, a világon szinte mindenhová kiterjedő infrastruktúrája van. Természetesen redundáns adatközpontokról beszélünk, így gyakorlatilag sosem tapasztalható kiesés a szolgáltatásaikban.

Az AWS felhő 42, úgynevezett Availability Zones (Elérhetőségi Zónából) épül fel, 16 földrajzi régióban, szerte a világon. Csak Európában 7 adatközpont található Frankfurtban, Londonban és Írországban. A fejlesztések, bővítések folyamatosak: egy új kínai, és egy párizsi központ is átadásra került az év elején.

 

graphic-info-on-hosting-providers

 

Kinek ajánljuk a felhőt?

 

Tapasztalataink szerint leginkább két szegmensben terjed ez a megoldás.

A kevésbé tőkeerős kis- és közepes vállalkozásoknál és a nagyvállalati szegmensben. Itt olyan erősen hatnak a felhőből jövő IT-szolgáltatások melletti érvek, hogy könnyű a döntés.

Sokan vallják, hogy ez a számítástechnika jövője, ellenzői éppúgy akadnak, elsősorban biztonságtechnikai kérdések felvetése miatt.

 

Felhő-alapú megoldások pro és kontra:

Nem minden vállalat számára előnyös:

A felhő-alapú számítástechnika bármilyen kis- és nagyvállalat számára előnyös lehet, de ehhez megfelelő szolgáltatási típust kell kiválasztani és meg kell határozni, hogy az informatikai környezet melyik részét telepítik a felhőbe. Előnyös elsősorban azokat az alkalmazásokat telepíteni át, amelyek egyébként is külső alkalmazásokhoz és szolgáltatásokhoz kapcsolódnak.

 

Nem biztonságos (?):

Egyes feltételeknek, mint az amerikai PCI biztonsági szabvány, amely a bankkártya adatok kezelését köti meg, nehéz megfelelő környezetet találni a felhő szolgáltatók között, ezeket nem minden szolgáltató biztosítja. Az Amazonnál azonban elérhetőek olyan VPC-k, amelyek nyújtják a PCI-DSS szabványt. Persze ennek ára van.

 

A felhőben tárolt adatok feletti ellenőrzés elveszítése:

Megoldás lehet erre, ha a szolgáltatásra egy megfelelő referenciákkal rendelkező céget keresünk, amely biztosítja, hogy az adatok biztonságban lesznek és a vállalat által előírt igényeknek megfelelnek, akár egy pénzügyi vagy jogi profilt képviselő vállalat esetében is. A mindennapi gyakorlatban azonban ezt a problémát könnyen áthidalhatjuk, ha egyszerűen napi biztonsági mentéseket készítünk lokálisan, a szerverek állományairól.

 

Ár:

Felhő-alapú szolgáltatások esetében nincs mindig szükség dedikált hardver vásárlására, ami jelentősebb megtakarítás a legtöbb esetben. Gyorsan változtatható az allokált erőforrások mérete is, ami további előny.

A legnagyobb előny viszont, hogy nem kell magas, kezdeti beruházással számolnunk, sem TCO szerint évekkel előre kalkulálni, hiszen az eszközök nem a mi birtokunkban vannak. Ezek a költségek leggyakrabban havi kiadásként jelentkeznek a számlánkon ‒ persze ha el tudjuk magunkat kötelezni hosszabb távon, azzal komoly, a bérleti díjat csökkentő kedvezményeket tudunk elérni.

További előnye a rendszernek a kiváló skálázhatóság, felfelé és lefelé is, tehát viszonylag kis költségvetés mellett ki lehet próbálni egy új szolgáltatást, és amennyiben az hasznosnak bizonyul, könnyen lehet alakítani a hatékony működés érdekében, és gyorsan meg is lehet válni egy felesleges erőforrástól.

 

Egyre kevesebb olyan cég van, amelynek nem ajánljuk a felhőt.

Pár évvel ezelőtt a nagymennyiségű adatokat kezelő, komoly sávszélességet felhasználó cégek nehezen vagy sehogyan nem tudták ezt a szolgáltatástípust használni. Mára ez is megoldott. Jelenleg már DVD-nyi adatok mozgatása is pár perc. Terrabyte-nyi adatok esetén az AWS SnowBall szolgáltatást érdemes használnunk, dedikált, garantált nagysávszélességű kapcsolathoz pedig az AWS DirectConnect szolgáltat megoldást.

 

Mi a feltétele annak, hogy a Magento webáruház az AWS felhőbe kerüljön?

Az Amazon Web Services lehetőségei rendkívül flexibilisek, testre szabhatók, és rugalmasan skálázhatók, terheléstől függően.

Az AWS költség kalkulátorának köszönhetően nincsenek rejtett fizetési tételek.

Minden előre tervezhető, gyakorlatilag egy HDD esetében, pontosan megmondható a winchester fejének olvasási/írási anyagi feltétele. Ez így talán elsőre furán hangzik, de ennek köszönhetően valójában csak azokért a szolgáltatásokért kell fizetnünk, amelyeket valóban igénybe is veszünk.

 

A Magento telepítése az AWS felhőbe

 

Amennyiben nincs egy-két év üzemeletetési, és sysadmin/devops tapasztalatunk, úgy a teljes folyamatot érdemes szakemberekre bízni. Különösen, ha a költséghatékony működtetés mellett az üzletfolytonosság is kiemelt szempont.

 

A lényeg: Az AWS lehetővé teszi számunkra, hogy a Magento-t támogató flexibilis, jól skálázható infrastruktúrát hozzunk létre.

 

Az árazás természetesen az üzembe helyezni kívánt erőforrás számítási kapacitásától, és az igénybe vett tárhely méretétől is függ.

Az alábbi táblázat néhány felhőbeli erőforrás fontosabb paramétereit és árait tartalmazza. Az egyes virtuális gépeket az AWS „Instance”-ként nevezi meg. Az alábbi táblázatban bemutatunk pár fontosabb AWS szervert és főbb paramétereit:

 

Instance típusa

t2.medium

vCPU

2

Memória (GiB)

4

 Tárolás (GB

Kizárólag EBS

Hálózati telj.

Alacsony – közepes

Fizikai proc.    

Intel Xeon család

Órajel (GHz) 

3.3-ig

t2.large

2

8

Kizárólag EBS

Alacsony – közepes

Intel Xeon család

3.0-ig

t2.xlarge

4

16

Kizárólag EBS

Közepes

Intel Xeon család

3.0-ig

t2.2xlarge

8

32

Kizárólag EBS

Közepes

Intel Xeon család

3.0-ig

m4.large

2

8

Kizárólag EBS

Közepes

Intel Xeon E5-2676 v3

2.4

m4.xlarge

4

16

Kizárólag EBS

Magas

Intel Xeon E5-2676 v3

2.4

m4.2xlarge

8

32

Kizárólag EBS

Magas

Intel Xeon E5-2676 v3

2.4

m4.4xlarge

16

64

Kizárólag EBS

Magas

Intel Xeon E5-2676 v3

2.4

m4.10xlarge

40

160

Kizárólag EBS

10 Gigabit

Intel Xeon E5-2676 v3

2.4

m4.16xlarge

64

256

Kizárólag EBS

20 Gigabit

Intel Xeon E5-2686 v4

2.3

m3.medium

1

3.75

1 x 4 SSD

Közepes

Intel Xeon E5-2670 v2

2.5

m3.large

2

7.5

1 x 32 SSD

Közepes

Intel Xeon E5-2670 v2

2.5

m3.xlarge

4

15

2 x 40 SSD

Magas

Intel Xeon E5-2670 v2

2.5

m3.2xlarge

8

30

2 x 80 SSD

Magas

Intel Xeon E5-2670 v2

2.5

c4.large

2

3.75

Kizárólag EBS

Közepes

Intel Xeon E5-2666 v3

2.9

c4.xlarge

4

7.5

Kizárólag EBS

Magas

Intel Xeon E5-2666 v3

2.9

c4.2xlarge

8

15

Kizárólag EBS

Magas

Intel Xeon E5-2666 v3

2.9

c4.4xlarge

16

30

Kizárólag EBS

Magas

Intel Xeon E5-2666 v3

2.9

 

tips Tipp : A „t” jelzésűek általában a tesztelésre használatosak, az „m” típusúakat (memória intenzív) érdemes a nagyobb adatbázisok, vagy single server telepítésekhez használni, és a nagyobb kapacitású, „c” instance-okat (CPU intenzív) érdemesebb Magento áruházak mögé rakni.

Az EC2 szerverek specifikációit, valamint a teljes listát meg tudjuk tekinteni az AWS oldalán.

 

AWS Szolgáltatások

 

Az alábbiakban felsoroljuk egy Magento próbaáruház hosztolásához szükséges főbb Amazon szolgáltatásokat, és rövid leírásukat.

  • Amazon EC2– Az Amazon Elastic Compute Cloud (Amazon Felhő Infrastruktúra) lehetővé teszi virtuális gépek indítását, a rájuk telepített operációs rendszerek széles skálájából választva. Dönthetünk már meglévő AMI (Amazon Machine Image), azaz Amazon Virtuális Gép image-e, képfájlja, vagy épp egy máshonnan importált képfájl között.
  • Amazon VPC– Az „Amazon Virtual Private Cloud” (Amazon Virtuális Magánhálózat) segítségével egy jól izolált, magán hálózatot definiálhatunk a felhőben, ahol szolgáltatásokat és egyéb erőforrásokat kapcsolhatunk be. Teljesen szabad kezet kapunk a virtuális hálózatunk beállítását illetően, beleértve saját IP tartományunk, alhálózat létrehozását, és a routing táblák, hálózati átjárók konfigurálását.
  • AWS CloudFormation– AWS CloudFormation egy könnyű módja annak, hogy létrehozzunk és felügyeljünk kapcsolódó AWS szolgáltatásokat, és előre tervezetten frissíthessük őket. Egy sablont használunk az összes erőforrás leírásához (pl.: Amazon EC2 instance-szok). Ily módon ezeket az erőforrásokat nem kell konfigurálnunk, vagy magunknak rájönni a kapcsolódásuk összefüggéseire, ezt mind megoldja helyettünk a CloudFormation. Lényege, hogy hasonló infrastruktúrákat gyorsan létre lehessen hozni.
  • Amazon RDS– Amazon Relational Database Service (Amazon Relációs Adatbázis)-t könnyű létrehozni, kezelni, és skálázni. Ezzel a szolgáltatással percek alatt telepíthető MySQL adatbázis, újratervezhető hardveres kapacitással.
  • Auto Scaling– Az Automata Skálázás segít helyreállítani, fenntartani a szerver elérhetőségét, azáltal hogy automatikusan növeli, vagy csökkenti a számítási kapacitást Amazon EC2 instance-szok hozzáadásával, vagy lekapcsolásával.
  • Elastic Load Balancing– A terhelés elosztás automatikusan kezeli és szétosztja a bejövő hálózati forgalmat, amennyiben a flottánkban egyszerre több Amazon EC2 Instance-ot is futtatunk.
  • Amazon S3– Amazon Simple Storage Service (Amazon Egyszerű Adattárolási Szolgáltatás) a biztonságos és hatékony módja a fájlok, adatok felhő-tárolásának. Leginkább multimédiás tartalmak tárhelyéül szolgál, az EC2 web szerverek innen érik el az áruházunkban megjelenő termékek képeit.
  • IAM– AWS Identity and Access Management (Felhasználó Hozzáférés és Kezelés) lehetővé teszi az AWS felhőben felhasználók létrehozását, és felügyeli azok jogosultságait, hozzáféréseit a különböző szolgáltatásokhoz és erőforrásokhoz. Az IAM-mel egyéb biztonsági intézkedéseket is tehetünk, például létrehozhatunk hozzáférési kulcsokat, engedélyeket, házirendeket, hasonlóan az ismertebb operációs rendszereken tapasztaltakhoz.
  • CloudFront – vagy rövidítve CDN a statikus tartalmakat kezelő szolgáltatás. Azt segíti elő, hogy a felhasználóknak ezek a tartalmak (például képek) mindig a legközelebbi szerverről, a lehető leggyorsabban legyenek elérhetőek, ezzel javítva az oldalak betöltési idejét.

 

Természetesen van lehetőségünk ingyenesen kipróbálni az AWS felhőjét. Erre két lehetőségünk is nyílik.

 

AWS Free Tier

Ha kalandkedvelőek vagyunk, vagy rendelkezünk a korábbiakban említett üzemeltetési tapasztalattal, akkor az Amazon-on tett személyes regisztrációval 1 év ingyenes hozzáférést kapunk az AWS bizonyos szolgáltatásaihoz.

Ne lepődjünk meg, ha a regisztráláshoz bankkártyánk adataira is szükség lesz, erre a telefonos visszaigazolás, valamint az alábbiakban említett körülmények miatt van szükség.

Körültekintően kell mazsoláznunk a lehetőségek között, mert könnyen bekapcsolhatunk, vagy konfigurálhatunk olyan erőforrásokat, melyek használata a számlánkat terheli majd a periódus végén.

Szerencsére a Dashboard-on nyomon követhetjük fogyasztásunkat, de mindig tájékozódjunk mielőtt valamilyen szolgáltatás működtetésébe kezdenénk. Ezt segítendő, az AWS külön megcímkézi azokat az erőforrásokat, melyeknek a kipróbálása nem kerül pénzbe.

Ami mellett a „Free Tier Eligible” jelzést lájuk, attól nem kell tartanunk.

  • Tárolhatunk fájlokat a felhőben,
  • létrehozhatunk felhasználókat, jogosultsági szintekkel,
  • üzleti analitikai szolgáltatást is igénybe vehetünk,
  • mikroszervert is élesíthetünk, megválasztott operációs rendszerrel, amelyen indíthatók szolgáltatások,
  • és a termináljában parancsokat is futtathatunk.

 

Illúzióink persze ne legyenek, ez az ingyenes szerver nem fogja kiszolgálni Magento webshopunk technikai igényeit!

De ha kedvet kaptunk hozzá, hogy közelebbről is megismerjük az AWS-t, akkor ezen a linken elindulhatunk a felfedezőúton.

Hosting Provider Demók

 

Sok szolgáltató igyekszik magához csábítani az ügyfeleket egy hetes, vagy maximum egy hónapos, ingyenes megoldásokkal, vagy előre konfigurált környezettekkel.

Bár roppant kényelmesen hangzik webáruházunk 5 perces kiköltöztetése a felhőbe, a legritkább esetekben fognak az ügyfél igényei, elképzelései igazodni, közelíteni a díjszabás nélküli hosztoláshoz. Az előre megtervezett környezetek értelemszerűen nincsenek felkészítve, hozzászabva szükségleteinkhez.

Ennek okán nagyon nehezen, vagy egyáltalán nem lehet személyre szabni, optimalizálni ezeket a „demo-shop”-okat. Az ügyfél előbb vagy utóbb rákényszerül, hogy megfizesse a szolgáltatást, hogy naprakész, gyors, stabil és megbízható webáruházzal várja a látogatóit.

 

Mi is az a menedzselt hosztolás?

 

Mielőtt webshopunkat el kívánjuk helyezni a felhőben, mindenképpen érdemes tájékozódni a piacon, kik és milyen megoldásokat kínálnak e téren.

Ha boltunk még fejlesztés előtt áll, érdemes olyan szolgáltatókból választani, akik fejlesztéssel és hosztolással is egyaránt foglalkoznak. Ennek főleg a jövőre nézve van előnye: elkerülhető későbbi félreértés, és egymásra mutogatás a fejlesztő és a hoszting cég között.

 

Miből lehet nézeteltérés, aminek esetleg az a vége, hogy a tulajdonos a fejlesztő és a hoszting cég között ül tanácstalanul, jelentős forgalomveszteséget elszenvedve? Számtalan probléma merülhet fel, de itt egy igen…

 

tips egyszerű és gyakori példa: Ha a webshop oldalán érezhető lassulás tapasztalható, akkor erre értelemszerűen a tulajdonos magyarázatot szeretne kapni. Első útja a fejlesztő céghez fogja vinni, aki a hosztingot nyújtó céget jelöli meg hibásként, mivel valószínűleg nem megfelelő környezetbe helyezték az oldalt.

A hoszting szolgáltató válasza erre valószínűleg az lesz, hogy a kód nem optimalizált, vagy annyira hibás, hogy gyorsításért felelő cache-eléses megoldások nem implementálhatók.

És ez a kör akár a végtelenségig tud folytatódni…

Ügyfélként érdemes lehet egy olyan megoldáson elgondolkodni, ahol mindkét forrás a szolgáltatást nyújtó cégnél összpontosul.

Vagyis ha a hosztoló és a fejlesztő ugyanaz, nagyobb eséllyel van birtokában annak a kompetenciának, ami a megbízható futtatáshoz kell, amely az áruház teljesítményét és az adatok biztonságos kezelését is szem előtt tartja.

 

A manage-elt hosztolás tulajdonképpen a normál hosztolásnak (legyen az dedikált vagy megosztott környezetben) olyan kibővítése, ahol a szolgáltató nemcsak az alap infrastruktúrát adja bérbe, hanem a futtatandó üzleti alkalmazáshoz (pl: Magento) igazítja a környezetet.

Minden olyan szükséges mikroszervizt, amely segíti az alkalmazást ‒ hogy gyorsabban, stabilabban, biztonságosabban fusson ‒ telepíti és karban is tartja azokat.

 

Magento esetében ilyenek például

  • a MySQL,
  • Redis,
  • Varnish,
  • CDN
  • és Search szerverek.

 

Lehetnek ezenkívül más szükséges mikroszervizek is, hiszen minden eCommerce alkalmazás nagyon eltérő tud lenni.

A manage-elt hoszting keretében ez a rendszergazdai vagy sysop tevékenység benne van a szolgáltatásban. Az árazás a különböző cégeknél ezért is nagyon eltérő, mivel ezek nagyon komoly kompetenciát érintő szolgáltatások és mindenki más és más szolgáltatásokból építi fel a portfólióját.

 

Tehát összefoglalva: manage-elt hoszting szolgáltatás keretében a hardveres infrastruktúrát csupán béreljük és a telepítéshez, futtatáshoz szükséges kompetenciát megvesszük.

 

Ezután nekünk csak az alkalmazást kell kezelni, de kizárólag üzleti szempontból. Ezért nagyon fontos, hogy a felelősségi körök, jogosultságok mindkét oldalon tisztázottak legyenek.

Sokan sokféleképpen definiálják a manage-elt hosting feladatköreit, az igénybe vett szolgáltatás szintje, annak minősége alapján. Ez a lista felfelé és lefelé is módosulhat, ami a megállapodás függvénye.

 

Nézzük meg, hogy melyek a legfontosabb tényezők:

  • Szerver Monitorozás– A szerver vagy szerverek aktív felügyelete, mellyel preventíven felismerhetők és orvosolhatók a kisebb hibák, mielőtt nagyobb problémává duzzadnának, a szolgáltatás kiesését elkerülendő. 
  • Biztonság– Ide tartozik a vírusvédelem, a spam szűrés, tűzfal konfigurálás, és az operációs rendszer konfigurációja, frissítése is. A biztonság minden gépen és hálózaton kiemelt fontosságúnak tekintendő, különösen olyan esetekben, ahol személyes vagy üzleti adatok sérülhetnek. Ide soroljuk az áruház üzembiztonsági (Operation Security), hozzáférés és adatbiztonsági (Security and Safety) feladatait, a szolgáltatást, az adatok elérését, mentését az SLA-ban leírtaknak megfelelően. Az áruház biztonsági tanúsítványai is kiemelt fontosságúak, hiszen eddig csak a payment gateway-ek és a bankok figyelték ezeket, de most már a Google is rangsorol ez alapján!
  • Teljes biztonsági mentés (back-up) és tárolás– Egy cég számára az adatvesztés többszörösen is veszteség: időt, pénzt és az ügyfél elégedettségét emészti fel. Ennek okán a szolgáltatónak fel kell készülnie, hogy rendszeres mentéssekkel, azok tárolásával, archiválásával növelje a stabilitást.
  • Támogatás (Support)– A szolgáltatók egyik vonzó előnye, hogy rendelkezésre állási idővel támogatják az üzletfolytonosság fenntartását. Ha bármi probléma adódik, azt az ügyfél azonnal jelenteni tudja a szolgáltató felé, és a holtidő minimalizálásával megkezdődhet az elhárítás. Sokféle konstrukcióban kínálják ezt a szolgáltatás típust: telefonos, email-es összeköttetésben, akár az év minden napjára, 24 órában kiterjesztve.

 

A jól megtervezett és működtetett manage-elt hoszting szolgáltatásnak nemcsak követelményei, de üzleti előnyei is vannak.

Összegezzük ezeket:

Csökkentett üzemeltetési költségek – A hardverek és a működtetésükhöz szükséges erőforrások nagyon sok cég számára megterhelők lehetnek, ezek folyamatos cseréje az amortizáció és a mögé helyezett tudásbázis napra készen tartása végett.

Az invesztálások kiadási oldala és az ezekből realizált haszon között nincs egyenlőség, nem tudnak ebből hathatós előnyre szert tenni. A szolgáltatóknak ezzel szemben megvannak az erőforrásaik, melyek így az ügyfél szempontjából költséghatékonnyá teszik az infrastruktúra igénybevételét. Az alacsonyabb beruházási költség mellett a skálázhatóság is fontos szerepet játszik az ésszerű, hatékony forráskezelésben.

Példa: kiemelten terhelt időszakok (peak-ek) esetén, ha nagyobb számítási kapacitásra van szükség (pl. karácsonykor), akkor erre nagyobb erőforrásokat különíthetünk el. Ezt kompenzálandó az év fennmaradó időszakában olcsóbb üzemeltetéssel működtethetjük tovább az áruházat.

Hatékonyabb erőforráskezelés – Ha az ügyfél cége IT munkatársakat alkalmaz, akkor pontosan tudja, hogy a jó szakembereket meg kell fizetni, ezért kiemelten fontos ezen erőforrások ésszerűsítése. Ha a hosztinghoz szükséges kompetenciákat egy külsős szolgáltatónál találja meg, akkor az ügyfél „belsős” informatikusai több időt és energiát fordíthatnak saját cégük mindennapi feladataira és munkatársaik támogatására.

 

Hogyan és miért fizetünk az AWS-nek?

 

Az AWS az úgynevezett „pay-as-you-go” (csak-azért-fizetsz-amit-használsz) rendszerben kínál több mint 70 felhő-alapú szolgáltatást.

Valóban csak az kerül kiszámlázásra, amit igénybe is veszünk, csakis a használat időszakát véve alapul, nincsenek kötelezően hosszú távú szerződések (de a kedvezményekért érdemes elgondolkodni rajta), vagy beüzemelési díjak. Hasonlóan a közüzemi fogyasztásinkhoz, mindent mér az Amazon, és erről pontos kimutatást is kapunk az elszámolás időszakában – általában havonta – és ha valamilyen komponensre már nincs szükségünk, egyszerűen felhagyunk a használatával.

Az egyik legnagyobb előny, hogy nem kell tetemes beruházási, vagy upfront költséggel számolnunk.

A hardveres összetevőkről (szerverek, aktív hálózati eszközök), adatközpontunk tárolásához szükséges terem-, vagy ingatlanköltségek, a szoftverek licenszei benne vannak a szolgáltatás árában. Tervezhető és jóval alacsonyabb üzemeltetési díjakkal kalkulálhatunk.

A „pay-as-you-go” modell lehetővé teszi, hogy rugalmasan igazodjon IT infrastruktúránk a hirtelen vagy gyakorta változó üzleti körülményeinkhez. Ahogy korábban említettük, az erőforrások gyorsan aktivizálhatók, vagy kapcsolhatók ki, így megspórolhatjuk a túlköltekezésből, vagy épp az alulbecslésből származó anyagi kiadásokat.

 

tips Hasznos:  Ezzel elérhetjük, hogy a forrásainkat előre tervezetten, nagyobb hatásfokkal tudjuk a vállalkozásunk fejlesztésére fordítani, és dinamikusan reagálhatunk a piaci változásokra.

 

 Az AWS nyitott rá, hogy ügyfelei számára mennyiségi kedvezményt nyújtson, ahogy növekszik a fogyasztás. Az olyan szolgáltatások esetében, mint az S3, vagy az adat export az EC2 szerverekből szintezettVagyis minél nagyobb az adatforgalmunk, annál kevesebbe kerül gigabájtonként a szolgáltatás.Mindemellett az adatimport ingyenes. Ennek következtében, mivel az AWS használati igények növekednek, életbe lép a méretgazdaságosság elve, amely lehetővé teszi a költségek ellenőrzés alatt tartását és a költségoptimalizált használatot.Ahogy vállalkozásunk fejlődik, az AWS is lehetőséget ad, hogy könnyebben szerezzük meg azokat a szolgáltatásokat, amelyek az új üzleti igényeket segítenek kezelni. Például az AWS adattárolási portfóliója lehetőséget kínál az áraik csökkentésére az alapján, hogy milyen gyakran és milyen gyorsan kívánunk hozzáférni adatainkhoz.Hogy optimalizáljuk a megtakarításokat, ki kell választanunk a megfelelő tárolási megoldások azon kombinációját, amelyek segítik a költségek csökkentését, miközben megőrizzük a teljesítményt és a biztonságot.
Bizonyos szolgáltatásoknál, mint az Amazon EC2 és az Amazon RDS, hasznosíthatjuk a fenntartott kapacitást. A fenntartott instance-ok esetén akár 75% kapacitást is megspórolhatunk.Ezeket 3 opcióban kaphatjuk a fizetési módozatok alapján: teljes induló költséggel – All up-front (Auri), részleges indulási költségekkel – Partial up-front (Puri) vagy előre nem fizetést – No up-front (Nuri) választva.

A fenti példát folytatva, minél nagyobb lesz a kezdőrészlet, annál nagyobb a későbbi, megkapható kedvezmény.Ahhoz, hogy maximalizáljuk a megtakarítást, érdemes kifizetni minden kezdeti költséget és a legnagyobb kedvezményre leszünk jogosultak.Részleges induló fizetéssel alacsonyabb kedvezményt biztosítanak, de jóval kisebb a szolgáltatás induló költsége.Végül, ha nem kívánunk up-front költségeket fizetni, a legkisebb kedvezményt szerezzük csak meg, de lehetővé tesszük, hogy a felszabadított tőkét a projektünk más részein tudjuk hasznosítani. A lekötött kapacitás segítségével minimalizálhatjuk a kockázatokat, kiszámíthatóbbá tesszük a költségvetésünket. 

Milyen költségekkel jár a Managed Magento Hosting?

 Milyen információkból tudja meghatározni a managed Magento hosting szolgáltató a költségeket?Egyrészt adottak és nyíltak az infrastruktúra használatáért fizetendő összegek. Ez bárki által megtekinthető az AWS kalkulátorában. Mégis, ha egy szolgáltatótól árajánlatot kérünk, ettől jóval eltérő számokkal fogunk találkozni, ami nyilván nem szorul különösebb magyarázatra.A hosting provider-nek, vagyis a szolgáltatónak ugyanezek a kiadásai, ezeket az erőforrásokat veszi igénybe az Amazon-tól. A szolgáltató hozzáadott értéke a csapatában lévő szakértelem:

  • az AWS finomhangolása,
  • testre szabása webshopunk részére,
  • a migrálás,
  • a szerverek konfigurációja, frissítése,
  • az adatbázis back up-ok kezelése
  • és minden olyan IT kompetencia, amivel az ügyfélnek nem kell foglakoznia,

így teljességgel webáruházának működtetésére fordíthatja a figyelmét.

 Az ügyfélnek ezt a szolgáltatást és tudást kell a különbözetben megfizetnie.A legtöbb szolgáltató nyílt árakkal is hirdeti magát, de sok esetben a „pricing” fülre kattintva pusztán egy levelezési linket kapunk, és egyéni árszabásban gondolkodnak. Ahol láthatók az alapárak, mint sok más helyen, itt is előszeretettel alkalmazzák a különféle árkategóriákat, ezáltal „csomagosítva” a szolgáltatási portfóliót.Összehasonlítva ezeket, azt láthatjuk, hogy nincsenek kiugróan nagy különbségek, általában 4-5 csomagajánlattal találkozunk havi költségeket illetően, mindezek egy egész széles skálán: $35 ‒ $5000 között mozognak.

 

tips Fontos: az AWS mindig USD-ben adja meg a díjakat, ezért legyünk körültekintőek, amikor egy szolgáltató ajánlatával foglalkozunk, különösen, ha más devizában számolunk el!

 

 Ez igaz miránk, az AionHill-re is, ezért az egy szerveres környezetet $150 ‒ $760, a többszerveres megoldásokat egy $500 ‒ $1600 közötti sávban kínáljuk ügyfeleinknek.

Nincs két egyforma elképzelés, ahogy két egyforma webshop sem.Ezért teret kell engedni, hogy a hoszting szolgáltató IT-s munkatársai a lehető legoptimálisabb környezetet állítsák össze az ügyfél számára. Ehhez azonban nem csupán az ötletek szükségesek, hanem a szakembereknek ismerniük kell jó pár technikai paramétert is, a lehető legpontosabb kalkuláció érdekében. 

 

Mire készüljek, ha a felhő szolgáltatóval tárgyalok?

 

A technikai paraméterek felmérése vagy előzetesen, email-ben vagy személyesen, az AWS specialisták bevonásával történik meg. Ügyfélként tisztában kell lenni azzal, hogy miért szeretnénk a felhőbe költöztetni a shop-unkat, mik ezeknek az előnyei, átlagosan mekkora költséggel és / vagy szolgáltatás kieséssel jár a migráció.

Értelemszerűen minél egyedibb, több összetevőből áll a rendszerünk, annál komplexebb megoldásra kell számítanunk. Minél inkább egyedi megoldásokat szeretnénk gyakorlatba fektetni – és ez nem csupán a cloud szolgáltatásokra vonatkozik – annál inkább forrásigényes a folyamat.

Azonban ha átszámoljuk a felmerülő költségeket a saját szerverpark beszerzésére, beüzemelésére, annak fenntartására vonatkozóan, és ezt szembehelyezzük a manage-elt hoszting áraival, akkor látni fogjuk, már középtávon meg tud térülni a befektetés.

A legfontosabb technikai adatok kinyerhetők a Google Analytics-ből. Ezen már el tud indulni a szolgáltató. Viszont adódhatnak olyan kérdések, melyekre a cégünk rendszergazdái vagy a korábbi fejlesztők tudnak csak releváns válaszokkal szolgálni. Érdemes egy vázlati rajzot készíttetni a szervertopológia publikus részéről, és annak specifikációiról (Visio).

 

Nézzük meg, hogy milyen kérdésekkel találkozhatunk:

  • Mekkora a látogatók száma az oldalon naponta?
  • Mekora az indított munkamenetek száma egy hónapban?
  • Peak-ek esetén mi volt a legnagyobb munkamenetérték a periódusban?
  • Mekkora ezeknek a csúcsoknak az előfordulási aránya egy adott üzleti évben?
  • Milyen verziójú Magento Shop-ot szeretnének készíttetni, illetve melyik verziót szeretnék migrálni?
  • Jelen webshopban mekkora az SKU (Stock Keeping Unit)?
  • Az aktuális szerver vagy szerverek milyen specifikációval rendelkeznek?
  • Milyen külső rendszerekkel kommunikál a webáruház, és vannak-e tervek ennek bővítéséről (adatbázis típus-méret, számlázó szoftverek, ERP, CRM, stb.) ?

 

Milyen szolgáltatásokat, technológiákat várjunk el a felhő szolgáltatótól?

 

Ahhoz, hogy Magento áruházunk a megfelelő minőségben szolgálhassa ki vevőinket egy sor követelménynek kell megfelelnie. Kezdve az üzemeltető szakmai felkészültségétől, a használt és napra készen tartott technológiákon keresztül, az ügyfél támogatásáig bezárólag.

 

  • A bérbe adott infrastruktúrán felül milyen szolgáltatásokat nyújt az ügyfélnek, és ebből a webshop tulajdonos hogyan tud profitálni?
  • Hogyan garantálja az adatai biztonságát?
  • A kommunikáció, hibabejelentés milyen csatornákon és hatékonysággal történik?

 

Kicsivel fentebb összegeztük, hogy mik az alapvető feladatkörök, de ha hosztingcég számára fontos az ügyfél megelégedettsége, akkor ennél több is kell.

 

Mire figyeljünk oda ügyfélként a felhő kapujában?

 

Migráció

Amennyiben már meglévő, kész áruházunkat szeretnénk a felhőben látni, a szolgáltató szakemberei fogják a teljes folyamatot lebonyolítani, de ehhez valószínűleg együtt kell működniük a webshop tulajdonosával vagy az áruház informatikai szakembereivel.

Ügyfélként, kapcsolattartóként ezt ajánlott megkönnyíteni, és minden lépést kétoldalúan dokumentálni a nyomon követhetőség érdekében.

 

Figyeljünk oda a következőkre:

  • A szolgáltató tájékoztat-e a migrálás körülményeiről?
  • Külön árazás alá esik a folyamat, vagy beépíti a szolgáltatás árába?
  • Milyen időbeni vállalást tesz ennek kivitelezésére, és mennyiben érinti ez az üzletfolytonosságot, mekkora kiesést jelent a webshop számára?

 

Legyünk következetesek és körültekintők, ne csak az üzleti partnerünkkel, de magunkkal szemben is! Inkább tegyünk fel egy kérdést többször a tárgyalási folyamatok során, mint hogy valamilyen technológiai akadályra kritikus időben derüljön fény.

 

Kódaudit

Amikor a szolgáltatót megbízzák egy webáruház felhőbeli migrációjával, jogosan várják el annak zökkenőmentes, gyors üzemeltetését is. A megfelelő működés, és hatékonyság azonban nem pusztán a szerveres környezet, hanem a környezet és a fejlesztés együttes függvénye.

A hosztingot végző cégek – ahogy a fejlesztők is – használnak olyan cache-elési eljárásokat, technológiákat, melyek használata gyorsítja az oldalbetöltést, optimalizálja a statikus tartalmak elérését, vagy az áruház látogatói szokásaiból, analitikai módszerekkel teszi láthatóvá az értékes adatokat, amelyek hozzásegítenek az úgynevezett „Data Driven Decision” (Adatalapú döntések) meghozatalához.

 

tips Figyelem!:  Ezeknek a technológiáknak a használatához hozzá kell férni a webshop kódjához, hogy egy megfelelő vizsgálattal kiderüljön kód minősége, illetve, hogy ezek technológiák alkalmazhatók-e! Amelyik szolgáltató nem veti fel ennek lehetőségét egy migrálandó oldal esetében, kezdhetünk gyanakodni!

 

SSD és EBS

Ma már egyre nagyobb azoknak a szolgáltatóknak a száma, akik a gyorsabb írási/olvasási érték elérése végett adatinkat „Solid State Drive”-on tárolják.

Ezek a meghajtók a lakossági felhasználók körében is elterjedtek már az elmúlt években. Egy cloud hosting esetében pedig már szinte elvárható ez a technológia. Az Amazon felhőjében egyaránt találunk SSD és úgynevezett EBS (Elastic Block Storage) tárolási megoldásokat.

Fő különbségük flexibilitásukban van: az EBS-t bármikor hozzá tudjuk kapcsolni, vagy leválasztani egy instance-ról, vagyis szerver független, míg az SSD fizikai értelemben is szerverhez kötött.

 

Apache és NGINX

Az Apache és NGINX a két leggyakrabban használt nyílt forráskódú webszerver a világon. Együttesen, az interneten lebonyolított forgalom 50%-át teszik ki. Mindkét megoldás lehetőséget ad különböző munkaterhelésekre és másik szoftverekkel való dolgozásra, egyfajta web stacket alkotva.

 

Apache

Rugalmasságának, erejének és széles körű támogatottságának köszönhetően gyakran választják ezt a megoldást. Egy dinamikusan terhelhető modulrendszerrel lehet kiterjeszteni, amely képes megannyi nyelv feldolgozására is anélkül, hogy ehhez egy különálló szoftvert kellene igénybe vennie.

 

NGINX

2002-ben Igor Sziszojev kezdett el dolgozni az NGINX-en, problémát keresve a C10K-s problémára (10.000 egyidejű kapcsolat kezelése), ami akkoriban kihívást jelentett a webszerverek számára, márpedig ez alapfeltétele volt a modern világhálónak. A kicsi erőforrás kihasználása és minimális hardveren való hibátlan működése miatt az NGINX népszerűsége kiadása óta is folyamatosan nő. Az NGINX kiválóan kezeli a statikus tartalmakat, és úgy hozták létre, hogy a dinamikus igényeket egy másik szoftverhez irányítja, amely annak kezelésére jóval alkalmasabb.

 

Varnish Cache

Ez a gyorsítótárazási eljárás széles körben elterjedt, mivel rendkívül hatékonyan növeli a weboldal teljesítményét azzal, hogy csökkenteni képes a szerveroldali töltési időt. Ez a tulajdonsága nemcsak a felhasználói élmény növelését segíti elő, de üzemeltetési szempontból is közkedveltté teszi. A töltésoptimalizálás mellett másik erős oldala az ESI (Edge Slide Includes), mely az oldalt komponensekre bontja, és ezeknek az elemeknek külön-külön, egymástól függetlenítve oldja meg a gyorsítását.

 

Biztonságban az AWS felhőjében?

 

Egy cég életében, legyen az középvállalkozás, vagy induló webshop, sokszor nem is kapacitásbeli problémák gátolják meg a felhőbe költözést, hanem a szemlélet, a szokások. A fejlődő országokban gyakorta uralkodik a görcsös ragaszkodás a saját tulajdonú gépparkhoz, a karnyújtásnyira lévő szerverekhez, mintha pusztán fizikai közelségük szavatolná a cégadatok biztonságát.

Az AWS számos megoldást nyújt a kritikus adatok, a munkahelyi hálózatok, és a gyors, de megbízható hozzáférés biztonságának érdekében:

  • A hálózati tűzfalakat beépítették az Amazon VPC-be, és az AWF WAF (Web Application Firewall) lehetővé teszi magánhálózat létrehozását a felhőben, valamint a hozzáférés korlátozható a szerverekhez és az alkalmazásokhoz
  • A TLS titkosítás kiterjed minden szolgáltatásra
  • Privát vagy dedikált kapcsolódási lehetőségek, munkahelyről, vagy kívánt megbízható környezetből

 

DDoS (Distributed Denial of Service – Masszív, elosztott túlterheléssel járó támadás)

 

  • Az elérhetőség kiemelkedően fontos a felhőalapú szolgáltatásoknál. Az AWS által használt technológiák ma már ellenállók a túlterheléses támadásokkal szemben.
  • A szolgáltatások megfelelő kombinációja biztosítja a DDoS elleni stratégiát. Egy ilyen támadás érzékelésekor a különböző szolgáltatások automatikusan jeleznek a rendszer többi része felé minimalizálva az esetleges időkiesést és támadás hatását.
  • Az AWS autoskálázása, a CloudFront és az Amazon Route 53 (ami egy DNS szolgáltatás) együttesen segít kivédeni, illetve enyhíteni egy esetleges DDoS támadást.

 

AWS titkosítás

Az AWS titkosítása egy újabb védelmi szint a felhőben lévő adatok megvédésére. Szintén jól skálázhazó, hatékony:

  • A titkosítás elérhető az adattároló és adatbázis szolgáltatások számára, mint az EBS, S3GlacierOracle RDS, SQL Server RDS és Redshift.
  • A rugalmas kulcs kezelési beállítások, mint az AWS Key Management Service, lehetővé teszi annak beállítását, hogy hogy az AWS vagy mi gyakoroljunk teljes hatalmat a hozzáférések kezelésében.
  • Dedikált, hardver alapú titkosítási kulcs tároló segítségével az AWS CloudHSM, amely lehetővé teszi, hogy eleget tegyünk a megfeleltetési követelményeknek

 

Ezenkívül, az AWS biztosít API-kat, melyeken keresztül telepíthetők egyéb titkosítási és adatvédelmi megoldások, illetve alkalmazások.

 

Monitorozás és log-olás

Rendelkezésre állnak azok az eszközök és szolgáltatások, melyekkel pontosan láthatjuk és felügyelhetjük az AWS rendszerünkben zajló folyamatok, eseményeket:

  • Az API hívásokra kiterjedő teljes felügyeletet, hogy láthassuk mi, mikor, mit és honnan hívott meg azAWS CloudTrail végzi el
  • Jelentések, vizsgálatok, aggregációs beállítások teljes naplózása
  • Figyelmeztetések, riasztások beállításainak lehetősége az Amazon CloudWatch-csal, mikor bizonyos események bekövetkeznek, vagy meghatározott limitet átlépünk

 

Ezekkel az eszközökkel megfigyelhetünk és felügyelhetünk adott eseményeket, mielőtt azok kifejtenék hatásukat. Ezzel is növelhetjük stabilitásunkat a felhőben, csökkentve a rizikófaktort.

 

Felhasználó és hozzáférés vezérlés

Az Amazon felhőjében lehetőségünk nyílik létrehozni és kezelni felhasználókat és a rájuk vonatkozó házirendeket, szabályokat:

  • Az AWS Identity and Access Management (IAM)-mel mi definiálhatjuk a felhasználói fiókokat és rendelhetjük hozzájuk az engedélyeket, jogosultságokat.
  • Az AWS Multi-Factor Authentication segítségévela kiemelt fontosságú felhasználóknak hardver kulcsos azonosítást hozhatunk létre.
  • Az AWS Directory Service a Microsoft Active Directory-hoz hasonló user kezelést valósít meg, lecsökkentve ezzel az adminisztrációs kérésekből, feladatokból álló időkiesést.

Az AWS támogatja a felhasználói fiókok és hozzáférés-felügyeleti alkalmazások integrációját a saját szolgáltatásaikba, valamint az API integrációt is, bármilyen saját alkalmazással vagy szolgáltatással.

 

Következtetés: Látni, hogy az Amazon mindent bevet annak érdekében, hogy jól skálázható, biztonságos felhő infrastruktúrát adjon ügyfelei kezébe. Kijelenthető akkor, hogy az AWS Cloud biztonságos? Igen, kijelenthető, hogy semmivel sem veszélyesebb, mint a dedikált, helyi szerverek üzemeltetése.

 

Összegzés

Napjainkra a legnagyobb márkák mögött húzódó cégek – néha tudtunk nélkül – a felhő mögül kommunikálnak velünk. Ezek a nagyvállalati struktúrák robusztus voltuk miatt mind profitáltak a cloud computing nyújtotta előnyökből, az erőforrások optimalizálásából, a költséghatékony üzemeltetési modellből.

A hoszting piacon is egyre több a szereplő, növekszik a lehetséges megoldások száma, és ehhez mérten, egyre többen választják annak lehetőségét, hogy adataikat a felhőben helyezik el.

Sokkal inkább áll az utunkba a szemlélet, a bizalmi, biztonsági aggályok, amelyeken ha túl tudunk lépni ügyfélként, egy új fejlődési pályára állíthatjuk áruházunkat, cégünket. Nem csupán a multik kiváltsága, hogy a hatékonyságunkat a felhőben lévő számítási kapacitások kihasználásával növeljük. A BuiltWith oldal szerint a felhőbe telepített Magento piacterek száma közel 12 000!

Érdemes elgondolkodnunk egy új megoldáson, hogy ha webshopunk nem tudta vevőinket maradéktalanul kiszolgálni a legutóbbi terhelések során, ha újra szeretnénk kalkulálni a működésünket érintő IT beruházásokat, ha korszerűsíteni szeretnénk vállalati infrastruktúránkat.

Keressünk meg referenciákat felmutatni tudó szolgáltatókat, és kérjük ki véleményüket, hogy milyen módon tudják szakértelmüket és a felhőben rejlő óriási kapacitást kihasználni webáruházunk érdekében.

 

tips UPDATE: Az olvasói kommentek alapján két alfejezettel egészítettük ki cikkünket.

Az első segít kiválasztani a Magento webshopodhoz leginkább megfelelő AWS EC2 infrastruktúrát. Ezt Mikó János, tapasztalt rendszeradminisztrátor kollégánk írta.

A második útmutatót az AionHill IT vezetője, Bognár Tamás írta, aki lépésről lépésre megmutatja neked, hogyan installálható a Magento az AWS felhőkörnyezetbe.

 

Melyek a Magento webshopodhoz leginkább illő AWS EC2 instance-ok, vagyis virtuális gép-példányok?

 

A fejezet címében szereplő kérdést kicsit átértelmezve – és kihagyva belőle a „leginkább” szócskát – gyors, egymondatos választ tudunk adni, hiszen a legkisebb példányokon kívül szinte bármely AWS Instance képes lehet egy Magento 1-es webáruház futtatására.

Ami nem mindegy, az a hogyan.

A válasz legtöbb esetben nem egyszerű, kifejezetten több tényezős játszma, rengeteg körülményt kell mérlegelni. Ebben a részben ezeket a tényezőket fogjuk kategorizálni, majd elemezni, hogy átfogó képet festhessünk arról, hogy melyik a te webshopodhoz leginkább illő megoldás.

Fontos szem előtt tartani, hogy a Magento 1-es és 2-es főverziói között óriási ugrás történt, szinte a teljes rendszert újra írták, minden szempontból erőforrásigényesebb lett.

Ettől eltekintve azonban két nyomvonal mentén határozhatjuk meg azokat a tényezőket, melyeket figyelembe kell vennünk, amennyiben egy AWS EC2 Instance-ra Magento-t szeretnénk telepíteni (és később az elvárásainknak megfelelő stabilitást tapasztalni rajta).

 

Ezek a kategóriák a következők:

  • A technológiai környezet felépítése, minősége, komplexitása:
    • a webszerver és a php motor, valamint ezek optimalizáltsága
    • cache mechanizmusok használata (OPcache, Varnish, Redis, Elasticsearch)
    • adatbázis mérete, elhelyezése
    • „külső” megoldások használata
    • a futtatott kód minősége
  • Az oldal látogatottsága, a terhelés eloszlása

 

A Webkiszolgáló és a PHP feldolgozó

 

Elsőként a rendszer kisebb erőforrást igénylő elemeiről is szót ejtve a webszerverről beszélnénk.

Bár manapság igen széles választék áll rendelkezésünkre, a Magento hivatalos dokumentációja szerint kettő hivatalosan is támogatott webkiszolgáló áll rendelkezésünkre, ezek az Apache Foundation által fejlesztett Apache HTTP Server és az Igor Sysoev nevével fémjelzett nginx.

A kettő között – ahogyan sebességben – manapság erőforrásigényben is egyre kevésbé jelentős a különbség, azonban szigorúan a teljesítménynél és a memóriafogyasztásnál maradva számunkra az nginx lehet a megfelelő választás. Természetesen rengeteg szempont van, melyeket az üzemeltetés során figyelembe kell vennünk, finomhangolhatjuk a webszerverünk memória-, és processzoréhségét.

Ismerve a webszerverek funkcióit (nagyon leegyszerűsítve ez nem más, mint a statikus tartalomra irányuló kérések közvetlen kiszolgálása, dinamikus tartalom során pedig a kérések továbbítása a PHP feldolgozónak) kijelenthetjük, hogy megfelelően optimalizált webszervernek egy Magento webáruház minimális kiszolgálásához 1-200 MB memóriánál többet nem szabad elfogyasztania. (Természetesen több 10 000 felhasználó kiszolgálásakor ez a szám ugrásszerűen megnő!)

Ami lényegesen nagyobb befolyással bír a kiszolgálás sebességére, az a merevlemez olvasási sebessége, ami miatt mindenképp érdemes a manapság egyre szélesebb körben elterjedő SSD-k mellett letennünk a voksunkat ha Magento tárhelyről beszélünk, mert nagymértékben megnő a teljesítmény a hagyományos, mágneses merevlemezekhez képest.

A PHP motor számára ajánlatos memórialimitet közel sem ennyire könnyű meghatározni.

Már a Magento 1 minimális memóriakövetelménye is 256 MB, az ajánlott pedig 512 MB, azonban ez a szám megugrik Magento 2-t futtatva, ahol 2 GB memória alatt lapozómemória (swap) használatát javasolják.

Ezen számok ismeretében kijelenthetjük, hogy Magento 1 futtatásához az AWS legkisebb Instance-án kívül (t2.nano), szinte bármelyik elég lehet, azonban ha Magento 2-es webshopot szeretnénk futtatni, azt mindenképpen olyan rendszerrel kell megtámogatnunk, amely legalább 2 GB memóriával rendelkezik.

Azt azonban semmiképp se felejtsük el, hogy ezek a számok jelenleg csak a minimális futtatókörnyezet kiszolgálására elegendőek, tehát még nem számoltunk azzal, ha cache mechanizmusokat (pl.: Varnish, Redis) szeretnénk beépíteni a rendszerbe, továbbá saját, dedikált adatbázis-kiszolgáló futtatásának a gondolata sem merült fel egyelőre.

 

Cache mechanizmusok használata a rendszerben

 

memory-cache-example

 

Ahhoz, hogy megértsük a különböző gyorsítótárak (cache-ek) erőforrás szükségletét, mindenképpen érdemes legalább pár szóban beszélnünk arról, hogy hogyan is működnek és mi a céljuk.

Gyorsítótárakon olyan átmeneti tárolóelemeket értünk, melyek célja az adatok hozzáférésének gyorsítása.

Egyszerű szemléltető példaként képzeljük el azt, hogy egy képet szeretnénk kiszolgálni a felhasználóink kérésére.

 

Ennek a menete elnagyolva a következő: A HTTP szerver a kérést megkapva a merevlemezhez fordul, onnan beolvassa azt, majd továbbítja a felhasználónak. Most képzeljük el, hogy a következő 50 felhasználó mind-mind ugyanezt a képet szeretné megkapni.

A HTTP szerver minden alkalommal a merevlemez irányába irányítja a kérést. Ismerve a merevlemezek (különösen a mágneses lemezek) és RAM-ok közötti olvasási sebességkülönbséget (kiugróan magas – HDD-SSD: 30-500 MB/másodperc, RAM: 4-10 GB/másodperc), adódik az ötlet, hogy mi lenne, ha az olyan adatokat, amelyekre gyakran szükségünk lesz, a memóriában tartanánk?

Ezzel a felismeréssel tulajdonképpen eljutottunk a különböző gyorsítótár megoldások szükségességéhez.

 

 

PHP OPcache

A címben említett gyorsítótár a PHP 5.5 óta a PHP csomag része, korábbi verziókhoz kiterjesztésként lehetett letölteni. Egyszerű, könnyen konfigurálható cachelési megoldás, így ajánlatos a használata. Memóriaigénye: 64–256 MB

 

Varnish

A Varnish szoftver működésébe ebben a cikkben nem mélyednénk bele, azonban itt bővebben is olvashatsz róla.

Használata – különösen Magento 2 webáruház esetén – erősen javallott, az oldalbetöltési idő töredéke lesz a Varnish nélküli rendszeréhez viszonyítva. Működésükből kifolyólag a gyorsítótárak memóriaigényesek.

Az oldalon tárolt tartalomhoz mérten 128 MB-tól kezdve, több GB-os memóriamennyiség adható a Varnish-nak. Ezzel mindenképpen érdemes számolni, ha webáruházunkat AWS-be szeretnénk költöztetni.

 

Redis

A Redis egy opcionálisan használható objektum cache – key/value store –, amelyet a Magento a konfigurációs paraméterei, illetve akár teljes oldalak (FPC) és sessionök tárolására is tud használni.

Használata a hivatalos Magento 2 fejlesztői dokumentáció szerint is ajánlott. Bár a gyári konfiguráció szerint nincs meghatározva hozzá alapértelmezett memóriakorlát, a tapasztalat azt mutatja, hogy nagy látogatottságú, sok termékkel rendelkező webáruházaknak is elegendő 64–1024 MB-ra állítani a Redis által felhasználható memória méretét.

 

ElasticSearch

Az Elasticsearch egy kereső és analitikai motor, amellyel többek között a webáruházunk termékei között gyorsíthatjuk meg a keresést. Kevéssé elterjedt, nagy számítási- és memóriaigényű megoldás, melyet hivatalosan csak a Magento 2 Enterprise Edition támogat.

Community Editionhöz és korábbi kiadásokhoz modul formájában érhető el. Minimális memóriaigénye 256 MB, az ajánlott pedig 1 GB körülire tehető.

 

Adatbázis

A futtatókörnyezet felépítése során magától értetődőnek tűnhet, hogy az adatbázis egyazon szerveren helyezkedjen el, ahol a webkiszolgáló (Apache/nginx), illetve a PHP kéréseket feldolgozó modul (php-fpm) található.

Kisebb, induló webáruházaknál (kevés termék, alacsonyabb látogatottság) még nem szükséges számottevő erőforrással támogatni az adatbázis-kiszolgálót, viszont soktermékes, nagy látogatottságú oldalaknál az adatbázis kiszolgálásához erős processzorra és rengeteg memóriára lesz szükség.

Ebben az esetben már érdemes elgondolkodnunk rajta, hogy másik szerveren, akár több másik szerveren is, esetleg az AWS adatbáziskezelő megoldásában dedikáltan és skálázottan futtatjuk webáruházunk adatbázisát.

A fejezet elején említett, kis látogatottságú, kevés termékkel rendelkező webshop megfelelően finomhangolt adatbázisához kb. 256–512 MB memóriának bőven elégnek kell lenni, viszont mindenképp fontos kiemelni, hogy ez a szám erősen nőni fog, ha sikeressé válik webáruházunk.

 

„Külső” megoldások használata

 

A külső-t itt képletesen kell érteni, hiszen ezek is AWS szolgáltatások, azonban az EC2 Instance-unkon kívüli szolgáltatásokról beszélünk.

Ha már eldöntöttük, hogy AWS-be szeretnénk költöztetni webáruházunkat, és épp azt mérlegeljük, hogy milyen méretű EC2 Instance-t válasszunk, említést kell tenni azokról a „külső” megoldásokról, melyeket az AWS kínál.

Ezek a fenti szolgáltatásokra nyújtanak AWS által menedzselt megoldást. Előnyük, amellett hogy nagyban lecsökkentik a szükséges EC2 Instance méretét az, hogy jól skálázhatók, illetve az üzemeltetésük könnyű.

Cserébe elég drága szolgáltatásokról beszélünk, így ha van egy olyan szakember a közelünkben, aki magabiztosan üzemelteti ezeket számunkra, akkor jobb választásnak bizonyulhat, ha magunknak telepít(tet)jük őket az EC2 Instance-unkra.

A szolgáltatásokat és azok AWS által nyújtott megfelelőjét az alábbi táblázat foglalja össze:

 

Szolgáltatás neve

Szolgáltatás AWS-beli megfelelője

MySQL

Amazon RDS

Redis

Amazon ElastiCache

Elasticsearch

Amazon Elasticsearch Service

 

A futtatott kód minősége

 

Az üzemeltetési oldal mellett van lehetőségünk Magento webáruházunk kód szintű optimalizálására is, mellyel további értékes erőforráspazarlástól kímélhetjük meg magunkat és pénztárcánkat.

A témával kapcsolatos optimalizálási tanácsokat ezen a linken találhatsz.

 

Az oldal látogatottsága, a terhelés eloszlása

 

Az eddigiekben összegyűjtött szempontokkal összefüggésben kiemelten fontos beszélnünk a technikailag kevésbé kézzel fogható (ha áll rendelkezésünkre korábbi adat, akkor mérhető, becsülhető) tényezőkről.

Meg kell vizsgálnunk azt, hogy áruházunknak napi szinten mennyi látogatója van, illetve, hogy melyik napszakban érkezik a legnagyobb terhelés.

Ha magas ügyfélelégedettséget szeretnénk elérni, akkor úgy kell megválasztanunk az erőforrásainkat, hogy a legmagasabb látogatottságot is képesek legyünk kiszolgálni.

A fentebb említett minimális rendszerigények ténylegesen csak a rendszer minimális futtatására és nagyon kevés felhasználó kiszolgálására elegendőek!

 

Ha a legmagasabb látogatottságot is ki szeretnénk szolgálni, annak behatárolására két módszert tudunk javasolni:

  • költséghatékony: kisebb teljesítményű instance-t választunk és a terhelést figyelve felskálázzuk az instance méretét,
  • drága, de biztonságos: nagy teljesítményű instance-t választunk és a terhelést figyelve addig csökkentjük az erőforrásokat, amíg el nem érjük a stabilitás határát.

 

Arról, hogy hogyan tudjuk mérni áruházunk maximális terhelését, korábban itt írtunk.

Bár eddig többnyire a memóriaméretekkel foglalkoztunk, fontos megjegyezni, hogy a látogatószámmal arányosan a processzorhasználat is nő, így 1 VCPU-val rendelkező, kisméretű EC2 példányokat nem tudunk ajánlani a futtatáshoz.

Amennyiben a látogatószámunk már igen magas, úgy érdemes a számítási teljesítményre optimalizált (C3-C4) példányokra beruháznunk.

 

Melyik a legkisebb EC2 instance, amelyen még képes lehetsz futtatni egy Magento 2.0+ környezetet?

 

Az összefoglaló táblázatból kiderül, hogy Magento 2 futtatásához elegendő lehet egy t2.medium példány, azonban ha sikeres webáruházat szeretnénk és a célunk nem 3-5 felhasználó egyidejű kiszolgálása lesz, akkor mindenképp érdemes a nagyobb instance-ok felé (ha hosszú távra tervezünk, akkor pedig több példány használata felé) irányítani a figyelmünket.

 

Konklúzió

Ebben a részben megismerkedhettél azzal, hogy nagyjából milyen szolgáltatásokra (és ezek futtatásához milyen erőforrásokra) lesz szükséged ahhoz, hogy Magento webáruházad kényelmesen üzemeltethesd AWS környezetben, azonban az erőforrások összeszámolására eddig nem került sor.

Az alábbi táblázatban megpróbáljuk összefoglalni, hogy milyen EC2 instance-ra lesz szükséged webáruházad biztonságos kiszolgálásához, de a megfelelő instance-ok mérete nagymértékben a forgalomtól is függ, amely a kiszolgálón landol.

Tehát a táblázatban feltételezzük azt, hogy az áruház látogatottsága nagyon alacsony (3-5 konkurens felhasználó, maximum ~300 látogató/nap ).

Ennél magasabb látogatottságú áruházak költöztetésekor a döntéshez mindenképp szakértői segítséget javaslunk, mert a vásárlóink áruházunkba és annak zavartalan működésébe vetett bizalma az egyik legnagyobb érték!

Látogatók száma Szolgáltatáskészlet Magento 1 Magento 2
300/nap, max 1-3 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL t2.small+ t2.small+
300-400/nap, max 2-3 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL t2.medium+ t2.medium+
300-500/nap, max 3-5 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis t2.medium+ t2.large+
400-800/nap, max 3-8 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis t2.large+ m4.large+
400-800/nap, max 3-8 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis + Elasticsearch t2.large+ m4.large+
600-1200/nap, Max 5-15 konkurens Egy szerveres: NGINX + PHP (+OPcache) + MySQL + Varnish + Redis + Elasticsearch m4.large+ c4.xlarge+

A táblázat tehát tájékoztató jellegű és a minimális követelményekre koncentrál (mind hardver, mind látogatottság tekintetében).

 

 

Hogyan telepítsd a Magento-t AWS-ben? (Gyakorlati útmutató)

 

A Magento napjaik egyik legelterjedtebb ingyenesen használható webáruházmotorja. Egy egyszerű áruházat pár kattintással létre lehet hozni.

Ez az alap oldal persze az esetek nagy részében nem használható komoly online kereskedésre, kisebb-nagyobb átalakításokra szüksége lesz, hogy vásárlóbarát kinézete legyen.

A webáruházak hosztingjára egyre népszerűbb és kényelmesebb megoldást nyújt az Amazon felhő szolgáltatása, az Amazon Web Services (AWS).

Mi az AionHill-nél is ezt ajánljuk és használjuk több okból, melyet egy másik cikkünkben részletesebben kifejtettünk már.

Ebben a részben lépésről lépésre bemutatjuk, hogyan lehet egy Magento áruházat telepíteni AWS környezetben.

 

A sokféle telepítési lehetőség közül hármat szeretnénk kiemelni:

  • 1) Egy teljesen üres gépre kézzel feltelepítjük a szolgáltatásokat (web és adatbázisszerver, php) és beállítjuk a saját magunknak a konfigurációt. Majd telepítjük a Magento-t.
  • 2) Keresünk egy meglévő, előre telepített AMI-t (Amazon Machine Images), amire előre fel vannak telepítve a szükséges szolgáltatások. Mi is rendelkezünk egy ilyen előre elkészített rendszerrel.
  • 3) A harmadik lehetőség, hogy keresünk egy Magento hosztinggal foglalkozó céget és megbízzuk, hogy az igényeinknek megfelelően végezzék el nekünk a beüzemelést. Legyen szó egy meglévő áruházról, vagy egy teljesen újról.

 

A fent említett pontok közül részletesebben a második lehetőséget mutatjuk be, miszerint egy meglévő AMI-t használunk a Magento webáruház beüzemeléséhez.

A leírásban végigmegyünk azon, hogyan készítsük el a saját EC2 gépünket, majd azon telepítünk egy Magento áruházat.

 

 

EC2 instance létrehozása

 

Első lépésként jelentkezzünk be az AWS fiókunkba. Ha ez megtörtént válasszuk ki a megfelelő zónát, ahol a gépet szeretnénk futtatni.

Segít ebben az alábbi kép, ha ezt látjuk jó úton indultunk el:

 

01-aws-account

 

Majd lépjünk az AWS EC2 menedzsment felületére és kattintsunk a Launch instance gombra.

A következő képernyőn – Choose an Amazon Machine Image (AMI) – lehetőségünk van kiválasztani az előre elkészített sablonok közül a nekünk megfelelőt.

A cikkben, ahogy azt korábban említettük, az AionHill által előre elkészített nyilvános sablont fogjuk használni. Ezen előre fel van telepítve az adatbázis és a webszerver, valamint a php.

A Community AMIs fülön az AIONHILL-Magento-Public sablont kell megkeresni és kiválasztani.

 

 

Ezután tudjuk beállítani a szerverünk erőforrásait: Choose an Instance Type.

A leírásban – alapbeállítás – t2.mirco instance-ra fogjuk telepíteni a Magento webáruházat.

Ezt a változatot éles környezethez semmiképpen sem ajánljuk!

 

02-aws-instance-configure-magento

 

Következő lépésként a hálózat beállítását fogjuk elvégezni.

A network és subnet paraméterek, valamint a hálózati eszközök adatait szükséges megadni. Itt használhatunk egy meglévő hálózatot, vagy készíthetünk egy újat külön ennek a szolgáltatásnak.

Ezután a szerverünk tárhelyének adatait tudjuk megadni.

A sablonban előre be van állítva egy 10 GB-os lemez a rendszernek. Az a javaslatunk, hogy a Magento-t ne erre, hanem egy másik, dedikált lemezre telepítsük.

Adjunk hozzá, egy 20 GB méretű lemezt és fontos megjegyeznünk, hogy az extra lemezt milyen néven (Device) adjuk hozzá a géphez. Az utolsó betűt (esetünkben a b) jegyezzük meg, mert ezzel a jelöléssel fogjuk megtalálni a lemezt a gépen belül.

 

03-aws-instance-storage-magento

 

A következő fülön a hálózati beállításokat tudjuk személyre szabni.

Az általunk telepített géphez a következő szabályokat kell beállítani, hogy elérhetőek legyenek mindenhonnan:

  • SSH eléréshez: 22-es port
  • HTTP és HTTPS eléréshez a 80-as és 443-as port

 

Miután ellenőriztük a gépünk beállításait, minden akadály elhárult az elől, hogy el tudjuk indítani.

Végső lépés, hogy meg kell adnunk egy SSH kulcspárt, amellyel távolról be tudunk lépni a gépünkre.

 

Magento 1 telepítése

 

1)

A gép telepítés és indítás utolsó lépéseként megadott SSH kulcspár privát kulcsával belépünk a szerverünkre. A publikus részt az AWS beilleszti a megfelelő helyre a telepítés után.
Windows-on erre alkalmas program a Putty, a Linuxon a következő módon lehet belépni a terminál segítségével:

ssh ubuntu@elasztikus-ip-cím -i /útvonal/a/privát-kulcsunkhoz

2)

A belépés után első lépésként frissítsük a rendszerünket a legfrissebb állapotra:

apt update && apt upgrade

3)

A gép telepítése során kiemeltük, hogy a Magento dedikált lemezre kerüljön. A használatbavétel előtt szükséges pár parancsot futtatni:

 

 # először létrehozunk az eszközön egy új partíciós táblát  
 # valamint egy darab partíciót, amely a teljes lemezterületet felhasználja  
 sudo parted -s /dev/sdb mklabel msdos mkpart primary ext4 1MiB 100% print  
   
 # az új partíciót ext4 fájlrendszerűvé formázzuk  
 sudo mkfs.ext4 /dev/sdb1  
   
 # a partíció csatolási pontját rögzítjük az fstabban  
 sudo /bin/bash -c "echo '/dev/sdb1  /var/www/webapp/  ext4  defaults,noatime  0 2' >> /etc/fstab"  
   
 # majd felcsatoljuk a /var/www/webapp/ könyvtár alá  
 sudo mount /var/www/webapp/  
   
 # végül beállítjuk a könyvtárhoz a megfelelő tulajdonost  
 sudo chown webapp:webapp /var/www/webapp  

 

4)

Adatbázis beállításainak módosítása, személyre szabása:

Az AionHill által biztosított AMI teljesen publikus, így kérjük, mindenképp változtasd meg a MySQL jelszavakat, mert más felhasználók számára ugyanaz lesz az alapértelmezett jelszó, mint számodra.

Ezen jelszavak megváltoztatására szintén az alábbi egysoros szkripteket ajánljuk. Az általad választott jelszót írd be a sorok elején a változók értékadásához.

Például:


 SQLROOTPWD='általad-választott-jelszó'
 SQLWAPWD='általad-választott-jelszó-2'
 SQLROOTPWD='PASSWORD-FOR-ROOT'; sudo -i mysql -e "SET PASSWORD FOR 'root'@'localhost' = PASSWORD('$SQLROOTPWD');" && sudo sed–i "s/^password=.*/password=$SQLROOTPWD/g" /root/.my.cnf
 SQLWAPWD='PASSWORD-FOR-WEBAPP'; sudo -i mysql -e "SET PASSWORD FOR 'webapp'@'localhost' = PASSWORD('$SQLWAPWD');"

 

Ezek a jelszavak nagyon fontosak, jegyezzük fel őket, mert a későbbiekben (10-es lépés) még használni fogjuk őket! (Root PWD: adminisztrátori jelszó, WA PWD: web alkalmazás jelszó [ezt a Magento fogja használni])

 

5)

Ha ezekkel készen vagyunk, akkor be kell szereznünk a Magento forráskódját, hogy nekifoghassunk a telepítésnek. Ezt érdemes egyből a Magento-t futtató felhasználó nevében csinálni.

sudo su -s /bin/bash webapp

 

6)

Felhasználóváltás után lépjünk abba a könyvtárba, ahová a Magento-t fogjuk telepíteni:

cd /var/www/webapp/www

 

7)

Töltsük le a forráskódot és csomagoljuk ki, az alábbi parancsokkal:

wget https://github.com/OpenMage/magento-mirror/archive/magento-1.9.zip

unzip magento-1.9.zip

mv magento-mirror-magento-1.9/ magento

rm –f magento-1.9.zip

 

8)

A következő mappák jogosultságait szükséges módosítani a megfelelő működéshez:

chmod -R o+w app/etc/

chmod -R o+w var/

chmod -R o+w media/

 

9)

A telepítés megkezdése előtt már csak egy dolgot kell beállítanunk: a webszervert.

Ehhez ismét egy szkriptet biztosítunk, amelynek elkészítéséhez a Magento telepítővel érkező konfigurációs fájlt vettük alapul.

Az lenti kódot a terminálba illesztve egy nginx konfigurációs állomány fog létrejönni a következő helyen:

/etc/nginx/sites-available/webapp.conf

 

A konfigurációs fájlban a server_name változó „mage.dev” értékre lesz beállítva, amely azt jelenti, hogy az nginx a mage.dev domain nevet fogja megfelelően kiszolgálni.

Ha más néven szeretnénk használni Magento-nkat, akkor a server_name mezőt át kell írni az általunk választott domainre a későbbiekben.

 


sudo /bin/bash -c 'echo -e " server {
    server_name magedev;

    listen              80;
    ssl off;

    root               /var/www/webappp/www/magento;
    access_log         /var/log/nginx/access.log  main;
    error_log          /var/log/nginx/error.log  warn;

    location / {
        index  index.html index.htm index.php;
        try_files $uri $uri/ @handler;
        autoindex off;
    }

    location /app/                { deny all; }
    location /includes/           { deny all; }
    location /lib/                { deny all; }
    location /media/downloadable/ { deny all; }
    location /pkginfo/            { deny all; }
    location /report/config.xml   { deny all; }
    location /var/                { autoindex on; }
    location  /. {
        return 404;
    }

    location @handler {
        rewrite / /index.php;
    }

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

        location ~ .php/ {
        rewrite ^(.*.php)/ $1 last;
    }

    error_page  404              /404.html;
    location = /404.html {
        #root   /usr/share/nginx/html;
        return 404;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        #root   /usr/share/nginx/html;
        #return 404;
    }
}” > /etc/nginx/sites-available/webapp.conf'

 

A konfiguráció engedélyezéséhez egy szimbolikus linket kell készítenünk a fájlról a megfelelő mappába, majd újra kell indítanunk az nginx webszervert.

sudo ln -s /etc/nginx/sites-available/webapp.conf /etc/nginx/sitesenabled/webapp.conf

 

sudo systemctl restart nginx.service

 

 

10)

Elérkeztünk a Magento  telepítéséhez. Kedvenc böngészőnk címsorába gépeljük be a következőt:

http://az-általunk-választott-domain/setup/

Ha mindent az útmutatásnak megfelelően csináltunk, akkor a következő ablak fogad minket:

 

04-aws-install-magento

 

Az „I agree to the above terms and conditions.” jelölőnégyzetet bepipálva lehetőségünk van tovább haladni a telepítésben.

Első lépésként be kell állítani a lokalizációs adatokat:

 

05-aws-install-magento-localization

 

Következőként a Magento-t kiszolgáló adatbázis hozzáférést kell beállítanunk.

Ezt a leniti ábra szerint kell kitölteni, a User Password mezőbe pedig azt a jelszót kell beírnunk, melyet korábban (4-es lépés) a második szkripthez adtunk meg (SQLWAPWD).

 

06-aws-install-magento-configuration

 

Az adatok kitöltése után tudunk tovább haladni.

 

07-aws-install-magento-admin-account

 

A Create Admin Account fülön egy adminisztratív felhasználó hozzáféréseit rögzíthetjük.

A felhasználónév, e-mail cím és a jelszó megadása, majd megismétlése után a „Continue” gombra kattintva elérkeztünk a végső lépéshez.

 

Itt lehetőségünk van megtekinteni a backend és frontend oldalt:

 

08-aws-install-magento-all-set

 

Ha minden jól csináltunk, az alábbi oldalakat kell látnunk a böngészőben.

 

Frontend:

 

09-aws-install-magento-frontend

 

Backend:

 

10-aws-install-magento-backend

 

A cron jobok, vagyis időzített folyamatok beállításához az alábbi parancsot kell kiadnunk, amely egy lépésben engedélyezni fogja a Magento-t futtató felhasználó (webapp) számára a cron jobokat a hivatalos Magento dokumentáció alapján:

 

sudo /bin/bash -c “echo -e ‘*/5 * * * *     (cd /var/www/webapp/www/;/bin/sh ./cron.sh) >/dev/null 2>&1’ | crontab -u webapp -“

 

Tovább fejlesztési lehetőségként említenénk meg, hogy a következő szolgáltatások cseréjével jobb teljesítmény érhető el egy nagyobb áruháznál. A Mysql adatbázis szervert kiválthatjuk az Amazon RDS szolgáltatásával. A Redist cserélhetjük az Amazon EleasticCache-re. Ha élünk ezzel a lehetőséggel, akkor az AMI-ból telepített gépen állítsuk le a Mysql-t és Redist, majd vegyük ki az automatikusan induló programok közül.

 

</p

Hetényi Zoltán

Hetényi Zoltán

Hoszting Szakértő

Zoltán az Amazon Web Services felhő alapú hosztingjának szenteli idejét, folyamatosan keresve a legoptimálisabb megoldásokat az ügyfelek számára. Fő célkitűzése, hogy szakmai segítséget nyújtson a „felhő” iránt érdeklődő webshop tulajdonosoknak éppúgy, mint azoknak, akik már használják ezt a technológiát webáruházuk esetén. Szabadidejében Zoltán szívesen játszik számítógépén, illetve basszusgitározik a legendás RGB együttesben.


SZÜKSÉGE VAN EGY MEGBÍZHATÓ, PROFI MAGENTO FEJLESZTŐ PARTNERRE?

Kérjük, keressen bennünket, ha bármilyen kérdése, igénye lenne új vagy meglévő webáruház készítésével, megújításával kapcsolatban!

Next