Infrastructure de construction de projet avec docker

Il existe déjà des matériaux sur Habr pour configurer le docker- container pour la compilation du projet. Par exemple, Utilisation de Docker pour créer et exécuter un projet C ++ . Dans cet article, comme dans le précédent, la question de la construction du projet sera examinée, mais ici, je voudrais aller au-delà du didacticiel et approfondir les questions de l'utilisation de conteneurs dans de telles tâches, ainsi que de la construction de l'infrastructure de construction avec Docker .

Un peu de docker

Pour plus de clarté de la discussion, il est nécessaire de fournir une description de certains composants docker .

Image

L'image Docker est un modèle en lecture seule avec des instructions pour créer un conteneur. Pour créer l' image, vous devez créer un Dockerfile , qui décrit toutes les étapes de l'assemblage. Chacune de ces étapes crée un calque séparé à l'intérieur de l' image . Chaque calque suivant est superposé au-dessus de tous les précédents et ne contient que les modifications qui doivent être apportées au calque précédent.

Par exemple, pour un Dockerfile :

FROM ubuntu:18.04 ADD app.sh /app ENTRYPOINT /bin/bash /app/app.sh 

L' image de docker aura la structure suivante:

Les couches à l'intérieur de l' image sont mises en cache et peuvent être réutilisées si aucune modification n'est détectée. Si le calque est modifié (ajouté / supprimé) , tous les calques suivants sont créés à partir de zéro. Pour apporter des modifications à l'image du conteneur (et, par conséquent, à l'environnement du processus lancé), il suffit de réparer le Dockerfile et de commencer à construire l'image.

Conteneur

Un conteneur Docker est une instance de démarrage de l' image . Il peut être créé, démarré, arrêté, supprimé, etc. Par défaut, les conteneurs sont isolés les uns des autres et du système hôte. Au démarrage, le conteneur démarre une commande, qui peut être spécifiée dans ENTRYPOINT ou CMD , et s'arrête lorsqu'elle est terminée. Une situation acceptable est lorsque CMD et ENTRYPOINT sont présents , car ils interagissent comme décrit dans la documentation .

Lorsque vous créez chaque conteneur, un nouveau calque est ajouté au-dessus de tous les conteneurs existants. Il est accessible en écriture dans le conteneur actuel et est détruit avec le conteneur. Toutes les opérations d'écriture, de création de nouveaux fichiers lors du fonctionnement du conteneur sont appliquées à cette couche, l' image reste toujours inchangée. Ainsi, la structure des couches du conteneur créé ressemblera à:

Lors de l'utilisation de la docker run , un nouveau conteneur sera créé à chaque fois, avec sa propre couche pour l'écriture. Dans les tâches de construction, cela signifie qu'à chaque démarrage, il créera un nouvel environnement propre qui n'a rien à voir avec les exécutions précédentes. La liste des conteneurs créés peut être consultée en exécutant la commande: docker container ls -a .

Nous collectons le projet dans le conteneur

Pour plus de clarté, nous décrivons brièvement le processus de création d'une application dans un conteneur; ce processus est décrit plus en détail dans l' article 1 et l' article 2 .

Les étapes schématiquement possibles pour créer l'application dans Docker peuvent être représentées comme suit:

Analysons les étapes indiquées:

1. Nous utilisons le Dockerfile , qui décrit l'environnement, les commandes pour assembler et copier les résultats, et sur cette base, nous créons une image du conteneur.
2. Nous utilisons l'image résultante pour créer et lancer le conteneur avec la docker run . Nous montons le dossier source et le dossier où le résultat de l'assemblage sera copié dans le conteneur.
3. Une fois le conteneur terminé, les artefacts d'assemblage seront placés dans le répertoire monté.

Un exemple est donné dans l' article .

Étant donné que la docker run est utilisée ici, pour chaque lancement, un conteneur distinct sera créé avec sa propre couche pour l'écriture , de sorte que les fichiers temporaires des assemblys précédents n'entreront pas dans celui en cours. N'oubliez pas de nettoyer les conteneurs arrêtés.

Le montage du répertoire source facilite le débogage de l'assembly. Mais cela comporte des risques - vous pouvez collecter une version à partir d'un code qui n'a pas passé le contrôle de qualité ou qui n'est pas du tout ajouté au système de contrôle de version. Pour éviter cela, vous pouvez cloner le référentiel git à l'intérieur du conteneur à chaque build, comme, par exemple, dans le fichier :

 FROM ubuntu:bionic RUN apt-get update \ && apt-get install -y apt-utils RUN apt-get update \ && apt-get install -y make gcc g++ qt5-default git RUN mkdir -p /app/src WORKDIR /app/build #       ENTRYPOINT git -C /app/src clone https://github.com/sqglobe/SimpleQtProject.git \ && qmake /app/src/SimpleQtProject/SimpleQtProject.pro \ && make \ && cp SimpleQtProject /app/res/SimpleQtProject-ubuntu-bionic 

Ici, le clonage est effectué dans ENTRYPOINT , pas dans l'instruction RUN , en raison de la mise en cache. ENTRYPOINT est toujours exécuté au démarrage du conteneur et le résultat de la commande RUN peut être extrait du cache .

Construire une infrastructure

Pour construire un projet pour différents systèmes d'exploitation ou distributions Linux, une certaine configuration de serveurs (build machines, serveurs avec un système de contrôle de version, etc.) peut être utilisée. Dans la pratique, j'ai dû gérer les infrastructures suivantes:

Ici, l'utilisateur accède au serveur Web via lequel le projet est construit sur des machines avec Ubuntu et Red Hat . Ensuite, sur chaque machine, le référentiel git est cloné avec le projet dans un répertoire temporaire et l'assembly démarre. L'utilisateur peut télécharger les fichiers résultants à partir de la même page à partir de laquelle il a commencé l'ensemble du processus.

Un tel assemblage est reproductible car les développeurs utilisent le même environnement.

Parmi les inconvénients - il est nécessaire de maintenir une infrastructure entière, d'administrer plusieurs serveurs, d'éliminer les bogues dans les scripts et les applications Web , etc.

Simplifiez avec Docker

Soutenir l'infrastructure illustrée ci-dessus nécessite certains coûts, à la fois monétaires et humains. Si votre équipe travaille sur une petite startup, ou si vous êtes le seul développeur, vous pouvez utiliser des conteneurs Docker pour implémenter votre infrastructure de build.

Considérons un projet Qt trivial qui est construit en utilisant qmake - SimpleQtProject . Le dossier Docker du projet spécifié contient un certain nombre de fichiers:

• centos7.docker - décrit un conteneur pour la construction d'un projet pour CentOS 7 ;
• ubuntu-bionic.docker - un conteneur pour la construction sous Ubuntu 18.04 ;
• ubuntu-xenial.docker - décrit un conteneur pour la construction sous Ubuntu 16.04 .

Ces fichiers implémentent l'idée de cloner le code source à l'intérieur d'un conteneur.

L'ensemble complet est lancé à l'aide du Makefile . Il est très court et contient suffisamment de commentaires. Sa base est la création d'une image et le lancement du conteneur:

 %: %.docker docker build -t simple-qt-$(strip $(subst .docker,, $< )) --file $< . docker run --mount type=bind,source=$(RELEASE_DIR),target=/app/res simple-qt-$(strip $(subst .docker,, $< )) 

À ce stade de l'assemblage, une image du conteneur est créée avec le nom composé du préfixe simple-qt- et le nom du système (pour centos 7, ce sera simple-qt-centos7 ). En tant que Dockerfile , le fichier correspondant avec l'autorisation .docker est utilisé . Ensuite, le conteneur est lancé en fonction de l'image créée et un dossier est monté dessus pour copier les artefacts d'assemblage.

Après avoir exécuté la make dans le répertoire docker , le dossier docker / releases contiendra les résultats de construction pour plusieurs plates-formes.

Ainsi, notre infrastructure pour construire SimpleQtProject ressemblera à ceci:

Avantages de cette configuration:

1. Localité . Le développeur collecte un projet pour plusieurs plates-formes sur sa machine locale, ce qui élimine la nécessité de contenir une flotte de serveurs, de configurer la copie des artefacts entre les serveurs sur le réseau, d'envoyer et de traiter les commandes réseau.
2. Isolement de l'environnement . Le conteneur fournit un environnement complètement isolé pour créer une application spécifique. Il est possible de créer des projets avec des environnements incompatibles sur la même machine (par exemple, ceux qui nécessitent différentes versions de la même bibliothèque).
3. Versioning En plaçant le Dockerfile dans le référentiel git, vous pouvez suivre les modifications dans l'environnement de génération avec la publication de nouvelles versions, revenir aux versions précédentes de l'environnement de génération, etc.
4. Mobilité . Si nécessaire, cette infrastructure est déployée sans problème sur un autre ordinateur. La technologie de création d' une image de conteneur vous permet d'apporter des modifications à l'image elle-même très facilement - il suffit de mettre à jour le Dockerfile et de commencer à créer l'image.
5. Auto-documentation . Essentiellement, un Dockerfile contient les étapes de déploiement d'un environnement d'assemblage. Par conséquent, si nécessaire, déployez un tel environnement, mais déjà dans un système normal, vous pouvez utiliser les commandes de celui-ci.
6. Légèreté . Le conteneur démarre au moment où l'assemblage commence et s'arrête automatiquement à la fin. Il ne perd pas de temps CPU et de RAM.

Cependant, il y a un inconvénient important - l'assemblage du projet nécessitera l'assemblage de l'image du conteneur. Lorsque vous démarrez pour la première fois, cela peut prendre beaucoup de temps. Mais avec des répétitions, surtout si le Dockerfile n'a pas changé, l'image est assemblée en utilisant le cache plusieurs fois plus rapidement.

Il faut également penser à nettoyer les conteneurs arrêtés.

Conclusion

En conclusion, je voudrais noter que le docker n'est pas la seule technologie de conteneurisation. Mais certaines fonctionnalités le distinguent favorablement pour les tâches d'assemblage du même LXC :

1. Vous pouvez créer un conteneur à l'aide d'un Dockerfile de texte. Il s'agit d'un fichier avec une syntaxe simple, vous pouvez l'ajouter au référentiel du projet (comme je le fais toujours) et le garder constamment à portée de main.
2. Chaque fois, en lançant le conteneur docker avec la docker run nous obtenons un environnement propre , comme si nous faisions tout pour la première fois. Les fichiers temporaires entre les assemblys ne sont pas enregistrés.
3. Le conteneur ne lance pas l'ensemble du système d'exploitation, mais uniquement le processus d'assemblage nécessaire.