Generalmente uno sviluppatore si preoccupa di soddisfare i requisiti aziendali. Potrebbe avere l'esperienza in un particolare stack o in un framework. Ma dovrebbe fare uno sforzo per imparare la docker ed i suoi vari metodi di schieramento (sciame, kube, mesos, ecc.)?
In poche parole, perché uno sviluppatore dovrebbe preoccuparsi della finestra mobile?
PS: La domanda principale di questo post è Implicazione dell'introduzione della finestra mobile nel team di sviluppo
Risposte:
Probabilmente non la risposta che stai cercando, ma una risposta comunque :)
La conoscenza della docker e dei suoi metodi di implementazione potrebbe effettivamente essere inclusa nei requisiti aziendali rendendola parte del progetto o dell'ambiente di sviluppo del team, proprio come il linguaggio (i) di codice, il sistema di controllo della versione, i compilatori, l'infrastruttura di test, ecc. quella squadra o su quel progetto bisogna conoscere e usare tutti questi, non si può "portare il proprio" (nella maggior parte dei casi).
Le cose diventano un po 'più complicate se per "uno sviluppatore" intendi effettivamente la maggioranza o addirittura l'intero team di sviluppo. Spingere uno strumento nell'ambiente di sviluppo senza che nessuno degli sviluppatori lo supporti sarà davvero difficile. Trascorrere del tempo per creare uno di questi sostenitori prima dalla leadership tecnica del team.
Nota a margine: potrebbe anche non essere necessario per ogni sviluppatore del team diventare un esperto di docker. Le ricette di utilizzo prestabilite racchiuse in comandi semplici e pronti per il cheatheet spesso consentono agli sviluppatori di utilizzare soluzioni basate su docker senza sapere davvero troppo sul loro funzionamento interno, il che potrebbe essere abbastanza accettabile, specialmente in team di grandi dimensioni. Proprio come essere in grado di contribuire con il codice senza conoscere tutti i dettagli su come viene costruito il prodotto finale.
Ti darò la mia prospettiva. Gli sviluppatori dovrebbero preoccuparsi della docker in quanto vi sono altri sviluppatori che sono disposti a utilizzare la docker e hanno già sviluppato una propria esperienza. Sono disposti a ricoprire i ruoli di ingegnere DevOps oltre ad essere uno sviluppatore. Quindi la parte Ops di DevOps è ciò su cui ora stanno costruendo competenze.
In questi giorni, troverai sempre più ragazzi che possono sviluppare, orchestrare, automatizzare i test, automatizzare i lavori e costruire strumenti per monitorare e portare questo pacchetto completo in produzione da solo. Questi sono i ragazzi che stanno spingendo docker e altri strumenti nella comunità degli sviluppatori.
Inoltre, la marea del mercato è verso la virtualizzazione, il ridimensionamento automatico, l'automazione, l'apprendimento automatico e la docker in tutti questi aspetti. È diventato molto indispensabile utilizzare la finestra mobile. Le aziende sono disposte a pagare 2 volte per un singolo che si assume tutte queste responsabilità e quando c'è domanda per questi ragazzi, inizierà anche l'offerta. Questo è dal punto di vista di un dipendente-datore di lavoro.
Tecnicamente, nelle organizzazioni in cui ho lavorato, ci sono team di sviluppo e DevOps separati, anche se lavorano a stretto contatto per le consegne. Gli ingegneri e gli sviluppatori DevOps condividono qui una vasta maggioranza di competenze e quindi a volte vi è una negoziazione di compiti.
Il minimo indispensabile che uno sviluppatore può fare è condividere i suoi binari, ma deve capire che i binari verranno utilizzati per essere eseguiti all'interno di un contenitore docker e per questo deve capire come funziona la docker. Per kub, sciami, mesos ecc., Lo sviluppatore potrebbe non interessarsi nemmeno di ciò che viene utilizzato, ma le basi della docker dovrebbero essere molto ben comprese dallo sviluppatore e una mentalità dovrebbe essere lì fin dall'inizio per costruire l'applicazione liberamente accoppiata per il riutilizzo come micro-servizi. Se l'applicazione è costruita da quella mentalità (che richiede le basi della finestra mobile), gli ingegneri DevOps possono prenderla da lì per ridimensionare, orchestrare, testare, distribuire e monitorare automaticamente.
Inoltre, la maggior parte delle volte non esiste una taglia adatta a tutti i tipi di cose. Uno sviluppatore non sa chiaramente come costruire un'app compatibile con la finestra mobile e un ingegnere DevOps giustamente non conosce gli interni del processo di creazione dell'app. Quindi, la maggior parte delle volte, le organizzazioni preferiscono affidare entrambi questi compiti allo stesso ragazzo per accelerare le cose. Se esistono elementi separati, è necessario un meccanismo di feedback continuo dal team DevOps al team di sviluppo per rendere le app più futuristiche e predisposte per docker / cloud / ridimensionamento.
Non si tratta di Docker o di altre tecnologie di containerizzazione là fuori.
Contenitori come Docker, rkt, ecc. Sono solo un modo per distribuire la tua applicazione in modo simile al binario statico. Stai sviluppando la tua distribuzione in modo che contenga tutto ciò di cui ha bisogno all'interno e l'utente finale non ha bisogno di altro che di runtime.
Queste soluzioni sono simili ai JAR grassi di Java, dove tutto ciò che serve (in teoria) è solo pre-installato (JRE) preinstallato e tutto Just Works ™.
Il motivo per cui gli sviluppatori hanno bisogno di capire (non hanno bisogno di imparare come utilizzare tale strumento, solo perché è necessario) strumenti di orchestrazione è che questo ti consente di avere alcuni vantaggi rispetto alla distribuzione "tradizionale".
EngineYard ha scritto un buon articolo a riguardo. Il punto è che quando il tuo server si spegne, fai spallucce e aspetti che appariranno nuovi. Li tratti come bestiame, ne hai decine, centinaia, migliaia in esecuzione e quando uno scende, né tu né i tuoi clienti dovreste mai esserne consapevoli.
Gli strumenti di orchestrazione ottengono questo monitorando lo stato di tutte le applicazioni (pod / lavori, qualunque cosa) nel cluster e quando vede che uno dei server smette di rispondere (si arresta), sposta automaticamente tutte le applicazioni in esecuzione su quel server da qualche altra parte.
Grazie all'orchestrazione puoi eseguire più applicazioni su un server e l'orchestrator monitorerà le risorse per te. Riordinerà le applicazioni quando richiesto.
Grazie alla gestione automatica del failover negli orchestrator è possibile eseguire le immagini personalizzate nel cloud così come sono. Quando avrai bisogno di un aggiornamento, devi solo creare una nuova immagine, impostare la tua Configurazione di avvio per usarla ora e semplicemente scorrere. Tutto sarà gestito per te:
TL; DR L' intero punto non riguarda Docker ma l'orchestrazione. Docker è solo una versione estesa di JAR tarball / fat necessari per la corretta orchestrazione.
Ecco ad esempio alcuni argomenti di un post sul blog pubblicato nel 2014 e intitolato in modo abbastanza corrispondente alla tua risposta:
- Iniezione molto più flessibile di nuove tecnologie nell'ambiente
- c'è ancora un grosso problema tra il commit del codice testato finale e il suo funzionamento sui server di produzione finali. Docker semplifica enormemente questo passaggio finale
- Docker rende banale mantenere un sistema operativo legacy, indipendentemente dal tipo di Linux in uso
Da: https://thenewstack.io/why-you-should-care-about-docker/
Se stai eseguendo la tua produzione nel container docker è fondamentale che tali container siano realizzati dagli stessi sviluppatori che hanno creato l'app in esecuzione su di essi. Chi altro è il posto migliore per sapere quale dipendenza esterna è necessaria e così via ...?
Inoltre, la pipeline può fallire in qualsiasi fase durante un CD, in particolare quando si tratta della fase di creazione dell'immagine della finestra mobile, a volte è un file mancante o una lib che è necessaria.
Al lavoro presentiamo tutti gli sviluppatori alla finestra mobile spiegando loro le basi per costruire il file docker al fine di servire la loro app, inoltre abbiamo semplificato la pipeline in modo da poter aggiungere solo un nome e un file docker e la sua app verrà automaticamente costruita sul prossima spinta indipendentemente dalla tecnologia che lo esegue.
Docker Quickstart è davvero un'ottima introduzione per farlo, dopo ciò che il team devOps guida lo sviluppatore nella scelta della distribuzione (molti di loro non conoscono cose del genere alpine).
Il nostro compito è fornire loro un facile accesso agli strumenti, fanno il resto in modo da poterlo riparare quando qualcosa non va. Docker fa davvero parte del processo di sviluppo e il team devOps fornisce loro immagini docker che soddisfano le nostre esigenze e che sono abbastanza facili, quindi ci vogliono solo un paio di minuti per creare una nuova app e distribuirla senza assistenza.
Docker riceve molte menzioni su stampa e blog che portano gli sviluppatori a interessarsi ad usarlo. Per alcune persone è interesse a giocare con una nuova tecnologia o capire come funzionano le cose. Per altri è un desiderio aggiungere parole chiave al loro curriculum. Ad ogni modo, più sviluppatori sanno su come funzionano le cose e su come vengono implementate, meno sorprenderanno in seguito. Da quello che ho visto c'è un discreto interesse preesistente in questo, quindi non dovrebbe essere così difficile incoraggiarlo ulteriormente.
Bene, se hai mai usato VM per i test potresti voler provare a usare container e docker è in realtà un ottimo strumento per i test ed è molto più semplice da usare invece di LXC :)