Come fare il self-hosting di IT Tools nel 2026: TLS, deploy stateless e aggiornamenti

Il self-hosting di IT Tools diventa interessante al primo redeploy, non al primo docker run. Se il proxy punta alla porta del container sbagliata o memorizza nella cache una vecchia application shell, Docker può comunque segnalare un processo perfettamente funzionante. Il deploy descritto di seguito è organizzato intorno a comportamenti osservabili: caricare l'interfaccia, generare un hash, decodificare un JWT e usare un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset.

Lo scopo di IT Tools è chiaro: raccolta di hash, converter, generatori e utility per sviluppatori. Questa descrizione ci indica cosa deve rimanere pubblico, cosa dovrebbe restare privato e cosa deve poter ricostruire un backup.

Separare IT Tools dalle sue dipendenze

Inizia dal namespace di rete di IT Tools: il suo web listener usa la porta 80, non una porta dell'host copiata da un tutorial per laptop. La build standard di IT Tools non richiede un database né un servizio runtime persistente separato. Mantieni il web container sostituibile e colloca qualsiasi futuro componente di autenticazione, collaborazione o storage dietro un confine documentato separatamente.

Dopo aver soddisfatto il requisito, esegui lo scenario completo — carica l'interfaccia, genera un hash, decodifica un JWT e usa un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset. Registra log e misurazioni relativi alla memoria del browser client, alla distribuzione degli asset statici e all'assenza di attività lato server su database o code. Queste evidenze diventano la prima architettura verificata e rendono testabili i successivi spostamenti tra il compute di Dockup e un server collegato.

Creare un container IT Tools sostituibile

Un comando minimale è utile quando mostra cosa gestirà in seguito la piattaforma.

docker run -d \
  --name it-tools \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  corentinth/it-tools:latest

In questo modo la porta 80 resta privata sull'host e ogni percorso richiesto è esplicito. Verifica il requisito locale prima dell'esposizione: nessun database, solo un piccolo web container. Verifica l'avvio sia con i log sia con la prova specifica dell'applicazione: carica l'interfaccia, genera un hash, decodifica un JWT e usa un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset. Dopo la verifica, fissa la versione dell'immagine affinché una sostituzione ordinaria non modifichi il comportamento senza avvisare.

Il TLS è semplice; gli URL generati no

Il confine pubblico di IT Tools dovrebbe essere costituito da un unico hostname canonico, TLS automatico e un unico target interno sulla porta 80. Instrada la web application statica tramite HTTPS, così i client tornano a un indirizzo riconosciuto dal servizio.

Se la transazione di accettazione fallisce, classifica il primo errore. I problemi di DNS, certificato e 502 appartengono alla checklist di validazione TLS. La condizione “il proxy punta alla porta del container sbagliata o memorizza nella cache una vecchia application shell” appartiene al lato applicativo, dopo che una richiesta ha raggiunto IT Tools correttamente.

I volumi sono solo il primo livello di ripristino

Il ripristino di IT Tools, essendo stateless, è un esercizio di riproducibilità. Non conservare dati sul server; mantieni la configurazione del deploy; il layer scrivibile del container non deve contenere nulla di necessario dopo una sostituzione.

Usa l'immagine fissata e la configurazione revisionata per ricreare IT Tools su un compute vuoto. La simulazione ha esito positivo quando un container nuovo riproduce lo stesso set di strumenti, perché non c'è stato utente lato server da recuperare. Segui il workflow di deploy da Git alla produzione per l'artefatto sostituibile, mentre qualsiasi servizio esterno opzionale deve avere una procedura di backup separata.

Documenta il digest esatto e l'input usato per l'accettazione. In questo modo un operatore può distinguere una regressione dell'applicazione da uno stato mancante ed evitare di collegare un volume puramente formale che IT Tools non legge mai.

Chiudere gli accessi temporanei di configurazione

La sicurezza di IT Tools, essendo stateless, inizia dai controlli sulla supply chain e sull'ingress, non da un'impostazione teorica dell'account. Evita di presumere che gli strumenti lato browser rendano sicure le informazioni incollate su un host non affidabile. Il confine previsto consiste nel servire un'immagine upstream attendibile e ricordare agli utenti che il self-hosting non rende affidabile un browser compromesso.

Servi IT Tools da un'immagine attendibile e fissata, aggiungi l'autenticazione della piattaforma se il pubblico è privato ed esponi solo la porta 80 tramite HTTPS. Imposta limiti per le risorse e le richieste tenendo conto della memoria del browser client, della distribuzione degli asset statici e dell'assenza di attività lato server su database o code. Poiché questa configurazione di base non contiene segreti integrati, mantieni la policy di accesso nella configurazione della route e testala da un client non autorizzato.

Provare in anticipo la modifica rischiosa di IT Tools

Monitora il comportamento, non solo il processo: carica l'interfaccia, genera un hash, decodifica un JWT e usa un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset. I segnali di pressione da osservare sono la memoria del browser client, la distribuzione degli asset statici e l'assenza di attività lato server su database o code. Esegui questo controllo dopo l'avvio e secondo una pianificazione che non possa sovraccaricare il servizio.

Un aggiornamento può essere promosso solo dopo aver verificato che un aggiornamento dell'immagine possa modificare gli algoritmi o le dipendenze lato client; perciò, fissa e verifica la build che gestisce input sensibili. Usa un candidato parallelo, digest fissati e input noti; questa immagine di base non prevede migrazioni dello schema da provare. Se il proxy punta alla porta del container sbagliata o memorizza nella cache una vecchia application shell, confronta le due versioni prima di modificare l'ingress o aggiungere storage.

Registrare un deploy IT Tools verificato

Non usare il traffico dei primi utenti come test di accettazione per IT Tools. Prepara uno stato di esempio innocuo ed esegui l'azione completa “carica l'interfaccia, genera un hash, decodifica un JWT e usa un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset”. Prendi nota dell'URL pubblico esatto, del risultato, del riferimento all'immagine e dell'intervallo di log associati all'esecuzione.

Sostituisci il container e ripeti senza ricostruire i dati. Poi esegui il ripristino su un host vuoto; la condizione di ripristino è che un container nuovo riproduca lo stesso set di strumenti, perché non c'è stato utente lato server da recuperare. In ogni esecuzione osserva la memoria del browser client, la distribuzione degli asset statici e l'assenza di attività lato server su database o code, quindi definisci un alert sul degrado della transazione anziché sulle metriche del container inattivo.

Un controllo finale dovrebbe fallire intenzionalmente: invia un input innocuo vicino al limite di risorse o formato associato a questo confine: il proxy punta alla porta del container sbagliata o memorizza nella cache una vecchia application shell. Verifica che il messaggio risultante di IT Tools identifichi il confine rilevante invece di attivare la cancellazione dei dati o un riavvio infinito. Ripristina la condizione valida e conferma che la stessa transazione di esempio abbia esito positivo. Mantieni questa breve esercitazione nella checklist di release.

Anche un deploy Dockup richiede un test di accettazione di IT Tools

Dockup può eseguire il deploy dell'immagine IT Tools fissata sul compute di Dockup o su un server collegato dal cliente, instradare l'hostname pubblico verso la porta 80 ed emettere automaticamente il TLS. Il container standard non ha un database applicativo, quindi Dockup non dovrebbe collegare un volume dati privo di significato solo per imitare un template stateful.

Dopo il deploy, instrada la web application statica tramite HTTPS. Dockup dovrebbe preservare le impostazioni runtime di IT Tools mentre l'operatore conferma questo requisito locale: nessun database, solo un piccolo web container. Esegui il controllo dell'output noto: carica l'interfaccia, genera un hash, decodifica un JWT e usa un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset. Se in seguito vengono aggiunti font personalizzati, autenticazione, collaborazione o configurazione, dichiara esplicitamente questi componenti e il loro stato invece di incorporarli nell'immagine web stateless. In questo modo il deploy one-click rimane trasparente su ciò che Dockup gestisce e su ciò che IT Tools memorizza realmente.

Domande frequenti

Cosa serve a IT Tools per un deploy in produzione?

Instrada il container IT Tools sulla porta 80 attraverso un'unica origin HTTPS. La build standard di IT Tools non richiede un database né un servizio runtime persistente separato. Non considerare IT Tools pronto finché non puoi caricare l'interfaccia, generare un hash, decodificare un JWT e usare un converter dopo aver disconnesso il browser dalla rete, una volta memorizzati nella cache gli asset.

Quali dati di IT Tools devono rientrare in un backup?

L'immagine standard di IT Tools non ha un mount obbligatorio per i dati applicativi. Conserva la configurazione del deploy ed esegui separatamente il backup di qualsiasi stato collegato; il ripristino ha esito positivo quando un container nuovo riproduce lo stesso set di strumenti, perché non c'è stato utente lato server da recuperare.

IT Tools richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origin pubblico di IT Tools e mantieni la porta 80 nella route interna. Applica correttamente l'impostazione di IT Tools: instrada la web application statica tramite HTTPS. Per IT Tools, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento client sensibile all'origin.

Come si deve testare un aggiornamento di IT Tools?

Esegui il deploy dell'immagine candidata di IT Tools accanto a quella attuale e ripeti la transazione di accettazione con un input noto. Presta particolare attenzione perché un aggiornamento dell'immagine può modificare gli algoritmi o le dipendenze lato client; perciò, fissa e verifica la build che gestisce input sensibili. Il container standard non prevede migrazioni dei dati, quindi conserva il digest precedente finché i controlli sull'output e sulla compatibilità non hanno esito positivo.