À l'ère des DevOps gagnants, les développeurs sont simplement obligés de connaître les conteneurs Docker, pourquoi ils sont nécessaires et comment travailler avec eux. Cela facilite grandement le travail. De plus, même ceux qui travaillent avec .Net Core dans l'environnement de développement Visual Studio 2017 peuvent ressentir toute la puissance de la conteneurisation.Pavel Skiba, chef du département de développement d'applications serveur, lors de la réunion
Panda-Meetup C # .Net , a parlé des outils disponibles et de la configuration de Docker pour VS.
Que doit faire un développeur? «Programme», répondez-vous et ... Devinez. Mais si plus tôt la liste des connaissances nécessaires s'est terminée sur ce point, maintenant à l'ère DevOps, elle ne fait que commencer. Lorsque nous écrivons du code, nous devons absolument connaître la structure du réseau: ce qui interagit avec quoi. La prise en charge est requise pour plusieurs langages de programmation à la fois, et différents morceaux de code dans un projet peuvent être écrits sur n'importe quoi.
Nous devons savoir comment restaurer le logiciel si une erreur est détectée. Nous devons gérer les configurations pour les différents environnements utilisés dans l'entreprise - ce sont au moins plusieurs environnements de développement, des environnements de test et de combat. Oh oui, vous devez toujours comprendre les scripts sur différents serveurs / systèmes d'exploitation, car tout ne peut pas être fait en utilisant du code, parfois vous devez écrire des scripts.
Nous devons connaître les exigences de sécurité, elles deviennent plus strictes et prennent beaucoup de temps au développeur. N'oubliez pas le support et le développement des logiciels associés: Git, Jenkins et ainsi de suite. En conséquence, le développeur peut tout simplement ne pas avoir suffisamment de temps pour un développement pur.
Que faire? Il existe un moyen de sortir, et il se trouve dans les conteneurs Docker et leur système de gestion. Une fois que vous aurez déployé tout ce colosse complexe, et vous, comme au bon vieux temps, vous n'écrirez à nouveau que du code. Tout le reste sera contrôlé par d'autres personnes ou par le système lui-même.
Nous comprenons les conteneurs
Qu'est-ce qu'un conteneur docker? Il s'agit d'une structure composée de plusieurs couches. La couche supérieure est la couche binaire de votre application. Les deuxième et troisième couches sont désormais intégrées dans .Net Core, le conteneur est déjà SDK-shny. La couche suivante dépend du système d'exploitation sur lequel le conteneur est déployé. Et la couche inférieure est le système d'exploitation lui-même.
Au niveau inférieur, Windows Nanoserver est déployé. Il s'agit d'une compression méga-coupée de Windows Server, qui ne peut rien faire d'autre que maintenir un programme utilitaire déployé. Mais son volume est 12 fois moins.
Si nous comparons les serveurs et conteneurs physiques et virtuels, les avantages de ces derniers sont évidents.
Lorsque tout fonctionnait sur des serveurs physiques, nous étions confrontés à un tas de problèmes. Il n'y avait pas d'isolement dans les codes de bibliothèque; certaines applications pouvaient interférer les unes avec les autres. Par exemple: une application a travaillé sur .Net 1.1 et une autre sur .Net 2.0. Le plus souvent, cela a conduit à une tragédie. Après un certain temps, des serveurs virtuels sont apparus, le problème de l'isolement a été résolu, il n'y avait pas de bibliothèques partagées. Certes, en même temps, cela est devenu très coûteux en termes de ressources et de main-d'œuvre: il fallait surveiller tout le temps le nombre de machines virtuelles qui tournent sur une machine virtuelle, sur Hyper-V et sur un morceau de fer.
Les conteneurs ont été conçus pour être une solution peu coûteuse et pratique, dépendant au minimum du système d'exploitation. Voyons comment ils diffèrent. Les serveurs virtuels à l'intérieur du système sont situés à peu près comme ceci.
La couche inférieure est le serveur hôte. Il peut être physique ou virtuel. La couche suivante est tout système d'exploitation avec virtualisation, au-dessus est un hyperviseur. En haut se trouvent des serveurs virtuels qui peuvent être divisés en OS invités et applications. Autrement dit, sous chaque serveur virtuel, un système d'exploitation invité est déployé au-dessus du système d'exploitation, ce qui représente un gaspillage supplémentaire de ressources.
Voyons comment les conteneurs Linux sont situés sur le système.
Comme vous pouvez le voir, les fichiers binaires avec applications sont immédiatement situés au-dessus du serveur hôte et du système d'exploitation. L'OS invité n'est pas nécessaire, les ressources sont libérées, les licences pour l'OS invité ne sont pas nécessaires.
Les conteneurs Windows sont légèrement différents de Linux.
Les couches de base sont les mêmes: infrastructure, OS hôte (mais maintenant Windows). Mais les conteneurs peuvent alors fonctionner directement avec le système d'exploitation ou être déployés au-dessus de l'hyperviseur. Dans le premier cas, il y a isolation des processus et des espaces, mais ils utilisent le même noyau avec d'autres conteneurs, ce qui du point de vue de la sécurité n'est pas de la glace. Si vous utilisez des conteneurs via Hyper-V, tout sera isolé.
Apprendre Docker pour VS
Passons à Docker lui-même. Supposons que vous disposez de Visual Studio et que vous installez le client Docker pour Windows pour la première fois. Dans ce cas, Docker déploiera le serveur démon Docker, l'interface sur Rest pour y accéder et le client lui-même - la ligne de commande Docker. Il nous permettra de gérer tout ce qui concerne les conteneurs: réseau, images, conteneurs, couches.
La diapositive montre les commandes les plus simples: tirer le conteneur Docker, le lancer, collecter, valider, renvoyer.
Docker est très organiquement associé à Visual Studio. La capture d'écran montre un menu de panneau de Visual Studio 2017. La prise en charge de la composition Docker est intégrée directement dans Intellisense, Dockerfile est pris en charge et tous les artefacts fonctionnent sur la ligne de commande.
Fait intéressant, nous pouvons Docker déboguer des conteneurs directement en temps réel. Et si vos conteneurs sont connectés les uns aux autres, ils seront immédiatement débazés d'un coup, et vous n'aurez pas besoin d'exécuter plusieurs environnements.
Comment les conteneurs sont-ils assemblés? L'élément principal ici est le dockerfile, qui contient des instructions pour la construction de l'image. Chaque dockerfile est créé pour chaque projet. Il indique: d'où obtient-on l'image de base, quels arguments passons-nous, quel est le nom du répertoire de travail avec les fichiers, les ports.
Cet argument source a deux paramètres. Le deuxième paramètre est le chemin le long duquel le résultat de l'assemblage sera placé dans le projet, la valeur est définie par défaut. À mon avis, ce n'est pas une très bonne option. Il y a souvent beaucoup de déchets dans ce dossier, il doit être nettoyé périodiquement, et lorsque nous nettoyons ce dossier, nous pouvons frotter l'assemblage. Donc, si vous le souhaitez, vous pouvez le modifier, il est défini par le paramètre système Docker_build_source, qui peut également être martelé.
L'instruction Entrypoint vous permet de configurer le conteneur en tant que fichier exécutable. Cette ligne est nécessaire pour .Net Core, de sorte qu'après le démarrage réussi du conteneur, il envoie un message «Votre application est en cours d'exécution» à la ligne de commande.
Maintenant sur le débogage des conteneurs. Tout ici est comme un .Net régulier, vous remarquerez à peine la différence. Le plus souvent, j'exécute .Net Core en tant qu'auto-hébergé sous dotnet.exe. Il utilise le débogueur CLRDBG, le cache de paquets NuGet et le code source.
ASP.Net 4.5+ est hébergé par IIS ou IIS Express, utilise le débogueur Microsoft Visual Studio et la source de la racine du site dans IIS.
Il existe deux environnements de débogage: Debug et Release. La balise d'image de débogage est marquée comme dev et la dernière version. Lors du débogage, l'argument Source est mieux défini sur obj / Docker / empty, afin de ne pas être confus, mais lorsque vous relâchez obj / Docker / publish. Ici, vous pouvez utiliser tous les mêmes fichiers binaires, vues, dossier wwwroot et toutes les dépendances qui existent.
Mastering Docker Compose
Passons à la partie amusante: l'outil d'orchestration Docker-compose. Prenons un exemple: vous avez une sorte de service commercial qui affecte 5-6 conteneurs. Et vous devez en quelque sorte fixer comment ils doivent être assemblés, dans quel ordre. C'est là que Docker-compose est utile, qui fournira tout l'assemblage, le lancement et la mise à l'échelle des conteneurs. Il est géré simplement, tout est collecté par une seule équipe.
Docker-compose utilise des fichiers YAML qui stockent la configuration de l'assemblage des conteneurs. Ils décrivent les paramètres que vous devez utiliser pour les images elles-mêmes, les assemblages, les services, les volumes, les réseaux et les environnements. La syntaxe est identique pour la publication en clusters. Autrement dit, une fois qu'ils ont écrit un tel fichier, et si à l'avenir il sera nécessaire de déployer un service métier dans un cluster, vous n'aurez rien à ajouter.
Considérez la structure d'un fichier YAML. L'image est une image Docker. Une image est un conteneur sans couche d'application, elle est immuable.
Build indique comment construire, où construire et où déployer.
Depends_on - Dépendance des services dont il dépend.
Environnement - nous définissons ici l'environnement.
Ports - cartographie des ports sur lesquels votre conteneur sera disponible.
Prenons un exemple. Nous avons juste une API sans service, essentiellement 3 conteneurs: il y a SQL.data sur Linux, il y a une application elle-même, cela dépend de webapi, et webapi dépend de SQL.data.
Peu importe l'ordre dans lequel les composants sont écrits dans le fichier. Si tout est décrit correctement, Compose générera automatiquement correctement ces informations en fonction des dépendances du projet. Ce fichier est suffisant pour collecter tous les conteneurs à la fois, la sortie sera une version finale.
Il existe une sorte de «conteneur conteneur», un conteneur spécial docker-compose.ci.build.yml, dans lequel la composition entière est assemblée. Vous pouvez exécuter ce conteneur spécial à partir de la ligne de commande Visual Studio et il pourra terminer l'assembly sur un serveur de génération, par exemple, dans Jenkins.
Jetez un œil à l'intérieur du fichier. L'exemple contient le répertoire de travail et d'où vient-il. Il restaure le projet depuis GIT, publie lui-même cette solution, configure Release et télécharge le résultat. C'est toute l'équipe à construire, rien d'autre n'a besoin d'être écrit. Il suffit de l'enregistrer une fois, puis de démarrer la publication avec un seul bouton.
À quoi d'autre mérite-t-il de prêter attention? Docker-compose pour chaque environnement recueille des images, pour chaque configuration un fichier distinct. Pour chaque configuration dans Visual Studio, il existe un fichier avec les paramètres dont vous avez besoin pour l'environnement.
Directement à partir de VS, vous pouvez démarrer à distance le débogage de la composition entière.
Orchestrateurs de cluster
Enfin, nous abordons des sujets tels que les orchestrateurs de cluster. Nous ne devons pas penser à la façon dont les conteneurs continuent d'exister, aux personnes ou aux systèmes qui sont gérés. Pour cela, il existe 4 des systèmes de gestion de conteneurs les plus populaires: Google Kubernetes, Mesos DC / OS, Docker Swarm et Azure Service Fabric. Ils vous permettent de gérer le clustering et la composition des conteneurs.
Ces systèmes sont capables de faire face à une énorme couche de microservices, leur fournissant tout le nécessaire. Le développeur n'aura besoin de configurer cette couche qu'une seule fois.
La version complète des performances de Panda Meetup est disponible ci-dessous.
Pour ceux qui souhaitent approfondir le sujet, je vous conseille d'étudier les supports suivants:
Http://dot.net
Http://docs.docker.com
Http://hub.docker.com/microsoft
Http://docs.microsoft.com
Http://visualstudio.com
Et enfin, un conseil important de la pratique: la chose la plus difficile est de se souvenir où se trouve.
La documentation lorsque vous travaillez avec des conteneurs Docker tombera sur vos épaules. Sans documentation, vous oublierez où dans quel conteneur ce qui est connecté à quoi et ce qui fonctionne. Plus il y a de services, plus le réseau total de connexions est grand.