Per oltre un decennio Bitnami è stato la risposta predefinita a «mi serve un WordPress su AWS per ieri». Impacchettava mezza internet —AMI, container e chart— con tutto configurato e pronto ad avviarsi in due clic. Se hai toccato infrastruttura negli ultimi dieci anni, quasi certamente ne hai lanciata una.
Quel catalogo gratuito non è più mantenuto. Dopo il passaggio a Broadcom, le immagini sono state spostate in un repository legacy che non riceve aggiornamenti e le AMI sono state ritirate dall’AWS Marketplace. Non c’è una versione nuova da lanciare, né qualcuno a cui aprire un ticket.
Il problema non è il giorno in cui smettono di pubblicare
È quello dopo. La tua istanza continua ad avviarsi esattamente come ieri: stessi servizi, stessi percorsi, stesse prestazioni. Non si rompe nulla, ed è proprio questa la trappola. Ciò che cambia è invisibile dall’esterno.
Da quel momento, ogni CVE pubblicata contro il sistema base o contro il software che contiene resta aperta sulla tua macchina. Non c’è un’immagine aggiornata da rilanciare, non c’è avviso, non c’è chi risponda. Il debito si accumula in silenzio finché qualcuno lo trova: un audit, un cliente che chiede l’inventario delle vulnerabilità, o qualcosa di peggio.
E rifare l’immagine a mano non è banale. Una AMI di Bitnami non è «il pacchetto installato»: è un albero di directory proprio, script di avvio, servizi collegati in un modo preciso e un mucchio di decisioni prese anni fa che la tua applicazione dà per scontate.
Cosa abbiamo fatto
Pubblicare sostituti che manteniamo davvero. L’idea è noiosa di proposito: stessa architettura, stessi percorsi, stessi servizi, così migrare non è un progetto ma un pomeriggio.
- Patch periodiche. Ogni revisione dell’immagine incorpora gli aggiornamenti di sicurezza del sistema base e del software che contiene.
- Audit di sicurezza. Scansione delle vulnerabilità e verifica dell’hardening CIS su ogni immagine pubblicata, con il relativo report.
- Supporto umano. I ticket arrivano al team che costruisce le immagini.
Il catalogo cresce in base a ciò che chiedono i team che migrano, e ogni AMI disponibile è nella mappa dei sostituti accanto allo stack Bitnami che rimpiazza.
Come si migra
Nella maggior parte dei casi sono tre passi, senza riscrivere nulla:
- Lancia il sostituto dall’AWS Marketplace, nella stessa regione e con lo stesso tipo di istanza che avevi.
- Migra i tuoi dati: ripristina il dump o monta il volume dati. Percorsi e servizi coincidono con quelli di Bitnami.
- Sposta l’IP elastico sulla nuova istanza. I tuoi clienti non se ne accorgono.
Se il tuo stack non è ancora nella mappa, scrivici. Diamo priorità ai nuovi sostituti in base a ciò che ci chiedono di più, e sapere che qualcuno ne ha bisogno è esattamente ciò che muove la lista.
