Anatomie van een AWS CloudFormation-sjabloon

Met behulp van een supportticketservice als mijn voorbeeld SaaS-oplossing, heb ik laten zien hoe iedereen kan profiteren van de tools die Amazon Web Services biedt om uw idee van een businessplan naar een product te brengen dat via de cloud beschikbaar is voor uw klanten. Tot dusverre hebben we rekening gehouden met planning- en ontwerpoverwegingen, een IaaS-laag gebouwd en AWS CloudFormation-sjablonen gebruikt om een ​​zeer beschikbaar cluster te maken. We zijn nu klaar om de applicatie te polijsten.

De volgende stap is het wijzigen van de AWS CloudFormation-sjabloon om de build van mijn supportticketservice te automatiseren. Ik heb een high-availability cluster, Drupal, een RDS-database, firewall-regels, een load balancer enzovoort. Het is fantastisch om te bereiken met een web-UI en een paar muisklikken.

Maar het is niet fantastisch genoeg. Ik moet het CloudFormation-sjabloon bewerken om het dichter bij mijn behoeften te brengen, maar eerst moet ik weten wat erin zit en waar ik de nodige wijzigingen moet aanbrengen. Hieronder geef ik je een overzicht van alle onderdelen.

Mijn service polijsten betekent het terrein van de ontwikkelaar betreden

De service die wordt geboden door de AWS CloudFormation Drupal-sjabloon is niet wat ik wil. Ik ga dat sjabloon hier aanpassen om de nodige wijzigingen aan te brengen. Helaas betekent dit het oversteken naar ontwikkelaarsgebied. Ik zal niet de hele reis maken, omdat ontwikkelaarsterrein een verlaten woestenij is die onaangenaam is om te bezoeken. Ik zal genoeg dekken om de weg te verlichten.

Een combinatie van Drupal-modules

SaaS-bedrijven bouwen hun diensten op. Ze nemen geen white-label goederen en plakken er hun insigne op. Ik zal mijn supportticketservice bouwen met behulp van de Drupal Core CMS-toolkit, een aantal optionele extra's en veel ontwikkeltijd.

Er zijn echter tal van optionele modules voor Drupal die ik kan samenvoegen om de ontwikkelingstijd te verkorten.

  • De ondersteuningsticketservice is afkomstig van de ondersteuningsmodule. De ondersteuningsmodule biedt het zakelijke einde van mijn service.
  • Het mechanisme voor het genereren van inkomsten is afkomstig van een reeks Commerce- modules. Deze behandelen de e-commerce kant. Drupal Commerce is een grote verzameling, met bijna twintig modules om te installeren en nog veel meer ondersteunende modules. Deze bieden het kader voor het omgaan met klanten, belasting, regelitems, betaling, producten, enzovoort.
  • De controle over deze premium-inhoud wordt beheerd door de Content Access- module en andere dingen, zoals het Rollen- toegangscontrolemechanisme. Deze modules plakken de commerce- en supportticketonderdelen samen.

Wat zit er in een AWS CloudFormation-sjabloon

Ik kan een AWS CloudFormation-sjabloonbestand aanpassen aan mijn behoeften.

Klik om te vergroten.

Eerst moet ik begrijpen wat een sjabloon is. Hier is een kort overzicht. Zie de AWS-gids Bootstrapping Applications via AWS CloudFormation voor een meer gedetailleerde beschrijving.

De kleine automatische gremlins die CloudFormation bouwen, nemen hun instructies uit een configuratiebestand dat er ongeveer zo uitziet.

 { 
 "AWSTemplateFormatVersion": "versiedatum", 
 "Description": "Geldige JSON-strings tot 4K", 
 "Parameters": { 
 sleutels en waarden 
 }, 
 "Mappings": { 
 sleutels en waarden 
 }, 
 "Bronnen": { 
 sleutels en waarden 
 }, 
 "Uitgangen": { 
 sleutels en waarden 
 } 
 } 

Deze tekst, met zijn liberale sprenkel van accolades, aanhalingstekens en dubbele punten, is JSON (JavaScript Object Notation). JSON is populair bij ontwikkelaars die niet de wordiness van XML willen, maar niet cool genoeg zijn voor YAML.

De toetsen en waardenregel in het bovenstaande voorbeeld zien er ongeveer zo uit in een echt sjabloonbestand.

 "S3Bucket": { 
 "Type": "AWS :: S3 :: Emmer", 
 "Eigendommen" : { 
 "AccessControl": "PublicRead", 
 "WebsiteConfiguration": { 
 "IndexDocument": "index.html", 
 "ErrorDocument": "error.html" 
 } 
 } 
 } 

Al dat ingesprongen spul is een lading geneste sleutel / waarde-paren. Het is ingewikkeld en het is slechts het topje van de ijsberg. Sjabloonbestanden zijn nerd heaven.

De Launch Config

De sectie Resources van het sjabloonbestand bevat een subsectie LaunchConfig . Deze sectie begint met deze regel.

"LaunchConfig": {

De sectie LaunchConfig bestaat uit 200 slimme lijnen. Het heeft een lijst met bestanden om te installeren, downloaden en maken. Het heeft ook een volledig bash-script erin ingebed.

Ik gebruik de geclusterde Drupal-sjabloon. Je kunt het hier zien: Zeer beschikbare webserver met Multi-AZ Amazon RDS-database-exemplaar en het gebruik van S3 voor het opslaan van bestandsinhoud.

Later zal ik enkele wijzigingen aanbrengen in de sectie LaunchConfig van deze sjabloon en een cluster maken.

Het ingesloten bash-script

Het bash-script in de sectie LaunchConfig bevindt zich onder aan het bestand. Het script is ongeveer 60 regels lang en ziet er zo uit.

"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" 
 
  }} 

De taak van deze verontrustende ogende sjablooncode is om al die regels in een bash-script te plaatsen.

Een bash-script is een verzameling opdrachten die allerlei dingen met het systeem doen. Systeembeheerders schrijven al tientallen jaren scripts. Dit slimme bash-script bewerkt de Apache-webserverconfiguratie, geeft een lijst van alle nieuwe EC2-machines, zet een standaard Drupal-site op, enzovoort.

Dit script wordt gekopieerd naar elke nieuwe EC2 VM. Het komt terecht in de directory / var / lib / cloud / data / scripts / . Alle berichten die het produceert, komen terecht in /var/log/cloud-init.log .

De bestanden en mappen van de EC2-machines

Het is lastig om een ​​applicatie over meerdere servers te verspreiden. Je moet weten wat er wordt gekopieerd, wat wordt gedeeld en waar het allemaal naartoe moet.

Veel bestanden worden op de machines gedupliceerd. Alle algemene code (Drupal Core) wordt gekopieerd naar de websitemap op elke nieuwe server (deze bevindt zich in / var / www / html ).

De S3-emmer

Sommige bestanden worden gedeeld tussen machines. Een deel van het bestandssysteem is eigenlijk een AWS S3-emmer (Simple Storage Service). Dit gedeelde gebied wordt op alle drie de servers (op / var / www / html / sites / default / files ) gemount. Sommige Drupal-bestanden zitten in deze S3-bucket.

S3-emmers worden meestal gebruikt voor statische inhoud van websites, in plaats van uitvoerbare bestanden, logboeken en andere lastige bestanden. Deze S3-bucket bevat uploads van klantbestanden. Eén klant uploadt een bestand één keer, waarna alle webservers kunnen reageren op aanvragen voor dit bestand.

Sjabloon back-up

Doe geen moeite om uw nieuwe sjabloon op internet op te slaan. U kunt CloudFormation een URL geven om uw sjabloonbestand op te halen, maar het werkt alleen met AWS S3 (Simple Storage Service). Daar slaat AWS zijn sjablonen op. Dat is waar uw geüploade sjabloon wordt opgeslagen. Ontwikkelaars die een coderepository zoals Github of Gitorious gebruiken, hebben pech.

© Copyright 2020 | mobilegn.com