Quan actualitzes el runtime d'una funció Lambda, per exemple de Python 3.9 a Python 3.12 o de Node.js 16 a Node.js 18, pots trobar-te amb un error inesperat durant un cold start: /lib64/libc.so.6: version `GLIBC_2.28' not found. El missatge indica que una biblioteca nativa (com un wheel de Python o un addon .node) no es pot carregar perquè va ser enllaçada contra una versió més recent de glibc que la disponible al sistema operatiu base del runtime. El codi de la teva aplicació no ha canviat, però l'actualització del runtime modifica la capa de compatibilitat subjacent. Aquest problema no és un error en la teva lògica, sinó una discrepància entre la versió de glibc amb què es va compilar el binari i la que ofereix l'entorn d'execució.
Per entendre l'origen, cal mirar les imatges base que utilitza AWS Lambda. Els runtimes més antics, com Python 3.9 i Node.js 16.x, s'executen sobre Amazon Linux 2 (AL2), que incorpora glibc 2.26. Els runtimes més moderns, com Python 3.12 i Node.js 20.x, fan servir Amazon Linux 2023 (AL2023), que té glibc 2.34. Quan instal·les una dependència amb una extensió nativa —per exemple, cryptography, numpy, pydantic-core, grpcio o psycopg2—, el binari s'enllaça contra la glibc de la màquina on es va compilar. Si el teu pipeline de CI/CD utilitza un runner modern amb una glibc recent (com Ubuntu 22.04 amb glibc 2.35) i descarregues un wheel manylinux_2_28, aquest binari demanarà GLIBC_2.28, que no existeix a AL2. El resultat és un error en temps d'importació que només apareix quan el contenidor Lambda arrenca de zero, és a dir, en un cold start.
Aquest error es manifesta amb més freqüència durant migracions parcials de runtime. Imagina que al teu compte d'AWS tens funcions Lambda repartides entre runtimes antics i nous. Un equip actualitza el pipeline d'integració contínua per construir els paquets de dependències usant una imatge base d'AL2023 o un runner amb glibc moderna. Les funcions que encara s'executen a AL2 comencen a fallar al següent desplegament, tot i que el seu codi no hagi canviat. L'impacte pot ser greu: interrupció del servei en producció, errors difícils de depurar i pèrdua de confiança en el procés d'actualització.
La solució definitiva és completar la migració a un runtime basat en AL2023, com Python 3.12 o Node.js 20.x endavant. En fer-ho, la glibc 2.34 del nou sistema operatiu és suficient per a qualsevol wheel modern. A més, t'avances a les polítiques de deprecació d'AWS: els runtimes antics tenen dates de bloqueig programades, i mantenir funcions en ells suposa un risc de seguretat i de disponibilitat. Si per raons de compatibilitat o roadmap necessites mantenir una funció en un runtime antic temporalment, pots forçar la construcció de les dependències per a la plataforma manylinux2014_x86_64, que exigeix glibc 2.17 com a mínim. Aquest binari funcionarà tant a AL2 (glibc 2.26) com a AL2023 (glibc 2.34). Per exemple, fent servir pip install --platform manylinux2014_x86_64 --only-binary=:all: --target ./package . També pots construir dins la imatge base exacta del runtime Lambda mitjançant Docker: docker run --rm -v '$PWD':/var/task public.ecr.aws/lambda/python:3.9 pip install -r requirements.txt -t /var/task/package. Aquest mètode garanteix que els binaris s'enllacin contra la mateixa glibc que tindran en producció.
No oblidis verificar l'arquitectura del processador. Les funcions Lambda poden executar-se en x86_64 o arm64 (Graviton). Un binari compilat per a l'arquitectura incorrecta generarà un error diferent però igualment opac. Assegura't que el teu pipeline utilitzi la plataforma i arquitectura adequades: manylinux2014_aarch64 per a arm64, per exemple. En entorns empresarials on es gestionen desenes o centenars de funcions Lambda, detectar aquests problemes abans que arribin a producció és crític. Una pràctica recomanada és realitzar proves de cold start local utilitzant la mateixa imatge base que desplegues: docker run public.ecr.aws/lambda/ .... També pots auditar les teves funcions buscant dependències natives que puguin generar conflictes de glibc. Eines d'anàlisi de riscos al núvol, com les que oferim a Q2BSTUDIO, poden escanejar el teu compte d'AWS en segons per identificar funcions amb runtimes obsolets i possibles incompatibilitats ABI.
A Q2BSTUDIO som una empresa de desenvolupament de programari i tecnologia especialitzada en el núvol d'AWS i Azure. Ajudem les nostres empreses clients a migrar les seves arquitectures serverless de manera segura, evitant aquest tipus d'errors mitjançant bones pràctiques de construcció i desplegament. El nostre equip integra aplicacions a mida amb un enfocament cloud-native, utilitzant intel·ligència artificial per automatitzar la detecció d'anomalies i agents d'IA que monitoritzen la salut de les teves funcions Lambda. A més, combinem aquestes capacitats amb serveis de ciberseguretat per protegir els teus entorns serverless, i amb solucions cloud a AWS i Azure que garanteixen que cada desplegament compleixi els requisits de compatibilitat i rendiment. També oferim consultoria en Business Intelligence amb Power BI per analitzar els logs de Lambda i anticipar incidents com l'error GLIBC 2.28. Els nostres agents d'IA poden fins i tot suggerir automàticament la versió de runtime més adequada per a cada funció basant-se en el seu arbre de dependències.
Si estàs enmig d'una migració de runtime i et trobes amb aquest error, recorda que no és un problema de codi, sinó d'entorn. La solució més neta és finalitzar la migració a AL2023. Si necessites un pedaç temporal, construeix les teves dependències amb manylinux2014 o dins la imatge base correcta. I per evitar sorpreses, automatitza les proves de cold start i l'auditoria de compatibilitat. A Q2BSTUDIO t'acompanyem en tot el procés, des de l'anàlisi inicial fins a la implantació d'un pipeline de CI/CD robust que gestioni automàticament les versions de glibc i les arquitectures. No deixis que un error d'enllaç dinàmic aturi la teva innovació al núvol.
