3 команды Docker, которые должны знать опытные пользователи Docker
Вот некоторые команды Docker, о которых вы, возможно, не знали, но они могут пригодиться при управлении вашими контейнерами.
Если вы какое-то время используете Docker, у вас, вероятно, уже есть простой и эффективный рабочий процесс, адаптированный для вас, который включает в себя некоторые из ваших любимых команд Docker (подкоманды, если быть технически правильными).
Например, я удалял неработающие контейнеры с помощью длинной команды, которая выглядит так: dockerContainer rm $ (dockerContainer ps -qf status=exited)
, это сработало, очевидно выбрасывая ошибка всякий раз, когда не было висячих контейнеров. Однажды это прекратилось, когда я узнал, что у нас также есть подкоманда prune
для контейнеров! Итак, теперь эта длинная команда свелась к простой очистке контейнера docker
.
Дело в том, что даже несмотря на то, что многие из нас какое-то время используют Docker, существует вероятность, что некоторые вещи могли быть упущены из виду или, возможно, даже забыты с течением времени.
В этой статье я собираюсь дать вам три подкоманды Docker, которые могут быть для вас новыми или вы не часто их используете, но я думаю, вам стоит это сделать.
Эти подкоманды могут также включать свои собственные подкоманды.
1. Системная подкоманда
В Docker есть команда system
, которая предоставляет вам некую информацию системного уровня, связанную с Docker. На самом деле вы уже некоторое время используете одну из его подкоманд. Помните информацию о докере
? На самом деле эта команда представляет собой информацию о системе Docker
.
Чтобы узнать больше об этой подкоманде и о том, что она предлагает, запустите для нее параметр --help
.
➟ docker system --help
Usage: docker system COMMAND
Manage Docker
Commands:
df Show docker disk usage
events Get real time events from the server
info Display system-wide information
prune Remove unused data
Run 'docker system COMMAND --help' for more information on a command.
Давайте рассмотрим каждую из этих подкоманд, поскольку я считаю, что все они очень важны.
Докер-система df
Вы когда-нибудь оказывались в ситуации, когда дисковое пространство вашего сервера казалось почти полным? Чтобы проверить, являются ли это контейнеры (работающие/тома), вы, вероятно, использовали команду du
непосредственно в корне данных.
Для использования du
в корне данных требуется доступ sudo
.
✗ du -h --max-depth=1 /var/lib/docker
du: cannot read directory '/var/lib/docker': Permission denied
4.0K /var/lib/docker
Мало того, чтобы точно узнать, сколько томов или образов выделено, вам придется запустить команду несколько раз.
➟ sudo du -h --max-depth=0 /var/lib/docker/volumes && \
sudo du -h --max-depth=0 /var/lib/docker/image && \
sudo du -h --max-depth=0 /var/lib/docker/
Гораздо лучшая альтернатива — вызвать команду docker system df
. Это автоматически определит корень данных и, соответственно, распечатает всю информацию об использовании диска контейнерами, изображениями и томами Docker.
Вот что показывает моя текущая система (это новая установка)
➟ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 10 1 84.17MB 84.17MB (100%)
Containers 1 1 8.219MB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Удаление системы Docker
Если вы когда-нибудь хотели удалить (1) все неиспользуемые сети, (2) висячие изображения, (3) остановленные контейнеры, (4) все неиспользуемые тома, велика вероятность, что вы использовали или привыкли использовать четыре отдельные команды для достижения работа.
docker network prune && \
docker image prune && \
docker volume prune && \
docker container prune
Если вы раньше не знали о container prune
, как я, то команда становится еще больше. Нам повезло, все это можно сделать с помощью простой команды, а именно docker system prune --volumes
.
По умолчанию сокращение системы docker
не удаляет тома, для этого вам нужно использовать опцию --volumes
. Эта команда дополнительно также очищает кеш сборки.
Вы можете использовать опцию -f
, чтобы избежать (иногда) раздражающего запроса. См. пример ниже:
➟ docker system prune --volumes -f
Deleted Containers:
672d39c1a78969887f411ce9139e74e5b21c31fccf2bcf8c1190a9e166089ede
Deleted Networks:
Example
SSHnet
Dummy
Deleted Volumes:
dummy
Total reclaimed space: 0B
Другие параметры включают -a
, который удаляет все неиспользуемые изображения, а не только висячие.
Системные события Docker
Возможно, эта команда не всегда полезна, но я думаю, что каждый должен знать об этом.
события системы docker
или события docker
для краткости предоставляют вам события в реальном времени непосредственно для демона docker (dockerd
). Это может помочь отслеживать определенные события, например, когда изображение было удалено.
Посмотрите скриншот ниже, чтобы лучше это понять.
2. Подкоманда контекста
Это еще одна красивая подкоманда, о которой, насколько мне известно, мало кто знает. Контекстом для любого выполнения команды Docker является пара пар ключ-значение, которые включают, помимо прочего, конечную точку, хост, возможно, какой-либо файл конфигурации и т. д.
После создания контекста его можно будет повторно использовать позже.
Одним из наиболее важных практических вариантов использования, особенно для меня, было создание отдельных контекстов для отдельных серверов, на которых у меня работает докер. Поскольку большая часть моей работы вращается вокруг этого, вместо того, чтобы каждый раз заходить на сервер, я использую свой локальный клиент с удаленным док-сервером через SSH.
Позвольте мне показать вам, как я достигаю этого с помощью контекстов докера.
Сначала у меня есть сервер, развернутый на Linode, на котором работает докер. Если бы мне нужно было получить доступ к удаленному демону Docker без контекста, я бы использовал следующую команду:
➟ docker --host ssh://[email :7770 ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bb4fa8390ab7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 2 hours ago Up 2 hours reverse-proxy_letsencrypt_1
ccdda507facb jwilder/nginx-proxy "/app/docker-entrypo…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp reverse-proxy_reverse_proxy_1
Таким образом, чтобы получить доступ к удаленному демону, мне придется либо использовать псевдоним docker
для docker --host ssh://[email :7770
, либо использовать переменную среды <DOCKER_HOST. Но это очень затрудняет переключение на другие хосты. Более простая альтернатива — просто создать контекст.
Следующая команда создает контекст с именем remote
для конечной точки Docker с хостом, отличным от локального.
docker context create remote --description "Remote docker server" --docker "host=ssh://[email :7770"
Вывод выглядит следующим образом:
➟ docker context create remote --description "Remote docker server" --docker "host=ssh://[email :7770"
remote
Successfully created context "remote"
Теперь вы можете использовать опцию -c
с docker
, если хотите быстро что-то проверить или для повторяющихся операций измените контекст на этот новый.
С опцией -c
:
➟ docker -c remote ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bb4fa8390ab7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 2 hours ago Up 2 hours reverse-proxy_letsencrypt_1
ccdda507facb jwilder/nginx-proxy "/app/docker-entrypo…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp reverse-proxy_reverse_proxy_1
В контексте docker используйте [CONTEXT_NAME]
:
➟ docker context use remote
remote
Current context is now "remote"
~
➟ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
bb4fa8390ab7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 2 hours ago Up 2 hours reverse-proxy_letsencrypt_1
ccdda507facb jwilder/nginx-proxy "/app/docker-entrypo…" 2 hours ago Up 2 hours 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp reverse-proxy_reverse_proxy_1
Чтобы выйти из контекста, используйте подкоманду use
с default
в качестве имени контекста:
➟ docker context use default
default
Current context is now "default"
~
➟ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3. Подкоманды паузы и возобновления паузы
Большие развертывания (приложения) теперь разделены на несколько компонентов, более известных как микросервисы. Когда вы развертываете их с помощью чего-то вроде docker-compose, иногда происходит так, что один компонент запускается раньше того, от которого он зависит. Это проблема, поскольку, поскольку его зависимость (или зависимости) еще не запущена, этот компонент не запустится.
Вы можете смягчить эту проблему, используя политики перезапуска в Docker, но они не предотвращают заполнение журнала неудачными попытками. Вначале я просто останавливал контейнер/сервис до тех пор, пока зависимость не запустится полностью.
Лучший способ — просто приостановить контейнер на некоторое время, и как только необходимые службы будут успешно запущены, вы можете возобновить работу контейнера, и дальше все будет идти нормально.
Хотя контейнеры быстро раскручиваются, это еще более быстрый способ решения такой проблемы.
Синтаксис pause
и unpause
довольно прост.
docker pause [CONTAINER_NAME|ID]
docker unpause [CONTAINER_NAME|ID]
На этом статья завершается. Если я найду еще такие команды, полезные или интересные, я соответствующим образом обновлю эту статью.
Есть ли у вас команда Docker, которая, по вашему мнению, должна была быть в этом списке? Дайте мне знать в комментариях ниже.