Contenedor avanzado
Uno: límite de recursos de Docker
1. Herramienta de prueba de esfuerzo del sistema
El estrés
es una herramienta de prueba de esfuerzo en Linux, específicamente para aquellas cargas altas y el usuario quiere probar su sistema y monitorear estos dispositivos para que se ejecuten.
instalación
[root@xingdian ~]# yum install stress -y
Ejemplos de escenarios de prueba
测试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文件块，且不清除，会逐步将硬盘耗尽。
Descripción de los principales parámetros de la tensión (- medias seguidas de una línea media, - medias seguidas de 2 líneas medias, ambos se pueden utilizar para la tensión seguida de parámetros, diferentes expresiones):
--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. Limitar el
recurso compartido de CPU · Recursos de CPU Los
procesos en el host utilizarán la CPU a través de un mecanismo de división de tiempo La unidad de cuantificación de la CPU es la frecuencia, que es el número de operaciones que se pueden realizar por segundo. Limitar los recursos de la CPU para los contenedores no cambia la frecuencia operativa de la CPU, pero cambia el intervalo de tiempo de la CPU que cada contenedor puede usar. Idealmente, la CPU debería estar siempre en un estado de computación (y la cantidad de cálculo requerida por el proceso no excederá la capacidad de procesamiento de la CPU). ¿Cuál es la cuota de CPU del
límite
de la ventana
acoplable ? La ventana acoplable permite a los usuarios establecer un número para cada contenedor, que representa la cuota de CPU del contenedor. De forma predeterminada, la cuota de cada contenedor es 1024. Esta participación es relativa y no representa ningún significado definido por sí misma. Cuando hay varios contenedores ejecutándose en el host, la proporción de tiempo de CPU ocupado por cada contenedor es la proporción de su participación en el total. Docker ajusta dinámicamente la proporción de tiempo que cada contenedor usa la CPU en función de los contenedores y procesos que se ejecutan en el host.
Ejemplo:
si hay dos contenedores en el host que usan la CPU todo el tiempo (para simplificar la comprensión, no se consideran otros procesos en el host), y su participación de CPU es 1024, entonces la tasa de uso de CPU de los dos contenedores es del 50%; si uno de los contenedores es Si la participación se establece en 512, el uso de CPU de los dos es 67% y 33% respectivamente; si se elimina el contenedor con la participación de 1024, el uso de CPU del contenedor restante será del 100%.
Ventajas:
puede garantizar que la CPU esté en un estado de ejecución tanto como sea posible, hacer un uso completo de los recursos de la CPU y garantizar la equidad relativa de todos los contenedores;
Desventajas: no es
posible especificar un valor determinado para que el contenedor use la CPU.
Configure los parámetros del recurso compartido de la CPU:
-c --cpu-actions, su valor es un número entero.
Mi máquina es una CPU de 4 núcleos, por lo que ejecuto un contenedor de estrés y uso el estrés para iniciar 4 procesos para generar presión informática:
# 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
Use htop en otra terminal para ver el uso de recursos:
Como se ve en la figura anterior, los cuatro recursos centrales de la CPU han alcanzado el 100%. El uso de CPU de los cuatro procesos de estrés no alcanzó el 100% porque hay otras máquinas ejecutándose en el sistema.
A modo de comparación, se inicia otro contenedor con una participación de 512:
# 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
Debido a que el recurso compartido de CPU del contenedor es 1024 de forma predeterminada, el uso de CPU de estos dos contenedores debe ser aproximadamente 2: 1. La siguiente es una captura de pantalla de la supervisión después de iniciar el segundo contenedor:
Dos contenedores han iniciado cuatro procesos de estrés. El uso de CPU del proceso de estrés del primer contenedor es aproximadamente del 54%, y el uso de CPU del proceso de estrés del segundo contenedor es de aproximadamente el 25%. La proporción es aproximadamente 2: 1, que es consistente con el anterior Expectativas.
3. Limitar la cantidad de núcleos de CPU que puede usar el contenedor
-c --cpu-shares El parámetro solo puede limitar la proporción de CPU usada por el contenedor, o la prioridad, y no puede limitar definitivamente la cantidad específica de núcleos de CPU usados por el contenedor; desde la versión 1.13, docker El parámetro --cpus se proporciona para limitar la cantidad de núcleos de CPU que puede usar el contenedor. Esta característica nos permite configurar con mayor precisión el uso de la CPU del contenedor, que es un método más fácil de entender y, por lo tanto, más utilizado.
-Cpus va seguido de un número de punto flotante, que representa el número máximo de núcleos utilizados por el contenedor, que puede tener una precisión de dos decimales, lo que significa que el contenedor puede usar un mínimo de 0.01 núcleos de CPU.
Limite el contenedor para usar solo CPU de 1.5 núcleos:
# 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
Inicie tres tensiones en el contenedor para ejecutar la presión de la CPU. Si no hay límite, este contenedor hará que la tasa de uso de la CPU sea de aproximadamente 300% (es decir, ocupará la potencia de cálculo de tres núcleos). El seguimiento real es el siguiente:
Se puede ver que el uso de la CPU de cada proceso de estrés es de aproximadamente el 50% y el uso total es del 150%, lo que se ajusta a la configuración de 1,5 núcleos.
Si el valor establecido --cpus es mayor que el número de núcleos de CPU del host, Docker informará un error directamente:
# 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 varios contenedores han establecido --cpus, y su suma excede la cantidad de núcleos de CPU del host, no hará que el contenedor falle o salga. Estos contenedores competirán por el uso de la CPU. La cantidad específica de CPU asignadas depende del estado de ejecución del host. Y el valor compartido de la CPU del contenedor. Es decir, cpus solo puede garantizar la cantidad máxima de CPU que el contenedor puede usar cuando los recursos de la CPU son suficientes, y Docker no puede garantizar que el contenedor pueda usar tantas CPU bajo ninguna circunstancia (porque esto es simplemente imposible).
4. Recursos de memoria
Por defecto, Docker no limita la memoria del contenedor, lo que significa que el contenedor puede usar toda la memoria proporcionada por el host. Por supuesto, esto es algo muy peligroso: si un contenedor ejecuta software malicioso que consume memoria, o el código tiene una pérdida de memoria, es probable que la memoria del host se agote y, por lo tanto, el servicio no esté disponible. En este caso, la ventana acoplable establecerá el valor OOM (memoria insuficiente) del demonio de la ventana acoplable para reducir la prioridad de ser eliminado cuando la memoria sea insuficiente. Además, puede establecer el límite superior de uso de memoria para cada contenedor. Una vez que se excede este límite superior, el contenedor se eliminará en lugar de agotar la memoria del host.
Aunque limitar el límite de memoria superior puede proteger al host, también puede dañar los servicios del contenedor. Si el límite superior de memoria establecido para el servicio es demasiado pequeño, OOM eliminará el servicio mientras todavía está funcionando; si se establece demasiado grande, desperdiciará memoria debido al algoritmo del programador. Por lo tanto, las prácticas razonables incluyen:
realizar una prueba de esfuerzo de memoria para la aplicación, comprender la memoria que se usa según los requisitos comerciales normales y luego ingresar al entorno de producción. Debe limitar el límite superior del uso de memoria del contenedor e intentar asegurarse de que el host tenga recursos suficientes. Una vez que se pasa la supervisión Si los recursos son insuficientes, expanda o migre el contenedor. Si es posible (cuando los recursos de memoria sean suficientes), intente no usar swap. El uso de swap conducirá a cálculos de memoria complejos y es muy poco amigable para el programador.
Docker limita el uso de memoria del contenedor.
En los parámetros de inicio de la ventana acoplable, las limitaciones de memoria incluyen (el valor del parámetro es generalmente el tamaño de la memoria, que es un número positivo, seguido de las unidades de memoria b, k, m, g, correspondientes a bytes, KB, MB y GB, respectivamente) :
-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(假)，否则容器会耗尽主机内存，而且导致主机应用被杀死
Con respecto a la configuración de --memory-swap: --memory-swap debe estar disponible cuando --memory también está configurado.
Si el valor de --memory-swap es mayor que --memory, entonces la memoria total (memory + swap) que puede usar el contenedor es el valor de --memory-swap, y el valor de swap que se puede usar es --memory-swap menos --memory Tiene
el mismo valor que si --memory-swap es 0, o un valor y --memory, el tamaño del contenedor se puede usar para intercambiar la memoria dos veces, si el valor correspondiente es --memory 200M, 400M puede usar el contenedor de intercambio, entonces
si - El valor de -memory-swap es -1, entonces no hay límite para el uso de swap, lo que significa que el host puede usar tantos intercambios como el contenedor puede usarse.
Si el uso de memoria del contenedor está limitado a 64M, el contenedor se está ejecutando normalmente ( Si la memoria en el host es muy escasa, es posible que esto no esté garantizado):
# 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
.....
Y si solicita 100M de memoria, encontrará que el proceso en el contenedor se cancela (el trabajador 7 obtuvo la señal 9, la señal 9 es la señal de eliminación)
# 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. Recursos de E / S
Para los discos, los parámetros a considerar son la capacidad y la velocidad de lectura y escritura, por lo que las restricciones de disco en los contenedores también deben basarse en estas dos dimensiones. Actualmente, la ventana acoplable admite limitar la velocidad de lectura y escritura del disco, pero no hay forma de limitar la capacidad del disco que puede usar el contenedor (una vez que el disco está montado en el contenedor, el contenedor puede usar toda la capacidad del disco).
Para limitar la velocidad de lectura y escritura del disco, Docker le permite limitar directamente la velocidad de lectura y escritura del disco. Los parámetros correspondientes son:
-device-read-bps: el número máximo de bytes que el disco puede leer por segundo (bytes)
-device-write-bps: por disco El número máximo de bytes que se pueden escribir en un segundo (bytes)
Los valores de los dos parámetros anteriores son el disco y la tasa correspondiente. El límite es un número entero positivo, y la unidad puede ser kb, mb y gb.
Por ejemplo, puede limitar la velocidad de lectura del dispositivo a 1 MB:
# 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
Se necesitaron alrededor de 50 segundos para leer 50 metros del disco, lo que muestra que el límite de velocidad del disco ha funcionado.
Otros dos parámetros pueden limitar la frecuencia de lectura y escritura del disco (cuántas operaciones de lectura y escritura se pueden realizar por segundo):
–device-read-iops: el número máximo de operaciones de lectura de E / S que el disco puede realizar por segundo
–device-write-iops: el disco máximo por segundo ¿Cuántas operaciones de escritura de E / S se pueden realizar?
Los valores de los dos parámetros anteriores son el disco y el límite superior de E / S correspondiente.
Por ejemplo, puede hacer que el disco se lea hasta 100 veces por segundo:
# 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
Se puede ver en la prueba que el contenedor estableció los iops de la operación de lectura en 100, y leyó 1 metro de datos del bloque dentro del contenedor (1k cada vez, un total de 1000 lecturas), lo que toma alrededor de 10 segundos en total, que es 100 iops. / s, en línea con los resultados esperados.
Dos: reenvío de puertos de contenedores
Contenedor: 172.16.0.2 5000
cliente -----> eth0: 10.18.45.197 -------> 172.16.0.2:5000
5000
Utilice el reenvío de puertos para resolver el problema de acceso al puerto del contenedor-
p:
Al crear un contenedor de aplicaciones, generalmente El mapeo de puertos se hará para que el exterior pueda acceder a las aplicaciones en estos contenedores. Puede usar múltiples -p para especificar múltiples relaciones de mapeo de puertos.
Reenvío de puertos de la aplicación 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
Ejecute el contenedor: use -p para el reenvío de puertos para reenviar el 3307 local al 3306 del contenedor. Para otros parámetros, debe verificar el indicador de página del contenedor de publicación
[root@xingdian ~]# docker run --name mysql1 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123 daocloud.io/library/mysql
Acceda a la base de datos en el contenedor mysql1 a través de la IP local: 192.168.245.134 puerto 3307, aparece el siguiente mensaje, felicitaciones
[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)]>
Tres: implementar un almacén privado
Duplicación de almacén, Docker Hub ha proporcionado oficialmente un registro de duplicación de contenedores, que se utiliza para construir un almacén privado para
extraer la duplicación:
[root@xingdian ~]# docker pull daocloud.io/library/registry:latest
Ejecute el contenedor:
[root@xingdian ~]# docker run --restart=always -d -p 5000:5000 daocloud.io/library/registry
Nota: Si la creación del contenedor no se realiza correctamente, se informa un error de firewall y la solución es la siguiente
[root@xingdian ~]# systemctl stop firewalld
[root@xingdian ~]# systemctl restart docker
Ver el contenedor en ejecución:
[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
Conecte el contenedor para ver el estado del puerto:
[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
Compruebe si puede acceder al almacén privado en esta máquina y compruebe si el código de estado es 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
Para mayor comodidad, descargue un espejo relativamente pequeño, buysbox
[root@xingdian registry]# docker pull busybox
Antes de cargar, debes etiquetar la imagen e indicar la ip y el puerto:
[root@xingdian ~]# docker tag busybox 本机IP：端口/busybox
Este es un espejo sacado directamente del funcionario, muy lento:
[root@xingdian ~]# docker tag busybox 192.168.245.136:5000/busybox
La siguiente Mysql es la segunda imagen que probé, extraída de daocloud:
[root@xingdian ~]# docker tag daocloud.io/library/mysql 192.168.245.136:5000/daocloud.io/library/mysql
Nota: Puedes usar el nombre de la imagen o la identificación después de la etiqueta. El nombre de la imagen que usé aquí, si usas la imagen oficial, no necesitas agregar un prefijo, pero necesitas agregar un prefijo para daocloud.io.
Modifica el método de solicitud a 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
Sube la imagen al almacén privado:
[root@xingdian ~]# docker push 192.168.245.136:5000/busybox
[root@xingdian ~]# docker push 192.168.245.136:5000/daocloud.io/library/mysql
Ver todos los espejos en el almacén privado:
[root@xingdian ~]# curl 192.168.245.130:5000/v2/_catalog
{
"repositories":["busybox"]
Cuatro: implementar la aplicación de contenedor centos7
Integración con Systemd:
Debido a que systemd requiere el permiso CAPSYSADMIN, tiene la capacidad de leer el cgroup del host. En CentOS7, se ha utilizado fakesystemd en lugar de systemd para resolver el problema de dependencia. Si aún desea utilizar systemd, puede consultar el siguiente Dockerfile:
[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"]
Este Dockerfile elimina fakesystemd e instala systemd.
Luego construye la imagen básica:
[root@xingdian ~]# docker build --rm -t local/c7-systemd .
Para utilizar un contenedor que contenga systemd como se indicó anteriormente, debe crear un Dockerfile similar al siguiente:
[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"]
Construye la imagen:
[root@xingdian ~]# docker build --rm -t local/c7-systemd-httpd .
Ejecute un contenedor de aplicaciones que contenga systemd:
para ejecutar un contenedor que contenga systemd, debe usar la opción –privileged y montar la carpeta cgroups del host. El siguiente es un comando de ejemplo para ejecutar un contenedor httpd que incluye systemd:
[root@xingdian ~]# docker run --privileged -ti -v /sys/fs/cgroup:/sys/fs/cgroup:ro -p 80:80 local/c7-systemd-httpd
Nota: No puede agregar / bin / bash al comando anterior. Agregarlo hará que el servicio no esté disponible, y algunos servicios pueden encontrar el problema de permisos insuficientes mencionado anteriormente, pero si no lo agrega, se ejecutará en primer plano (sin usar -d), Puede usar ctrl + p + q para ponerlo en segundo plano para
probar la disponibilidad:
# 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.
Cuatro: IP de contenedor fijo Una vez
instalada la ventana acoplable, se crearán tres tipos de red de forma predeterminada, puente, host y ninguno
muestra la red actual:
[root@xingdian ~]# docker network list
NETWORK ID NAME DRIVER SCOPE
90b22f633d2f bridge bridge local
e0b365da7fd2 host host local
da7b7a090837 none null local
bridge: network bridging
Este modo se usa para iniciar y crear contenedores de forma predeterminada, por lo que cada vez que se reinicia el contenedor de la ventana acoplable, las direcciones IP correspondientes se obtendrán en orden, lo que hace que la IP cambie cada vez que se reinicia el contenedor
none: no se especifica el
inicio de la red Cuando el contenedor, puede pasar network = none, el contenedor de la ventana acoplable no asignará el
host IP de la LAN : la red del
contenedor de la ventana acoplable de la red del host se conectará al host, los dos son interoperables.
Cree un contenedor de IP fijo
1, cree un tipo de red personalizado y especifique el segmento de red
[root@xingdian ~]# docker network create --subnet=192.168.0.0/16 staticnet
A través de la red acoplable ls, puede ver que hay una
red estática más en el tipo de red 2. Utilice el nuevo tipo de red para crear e iniciar el contenedor.
[root@xingdian ~]# docker run -it --name userserver --net staticnet --ip 192.168.0.2 centos:6 /bin/bash
A través de la inspección de Docker, puede verificar que la IP del contenedor es 192.168.0.2, cerrar el contenedor y reiniciarlo, y encontrar que la IP del contenedor no ha cambiado