LEO ZHADANOVSKY: Hei, alle sammen. Jeg er Leo Zhadanovsky. Jeg er en løsningsarkitekt på Amazon Web Services. Og jeg kommer til å snakke med deg i dag om hva Amazon Web Services er, sin historie, en kort oversikt av de tjenestene vi tilbyr. Og også jeg skal gjøre en live demo av hvordan å lansere en LAMP stack i AWS både på en enkelt forekomst og gjennom å bruke noen av våre andre [? administrerte?] tjenester, slik som vår relasjonsdatabase service, og vår last balancer, og våre tilfeller. Så først av alt, la oss snakke om AWS historie. Så hvordan har Amazon.com komme inn dette cloud computing bedrift? Vel, er Amazon virkelig gode på gir et stort utvalg av produkter og frakt dem til kunder effektivt. Og bak den evnen ligger mange års erfaring med driftsdatasentre, med logistikk, med alle slags ting. Og så vi oppdaget over 10 år at vi ønsket å gjøre våre kunder å gjøre mange forskjellige ting, ikke sant? Så endte vi tilby noen interne tjenester opp til tredjeparts selgere. Som vi publiserte enkle webtjenester slik som vår katalog søk. Og det ble virkelig tilsynelatende veldig fort at utviklerne var sulten for flere av våre tjenester. Og så dette førte oss til å utvikle AWS. Så vi spurte hva om vi kunne pakke alt vi gjør og tilbyr det til andre over nettet? Så AWS misjon er å muliggjøre bedrifter og utviklere å bruke webtjenester til å bygge skalerbare avanserte applikasjoner. Og web-tjenester er hva folk nå kaller Cloud. Så i 2006 ble AWS født. Og la oss snakke om hva AWS faktisk er. Så vi gir forskjellig tjenester på ulike nivåer. Så vi har en slags av våre kjernetjenester, vår beregne lagring og database. Og så har vi også et nettverk lag, og vi har fått en global infrastruktur, så vi har fikk regioner rundt om i verden og tilgjengelighet soner verden over. Og så har vi høyere nivå tjenester, som applikasjonstjenester som du bruker til å bygge horisontalt skalerbare applikasjoner. Og så har vi distribusjon og administrative tjenester. Så dette er tjenester som du bruke til å distribuere koden din i AWS og å administrere din AWS-konto som du skalerer. Så la oss snakke om vår global infrastruktur først. Vi har 11 regioner rundt om i verden. Så vi bare lagt til en ny region for noen uker siden i Frankfurt, men hver region er som en egen sky. Så disse tjenestene er jeg skal snakke om, de foreligge i de forskjellige regioner. Så i USA, er det en region i Nord-Virginia. Det er en region i Nord California og i Oregon. Regionen i Oregon er også karbonnøytralt. Vi har også en region Oregon kalt GovCloud. Så hvis du har en arbeidsbelastning som trenger å være ITAR-kompatibel, så det er Internasjonal trafikk og Arms Reduction Traktaten, bør du bruke GovCloud. Så det viktigste om dette er at du velge og vrake hvor dataene går og hvor dine apps gå. Så vi ikke flytte data over regioner, eller på tvers av tilgjengelighet soner hvis det er en tjeneste der du kan velge tilgjengeligheten sonen. Du kan velge og vrake hvor det går. Du kan flytte den. Vi gir deg verktøy for å flytte din data, men vi vil ikke flytte den for deg. Og så innen hver region er det minst to soner, tilgjengelighet og vi skal snakke om hva de som finnes i et sekund. Og det er også 52 kant steder rundt om i verden. Så edge steder er i utgangspunktet for vår CloudFront, [? sky?] distribusjon nettverk, og vår Route 53 DNS-tjenesten. Og så det er mange av dem fordi de er nærmere brukerne, fordi de er latency-baserte tjenester. Så ventetid saker for dem. Så dette er hva en typisk regionen ser ut. Og deretter [? innenfor?] hver region er det, som jeg sa, i det minste to tilgjengelighet soner. En tilgjengelighet sonen er minst en datasenteret, noen ganger kan det være mer innenfor det samme geografiske området. Og vår tilgjengelighet soner er utformet å være på forskjellige flod, feil slettene for å ha tydelig makt verktøy og ulike tier 1 ISPer. Så du bør designe din søknad [? tankene?] der noe kan skje i ett tilgjengelighet sone, men så du bør spre ut søknad i flere tilgjengelighet soner fordi de er bygget med disse oppsigelser i tankene. Og så vi drive mye virksomheter som du kjenner igjen. Så fra Airbnb, til Netflix, til Dropbox, til Yelp, Vi har alle typer startups og bedrifter som kjører arbeidsbelastning på oss. I offentlig sektor har vi alle typer offentlige etater som kjører på oss, edtech startups, universiteter. Obama-kampanjen kjørte i utgangspunktet alle av sine ting på Amazon Web Services. Og bare for å gi deg et perspektiv på vår skalering, på en gjennomsnittlig dag vi hadde nok ny server kapasitet til å støtte Amazon.com globale infrastruktur når det var en $ 7000000000 virksomhet tilbake i 2004. Så det er hvor mye vi hadde på en gjennomsnittlig dag. Så det generelle konseptet er hvis du tenke på hvordan får du makt. Så du får makt, er det på etterspørsel, ikke sant? Så du vet når du får det, vet du at du kan få det. Det er uniform, slik at du vet hva spenning du får. Det er pay as you go, slik at du betaler for nøyaktig hvor mye du bruker. Og det er tilgjengelig. Så du plugge inn, du vet du kommer til å få makt. Så vi har tatt det og utvidet det til databehandling. Så dette løser en rekke problemer. Vi vanligvis ser mye IT-organisasjoner. De har denne kapasitetsproblem. Så de har visse mengder av IT-behov, og deretter de må over-bestemmelsen sin kapasitet. Så enten de er veien over-forsyning, eller de ikke har nok kapasitet, og de har utilfreds kunder. Så for eksempel, disse er ulike mønstre av trafikk. Så om du har ting som slår av og på, eller vokser fort, eller har variable topper eller forutsigbare topper, for alle disse, du enten kommer til å over-bestemmelsen typisk, eller du kommer til under-bestemmelsen. Så du har enten avfall, eller du har misfornøyde kunder. Så hva AWS lar deg gjøre er deg kan skalere opp og ned dynamisk basert på hva din faktiske bruksmønster er. Så du kan betale bare for det du bruker. Og du kan starte tilfeller, så forekomst er vårt ord for virtuell server. Du kan starte en eksempel, kan du starte tusenvis av tilfeller i løpet av minutter eller sekunder, like mye som du trenger. Og du kan ringe den opp og ned etter behov. Så la meg snakke med deg om en eksempel det er slags nær hjemmet. Så dette er en typisk trafikk Kart for November for Amazon.com. Og de to siste topper her, er det noen som vet hva de er? Så they're-- PUBLIKUM: Cyber ​​mandag? LEO ZHADANOVSKY: Cyber ​​mandag og Black Friday, ikke sant? Så tradisjonelt, hva Amazon.com hadde å gjøre var måtte de bestemmelse kapasitet å dekke de to toppene. Så som et resultat av 76% av tiden, de hadde for mye kapasitet. Og bare 24% av tiden ble de fullt ut utnytte det. Og så i 2010 Amazon.com slått av sin siste fysiske webserver og flyttet den til AWS. Så dette er hva trafikken Mønsteret ser ut nå. Kapasiteten er like over hva som faktisk trengs. Så hvorfor ser vi kunder vedta cloud computing i AWS så raskt? Vel, agility. Så det er den primære Grunnen til at vi ser. Hvorfor er agility viktig? Vel, det gjør at kundene til gjøre ting som i den gamle verden tok uker eller måneder å gjøre dem i minutter eller sekunder. Så du kan gjøre ting som å spinne opp en helt ny Dev eller testmiljø, spinne opp en helt ny DR miljø, spinne opp 50 tilfeller, eller 1000 instanser for peak trafikk, fjerne disse 1000 tilfeller satt opp en HPC klynge, eller en GS klynge, og du kan gjøre det alt i minutter på AWS. Så hva dette fører til, er en kultur for innovasjon. Så du kan eksperimentere ofte. Du kan betale bare for det du bruker og du kan mislykkes uten risiko. Så hvis du prøver noe ut, har du betalt for et par timer med bruk. Det er ikke en stor avtale. Du har ikke satt en storkapitalen investering opp foran for det. Så hva er kunder faktisk bruker AWS for? Vel, så University of Notre Dame, de flyttet deres hjemmeside over til AWS. De har et gjennomsnitt på ca 38.000 besøkende per dag til nettstedet deres, men det kan svelle til 150000 løpet sportsarrangementer og fotballkamper. Så de flyttet sitt nettsted over til oss. Og nå deres hjemmeside kan støtte en 500% økning i trafikken, hele mens de har lagret 40% over deres eksisterende på premisset oppsett for deres hjemmeside. NASA JPL, de bruker AWS til live stream den Curiosity Mars roveren landing. Og så fant de ut bare seks dager i forveien at de trengte for å finne en annen leverandør fra sine vanlige leverandør for deres live stream. Dette var også den samme tid som OL. Slik at de ikke kunne kjøpe CDM kapasitet hvor som helst på den tiden. Og så de i utgangspunktet satt opp sitt eget innhold levering nettverk på vår EC2 tjeneste i seks dager. Og de var i stand til å ha det skalere opp til deres behov. De var, tror jeg, å se for oss ca en million seere. Så det var en veldig interessant teknisk fôr de brukte, Adobe Flash Media-servere og [? internett?] cacher. Og de var i stand til å distribuere hele klynger av disse programma som nødvendig. Og da de snurret dem ned når de ikke bruke dem lenger. Obama-kampanjen i 2012 brukt AWS for over 200 søknader at de vert på plattformen. De hadde alt fra kalle verktøy, til betaling prosessorer, til mobile applikasjoner, til frivillig organisasjon nettsteder, til store data analyseverktøy. Og alt måtte arbeide på valgdagen. Så for å flytte valgdagen ville krever en grunnlovsendring, så det var ikke til å skje. Så alle sine systemer skulle å måtte jobbe på dag én. Og det gjorde de. Så la oss snakke om de faktiske tjenester. Så først nettverkstjenestene. Så Amazon VPC er Virtual Private Cloud. Det er i utgangspunktet en programvare definerte nettverk som lever på toppen av din EC2 instanser, og dine RDS, som vi vil snakke om, og ElastiCache. Og så kan du definere en privat adresserom for forekomstene. Du kan bryte den opp i offentlige subnett, private subnett. Du kan gjøre VPN-tilkoblinger til din på premisset datasenter. Deretter kan du også utvide på premisset adresseområdet til VPC. Du har makt til å manipulere ruten bordet slik at du kan tilpasse ting. Du har nettverkstilgang kontrollister i VPC. [? Så det?] Gir stor fleksibilitet over hva du har å kjøre i AWS. Så er det AWS Directconnect. Så Directconnect er et privat tilkobling til våre regioner. Så du kan få en eller en 10 gig kobling eller flere ett eller 10 gig lenker opp til en region. Så hvis du laster opp en masse data eller laste ned en masse data og trenger privat tilkobling, det er et alternativ der. Det er også Route 53. Så Route 53 er vår DNS-tjeneste. Det gjør alle slags interessante ting. Så det støtter helsekontroller. Så du kan si, kjøre to eksemplarer av nettstedet ditt på samme tid. Og hvis en av dem svikter, du omdirigere trafikken til den andre kopien. Eller du kan gjøre geografibasert arkiv slik at du kan rute trafikk for ett land til en klynge fra en annen land til et annet klynge. Du kan gjøre A / B-testing, slik at du kan ha 80% av trafikken til ett eksemplar av nettstedet ditt og 20% til den nye kopien av nettstedet ditt og se hvilken som utfører bedre. Så du kan gjøre alle typer interessante ting der. Du kan gjøre latency baserte poster. Så du kan ha kopier av nettside over hele verden og har brukeren sendt til hvilken ens nærmest dem basert på latency. Det har også dyp integrasjon med AWS tjenester, så slik som våre belastningsfordelt, og S3, og CloudFront, så det er veldig lett å påpeke ting til CloudFront fordelinger for din LBS eller S3 bøtter. Så er det EC2. Så EC2 er vår virtuelle servertjeneste. Du kan kjøre på Windows. Du kan kjøre Linux på den. Du har full kontroll av operativsystemet. Det finnes ulike varianter av Windows og Linux, så Red Hat, Debian, Ubuntu. Vi har vår egen distribusjon kalt Amazon Linux. Du kan velge hvilken du vil. Det finnes ulike typer tilfeller. Så det er over 27 forekomst typer på dette punktet. Så det er forskjellig forekomst familier basert på ulike arbeidsoppgaver. Så det er generell purpose tilfeller, som er bare, hvis du ikke vet hva du trenger, kan du begynne med de. Det har compute optimalisert, som er stor for ting som webservere, ikke sant? Det har hukommelse optimalisert instanser, som er stor for ting som dato relasjonsdatabaser. Det er lagrings-optimalisert tilfeller så disse har store SSD på dem. Så de er gode for ting som Mongo eller NoSQL, ikke sant? Og det er grafikk optimalisert tilfeller, som er stor for GPU beregne og klase tilfeller. Og til slutt er det kostnads optimalisert tilfeller. Så hvis du bare prøver å eksperimentere, du kan få en haug med lav pris forekomst typer som er stor for at brukstilfellet. Så er det Auto Skalering. Så Auto Skalering er en API for EC2. Og det tillater deg å horisontalt skala opp og ned nivåer av EC2 instanser. Så la oss si du har en haug med webservere. Og, som i Notre Dame tilfellet deg normalt må du ha to av dem, men du må kanskje skala for 10. Vel, du kan bruke Auto Skalering til automatisk utløse skalere opp eller ned hendelser basert på en beregning. Så [? CPU?] Bruk, latency. Du kan gjøre egendefinerte beregninger, så det er ganske åpent endte det. Du kan også skalere basert på en tidsplan. Så hvis du vet at du kommer til å ha mye trafikk på mandag kl 06:00, du kan skalere opp på mandag kl 06:00 og skalere ned på mandag kl 05:00. Du kan også gjøre det basert på bare kommandolinjen kommandoer. Så er det balansering elastisk belastning. Balansering så elastisk belastning er et klart lastbalansering. Så du klikke på en knapp, det Bestemmelsene en lastbalansering for deg. Lastbalansering bor i flere tilgjengelighet soner. Det gjør SSL lossing for portene 25, 80, 443, og noe over 1024 for TCP trafikk. Det gjør tilkobling drenering, proxy protokollstøtte. Så det er en veldig featureful lastbalansering. Og det har integrering med Auto Skalering. Så når du bruker Auto Skalering og du skalere opp og ned, du kan ha dine forekomster automatisk bli med eller forlate en elastisk lastbalansering. Så da er det våre lagringstjenester. Så det første er Amazon EBS, eller Elastic Block Store. Dette er vedvarende volumer som du kan montere på dine EC2 instanser. Så du kan snapshot dem. Så når snapshot et EBS volum, går den til S3 som vi skal snakke om i et sekund. Det er tre forskjellige typer EBS volumer. Det er magnetisk EBS, som er akkurat den slags standard slags magnetisk disk. Det er den mest økonomiske alternativet. Så er det generell Formålet SSD, hvor vi får tre IOPS per gigabyte bestemmelsen. Så hvis du har én terabyte volum, har du 3000 IOPS. Og så er det klargjort IOPS. Så klargjort IOPS er når du betale for hvor mye diskplass du bruker og hvor mye IOPS kapasitet du trenger. Så du kan bestemmelsen opp 4000 IOPS per volum. Så så er det Amazon S3. Amazon S3 er vår objekt butikken. Så Amazon S3, kan du bruke den å lagre en hvilken som helst form for data. Du kan bruke den til å lagre statisk nettsteder og slange statiske nettsider. Du kan bruke S3 for sikkerhetskopier og arkiver i enkelte brukstilfeller som kilde og utgang bøtte for big data analyse, eller transkoding. Det kan også brukes som en opprinnelses for en CloudFront distribusjon. Så S3 super kraftig. S3 er designet for 11 linjer holdbarhet. Så hva det betyr er det kan opprettholde tapet av minst to data sentre samtidig uten å miste data. Du kan gjøre kryptering på S3. Så serveren sett kryptering, eller server satt kryptering med nøkkelen. Så hvis du ønsker å administrere tastene, kan du gjøre det også. Og det er breen. Så Glacier er vår langsiktig arkivering service. Det er også designet for 11 linjer med holdbarhet, men det er for når du ønsker å spare noe og glemme det, ikke sant? Så enten for overholdelse eller annen årsaker til at du trenger å arkivere noe, du bør bruke Glacier. Så Glacier koster $ 0,01 per gigabyte per måned. Og Amazon S3 starter på $ 0,03 per gigabyte per måned. Så Glacier er rimeligere og Breen tar tre til fem timer for å få dataene tilbake. Så hvis det er OK, hvis det er arkiv fall deretter Glacier er sannsynligvis den riktig bruk tilfellet for det. Så er det Storage Gateway. Så Storage Gateway er en virtuell maskin at du kan kjøre lokalt i VMware eller Hyper-V. Det gir deg et iSCSI endepunkt. Du kan deretter sette opp en annen VM på toppen av det som viser at iSCSI endepunkt med CIFS eller NFS. Alt som går inn i den aksje nettverk og deretter får støttet opp til Amazon S3, eller Glacier, eller EBS avhengig av hvordan du setter det opp. Så det er en enkel måte å få dataene opp til AWS. Så da er det vår databasetjenester. Så det første er Amazon RDS. Så dette er vår relasjonelle databasetjeneste. Så dette er en styrt relasjons database [? for deg. ?] Det vil støtte SQL Server, Oracle, MySQL, og Postgres motorer. Det gjør automatisk failover. Så hvis du har Multi-AZ alternativet er aktivert, det gjør synkron blokknivå replikering tvers tilgjengelighet soner. Og så hvis primær mislykkes, det vil bare automatisk failover mellom dem. Det også, for MySQL motor, støtter lese kopier innenfor samme region eller på tvers av regioner. Og det er alle typer interessante alternativer der. Så det vil gjøre sikkerhetskopiene for deg. Så det vil backup til S3. Det vil gjøre din patching for deg også. Så er det DynamoDB. DynamoDB er vår klart NoSQL tjeneste. For Dynamo DB det tar bort all den administrative byrden med å håndtere en NoSQL tjeneste for deg. Så du bare bestemmelse bordet og du sier hvor mye lese og skrive kapasitet du ønsker. Og det vil gi det for deg. Så det er en ekstremt enkel tjeneste å bruke. Så er det ElastiCache. Så ElastiCache er vår klarte caching tjeneste. Det er i utgangspunktet en administrert Redis eller ElastiCache. Så igjen, kan du bestemmelsen en klynge av ElastiCache eller Redis forekomster og ikke trenger å bekymre deg for backup, eller failover, eller noen av at ting. Da har vi våre applikasjonstjenester. Så CloudFront er vår Content Delivery Network og det lever på disse Edge steder at jeg snakket om før. Så CloudFront kan benyttes for live video streaming, for on demand video streaming, og for bare å ha en nettside, så hosting en nettside. Så du kan ha webområde på elastiske lastbalansering, eller tilfeller, eller S3 bøtter, eller bare på premisset maskinvare. Og du kan sette en CloudFront fordelingen foran den. Det vil bufre innholdet. Det vil sette det på kanten steder. Og så når noen går til ditt nettsted de vil bli trykket CloudFront, som skal trolig nærmere dem enn hva opprinnelsen er. Og det vil avlaste mye av belastningen av opprinnelse, dermed både sparer du penger og å få en bedre brukeropplevelse. Så er det Amazon CloudSearch. Så CloudSearch er en administrert søketjeneste. Så du sende den til din søkbar data og snakke til det gjennom en API, og det vil gjøre søkeresultatene for deg. Så er det Elastic transkoder. Så det er et klart transcoding løsning. Du setter dine videoer i en S3 bøtte, fortelle det hva du omkode inn, hvilket format og hva størrelse og alt. Og det vil omkode den og sette det inn en S3 bøtte for deg. Så er det vår store datatjenester. Så vi har fått Amazon EPJ, som er Elastic Kart Reduce. Så dette er en verts Hadoop rammeverk. Så du kan spinne opp en Hadoop cluster fra ett tilfelle til hundrevis av tilfeller Hvis du trenger. Det har dyp integrasjon av S3, slik som et filsystem for det du kan bruke HDSF, som du tradisjonelt gjøre med Hadoop. Eller du kan gjøre S3 som filsystemet. Det har støtte for flekk prissetting, noe som er, på Amazon, hvordan du legger inn bud for overkapasitet. Så det støtter alt det der. Den støtter vanlige Hadoop rammer slik som Spark og Shark og Hive og gris. Og vi har sett over 5.5 million EPJ klynger lansert på dette punktet på Amazon. Da har vi AWS dataPipeLine. Så data Pipeline er et tjeneste som vil tillate du flytte data på tvers våre ulike datalagre. Så du kan ta noe fra S3, sette det inn RDS, deretter gjøre noen emr på det, putte den inn rødforskyvning, som er våre datavarehus apparatet, og da kan du trekke noe ut av en på premisset, MySQL eksempel. Så det er alle typer ting du kan gjøre med det. Så er det rødforskyvning. Rødforskyvning er vår klart datavarehus apparatet. Det er ment å være petabyte skala, så du kan lagre mye data på den. Det er et massivt parallell arkitektur. Så du kan ha mange noder hvis du ville. Og det gjør alle sikkerhetskopier og alle den administrative ting for deg. Og så er det Kinesis. Kinesis er vår sanntid tjenesten. Så du kan ta noen kilde av real-time streaming av data, så si som Twitter Firehose, eller en haug av loggdata, send det til Kinesis. Kinesis håndterer alt for deg. Og så kan du koble arbeidere til det å trekke ut ting og, si, gjøre en live dashbord eller gjøre live-analyser på det. Så da har vi våre distribusjonstjenester. Så AWS OpsWorks er en DevOps rammeverk. Så du ta din søknad, du bryte den opp i lag. Så du har fått din lastbalansering lag, nett lag, din app laget, databasen lag, og du Bestemmelsen ting på disse lagene basert på Chef oppskrifter. Kjøkkensjefen er en konfigurasjon styringssystem. Så det støtter også livssyklus hendelser og så Hvis du ikke ønsker å administrere din egen kokk, høyre, hvis du ønsker å ha noen form for programma måte å distribuere ting på forekomstene dette er ett alternativ for deg. Da har vi Elastic Beanstalk. Så Elastic Beanstalk er en tjeneste som lar deg to-- si du er en utvikler. Du har din kode i en Git repo. Du ønsker ikke å måtte bekymre om distribusjon av dine egne ELBs eller RDS forekomster eller vanlige EC2 instanser. Så hva du gjør er du, fra koden, bare sende det til Elastic Beanstalk. Elastic Beanstalk vil bestemmelsen RDS forekomster og ELBs og alt det der for deg og distribuere koden din på dem. Så det gjør det mye enklere for utviklere å distribuere sin kode på AWS. Så er det CloudFormation. Så CloudFormation er en tjeneste for behandling av infrastrukturen som kode. Så nå at du har alt dette ting i programmet, du har fått din VPC, og din sikkerhet grupperegler, og dine EC2 instanser, og dine RDS tilfeller. Så du har hele denne arkitektur på AWS. Vel, hvordan gjør du programma spinne det opp eller gjenskape det? Du kan skrive en JSON-fil som representerer alt dette. Og så kan du [? ta?] som JSON-fil og distribuere infrastruktur ut av det. Så du kan ha en arkitektur der, hver gang du distribuerer kode, den spinner opp en ny kopi av hele arkitektur og deretter svikter over til det. Så du kan også gjøre dette til har en foranderlig infrastruktur. Så til slutt er det vår administrasjonstjenester. Slik at våre administrative tjenester starte med Amazon IAM, så det er Identity og Access Management. Slik som lar deg administrere AWS konto slik at du kan ha sub brukere og grupper og gjøre identitet federation og alle slags ting. Det er veldig viktig for sikkerheten. Da har vi Amazon CloudWatch, som er vår beregninger tjeneste. Så det gir deg CPU-bruk og alle typer beregninger. Og du kan gjøre egendefinert beregninger, og [? du kan gjøre?] auto skalering basert på disse beregningene. Og så har vi CloudTrail. Så CloudTrail er vår tjeneste for revisjon. Så det vil logge API-kall mot Amazon Web Services. Så hvem omstartet dette tilfellet? Hvem endret denne sikkerhetsgruppen? Og logge dem inn nødvendige bøtter slik at du kan se hva som skjedde i din konto og hvem som gjorde det. En ny tjeneste som vi har er arbeidsområder. Så det er en desktop virtualisering på AWS. Så du kan bestemmelsen en arbeidsstasjon, en Windows arbeidsstasjon, og det vil da komme opp i noen få minutter. Det vil være koblet til din aktive katalog, så med brukerne. Og du kan enkelt bygge den opp. Du kan enkelt bestemmelsen en ny. Det finnes forskjellige typer med annen programvare på det. Så nå som vi har gått gjennom mange av våre tjenester, la oss gjøre en faktisk live demo. Så jeg kommer til å bytte over til min nettleser her. Så det jeg ønsker å vise deg er hvordan du raskt sette opp en EC2 eksempel med Wordpress på det. Og så skal vi å gjøre det samme, men vi kommer til å spinne opp en RDS forekomst og en ELB. Så vi gjør det bare på forekomsten og vi vil bryte alle lagene ut også. Så la oss starte en EC2 eksempel. Så det første som Jeg har allerede gjort her er du kommer til å ønske å ha et nøkkelpar. Så et nøkkelpar lar deg logge inn i selve forekomsten. Så du holder den private en del av nøkkelparet, og vi legger det offentlige del på forekomsten. Og det er det som gjør at du kan logge inn. Så jeg har allerede importert min nøkkelpar, bare min vanlige SSH-nøkkelpar her. Og så den andre tingen Jeg kommer til å gjøre her er, Jeg har allerede noen tilfeller kjører, men jeg vil lansere en ny. Så jeg kommer til å plukke min operativsystemet her. Så du kan se jeg har en ganske stort valg av operativsystem. Så jeg bare kommer til å plukke din standard Amazon Linux. Og jeg kommer til å plukke en forekomst type. Og siden dette er en webserver, jeg kommer å gjøre en c3.large fordi det er sannsynligvis beregne krevende. Så jeg kommer til å plukke en c3.large, og jeg kommer til å lansere en av dem. Jeg kommer til å la den ligge i standard VPC for nå. Jeg kommer til å forlate alt dette alene. Og jeg kommer til å gjøre det mulig CloudWatch overvåking fordi CloudWatch detaljert overvåking forandrer CloudWatch overvåking fra fem minutters oppløsning til ett minutts oppløsning. Så jeg ønsker at med min web server her. Og så kommer jeg til å gå til lagring. Så jeg ønsker General Purpose SSD på her. 8 gigabyte er nok nok for meg, så jeg bare kommer til å holde det. Jeg kommer bare til å merke det Wordpress Demo. Så dette er den koden så jeg vet hva det faktisk er. Og så kommer jeg til å konfigurere en sikkerhetsgruppe. Så en sikkerhetsgruppe er som En brannmur for forekomsten. Så jeg kommer til å bruke en av mine eksisterende. Så denne sikkerhetsgruppen, det muliggjør SSH, så jeg kan SSH inn i den. Og gjør det mulig HTTP. Nå, jeg kommer til å ønske å låse ned at SSH litt mer. Du ønsker ikke hvemsomhelst fra en IP-adresse SSHing i. Så vi vil gjøre det etter at det lanseres. Så jeg er fornøyd med alt av denne ting her. Og jeg kommer til å lansere. Og så kommer jeg til å velge hva nøkkelpar jeg vil. Så jeg kommer til å velge det nøkkelpar at jeg oppdaterte før. Så nå at jeg venter for det å starte, la oss gå se på vår sikkerhetsgruppe. Så vi har fått sikkerhetsgrupper her. Her er min sikkerhet gruppe som jeg setter den i. Jeg kommer til å bare endre dette her. Så la meg gjøre dette til en litt større her. Så jeg ønsker å endre dette fra hvor som helst til My IP. Fordi det vil automatisk plukke opp min IP adressere her og lås det ned litt. Og så mens det eksempel er spinning opp, la oss spinne opp noen ting for vår andre forekomsten hvor vi kommer til å bryte ut databasen og lastbalansering slik at det kan være klart for oss. Så det første jeg kommer til å ønske å gjøre er å spinne opp en lastbalansering. Så jeg kommer til å velge lastbalansering her. Og jeg kommer til å kalle det WordpressELB. Og jeg kommer til å just-- alle Jeg ønsker er port 80 i her. Og for nå for helsen sjekk, jeg bare kommer til å gjøre TCP. Så hvis Apaches kjører, vil det være bra. Og jeg kommer til å senke sunt terskelen bare slik at det blir sunt ganske raskt. Så, igjen, har dette en sikkerhetsgruppe. Så jeg har allerede gjort en sikkerhet gruppe for dette kalles Wordpress ELB. Og det er i utgangspunktet bare skal å godta trafikk fra Port 80. Og da jeg ikke kommer til å legge til eventuelle forekomster til det for nå. Og jeg kommer til å hoppe over tagging. Og så vi kommer til å skape denne ELB akkurat nå. Så skapte lastbalansering. Jeg er også tenkt å lansere en mer eksempel her, kun for nettet en del av min Wordpress. Så her vi går. Jeg vil bare gjøre det samme ting jeg gjorde før. Så c3.large, CloudWatch detaljert overvåking aktivert. Universal SSD. Kalle dette Wordpress Web. Og jeg ønsker å velge a-- jeg allerede ha en sikkerhetsgruppe for dette. Så denne sikkerhetsgruppen godtar trafikk på port 80 fra min Wordpress ELB sikkerhetsgruppe, fra sikkerhet gruppe fra min lastbalansering, men også SSH, som igjen, vi kommer til å låse ned. Så jeg kommer til å lansere dette. Høyre. Og så hva jeg skal gjøre neste er Jeg kommer til å lansere en RDS eksempel. RDS kommer til å være min database. Så jeg kommer til å gå her. Jeg kommer til å gå til RDS. Jeg kommer til å lansere en ny forekomst. Så jeg kommer til å plukke min motor. Så her jeg har et valg av MySQL, Postgres, Oracle, eller SQL Server. Jeg ønsker MySQL. Og så kommer jeg til å si ja. Så dette er et alternativ for Multi-AZ. Så Multi-AZ, igjen, de kjøringer kommer til å spinne opp to RDS tilfeller og gjøre replikasjon mellom dem. Og hvis jeg ikke vil at jeg kan bare ha et enkelt eksempel, men jeg ønsker det. Og så kommer jeg til å plukke min databasemotor. Så jeg kommer til å plukke senest én her. Og så kommer jeg til å plukke hva slags eksempel jeg vil. Så jeg vil ha en R3, så det er minnet optimalisert eksempel. Så jeg kommer til å plukke den R3. Og jeg kommer til å plukke Ja, jeg vil Multi-AZ. Og jeg vil ha generelle formål SSD. Og jeg sannsynligvis vil ha en litt mer lagringsplass. Jeg kommer til å ha 10 konserter her. Og så kommer jeg til å plukke noen legitimasjon. Så hva er identifikator for min database? Så det kommer til å bli wordpressdb1. Jeg kommer til å kalle denne roten. Jeg kommer til å gi det et passord. Og vi kommer til å plukke en sikkerhetsgruppe for dette også. Så jeg har allerede gjort en sikkerhetsgruppe for dette. Og så kommer jeg til å gi den et databasenavn. Så vi kommer til å like kalle det wordpress. Og vi kommer til å velge en oppbevaring vindu slik at dette gjør backup for deg. Så jeg vil ha en uke med sikkerhetskopier. Og jeg ikke har en preferanse for backup vinduet. Og jeg vil ha det til automatisk oppgradere min mindre versjon her. Så jeg kommer til å forlate det som standard. Og så nå er jeg lansere min RDS eksempel. Høyre? Så nå det blir opprettet. Så nå venter vi bare på for det å installere. Så mens det skjer, la oss logge i den første EC2 eksempel vi har gjort. Så det er dette Wordpress Demo. Og vi vil bare bekrefte det. Jepp. Så la oss se om vi kan logge inn på det. Så jeg kommer til å kopiere offentlig vert navnet på den. Jeg kommer til å åpne opp et shell vindu her. [Uhørbart] SSH. Standard brukernavn er EC2-bruker. PUBLIKUM: Leo, ville du tankene Command [uhørbart]? LEO ZHADANOVSKY: Bra? Og så la oss prøve å SSH inn. Jepp. Så jeg er i mitt tilfelle akkurat nå. Så jeg SSHed i. Det er opp til fem minutter så det er definitivt min instans. Så første vi er kommer til å ønske å gjøre her det forteller meg at, oh, Jeg har noen sikkerhetsoppdateringer. Så jeg bare kommer til å kjøre hver sikkerhetsoppdateringen på her. [? sudo yum?] minus y oppdatering. Så det kommer til å raskt installere dem. Neste ting jeg ønsker å gjøre er jeg ønsker å installere noen flere ting. Så jeg kommer til å installere MySQL. Jeg kommer til å installere Apache. Jeg kommer til å måtte installere PHP. Jeg kommer til å ha for å installere PHP-plugin for MySQL. Og jeg må installere MySQL server. Så la oss installere denne ting. Installere. Slik det er gjort. Så nå vil jeg [? HTTPD. ?] Jeg ønsker Apache å starte ved oppstart. Så jeg kommer til å gjøre dette. OK. Så nå hvis jeg starter dette det vil starte. Jeg vil også MySQL til å starte ved oppstart. Så samme. Oops, skrivefeil her. OK. Og deretter faktisk jeg vil starte min web server senere. Nå ønsker jeg å starte min databaseserver, skjønt. Så gjør dette. Og så det begynner for første gang, så jeg er nødt til å gjøre noen grunnleggende trinn her. Så det første jeg kommer til å gjøre er satt et root-passord for min MySQL. Så jeg skal bare kjøre denne MySQL sikker kommando installasjon. Så det har ingen gjeldende rot passord, så la oss sette en. Og jeg kommer til å fjerne disse anonyme brukere at det skaper og deaktivere root innlogging. Og ta test databaser. Så dette alle slags productionizes din MySQL installere. Slik det er gjort. Så nå jeg burde være i stand til å koble til min MySQL server. Så jeg kommer til å se om det fungerer her. Jepp. Så jeg er i min MySQL server. Så nå det neste jeg ønsker å gjøre er Jeg ønsker å lage min Wordpress database. Så jeg kommer til å gjøre MySQL admin. [Uhørbart] OK. Så jeg laget min database. Og nå hva jeg ønsker å gjøre er jeg ønsker å opprette en Wordpress bruker. Så jeg ønsker ikke å logge inn på min Wordpress med root brukeren fordi det ville være dårlig. Så jeg vil ha en bruker som bare kan tilgang til Wordpress database. Så la oss gå inn her igjen. Og vi kommer til å [? flytte?] dette her. Så hva jeg gjør her er Jeg oppretter en bruker som kan koble fra localhost det er identifisert av min super sikkert passord her. Og så kommer jeg til å gi denne brukertilgang til hele databasen. OK. Og så nå skal jeg være i stand til å logge inn som den brukeren og bare se at databasen [? og?] testdatabase. Så jeg kommer til å gjøre mysql minus u wordpress, i stedet for rot. All right? Og da bør vi være i stand til å do-- rett? Så jeg kan se min Wordpress database her. Så det er flott. Så nå må vi faktisk laste ned og installere Wordpress. Så la oss gå til vår web-katalog. Så jeg kommer til wget Wordpress, den nyeste versjonen av Wordpress her. Jeg kommer til å trekke det. Og nå kommer jeg til å bytte HTML katalogen, som er standard [? web?] rot, med Wordpress katalogen, så. OK. Og nå skal jeg bare endring tillatelsene slik at Apache brukeren eier Wordpress katalogen. OK. Og til slutt, jeg kommer til å starte opp min webserver og håper alt fungerer. OK. Så nå la oss se hva som skjer her. Så jeg kommer til å gå her. Og se om jeg kan få i dette tilfellet her. OK. Så her er vår Wordpress oppsettskjermen. Så vi vet all denne informasjonen. Så vår database navn er wordpress. Vårt brukernavn kommer til å være wordpress. Jeg har min super sikkert passord her. Vi kommer til å være koble til localhost. Og vi kommer til å kjøre installasjons. Nå er vi bare kommer til å gi nettstedet mitt navn. Så Leos Amazing Blog. [Uhørbart] brukernavn. Jeg kommer til å få en passord for brukernavnet mitt. Jeg kommer til å sette i min e-postadresse. Og siden det er en test en, gjør jeg ikke vil at søkemotorer skal indeksere denne. Så nå er vi installere Wordpress. Så nå er vi alle satt. Så her er min Wordpress. Og her er min dashbordet. Det er en fullt fungerende Wordpress. Jeg kan oppdatere plugins her hvis jeg ville. Gjøre hva jeg vil her. Og så her er min faktiske fullt kjører Wordpress på min ett eksempel. Nå, dette er flott hvis du har en testområde, betyr men dette er ikke riktig målestokk. Vi har ett eksempel. Vi kan gjøre at forekomsten virkelig stor, men på et tidspunkt du kommer til å kjøre ut av vertikal skalering rom. Så du kommer til å ønske å skalere det mer enn det. Det er derfor vi spunnet opp med alt dette andre ting. Så la oss se om vår RDS eksempel er gjort. [? Ja,?] Våre RDS eksempel er nesten ferdig. Så det er OK fordi i mellomtiden vi kan sette opp vår EC2 eksempel. Det kommer til å være bare en litt annen prosedyre. Så vi har fått vår Wordpress web. Nå har jeg allerede hatt en løpende i går. Så jeg må bare finne ut hvilke ett var det som jeg lanserte i dag. Så dette ble lansert 4 november. Så det er en fra i dag. [? Jeg vet?] Dette var lansert, oh, 04:00. Så faktisk dette er den nye. Jepp. OK. Så dette er min nye eksempel. Så igjen, kommer jeg til å SSH inn i den. Så la oss gå tilbake til min terminal her. Så jeg kommer til å komme ut av denne. Jeg kommer til å SSH i den nye forekomsten. OK. Så jeg kommer til å gjøre noen av de samme tingene her. Så jeg kommer til å kjøre sikkerhetsoppdateringer. Jeg kommer til å installere noen pakker. Pakkene skal være litt annerledes nå. Så jeg trenger ikke MySQL server fordi vi bryte det ut. Så jeg fortsatt kommer til installere MySQL klient. Jeg er fortsatt kommer til å installere Apache. Jeg er fortsatt kommer til å installere PHP og PHP MySQL. Jeg er bare ikke kommer til å installere MySQL server. Da er jeg fortsatt kommer til å gjøre sikker Apache starter ved oppstart. Nå trenger vi databasen til å være opp. Så mens vi gjør det la oss legge dette eksempel til lastbalansering. Så vi kommer til å gå til vår lastbalansering her. Og vi er bare nødt til å kopiere ned forekomsten ID. Fikk mitt eksempel ID her. Når jeg går til min lastbalansering, se, her er min lastbalansering, her er DNS-navnet. Så det har null tilfeller i tjeneste akkurat nå fordi jeg har ikke lagt eventuelle forekomster til det. Så jeg kommer til å legge mitt eksempel. Så her er min liste over tilfeller. Så hvis jeg vil ha denne, så jeg er kommer til å legge dette til det. Nå kommer det til å vente og det er ikke til for å muliggjøre dette tilfellet inntil det blir sunt. Og det er ikke til å bli frisk før jeg slår på min web server. Så la oss se om våre RDS eksempel er opp igjen. OK. Stor. Så vår nye RDS eksempel er klar. Så dette er endepunktet for min RDS eksempel. Så det jeg skal gjøre er jeg skal koble til min RDS eksempel. Så dette er nå en fullt klarte MySQL database. Det har backup satt opp på den. Det er overflødig. Det spunnet opp i bare noen få minutter. Så nå jeg burde være i stand til å SSH inn i det from-- eller ikke SSH, men logge inn i det med MySQL klienten. Jepp. Så her er jeg. Jeg er i. Så nå dette kommer til å være lik bortsett fra at vi bare bryte det ut. Så, igjen, jeg skal faktisk komme seg ut av dette for et sekund. Vel, vi allerede opprettet Wordpress database fordi vi sette Wordpress der, så Jeg kommer til å opprette Wordpress bruker. Og det kommer til å være noen små forskjeller i her fra hva vi gjorde forrige gang. Så vi kommer til å skape Wordpress-bruker, men nå er vi ikke kommer til å være logge inn fra localhost lenger. Vi kommer til å logge inn fra EC2 eksempel. Og vi ikke kommer til å nødvendigvis vite om hva IP-adresse det kommer fra, eller vi ikke ønsker å spesifisere det til at detaljnivå. Vi kommer til å ha sikkerhet grupper som sikrer at bare våre webservere kan koble seg til dette. Så jeg bare kommer til å tillate det fra, på dette nivået, fra en IP-adresse tilkobling. Så vi bare gjorde det. Og nå er vi bare nødt til å, igjen, gi denne brukeren tilgang til Wordpress database. Så nå er jeg bare kommer til å endre dette til et wild card. OK. Så vi har fått det. La oss komme oss ut herfra. Så får vi bare sørge at vi kan logge inn nå. Jeg kommer bare til å endre mitt brukernavn til wordpress. OK. Så vi er i. Så det fungerer. Nå skal vi, igjen, jeg må sette opp Wordpress på dette tilfellet. Så hva vi kommer til å ha å gjøre er å gå til Var, www. Jeg må flytte HTML katalogen til html.old. OK. Og vi kommer til å ha å laste ned Wordpress. OK. Pakk Wordpress. Vi kommer til å flytte den til HTML-katalogen. OK. Og vi kommer til å endre tillatelsene. Og så kommer vi til å starte Apache. Så hva skal skje nå er det som skjer å være i utgangspunktet fem prøver igjen på denne ELB. Og det er slutt, dette tilfellet er kommer til å bli frisk på ELB. Så [uhørbart] her. La oss se. Dette tilfellet er ennå ikke sunt. Så hva er jeg faktisk kommer til å gjøre er jeg skal å endre helse sjekke litt litt mer bare for å gjøre det raskere. Vi kan endre det tilbake senere. Så la oss si jeg ønsker sunt terskelen på tre i stedet for fem. OK. Så nå er vi i tjenesten. Så nå kommer jeg til å gå til denne lastbalansering. Og det skal proxy meg tilbake gjennom til dette eksempel, og vi vil sette opp Wordpress på her. Nå, hvis du har din egen domenenavn eller noe, du kan bare gjøre en CNAME posten til denne DNS-navn. Og den elastiske lastbalansering Tjenesten er skalerbar på baksiden slutten, slik at det skalerer opp og ned av seg selv. Så det kan være flere IP-adresser. IPS kan endre seg. Så du bør alltid referere det fra at DNS-navn. OK. Så her vi går. Vi er tilbake på vår oppsettskjermen. Nå skal vi gjøre den samme prosessen nesten. Så vår database navn er wordpress. Vårt brukernavn navn er wordpress. Vi har fått den samme super sikre passord som før, bortsett fra databasen verten er nå kommer til å være den RDS eksempel. Så vi kommer til å gå her. Vi kommer til å gå til RDS. Vi kommer til å gå til mine tilfeller. Jeg trenger min endepunkt navn her. Det er denne. Så jeg skal bare kopiere og lime inn denne. All right? Så la oss se om det fungerte. OK. Så det fungerer. Så du kan koble til RDS eksempel. Igjen, det kommer til være Leos Awesome Blog. OK. Så nå skal vi installere vår Wordpress. Så vi er ferdige. Så la meg bare logge inn å sørge for at det fungerte. OK. Så nå har vi fått en fullt kjører Wordpress. Vi kan gjøre alle typer operasjoner på den. Så forskjellen er nå at vi har en egen database. At databasene er overflødig. Vi fortsatt bare har én nettside server, men vi kunne nå ta et bilde av denne web server, starte den på nytt, og så har vi to webservere bak denne lastbalansering. Endepunktet endrer ikke om det er en, eller to, eller 50 webservere. Vi kan skalere det utover dette. Så det er plugins for Wordpress hvor du kan bruke S3 for statiske eiendeler. Du kan bruke CloudFront å cache disse eiendelene. Du kan bruke ElastiCache slik at du kan bruke memcached utgangspunktet å lagre øktstatus der. Så som du skalerer fra ett til flere tilfeller du kommer til å anta at disse forekomstene er flyktig, slik at de kan gå bort. Så du er nødt til å tenke om hvor lagrer jeg logger, hvor skal jeg lagre øktstatus. Hvordan gjør jeg det slik at det er OK at slike tilfeller kan forsvinne, eller mer av dem kan vises? Så du er nødt til å svare på spørsmål som dette. Men det er ganske vanlig mønster. Så du bare begynne å losse noen vedvarende ting til andre nivåer. Så nå har vi fått dette, er vi gjort [? tre lags?] ting. Det siste er jeg kommer til å gjøre her er jeg kommer til å gjøre mitt lastbalansering en litt mer solid nå at det er merket som sunn. Så det er vanligvis ikke en god idé for nettsteder å gjøre TCP helsesjekk fordi Apache kan være opp, men det kan være tilbake PHP feil. Så du ikke ønsker det. Så hva jeg kommer til å gjør her er jeg kommer å endre dette til en HTTP helsesjekk. Og det kommer til å være index.php, ikke index.html. Og vi kommer til å endre dette sunn terskelen tilbake til fem. Slik det er gjort. Så det bør fortsatt være sunn. Jepp. Så vi er fortsatt i tjeneste. Så det er hvordan du setter opp Wordpress på AWS. Så jeg tror på mindre enn 20 minutter har vi begge satt opp på en forekomst, på egen hånd, og en full tre lags arkitektur der hver tier er uavhengig skalerbar. Du kan gjøre alle typer av interessante ting med databasen å skalere også. La meg vise deg ett mer interessante her. Så la oss si for dette jeg ønsker å bryte ut leser fra de skriver. Jeg kan lage en lese replika. Så jeg kommer til å like skape en lese replika. Så dette kommer til å være wordpressdb1 read1. Jeg kommer til å gjøre det på samme region, men jeg kunne gjøre det i en annen region. Så vi kommer til å begynne provisioning en lese kopi her. Så nå vi skaper lese kopi. Som blir skapt det i bunnen. Så du kan gjøre alle typer av kule ting her. Så er jeg ferdig med demoen. Så jeg tror vi har ca 10 minutter. Så jeg skal ta noen spørsmål noen har, om noen AWS relatert emne. Anyone? Cool. OK. Takk alle sammen.