Construisez Docker Engine - Community Edition à partir du code source. Les dernières versions des sources changent de plusieurs manières. Les informations de construction source sont disponibles ailleurs, mais je n'ai vu aucune information japonaise montrant les dernières instructions de construction. Si les informations sont un peu anciennes, la procédure de construction sera différente [^ 1]. Par conséquent, le texte montre la dernière version de la source Docker-ce-19.03.11 en juin 2020.
[^ 1]: En premier lieu, la structure du projet de Docker a changé, et le Docker Engine est désormais sous la responsabilité de Moby Project. Par conséquent, les informations obtenues à partir de [https://github.com/docker/docker] pour la source git sont obsolètes. De plus, étant donné que les versions du démon Docker et du client Docker ont été séparées à un moment donné, la procédure dans le texte principal est nécessaire pour construire le démon et le client en même temps.
Soyez prudent si vous suivez la procédure décrite dans le texte. Dans la distribution Linux que beaucoup de gens utilisent, il y a un gestionnaire de paquets, et je pense que le module Docker est installé en tant que paquet. Le travail dans le texte tente de désactiver le Docker emballé et de le remplacer par un Docker auto-construit. De plus, comme j'utilise Linux From Scratch, je ne considère pas le gestionnaire de paquets, et je n'hésite pas à l'installer en tant que / usr / bin. Assurez-vous de bien comprendre les conditions gérées par le gestionnaire de paquets et les risques d'endommagement de l'environnement avant de passer au texte. Par exemple, prenez des mesures telles que la définition de la destination d'installation sur / usr / local / bin.
L'auteur est [Linux From Scratch](http: //) comme indiqué dans cet article de Qiita "Présentation du moteur Docker à Linux From Scratch". Nous utilisons un système d'exploitation Linux construit sur la base de www.linuxfromscratch.org), et nous allons construire le source sur cet OS. Cependant, je pense que cette méthode de construction source fonctionne pour Linux OS en général. En effet, lors de la construction à partir de la source Docker, un conteneur Docker est créé à l'aide de Docker (pour être exact, le démon Docker) déjà installé sur le système (= système hôte) où la génération source est effectuée, et la source est créée dans ce conteneur. Parce qu'il construit. Parlant comme Docker, dans un environnement encapsulé dans un conteneur, les outils de construction nécessaires sont installés dynamiquement, c'est-à-dire installés à ce stade et construits, de sorte que n'importe quel système hôte Linux peut être utilisé et les outils de construction sont installés dans le système hôte. Vous pouvez le construire même s'il n'est pas en ordre.
En général, les hypothèses suivantes sont formulées.
/ var / lib / docker (le répertoire qui contient divers fichiers liés à Docker) est passé à 10 Go ou plus simplement en construisant, il est donc nécessaire de réserver de l'espace libre.Dans ce qui suit, cette procédure est effectuée par l'utilisateur root. S'il vous plaît soyez prudente.
Il existe deux façons d'obtenir la source. La première consiste à utiliser le code source résumé dans l'archive tar. Et l'autre est d'obtenir la dernière source du dépôt git, comme cela est souvent expliqué partout. Je pense que vous devriez décider lequel choisir en fonction de votre objectif et de vos préférences, mais je recommande la méthode tarball.
git à un moment donné et rassemblée dans une archive tar. Il est généralement recommandé de l'utiliser.git lorsque vous voulez vraiment obtenir la dernière source (la dernière de git HEAD, qui est mise à jour de temps en temps), ou lorsque vous avez besoin de vérifier ou de suivre l'historique des modifications du code source. .. Mais la question est, "vraiment", par exemple, si vous avez vraiment besoin d'une nouvelle source qui vient d'être mise à jour il y a environ 5 minutes aujourd'hui. Sauf si vous êtes un développeur, vous n'avez probablement pas besoin de ces dernières sources. Sachez plutôt qu'il n'y a aucune garantie que la source git HEAD sera toujours construite sans erreur. Même si vous prenez beaucoup de temps pour générer la source, cela ne signifie pas que vous obtiendrez une erreur de génération à la fin ou que cela ne fonctionnera pas en raison d'une erreur d'exécution. Par conséquent, il n'est pas recommandé d'obtenir la source par git à moins qu'il n'y ait un objectif clair.La source tarball est fournie par la page officielle de publication du site Docker Github (https://github.com/docker/docker-ce/releases). Il y a un lien de téléchargement de l'archive tar au milieu de la description longue et longue de la version, ce qui est difficile à comprendre, mais si vous regardez de plus près, [Code source]
(tar.gz)](https://github.com/docker/docker-ce/archive/v19.03.11.tar.gz). Dans le texte, la dernière v19.03.11.tar.gz au moment de la rédaction est utilisée.
Utilisez donc wget pour télécharger. Pour le répertoire de téléchargement, utilisez / mnt / lfs / sources comme exemple de répertoire pour la construction source.
C'est un goût personnel ici, mais comme le nom de l'archive tar est v19.03.11.tar.gz, vous ne pouvez pas dire quelle est l'archive tar source simplement en la regardant. Étant donné que nous le gérerons plus tard, nous renommerons le fichier et le téléchargerons en utilisant l'option wget`` --output-document comme indiqué ci-dessous.
# cd /mnt/lfs/sources
# wget -N https://github.com/docker/docker-ce/archive/v19.03.11.tar.gz \
--output-document docker-ce-19.03.11.tar.gz
Si vous vérifiez le contenu de l'archive tar au cas où, vous pouvez voir que divers codes sources sont rassemblés sous le répertoire docker-ce-19.03.11.
# tar tf docker-ce-19.03.11.tar.gz | less
docker-ce-19.03.11/
docker-ce-19.03.11/.github/
docker-ce-19.03.11/.github/PULL_REQUEST_TEMPLATE
docker-ce-19.03.11/.gitignore
docker-ce-19.03.11/CHANGELOG.md
docker-ce-19.03.11/CONTRIBUTING.md
docker-ce-19.03.11/Makefile
docker-ce-19.03.11/README.md
docker-ce-19.03.11/VERSION
docker-ce-19.03.11/components.conf
docker-ce-19.03.11/components/
docker-ce-19.03.11/components/cli/
docker-ce-19.03.11/components/cli/.dockerignore
(Ce qui suit est omis)
Décompressez (décompressez) l'archive tar et déplacez-la vers le répertoire source supérieur docker-ce-19.03.11.
# tar xf docker-ce-19.03.11.tar.gz
# cd docker-ce-19.03.11
Si vous choisissez d'obtenir cette archive tar, ignorez la description de git ci-dessous et passez à la section 2. Construction source.
gitClonez le référentiel officiel Docker git pour obtenir le dernier code source. Un nouveau répertoire docker-ce sera créé, alors allez-y.
# cd /mnt/lfs/sources
# git clone https://github.com/docker/docker-ce.git
# cd docker-ce
Avant de procéder à la génération source, définissez d'abord la stratégie de génération.
Si vous entrez dans le répertoire source et tapez make, cela seul ne démarrera pas le processus de construction et affichera une liste de cibles de construction make. make est conçu pour s'exécuter avec une cible de construction donnée comme argument. En d'autres termes, vous devez décider quelle cible de construction make choisir. Il existe plusieurs cibles, mais il existe trois façons de créer un nouveau module d'exécution Docker.
make: static, deb, rpmSauf si vous avez un objectif de construction clair, l'essentiel est que vous devriez choisir statique. Je vais choisir cela dans le texte.
Comme son nom l'indique, deb et rpm sont censés construire respectivement les packages deb et rpm. Je ne l'ai pas vraiment essayé, donc je ne l'expliquerai pas dans cet article.
Le choix de la make build target static a l'inconvénient de construire trop de modules exécutables. Plus précisément, il compile tous les modules d'exécution pour les architectures compatibles telles que Linux, Windows, Mac et ARM. À moins que vous n'essayiez de créer tout cela, vous n'avez pas besoin de tout. Même si la génération des sources Docker prend beaucoup de temps à construire, la construction de tout nécessite une grande préparation.
Ma conscience est de reconfigurer le démon Docker et les modules clients fonctionnant sur le système d'exploitation Linux avec une version source, sans avoir besoin d'un module d'exécution Windows ou Mac. Par conséquent, ne construisez que le module d'exécution Linux.
Le démon Docker doit être en cours d'exécution pour pouvoir créer une source Docker. S'il n'est pas démarré, démarrez-le comme suit.
# systemctl start docker
Le répertoire docker-ce-19.03.11 créé par décompression (décompression) de l'archive tar est le répertoire principal source. (Ou docker-ce est le répertoire principal source si vous l'avez obtenu à partir du référentiel git.)
git est docker-ce, mais il est difficile à expliquer en refusant à chaque fois, donc j'ai expliqué que le répertoire principal source est docker-ce-19.03.11. J'irai.Commencez par passer au répertoire supérieur source.
# cd /mnt/lfs/sources/docker-ce-19.03.11
Ensuite, lancez make static. Cependant, si vous l'exécutez tel quel, il créera tous les modules d'exécution pour l'architecture correspondante comme mentionné ci-dessus. Pour créer uniquement le module exécutable pour Linux, tapez:
# make static DOCKER_BUILD_PKGS=static-linux
Je vais expliquer brièvement la signification de la commande ci-dessus.
DOCKER_BUILD_PKGS spécifié ci-dessus se trouve dans Makefile dans <répertoire principal de la source> / components / packaging`. La description suivante existe dans ce fichier..PHONY: static
static: DOCKER_BUILD_PKGS:=static-linux cross-mac cross-win cross-arm
Si vous exécutez simplement make static, le processus continuera avec la définition de variable de DOCKER_BUILD_PKGS: = static-linux cross-mac cross-win cross-arm. C'est le processus par défaut. La méthode du texte est d'écraser et de le définir comme DOCKER_BUILD_PKGS = static-linux et d'exécuter make static.
Les caractères trouvés dans cette définition de variable sont faciles à imaginer. «cross-mac» signifie un binaire en cours d'exécution compilé de manière croisée pour Mac, «cross-win» signifie exécuter un binaire pour Windows et «cross-arm» signifie exécuter un binaire pour ARM. Par défaut, tout construire est défini ici. Dans le texte, j'ai décidé de ne construire que le binaire d'exécution pour Linux en définissant cette variable sur DOCKER_BUILD_PKGS = static-linux, mais en modifiant cette valeur de variable, il est possible de définir la cible de construction en détail. C'est.
Au fait, j'ai utilisé la commande time pour mesurer le temps de construction de toutes les versions de module en exécutant uniquement make static et les versions de module Linux avec DOCKER_BUILD_PKGS = static-linux. L'environnement de construction est le même environnement avec une image virtuelle sur VMware, Linux From Scratch, mémoire 2 Go, swap 1 Go. Voyez la différence écrasante.
| Méthode de traitement | Commande de traitement | temps de traitement |
|---|---|---|
| Construction de tous les modules | make static |
4 heures 06 minutes 49 secondes |
| Construire le module Linux uniquement | make static DOCKER_BUILD_PKGS=static-linux |
59 minutes 04 secondes |
Dans toutes les versions de modules, nous construisons 4 types de modules pour l'architecture, static-linux, cross-mac, cross-win et cross-arm, et il faut environ 1 heure pour construire une architecture. Le résultat est que c'est nécessaire.
Les modules d'exécution construits par make static sont stockés dans <répertoire principal source> / components / packaging / static / build / linux. L'un est une archive tar qui rassemble les modules d'exécution, et l'autre est un module d'exécution individuel dans le sous-répertoire docker (et docker-rootless-extras). Je vais. La situation est la suivante. Vous pouvez voir deux archives tar et les sous-répertoires docker et docker-rootless-extras.
# cd /mnt/lfs/sources/docker-ce-19.03.11
# cd components/packaging/static/build/linux
# ls
docker docker-rootless-extras
docker-19.03.11.tgz docker-rootless-extras-19.03.11.tgz
Si vous continuez à regarder les sous-répertoires docker et docker-rootless-extras ci-dessus, le module exécutable est toujours là.
# ls docker
containerd ctr docker-init dockerd
containerd-shim docker docker-proxy runc
# ls docker-rootless-extras
dockerd-rootless.sh rootlesskit rootlesskit-docker-proxy vpnkit
La méthode d'installation suivante consiste à copier et à enregistrer l'archive tar quelque part, et dans certains cas à la copier sur une autre machine et à l'installer. Vous pouvez simplement copier le module exécutable dans le sous-répertoire docker (et docker-rootless-extras) directement sur le système hôte. Choisissez la méthode appropriée en fonction de vos besoins. Dans le texte, nous allons procéder avec cette dernière méthode.
Le service Docker sera réinstallé, alors arrêtez d'abord le service Docker.
# systemctl stop docker
Si vous ne le faites pas, même si vous essayez de copier et d'installer le module d'exécution du démon Docker dockerd, systemd récupérera l'ancien dockerd, donc vous obtiendrez un nouveau module d'exécution. La copie par écrasement n'est pas possible.
Si nécessaire, effectuez une sauvegarde du module Docker que vous utilisiez. Déplacez-le dans un répertoire et enregistrez-le, ou enregistrez-le avec un suffixe tel que .orig. La procédure de sauvegarde n'apparaît pas dans le texte. Veuillez utiliser la méthode de votre choix.
Alternativement, si vous êtes bien conscient de la situation et que c'est possible, vous pouvez supprimer tous les modules d'exécution Docker précédents. Si vous avez installé des packages liés à Docker à l'aide du gestionnaire de packages fourni par votre distribution Linux, vous souhaiterez peut-être les supprimer. Cependant, je l'écrirai plusieurs fois, mais seulement si je comprends parfaitement la situation.
Comme indiqué ci-dessus, le module d'exécution nouvellement construit est placé sous le répertoire source, c'est donc une méthode pour le copier directement dans / usr / bin. Copiez simplement depuis le répertoire source vers / usr / bin.
J'ai expliqué que le module d'exécution unique est situé dans <répertoire supérieur de la source> / components / packaging / static / build / linux / docker.
Donc, comme précédemment, en supposant que le répertoire principal source est / mnt / lfs / sources / docker-ce-19.03.11, procédez comme suit:
# cd /mnt/lfs/sources/docker-ce-19.03.11
# cd components/packaging/static/build/linux/docker
# cp * /usr/bin
Si vous souhaitez également installer l'exécutable sans racine, faites de même pour le répertoire docker-rootless-extras.
# cd /mnt/lfs/sources/docker-ce-19.03.11
# cd components/packaging/static/build/linux/docker-rootless-extras
# cp * /usr/bin
Essayez d'exécuter docker, dockerd et d'autres modules exécutables installés dans / usr / bin avec l'option --version. Assurez-vous que la nouvelle version est installée.
# which -a docker
/usr/bin/docker
# docker --version
Docker version 19.03.11, build
# which -a dockerd
/usr/bin/dockerd
# dockerd --version
Docker version 19.03.11, build unsupported
Démarrez le service Docker qui a été arrêté.
docker.service et docker.socket pour démarrer le démon Docker. Peut être.docker.service et docker.socket dans mon manuscrit" Présentation du moteur Docker à Linux From Scratch ". Veuillez vous y référer car il montre la méthode.Si docker.service et docker.socket sont correctement préparés, un nouveau module d'exécution du démon Docker dockerd démarrera à partir d'ici. Je vais vraiment le déplacer.
# systemctl start docker.service
Après cela, essayez docker run hello-world et la documentation officielle de Docker Tutorial pour faire fonctionner le démon Docker et le client Docker. Assure-toi.
C'est tout pour le texte.
Recommended Posts