Kuidas luua skaleeritavat Symfony rakendust Kubernetes

Kaasaegsed veebirakendused on keerukad. Kasutajate ootused teie rakendusele suurenevad pidevalt: tänapäeval peab rakendus olema kiire, mugav, hõlpsasti kasutatav ja ilus.

Nende nõudmiste täitmine võib saada uue toote loomisel veel üheks raskuseks. Isegi kui tegelete tõelise probleemiga, peate selle õigesti rakendama, et sellest elatist teenida.

Selle uue raskuse leevendamiseks ja nende eeldatavate funktsioonide loomiseks ja säilitamiseks kuluva aja lühendamiseks kasutab kaasaegne rakendus tavaliselt paljusid erinevaid komponente, alates sisu edastamise võrkudest (CDN) kuni täistekstiotsinguteenuste ja laadimisbilanssideni.

Kaasaegne veebirakenduste arhitektuuri ülevaade (Jonathan Fultoni veebiarhitektuurist 101)

Selle arhitektuuri eesmärk on ehitada rakendus lisaks üldteenustele (vahemälu, täisteksti otsing, tööjärjekord jne). See vähendab loomulikult nende teenuste säilitamiseks kuluvat aega, kuna neid hooldab tavaliselt keegi teine ​​(ja mõnikord ka avatud lähtekoodiga).

Sellise infrastruktuuri kasutamisel on kriitiline võimalus hõlpsalt suhelda kõigi selle komponentidega rakenduses. Siin teevad Kubernetes ja Symfony koostööd, et aidata teil saavutada ülikiireid tulemusi.

Kubernetes: Dockeri konteinerorkester

Mõni aasta tagasi hakkas tekkima Dockeri projekt, mis võimaldas arendajatel hõlpsalt luua eelmist tüüpi infrastruktuure. Mõne rea konfiguratsiooni abil saab iga Dockerit kasutav arendaja luua ühendatud konteinerite võrgu, vähendades iga teenuse seadistamise keerukust.

See projekt pani pöörde sellele, kuidas paljud arendajad arvasid infrastruktuuri üle. Tänapäeval on tavaline kasutada terminit DevOps, viidates inimestele, kes on võimelised rakendusi arendama, pidades silmas sobivat infrastruktuuri.

Kubernetes on järgmine loomulik samm: see loob tootmiseks valmis keskkonna Dockeri konteinerite käitamiseks, pakkudes turvalisust, vastupidavust ja mastaapsust. Dockeri ja Kubernetesi abiga saate hõlpsasti luua rakendusi, mis võimendavad kogu geneeriliste teenuste komplekti, aidates teil suurepäraseid tooteid palju kiiremini üles ehitada.

Selles artiklis keskendun täpsemalt Kubernetesile Google Cloud Platformil (GCP), et oleks näide, kuid seda saaks rakendada kõigi pilveteenuse pakkujate puhul.

Symfony kasutamine Kubernetes

Enne selle arendamist on alati kasulik mõelda rakenduse integreerimise üle oma infrastruktuuri. See võimaldab teil oma ärinõuete põhjal kindlaks teha, milliseid teenuseid vajate ja kuidas nendega rakendusest suhelda.

Üks olulisemaid elemente, mida rakenduse loomisel tuleks meeles pidada, on selle ulatus.

Rakenduse mastaapimine tähendab tegelikult teie rakenduse koodi tootmisprobleemide arvu suurendamist, et käsitleda rohkem taotlusi. Seega on „skaleeritava rakenduse” loomiseks alati meeles üks peamine mõte: ärge talletage oma rakenduse olekut koodikonteinerisse. Kui teie koodikonteineril on olek, dubleeritakse see olek mõõtmise ajal, mis põhjustab järjepidevusprobleeme, mis võivad teie rakenduse rikkuda.

Nagu ma oma artiklis kiirete testide komplekti loomise kohta Symfonyga selgitasin, on meie rakenduse olekus kaks peamist kohta: andmebaas ja failisüsteem.

Rakenduste failide hallatud failihoidlasse salvestamiseks kasutage rakendust Flysystem

Peaaegu kõigil pilveteenuse pakkujatel on vähemalt mingil viisil võimalus failisarnaseid elemente väliselt talletada (GCP-l on Google Cloud Storage). Ärge kõhelge nende rakenduste failide talletamisel lootmapanemisest: need on lõpmata laiendatavad, pakuvad nende peal hõlpsasti konfigureeritavat CDN-i ning on kiired ja usaldusväärsed.

Tavaliselt kasutan sellistele teenustele juurde pääsemiseks ja nendega suhtlemiseks Flysystemit. Flysystem on raamatukogu, mis pakub failisüsteemi abstraktsiooni. Lisaks parema testikomplekti loomisele ühildub Flysystem ka paljude pakkujatega, kelle hulgas on peaaegu kindlasti ka teie pilveteenuse pakkuja.

Google'i pilvesalvestuse jaoks kasutan isiklikult https://github.com/Superbalist/flysystem-google-cloud-storage.

Seadistage Doctrine pakutava SQL-teenuse kasutamiseks

Enamik pilveteenuse pakkujaid annab teile võimaluse tugineda ka nende enda hallatavale SQL-i teenusele. GCP-l on Google Cloud SQL-i teenus, mis toetab MySQL ja PostgreSQL.

Need tooted on suurepärane viis oma rakenduse andmebaasi oleku salvestamiseks skaleeritavas ja usaldusväärses kohas. Kui kasutate rakendust Google Cloud SQL koos Kubernetesiga, soovitan teil kasutada Cloud SQL puhverserverit. See loob teie andmebaasi puhverserveri, mida saate kasutada klassikalise andmebaasina koos Doctrine'iga.

Kasutage vahemälu ja seansside jaoks Redist

Teie rakenduse vahemälu ja seansid on osa teie projekti olekust. Probleemide vältimiseks tuleb need teie instantside vahel jagada.

Redis sobib suurepäraselt nendeks kasutusjuhtumiteks: mäluklahvi väärtuse säilitajana on see ülikiire ja suudab paralleelselt käsitleda sadu tuhandeid ühendusi. Tõenäoliselt ei ole see teie rakenduse kitsaskoht.

Õnneks on Symfony juba looduse poolt loodud, et võimaldada Redise konfigureerimist seansi käitlejana ja vahemälu taustaprogrammina:

  • seansi töötlejana konfigureerimiseks kasutan isiklikult https://github.com/snc/SncRedisBundle
  • vahemälu taustaprogrammina seadistamiseks piisab mõnest konfiguratsiooniridast:
raamistik:
    vahemälu:
        rakendus: vahemälu.adapter.redis
        default_redis_provider: "redis: // localhost"

Kasutage oma logide jaoks ühist asukohta

Ehkki teie rakenduse logid ei ole tehniliselt teie osariik, on probleemide silumise õudusunenägu nende saatmine paljudes erinevates konteinerites. Tavaliselt on hea mõte hoida neid konteineri asemel ühiskasutatavas kohas.

Monologis on saadaval palju käitlejaid, mis saavad sellel tasemel abiks olla: ElasticSearch, MongoDB, ... Kuid mulle meeldib Sentry: see on eriti kasulik teenus, mis loob teie probleemidest automaatselt üksikasjalikud aruanded. Räägin sellest natuke ja sellest, kuidas seda Symfony'is kasutada tulevases artiklis :).

Kasutage Kuberneteses oma rakenduse konfigureerimiseks keskkonnamuutujaid

On olemas seisund, mille võime hõlpsalt unustada: volikirjad ja saladused. Ehkki neid käitusel ei muudeta, ei tohiks neid turvalisuse huvides siiski teie koodikonteinerisse salvestada.

Õnneks on Kubernetes'iga võimalik paremini hakkama saada. Tegelikult on selle paremaks tegemiseks kaks võimalust:

  • võite tugineda Kubernetes'i keskkonnamuutujatele, et sisestada väärtused otse oma mahutitesse ja kasutada Symfony keskkonnamuutuja funktsioone.
  • või võite kasutada spetsiaalset Kubernetes'i salajast haldussüsteemi, mis võimaldab teil saladusi salvestada, hallata ja ühendada oma konteinerites failidena, mida Symfony toetab keskkonnamuutujate protsessoritega (env (fail: your_secret_file)).

See idee mitte salvestada rakenduse olekut selle koodi lähedale on muutumas millekski tavapäraseks. Siin loetletud mõisted on vaid jäämäe tipp: ärge kartke, et vaadata lisateabe saamiseks rakendust The Twelve-Factor App ja Reproducible Builds.

Kas teil on sellele artiklile veel midagi lisada? Ärge kõhelge kommenteerimast!