Evolutie van een applicatie: Symfony and Cloud Integration

In het landschap van softwareontwikkeling is het essentieel om actueel te blijven met technologiestacks.

Mijn recente project betrof het moderniseren van een verouderde applicatie van een oudere versie van Symfony naar Symfony 7. Ik heb ook een deployment pipeline gemaakt om Continuous Delivery te vergemakkelijken als onderdeel van de overgang naar de AWS cloudomgeving.

De Symfony upgrade
Upgraden naar Symfony 7 was een relatief soepel proces, hoewel het enige inspanning vereiste.

Ik heb verschillende belangrijke veranderingen aangebracht in de applicatie om deze naar de cloud over te zetten:

• Ik heb de opslag van assets en afbeeldingsuploads overgezet naar een externe dienst, specifiek Amazon S3.
• Ik heb de applicatie geconfigureerd voor volledige containerisatie, met afzonderlijke containers voor de webserver, applicatieserver en werker om modulariteit en schaalbaarheid te waarborgen.
• Om de efficiëntie te verhogen, heb ik een gecontaineriseerde proxy ingesteld die de mediastroom van het opslagsysteem naar het web beheert, met dynamische beeldresizen en cachingfunctionaliteiten.

Cloud migratie naar AWS

Platform keuze
Na het beoordelen van zowel de vereisten als het budget, heb ik AWS LightSail gekozen als hostingoplossing. AWS biedt kosteneffectieve instanties die een aanzienlijke hoeveelheid bandbreedte bevatten, wat voldeed aan onze behoeften. Bovendien biedt LightSail een beheerde databaseservice.

Momenteel biedt het combineren van EC2 met RDS of het gebruik van Elastic Beanstalk geen opmerkelijke voordelen in vergelijking met LightSail voor onze doeleinden. Hoewel ECS zijn verdiensten heeft, rechtvaardigt de verhoogde kostprijs de overstap in dit stadium niet. Overstappen van LightSail naar EC2 zou ongecompliceerd zijn, en verhuizen naar ECS zou relatief eenvoudig kunnen zijn, zeker gezien de deployment pipelines die al voor dit project zijn opgezet.

Continuous delivery met deployment pipelines

De highlight van dit project was het ontwikkelen van de deployment pipelines met behulp van AWS CodePipeline.

De strategie voor de implementatiepijpleiding omvatte het creëren van Docker-images die zelfvoorzienend zijn en geïmplementeerd kunnen worden op elk doelwit dat is uitgerust met een container orkestratie service.

Deze opzet is ontworpen om compatibel te zijn met verschillende systemen, of het nu Docker Compose, Docker Stack, externe servers, ECS, Kubernetes of vergelijkbare omgevingen betreft.

Ik heb twee afzonderlijke pipelines ontwikkeld: de eerste voor het creëren van base image, die uniformiteit en herhaalbaarheid leveren over ontwikkelings-, test- en productiestadia; de tweede pipeline was voor het 'builden' van de applicatie, resulterend in een volledig zelfstandige en uitvoerbare image.

Hoewel de images al geschikt zijn om direct op ECS uit te rollen, was het doel om ze op externe (LightSail) servers te plaatsen.

Hiervoor hebben we een lambda-functie gecreëerd die wordt uitgevoerd in de build-fase, die een 'deploy' script voor Docker stack op het implementatiedoelwit activeert.

Zoals ik heb geleerd in mijn AWS DevOps-training, is de Parameter Store ideaal voor het centraliseren van applicatieconfiguraties.

In dit project bleek de Parameter Store zeer waardevol:

• Ik gebruikte het om het versienummer van de base Docker-images tijdens het bouwproces op te slaan, wat hardcoding voorkomt en terugdraaien vereenvoudigt.
• In de 'build stage' worden de benodigde gegevens opgehaald uit de Parameter Store, inclusief de versie van de base image en diverse applicatieconfiguratieparameters.
• Een lichtgewicht 'agent'-applicatie op het implementatiedoelwit raadpleegt de Parameter Store om te bepalen welke images te gebruiken in een deploy, en om extra applicatie- en implementatieconfiguraties op te halen.

In wezen fungeert de Parameter Store als een centrale opslagplaats voor te gebruiken versies van applicatie componenten, en configuratiebestanden voor de omgeving.

CDN Gateway
Ik heb ook een 'cdn gateway' geïntegreerd in LightSail, waarmee een bestaande dienst die voornamelijk werd gebruikt voor het schalen van afbeeldingen, is verbeterd.

Deze opstelling verandert de manier waarop assets worden geleverd. In plaats van direct van S3 te bedienen of via S3 gecombineerd met CloudFlare of CloudFront, bemiddelt de gateway de levering.

De CDN-gateway fungeert als een forward proxy en introduceert verschillende verbeteringen:

• SSL-terminatie
• Gebruikt Nginx voor caching, waardoor de levering van content wordt geoptimaliseerd.
• Past Nginx toe voor on-demand beeldresizen, of andere middleware indien nodig.
• Implementeert rate limiting om resize-operaties te beheren en overbelasting te voorkomen.
• Leidt content naar verschillende opslaglocaties op basis van vooraf gedefinieerde regels.

In wezen scheidt deze gateway de levering en het resizen van assets van de hoofdapplicatie en het opslagsysteem, waardoor de levering van assets wordt beheerd en systeemstress op meerdere punten wordt voorkomen.

Met deze post wil ik inzicht geven in de strategieën en gedachten achter mijn DevOps-projecten. Het laat mijn inzet zien om de DevOps best practices te volgen en up-to-date te blijven met technologische vooruitgang.

• AWS CodePipeline
• AWS Lambda
• AWS ECR
• GitLab CI
• Docker multiplatform build
• Docker stack/swarm
• Nginx
• Symfony