Sono artefatti di finestra mobile quando si esegue un contenitore memorizzato nell'host fs o nella memoria?

Question

Contesto

scrivo rotaie applicazioni, facendo page caching dei frammenti sulla produzione (memorizzare il risultato html di un frammento specifico al fine di evitare di ricalcolare esso).

Il modo normale per eseguire questa operazione è archiviare il frammento in memcache o redis. L'opzione di memorizzazione cache predefinita nei binari consiste nell'utilizzare il caching di FS (memorizzazione del frammento come file), poiché ha il vantaggio di non avere dipendenze (non è necessario configurare memcache o redis). Si tratta di un'opzione meno diffusa, tuttavia, poiché è più lenta della memorizzazione nella cache e si deve pulire manualmente la cache, mentre si può fare affidamento su chiavi più vecchie per essere eliminate automaticamente utilizzando memcache o redis adeguatamente configurati.

Domanda

Dopo aver utilizzato finestra mobile per un po ', mi rendo conto che l'eliminazione dei file di cache precedenti non è più un problema: il deploy, un nuovo contenitore è stato eseguito, lasciando cadere automaticamente tutti i file di cache precedenti. Questo è probabilmente più lento rispetto all'utilizzo della memoria, sicuramente, ma questo ha il vantaggio di non richiedere alcuna configurazione, il che è abbastanza interessante quando si esegue il boot di progetti rapidi.

Ma poi mi chiedo: sta scrivendo in un contenitore fs davvero scrivendo in fs, o è scritto nella RAM, invece? Questa è una preoccupazione, perché ciò significherebbe fare affidamento su questo potrebbe saturare molto rapidamente la RAM, specialmente con molti progetti sullo stesso server che lo fanno.

Answer 1

Il caso qui è che Docker sta facendo tutto ciò che sta facendo il processo. Docker è solo un modo elegante per eseguire un processo, non una VM tradizionale. Probabilmente lo sai, ma sto solo ribadendo per gettare le basi della mia risposta. Docker obbedisce a ciò che il tuo processo vuole fare. Se si specifica che si desidera che il processo utilizzi una cache del file system sul disco e tale processo scriva sulla cache, Docker non memorizzerà quel risultato in memoria. Scriverà nella cache sul disco. Hai ragione sul fatto che i contenitori effimeri abbiano vantaggi come quelli che dici qui, con la cache dei file che viene ripulita quando fai girare un nuovo contenitore.

Quando il processo scrive su disco, Docker scrive sul suo speciale UnionFS (che può usare uno dei pochi backend di memorizzazione, come aufs o btrfs, ci sono diverse scelte). Docker utilizza questo filesystem "speciale" per due motivi: per evitare la duplicazione dei file dalla stessa immagine di base e per isolare le modifiche al file system specifiche del processo dai livelli condivisi dell'immagine di base. Il termine specifico per il meccanismo è copy-on-write. Il punto è che quando Docker dice che sta scrivendo sul filesystem, questo è ciò che sta facendo Docker. Non sta scrivendo cose in memoria e agendo come se le cose fossero scritte sul filesystem: in realtà sta scrivendo le cose su disco. L'argomento dei driver di archiviazione è profondo e complesso, ma lo documentation per questa roba è ben scritto e accurato, come nel caso di tutta la documentazione Docker in generale. Siate certi che non vi è alcuna magia in esecuzione il processo. Puoi tranquillamente supporre che Docker stia facendo ciò che dice.