Anatomi av en AWS CloudFormation-mall

Med hjälp av en supportbiljettjänst som mitt exempel på SaaS-lösning har jag visat hur vem som helst kan dra nytta av de verktyg som erbjuds av Amazon Web Services för att ta din idé från en affärsplan till en produkt som är tillgänglig för dina kunder via molnet. Hittills har vi arbetat med planerings- och designhänsyn, byggt ett IaaS-lager och använt AWS CloudFormation-mallar för att skapa ett mycket tillgängligt kluster. Vi är nu redo att börja polera applikationen.

Nästa steg är att ändra AWS CloudFormation-mallen för att automatisera uppbyggnaden av min supportbiljettjänst. Jag har ett kluster med hög tillgänglighet, Drupal, en RDS-databas, brandväggsregler, en lastbalanserare och så vidare. Det är en fantastisk sak att uppnå med ett webbgränssnitt och några musklick.

Men det är inte tillräckligt fantastiskt. Jag måste redigera CloudFormation-mallen för att föra den närmare mina behov, men först måste jag veta vad som finns i den och var jag behöver göra nödvändiga ändringar. Nedan ger jag dig en översikt över alla delar.

Polering av min tjänst betyder att jag kommer in i utvecklarens territorium

Tjänsten som tillhandahålls av AWS CloudFormation Drupal-mallen är inte vad jag vill ha. Jag kommer att justera den mallen här för att göra nödvändiga ändringar. Tyvärr innebär detta att man går över till utvecklarens territorium. Jag kommer inte att göra hela resan, för utvecklare territorium är en öde ödemark som är obehagligt att besöka. Jag täcker tillräckligt för att tända vägen.

En kombination av Drupal-moduler

SaaS-företag bygger sina tjänster. De tar inte vita etikettvaror och tar på sig märket. Jag kommer att bygga min supportbiljettjänst med hjälp av Drupal Core CMS verktygssats, ett gäng extra tillbehör och mycket utvecklingstid.

Men det finns många valfria moduler för Drupal som jag kan stränga ihop för att minska utvecklingstiden.

  • Supportbiljettjänsten kommer från supportmodulen. Supportmodulen tillhandahåller verksamhetens slut på min tjänst.
  • Den intäktsmekanismen kommer från en uppsättning av handelsmoduler . Dessa hanterar e-handelssidan. Drupal Commerce är en stor samling med nästan tjugo moduler att installera och många fler stödmoduler. Dessa ger ramen för att hantera kunder, skatt, radposter, betalning, produkter och så vidare.
  • Kontrollen av detta premiuminnehåll hanteras av Content Access- modulen och andra saker, till exempel mekanismen för åtkomstkontroll för roller . Dessa moduler fäster handeln och stödjer biljettdelarna.

Vad finns i en AWS CloudFormation-mall

Jag kan redigera en AWS CloudFormation-mallfil efter mina behov.

Klicka för att förstora.

Först måste jag förstå vad en mall är. Här är en kort översikt. För en mer detaljerad beskrivning, se AWS-guiden Bootstrapping-applikationer via AWS CloudFormation.

De lilla automatiska gremlinerna som bygger CloudFormation tar sina instruktioner från en konfigurationsfil som ser lite ut så här.

 { 
 "AWSTemplateFormatVersion": "versiondatum", 
 "Description": "Giltiga JSON-strängar upp till 4K", 
 "Parametrar": { 
 tangenter och värden 
 }, 
 "Kartläggningar": { 
 tangenter och värden 
 }, 
 "Resurser" : { 
 tangenter och värden 
 }, 
 "Utgångar": { 
 tangenter och värden 
 } 
 } 

Denna text, med dess liberala strö av lockiga hängslen, citat och kolon, är JSON (JavaScript Object Notation). JSON är populär bland utvecklare som inte vill ha XML: s ordlighet men inte är tillräckligt coola för YAML.

Nycklarna och värdelinjen i exemplet ovan skulle se lite ut så här i en riktig mallfil.

 "S3Bucket": { 
 "Type": "AWS :: S3 :: Bucket", 
 "Egenskaper" : { 
 "AccessControl": "PublicRead", 
 "Webbplatskonfiguration": { 
 "IndexDocument": "index.html", 
 "ErrorDocument": "error.html" 
 } 
 } 
 } 

Allt detta intryck är en mängd kapslade nyckel- / värdepar. Det är komplicerat och det är bara toppen av isberget. Mallfiler är nörd himmel.

Startkonfig

Resursavsnittet i mallfilen innehåller ett underavsnitt som heter LaunchConfig . Det här avsnittet börjar med den här raden.

"LaunchConfig": {

Avsnittet LaunchConfig är 200 linjer med smarthet. Den har en lista över filer att installera, ladda ner och skapa. Det har också ett helt bash-skript inbäddat i det.

Jag använder den klusterade Drupal-mallen. Du kan se det här: Mycket tillgänglig webbserver med Multi-AZ Amazon RDS-databasinstans och använda S3 för att lagra filinnehåll.

Senare kommer jag att göra några ändringar i LaunchConfig- avsnittet i den här mallen och skapa ett kluster.

Det inbäddade basskriptet

Basskriptet i LaunchConfig- avsnittet ligger längst ner i filen. Skriptet är cirka 60 rader långt och ser ut så här.

"UserData" : { "Fn::Base64" : { "Fn::Join" : "",  
  "#!/bin/bash -v\n",  
  "yum update -y aws-cfn-bootstrap\n",  
 ... 
 ... 
 ... 
  "# All is well so signal success\n",  
  "/opt/aws/bin/cfn-signal -e 0 -r \"Drupal setup complete\" '", { "Ref" : "WaitHandle" }, "'\n" 
 
  }} 

Jobbet med denna störande snygga mallkod är att lägga in alla dessa rader i ett bash-skript.

Ett basskript är en samling av kommandon som gör alla möjliga saker för systemet. Systemadministratörer har skrivit skript i decennier. Detta smarta bash-skript redigerar Apache-webbserverkonfigurationen, listar alla nya EC2-maskiner, sätter upp en grundläggande Drupal-webbplats och så vidare.

Detta skript kopieras till varje ny EC2 VM. Det hamnar i katalogen / var / lib / cloud / data / scripts / . Alla meddelanden som den producerar hamnar i /var/log/cloud-init.log .

EC2-maskinernas filer och kataloger

Att distribuera en applikation över många servrar är svårt. Du måste veta vad som kopieras, vad som delas och vart det borde gå.

Massor av filer dupliceras över maskinerna. All den allmänna koden (Drupal Core) kopieras till webbplatskatalogen på varje ny server (den är i / var / www / html ).

S3-hinken

Vissa av filerna delas mellan maskiner. En bit av filsystemet är faktiskt en AWS S3 (Simple Storage Service) hink. Det delade området är monterat på alla tre servrar (on / var / www / html / sites / default / files ). Vissa Drupal-filer kommer att sitta i denna S3-hink.

S3-hinkar används vanligtvis för statisk innehåll på webbplatsen, snarare än körbara filer, loggar och andra knepiga filer. Denna S3-hink håller uppladdningar av kundfiler. En kund laddar upp en fil en gång, då kan alla webbservrar svara på förfrågningar för den här filen.

Mallbackup

Bry dig inte om att lagra din nya mall på webben. Du kan ge CloudFormation en URL för att få din mallfil, men den fungerar bara med AWS S3 (Simple Storage Service). Det är där AWS lagrar sina mallar. Det är där din uppladdade mall lagras. Utvecklare som använder ett kodförvar som Github eller Gitorious har turen.

© Copyright 2020 | mobilegn.com