Anatomi af en AWS CloudFormation-skabelon

Ved hjælp af en support-billet-tjeneste som min eksempel på SaaS-løsning har jeg demonstreret, hvordan nogen kan drage fordel af de værktøjer, der tilbydes af Amazon Web Services til at tage din idé fra en forretningsplan til et produkt, der er tilgængeligt for dine kunder via skyen. Indtil videre har vi arbejdet gennem planlægning og designovervejelser, bygget et IaaS-lag og brugt AWS CloudFormation-skabeloner til at skabe en meget tilgængelig klynge. Vi er nu klar til at begynde at polere applikationen.

Det næste trin er at ændre AWS CloudFormation-skabelonen for at automatisere opbygningen af ​​min supportbilletjeneste. Jeg har en klynge med høj tilgængelighed, Drupal, en RDS-database, firewall-regler, en belastningsbalancer og så videre. Det er en fantastisk ting at opnå med en webgrænseflade og et par museklik.

Men det er ikke fantastisk nok. Jeg skal redigere CloudFormation-skabelonen for at bringe den nærmere mine behov, men først skal jeg vide, hvad der er der, og hvor jeg skal foretage de nødvendige ændringer. Nedenfor giver jeg dig en oversigt over alle dele.

Polering af min service betyder, at jeg kommer ind i udviklerens område

Tjenesten, der leveres af AWS CloudFormation Drupal-skabelonen, er ikke det, jeg ønsker. Jeg vil finjustere den skabelon her for at foretage de nødvendige ændringer. Desværre betyder dette at krydse ind i udviklerområdet. Jeg vil ikke tage hele rejsen, fordi udviklerområdet er et øde ødemark, som det er ubehageligt at besøge. Jeg vil dække nok til at lyse op.

En kombination af Drupal-moduler

SaaS-virksomheder bygger deres tjenester. De tager ikke hvidmærkede varer og sætter deres badge på. Jeg vil opbygge min support-billet-service vha. Drupal Core CMS-værktøjssæt, en flok ekstraudstyr og meget udviklingstid.

Der er dog masser af valgfrie moduler til Drupal, som jeg kan strenge sammen for at skære ned på udviklingstiden.

  • Supportbillet-tjenesten kommer fra Support-modulet. Support- modulet giver den forretningsmæssige afslutning af min service.
  • Den indtægtsmekanisme kommer fra et sæt Commerce- moduler. Disse håndterer e-handelssiden. Drupal Commerce er en stor samling med næsten tyve moduler til installation og mange flere understøttende moduler. Disse udgør rammen for håndtering af kunder, skat, linjeposter, betaling, produkter og så videre.
  • Styringen af ​​dette premiumindhold styres af Content Access- modulet og andre ting, såsom Roles adgangskontrolmekanisme. Disse moduler sætter handel og support billetdele sammen.

Hvad er der i en AWS CloudFormation-skabelon

Jeg kan redigere en AWS CloudFormation-skabelonfil, der passer til mine behov.

Klik for at forstørre.

Først må jeg forstå, hvad en skabelon er. Her er en kort oversigt. For en mere detaljeret beskrivelse, se AWS-guide Bootstrapping-applikationer via AWS CloudFormation.

De små automatiske gremlins, der bygger CloudFormation, tager deres instruktioner fra en konfigurationsfil, der ligner lidt sådan.

 { 
 "AWSTemplateFormatVersion": "version dato", 
 "Description": "Gyldige JSON strenge op til 4K", 
 "Parametre": { 
 taster og værdier 
 }, 
 "Kortlægning": { 
 taster og værdier 
 }, 
 "Ressourcer": { 
 taster og værdier 
 }, 
 "Outputs": { 
 taster og værdier 
 } 
 } 

Denne tekst, med dens liberale dryss af krøllede seler, citater og kolon, er JSON (JavaScript Object Notation). JSON er populær blandt udviklere, der ikke ønsker XML's ordlighed, men ikke er cool nok til YAML.

Tasterne og værdieraden i eksemplet ovenfor ville se lidt sådan ud i en ægte skabelonfil.

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

Alt det indrykkede stof er en masse indlejrede nøgle / værdipar. Det er kompliceret, og det er kun toppen af ​​isbjerget. Skabelonfiler er nørdhimmel.

Startkonfig

Ressourcer- sektionen i skabelonfilen indeholder et underafsnit kaldet LaunchConfig . Dette afsnit starter med denne linje.

"LaunchConfig": {

Afsnittet LaunchConfig er 200 linier med kløgtighed. Det har en liste over filer, der skal installeres, downloades og oprettes. Det har også et helt bash-script indlejret i det.

Jeg bruger den grupperede Drupal-skabelon. Du kan se det her: Meget tilgængelig webserver med Multi-AZ Amazon RDS-database-forekomst og bruge S3 til lagring af filindhold.

Senere vil jeg foretage et par ændringer i sektionen LaunchConfig i denne skabelon og oprette en klynge.

Det indlejrede bash-script

Bash-scriptet i sektionen LaunchConfig er placeret i bunden af ​​filen. Scriptet er omkring 60 linjer langt og ser sådan ud.

"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 denne forstyrrende skabelonkode er at sætte alle disse linjer i et bash-script.

Et bash script er en samling af kommandoer, der gør alle mulige ting til systemet. Systemadministratorer har skrevet scripts i årtier. Dette smarte bash-script redigerer Apache-webserverens konfiguration, viser alle de nye EC2-maskiner, opretter et grundlæggende Drupal-websted og så videre.

Dette script kopieres til hver nye EC2 VM. Det ender i kataloget / var / lib / sky / data / scripts / . Alle meddelelser, den producerer, ender i /var/log/cloud-init.log .

EC2-maskinernes filer og mapper

Det er vanskeligt at distribuere en applikation på tværs af mange servere. Du skal vide, hvad der er kopieret, hvad der deles, og hvor det hele skal gå.

Masser af filer kopieres på tværs af maskinerne. Al den generelle kode (Drupal Core) kopieres til webstedets bibliotek på hver nye server (den er i / var / www / html ).

S3-spanden

Nogle af filerne deles mellem maskiner. En bit af filsystemet er faktisk en AWS S3 (Simple Storage Service) skovl. Dette delte område er monteret på alle tre servere (on / var / www / html / sites / default / files ). Nogle Drupal-filer vil sidde i denne S3-spand.

S3-spande bruges normalt til statisk indhold på webstedet snarere end eksekverbare filer, logfiler og andre vanskelige filer. Denne S3-spand holder upload af kundefiler. En kunde uploader en fil en gang, så kan alle webservere svare på anmodninger om denne fil.

Skabelon backup

Gid ikke med at gemme din nye skabelon på nettet. Du kan give CloudFormation en URL for at få din skabelonfil, men den fungerer kun med AWS S3 (Simple Storage Service). Det er her AWS gemmer sine skabeloner. Det er her din uploadede skabelon gemmes. Udviklere, der bruger et kodelager som Github eller Gitorious, er ude af held.

© Copyright 2020 | mobilegn.com