Henri Binsztok er Chief Innovations Officer hos Wallix og medskaber af Awless open source-projektet.
Da skyen kun handlede om virtuelle maskiner, hjalp værktøjer som Chef eller Puppet os med at forberede vores virtuelle maskiner let. Det eneste der betyder noget var at sørge for forekomster, der indeholdt al den nødvendige kode og data. Men nu hvor Amazon Web Services har balloonet til mere end 90 tjenester, bliver interaktion med AWS API den største del af arbejdet.
Hvordan skal vi administrere AWS-infrastruktur, og hvilke grænseflader skal vi bruge? De fleste begyndere starter med AWS Console, standard GUI, mens erfarne sysadmins generelt foretrækker en kommandolinjegrænseflade (CLI). Problemet er, at AWS CLI ikke er brugervenlig. Fordi det integrerer hele AWS API, udsætter det et enormt overfladeareal med hensyn til kommandoer, flag og muligheder.
Awless er født af vores behov for en hurtig, kraftfuld og brugervenlig CLI til at styre AWS. Med Awless kan du oprette og køre en AWS-infrastruktur, der starter fra bunden og altid få læsbar output (til både mennesker og programmer), udforske og forespørge om alle skyressourcer (selv offline), oprette forbindelse til forekomster og oprette, opdatere og slette skyressourcer. Ud over enkelte kommandolinjer understøtter Awless skabeloner, der muliggør højere niveauer af automatisering. Sidst, men ikke mindst, tager Awless sigte på at sikre smart standardindstillinger og bedste praksis for sikkerhed.
Da der er så mange AWS-tjenester, er det ofte vigtigt at finde og vise et hierarki af tjenester fra kommandolinjen. Vi kan gruppere tjenester efter funktionalitet - såsom beregning og database. Men at gå gennem hver af dem udtømmende er kedeligt, da der i skrivende stund ikke er færre end 15 tjenester omkring lagring og database, medregner ikke fire datamigreringstjenester og ni analysetjenester, der er direkte relateret til dataforbrug.
Vi finder det lettere at gruppere tjenester efter skyberedskab. I denne artikel vil vi detaljerede, hvordan du bruger Awless til at oprette og administrere skyressourcer til en reel brugssag, implementeringen af produktionsklare WordPress-forekomster. Vi bruger følgende AWS-ressourcer:
- VM-tjenester EC2 (Elastic Compute Cloud) og ELB (Elastic Load Balancing);
- Tjenester på højt niveau, der kører i virtuelle computere, men administreres af AWS, såsom RDS (Relational Database Service) eller ElastiCache (til køer);
- "Serverløse" tjenester, der kører i multi-tenant-virtuelle computere, såsom S3 (objektlagring) eller Lambda (udførelse af en enkelt funktion).
Wallix Kom godt i gang med Awless
Tilmeld dig AWS, og opret en første konto med Administratoradgang rettigheder. Vær opmærksom på din adgangsnøgle og hemmelige nøgle.
Installer Awless
Awless er tilgængelig på GitHub. Vi sørger for forudbyggede binære filer og Homebrew-pakker til MacOS:
> bryg vandhane wallix / awless
> bryg installation ubesværet
Du kan kontrollere, at Awless er korrekt installeret ved at køre:
> awless versionAwless er modelleret efter populære kommandolinjeværktøjer som Git. De fleste kommandoer er i form af:
> awless verb [entity] [parameter = værdi ...]Denne artikel giver et 360-graders overblik over reelle produktionsbelastninger på AWS startende fra bunden. For klarhedens skyld udelader vi al bekræftelse og nogle outputtrin, da Awless altid beder om at bekræfte kommandoer, der opretter, opdaterer eller sletter ressourcer.
Første skridt med Awless
Vi kan udstede vores første Awless-kommando ved at liste vores Virtual Private Clouds (VPC'er). Fordi dette er vores første kørsel, bliver vi nødt til at indtaste nogle nødvendige data for at konfigurere Awless:
> awless liste vpcsVelkommen til awless! Løser miljødata ...
Vælg en AWS-region:
ap-nordøst-1, ap-nordøst-2, ap-syd-1, ap-sydøst-1, ap-sydøst-2, ca-central-1, cn-nord-1, eu-central-1, eu- vest-1, eu-vest-2, sa-øst-1, os-øst-1, os-øst-2, os-gov-vest-1, os-vest-1, os-vest-2
Værdi? > os-vest-2
Synkroniserer region 'us-west-2' ...
Kan ikke løse AWS-legitimationsoplysninger (AWS_ACCESS_KEY_ID og AWS_SECRET_ACCESS_KEY) Indtast adgangsnøgler og vælg et profilnavn (gemt på /Users/john/.aws/credentials):
AWS adgangsnøgle-id? AKIAIINZQI7WIEXAMPLE
AWS hemmelig adgangsnøgle? hYWZBVOusePEPSr5PkscplskB84fjbgUEXAMPLE
Vælg et profilnavn? admin
✓ /Users/john/.aws/credentials oprettet
✓ Legitimationsoplysninger for profilen 'admin' gemt med succes
Helt færdig. God fornøjelse!
Du kan gennemse og konfigurere awless med `awless config`.
Kører nu: awless list vpcs
| ID ▲ | NAVN | STANDARD | STAT | CIDR |
|--------------|------|---------|-----------|---------------|
| vpc-1d1df679 | | sandt tilgængelig | 172.31.0.0/16 |
Opret en AWS-bruger
Vi bruger nu Awless til at oprette en ny AWS-bruger og give ham tilstrækkelige rettigheder ved hjælp af administratorprofilen. Vi opretter brugeren John og hans adgangsnøgle:
> medmindre oprette brugernavn = john
> awless oprette accesskey bruger = john aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI / K7MDENG / bPxRfiCYEXAMPLEKEY
Vil du gemme dine .aws / legitimationsoplysninger? (y / n) y
Indtastningsnavn i .aws / legitimationsoplysninger? [standard] john
Nu hvor John eksisterer, har han brug for et sæt tilladelser. Vi giver John fuld adgang til de EC2-, RDS-, Auto Scaling-, CloudFront- og S3-tjenester, som vi vil bruge i denne artikel:
> awless vedhæft politik service = ec2 adgang = fuld bruger = john
> awless vedhæft politik service = rds adgang = fuld bruger = john
> awless vedhæft politik service = s3 adgang = fuld bruger = john
> awless vedhæft politiktjeneste = automatisk skaleringsadgang = fuld bruger = john
> awless attach policy service = cloudfront access = full user = john
Nu hvor John er en fuldt funktionel bruger, skifter vi til hans profil for de næste trin:
> awless config set aws.profile johnVi bruger AWS til at oprette en meget tilgængelig, administreret WordPress-implementering, der kombinerer virtuelle computere, administrerede og serverløse tjenester. Vores hovedmål er afbildet nedenfor. Vi bliver nødt til at tage fat på tre "devops-udfordringer" for at nå det, ved hjælp af henholdsvis AWS-infrastrukturtjenester, administrerede tjenester og serverløse tjenester.
Wallix Udfordring 1: Løft og flyt en applikation til EC2
Løft og skift er den hurtigste til at migrere ældre applikationer til skyen og drage fordel af skyplatformers fleksibilitet og omkostningsfordele. I dette tilfælde starter vi med at installere en WordPress-motor og dens database i en enkelt VM. Klienter opretter forbindelse direkte til VM.
Wallix Opret en VPC
Før vi fortsætter med oprettelsen af VM, skal vi først oprette netværksressourcer:
- Et privat netværk (eller VPC)
- En internet-gateway til denne VPC
- Et undernet, der bruger internet-gatewayen
Awless vil bede om manglende parametre med autofuldførelse. Her bruger vi en blanding af begge forudsat (param = værdi) og bedte parametre:
> medmindre oprette vpc cidr = 10.0.0.0 / 16 navn = wordpress-vpc
> uden at skabe internetgateway
[OK] id = igw-1234567
> usædvanligt vedhæft internetgateway
Angiv venligst (Ctrl + C for at afslutte, fane til afslutning):
internetgateway.id? [Tab]
internetgateway.id? igw-1234567
internetgateway.vpc? @wo [Tab]
internetgateway.vpc? @ wordpress-vpc
Awless fremsætter den bedste praksis for at bruge navne snarere end ressource-id'er. Som sådan, @ ressource-navn er identifikatoren for ressourcen med navnet "ressource-navn."
Lad os oprette et offentligt undernet til at være vært for vores WordPress-forekomst og vedhæfte en rutetabel, der dirigerer internettrafikken til VPC's internet-gateway:
> uden at skabe subnet cidr = 10.0.0.0 / 24 vpc = @ wordpress-vpc name = wordpress-public-subnet
> awless opdatering subnet id = @ wordpress-public-subnet public = true
> medmindre du opretter rutetabel vpc = @ wordpress-vpc
> awless attach routetable subnet = @ wordpress-public-subnet
Angiv venligst (Ctrl + C for at afslutte, fane til afslutning):
routetable.id?(tab]
* vælg id'et for rutetabellen, du oprettede ovenfor *
> opsæt rute cidr = 0.0.0.0 / 0
Angiv venligst (Ctrl + C for at afslutte, fane til afslutning):
rute. vej? * ID'et for internetgatewayen, du har knyttet til VPC ovenfor *
rute.tabel? * ID'et for rutetabellen, du oprettede ovenfor *
Bemærk, at hver handling i Awless er omtrent så enkel som den kan blive. Selvom vi følger en omfattende trin-for-trin tilgang, giver Awless os mulighed for at komme igennem den kedelige proces med at oprette en infrastruktur meget hurtigere end med den grafiske konsol eller AWS CLI.
Opret et SSH-tastatur og en sikkerhedsgruppe
Cloud-netværket er nu klar. Før vi opretter forekomsten, har vi brug for et SSH-nøglepar for at oprette forbindelse til forekomsten senere. I en enkelt kommando genererer Awless et SSH-nøglepar lokalt og registrerer det på AWS:
> medmindre du oprette tastaturnavn = johnkeyEn bedste praksis er at give minimal adgang til enhver ressource, så vi accepterer kun HTTP-forbindelser fra hele Internettet og SSH fra vores udgående IP-adresse. For at gøre det opretter og konfigurerer vi en sikkerhedsgruppe:
> medmindre du opretter sikkerhedsgruppe vpc = @ wordpress-vpc beskrivelse = \ ”HTTP offentlig + SSH-adgang \” navn = wordpress-secgroup
> MY_IP = $ (awless whoami — kun-ip)
> awless opdatering sikkerhedsgruppe id = @ wordpress-secgroup indgående = godkend cidr = $ MY_IP / 32 portrange = 22
> awless opdatering sikkerhedsgruppe id = @ wordpress-secgroup indgående = godkend cidr = 0.0.0.0 / 0 portrange = 80
Giv applikationen AWS-brugerdata
Vi leverer nu vores WordPress-instans gennem AWS-brugerdata. Her bruger vi det script, der er tilgængeligt på GitHub:
> awless oprette instans subnet = @ wordpress-public-subnet keypair = johnkey name = wordpress-instans userdata = // raw.githubusercontent.com/zn3zman/AWS-WordPress-Creation/16a52aef4f618d558d61197df4e4eca4c015277f/WP-Setup.shgr secgroupDu kan bruge awless show for at få oplysninger om enhver ressource, såsom den offentlige IP-adresse på vores WordPress-forekomst:
> awless vis wordpress-instansDu kan oprette forbindelse til IP-adressen fra kommandooutputtet for at få adgang til din WordPress-tjeneste (selvom du muligvis bliver nødt til at vente et par minutter på, at forekomsten tilvejebringes korrekt).
WordPress Foundation Awless opretter som standard en type t2.micro (1 vCPU, 1 GB RAM) ved hjælp af Amazon Linux. Du kan opdatere standardværdier ved hjælp af awless konfigurationssæt:
> awless config set instance.type m4.large
> UBUNTU_AMI = $ (medmindre søge billeder kanoniske: ubuntu - kun id - stille)
> awless config set instance.billede $ UBUNTU_AMI
Til dette punkt har vi bygget flere ressourcer. Ved brug af awless liste, kan vi liste brugere, forekomster, undernet og alle andre typer ressourcer (forudsat at din AWS-profil naturligvis har tilstrækkelige rettigheder). For eksempel kan vi liste forekomster:
> awless liste forekomster
| ID ▲ | ZONE | NAVN | OPTID |
|-------------------|----------|--------------------|---------|
| i-00268db26b0d0393c | us-west-1c | wordpress-instans | 57 minutter |
[...]
Awless giver en kraftfuld funktion, der muliggør nem forbindelse til forekomster med SSH. Bag kulisserne får Awless automatisk IP-adressen til forekomsten, gætter brugernavnet og opretter forbindelse til det tastatur, vi oprettede tidligere:
> awless ssh wordpress-instansHvis du vil slette WordPress-forekomsten, kan du køre undtagen slette forekomst id = @ wordpress-forekomst. Du kan gøre det nu, da vi opretter en mere avanceret implementering i den næste udfordring.
Sådan bruges Awless skabeloner
Alle trin i denne udfordring kan beskrives som en sekvens af Awless-kommandoer, hvor resultaterne af tidligere kommandoer (for eksempel ID-en til internet-gatewayen) bruges som input til efterfølgende kommandoer. Da Awless leverer et indbygget skabelonsystem, kan du indkapsle hele udfordring 1 i en skabelon og køre den med:
> awless run //raw.githubusercontent.com/wallix/awless-templates/bcd0dd41b1524eeac1e53d12b2998bc56689c517/simple_wordpress_infra.awsAwless tilbyder en stærk funktion, der giver dig mulighed for at tilbagekalde de fleste ændringer, der er anvendt til en AWS-infrastruktur. For eksempel kan du slette hele infrastrukturen oprettet af en skabelon i en enkelt kommando: medmindre du vender tilbage-id. At finde en given tilbageførsel-id, awless log viser alle de kommandoer, der tidligere er anvendt på skyinfrastrukturen, med både deres output og deres ID:
> awless log # find id'et, der skal tilbageføres > awless revert 01BM6D1YRZ5SSN5Z09VEEGN0HVUdfordring 2: Brug AWS-administrerede tjenester
Vores tidligere implementering er funktionel, men ret håndværksmæssig. Vores blog er drevet af en enkelt forekomst i en enkelt tilgængelighedszone (AZ). Vi vil nu oprette en meget tilgængelig blog med en belastningsafbalancering, to forekomster i forskellige AZ'er og en replikeret database, der deles af vores forekomster. I stedet for at køre vores egen database i en instans bruger vi AWS RDS, Amazons administrerede service til SQL-databaser. Brug af en administreret tjeneste giver mange fordele, herunder klyngedannelse, administreret sikkerhed og sikkerhedskopier.
Wallix For at have meget tilgængelige ressourcer er vi nødt til at distribuere dem i undernet i forskellige tilgængelighedszoner (AZ'er) og afbalancere belastningen gennem elastisk belastningsbalancering.
Wallix Til denne udfordring opretter vi følgende:
- Én belastningsafbalancering, der fordeler belastningen mellem forekomsterne
- To offentlige undernet, der skal forbindes med den internetvendte load balancer
- To private undernet i forskellige AZ'er (fx us-øst-1a, us-øst-1e) for at være vært for forekomsterne
- En gruppe til automatisk skalering til styring af skaleringen af WordPress-forekomster
- Én NAT-gateway i et offentligt undernet for at muliggøre udgående opkald til tilvejebringelse af instanser
- Én offentlig fast IP (elastisk IP) til NAT-gatewayen
- Én RDS til MariaDB-forekomst replikeres automatisk i de private undernet
Vi bygger denne infrastruktur ved at køre Awless-skabeloner. Den første skabelon opretter undernet og routing. Det {hul} notation gør det muligt at udfylde parametre dynamisk under kørsel af skabelonen. Det $ reference notation muliggør referencer til oprettede ressourcer.
