Если вы какое-то время используете Docker, у вас, вероятно, уже есть адаптированный для вас простой и эффективный рабочий процесс, который включает в себя некоторые из ваших любимых команд Docker (если это технически правильные подкоманды).
Например, я использовал для удаления неработающих контейнеров длинную команду, которая выглядит так, как этот docker container rm $ (docker container ps -qf status = exited), она работала, очевидно, выдавая ошибку всякий раз, когда не было застрявших контейнеров.
Я прекратил ее использование когда я узнал, что у нас также есть подкоманда prune для контейнеров!
Итак, теперь эта длинная команда свелась к простой.
Дело в том, что даже несмотря на то, что многие из нас уже некоторое время используют Docker, есть вероятность, что некоторые вещи могли быть упущены из виду или, возможно, даже забыты с течением времени.
В этой статье я собираюсь показать вам три подкоманды Docker, которые могут быть для вас новыми, или вы их мало используете, но я думаю, вам стоит их изучить.
Эти подкоманды могут также включать свои собственные подкоманды.
1. Подкоманда system
В Docker есть команда system, которая дает вам некоторую информацию на системном уровне, связанную с Docker.
На самом деле вы уже некоторое время используете одну из его подкоманд.
Помните Docker info?
Эта команда на самом деле является docker system info
Чтобы узнать больше об этой подкоманде и о том, что она предлагает, запустите для нее параметр –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.Давайте рассмотрим каждую из этих подкоманд, так как я думаю, что все они очень важны.
Docker system df
Вы когда-нибудь были в ситуации, когда дисковое пространство вашего сервера казалось почти заполненным?
Чтобы проверить, действительно ли это контейнеры (запущенные/тома), вы, вероятно, использовали команду du непосредственно в данных root.
Data-root – это место системе, где Docker хранит все данные, связанные с его состоянием.
Это включает, помимо прочего, образа (слои), тома, информацию, связанную с сетью, плагины.
Использование 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.
Система автоматически обнаружит data-root, и соответственно, выведет всю информацию о выделенных данных.
Вот что показывает моя текущая система (это новая установка)
➟ 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 system prune
Если вы когда-либо хотели удалить (1) все неиспользуемые сети, (2) висящие образа, (3) остановленные контейнеры, (4) все неиспользуемые тома, есть большая вероятность, что вы использовали или привыкли использовать четыре отдельные команды для достижения этих целей.
docker network prune && \
docker image prune && \
docker volume prune && \
docker container pruneК счастью для нас, все это можно сделать с помощью простой команды, а именно docker system prune –volumes.
По умолчанию docker system prune не удаляет тома, для этого вам нужно использовать параметр –volumes.
Эта команда дополнительно очищает кеш сборки.
Вы можете использовать параметр -f, чтобы не выводить (иногда) раздражающий запрос.
См. Пример ниже:
➟ docker system prune --volumes -f
Deleted Containers:
672d39c1a78969887f411ce9139e74e5b21c31fccf2bcf8c1190a9e166089ede
Deleted Networks:
Example
SSHnet
Dummy
Deleted Volumes:
dummy
Total reclaimed space: 0BDocker system events
Эта команда может быть полезна далеко не всегда, но я думаю, что каждый должен знать о ней.
docker system events иили docker events предоставляют вам события в реальном времени непосредственно от демона docker (dockerd).
Это может помочь отслеживать определенные события, например, когда образ было удален.
См. Снимок экрана, показанный ниже, чтобы лучше понять это.
2. Подкоманда context
Это еще одна красивая подкоманда, о которой, насколько мне известно, мало кто знает.
Context при выполнении любой команды Docker – это пара пар ключ-значение, которые включают, но не ограничиваются конечной точкой, хостом, возможно, некоторым файлом конфигурации и т.д.
После того, как вы создали контекст, его можно будет повторно использовать позже.
Один из самых больших практических вариантов использования, особенно для меня, – это создание отдельных контекстов для отдельных серверов, на которых работает Docker.
Поскольку большая часть моей работы вращается вокруг этого, вместо того, чтобы каждый раз входить на сервер, я использую свой локальный клиент до сервера для удаления Docker через SSH.
У меня развернут сервер, на котором запущен Docker.
Если бы мне нужно было получить доступ к удаленному демону Docker без контекстов, я бы использовал такую команду, как следующая:
➟ docker --host ssh://debdut@194.195.116.210: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 –host ssh://debdut@194.195.116.210:7770, либо использовать переменную среды DOCKER_HOST.
Но это очень затрудняет переключение на другие хосты.
Более простая альтернатива – просто создать контекст.
Следующая команда создает контекст с именем remote для конечной точки Docker
docker context create remote --description "Remote docker server" --docker "host=ssh://debdut@194.195.116.210:7770"
Результат выглядит так:
➟ docker context create remote --description "Remote docker server" --docker "host=ssh://debdut@194.195.116.210: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 используйте [CONTEXT_NAME]:
➟ docker context use default
default
Current context is now "default"
~
➟ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES3. Подкоманда pause и unpause
Большое развертывание (приложения) теперь разделено на несколько компонентов, более известных как микросервисы.
Когда вы развертываете их с помощью чего-то вроде docker-compose, иногда случается, что один компонент запускается раньше, чем тот, от которого он зависит.
Это действительно проблема, потому что, поскольку его зависимость (или зависимости) еще не запущена, этот компонент не запустится.
Вы можете смягчить эту проблему, используя политики перезапуска в Docker, но они не предотвращают переполнение логов неудачными попытками.
Вначале я просто останавливал контейнер/службу до тех пор, пока зависимость не запустится полностью.
Лучше всего просто приостановить контейнер на некоторое время, и после того, как необходимые службы будут успешно запущены, вы можете возобновить работу контейнера.
Синтаксис команд довольно прост.
docker pause [CONTAINER_NAME|ID]
docker unpause [CONTAINER_NAME|ID]
Заключение
На этом мы заканчиваем эту статью.
Если я найду еще такие команды, полезные или интересные, я соответствующим образом обновлю эту статью.
У вас есть команда Docker, которая, по вашему мнению, должна была быть в этом списке?
Дайте мне знать в комментариях !
