iBaffiPro ha scritto:
Per caso sai se è possibile escludere dal .jar alcuni file come facevo con il .war?
Sì, basterebbe configurare il maven-jar-plugin. (non ho modo di fare una prova ora)
https://maven.apache.org/plugins/maven-jar-plugin/examples/include-exclude.html
iBaffiPro ha scritto:
Altra cosa che non ho capito bene è cosa accade nel contenitore.
In pratica quando scrivo "COPY target/prova-10.0.jar /demoapp/" Docker copia in /demoapp il file .jar e lo decomprime?
No, non decomprime nulla. COPY copia dalla tua macchina al file-system della immagine.
La tua immagine finale, quella di cui fai il run è basata su uno o più layer. Ma ciascun layer di fatto è una immagine, semplicemente è una immagine intermedia che non ha un nome esplicito ma solo il ID autogenerato.
I comandi che metti nel Dockerfile generano i layer. Il COPY genera un nuovo layer in cui dice che ci sono un tot di file (uno o più) a certe locazioni del filesystem. Nel caso del COPY sopra, il layer è composto da un singolo file (il jar) in quella locazione specifica ( /demoapp ).
Immagina che ciascun layer sia come uno di quei fogli di acetato trasparente che si usano nelle scuole. Sul foglio ci puoi scrivere sopra ma è trasparente, quindi vedi attraverso. Sul layer (il "foglio trasparente") ci sono le informazioni che descrivono ciò che c'è in più/in meno o differente sul filesystem.
Ora, immagina di prendere tutti i fogli trasparenti (i layer) e di metterli uno sopra l'altro e poi guardare dall'alto partendo dall'ultimo layer generato. Ecco, quello che vedi è il risultato finale, ovvero la tua immagine.
iBaffiPro ha scritto:
Ti faccio questa domanda perché mi sono accorto che a questa configurazione manca il volume del servizio.
Immagina di aver creato un'app simile a WordPress. Le immagini delle notizie non finiscono nel db ma sul disco dell'OS (ipotizziamo che non si voglia usare MongoDB ma solo PostgreSQL o MySQL).
Le immagini che si creano come detto prima sono
read-only, a sola lettura. Quando crei un nuovo container per eseguire l'immagine, il container è semplicemente uno strato in più ma attenzione, SCRIVIBILE. In sostanza, le applicazioni che girano nel container POSSONO scrivere sul file-system e questi dati sono persistenti. Perlomeno ... fintanto che il container non viene eliminato.
Il problema è che se devi rifare l'immagine perché c'è qualcosa da aggiornare, il container lo devi ricreare e ... perdi tutto. Per questo sono stati ideati i "volumi" in Docker. Che sono separati dai container, possono essere riutilizzabili e anche eventualmente essere condivisi tra container differenti.
Inoltre c'è la questione che il file-system del container, quello che è scrivibile, è basato su un "union filesystem" ed è quindi meno efficiente per via di questra stratificazione. Mentre i volumi scrivono direttamente sul file-system della macchina host, quindi più performante.