Théorie et pratique de la normalisation des services Docker

Les informations sur le thème de l'architecture des applications de microservices, qui ont déjà réussi à combler leur retard, suffisent aujourd'hui pour décider si elles conviennent ou non à votre produit. Et ce n'est pas du tout un secret que les entreprises qui ont décidé de choisir cette voie doivent faire face à de nombreux défis d'ingénierie et de culture. L'une des sources de problèmes est les frais généraux qui se multiplient partout, et cela s'applique également à la routine associée aux processus de production.

_{Source de l'image:}

Comme vous pouvez le deviner, l'Anti-plagiat est exactement une telle entreprise, où la compréhension est progressivement venue que nous sommes avec des microservices en cours de route. Mais avant de commencer à manger le cactus, nous avons décidé de le nettoyer et de le faire cuire. Et puisque toutes les seules solutions vraies et correctes pour chacune sont uniques, au lieu de diapositives DevOps universelles avec de belles flèches, nous avons décidé de partager notre propre expérience et de dire comment nous avons déjà couvert une partie considérable de notre chemin spécial vers, je l'espère, le succès.

Si vous fabriquez un produit vraiment unique, largement constitué de savoir-faire, il n'y a presque aucune chance d'esquiver ce chemin spécial, car il est formé de nombreux chemins privés: à partir de la culture et des données historiques qui se sont développées dans l'entreprise, se terminant par sa propre spécificité et la pile technologique utilisée .

L'une des tâches de toute entreprise et équipe est de trouver l'équilibre optimal entre les libertés et les règles, et les microservices portent ce problème à un nouveau niveau. Cela peut sembler contredire l'idée même de microservices, qui implique une grande liberté dans le choix des technologies, mais si vous ne vous concentrez pas directement sur les problèmes architecturaux et technologiques, mais regardez les problèmes de production en général, alors le risque d'être quelque part dans l' intrigue du «Jardin des délices terrestres» est tout à fait tangible. .

Cependant, dans l'ouvrage "Création de microservices" Sam Newman propose une solution à ce problème, où littéralement dès les premières pages il évoque la nécessité de limiter la créativité des équipes dans le cadre d'accords techniques. Ainsi, l'une des clés du succès, en particulier dans le contexte d'une ressource à main levée limitée, est la standardisation de tout ce qui ne peut être négocié et que personne ne voudrait vraiment faire tout le temps. En élaborant des accords, nous créons des règles du jeu claires pour tous les participants à la production et au fonctionnement des composants du système. Et connaissant les règles du jeu, vous devez être d'accord, jouer devrait être plus facile et plus agréable. Cependant, suivre ces règles elles-mêmes peut devenir une routine et causer de l'inconfort aux participants, ce qui entraîne directement toutes sortes de déviations par rapport à elles et, par conséquent, l'échec de l'idée dans son ensemble. Et le moyen le plus évident est de mettre tous les accords dans le code, car aucune réglementation ne peut faire ce que l'automatisation et les outils pratiques peuvent utiliser, dont l'utilisation est intuitive et naturelle.

En allant dans cette direction, nous avons pu automatiser de plus en plus, et plus notre processus est devenu comme un convoyeur de bout en bout pour la production de bibliothèques et de micro (ou pas) services.

Un peu de fond

Au printemps 2017, Microsoft a présenté au monde un aperçu de .NET Core 2.0, et cette année, les astrologues C # se sont immédiatement précipités pour déclarer l'année Linux, alors ...

_{Source de l'image:}

Pendant un certain temps, nous, ne faisant pas confiance à la magie, avons tout collecté et testé sur Windows et Linux, publié des artefacts avec certains scripts SSH, essayé de configurer les anciens pipelines CI / CD en mode couteau suisse. Mais après un certain temps, ils ont réalisé que nous faisions quelque chose de mal. De plus, les références aux microservices et aux conteneurs résonnaient de plus en plus souvent. Nous avons donc également décidé de surfer sur la vague de battage médiatique et d'explorer ces directions.

Déjà au stade de la réflexion sur notre futur possible de microservices, un certain nombre de questions se sont posées, ignorant lesquelles, nous avons risqué dans ce tout futur de nouveaux problèmes que nous aurions nous-mêmes créés en échange de leur résolution.

Premièrement, lorsque nous regardons le côté opérationnel du monde théorique des microservices sans règles, nous avons été effrayés par la perspective du chaos avec toutes les conséquences qui en découlent, y compris non seulement la qualité imprévisible du résultat, mais aussi les conflits entre équipes ou développeurs et ingénieurs. Et essayer de faire des recommandations, ne pas être en mesure de les respecter, semblait immédiatement une entreprise vide de sens.

Deuxièmement, personne ne savait vraiment comment créer correctement des conteneurs et écrire des fichiers dockerfile, qui, néanmoins, ont déjà commencé à vivre dans nos référentiels. De plus, beaucoup «lisent quelque part» que tout n'y est pas si simple. Donc, quelqu'un a dû plonger plus profondément et comprendre, puis revenir avec les meilleures pratiques d'assemblage de conteneurs. Mais la perspective de jouer le rôle d'un docker packer à plein temps, laissé seul avec des piles de fichiers docker, pour une raison quelconque, n'a inspiré personne dans l'entreprise. En outre, comme il s'est avéré, plonger une fois n'est clairement pas suffisant, et même à première vue, il peut s'avérer faux ou tout simplement pas très bon.

Et troisièmement, je voulais être sûr que les images obtenues avec les services seraient non seulement correctes du point de vue des pratiques de conteneur, mais seraient également prévisibles dans leur comportement et auraient toutes les propriétés et attributs nécessaires pour simplifier le contrôle des conteneurs lancés. En d'autres termes, je voulais obtenir des images avec des applications qui sont également configurées et écrire des journaux, fournir une interface unique pour obtenir des mesures, avoir un ensemble cohérent d'étiquettes, etc. Il était également important que l'assemblage sur l'ordinateur du développeur donne le même résultat que l'assemblage sur n'importe quel système CI, y compris la réussite des tests et la génération d'artefacts.

Ainsi, une compréhension est née qu'un certain processus serait nécessaire pour gérer et centraliser de nouvelles connaissances, pratiques et normes, et le chemin depuis le premier commit vers une image docker complètement prête pour l'infrastructure du produit devrait être unifié et aussi automatisé que possible, sans aller au-delà des termes commençant avec le mot continu.

CLI vs GUI

Le point de départ d'un nouveau composant, qu'il s'agisse d'un service ou d'une bibliothèque, est de créer un référentiel. Cette étape peut être divisée en deux parties: créer et configurer le référentiel sur l'hébergement du système de contrôle de version (nous avons Bitbucket) et l'initialiser avec la création d'une structure de fichiers. Heureusement, un certain nombre d'exigences existaient déjà pour les deux. Par conséquent, leur formalisation dans le code était une tâche logique.

Alors, quel devrait être notre référentiel:

• Situé dans l'un des projets, sur lequel le nom, les droits d'accès, les politiques d'acceptation des demandes de tirage, etc.;
• Contiennent les fichiers et répertoires requis, tels que:
  
  • fichier avec la configuration et les informations sur le référentiel SolutionInfo.props (plus d'informations ci-dessous);
  • les codes source du projet dans le répertoire src ;
  • .gitignore , README.md , etc.;
• Contient les sous-modules Git nécessaires;
• Le projet doit être dérivé de l'un des modèles.

Étant donné que l'API REST Bitbucket donne un contrôle total sur la configuration des référentiels, un utilitaire spécial a été créé pour interagir avec elle - le générateur de référentiel. En mode question-réponse, elle reçoit de l'utilisateur toutes les données nécessaires et crée un référentiel qui répond pleinement à toutes nos exigences, à savoir:

• Définit un projet dans Bitbucket à choisir;
• Valide le nom conformément à notre accord;
• Définit tous les paramètres nécessaires qui ne peuvent pas être hérités du projet;
• Met à jour la liste des modèles personnalisés (nous utilisons des modèles dotnet ) pour le projet et suggère de choisir parmi ceux-ci;
• Remplit le minimum d'informations nécessaires sur le référentiel dans le fichier de configuration et dans les documents *.md ;
• Il connecte les sous-modules avec la configuration du pipeline CI / CD (dans notre cas, c'est Bamboo Specs ) et les scripts d'assemblage.

En d'autres termes, le développeur, en commençant un nouveau projet, lance l'utilitaire, remplit plusieurs champs, sélectionne le type de projet et reçoit, par exemple, le «Hello world!» Complètement terminé. un service qui est déjà connecté au système CI, d'où le service peut même être publié si vous effectuez une validation qui change la version en non nul.

La première étape a été franchie. Pas de travail manuel et d'erreurs, recherche de documentation, inscriptions et SMS. Passons maintenant à ce qui y a été généré.

La structure

La standardisation de la structure du référentiel a pris racine avec nous depuis longtemps et était nécessaire pour simplifier l'assemblage, l'intégration avec le système CI et l'environnement de développement. Initialement, nous sommes partis de l'idée que le pipeline dans CI devrait être aussi simple et, comme vous pouvez le deviner, standard, ce qui garantirait la portabilité et la reproductibilité de l'assemblage. Autrement dit, le même résultat pourrait être facilement obtenu à la fois dans n'importe quel système CI et sur le lieu de travail du développeur. Par conséquent, tout ce qui ne se rapporte pas aux fonctionnalités d'un environnement d'intégration continue spécifique est soumis à un sous-module Git spécial et est un système de construction autosuffisant. Plus précisément, le système de normalisation de l'assemblage. Le pipeline lui-même, dans une approximation minimale, ne doit exécuter que le script build.sh , récupérer un rapport sur les tests et lancer un déploiement, si nécessaire. Pour plus de clarté, voyons ce qui se passe si vous générez le référentiel SampleService dans un projet avec le nom parlant Sandbox .

 . ├── [bamboo-specs] ├── [devops.build] │ ├── build.sh │ └── ... ├── [docs] ├── [.scripts] ├── [src] │ ├── [CodeAnalysis] │ ├── [Sandbox.SampleService] │ ├── [Sandbox.SampleService.Bootstrap] │ ├── [Sandbox.SampleService.Client] │ ├── [Sandbox.SampleService.Tests] │ ├── Directory.Build.props │ ├── NLog.config │ ├── NuGet.Config │ └── Sandbox.SampleService.sln ├── .gitattributes ├── .gitignore ├── .gitmodules ├── CHANGELOG.md ├── README.md └── SolutionInfo.props 

Les deux premiers répertoires sont des sous-modules Git. bamboo-specs est «Pipeline as Code» pour le système Atlassian Bamboo CI (il pourrait y avoir un fichier Jenkins à sa place), devops.build est notre système de construction, dont je devops.build plus en détail ci-dessous. Le répertoire .scripts également. Le projet .NET lui-même est situé dans src : NuGet.Config contient la configuration du référentiel privé NuGet , NLog.config configuration en temps réel de NLog . Comme vous pouvez le deviner, l'utilisation de NLog dans une entreprise est également l'une des normes. Le fichier Directory.Build.props est presque magique. Pour une raison quelconque, peu de gens connaissent une telle possibilité dans les projets .NET, comme la personnalisation de l'assembly . En bref, les fichiers portant les noms Directory.Build.props et Directory.Build.targets automatiquement importés dans vos projets et vous permettent de configurer des propriétés communes pour tous les projets en un seul endroit. Par exemple, c'est ainsi que nous connectons l'analyseur StyleCop.Analyzers et sa configuration à partir du répertoire CodeAnalysis à tous les projets de style code, définissons des règles de version et certains attributs communs pour les bibliothèques et les packages ( Company , Copyright , etc.), et nous nous connectons également via le <Import> fichier SolutionInfo.props , qui est précisément le même fichier de configuration de référentiel, qui a été discuté ci-dessus. Il contient déjà la version actuelle, des informations sur les auteurs, l'URL du référentiel et sa description, ainsi que plusieurs propriétés qui affectent le comportement du système d'assemblage et les artefacts résultants.

 <?xml version="1.0"?> <Project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="devops.build/SolutionInfo.xsd"> <PropertyGroup> <!-- Product name --> <Product>Sandbox.SampleService</Product> <!-- Product version. Version 0.0.0 wouldn't be published! --> <BaseVersion>0.0.0</BaseVersion> <!-- Project name which contains Main() --> <EntryProject>Sandbox.SampleService.Bootstrap</EntryProject> <!-- Exposed port --> <ExposedPort>4000/tcp</ExposedPort> <!-- DOTNET_SYSTEM_GLOBALIZATION_INVARIANT value. See https://github.com/dotnet/corefx/blob/master/Documentation/architecture/globalization-invariant-mode.md --> <GlobalizationInvariant>false</GlobalizationInvariant> <!-- Project URL --> <RepositoryUrl>https://bitbucket.contoso.com/projects/SND/repos/sandbox.sampleservice/</RepositoryUrl> <!-- Documentation URL --> <DocumentationUrl>https://bitbucket.contoso.com/projects/SND/repos/sandbox.sampleservice/browse/README.md</DocumentationUrl> <!-- Your name here --> <Authors>User Name &lt;username@contoso.com&gt;</Authors> <!-- Project description --> <Description>The sample service for demo purposes.</Description> <!-- Bamboo plan key (required for Bamboo Specs --> <BambooBlanKey>SMPL</BambooBlanKey> </PropertyGroup> </Project> 

 <Project> <Import Condition="Exists('..\SolutionInfo.props')" Project="..\SolutionInfo.props" /> <ItemGroup> <None Include="$(MSBuildThisFileDirectory)/CodeAnalysis/stylecop.json" Link="stylecop.json" CopyToOutputDirectory="Never"/> <PackageReference Include="StyleCop.Analyzers" Version="1.*" PrivateAssets="all" /> </ItemGroup> <PropertyGroup> <CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)/CodeAnalysis/stylecop.ruleset</CodeAnalysisRuleSet> <!-- Enable XML docs generating--> <GenerateDocumentationFile>true</GenerateDocumentationFile> <!-- Enable C# 7.x features --> <LangVersion>latest</LangVersion> <!-- default base version --> <BaseVersion Condition="'$(BaseVersion)' == ''">0.0.0</BaseVersion> <!-- default build number and format --> <BuildNumber Condition="'$(BuildNumber)' == ''">0</BuildNumber> <BuildNumber>$([System.String]::Format('{0:0000}',$(BuildNumber)))</BuildNumber> <!-- default version suffix --> <VersionSuffix Condition="'$(VersionSuffix)' == ''">local</VersionSuffix> <!-- empty version suffix instead of 'prod' --> <VersionSuffix Condition="'$(VersionSuffix)' == 'prod'"></VersionSuffix> <!-- format version prefix --> <VersionPrefix>$(BaseVersion).$(BuildNumber)</VersionPrefix> <!-- disable IsPackable by default --> <IsPackable>false</IsPackable> <PackageProjectUrl>$(RepositoryUrl)</PackageProjectUrl> <Company>Contoso</Company> <Copyright>Copyright $([System.DateTime]::Now.Date.Year) Contoso Ltd</Copyright> </PropertyGroup> </Project> 

Assemblage

Il convient de mentionner tout de suite que moi-même et mes collègues avions déjà une expérience assez réussie dans l’utilisation de différents systèmes de construction . Et au lieu de pondérer un outil existant avec des fonctionnalités totalement inhabituelles, il a été décidé d'en créer un autre, spécialisé pour notre nouveau processus, et de laisser l'ancien seul pour mener à bien ses tâches dans le cadre de projets hérités. L'idée de correction était le désir d'obtenir un outil qui transformera le code en une image docker qui répond à toutes nos exigences, en utilisant un processus standard unique, tout en éliminant la nécessité pour les développeurs de plonger dans les subtilités de l'assemblage, mais en préservant la possibilité d'une certaine personnalisation.

La sélection d'un cadre approprié a commencé. Sur la base des exigences de reproductibilité du résultat à la fois sur les machines de build avec Linux et sur les machines Windows de tout développeur, la véritable multiplateforme et un minimum de dépendances prédéfinies sont devenues une condition clé. À différents moments, j'ai réussi à bien connaître certains des cadres d'assemblage pour les développeurs .NET: de MSBuild et ses configurations XML monstrueuses, qui ont ensuite été traduites en Psake (Powershell), en FAKE exotique (F #). Mais cette fois, je voulais quelque chose de frais et léger. De plus, il a déjà été décidé que l'assemblage et les tests devraient être entièrement effectués dans un environnement de conteneur isolé, donc je ne prévoyais pas de fonctionner à l'intérieur d'autre chose que les commandes Docker CLI et Git, c'est-à-dire que la plupart du processus aurait dû être décrit dans le Dockerfile.
À cette époque, FAKE 5 et Cake pour .NET Core n'étaient toujours pas prêts, donc avec une plateforme multiplateforme, ces projets étaient comme ça. Mais mon très cher PowerShell 6 Core a déjà été publié, et je l'ai utilisé au maximum. Par conséquent, j'ai décidé de me tourner à nouveau vers Psake, et pendant que je me tournais, je suis tombé sur un projet Invoke-Build intéressant, qui est une refonte de Psake et, comme le souligne l'auteur lui-même, est le même, mais en mieux et plus facilement. Il en est ainsi. Je ne m'y attarderai pas en détail dans le cadre de cet article, je noterai seulement que la compacité me soudoie si toutes les fonctions de base de cette classe de produits sont disponibles:

• La séquence d'actions est décrite par un ensemble de tâches interdépendantes (tâches), qui peuvent être contrôlées en utilisant leurs interdépendances et leurs conditions supplémentaires.
• Il existe plusieurs aides pratiques, par exemple, exec {} pour gérer correctement les codes de sortie des applications de console.
• Toute exception ou arrêt d'utilisation de Ctrl + C sera correctement traitée dans un bloc Exit-Build spécial intégré. Par exemple, vous pouvez supprimer tous les fichiers temporaires, un environnement de test ou dessiner un rapport agréable à l'œil.

Dockerfile générique

Le Dockerfile lui-même et l'assemblage utilisant la docker build offrent des capacités de paramétrage assez faibles, et la flexibilité de ces outils est à peine supérieure à celle d'une poignée de pelle. En outre, il existe un grand nombre de façons de rendre la «mauvaise» image, trop grande, trop dangereuse, trop peu intuitive ou simplement imprévisible. Heureusement, la documentation de Microsoft propose déjà plusieurs exemples de Dockerfile , qui vous permettent de comprendre rapidement les concepts de base et de créer votre premier Dockerfile, en l'améliorant progressivement plus tard. Il utilise déjà un modèle à plusieurs étapes et crée une image spéciale « Test Runner » pour exécuter les tests.

Modèle et arguments à plusieurs étapes

La première étape consiste à diviser les étapes d'assemblage en plus petites et à en ajouter de nouvelles. Il convient donc de souligner le lancement de la dotnet build tant qu'étape distincte, car pour les projets contenant uniquement des bibliothèques, il est inutile d'exécuter la dotnet publish . Maintenant, à notre discrétion, nous ne pouvons exécuter que les étapes d'assemblage requises en utilisant
dotnet build --target <name>
Par exemple, nous collectons ici un projet contenant uniquement des bibliothèques. Les artefacts ici ne sont que des packages NuGet, ce qui signifie que cela n'a aucun sens de collecter une image d'exécution.

Ou nous construisons déjà un service, mais à partir de la branche des fonctionnalités. Nous n'avons pas du tout besoin d'artefacts d'un tel assemblage, il est seulement important de passer les tests et le bilan de santé.

La prochaine chose à faire est de paramétrer l'utilisation des images de base. Depuis un certain temps maintenant, dans le Dockerfile, la directive ARG peut être placée en dehors des étapes de construction, et les valeurs transférées peuvent être utilisées dans le nom de l'image de base.

 ARG DOTNETCORE_VERSION=2.2 ARG ALPINE_VERSION= ARG BUILD_BASE=mcr.microsoft.com/dotnet/core/sdk:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} ARG RUNTIME_BASE=mcr.microsoft.com/dotnet/core/runtime:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} FROM ${BUILD_BASE} AS restore ... FROM ${RUNTIME_BASE} AS runtime ... 

Nous avons donc eu de nouvelles opportunités à première vue et pas évidentes. Premièrement, si nous voulons créer une image avec une application ASP.NET Core, alors l'image d'exécution en aura besoin d'une autre: mcr.microsoft.com/dotnet/core/aspnet . Le paramètre avec une image de base non standard doit être enregistré dans la configuration du référentiel SolutionInfo.props et passé en argument lors de l'assemblage. Nous avons également facilité l'utilisation par le développeur d'autres versions des images .NET Core: des aperçus, par exemple, ou même des personnalisées (on ne sait jamais!).

Deuxièmement, la possibilité de "développer" le Dockerfile est encore plus intéressante, ayant fait partie des opérations dans un autre assemblage, dont le résultat sera pris comme base lors de la préparation de l'image d'exécution. Par exemple, certains de nos services utilisent JavaScript et Vue.js, dont nous préparerons le code dans une image distincte, en ajoutant simplement un tel Dockerfile «en expansion» au référentiel:

 ARG DOTNETCORE_VERSION=2.2 ARG ALPINE_VERSION= ARG RUNTIME_BASE=mcr.microsoft.com/dotnet/core/aspnet:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} FROM node:alpine AS install WORKDIR /build COPY package.json . RUN npm install FROM install AS src COPY [".babelrc", ".eslintrc.js", ".stylelintrc", "./"] COPY ClientApp ./ClientApp FROM src AS publish RUN npm run build-prod FROM ${RUNTIME_BASE} AS appbase COPY --from=publish /build/wwwroot/ /app/wwwroot/ 

Collectons cette image avec la balise, que nous passerons à l'étape d'assemblage de l'image d'exécution du service ASP.NET comme argument à RUNTIME_BASE. Vous pouvez donc étendre l'assemblage autant que vous le souhaitez, y compris, vous pouvez paramétrer ce que vous ne pouvez pas simplement faire dans la docker build . Vous souhaitez paramétrer l'ajout de Volume? Facile:

 ARG DOTNETCORE_VERSION=2.2 ARG ALPINE_VERSION= ARG RUNTIME_BASE=mcr.microsoft.com/dotnet/core/aspnet:${DOTNETCORE_VERSION}-alpine${ALPINE_VERSION} FROM ${RUNTIME_BASE} AS runtime ARG VOLUME VOLUME ${VOLUME} 

Nous commençons l'assemblage de ce Dockerfile autant de fois que nous voulons ajouter de directives VOLUME. Nous utilisons l'image résultante comme base pour le service.

Exécution de tests

Au lieu d'exécuter des tests directement dans les étapes d'assemblage, il est plus correct et plus pratique de le faire dans un conteneur spécial «Test Runner». Présentant brièvement l'essence de cette approche, je note qu'elle vous permet de:

• Effectuez tous les lancements planifiés, même si l'un d'eux se bloque;
• Montez le répertoire du système de fichiers hôte dans le conteneur pour recevoir un rapport de test, ce qui est essentiel lors de la construction dans le système CI;
• Exécutez les tests dans un environnement temporaire en transmettant le nom de son réseau au docker run --network <test_network_name> .

Le dernier paragraphe signifie que nous pouvons désormais exécuter non seulement des tests unitaires, mais aussi des tests d'intégration. Nous décrivons l'environnement, par exemple, dans docker-compose.yaml , et l' docker-compose.yaml pour la build entière. Vous pouvez maintenant vérifier l'interaction avec la base de données ou notre autre service, et enregistrer les journaux d'eux au cas où vous en auriez besoin pour l'analyse.

Nous vérifions toujours l'image d'exécution résultante pour réussir le contrôle de santé, qui est également une sorte de test. Un environnement de test temporaire peut être utile ici si le service testé a des dépendances sur son environnement.

Je note également que l'approche avec les conteneurs de dotnet build assemblés au stade de la dotnet build servira alors très bien pour lancer la dotnet publish dotnet pack dotnet nuget push et la dotnet nuget push . Cela nous permettra d'enregistrer les artefacts d'assemblage localement.

Dépendances Healthcheck et OS

Assez rapidement, il est devenu clair que nos services standardisés seraient toujours uniques à leur manière. Ils peuvent avoir des exigences différentes pour les packages préinstallés du système d'exploitation à l'intérieur de l'image et différentes façons de vérifier le contrôle de santé. Et si curl convient pour vérifier l'état d'une application Web, alors pour un backend gRPC ou, en outre, un service sans tête, il sera inutile, et ce sera également un package supplémentaire dans le conteneur.

Pour donner aux développeurs la possibilité de personnaliser l'image et d'étendre sa configuration, nous utilisons l'accord sur plusieurs scripts spéciaux qui peuvent être redéfinis dans le référentiel:

 .scripts ├── healthcheck.sh ├── run.sh └── runtime-deps.sh 

Le script healthcheck.sh contient les commandes nécessaires pour vérifier l'état:

• Pour le Web à l'aide de curl:

  
  

   #!/bin/ash set –e curl -sIf -o /dev/null -w "%{http_code}\n" 127.0.0.1/health || exit 1 

  
  

• Autres services utilisant notre propre utilitaire cli:

  
  

   #!/bin/ash set –e healthcheck || exit 1 

  
  

À l'aide de runtime-deps.sh , les dépendances sont installées et, si nécessaire, toutes les autres actions sur le système d'exploitation de base sont effectuées qui sont nécessaires au fonctionnement normal de l'application à l'intérieur du conteneur. Exemples typiques:

• Pour une application Web:

  
  

   #!/bin/ash apk add --no-cache curl icu-libs 

  
  

• Pour le service gRPC:

  
  

   #!/bin/ash apk add --no-cache libc6-compat 

  
  

Ainsi, la manière de gérer les dépendances et de vérifier l'état est standardisée, mais il y a de la place pour une certaine flexibilité. Quant à run.sh , c'est plus loin.

Script Entrypoint

Je suis sûr que tous ceux qui ont écrit au moins une fois leur Dockerfile se sont demandé quelle directive utiliser - CMD ou ENTRYPOINT . De plus, ces équipes ont également deux options de syntaxe, qui affectent de la manière la plus dramatique le résultat. Je n'expliquerai pas la différence en détail, en répétant après ceux qui ont déjà tout clarifié . Je recommande simplement de se rappeler que dans 99% des situations, il est correct d'utiliser ENTRYPOINT et la syntaxe exec:

ENTRYPOINT ["/ chemin / vers / exécutable"]

Sinon, l'application lancée ne pourra pas traiter correctement les commandes du système d'exploitation, telles que SIGTERM, etc., et vous pouvez également avoir des problèmes sous la forme de processus zombies et de tout ce qui concerne le problème PID 1 . Mais que se passe-t-il si vous souhaitez démarrer le conteneur sans lancer l'application? Oui, vous pouvez remplacer le point d'entrée:
docker run --rm -it --entrypoint ash <image_name> <params>
Il n'a pas l'air trop confortable et intuitif, non? Mais il y a une bonne nouvelle: vous pouvez faire mieux! À savoir, utilisez un script de point d'entrée . Un tel script vous permet de rendre l'initialisation ( exemple ) arbitrairement complexe, le traitement des paramètres et tout ce que vous voulez.

Dans notre cas, par défaut, le scénario le plus simple, mais en même temps fonctionnel, est utilisé:

 #!/bin/sh set -e if [ ! -z "$1" ] && $(command -v $1 >/dev/null 2>&1) then exec $@ else exec /usr/bin/dotnet /app/${ENTRY_PROJECT}.dll $@ fi 

Il vous permet de contrôler le lancement du conteneur de manière très intuitive:
docker run <image> env - exécute simplement env dans l'image, montrant les variables d'environnement.
docker run <image> -param1 value1 - démarre le service avec les arguments spécifiés.

Séparément, vous devez faire attention à la commande exec : sa présence avant d'appeler l'application exécutable lui fournira le PID 1 convoité dans votre conteneur.

Quoi d'autre

Bien sûr, sur plus d'un an et demi d'utilisation, le système de build a accumulé de nombreuses fonctionnalités différentes. En plus de gérer les conditions de lancement des différentes étapes, en travaillant avec le stockage des artefacts, la gestion des versions et d'autres fonctionnalités, notre «standard» du conteneur s'est également développé. Il était rempli d'attributs importants qui le rendent plus prévisible et plus pratique sur le plan administratif:

• Toutes les étiquettes d'images nécessaires sont installées: versions, numéros de révision, liens vers la documentation, auteur et autres.
• Dans le conteneur d'exécution, la configuration NLog est redéfinie afin qu'après la publication, tous les journaux soient immédiatement présentés sous une forme structurée à l'aide de json, dont la version est versionnée.
• Les règles d'analyse statique et toutes les autres normes sont automatiquement mises à jour.

Un tel outil, bien sûr, peut toujours être amélioré et développé. Tout dépend des besoins et de l'imagination. Par exemple, en plus de tout, il était possible de regrouper des utilitaires cli supplémentaires dans une image. Le développeur peut facilement les mettre dans l'image, en spécifiant dans le fichier de configuration uniquement le nom de l'utilitaire requis et le nom du projet .NET à partir duquel il doit être assemblé (par exemple, notre healthcheck ).

Conclusion

Décrit ici n'est qu'une partie d'une approche intégrée de la normalisation. Les services eux-mêmes, qui sont créés à partir de nos modèles, sont restés en arrière-plan, et ils sont donc assez unifiés par de nombreux critères, tels qu'une approche unique de la configuration, des méthodes courantes pour accéder aux métriques, la génération de code, etc. . , .

, Linux , - . , , . , , , Code Style, , .

, ! , « », , . , Docker .