Best practice per la versione del nodo immagine Docker e .nvmrc

Question

Best practice per la versione del nodo immagine Docker e .nvmrc

#1 da (1 voti)

2

Se sto costruendo microservizi usando le immagini di Node on Docker, è necessario avere un'idea di quale versione di Node sto usando.

L'idea è - ho intenzione di eseguire il nodo localmente in fase di sviluppo - e quindi deve ancora funzionare quando è in esecuzione su un container.

Se il mio Dockerfile ha questo aspetto:

FROM node:10.10-alpine

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies
# A wildcard is used to ensure both package.json AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./

RUN npm install
# If you are building your code for production
# RUN npm install --only=production

# Bundle app source
COPY . .

EXPOSE 3001
CMD [ "npm", "start" ]

Questo va bene - tranne il mio ambiente locale non sa quale versione del nodo sto usando.

Ora potrei semplicemente mettere 10.10 nel mio file .nvmrc .

Ma poi devo ricordarmi di mantenere questi in sincronia. C'è un modo migliore per farlo? C'è un nodo: alpino che rispetta .nvmrc?

docker node.js

posta dwjohnston 17.09.2018 - 22:25

fonte

1 risposta

Leggi altre domande sui tag docker node.js

Microservices - Usa caso per database condiviso Come modellare le relazioni rdbms come relazioni grafiche?

score 1 · Answer 1

Il punto principale di Docker è isolare ciò che accade all'interno di un contenitore da ciò che accade all'esterno (sia che altri programmi in esecuzione, altri contenitori o in .nvmrc ). Le immagini del Docker tendono ad essere estremamente libere, contenenti solo i componenti e i dati di cui hanno bisogno, specificati esplicitamente in Dockerfile . Qualsiasi configurazione richiesta deve essere impostata in modo esplicito, ad esempio da variabili di ambiente o file di configurazione copiati. Un ambiente isolato con tutti i requisiti raggruppati / incapsulati: ecco come Docker carica i carichi di lavoro con requisiti diversi (anche molto incompatibili) in esecuzione side-by-side.

Node Version Manager deriva da una visione del mondo molto diversa. Uno che crede di avere più versioni di nodi installati, e potrebbe passare liberamente avanti e indietro tra loro. Non c'è niente di sbagliato in questo per sé , specialmente per una workstation per sviluppatori, ma è quasi ostile alla filosofia di Docker. Il numero di configurazioni Docker con versione di > 1 nodo installata sarà estremamente piccolo, e sarebbe estremamente insolito, specialmente quelle basate sul minimalista Alpine Linux o per la strategia minimalista dei microservizi.

Se è necessario passare da una versione di nodo alla stazione di sviluppo, così sia. Tuttavia, consigliamo di non tentare di mappare il flusso di lavoro / la strategia di più versioni installate nelle immagini Docker. Sarà meglio adattarsi alla forza e ti deruberà della precisione e del minimalismo che rendono Docker così ben funzionante. Invece, considera le immagini del Docker il risultato specifico e mirato del tuo processo di costruzione. Le versioni specifiche del nodo o altre risorse possono essere "masterizzate" nell'immagine come variabili di ambiente o file di configurazione se è necessario interrogare la versione corrente in fase di esecuzione. Se hai bisogno di costruire diverse varianti, ognuna con targeting per una versione di nodo separata, è abbastanza fattibile. Docker ha una ricca capacità di tagging; è comunemente usato solo per questo scopo.