Conteneur avancé
Un: limite de ressources Docker
1. Outil de test de résistance du système
stress
est un outil de test de stress sous Linux, spécifiquement pour ces charges élevées et complètement l'utilisateur veut tester leur système pour surveiller ces périphériques.
installation
[root@xingdian ~]# yum install stress -y
Exemples de scénarios de test
测试CPU负荷
[root@xingdian ~]# stress –c 4
增加4个cpu进程，处理sqrt()函数函数，以提高系统CPU负荷
内存测试
[root@xingdian ~]# stress –i 4 --vm 10 --vm-bytes 1G --vm-hang 100 --timeout 100s
新增4个io进程，10个内存分配进程，每次分配大小1G，分配后不释放，测试100S
磁盘I/O测试
# stress –d 1 --hdd-bytes 3G
新增1个写进程，每次写3G文件块
硬盘测试（不删除）
# stress -i 1 -d 10 --hdd-bytes 3G –hdd-noclean
新增1个IO进程，10个写进程，每次写入3G文件块，且不清除，会逐步将硬盘耗尽。
Description des principaux paramètres de contrainte (- moyens suivis d'une ligne médiane, - moyens suivis de 2 lignes médianes, les deux peuvent être utilisés pour les contraintes suivies de paramètres, expressions différentes):
--help 显示帮助信息
--version 显示软件版本信息
-t secs:
--timeout secs指定运行多少秒
-c forks:
--cpu forks 产生多个处理sqrt()函数的CPU进程
-m forks
--vm forks:产生多个处理malloc()内存分配函数的进程，后接进程数量
-i forks
--io forks:产生多个处理sync()函数的磁盘I/O进程
--vm-bytes bytes：指定内存的byte数，默认值是1
--vm-hang:表示malloc分配的内存多少时间后在free()释放掉
-d :
--hdd:写进程，写入固定大小，通过mkstemp()函数写入当前目录
--hdd-bytes bytes:指定写的byte数，默认1G
--hdd-noclean:不要将写入随机ascii数据的文件unlink，则写入的文件不删除，会保留在硬盘空间。
2. Limiter le partage du processeur
· Ressources du processeur
Les processus de l'hôte utiliseront le processeur via le mécanisme de découpage temporel L'unité de quantification du processeur est la fréquence, qui est le nombre d'opérations pouvant être effectuées par seconde. La limitation des ressources CPU pour les conteneurs ne modifie pas la fréquence de fonctionnement de la CPU, mais modifie la tranche de temps CPU que chaque conteneur peut utiliser. Idéalement, le processeur doit toujours être dans un état de calcul (et la quantité de calcul requise par le processus ne dépassera pas la capacité de traitement du processeur). Quelle est la part de
CPU de la limite
de docker CPU Share :
docker permet aux utilisateurs de définir un nombre pour chaque conteneur, qui représente la part de CPU du conteneur. Par défaut, la part de chaque conteneur est de 1024. Cette part est relative et ne représente en elle-même aucune signification définie. Lorsqu'il y a plusieurs conteneurs en cours d'exécution sur l'hôte, la proportion de temps processeur occupé par chaque conteneur est la proportion de sa part dans le total. Docker ajuste dynamiquement la proportion de temps pendant laquelle chaque conteneur utilise le processeur en fonction des conteneurs et des processus exécutés sur l'hôte.
Exemple:
s'il y a deux conteneurs sur l'hôte qui utilisent le processeur tout le temps (afin de simplifier la compréhension, les autres processus sur l'hôte ne sont pas pris en compte) et que leur part CPU est de 1024, alors le taux d'utilisation du processeur des deux conteneurs est de 50%; si l'un des conteneurs est Si le partage est défini sur 512, l'utilisation du processeur des deux est respectivement de 67% et 33%; si le conteneur avec le partage de 1024 est supprimé, l'utilisation du processeur du conteneur restant sera de 100%.
Avantages: il
peut garantir que le processeur est en état de fonctionnement autant que possible, utiliser pleinement les ressources du processeur et garantir l'équité relative de tous les conteneurs;
Inconvénients: il n'est
pas possible de spécifier une certaine valeur pour que le conteneur utilise le processeur.
Définissez les paramètres du partage CPU:
-c --cpu-partages, sa valeur est un entier.
Ma machine est un processeur à 4 cœurs, je lance donc un conteneur de stress et j'utilise le stress pour démarrer 4 processus afin de générer une pression de calcul:
# docker pull progrium/stress
# yum install htop -y
# docker run --rm -it progrium/stress --cpu 4
stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 12000us
stress: dbug: [1] --> hogcpu worker 4 [7] forked
stress: dbug: [1] using backoff sleep of 9000us
stress: dbug: [1] --> hogcpu worker 3 [8] forked
stress: dbug: [1] using backoff sleep of 6000us
stress: dbug: [1] --> hogcpu worker 2 [9] forked
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [10] forked
Utilisez htop dans un autre terminal pour afficher l'utilisation des ressources:
Comme le montre la figure ci-dessus, les quatre ressources de base du processeur ont atteint 100%. L'utilisation du processeur des quatre processus de stress n'a pas atteint 100% car d'autres machines sont en cours d'exécution dans le système.
A titre de comparaison, un autre conteneur avec une part de 512 est démarré:
# docker run --rm -it -c 512 progrium/stress --cpu 4
stress: info: [1] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 12000us
stress: dbug: [1] --> hogcpu worker 4 [6] forked
stress: dbug: [1] using backoff sleep of 9000us
stress: dbug: [1] --> hogcpu worker 3 [7] forked
stress: dbug: [1] using backoff sleep of 6000us
stress: dbug: [1] --> hogcpu worker 2 [8] forked
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [9] forked
Étant donné que la part du processeur du conteneur est de 1024 par défaut, l'utilisation du processeur de ces deux conteneurs doit être d'environ 2: 1. Voici une capture d'écran de la surveillance après le démarrage du deuxième conteneur:
Deux conteneurs ont lancé quatre processus de contrainte. L'utilisation du processeur du processus de contrainte du premier conteneur est d'environ 54% et l'utilisation du processeur du processus de contrainte du second conteneur est d'environ 25%. Le rapport est d'environ 2: 1, ce qui est cohérent avec le précédent. Attentes.
3. Limiter le nombre de cœurs de CPU utilisables par le conteneur
-c --cpu-share Le paramètre ne peut limiter que la proportion de CPU utilisée par le conteneur, ou priorité, et ne peut pas limiter définitivement le nombre spécifique de cœurs de CPU utilisés par le conteneur; depuis la version 1.13, docker Le paramètre --cpus est fourni pour limiter le nombre de cœurs de processeur que le conteneur peut utiliser. Cette fonction nous permet de définir plus précisément l'utilisation du processeur du conteneur, ce qui est une méthode plus facile à comprendre et donc plus couramment utilisée.
-Cpus est suivi d'un nombre à virgule flottante, qui représente le nombre maximum de cœurs utilisés par le conteneur, qui peut être précis à deux décimales, ce qui signifie que le conteneur peut utiliser un minimum de 0,01 cœur CPU.
Limitez le conteneur à n'utiliser que 1,5 CPU principaux:
# docker run --rm -it --cpus 1.5 progrium/stress --cpu 3
stress: info: [1] dispatching hogs: 3 cpu, 0 io, 0 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 9000us
stress: dbug: [1] --> hogcpu worker 3 [7] forked
stress: dbug: [1] using backoff sleep of 6000us
stress: dbug: [1] --> hogcpu worker 2 [8] forked
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogcpu worker 1 [9] forked
Démarrez trois contraintes dans le conteneur pour faire fonctionner la pression du processeur. S'il n'y a pas de limite, ce conteneur entraînera un taux d'utilisation du processeur d'environ 300% (c'est-à-dire qu'il occupera la puissance de calcul de trois cœurs). La surveillance proprement dite est la suivante:
On peut voir que l'utilisation du processeur de chaque processus de stress est d'environ 50% et que l'utilisation totale est de 150%, ce qui est conforme au paramètre de 1,5 cœur.
Si la valeur définie --cpus est supérieure au nombre de cœurs de processeur de l'hôte, docker signalera directement une erreur:
# docker run --rm -it --cpus 8 progrium/stress --cpu 3
docker: Error response from daemon: Range of CPUs is from 0.01 to 4.00, as there are only 4 CPUs available.
See 'docker run --help'.
Si plusieurs conteneurs ont défini --cpus et que leur somme dépasse le nombre de cœurs de processeur de l'hôte, cela n'entraînera pas l'échec ou la fermeture du conteneur. Ces conteneurs entreront en concurrence pour l'utilisation du processeur. Le nombre spécifique de processeurs alloués dépend de l'état de fonctionnement de l'hôte. Et la valeur de partage du processeur du conteneur. C'est-à-dire que cpus ne peut garantir le nombre maximal de processeurs que le conteneur peut utiliser lorsque les ressources de processeur sont suffisantes, et docker ne peut garantir que le conteneur peut utiliser autant de processeurs en aucune circonstance (car c'est tout simplement impossible).
4. Ressources de mémoire
Par défaut, docker ne limite pas la mémoire du conteneur, ce qui signifie que le conteneur peut utiliser toute la mémoire fournie par l'hôte. C'est bien sûr une chose très dangereuse: si un conteneur exécute un logiciel malveillant qui consomme de la mémoire, ou si le code a une fuite de mémoire, il est probable que la mémoire de l'hôte s'épuise, entraînant ainsi l'indisponibilité du service. Dans ce cas, docker définira la valeur du MOO (mémoire insuffisante) du démon docker pour réduire la priorité d'être tué lorsque la mémoire est insuffisante. De plus, vous pouvez définir la limite supérieure d'utilisation de la mémoire pour chaque conteneur. Une fois cette limite supérieure dépassée, le conteneur sera tué au lieu d'épuiser la mémoire de l'hôte.
Bien que la limitation de la limite de mémoire supérieure puisse protéger l'hôte, elle peut également nuire aux services dans le conteneur. Si la limite de mémoire définie pour le service est trop petite, cela entraînera la suppression du service par MOO alors qu'il fonctionne encore; si elle est trop grande, la mémoire sera gaspillée en raison de l'algorithme du planificateur. Par conséquent, les pratiques raisonnables incluent:
effectuer un test de résistance de la mémoire pour l'application, comprendre la mémoire utilisée dans les conditions normales de l'entreprise, puis entrer dans l'environnement de production. Vous devez limiter la limite supérieure d'utilisation de la mémoire du conteneur et essayer de vous assurer que l'hôte dispose de ressources suffisantes. Une fois la surveillance réussie Si les ressources s'avèrent insuffisantes, développez ou migrez le conteneur. Si possible (lorsque les ressources de mémoire sont suffisantes), essayez de ne pas utiliser de swap. L'utilisation de swap entraînera des calculs de mémoire complexes et est très peu conviviale pour le planificateur.
Docker limite l'utilisation de la mémoire du conteneur.
Dans les paramètres de démarrage du docker, les limitations de mémoire incluent (la valeur du paramètre est généralement la taille de la mémoire, qui est un nombre positif, suivi des unités de mémoire b, k, m, g, correspondant aux octets, Ko, Mo et Go, respectivement) :
-m --memory：容器能使用的最大内存大小，最小值为 4m
--memory-swap：容器能够使用的 swap 大小
--memory-swappiness：默认情况下，主机可以把容器使用的匿名页（anonymous page）swap 出来，你可以设置一个 0-100 之间的值，代表允许 swap 出来的比例
--memory-reservation：设置一个内存使用的 soft limit(软限制)，如果 docker 发现主机内存不足，会执行 OOM 操作。这个值必须小于 --memory 设置的值
--kernel-memory：容器能够使用的 kernel memory (内核内存)大小，最小值为 4m。
--oom-kill-disable：是否运行 OOM 的时候杀死容器。只有设置了 -m，才可以把这个选项设置为 false(假)，否则容器会耗尽主机内存，而且导致主机应用被杀死
Concernant le paramétrage de --memory-swap: --memory-swap doit être utilisé lorsque --memory est également configuré.
Si la valeur de --memory-swap est supérieure à --memory, alors la mémoire totale (mémoire + swap) qui peut être utilisée par le conteneur est la valeur de --memory-swap, et la valeur de swap qui peut être utilisée est --memory-swap moins --memory Il a
la même valeur que si --memory-swap vaut 0, ou une valeur et --memory, la taille du conteneur peut être utilisée pour échanger la mémoire deux fois, si la valeur correspondante est --memory 200M, 400M peut utiliser le conteneur d'échange puis
si - La valeur de -memory-swap est -1, alors il n'y a aucune limite à l'utilisation de swap, ce qui signifie que l'hôte peut utiliser autant de swaps que le conteneur peut être utilisé.
Si l'utilisation de la mémoire du conteneur est limitée à 64 Mo, le conteneur s'exécute normalement lors de l'application pour 64 millions de ressources ( Si la mémoire sur l'hôte est très faible, cela peut ne pas être garanti):
# docker run --rm -it -m 64m progrium/stress --vm 1 --vm-bytes 64M --vm-hang 0
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogvm worker 1 [7] forked
stress: dbug: [7] allocating 67108864 bytes ...
stress: dbug: [7] touching bytes in strides of 4096 bytes ...
stress: dbug: [7] sleeping forever with allocated memory
.....
Et si vous postulez pour une mémoire de 100M, vous constaterez que le processus dans le conteneur est tué (le travailleur 7 a reçu le signal 9, le signal 9 est le signal de mise à mort)
# docker run --rm -it -m 64m progrium/stress --vm 1 --vm-bytes 100M --vm-hang 0
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
stress: info: [1] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: dbug: [1] using backoff sleep of 3000us
stress: dbug: [1] --> hogvm worker 1 [7] forked
stress: dbug: [7] allocating 104857600 bytes ...
stress: dbug: [7] touching bytes in strides of 4096 bytes ...
stress: FAIL: [1] (415) <-- worker 7 got signal 9
stress: WARN: [1] (417) now reaping child worker processes
stress: FAIL: [1] (421) kill error: No such process
stress: FAIL: [1] (451) failed run completed in 0s
5. Ressources d'E / S
Pour les disques, les paramètres à prendre en compte sont la capacité et la vitesse de lecture et d'écriture, de sorte que les restrictions de disque sur les conteneurs doivent également être basées sur ces deux dimensions. Actuellement, docker prend en charge la limitation de la vitesse de lecture et d'écriture du disque, mais il n'y a aucun moyen de limiter la capacité du disque que le conteneur peut utiliser (une fois que le disque est monté dans le conteneur, le conteneur peut utiliser toute la capacité du disque).
Pour limiter le taux de lecture et d'écriture du disque, docker vous permet de limiter directement le taux de lecture et d'écriture du disque. Les paramètres correspondants sont:
-device-read-bps: le nombre maximum d'octets que le disque peut lire par seconde (octets)
-device-write-bps: par disque Nombre maximal d'octets pouvant être écrits en une seconde (octets)
Les valeurs des deux paramètres ci-dessus sont le disque et le débit correspondant. La limite est un entier positif et l'unité peut être kb, mb et gb.
Par exemple, vous pouvez limiter le taux de lecture de l'appareil à 1 Mo:
# docker run -it --device /dev/sda:/dev/sda --device-read-bps /dev/sda:1mb ubuntu:16.04 bash
root@6c048edef769:/# cat /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device
8:0 1048576
root@6c048edef769:/# dd iflag=direct,nonblock if=/dev/sda of=/dev/null bs=5M count=10
10+0 records in
10+0 records out
52428800 bytes (52 MB) copied, 50.0154 s, 1.0 MB/s
Il a fallu environ 50 secondes pour lire 50 m du disque, ce qui montre que la limite de débit du disque a fonctionné.
Deux autres paramètres peuvent limiter la fréquence de lecture et d'écriture du disque (combien d'opérations de lecture et d'écriture peuvent être effectuées par seconde):
–device-read-iops: le nombre maximum d'opérations de lecture d'E / S que le disque peut effectuer par seconde
–device-write-iops: le disque maximum par seconde Combien d'opérations d'écriture d'E / S peuvent être effectuées
Les valeurs des deux paramètres ci-dessus sont le disque et la limite supérieure d'E / S correspondante.
Par exemple, vous pouvez faire en sorte que le disque soit lu jusqu'à 100 fois par seconde:
# docker run -it --device /dev/sda:/dev/sda --device-read-iops /dev/sda:100 ubuntu:16.04 bash root@2e3026e9ccd2:/# dd iflag=direct,nonblock if=/dev/sda of=/dev/null bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes (1.0 MB) copied, 9.9159 s, 103 kB/s
Il peut être vu à partir du test que le conteneur a défini les iops de l'opération de lecture à 100 et a lu 1 m de données à partir du bloc à l'intérieur du conteneur (1 k à chaque fois, un total de 1000 lectures), ce qui prend environ 10 s au total, soit 100 iops. / s, en ligne avec les résultats attendus.
Deux: la redirection de port de conteneur
Container: 172.16.0.2 5000
client -----> eth0: 10.18.45.197 -------> 172.16.0.2:5000
5000
Utiliser la redirection de port pour résoudre le problème d'accès au port du conteneur-
p:
Lors de la création d'un conteneur d'application, généralement Le mappage des ports sera effectué pour permettre l'accès externe aux applications dans ces conteneurs. Vous pouvez utiliser plusieurs -p pour spécifier plusieurs relations de mappage de port.
redirection de port d'application mysql:
查看本地地址：
[root@xingdian ~]# ip a
ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:0a:5b:8b brd ff:ff:ff:ff:ff:ff
inet 192.168.245.134/24 brd 192.168.245.255 scope global dynamic ens33
valid_lft 1444sec preferred_lft 1444sec
Exécutez le conteneur: utilisez -p pour le transfert de port, transférez le 3307 local vers le 3306 du conteneur, d'autres paramètres doivent vérifier l'invite de page du conteneur de publication
[root@xingdian ~]# docker run --name mysql1 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123 daocloud.io/library/mysql
Accédez à la base de données dans le conteneur mysql1 via l'adresse IP locale: 192.168.245.134 port 3307, l'invite suivante apparaît, félicitations
[root@xingdian /]# mysql -u root -p123 -h 192.168.245.134 -P3307
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.18 MySQL Community Server (GPL)
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MySQL [(none)]>
Trois: déployer un entrepôt privé
Mise en miroir de l'entrepôt, Docker hub a officiellement fourni un registre de miroir de conteneur, qui est utilisé pour créer un entrepôt privé pour
extraire le miroir:
[root@xingdian ~]# docker pull daocloud.io/library/registry:latest
Exécutez le conteneur:
[root@xingdian ~]# docker run --restart=always -d -p 5000:5000 daocloud.io/library/registry
Remarque: si la création du conteneur échoue, une erreur de pare-feu est signalée et la solution est la suivante
[root@xingdian ~]# systemctl stop firewalld
[root@xingdian ~]# systemctl restart docker
Afficher le conteneur en cours d'exécution:
[root@xingdian ~]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1f444285bed8 daocloud.io/library/registry "/entrypoint.sh /etc/" 23 seconds ago Up 21 seconds 0.0.0.0:5000->5000/tcp elegant_rosalind
Connectez le conteneur pour afficher l'état du port:
[root@xingdian ~]# docker exec -it 1f444285bed8 /bin/sh //这里是sh 不是bash
/ # netstat -antpl //查看5000端口是否开启(容器内查看)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 :::5000 :::* LISTEN 1/registry
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
Vérifiez si vous pouvez accéder à l'entrepôt privé sur cette machine et voyez si le code d'état est 200
[root@xingdian registry]# curl -I 127.0.0.1:5000
HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Thu, 08 Oct 2020 05:34:32 GMT
Pour plus de commodité, téléchargez un miroir relativement petit, buysbox
[root@xingdian registry]# docker pull busybox
Avant de télécharger, vous devez baliser l'image et indiquer l'adresse IP et le port:
[root@xingdian ~]# docker tag busybox 本机IP：端口/busybox
C'est un miroir directement tiré de l'officiel, très lent:
[root@xingdian ~]# docker tag busybox 192.168.245.136:5000/busybox
Le Mysql suivant est la deuxième image que j'ai testée, tirée de daocloud:
[root@xingdian ~]# docker tag daocloud.io/library/mysql 192.168.245.136:5000/daocloud.io/library/mysql
Remarque: vous pouvez utiliser le nom ou l'identifiant de l'image après la balise. Le nom de l'image que j'ai utilisé ici, si vous utilisez l'image officielle, vous n'avez pas besoin d'ajouter de préfixe, mais vous devez ajouter un préfixe pour daocloud.io.
Modifiez la méthode de requête en http:
默认为https，不改会报以下错误:
Get https://master.up.com:5000/v1/_ping: http: server gave HTTP response to HTTPS client
[root@xingdian ~]# vim /etc/docker/daemon.json
{
"insecure-registries":["192.168.245.136:5000"] }
重启docker:
[root@xingdian ~]# systemctl restart docker
Téléchargez l'image dans l'entrepôt privé:
[root@xingdian ~]# docker push 192.168.245.136:5000/busybox
[root@xingdian ~]# docker push 192.168.245.136:5000/daocloud.io/library/mysql
Voir tous les miroirs de l'entrepôt privé:
[root@xingdian ~]# curl 192.168.245.130:5000/v2/_catalog
{
"repositories":["busybox"]
Quatre: déployer l'application de conteneur centos7
Intégration de Systemd: étant
donné que systemd nécessite l'autorisation CAPSYSADMIN, il a la capacité de lire le groupe de contrôle hôte. Dans CentOS7, fakesystemd a été utilisé à la place de systemd pour résoudre le problème de dépendance. Si vous souhaitez toujours utiliser systemd, vous pouvez vous référer au Dockerfile suivant:
[root@xingdian ~]# vim Dockerfile
FROM daocloud.io/library/centos:7
MAINTAINER "xingdian" [email protected]
ENV container docker
RUN yum -y swap -- remove fakesystemd -- install systemd systemd-libs
RUN yum -y update; yum clean all; \
(cd /lib/systemd/system/sysinit.target.wants/; for i in *; do [ $i == systemd-tmpfiles-setup.service ] || rm -f $i; done); \
rm -f /lib/systemd/system/multi-user.target.wants/*;\
rm -f /etc/systemd/system/*.wants/*;\
rm -f /lib/systemd/system/local-fs.target.wants/*; \
rm -f /lib/systemd/system/sockets.target.wants/*udev*; \
rm -f /lib/systemd/system/sockets.target.wants/*initctl*; \
rm -f /lib/systemd/system/basic.target.wants/*;\
rm -f /lib/systemd/system/anaconda.target.wants/*;
VOLUME [ "/sys/fs/cgroup" ]
CMD ["/usr/sbin/init"]
Ce Dockerfile supprime fakesystemd et installe systemd.
Puis construisez l'image de base:
[root@xingdian ~]# docker build --rm -t local/c7-systemd .
Pour utiliser un conteneur contenant systemd comme ci-dessus, vous devez créer un Dockerfile similaire à ce qui suit:
[root@xingdian ~]# vim Dockerfile
FROM local/c7-systemd
RUN yum -y install httpd; yum clean all; systemctl enable httpd.service
EXPOSE 80
CMD ["/usr/sbin/init"]
Construisez l'image:
[root@xingdian ~]# docker build --rm -t local/c7-systemd-httpd .
Exécutez un conteneur d'application contenant systemd:
pour exécuter un conteneur contenant systemd, vous devez utiliser l'option –privileged et monter le dossier cgroups de l'hôte. Voici un exemple de commande pour exécuter un conteneur httpd qui inclut systemd:
[root@xingdian ~]# docker run --privileged -ti -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 local/c7-systemd-httpd
Remarque: vous ne pouvez pas ajouter / bin / bash à la commande précédente. L'ajouter entraînera l'indisponibilité du service, et certains services peuvent trouver le problème d'autorisations insuffisantes mentionné précédemment, mais si vous ne l'ajoutez pas, il s'exécutera au premier plan (pas d'utilisation de -d), Vous pouvez utiliser ctrl + p + q pour le mettre en arrière-plan pour
tester la disponibilité:
# elinks --dump http://docker //下面为apache默认页面
Testing 123..
This page is used to test the proper operation of the [1]Apache HTTP
server after it has been installed. If you can read this page it means
that this site is working properly. This server is powered by [2]CentOS.
Quatre: IP de conteneur fixe Une fois le
docker installé, trois types de réseau seront créés par défaut, pont, hôte et aucun
n'affiche le réseau actuel:
[root@xingdian ~]# docker network list
NETWORK ID NAME DRIVER SCOPE
90b22f633d2f bridge bridge local
e0b365da7fd2 host host local
da7b7a090837 none null local
bridge: pontage réseau
Ce mode est utilisé pour démarrer et créer des conteneurs par défaut, donc chaque fois que le conteneur docker redémarre, les adresses IP correspondantes seront obtenues dans l'ordre, ce qui provoque le changement d'IP à chaque redémarrage du conteneur
aucun: aucun
démarrage réseau spécifié Lorsque le conteneur, vous pouvez passer network = none, le conteneur de docker n'allouera pas d'
hôte IP LAN : le réseau de
conteneur de docker de réseau hôte sera attaché à l'hôte, les deux sont interopérables.
Créer un conteneur IP fixe
1, créer un type de réseau personnalisé et spécifier le segment de réseau
[root@xingdian ~]# docker network create --subnet=192.168.0.0/16 staticnet
Grâce au réseau docker ls, vous pouvez voir qu'il existe un autre staticnet
dans le type de réseau 2. Utilisez le nouveau type de réseau pour créer et démarrer le conteneur
[root@xingdian ~]# docker run -it --name userserver --net staticnet --ip 192.168.0.2 centos:6 /bin/bash
Grâce à docker inspect, vous pouvez vérifier que l'IP du conteneur est 192.168.0.2, fermer le conteneur et le redémarrer, et constater que l'IP du conteneur n'a pas changé