Com es crea una aplicació escalable de Symfony a Kubernetes

Les aplicacions web modernes són complexes. Les expectatives dels vostres usuaris sobre la vostra aplicació augmenten constantment: actualment, una aplicació ha de ser ràpida, còmoda, fàcil d’utilitzar i atractiva.

Complir aquests requisits pot convertir-se en una altra dificultat per elaborar un gran producte. Fins i tot si s’aborda un problema real, s’ha d’encertar per viure-ne.

Per resoldre aquests nous reptes i reduir el temps que es necessita per construir i mantenir aquestes funcions esperades, una aplicació moderna sol utilitzar molts components diferents, des de xarxes de lliurament de contingut (CDN) fins a serveis de cerca de text complet i equilibradors de càrrega.

Descripció general de l'arquitectura d'aplicacions web moderna (de Web Architecture 101 de Jonathan Fulton)

Aquesta arquitectura té com a objectiu construir una aplicació basada en serveis generals (memòria cau, cerca de text complet, cua de treballs, etc.). Això, per descomptat, redueix el temps necessari per mantenir aquests serveis, ja que solen ser gestionats per algú altre (i de vegades de codi obert).

En utilitzar aquesta infraestructura, és vital poder interactuar fàcilment amb tots els components de la vostra aplicació. Aquí és on Kubernetes i Symfony treballen junts per ajudar-vos a obtenir resultats increïblement ràpids.

Kubernetes: un orquestrador de contenidors Docker

Fa uns anys es va llançar el projecte Docker per permetre als desenvolupadors crear fàcilment infraestructures com l’anterior. Amb algunes línies de configuració, qualsevol desenvolupador que faci servir Docker pot crear una xarxa de contenidors interconnectats, abstracte de la complexitat de la configuració de cada servei.

Aquest projecte va revolucionar la manera com molts desenvolupadors pensaven sobre la infraestructura. Actualment, el terme DevOps s’utilitza sovint per referir-se a persones que són capaces de desenvolupar aplicacions tenint en compte la infraestructura adequada.

Kubernetes és el pas lògic: es crea un entorn preparat per a la producció per a contenidors Docker que ofereix seguretat, fiabilitat i escalabilitat. Mitjançant Docker i Kubernetes, podeu crear fàcilment aplicacions que facin servir un conjunt complet de serveis genèrics per crear productes excel·lents molt més ràpidament.

En aquest article, em centraré més específicament en Kubernetes a Google Cloud Platform (GCP) per posar un exemple. Tanmateix, això es pot aplicar a qualsevol proveïdor de núvol.

Ús de Symfony a Kubernetes

Sempre és útil pensar en integrar la vostra aplicació amb la vostra infraestructura abans de desenvolupar-la. En funció de les vostres necessitats empresarials, podeu determinar quins serveis necessiteu i com podeu interactuar amb ells des de la vostra aplicació.

Un dels elements més importants a tenir en compte a l’hora de construir una aplicació és l’escalabilitat.

"Escalar una aplicació" significa en realitat augmentar el nombre d'instàncies de producció del codi de l'aplicació per gestionar més sol·licituds. Per crear una "aplicació escalable", cal tenir en compte una única idea: no deseu l'estat de la vostra aplicació al contenidor de codis. Si el vostre contenidor de codis té un estat, aquest estat es duplica durant l’escala, cosa que crea problemes de coherència que poden danyar la vostra aplicació.

Com he explicat en el meu article sobre la creació d'una suite de proves ràpida amb Symfony, hi ha dues àrees principals on resideix l'estat de la nostra aplicació: la base de dades i el sistema de fitxers.

Utilitzeu Flysystem per emmagatzemar els fitxers de l'aplicació a l'emmagatzematge de fitxers gestionat

Gairebé tots els proveïdors de núvol tenen almenys una forma d'emmagatzemar elements semblants a fitxers externament (GCP té Google Cloud Storage). No dubteu a confiar-hi per emmagatzemar els vostres fitxers d’aplicació: són infinitament ampliables, ofereixen un CDN fàcil de configurar i són ràpids i fiables.

Normalment utilitzo Flysystem per accedir a aquests serveis i interactuar amb ells. Flysystem és una biblioteca que proporciona una abstracció del sistema de fitxers. Flysystem no només us ajuda a crear un millor conjunt de proves, sinó que també és compatible amb molts proveïdors, que gairebé segur inclouen el vostre proveïdor de núvol.

Personalment faig servir https://github.com/Superbalist/flysystem-google-cloud-storage per a Google Cloud Storage.

Configureu Doctrina per utilitzar el servei SQL proporcionat

La majoria de proveïdors de núvol també us ofereixen l'opció de confiar en el vostre propi servei SQL gestionat. GCP té el servei de Google Cloud SQL que admet MySQL i PostgreSQL.

Aquests productes us permeten emmagatzemar l’estat de la base de dades de la vostra aplicació en una ubicació fiable i escalable. Si utilitzeu Google Cloud SQL amb Kubernetes, us recomano que feu servir el servidor intermediari Cloud SQL. Es crearà un servidor intermediari per a la vostra base de dades que podeu utilitzar com a base de dades clàssica amb Doctrine.

Utilitzeu Redis per a la vostra memòria cau i les vostres sessions

La memòria cau i les sessions de l'aplicació formen part de l'estat del projecte. Cal que les compartiu entre les vostres instàncies per evitar problemes.

Redis és perfecte per a aquests casos d’ús: com a emmagatzematge de valors de claus d’emmagatzematge, és extremadament ràpid i pot processar centenars de milers de connexions en paral·lel. Probablement no serà el coll d'ampolla de la vostra aplicació.

Afortunadament, Symfony està dissenyat de manera inherent perquè Redis es pugui configurar com a gestor de sessions i backend de memòria cau:

  • Per configurar-lo com a gestor de sessions, faig servir personalment https://github.com/snc/SncRedisBundle
  • Algunes línies de configuració són suficients per configurar-lo com a backend de memòria cau:
Frame: Cache: app: cache.adapter.redis default_redis_provider: "redis: // localhost"

Utilitzeu una ubicació compartida per als vostres registres

Tot i que els registres d'aplicacions tècnicament no pertanyen al vostre estat, és un malson enviar-los en molts contenidors diferents per solucionar problemes. Normalment és una bona idea guardar-los en un lloc i no al contenidor.

Hi ha molts gestors disponibles a Monolog que poden ajudar-vos en aquest nivell: ElasticSearch, MongoDB, ... No obstant això, m'agrada Sentry: és un servei molt útil que genera automàticament informes molt detallats sobre els vostres problemes. Parlaré una mica més sobre això i sobre com utilitzar-lo en un futur article de symfony :).

Utilitzeu variables d'entorn per configurar l'aplicació a Kubernetes

Hi ha una condició que podem oblidar fàcilment: identificacions i secrets. Tot i que no canvien en temps d'execució, per raons de seguretat tampoc no s'han d'emmagatzemar al contenidor de codi.

Afortunadament, és possible obtenir millors resultats amb Kubernetes. De fet, hi ha dues maneres de fer-ho millor:

  • Podeu confiar en les variables d'entorn de Kubernetes per posar els valors directament als contenidors i utilitzar les funcions de les variables d'entorn de Symfony.
  • o podeu utilitzar el sistema de gestió de secrets dedicat de Kubernetes que us permet emmagatzemar, gestionar i compartir secrets com a fitxers als vostres contenidors. Això és compatible amb Symfony amb processadors de variables d'entorn (env (file: your_secret_file)).

Aquesta idea de mantenir l’estat d’una aplicació lluny del seu codi es converteix en estàndard. Els conceptes que s'enumeren aquí són només la punta de l'iceberg: consulteu l'aplicació Twelve Factor i les versions reproductibles per obtenir més informació.

Hi ha alguna cosa més que vulgueu afegir a aquest article? No dubteu a deixar un comentari!