Quan una empresa migra les seves funcions Lambda a un runtime més recent, el temut error '/lib64/libc.so.6: version `GLIBC_2.28' not found' sovint apareix en el pitjor moment: durant un arrencada en fred en producció, deixant sense servei a usuaris crítics. Aquest problema no és un bug al codi, sinó un desajust entre la versió de glibc amb què es va compilar alguna dependència nativa (com cryptography, numpy, pydantic-core, grpcio o un binari de Go/Rust empaquetat com a capa) i la que ofereix el sistema base del runtime de Lambda. Quan s'actualitza el runtime, les dependències solen recompilar-se amb una glibc més moderna —per exemple, la 2.34 d'Amazon Linux 2023— i si la funció segueix executant-se sobre un runtime basat en Amazon Linux 2 (glibc 2.26), l'enllaçador dinàmic no troba els símbols requerits i la funció mor en carregar-se.
L'arrel del problema és que Lambda no permet triar la versió de glibc de forma independent; va lligada al sistema operatiu base de cada runtime. Els runtimes basats en Amazon Linux 2 (python3.9 i anteriors, nodejs16.x i anteriors) utilitzen glibc 2.26, mentre que els basats en Amazon Linux 2023 (python3.12+, nodejs18.x+) incorporen glibc 2.34. Si una dependència va ser compilada en una màquina amb glibc 2.28 o superior —cosa habitual en CI moderns, imatges manylinux recents o entorns de desenvolupament basats en AL2023— al desplegar-la sobre un runtime AL2, el sistema operatiu no troba la versió requerida. glibc és compatible cap enrere, però no cap endavant: no es pot 'baixar' la versió de la llibreria sense recompilar des d'origen.
Aquest escenari és especialment freqüent durant migracions parcials: mentre alguns equips ja han mogut les seves funcions a python3.12 o nodejs22.x, altres romanen en runtimes antics. El pipeline de CI/CD, en reconstruir les dependències per a totes les funcions, pot generar artefactes que només funcionen amb la glibc més nova. El resultat: funcions que mai vam tocar comencen a fallar en la següent arrencada en fred. Per a una empresa que gestiona desenes o centenars de funcions Lambda, aquest error pot escalar ràpid i afectar la disponibilitat de serveis clau.
La solució més neta i definitiva és completar la migració del runtime: passar la funció a un runtime basat en Amazon Linux 2023 (python3.12+, nodejs20.x, nodejs22.x). D'aquesta manera, la glibc 2.34 del nou sistema satisfà qualsevol dependència moderna. A més, s'elimina el risc d'usar un runtime que ja està en procés de deprecació o bloqueig per part d'AWS. No obstant, si per raons de compatibilitat o planificació una funció ha de romandre temporalment en un runtime antic, existeixen estratègies alternatives.
Una opció és forçar la compilació de les dependències per a la plataforma manylinux2014, que té com a objectiu glibc 2.17, una versió prou antiga per funcionar tant en AL2 (2.26) com en AL2023 (2.34). Usant pip amb les opcions --platform manylinux2014_x86_64 --only-binary=:all: --target ./package s'obtenen wheels que funcionen en ambdós entorns. Una altra alternativa més segura és construir les dependències dins de la imatge base exacta del runtime Lambda que s'usarà en producció, per exemple executant docker run --rm -v '$PWD':/var/task public.ecr.aws/lambda/python:3.9 pip install -r requirements.txt -t /var/task/package. Així el binari s'enllaça contra la glibc real del runtime, eliminant qualsevol conjectura.
A més de l'aparellament de glibc, cal verificar l'arquitectura. Un binari compilat per a x86_64 no funcionarà en una funció Lambda amb arquitectura arm64 (Graviton), i viceversa. L'error serà diferent (probablement 'Exec format error' o similar), però igualment opac. Assegurar-se que la plataforma de compilació coincideixi amb la de desplegament és un pas que sovint es passa per alt.
Per evitar que aquest error arribi a producció, convé fer proves d'arrencada en fred locals usant la mateixa imatge base que es desplega. Executar docker run public.ecr.aws/lambda/ ... amb el codi i dependències empaquetats permet detectar la fallada abans de pujar-lo. També és recomanable auditar periòdicament les funcions que utilitzen runtimes deprecats, ja que el risc de desajust de glibc és només un símptoma més d'un deute tècnic major. Eines com l'escàner gratuït d'EOLkits poden identificar en segons quines funcions del teu compte tenen dependències natives en risc, sense necessitat de revisar cada paquet manualment.
A Q2BSTUDIO, com a empresa de desenvolupament de programari i tecnologia, sabem que aquest tipus d'incidents no només afecten l'operativa diària, sinó que erosionen la confiança del negoci. Per això, quan ajudem els nostres clients a migrar les seves arquitectures serverless, no només resolem l'error de glibc: revisem tot l'ecosistema de dependències, l'estratègia de cloud AWS/Azure i la maduresa dels pipelines de CI/CD. Integrem IA en els processos de monitorització per anticipar fallades abans que impactin en producció, i apliquem principis de ciberseguretat per evitar que una dependència desactualitzada es converteixi en una porta d'entrada a vulnerabilitats.
L'experiència ens ha ensenyat que el veritable cost d'un error com aquest no és només el temps d'inactivitat, sinó la necessitat de reaccionar sota pressió. Per això recomanem a les empreses que estiguin planificant la migració dels seus runtimes Lambda que ho facin de forma ordenada, usant un enfocament d'aplicacions a mida que contempli la compatibilitat de dependències des del principi. Un programari a mida ben dissenyat inclou tests d'integració que simulen l'entorn real de Lambda, no només el de desenvolupament local.
A més, la combinació d'intel·ligència artificial i automatització pot ajudar a detectar patrons d'error abans que afectin els usuaris. A Q2BSTUDIO desenvolupem agents IA que analitzen logs de CloudWatch i mètriques de Lambda per identificar funcions amb alt risc de fallada en arrencada en fred. Això s'uneix a les nostres solucions de BI/Power BI, que permeten visualitzar l'estat de salut de tota la infraestructura serverless en temps real, facilitant la presa de decisions informades.
Finalment, no oblidem que la ciberseguretat és un pilar fonamental en qualsevol estratègia cloud. Una dependència nativa mal compilada no només provoca errors de càrrega, sinó que pot exposar la funció a atacs si la versió de glibc o de la llibreria té vulnerabilitats conegudes. A Q2BSTUDIO integrem anàlisi de vulnerabilitats als nostres pipelines de CI/CD com a part dels nostres serveis de ciberseguretat, garantint que cada desplegament compleixi amb els estàndards de seguretat més exigents.
En resum, l'error GLIBC_2.28 no trobat a Lambda és un símptoma d'una migració incompleta, però també una oportunitat per millorar l'arquitectura i les pràctiques de desenvolupament. Completar la migració a runtimes basats en AL2023, construir dependències en l'entorn exacte de destinació i auditar regularment les funcions són passos clau. Si la teva empresa necessita suport tècnic per afrontar aquests desafiaments, a Q2BSTUDIO oferim consultoria i desenvolupament especialitzat en cloud, IA, ciberseguretat i automatització, ajudant a transformar problemes operatius en avantatges competitius.
