Généralement, un développeur se soucie de satisfaire les exigences commerciales. Il / elle pourrait avoir l'expertise dans une pile ou un cadre particulier. Mais devrait-il faire un effort pour apprendre le docker et ses différentes méthodes de déploiement (essaim, kube, mesos, etc.)?
En termes simples, pourquoi un développeur devrait-il se soucier de Docker?
PS: La question parent à ce poste est Implication de l'introduction de docker à l'équipe de développement
Réponses:
Probablement pas la réponse que vous cherchez, mais une réponse quand même :)
L'apprentissage de Docker et de ses méthodes de déploiement pourrait en fait être inclus dans les exigences de l'entreprise en l'intégrant dans l'environnement de développement du projet ou de l'équipe, tout comme le (s) langage (s) de code, le système de contrôle de version, les compilateurs, l'infrastructure de test, etc. cette équipe ou sur ce projet, il faut connaître et utiliser tout cela, ne peut pas "apporter le vôtre" (dans la plupart des cas).
Les choses deviennent un peu plus compliquées si, par "développeur", vous entendez en fait la majorité ou même toute l'équipe de développement. Pousser un outil dans l'environnement de développement sans qu'aucun des développeurs ne le supporte sera vraiment difficile. Passez du temps à créer un de ces supporters d'abord à partir du leadership technique de l'équipe.
Remarque: il peut également ne pas être nécessaire que chaque développeur de l'équipe devienne un expert docker. Des recettes d'utilisation préétablies, regroupées dans des commandes simples et prêtes pour la triche, permettent souvent aux développeurs d'utiliser des solutions basées sur les dockers sans en savoir trop sur leur fonctionnement interne, ce qui pourrait être assez acceptable, en particulier dans les grandes équipes. Tout comme pouvoir contribuer du code sans connaître tous les détails sur la façon dont le produit final est construit.
Je vais vous donner mon point de vue. Les développeurs doivent se soucier de Docker car il existe d'autres développeurs qui sont prêts à utiliser Docker et ont déjà acquis une expertise dans ce domaine. Ils sont prêts à assumer les rôles d'ingénieur DevOps en plus d'être développeur. Donc, la partie Ops de DevOps est sur laquelle ils développent maintenant leur expertise.
Ces jours-ci, vous trouverez de plus en plus de gars capables de développer, d'orchestrer, d'automatiser des tests, d'automatiser des travaux et de créer des outils pour surveiller et mettre ce package complet en production à lui seul. Ce sont les gars qui poussent Docker et d'autres outils parmi la communauté des développeurs.
En outre, la marée du marché est vers la virtualisation, la mise à l'échelle automatique, l'automatisation, l'apprentissage automatique et le docker s'intègre dans tous ces domaines. Il est devenu impératif d'utiliser Docker. Les entreprises sont prêtes à payer 2x pour un seul homme qui prend toutes ces responsabilités et lorsqu'il y a une demande pour de tels gars, l'offre commencera également. C'est du point de vue d'un employé-employeur.
Techniquement, dans les organisations dans lesquelles j'ai travaillé, il existe des équipes de développement et DevOps distinctes, bien qu'elles travaillent très étroitement pour les livraisons. Les ingénieurs et développeurs DevOps partagent ici une grande majorité de compétences et il y a donc parfois une négociation de tâches.
Le strict minimum qu'un développeur peut faire est de partager ses fichiers binaires, mais il doit comprendre que les fichiers binaires seront utilisés pour s'exécuter dans un conteneur Docker et pour cela, il doit comprendre comment fonctionne Docker. Pour les kubes, les essaims, les mesos, etc., le développeur peut même ne pas se soucier de ce qui est utilisé, mais les bases de docker devraient être très bien comprises par le développeur et un état d'esprit devrait être là dès le début pour créer l'application couplée de manière lâche pour une réutilisation comme micro-services. Si l'application est construite à partir de cet état d'esprit (ce qui nécessite des bases de docker), les ingénieurs DevOps peuvent ensuite reprendre à l'échelle automatique, orchestrer, tester, déployer et surveiller.
De plus, la plupart du temps, il n'y a pas de taille unique pour tous les types de choses. Un développeur ne sait pas clairement comment créer une application compatible avec les dockers et un ingénieur DevOps ne connaît pas à juste titre les éléments internes du processus de création d'application. Par conséquent, la plupart du temps, les organisations préfèrent confier ces deux tâches au même gars pour accélérer les choses. S'il y a des choses distinctes, alors un mécanisme de rétroaction continue est requis de l'équipe DevOps à l'équipe de développement pour rendre les applications plus futuristes et docker / cloud / scaling ready.
Il ne s'agit pas de Docker ou d'autres technologies de conteneurisation.
Les conteneurs tels que Docker, rkt, etc. ne sont qu'un moyen de fournir votre application de manière similaire au binaire statique. Vous construisez votre déploiement pour qu'il contienne tout ce dont il a besoin à l'intérieur et l'utilisateur final n'a besoin de rien de plus que de l'exécution.
Ces solutions sont similaires aux gros JAR de Java, où tout ce dont vous avez besoin (en théorie) est juste JRE (runtime) préinstallé et tout Just Works ™.
La raison pour laquelle les développeurs doivent comprendre (ils n'ont pas besoin d'apprendre à utiliser un tel outil, seulement pourquoi cela est nécessaire) les outils d'orchestration est que cela vous permet d'avoir certains avantages par rapport au déploiement "traditionnel".
EngineYard a écrit un bon article à ce sujet. Tout cela, c'est que lorsque votre serveur meurt, vous haussez les épaules et attendez que de nouveaux apparaissent. Vous les traitez comme du bétail, vous en avez des dizaines, des centaines, des milliers qui courent et quand on tombe en panne, ni vous ni vos clients ne devez en être conscients.
Les outils d'orchestration y parviennent en surveillant l'état de toutes les applications (pods / travaux, peu importe) dans le cluster, et lorsqu'il voit que l'un des serveurs cesse de répondre (tombe en panne), il déplace automatiquement toutes les applications qui s'exécutaient sur ce serveur ailleurs.
Grâce à l'orchestration, vous pouvez exécuter plusieurs applications sur un même serveur et l'orchestrateur suivra les ressources pour vous. Il réorganisera les applications si nécessaire.
Grâce à la gestion automatique du basculement dans les orchestrateurs, vous pouvez exécuter vos images personnalisées dans le cloud telles quelles. Lorsque vous aurez besoin d'une mise à jour, vous créez simplement une nouvelle image, définissez votre configuration de lancement pour l'utiliser maintenant et lancez simplement. Tout sera géré pour vous:
TL; DR Tout n'est pas sur Docker mais sur l'orchestration. Docker n'est qu'une version étendue des fichiers JAR tarball / fat requis pour une bonne orchestration.
Voici par exemple quelques arguments d'un article de blog publié en 2014 et intitulé d'une manière qui correspond tout à fait à votre réponse:
- Injection beaucoup plus flexible de nouvelles technologies dans l'environnement
- il y a toujours un gros problème entre la validation du code testé final et sa mise en service sur les serveurs de production finaux. Docker simplifie considérablement cette dernière étape
- Docker simplifie le maintien du système d'exploitation hérité, quelle que soit la saveur de Linux que vous utilisez
De: https://thenewstack.io/why-you-should-care-about-docker/
Si vous exécutez votre production dans un conteneur Docker, il est crucial que ces conteneurs soient créés par les mêmes développeurs qui ont créé l'application sur eux. Qui d'autre est le meilleur endroit pour savoir quelles dépendances externes sont nécessaires et ainsi de suite ...?
De plus, le pipeline peut échouer à n'importe quelle étape d'un CD, en particulier lorsque c'est l'étape de construction de l'image Docker, parfois c'est un fichier qui manque ou une bibliothèque qui est nécessaire.
Au travail, nous avons présenté à tous les développeurs Docker en leur expliquant les bases de la construction du dockerfile afin de servir leur application, nous avons également rendu le pipeline facile afin que l'on ne puisse ajouter qu'un nom et un dockerfile et son application sera automatiquement construite sur le prochaine poussée quelle que soit la technologie qui l'exécute.
Docker quickstart est vraiment une excellente introduction pour le faire, après quoi l'équipe devOps guide le développeur dans son choix de distribution (beaucoup d'entre eux ne savent pas des choses comme alpine).
Notre travail consiste à leur fournir un accès facile aux outils, ils font le reste pour pouvoir le réparer en cas de problème. Docker fait vraiment partie du processus de développement et l'équipe devOps leur fournit des images de docker qui correspondent à nos besoins et qui sont assez faciles, il ne faut donc que quelques minutes pour créer une nouvelle application et la déployer sans assistance.
Docker reçoit de nombreuses mentions de presse et de blog, ce qui incite les développeurs à l'utiliser. Pour certains, c'est l'intérêt de jouer avec une nouvelle technologie ou de comprendre comment les choses fonctionnent. Pour d'autres, c'est le désir d'ajouter des mots clés à leur CV. Quoi qu'il en soit, plus les développeurs savent comment les choses fonctionnent et comment ils sont déployés, moins ils seront surpris plus tard. D'après ce que j'ai vu, il y a un intérêt décent dans ce domaine, il ne devrait donc pas être si difficile de l'encourager davantage.
Eh bien, si vous avez déjà utilisé des machines virtuelles pour tester, vous voudrez peut-être essayer d'utiliser des conteneurs et docker est en fait une excellente chose pour les tests et il est beaucoup plus simple à utiliser à la place de LXC :)