Kuidas pidevalt staatilist veebisaiti stiilselt juurutada, kasutades GitHubi ja AWS-i

Selles postituses õpime tundma, kuidas kasutada AWS CodePipeline'i ja CodeDeployi GitHubist staatilise veebisaidi lähtekoodi automaatseks hankimiseks ja selle veebisaidi S3-le juurutamiseks.

Me konfigureerime juurutamise nii, et see juhtuks igal meie uue haruga seotud kohustuse korral.

Alustame kooditoru loomisega, mille lähtepunktiga on seotud meie GitHubi hoidla. Kui meie peamisele harule suunatakse uus kohustus, kontrollib gaasijuhe automaatselt uusimat koodi. Seejärel saame käivitada ehitusetapi meie torustikus. Selle sammu abil saate installida sõltuvusi, käivitada teste ja pakkida meie saidi juurutamiseks. Viimane samm juhib meie staatilise veebisaidi meie S3 staatilise veebisaidi ämbrisse.

Nüüd, kui me teame, mida me ehitama hakkame, hüppame sisse ja õpime seda ehitades veelgi rohkem.

AWS CodePipeline'i eeltingimused

Meie kontol oleva AWS CodePipeline'i püstitamiseks, mis suhtleb meie GitHubi hoidlaga, on mõned eeltingimused, mille eest peate hoolitsema.

  1. Teil peaks olema AWS-i konto juba seadistatud.
  2. Teil peaks olema konto jaoks konfigureeritud CLI-juurdepääs.
  3. Teie staatilist veebisaiti tuleks juba AWS S3-st hostida. Kui ei, siis vaadake seda linki.

GitHubi ja AWS-i konfigureerimine

Selleks, et AWS saaks GitHubis asuva meie haru muudatuste kohta küsitlusi teha, peame suutma genereerida oma GitHubi hoidla jaoks juurdepääsuloa. Isikliku juurdepääsu loa saab genereerida GitHubis järgmiste sammude abil.

  1. Kui olete GitHubisse sisse loginud, klõpsake paremas ülanurgas oma profiilifotol ja klõpsake siis nuppu Seaded.
  2. Klõpsake vasakul vasakul valikul Arendaja seaded.
  3. Klõpsake vasakul isiklikke pääsulubasid.
  4. Klõpsake käsul Genereerige uus luba ja sisestage nime jaoks AWSCodePipeline.
  5. Lubade saamiseks valige repo.
  6. Klõpsake käsul Genereeri luba.
  7. Kopeerige luba kuskile, et saaksime seda hiljem kasutada.

Meie käsitsi CodePipeline'i loomine

Esimene asi, mida peame pakkuma, on CodePipeline. Meie torujuhe koosneb kahest etapist, lähteetapist, mis on ühendatud GitHubiga, ja ehitusetapist, mis kasutab meie staatilist veebisaiti.

Jätkame ja looge AWS-i konsooli kaudu meie CodePipeline:

  1. Liikuge AWS-i konsoolis jaotisse CodePipeline.
  2. Klõpsake nuppu Loo torujuhtme.
  3. Sisestage oma torujuhtme nimi.
  4. Valige allikapakkujaks GitHub.
  5. Klõpsake nuppu Ühenda GitHubiga. See avab eraldi akna, kus logite sisse oma GitHubi kontole. Pärast sisselogimist peate andma AWS CodePipeline'ile repo juurdepääsu. See on sideühendus teie GitHubi repo ja CodePipeline'i vahel.
  6. Valige hoidla, mida soovite selles torustikus kasutada.
  7. Sisestage haru sisendisse pea- või vaikimisi haru.
  8. Klõpsake nuppu Edasi.
  9. Ehituse pakkuja jaoks valime AWS CodeBuild.
  10. Valige Loo uus ehituse projekt.
  11. Sisestage oma projekti projekti nimi.
  12. Keskkonnapildi jaoks kasutame pilti, mille pakub AWS CodeBuild.
  13. Valige operatsioonisüsteemiks Ubuntu.
  14. Valige käitamisajaks Node.js ja versiooniks nodejs: 6.3.1.
  15. Jätke ehituse spetsifikatsioon variandiks buildspec.yml.
  16. Jaotises CodeBuild teenusroll tahame luua uue teenusrolli.
  17. Sisestage teenuserolli nimi, mida CodeBuild kasutab.
  18. Jätke ülejäänud väärtused vaikeseadetele.
  19. Klõpsake nuppu Salvesta ehituse projekt ja seejärel nuppu Edasi.
  20. Juurutuspakkuja jaoks soovime, et juurutamist pole.
  21. Klõpsake nuppu Edasi.

Kellele meeldib nuppude klõpsamine? Mitte mina.

See oli palju nupuvajutusi, eks? Kas saaksite seda uuesti teha ilma kõiki 21 sammu vaatamata? Ma tean, et ei saanud.

Head uudised! Seal on palju parem viis oma kooditorustike või mis tahes AWS-i infrastruktuuri loomiseks ja haldamiseks. Võib-olla olete kuulnud terminist Infrastruktuur kui kood ja see on üsna täpselt nii, nagu see kõlab. Esitage oma infrastruktuuri koodina, nii et saate seda luua, hooldada ja hävitada ilma GUI-d kunagi avamata.

Kui olete AWS-i või mõne uue pilveteenuse pakkuja uus, pole GUI-ga alustamisel midagi halba. Kuid me tahame seada eesmärgiks automatiseerimise.

Seal on palju tööriistu, mis teevad selle väga lihtsaks. AWS pakub CloudFormationi, mis võimaldab teil määratleda oma ressursid JSON- või YAML-i mallides.

CloudFormation on suurepärane, kuid seal on ka muid tööriistu. Üks, mida olen viimasel ajal palju kasutanud, on Terraform. See on pilveteenuse pakkuja agnostiline ja toetab kogukonna arendatud moodulite kaudu mitmesuguseid pakkujaid.

Selle ajaveebi postituse jaoks panin kokku kiire Terraformi malli, mis pakub meie AWS-i infrastruktuuri.

Teeme kiire ülevaate selle malli tegemistest.

Ülaosas määratleme malli kantavad muutujad. Ressursside eraldamiseks peame läbima järgmise:

  • meie torujuhtme nimi
  • meie GitHubi kasutajanimi
  • meie varasema GitHubi märk
  • GitHubi hoidla, mille tahame oma torujuhtmega ühendada

Kui me täpsustame, et soovime kasutada AWS-i pakkujana, kui regioon on muudetud muutujana. Nagu me hetkega näeme, laadib see Terraformi pakkuja, mis toetab enamikku AWS-i ressursse. Siit saate vaadata, milliseid AWS-i ressursse Terraform toetab.

Järgmine ressursside komplekt, mida loome, on meie AWS CodePipeline'i jaoks.

  • Loome S3-ämbri, mis hoiab meie torujuhtme igast etapist esemeid / väljundeid.
  • Peame looma IAM-i poliitika, mis võimaldab CodePipelineil oma mallis koodpipeline_role täita siin loodava rolli. Sellele rollile on lisatud poliitika, Atta_codepipeline_policy. Eeskirjad võimaldavad juurdepääsu AWS-i teenustele, millele peame oma gaasijuhtme kutsumise ajal helistama.
  • Seadistame vajalikud ressursid selleks, et CodeBuild töötaks ootuspäraselt. Me määratleme eeldatava rolli poliitika, mis võimaldab CodeBuildil võtta endale roll ja pääseda juurde teenustele koodipildi_policy kaudu.
  • Loome oma tegeliku CodeBuildi projekti build_project, mis juhib meie CodePipeline'i ehitusetappi. Pange tähele, et me määratleme allika, mis tuleb olla kooperatiivne, ja meie ehitisviis peab olema ehitispec.yml.

CodePipeline'i varustamiseks määrame artefaktikaupluseks S3-ämbri, mille varem varustasime. See roll on kooperatiivi roll, mille me ka varem määratlesime. Lähteastmes kasutatakse GitHubi pakkujat ja luba, mille me GitHubis genereerisime. Tahame selle etapi väljundi saata omaduse output_artifacts kaudu sildile, mille nimi on kood.

Meie CodePipeline'i ressursi viimane etapp on ehitusetapp. Pakkuja on siin CodeBuild ja oleme määratlenud, et meie sisend_artifaktid on lähteteksti etapis koodiväljundid. Seejärel täpsustame CodeBuildi projektile ProjectName, mis vastutab ehitusetapi täitmise eest.

Selles mallis on kõik, mida peame oma pideva juurutamise jaoks ette nägema. Kui soovite ainult AWS-iga üles astuda, võib selle käsitsi konfigureerimine olla kiirem kui esimese Terraformi malli kirjutamine. Kuid pikas perspektiivis on teie infrastruktuuri koodina määratlemisel tohutu kasu:

  • Teie infrastruktuuri määratlus on allikakontrollis. Seda saab korrata, nagu kood oleks.
  • Teie infrastruktuur on nüüd korratav. Kui peate selle teise AWS-i piirkonda teisaldama, saate malli selles piirkonnas käitada.
  • Saate kiiresti muudatusi teha, muutes malli ja rakendades värskendusi.

Nüüd, kui me teame, mida see mall teeb ja meil on Terraform installitud, saame selle malli käsurida käitada.

Esmalt käivitame terraform init kataloogist, kus asub meie mall. See tõmbab sõltuvused, mida Terraform peab malli käivitama.

Kui meie Terraformi mall on initsialiseeritud, saame kasutada käsku „plaan”, et näha, mida täpselt luuakse.

Kas märkate kõike rohelist värvi? Need on ressursid, mis luuakse. Kui ressursid on kollastes värvides, siis uuendatakse neid ressursse. Siis, kui ressursse oleks punaselt, kustutatakse need.

Seejärel saate käsu rakendada käivitada, et mallist kõik tegelikult luua. Tekib kinnitusviip, sisestage lihtsalt jah.

Kui mall on valmis, peaksime nägema, et kõik meie AWS-i ressursid on loodud meie pideva juurutamise ettevalmistamiseks.

Oota, mida me just tegime?

See on palju samme ja üsna väike infrastruktuur, millega me AWS-is püsti tõstsime. Vaatame siis kõrgel tasemel läbi selle, mille just lõime.

Meie torujuhtme ülaosas on Allikas, meie puhul on see meie GitHubi hoidla. Konfigureerisime torujuhtme perioodiliselt küsitlema meie hoidla peamist haru. Kui peaharus on uusi kohustusi, aktiveerub torujuhe uue ehitamisprotsessi käivitamiseks. Seda nimetatakse sageli meie ehitustorustiku käivitajaks.

Kui algab uus ehitamine, kontrollib meie torujuhtme ülemharu viimased kohustused. Kui muudatused on kontrollitud, edastatakse need meie torustiku järgmisele etapile, ehitamisjärgule. Selle sammu jaoks kasutame teist AWS-i teenust CodeBuild. Oleme oma CodeBuildi projekti konfigureerinud kasutama Node.js pilti, mille pakub Amazon. Selle pildi juurde on juba installitud Node.js, nii et meie hoidlat ehitaval ehitamismasinal on sellele juurdepääs.

Kuidas aga AWS CodeBuild teab, kuidas meie hoidlat üles ehitada? Siit tuleb sisse ehitispec.yml. See on spetsiaalne fail, mille paneme oma hoidla juure. Selles konfigureerime ehitamisprotsessi erinevaid faase, nagu eelinstalli, ehituse ja järelehituse. Meie kasutusjuhuks konfigureerime lihtsalt ehitamisprotsessi failispecdspec. See koosneb sisu kopeerimisest meie Allikast meie S3 veebisaidi ämbrisse, rakendades tõhusalt meie staatilist veebisaiti.

Liigume üle meie staatilisele veebisaidi hoidlale ja konfigureerige meie ehitispõhine fail.

Meie ehituse spetsifikaadi faili seadistamine

Alustame faili buildspec.yml lisamisega meie staatilise veebisaidi juuri.

Sellest failist saab mall, mida AWS CodeBuild kasutab meie staatilise veebisaidi ehitamiseks ja juurutamiseks. See koosneb eelinstalli, installi, ehituse ja ehituse järkudest. Meie kasutuseks on ehitusetapi võimendamine.

See, mida me ülaltoodud ehituse spetsifikatsioonis teeme, on üsna sirgjooneline, see on tegelikult vaid üks joon. Võtame oma staatilise veebisaidi sisu ja kopeerime selle S3-ämbrisse, mis majutab meie saiti AWS-i käsuribaliidese kaudu. Teiste sammude ajal uurime, milline samm meie ehitamisprotsessis kulges.

Muidugi saaksime siin veelgi rohkem ära teha, kui meil oleks selleks vajadus. Näiteks kui meil oleks vaja käivitada meie paketis.json ehitamisprotsess, siis näeksid ehitamise ja ehitamise samm välja järgmised:

Nüüd töötame npm buildi oma ehitusetapis ja salvestame s3 sünkroonimiskäsu meie ehitusejärgseks etapiks. Meie ehitusspekt annab meile võimaluse skriptida mitte ainult meie saidi juurutamist, vaid ka seda, kuidas need on üles ehitatud ja testitud. Saame kasutada ka muid etappe, näiteks installimist, et lisada sõltuvusi, mida meie ehitamisprotsess vajab.

Vaatame nüüd meie originaalset ehitustüübi faili, mis kopeerib meie staatilise saidi S3-sse. Veenduge, et see asub teie hoidla juurdes, kuna CodeBuild otsib seda just siit. Kontrollige seda oma hoidlas, et saaksime käivitada meie CodePipeline'i.

Meie CodePipeline'i käivitamine

Varem seostasime CodePipeline'i lähteteksti meie staatilise veebisaidi GitHubi hoidlaga. See on konfigureeritud jälgima muudatusi meie peaharus. Niisiis käivitavad kõik sellele harule tehtud uued muudatused uue CodePipeline'i käitamise. Kui me just kontrollisime faili buildspec.yml, peaksime nüüd nägema meie CodePipeline'i käivitamist.

Näeme siin, et meie allikaetappi on kasutatud meie hoidla peaharu uute muudatuste tõttu. See lõpetas ja saatis oma esemeid ehituse etapile. Ehitusetapp võttis need esemed ja käivitas faili buildspec.yml, et neid meie S3-ämbrisse juurutada.

Kui me klõpsaksime DeployToS3 etapil üksikasjade lingil, näeksime logisid, mida meie ehitamisprotsess väljastab.

Kui meie DeployToS3 etapp on õnnestunud, peaksime saama staatilise veebisaidi brauseris uuesti laadida ja muudatusi näha.

Bam! Meil on pidev juurutamine

Kui ma kanaldan siia oma sisemise Emerili, on meil nüüd staatilise veebisaidi pidev juurutamine. Mis tahes uue pühendumisega meie peaharule käivitatakse uus CodePipeline'i käitamine. See kontrollib GitHubi uusimat koodi ja edastab selle CodeBuildile. Seejärel käivitab meie ehitamisprojekt selle, mis on meie ehituse spetsifikaadis.

Praegu kopeerib meie buildspec-fail lihtsalt meie staatilise veebisaidi sisu meie S3-ämbrisse. Kuid me võiksime seda laiendada, et teha rohkem asju. Meie saidi ehitamiseks või testide käivitamiseks võiksime käivitada npm ülesandeid. Kui kasutame oma staatilise veebisaidi ees ka CloudFronti, võime oma uue saidi juurutamisel esitada kehtetuks tunnistamise taotluse.

AWS-i sukeldumisega ja seda tegelikult kasutades on nii palju asju õppida. Staatiline veebisait võib tunduda lihtsa kasutusvõimalusena, kuid paljude asjade õppimiseks on see fantastiline.

Kas näete rohkem Amazoni veebiteenuste kohta?

Olen kasutanud AWS-i juba üle kuue aasta ja õpin alati uusi teenuseid ja uusi võimalusi olemasolevate kasutamiseks. See on tohutu platvorm, kus on palju dokumentatsiooni. Kuid on aegu, kus see dokumentatsioon võib tunda end tohutu hulgaliselt teavet. Selle punktini, kus te selles eksite.

Sellest probleemist inspireerituna andsin hiljuti välja e-raamatu ja videokursuse, mis lõikab läbi teabemere. See keskendub staatiliste veebisaitide majutamisele, turvamisele ja juurutamisele AWS-is. Eesmärk on õppida selle probleemiga seotud teenuseid nende kasutamise ajal. Kui olete soovinud AWS-i õppida, kuid te pole kindel, kust alustada, siis vaadake minu kursust.

Kui teile see meeldis, ärge unustage, et pakute oma toetuse näitamiseks ka plaksutusi!