Deploy con OpenShip: dove gira l’app e cosa verificare

Scritto da

OpenShip può gestire il deploy su un server che controlli. La distinzione fondamentale è tra la dashboard che avvia il rilascio e la macchina che esegue l’applicazione pubblica.

Pubblicato il

Deploy con OpenShip: dove gira l’app e cosa verificare

Aggiornato

Chiudere l’app desktop ferma il sito?

Nel modello di deploy tramite SSH, il pannello desktop si collega a un server remoto. L’applicazione gira su quel server. Chiudere la dashboard locale è diverso da fermare i container remoti. Il README attuale di OpenShip distingue l’uso desktop da un pannello sempre attivo per accesso del gruppo e deploy automatici.

Questo conta nella diagnosi. Una connessione SSH riuscita dimostra l’accesso di gestione. Non dimostra che i visitatori raggiungano HTTPS, che il DNS punti all’indirizzo giusto o che tutti i servizi collegati funzionino.

Dal codice all’app pubblica
Il deploy porta il codice sul server e collega il dominio pubblico all’applicazione avviata.

Segui una richiesta attraverso il sistema

In un sito con più servizi, il browser raggiunge il proxy pubblico. Il proxy instrada il dominio verso il servizio web, che può interrogare un’API. L’API legge database e archivio degli oggetti. Ogni passaggio ha una configurazione propria.

OpenShip documenta le applicazioni Compose e il suo edge. Controlla la guida della versione installata. Se un proxy occupa già le porte pubbliche 80 e 443, un secondo proxy non deve provare a usare le stesse porte sull’host. HTTP interno dietro un proxy che termina TLS può essere una scelta corretta.

Verifiche che trovano problemi concreti

Verifica Prova da raccogliere
Versione del codice Il commit distribuito coincide con quello verificato
Configurazione di build Gli URL pubblici non sono rimasti su localhost
Configurazione runtime API, database e storage sono raggiungibili nella rete interna
Percorso pubblico Il dominio reale restituisce la pagina prevista in HTTPS
Persistenza Dati e caricamenti sopravvivono al riavvio del servizio
Ripristino Un backup è recuperabile e la versione precedente è nota

Prova un flusso completo. Pubblica una bozza nell’ambiente di test, aprila attraverso il dominio e verifica un’immagine caricata. La sola lettura della home non dimostra che le scritture funzionino.

Variabili di build e runtime

La build del frontend può incorporare un valore prima dell’avvio del container. Una variabile impostata dopo non cambia il testo già compilato. Il codice server può invece leggere la configurazione durante le richieste. Documenta quale meccanismo gestisce dominio canonico e indirizzo API, poi controlla l’HTML restituito.

Cosa resta a tuo carico?

La piattaforma riduce le configurazioni ripetitive. Impostazioni dell’app, permessi, backup e verifica dei rilasci restano responsabilità operative. Prima di migrare, leggi la guida a backup e ripristino e prova la procedura su dati eliminabili.

Per un’applicazione concreta in Astro e Rust, vedi Wegweiser Leben. Per un nuovo progetto, scopri lo sviluppo di applicazioni web.

Parliamone

Raccontami cosa hai in mente. Rispondo di solito entro un giorno lavorativo.