Programmering

Awless tutorial: Prøv en smartere CLI for AWS

Henri Binsztok er sjef for innovasjon i Wallix og medskaper av Awless open source-prosjektet.

Da skyen bare handlet om virtuelle maskiner, hjalp verktøy som Chef eller Puppet oss med å forberede våre virtuelle maskiner. Det eneste som gjaldt var å sørge for forekomster som inneholdt all nødvendig kode og data. Men nå som Amazon Web Services har ballooned til mer enn 90 tjenester, blir samhandling med AWS API den viktigste delen av arbeidet.

Hvordan skal vi administrere AWS-infrastruktur, og hvilke grensesnitt skal vi bruke? De fleste nybegynnere starter med AWS Console, standard GUI, mens erfarne sysadmins generelt foretrekker et kommandolinjegrensesnitt (CLI). Problemet er at AWS CLI ikke er brukervennlig. Fordi den integrerer hele AWS API, eksponerer den et enormt overflateareal når det gjelder kommandoer, flagg og alternativer.

Awless er født av vårt behov for en rask, kraftig og brukervennlig CLI for å administrere AWS. Med Awless kan du opprette og kjøre en AWS-infrastruktur, helt fra bunnen av, og alltid få lesbare utdata (for både mennesker og programmer), utforske og spørre alle skyressurser (selv offline), koble til forekomster og opprette, oppdatere og slett skyressurser. Utover enkeltkommandolinjer støtter Awless maler som muliggjør høyere nivåer av automatisering. Sist, men ikke minst, har Awless som mål å sikre smarte standarder og beste praksis for sikkerhet.

Fordi det er så mange AWS-tjenester, er det ofte viktig å finne og vise et hierarki av tjenester fra kommandolinjen. Vi kan gruppere tjenester etter funksjonalitet - for eksempel beregning og database. Men å gå gjennom hver av dem uttømmende er kjedelig da det i skrivende stund ikke er færre enn 15 tjenester rundt lagring og database, uten å telle fire datamigreringstjenester og ni analysetjenester som er direkte relatert til databruk.

Vi finner det lettere å gruppere tjenester etter skyberedskap. I denne artikkelen vil vi detaljere hvordan du bruker Awless til å opprette og administrere skyressurser for en reell brukstilfelle, distribusjon av produksjonsklare WordPress-forekomster. Vi bruker følgende AWS-ressurser:

  1. VM-tjenester EC2 (Elastic Compute Cloud) og ELB (Elastic Load Balancing);
  2. Tjenester på høyt nivå som kjører i virtuelle maskiner, men administreres av AWS, for eksempel RDS (Relational Database Service) eller ElastiCache (for køer);
  3. “Serverløse” tjenester som kjører i flere virtuelle virtuelle maskiner, for eksempel S3 (objektlagring) eller Lambda (kjøring av en enkelt funksjon).
Wallix

Kom i gang med Awless

Registrer deg for AWS og opprett en første konto med AdministratorTilgang rettigheter. Legg merke til tilgangsnøkkelen og den hemmelige nøkkelen.

Installer Awless

Awless er tilgjengelig på GitHub. Vi skaffer ferdigbygde binærfiler og Homebrew-pakker for MacOS:

> bryg kran wallix / awless 

> bryggeinstallering uten problemer

Du kan kontrollere at Awless er riktig installert ved å kjøre:

> awless versjon

Awless er modellert etter populære kommandolinjeverktøy som Git. De fleste kommandoer er i form av:

> awless verb [entity] [parameter = value ...]

Denne artikkelen vil gi en 360-graders oversikt over reelle produksjonsbelastninger på AWS, helt fra bunnen av. For klarhetens skyld utelater vi alle bekreftelses- og noen utgangstrinn, da Awless alltid ber om å bekrefte kommandoer som oppretter, oppdaterer eller sletter ressurser.

Første trinn med Awless

Vi kan utstede vår første Awless-kommando ved å liste opp våre Virtual Private Clouds (VPCs). Fordi dette er vårt første løp, må vi legge inn noen nødvendige data for å konfigurere Awless:

> awless liste vpcs

Velkommen til awless! Løse miljødata ...

Velg en AWS-region:

ap-nordøst-1, ap-nordøst-2, ap-sør-1, ap-sørøst-1, ap-sørøst-2, ca-sentral-1, cn-nord-1, eu-sentral-1, eu- vest-1, eu-vest-2, sa-øst-1, us-øst-1, us-øst-2, us-gov-vest-1, us-vest-1, us-vest-2

Verdi? > oss-vest-2

Synkroniserer region ‘us-west-2’ ...

Kan ikke løse AWS-legitimasjon (AWS_ACCESS_KEY_ID og AWS_SECRET_ACCESS_KEY) Angi tilgangsnøkler og velg et profilnavn (lagret på /Users/john/.aws/credentials):

AWS ID for tilgangsnøkkel? AKIAIINZQI7WIEXAMPLE

AWS hemmelig tilgangsnøkkel? hYWZBVOusePEPSr5PkscplskB84fjbgUEXAMPLE

Velg et profilnavn? admin

✓ /Users/john/.aws/credentials opprettet

✓ Legitimasjonsopplysninger for profilen ‘admin’ er lagret

Ferdig. Nyt!

Du kan se gjennom og konfigurere awless med `awless config`.

Kjører nå: awless list vpcs

| ID ▲ | NAVN | STANDARD | STAT | CIDR |

|--------------|------|---------|-----------|---------------|

| vpc-1d1df679 | | sant | tilgjengelig | 172.31.0.0/16 |

Opprett en AWS-bruker

Vi vil nå bruke Awless til å opprette en ny AWS-bruker og gi ham tilstrekkelige rettigheter ved hjelp av administratorprofilen. Vi oppretter brukeren John og hans tilgangsnøkkel:

> uten å opprette brukernavn = john 

> awless create accesskey user = john aws_access_key_id = AKIAIOSFODNN7EXAMPLE

aws_secret_access_key = wJalrXUtnFEMI / K7MDENG / bPxRfiCYEXAMPLEKEY

Vil du lagre i .aw / legitimasjon? (y / n) y

Oppføringsnavn i .aw / legitimasjon? [standard] john

Nå som John eksisterer, trenger han et sett med tillatelser. Vi gir John full tilgang til EC2, RDS, Auto Scaling, CloudFront og S3-tjenestene som vi vil bruke i denne artikkelen:

> awless attach policy service = ec2 access = full bruker = john 

> awless attach policy service = rds access = full bruker = john

> awless attach policy service = s3 tilgang = full bruker = john

> awless attach policy service = autoscaling access = full user = john

> awless attach policy service = cloudfront access = full user = john

Nå som John er en fullt funksjonell bruker, bytter vi til profilen hans for de neste trinnene:

> awless config set aws.profile john

Vi vil bruke AWS til å sette opp en svært tilgjengelig, administrert WordPress-distribusjon, som kombinerer virtuelle maskiner, administrerte og serverfrie tjenester. Vårt hovedmål er avbildet nedenfor. Vi må ta tak i tre “devops-utfordringer” for å nå det, ved å bruke henholdsvis AWS-infrastrukturtjenester, administrerte tjenester og serverløse tjenester.

Wallix

Utfordring 1: Løft og flytt en applikasjon til EC2

Lift and shift er den raskeste til å migrere eldre applikasjoner til skyen og dra nytte av skyplattformers fleksibilitet og kostnadsfordeler. I dette tilfellet vil vi starte med å distribuere en WordPress-motor og dens database i en enkelt VM. Klienter vil koble seg direkte til VM.

Wallix

Opprett en VPC

Før vi fortsetter med opprettelsen av VM, må vi først opprette nettverksressurser:

  • Et privat nettverk (eller VPC)
  • En Internett-gateway for denne VPC
  • Et delnett som bruker Internett-gatewayen

Awless vil be om manglende parametere med autofullføring. Her bruker vi en blanding av begge gitt (param = verdi) og spurte parametere:

> uten å lage vpc cidr = 10.0.0.0 / 16 navn = wordpress-vpc 

> uten å lage internetgateway

[OK] id = igw-1234567

> awless feste internetgateway

Vennligst spesifiser (Ctrl + C for å avslutte, Tab for fullføring):

internetgateway.id? [Tab]

internetgateway.id? igw-1234567

internetgateway.vpc? @wo [Tab]

internetgateway.vpc? @ wordpress-vpc

Awless legger frem den beste fremgangsmåten for å bruke navn i stedet for ressurs-ID. Som sådan, @ ressursnavn er identifikatoren for ressursen "ressursnavn".

La oss lage et offentlig undernett for å være vert for WordPress-forekomsten vår, og legge ved en rutetabell som dirigerer internettrafikken til VPCs Internett-gateway:

> uten å lage subnett cidr = 10.0.0.0 / 24 vpc = @ wordpress-vpc name = wordpress-public-subnet 

> awless update subnet id = @ wordpress-public-subnet public = true

> uten å lage rutetabell vpc = @ wordpress-vpc

> awless attach routetable subnet = @ wordpress-public-subnet

Vennligst spesifiser (Ctrl + C for å avslutte, Tab for fullføring):

rutetable.id?(tab]

* velg ID for rutetabellen du opprettet ovenfor *

> uten å lage rute cidr = 0.0.0.0 / 0

Vennligst spesifiser (Ctrl + C for å avslutte, Tab for fullføring):

rute. gateway? * IDen til internettportalen du koblet til VPC ovenfor *

rute.tabell? * IDen til rutetabellen du opprettet ovenfor *

Merk at hver handling i Awless er omtrent så enkel som den kan bli. Selv om vi følger en omfattende trinnvis tilnærming, lar Awless oss komme gjennom den kjedelige prosessen med å sette opp en infrastruktur mye raskere enn med den grafiske konsollen eller AWS CLI.

Opprett et SSH-tastatur og en sikkerhetsgruppe

Skynettverket er nå klart. Før vi oppretter forekomsten, trenger vi et SSH-nøkkelpar for å koble til forekomsten senere. I en enkelt kommando genererer Awless et SSH-nøkkelpar lokalt og registrerer det på AWS:

> uten å lage tastaturnavn = johnkey

En god praksis er å gi minimal tilgang til alle ressurser, så vi godtar bare HTTP-tilkoblinger fra hele Internett og SSH fra vår utgående IP-adresse. For å gjøre det oppretter og konfigurerer vi en sikkerhetsgruppe:

> uten å opprette sikkerhetsgruppe vpc = @ wordpress-vpc beskrivelse = \ ”HTTP offentlig + SSH-tilgang \” navn = wordpress-secgroup 

> MY_IP = $ (awless whoami — bare-ip)

> awless update securitygroup id = @ wordpress-secgroup inbound = authorize cidr = $ MY_IP / 32 portrange = 22

> awless update securitygroup id = @ wordpress-secgroup inbound = authorize cidr = 0.0.0.0 / 0 portrange = 80

Sørg for applikasjonen med AWS-brukerdata

Vi vil nå sørge for WordPress-forekomsten vår gjennom AWS-brukerdata. Her vil vi bruke skriptet som er tilgjengelig på GitHub:

> awless lage forekomst subnet = @ wordpress-public-subnet keypair = johnkey name = wordpress-instance userdata = // raw.githubusercontent.com/zn3zman/AWS-WordPress-Creation/16a52aef4f618d558d61197df4e4eca4c015277f/WP-Setup.sh secgroup

Du kan bruke awless show for å få informasjon om hvilken som helst ressurs, for eksempel den offentlige IP-adressen til WordPress-forekomsten vår:

> awless vis wordpress-forekomst

Du kan koble til IP-adressen fra kommandoutgangen for å få tilgang til WordPress-tjenesten din (selv om du kanskje må vente noen minutter på at forekomsten skal klargjøres riktig).

WordPress Foundation

Awless vil som standard opprette en type t2.micro (1 vCPU, 1 GB RAM) ved hjelp av Amazon Linux. Du kan oppdatere standardverdiene ved å bruke awless config sett:

> awless config set instance.type m4.large 

> UBUNTU_AMI = $ (med mindre søkebilder kanoniske: ubuntu — bare-stille)

> awless config set instance.image $ UBUNTU_AMI

Til dette punktet har vi bygget flere ressurser. Ved hjelp av awless liste, kan vi liste opp brukere, forekomster, undernett og alle andre typer ressurser (forutsatt at AWS-profilen din selvfølgelig har tilstrekkelige rettigheter). For eksempel kan vi liste forekomster:

> awless listeforekomster 

| ID ▲ | SONE | NAVN | OPTID |

|-------------------|----------|--------------------|---------|

| i-00268db26b0d0393c | us-west-1c | wordpress-forekomst | 57 minutter |

[...]

Awless gir en kraftig funksjon som gjør det enkelt å koble til forekomster med SSH. Bak kulissene vil Awless automatisk få IP-adressen til forekomsten, gjette brukernavnet og koble til tastaturet vi opprettet tidligere:

> awless ssh wordpress-forekomst

Hvis du vil slette WordPress-forekomsten, kan du kjøre awless slett forekomst id = @ wordpress-forekomst. Du kan gjøre det nå, ettersom vi vil skape en mer avansert distribusjon i neste utfordring.

Hvordan bruke Awless maler

Alle trinnene i denne utfordringen kan beskrives som en sekvens av Awless-kommandoer, der resultatene av tidligere kommandoer (for eksempel IDen til Internett-gatewayen) brukes som innganger til påfølgende kommandoer. Fordi Awless tilbyr et innebygd malsystem, kan du kapsle hele utfordring 1 i en mal og kjøre den med:

> awless run //raw.githubusercontent.com/wallix/awless-templates/bcd0dd41b1524eeac1e53d12b2998bc56689c517/simple_wordpress_infra.aws

Awless tilbyr en kraftig funksjon som lar deg tilbakestille de fleste endringene som er brukt i en AWS-infrastruktur. For eksempel kan du slette hele infrastrukturen opprettet av en mal i en enkelt kommando: awless revert revert-id. For å finne en gitt tilbakestill-id, awless logg viser alle kommandoene som tidligere ble brukt på skyinfrastrukturen, med både utdata og ID:

> awless logg # finn IDen du vil tilbakestille > awless revert 01BM6D1YRZ5SSN5Z09VEEGN0HV

Utfordring 2: Bruk AWS-administrerte tjenester

Vår forrige distribusjon er funksjonell, men ganske håndverkerlig. Bloggen vår drives av en enkelt forekomst i en enkelt tilgjengelighetssone (AZ). Vi ønsker nå å bygge en svært tilgjengelig blogg, med en lastbalanser, to forekomster i forskjellige AZ-er, og en replikert database som deles av våre forekomster. I stedet for å kjøre vår egen database i en forekomst, vil vi bruke AWS RDS, Amazons administrerte tjeneste for SQL-databaser. Å bruke en administrert tjeneste gir mange fordeler, inkludert klynging, administrert sikkerhet og sikkerhetskopier.

Wallix

For å ha svært tilgjengelige ressurser, må vi distribuere dem i delnett i forskjellige tilgjengelighetssoner (AZer) og balansere belastningen gjennom elastisk lastbalansering.

Wallix

For denne utfordringen vil vi lage følgende:

  • Én lastbalanser for å fordele belastningen mellom forekomster
  • To offentlige undernett for å knytte seg til den internettvendte lastbalanseren
  • To private undernett i forskjellige AZ-er (f.eks. Us-øst-1a, us-øst-1e) for å være vert for forekomster
  • Én automatisk skaleringsgruppe for å administrere skaleringen av WordPress-forekomster
  • Én NAT-gateway i ett offentlig undernett for å aktivere utgående samtaler for forsyning av forekomster
  • Én offentlig fast IP (elastisk IP) for NAT-gatewayen
  • Én RDS for MariaDB-forekomst replikeres automatisk i de private undernettene

Vi bygger denne infrastrukturen ved å kjøre Awless maler. Den første malen oppretter undernett og ruting. De {hull} notasjon lar parametere fylles ut dynamisk under kjøring av malen. De $ referanse notasjon muliggjør referanser av opprettede ressurser.

$config[zx-auto] not found$config[zx-overlay] not found