Categoria: Web i aplicacions
Aplicacions PHP amb Laravel o Symfony: desplegament, cues i servidor gestionats
El vostre equip escriu el codi; nosaltres ens ocupem que arribe a producció sense talls, que les cues no es queden parades i que el servidor aguante el dia que més trànsit teniu.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- Open source: Laravel i Symfony, MIT
En resum
Laravel i Symfony són els dos marcs de treball de PHP més utilitzats per a aplicacions web i API. Preparem el servidor o els contenidors al vostre compte, muntem desplegaments automàtics des de Git sense tall de servei, mantenim vius els workers de cues i el scheduler, ajustem PHP-FPM i OPcache, i vigilem errors, cues i temps de resposta. El codi continua sent del vostre equip.
Què ens encarreguem de mantindre?
Una aplicació de Laravel o Symfony en producció és més que la web: hi ha workers processant cues, tasques programades, una base de dades, sovint Redis i una configuració de PHP que ningú no revisa des que es va instal·lar. Això és el que deixem sota control:
Desplegaments
Des de Git, sense tall, amb migracions i memòries cau generades i tornada arrere immediata.
Cues
Workers supervisats amb Supervisor o systemd, o Horizon; reinici ordenat i treballs fallits a la vista.
Scheduler
Tasques programades que s’executen una vegada, a la seua hora, encara que hi haja diversos servidors.
PHP-FPM i OPcache
Processos, memòria i versió de PHP ajustats a la vostra aplicació i al vostre trànsit.
Dades
MySQL, MariaDB o PostgreSQL, i Redis o Valkey, amb còpies fora i restauració provada.
Monitoratge
Errors, cues que creixen, workers caiguts, temps de resposta, disc i certificats.
Com és un desplegament?
Seguim el model de versions en carpetes que fan servir eines com Deployer, o una imatge de contenidor nova per versió si l’aplicació ja va en contenidors:
Preparar
Es descarrega el codi de l’etiqueta o branca, s’instal·len les dependències amb Composer sense les de desenvolupament i es compilen els recursos del frontal.
Optimitzar
Es generen les memòries cau de configuració, rutes i vistes en Laravel, o la memòria cau del contenidor en Symfony.
Migrar
S’executen les migracions de base de dades, amb una còpia prèvia si toquen taules grans.
Activar
L’enllaç de la versió activa canvia, PHP-FPM es recarrega per a netejar OPcache i els workers es reinicien.
Les variables d’entorn i els secrets viuen fora del repositori, al servidor o al gestor de secrets del proveïdor. Si voleu muntar tot el circuit d’integració contínua, ho tractem en infraestructura com a codi, GitOps i CI/CD.
Quins problemes trobem més sovint?
- Workers amb codi vell: es desplega una versió nova, però els processos de cues continuen amb l’anterior en memòria.
- Scheduler duplicat: diversos servidors executen la mateixa tasca programada alhora.
- Cues que creixen en silenci: els processos estan vius, però no donen l’abast i ningú no mira la mida de la cua.
- PHP fora de suport: l’aplicació continua en una versió de PHP sense pegats de seguretat.
- Mode de depuració activat en producció: errors amb rutes, variables i consultes visibles per a qualsevol.
- Desplegament a mà per SSH: un git pull al servidor i una memòria cau sense regenerar.
Com tractem les cues i el scheduler?
En Laravel, cada connexió de cues té els seus workers amb un límit de temps i de memòria per treball; si feu servir Redis, Horizon dona un tauler amb l’estat de cada cua i el deixem protegit. En Symfony, els consumidors de Messenger funcionen igual, supervisats i amb un nombre màxim de missatges abans de reiniciar-se per a no acumular memòria. El scheduler es llança des del cron del sistema o com a procés propi, i si hi ha diversos servidors ens assegurem que cada tasca s’execute només en un. Quan la missatgeria creix fins a necessitar un broker propi, el muntem com en RabbitMQ gestionat.
Com fem còpies i actualitzacions de PHP?
La base de dades es copia amb el mètode que corresponga al seu motor, i els arxius pujats pels usuaris, si no són ja en un emmagatzematge d’objectes, també ixen fora del servidor. Restaurem de prova amb regularitat. Per a canviar de versió de PHP preparem un entorn amb la versió nova, el vostre equip hi passa les seues proves i revisem els avisos de funcions obsoletes; després canviem producció servidor a servidor. Les versions de pegats de PHP i del sistema operatiu s’apliquen tan bon punt ixen. Si la base de dades necessita rèpliques o recuperació a un minut concret, la portem com en PostgreSQL gestionat o MySQL i MariaDB gestionats.
Contenidors o servidors?
Les dues opcions funcionen. Els servidors amb Nginx i PHP-FPM són el més senzill d’operar per a una aplicació amb trànsit estable. Els contenidors tenen sentit si ja els feu servir en desenvolupament, si voleu el mateix entorn a tot arreu o si penseu escalar la part web per separat dels workers. Si preferiu un tauler on el vostre equip desplegue tot sol, encaixa amb Coolify i Dokploy gestionats. Si voleu que algú responga de l’aplicació en producció cada mes, és en el SRE com a servei.
- GitPush o etiqueta
- NginxHTTPS
- PHP-FPMLaravel o Symfony
- WorkersCues i scheduler
- Bases de dadesMySQL o PostgreSQL, i Redis
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Servidors cloud amb Nginx i PHP-FPM, un servidor a part per a workers quan la càrrega ho demana i còpies en Object Storage de Hetzner. | Hetzner no ofereix base de dades gestionada: la muntem i la cuidem nosaltres. |
| AWS | EC2 o contenidors en ECS, amb RDS, ElastiCache per a Redis o Valkey i SQS si les vostres cues ja el fan servir. | |
| Google Cloud | Compute Engine o Cloud Run per a la part web, Cloud SQL i Memorystore. | A Cloud Run els workers de cues llargues necessiten un altre lloc; ho plantegem abans. |
| Azure | Màquines virtuals o App Service, amb Azure Database for MySQL o PostgreSQL. | |
| DigitalOcean | Droplets amb PHP-FPM i bases de dades gestionades de DigitalOcean. | |
| OVH | Instàncies de Public Cloud i bases de dades gestionades d'OVHcloud. | |
| Servidor propi | L'aplicació en els vostres servidors o màquines virtuals, amb el mateix sistema de desplegament. |
Què inclou
- Servidors o contenidors amb Nginx, PHP-FPM i la versió de PHP que demane la vostra aplicació, al vostre compte.
- Desplegament automàtic des de Git amb versions en carpetes separades i tornada arrere en segons.
- Migracions de base de dades dins del desplegament, amb còpia prèvia quan toquen taules grans.
- Workers de cues supervisats amb Supervisor o systemd, reiniciats a cada desplegament, o Laravel Horizon si feu servir Redis.
- Scheduler de Laravel o Symfony executat una sola vegada per minut, encara que hi haja diversos servidors.
- PHP-FPM i OPcache dimensionats segons memòria i trànsit, amb la memòria cau de configuració i rutes generada en el desplegament.
- Còpies de base de dades i d'arxius pujats fora del servidor, amb restauració de prova.
- Monitoratge d'errors, cues encallades, workers caiguts, temps de resposta i disc, amb alertes.
Preguntes freqüents
Hi ha tall de servei a cada desplegament?
No n'hi hauria d'haver. Cada versió es prepara en la seua pròpia carpeta: s'instal·len les dependències, es generen les memòries cau i, quan tot està a punt, l'enllaç de la versió activa canvia de colp. Si alguna cosa falla, es torna a l'anterior canviant l'enllaç una altra vegada. L'única cosa que pot demanar una finestra és una migració que bloquege una taula gran, i això ho veiem abans.
Què passa si un worker de cues es queda penjat?
Supervisor o systemd el tornen a arrancar si el procés mor, i els workers es reinicien de manera ordenada després de cada desplegament perquè no continuen amb el codi vell. A més vigilem la mida de les cues i els treballs fallits: si la cua creix sense baixar, salta una alerta encara que els processos semblen vius.
Laravel Forge, Vapor o el nostre propi servidor?
Forge prepara servidors i Vapor porta Laravel a funcions d'AWS; tots dos són bons si encaixen amb vosaltres. Muntem l'aplicació sense ells quan voleu una configuració descrita al vostre repositori, un altre proveïdor com Hetzner, o algú que a més vigile i responga. Si ja feu servir Forge, podem treballar sobre els servidors que gestiona.
Escriviu o corregiu el codi de l'aplicació?
No és el que fem. Si un error ve del codi, us el lliurem amb el registre, la petició que el provoca i el que hem vist al servidor, perquè el vostre equip l'arregle ràpidament. Sí que ens encarreguem de tot el que envolta el codi: versions de PHP, extensions, configuració, desplegament i infraestructura.
Gestioneu també altres aplicacions PHP?
Sí, amb el mateix enfocament: CodeIgniter, Slim, aplicacions sense marc de treball o versions antigues que cal portar a un PHP amb suport. Per a WordPress i WooCommerce tenim una pàgina pròpia.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
Revisat el