Aki már indított valaha virtuális gépet (EC2-példányt) az AWS-ben, az használt már Amazon Machine Image-et, azaz AMI-t. Ebben a posztban az AMI-k használatát járjuk picit körbe.

Az AWS virtuális gépeit nem "telepítjük" a hagyományos értelemben, nem helyezünk virtuális CD-t a virtuális gépbe, hanem egy AMI-ból indulunk ki. Egy AMI lényegében:

• egy vagy több EBS-snapshot
• indítási engedély, ami megmutatja, hogy melyik AWS-account használhatja az AMI-t gépindításra
• egy blokkeszköz-megfeleltetés, ami megmutatja, hogy mely eszközök csatolandók az EC2-példányhoz indítást követően.

Az AWS minden általa jelentősebbnek ítélt operációs rendszerből (Amazon, Red Hat, SuSE, és Ubuntu Linux, illetve Microsoft Windows) készített AMI-t, és alighanem ezeket használjuk a legtöbbet. Az AWS piactéren vásárolhatunk magunknak olyan AMI-t, ami mondjuk a kedvenc IPS-ünket (Intrusion Prevention System, behatolásmegelőző-rendszer), tartalmazza. Válogathatunk sok-sok közösségi AMI-ból, de talán ennél is lényegesebb, hogy tudunk saját AMI-t létrehozni. De hogyan?

• Egy saját, nem felhőben futó virtuális gépet exportálva, és az AWS-felhőjébe feltöltve, vagy
• egy EC2-példányból kiindulva.

És hogy mire jó nekünk a saját AMI? Hát természetesen arra, hogy olyan gépünk legyen, amilyet szeretnénk. Ha pontosan beállított gépre vágyunk, amelyik indítás után a mi beavatkozásunk nélkül azonnal képes futtatni a megfelelő alkalmazást, akkor az egyik lehetőség, hogy bootstrap scriptet készítünk, és ezzel a scripttel telepítünk mindent, ami kell. A másik, hogy elindítás után kézzel beállítjuk a gépet, megállítjuk, és AMI-t készítünk belőle, és majd ebből indulnak a gépeink. Mindkét módszernek megvannak az előnyei és hátrányai.

AMI-t használhatunk olyankor is, amikor egy már létező gépet kell másik AZ-be, vagy másik régióba költöztetnünk, vagy ha utóbb mégis kiderült, hogy titkosítanunk kell a háttértárát.

Sok cég követi azt a módszert, hogy egy (vagy éppen sok) saját AMI-t használ - mert biztos lehet abban, hogy ezek a gépek megfelelnek a céges előírásoknak - és ebből indítja a saját gépeit. Az indításra pedig bátran használhatjuk az EC2-szolgáltatás API-ját (ha szívesen néznél erről videót, akkor iratkozz fell a YouTube-csatornánkra, lesz ilyen ingyenes videónk), vagy parancssort:

aws ec2 run-instances --image-id ami-076431be05aaf8080 --count 1 --instance-type m5.large --key-name SajatKulcs --security-groups SajatSecurityGroup

Akármelyik módszert használjuk, az a gondunk adódhat belőle, hogy változik az AMI - vagy azért, mert az AWS frissít verziót az általa karbantartott AMI-knál, vagy mert a cégünk megfelelő csoportja teszi meg ugyanezt a saját, céges AMI-k esetében. Ilyenkor aztán nézhetjük végig az összes scriptünket, szoftverünket, és cserélgethetjük az AMI azonosítóját, hiszen a gép indításakor azt meg kell adni (a fenti példában vastaggal kiemelve).

Ezen a problémán segít egy, a közelmúltban bejelentett új lehetőség, amellyel arra nyílik mód, hogy a Systems Manager Parameter Store-ban álneveket hozzunk létre az AMI-jainkhoz. Ezt követően még egyszer módosítanunk kell a scriptjeinket és programjainkat: az AMI-azonosítókat lecseréljük az álnevekre. Mostantól az álnevekkel hivatkozunk az AMI-kra, és így indítjuk az EC2-példányokat.

aws ec2 run-instances --image-id resolve:ssm:aLegjobbAMI --count 1 --instance-type m5.xlarge --key-name SajatKulcs --security-groups SajatSecurityGroup

Ha legközelebb frissül az AMI, akkor már csak a Parameter Sore-ban követjük a frissülést az álnév napra készre állításával. A Parameter Store egyébiránt sokmindenre jó még, alighanem egyszer erről is készítünk videót, aprók és nagyok épülésére.