Docker è un giocattolo oppure no? O è ancora vero?

Ciao a tutti!

Voglio davvero entrare subito in argomento, ma sarebbe più corretto raccontare un po' la mia storia:

Iscrizione

Sono un programmatore con esperienza nello sviluppo di applicazioni frontend a pagina singola, scala/java e nodejs sul server.

Per molto tempo (sicuramente un paio o tre anni) sono stato dell'opinione che Docker fosse una manna dal cielo e in generale uno strumento molto interessante e assolutamente ogni sviluppatore dovrebbe essere in grado di usarlo. E da ciò ne consegue che ogni sviluppatore dovrebbe avere Docker installato sul proprio computer locale. Che dire della mia opinione, guarda i posti vacanti pubblicati sullo stesso hh. Ogni secondo contiene una menzione di docker e, se lo possiedi, questo sarà il tuo vantaggio competitivo 😉

Nel mio cammino ho incontrato tante persone, con i loro diversi atteggiamenti nei confronti di Docker e del suo ecosistema. Alcuni hanno detto che questa è una cosa conveniente che garantisce la funzionalità multipiattaforma. I secondi non capivano perché avrebbero dovuto correre in container e quale profitto ne sarebbe derivato, al terzo non importava affatto e non si è preoccupato (hanno semplicemente scritto il codice e sono tornati a casa - li invidio, dal modo :)

Ragioni per l'uso

Perché ho usato la finestra mobile? Probabilmente per i seguenti motivi:

• lancio del database, il 99% delle applicazioni li utilizza
• lancio di nginx per la distribuzione frontend e proxy al backend
• puoi impacchettare l'applicazione in un'immagine docker, in questo modo la mia applicazione funzionerà ovunque esista docker, il problema della distribuzione è risolto immediatamente
• scoperta dei servizi fuori dagli schemi, puoi creare microservizi, ogni contenitore (connesso a una rete comune) può facilmente raggiungerne un altro tramite un alias, molto conveniente
• È divertente creare un contenitore e “giocare” al suo interno.

Quello che NON mi piace sempre della finestra mobile:

• Affinché la mia applicazione funzioni, ho bisogno dello stesso Docker sul server. Perché ne ho bisogno se le mie applicazioni vengono eseguite su jre o nodejs e il relativo ambiente è già sul server?
• se voglio eseguire la mia immagine (privata) creata localmente su un server remoto, allora ho bisogno del mio repository docker, ho bisogno che il registro funzioni da qualche parte e devo anche configurare https, perché docker cli funziona solo su https. Oh cavolo... ovviamente ci sono le opzioni per salvare l'immagine localmente tramite docker save e invia semplicemente l'immagine tramite scp... Ma sono molti movimenti del corpo. Inoltre, sembra una soluzione "stampella" finché non appare il tuo repository
• docker-compose. È necessario solo per eseguire i contenitori. È tutto. Non può fare nient'altro. Docker-compose ha un sacco di versioni dei suoi file, una propria sintassi. Non importa quanto sia dichiarativo, non voglio leggere la loro documentazione. Non ne avrò bisogno da nessun'altra parte.
• quando si lavora in gruppo, la maggior parte delle persone scrive un Dockerfile in modo molto storto, non capisce come viene memorizzato nella cache, aggiunge tutto ciò di cui ha bisogno e non gli serve all'immagine, eredita da immagini che non sono in Dockerhub o in un repository privato, ne crea alcune docker-compose file con database e nulla persiste. Allo stesso tempo, gli sviluppatori dichiarano con orgoglio che Docker è interessante, tutto funziona a livello locale per loro e le risorse umane scrivono in modo importante nel posto vacante: "Utilizziamo Docker e abbiamo bisogno di un candidato con tale esperienza lavorativa".
• Sono costantemente perseguitato dal pensiero di creare tutto in Docker: postgresql, kafka, redis. È un peccato che non tutto funzioni nei container, non tutto sia facile da configurare ed eseguire. Questo è supportato da sviluppatori di terze parti e non dai fornitori stessi. E a proposito, sorge immediatamente la domanda: i fornitori non si preoccupano di mantenere i loro prodotti in Docker, perché è così, forse sanno qualcosa?
• Sorge sempre la domanda sulla persistenza dei dati contenitore. e poi pensi, dovrei semplicemente montare la directory host o creare un volume docker o creare un contenitore di dati che è adesso deprecated? Se monto una directory, devo assicurarmi che l'uid e il gid dell'utente nel contenitore corrispondano all'id dell'utente che ha avviato il contenitore, altrimenti i file creati dal contenitore verranno creati con diritti di root. Se uso volume quindi i dati verranno semplicemente creati in alcuni /usr/* e con uid e gid ci sarà la stessa storia del primo caso. Se stai lanciando un componente di terze parti, devi leggere la documentazione e cercare la risposta alla domanda: “in quali directory del contenitore il componente scrive i file?”

Non mi è sempre piaciuto il fatto di dover armeggiare con Docker per troppo tempo nella fase iniziale: ho capito come avviare i contenitori, da quali immagini avviarli, ho creato Makefile che contenevano alias per lunghi comandi Docker. Odiavo docker-compose perché non volevo imparare un altro strumento nell'ecosistema docker. E docker-compose up Mi dava fastidio, soprattutto se si incontravano ancora lì build costruzioni, piuttosto che immagini già assemblate. Tutto quello che volevo veramente era semplicemente realizzare un prodotto in modo efficiente e rapido. Ma non sono riuscito a capire come usare la finestra mobile.

Presentazione di Ansible

Di recente (tre mesi fa), ho lavorato con un team DevOps, quasi tutti i membri del quale avevano un atteggiamento negativo nei confronti di Docker. Per ragioni:

• docker governa iptables (anche se puoi disabilitarlo in daemon.json)
• docker è difettoso e non lo eseguiremo in produzione
• se il demone docker si blocca, tutti i contenitori con infrastruttura si bloccano di conseguenza
• non c'è bisogno di finestra mobile
• perché docker se ci sono Ansible e macchine virtuali

Nello stesso lavoro ho conosciuto un altro strumento: Ansible. Ne ho sentito parlare una volta, ma non ho provato a scrivere i miei manuali. E ora ho iniziato a scrivere i miei compiti e poi la mia visione è cambiata completamente! Perché ho capito: Ansible dispone di moduli per eseguire gli stessi contenitori docker, build di immagini, reti, ecc. E i contenitori possono essere eseguiti non solo localmente, ma anche su server remoti! La mia gioia non conosceva limiti: ho trovato uno strumento NORMALE e ho buttato via i miei file Makefile e docker-compose, sono stati sostituiti con attività yaml. Il codice è stato ridotto utilizzando costrutti come loop, when, ecc.

Docker per l'esecuzione di componenti di terze parti come i database

Recentemente ho conosciuto i tunnel ssh. Si è scoperto che è molto semplice "inoltrare" la porta di un server remoto a una porta locale. Il server remoto può essere una macchina nel cloud o una macchina virtuale in esecuzione in VirtualBox. Se io o il mio collega abbiamo bisogno di un database (o qualche altro componente di terze parti), possiamo semplicemente avviare il server con questo componente e spegnerlo quando il server non è necessario. Il port forwarding dà lo stesso effetto di un database in esecuzione in un contenitore docker.

Questo comando inoltra la mia porta locale a un server remoto che esegue postgresql:

ssh -L 9000: host locale: 5432 [email protected]

L'utilizzo di un server remoto risolve il problema con lo sviluppo del team. Un server di questo tipo può essere utilizzato da più sviluppatori contemporaneamente; non è necessario che siano in grado di configurare postgresql, comprendere Docker e altre complessità. Su un server remoto, è possibile installare lo stesso database nello stesso Docker, se è difficile installare una versione specifica. Tutto ciò di cui gli sviluppatori hanno bisogno è fornire l'accesso ssh!

Recentemente ho letto che i tunnel SSH sono una funzionalità limitata di una normale VPN! Puoi semplicemente installare OpenVPN o altre implementazioni VPN, configurare l'infrastruttura e fornirla agli sviluppatori per l'uso. Questo è veramente forte!

Fortunatamente, AWS, GoogleCloud e altri ti regalano un anno di utilizzo gratuito, quindi usali! Costano poco se li spegni quando non li usi. Mi sono sempre chiesto perché avrei bisogno di un server remoto come gcloud, sembra di averli trovati.

Come macchina virtuale locale, puoi utilizzare la stessa Alpine, che viene utilizzata attivamente nei contenitori docker. Bene, o qualche altra distribuzione leggera per velocizzare l'avvio della macchina.

In conclusione: puoi e dovresti eseguire database e altri gadget dell'infrastruttura su server remoti o in virtualbox. Non ho bisogno della finestra mobile per questi scopi.

Qualcosa sulle immagini e sulla distribuzione della finestra mobile

Ho già scritto Articolo in cui volevo trasmettere che l'utilizzo delle immagini docker non fornisce alcuna garanzia. Le immagini Docker sono necessarie solo per creare un contenitore Docker. Se stai eseguendo l'aggiornamento a un'immagine docker, stai eseguendo l'aggiornamento per utilizzare i contenitori docker e utilizzerai solo quelli.

Hai visto da qualche parte dove gli sviluppatori di software trasferiscono i loro prodotti solo in un'immagine docker?
Il risultato della maggior parte dei prodotti sono file binari per una piattaforma specifica; vengono semplicemente aggiunti all'immagine docker, che viene ereditata dalla piattaforma desiderata. Ti sei mai chiesto perché ci sono così tante immagini simili su dockerhub? Inserisci nginx ad esempio, vedrai 100500 immagini di persone diverse. Queste persone non hanno sviluppato nginx in sé, hanno semplicemente aggiunto nginx ufficiale alla loro immagine docker e l'hanno condita con le proprie configurazioni per la comodità di lanciare container.

In generale, puoi semplicemente memorizzarlo in tgz, se qualcuno ha bisogno di eseguirlo in docker, lascia che aggiunga tgz al Dockerfile, erediti dall'ambiente desiderato e crei panini aggiuntivi che non modifichino l'applicazione stessa in tgz. Chiunque creerà un'immagine docker saprà cos'è tgz e di cosa ha bisogno per funzionare. Ecco come utilizzo docker qui

In conclusione: non ho bisogno del registro docker, userò una sorta di S3 o semplicemente l'archiviazione di file come Google Drive/Dropbox

Docker in CI

Tutte le aziende per cui ho lavorato sono simili. Di solito sono generi alimentari. Cioè, hanno un'applicazione, uno stack tecnologico (beh, forse un paio o tre linguaggi di programmazione).

Queste aziende utilizzano la finestra mobile sui propri server su cui viene eseguito il processo CI. Domanda: perché è necessario creare progetti in un contenitore docker sui tuoi server? Perché non preparare semplicemente un ambiente per la build, ad esempio scrivendo un playbook Ansible che installerà le versioni necessarie di nodejs, php, jdk, copierà le chiavi ssh, ecc. Sul server in cui avrà luogo la build?

Ora capisco che questo mi dà la zappa sui piedi, perché docker non porta alcun profitto con il suo isolamento. Problemi che ho riscontrato con CI nella finestra mobile:

• ancora una volta è necessaria un'immagine docker da creare. devi cercare un'immagine o scrivere il tuo dockerfile.
• Per il 90% devi inoltrare alcune chiavi ssh, dati segreti che non vuoi scrivere nell'immagine docker.
• il contenitore viene creato e muore, tutte le cache vengono perse insieme ad esso. la build successiva scaricherà nuovamente tutte le dipendenze del progetto, il che richiede molto tempo ed è inefficace, e il tempo è denaro.

Gli sviluppatori non creano progetti in contenitori docker (una volta ero un tale fan, davvero, mi dispiace per me stesso in passato xD). In Java è possibile avere diverse versioni e modificarle con un comando in quella che ti serve ora. È lo stesso in nodejs, c'è nvm.

conclusione

Credo che docker sia uno strumento molto potente e flessibile, questo è il suo svantaggio (sembra strano, sì). Con il suo aiuto, le aziende possono facilmente appassionarsene e utilizzarlo dove necessario e non necessario. Gli sviluppatori lanciano i loro contenitori, alcuni dei loro ambienti, quindi tutto confluisce senza intoppi nella CI e nella produzione. Il team DevOps sta scrivendo una sorta di codice per eseguire questi contenitori.

Utilizza la finestra mobile solo su il più recente fase del tuo flusso di lavoro, non trascinarlo nel progetto all'inizio. Non risolverà i tuoi problemi aziendali. Sposterà solo i problemi ad UN ALTRO livello e offrirà le sue soluzioni, farai il doppio lavoro.

Quando è necessaria la finestra mobile: Sono giunto alla conclusione che la finestra mobile è molto efficace nell'ottimizzare un determinato processo, ma non nel creare funzionalità di base

Se decidi comunque di utilizzare Docker, allora:

• essere estremamente attento
• non forzare gli sviluppatori a utilizzare docker
• localizzarne l'utilizzo in un unico posto, non distribuirlo su tutti i repository Dockefile e docker-compose

PS:

• Mi sono imbattuto di recente Packer e dicono che funzioni molto bene con Ansible e ti consenta di unificare il processo di creazione delle immagini (inclusa l'immagine docker)
• anche sulla finestra mobile, articolo interessante

Grazie per aver letto, ti auguro decisioni trasparenti nei tuoi affari e giornate lavorative produttive!

Fonte: habr.com