Хотите знать, что такое MYROUTER.LOCAL? Вы пришли в нужное место. В этой статье мы расскажем вам о том же и о том, как войти в него.
MYROUTER.LOCAL — это веб-адрес по умолчанию, который используется для взаимодействия с окном веб-управления маршрутизатора. Он также используется для взаимодействия с различными настройками и функциями маршрутизатора. Если вам нужно посетить окно веб-утилиты вашего маршрутизатора, используйте этот веб-адрес. Но если вы столкнулись с ошибкой в myrouter.local/login, используйте IP-адрес вашего маршрутизатора в локальной сети.
Как войти в MYROUTER.LOCAL?
Процесс входа в систему маршрутизатора играет решающую роль в обеспечении взаимодействия пользователей с веб-интерфейсом маршрутизатора. Только после того, как вы получите одобрение, вы сможете войти в систему, используя правильные учетные данные для входа в соответствующее поле. После завершения процесса настройки рекомендуется изменить пароль для входа по умолчанию.
Теперь взгляните на шаги, которые вы должны выполнить, чтобы войти в интерфейс MY ROUTER LOCAL.
Откройте предпочтительный браузер на рабочем столе, подключенном к сети маршрутизатора. Рабочий стол не должен быть подключен к каким-либо другим расширенным или беспроводным сетям.
В адресной строке браузера введите myrouter.local и нажмите Enter. Вы попадете на страницу входа в роутер.
На вкладке имени пользователя введите «admin» и введите пароль, который вы установили в процессе установки. Если вы еще не изменили пароль, введите «admin».
Когда вы закончите, нажмите «Войти», чтобы войти в http://myrouter.local.
Примечание
Если вы впервые подключаетесь к веб-интерфейсу маршрутизатора, вам не нужно проходить через окно входа в маршрутизатор. Как только вы подключитесь к Wi-Fi маршрутизатора, вы будете автоматически перенаправлены на веб-интерфейс маршрутизатора.
Как получить доступ к странице администратора маршрутизатора с помощью MYROUTER.LOCAL?
Существует несколько способов доступа к веб-странице настройки маршрутизатора. Используя страницу настройки маршрутизатора, вы можете выбрать базовые или расширенные параметры. С помощью локального веб-портала настройки вы можете включить защиту Wi-Fi, переадресацию портов и настройки игровой консоли.
Первый шаг — убедиться, что светодиод, соответствующий порту, к которому подключен ваш рабочий стол, включен. После подключения рабочего стола к роутеру вы сможете это сделать. Внимательно следя за процессом, вы можете получить подробные инструкции о трудностях, с которыми вы сталкиваетесь при использовании myrouter local.
Откройте браузер по умолчанию и введите частный IP-адрес для доступа к myrouterlocal/admin, который дает вам доступ к расширенным настройкам маршрутизатора. Сделайте это, введя знаковый адрес myrouter local в адресной строке браузера.
Вы будете перенаправлены на страницу myrouterlocal/login для доступа к веб-странице. Просто заполните вкладки с именем пользователя и паролем, и вы сможете посетить веб-страницу настройки.
Советы
При выполнении этих задач специалисты рекомендуют использовать проводное соединение маршрутизатора и компьютера.
Что делать, если MYROUTERLOCAL не работает?
Если эта ссылка не работает, вы не сможете взаимодействовать с веб-интерфейсом. Невозможно вносить коррективы, исправлять или изменять настройки в настройках сети без взаимодействия с панелью инструментов этого интерфейса.
Чтобы решить эту проблему, вот несколько вариантов устранения неполадок:
1. Проверьте аппаратное соединение.
Проверьте физическое соединение между настольным компьютером и маршрутизатором. Если соединение не установлено должным образом, это приведет к некоторым проблемам. Подключите роутер для доступа к веб-интерфейсу роутера.
2. Автоматическое
изменение IP-адреса IP-адрес вашего маршрутизатора может измениться автоматически, что может привести к некоторым проблемам. DHCP, используемый функцией устройства, автоматически назначает IP-адрес компьютера. Если маршрутизатор включил функцию DHCP, возможно, именно поэтому ему автоматически назначается IP-адрес. Перезагрузите маршрутизатор, чтобы решить проблему. Когда вы закончите сброс, вы можете использовать IP-адрес по умолчанию для доступа к интерфейсу вашего маршрутизатора. IP-адрес роутера 192.168.1.1.
3. Используйте только авторизованные браузеры
Вы всегда должны использовать утвержденный браузер. Использование авторизованного браузера может привести к проблеме myrouter.local. Используйте веб-браузеры, такие как Internet Explorer, Mozilla Firefox и Google Chrome. Если вы используете другой браузер, переключитесь на авторизованный браузер.
4. Удалить историю
Иногда заполненный кеш и история могут стать причиной того, что вы не получаете доступ к этому интерфейсу. Итак, удалите проблему, чтобы узнать, решает ли она проблему. По мере накопления кэш-памяти и истории браузера немедленно удаляйте их.
5. DNS Hijacking Malware
DNS может ограничить взаимодействие пользователя с интерфейсом этого URL-адреса. Он может заразить ваш рабочий стол и повлиять на доступ маршрутизатора. Итак, перейдите к «Сетевое подключение» и нажмите «Центр управления сетями и общим доступом». Выберите «Изменить настройки адаптера», щелкните правой кнопкой мыши параметр «Подключение по локальной сети» и, наконец, нажмите «Свойства». Выберите TCP/IPV4 и нажмите «Свойства». Теперь введите необходимые данные в поля Альтернативный DNS и Предпочтительный DNS-сервер. Сканируйте на вирусы и убедитесь, что антивирус обновлен.
Примечание
В случае возникновения проблем с сетью обратитесь к поставщику услуг Интернета для решения проблемы. Если ваши шаги по устранению неполадок не увенчались успехом, восстановите настройки маршрутизатора по умолчанию с помощью процесса сброса. Нажмите и удерживайте кнопку сброса в течение 10 секунд, чтобы перезагрузить маршрутизатор.
Шаги по изменению пароля окна MYROUTER.LOCAL
Вы можете изменить пароль для входа в окно входа в маршрутизатор в любое время, используя веб-интерфейс маршрутизатора. Если при настройке маршрутизатора вы пропустите процесс ввода пароля администратора, вам придется использовать пароль администратора по умолчанию для взаимодействия с веб-интерфейсом маршрутизатора. Пароль по умолчанию — «admin».
Шаги по изменению пароля веб-интерфейса маршрутизатора следующие:
Откройте предпочтительный браузер на рабочем столе, подключенном к сети маршрутизатора.
В строке веб-адреса введите http://myrouter.local. у вас также есть возможность ввести 192.168.1.1. как URL-адрес.
Затем нажмите «Войти», и он будет перенаправлен на страницу настройки маршрутизатора.
Перейдите в настройки маршрутизатора и нажмите «Подключение».
Найдите параметр «Пароль маршрутизатора» на основной вкладке и нажмите «Изменить».
В поле «Новый пароль» введите предпочитаемый пароль.
Введите подсказку пароля роутера в данное поле.
Чтобы сохранить настройки, нажмите «Применить».
Примечание
При назначении пароля для окна входа необходимо выполнить все требования. Помните, что поле пароля чувствительно к регистру. Если вы ошибетесь с паролем для входа, вы не сможете получить доступ к интерфейсу.
Microsoft реализует свою угрозу поставить водяные знаки на Windows 11 при установке на ПК, которые не соответствуют минимальным требованиям производителя программного обеспечения.
Новости о таких вопиющих водяных знаках уже давно ходят по кругу, и тестировщики время от времени видят предупреждение как часть предварительных сборок Insider. Те, кто полагал, что Microsoft не будет выпускать такие предупреждения для населения в целом, оказались неправы, поскольку водяной знак теперь появляется в последней версии Release Preview.
Многие пользователи обратились в социальные сети, чтобы подчеркнуть это изменение, с изображениями, показывающими белый текст Microsoft в правом нижнем углу рабочего стола Windows 11. Сообщение прямо гласит: «Системные требования не выполнены. Перейдите в «Настройки», чтобы узнать больше».
Считается, что водяной знак влияет на все версии Windows 11, включая Windows 11 Pro, и похож на предупреждение, которое появляется, если операционная система не активирована.
Решение Microsoft визуально помечать неподдерживаемое оборудование будет рассматриваться миллионами пользователей, чьи ПК официально не входят в список, как еще один удар по зубам. Согласно документации фирмы, для поддержки процессоров Intel требуется как минимум процессор Coffee Lake 8-го поколения, в то время как поддержка AMD распространяется только на части Ryzen серии 2000 Zen +.
Обойти эти требования было несложно, и Microsoft ранее предлагала развернуть Windows 11 на старом оборудовании, если пользователи готовы взять на себя риск.
«Установка Windows 11 на устройство, которое не соответствует минимальным системным требованиям Windows 11, не рекомендуется. Если вы решите установить Windows 11 на неподходящее оборудование, вы должны быть уверены, что рискуете столкнуться с проблемами совместимости», — говорится в официальном руководстве фирмы.
В данной статье расcкажу как можно легко переименовать сетевые интерфейсы в Ubuntu18.04|20.04|22.04.
Ещё в Ubuntu 16.04 для настройки сети мы использовали файл /etc/network/interfaces и при помощи команды service networking restart запускали сделанные изменения, в указанном выше файле, в работу. Но уже начиная с Ubuntu 18.04 разработчики внедрили новый тип настройки сети – NetPlan, а также пересмотрели названия сетевых интерфейсов. Это вызвало некоторые неудобства с настройкой сети. Представьте что вы используете USB-modem, который в свою очередь поднимает сетевой интерфейс, и вместо названия eth0 выдает вам что-то вроде этого: nse45trg6504. Как вы думаете в конфигурационном файле утилиты netplan будет удобно вбивать данное название? Думаю что НЕТ!
Но как изменить название интерфейса на более привычное? Да очень просто.
Переименовываем сетевой интерфейс в Ubuntu 18.04|20.04|22.04
Запускаем терминал на нашей системе. Сделать это можно нажав ctrl+T, ну или при помощи ssh подключения.
Далее смотрим какие интерфейсы присутствуют в нашей системе, для этого вводим следующую команду:
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 4c:ed:fb:da:8c:c9 brd ff:ff:ff:ff:ff:ff
Альтернатива данной команде может быть старая команда ifconfig -a, но разработчики в сборках удалили её. Если хотите можете установить и её, для меня же она более наглядно выводит результат.
Как видно из вывода у меня в системе присутствует всего два интерфейса – это локальная петля lo и сетевой интерфейс ens0f1. Вот как раз второй интерфейс мы и будем переименовывать.
Для этого запоминаем или скопируйте у данного интерфейса его MAC-адрес (информация в выводе выше). У меня он следующий:4c:ed:fb:da:8c:c9
Далее открываем файл настроек утилиты netplan:
sudo nano /etc/netplan/00-installer-config.yaml
у вас может быть другое название файла, но суть от этого не меняется.
Вот теперь внесем изменения в данный файл.
Помните что в данном файле нужно четко соблюдать количество пробелов для блоков и ни в коем случае не использовать табуляцию.
Было
# This is the network config written by 'subiquity'
network:
version: 2
ethernets:
ens0f1:
dhcp4: true
Стало
# This is the network config written by 'subiquity'
network:
version: 2
ethernets:
eth0:
dhcp4: true
match:
macaddress: 4c:ed:fb:da:8c:c9
set-name: eth0
После изменений вводим команду для проверки и применении настроек
sudo netplan try
если ошибок в файле не было, то должно появится вот такое окно с отчетом в 120 секунд:
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
Configuration accepted.
Если же появились ошибки, то их необходимо исправить. В выводе будет указанна строка и порядковый номер в котором допустили ошибку. Еще раз повторюсь – не забываем о yaml синтаксисе при редактировании конфигурационного файла.
Сегодня поговорим о том, как можно пробросить PPPoE соединение на Linux к другим машинам находящимся в локальной сети.
Предыстория
Завел я у себя дома небольшой сервер для всяких мирских нужд (торрент качалка, NAS-сервер, MiniDLNA-сервер, Web-сервер, Cloud-сервер ну и так далее.) Вот все это великолепие решил настроить в виртуальной среде. Для достижения поставленной цели выбрал проект Proxmox. На данный момент это версия Proxmox 7.1-4. В качестве провайдера выступает не без известный RT, у которого в качестве идентификации клиента используется протокол PPPoE. Вот тут-то и начинаются танцы с бубном:
В Proxmox v7 используется пакет – ifupdown2, для управления сетевыми настройками. Мне же чтобы поднять PPPoE соединение нужен был пакет pppoeconf у которого в зависимостях еще используется пакет – ifupdown. Ну как вы понимаете данные пакеты мешают работе друг друга. Встал выбор:
либо сносить с родительской машины, а это сам Proxmox, пакет ifupdown2 и устанавливать pppoeconf.
либо же поднимать виртуальную машину, а у же в ней использовать PPPoE соединение.
Я решил идти по второму пути, а для этого необходимо было пробросить PPPoE в локальную сеть. В этом мне помогла утилита pppoe-relay идущая в зависимостях пакета pppoe.
Синтаксис команды pppoe-relay
pppoe-relay [опции]
Опции pppoe-relay
–S interface – Добавляет выбранный интерфейс в список интерфейсов, управляемых pppoe-relay. К этому интерфейсу могут быть подключены только PPPoE-серверы.
-С interface – Добавляет выбранный интерфейс в список интерфейсов, управляемых pppoe-relay. К этому интерфейсу могут быть подключены только PPPoE-клиенты.
-B interface – Добавляет интерфейс в список интерфейсов, управляемых pppoe-relay. К этому интерфейсу могут быть подключены как PPPoE-клиенты, так и серверы.
-n num – Позволяет не более num одновременных сеансов PPPoE. Если не указано, то значение по умолчанию равно 5000. num может варьироваться от 1 до 65534.
-i timeout – Задает тайм-аут простоя сеанса. Если оба одноранговых узла в сеансе простаивают более 30 секунд, сеанс завершается. Если тайм-аут указан равным нулю, сеансы никогда не будут прекращены из-за простоя.
Обратите внимание, что процедура истечения срока действия сеанса ожидания никогда не выполняется чаще, чем каждые 30 секунд, поэтому тайм-аут является приблизительным. Значение тайм-аута по умолчанию составляет 600 секунд (10 минут).
-F – Опция приводит к тому, что pppoe-relay не разветвляется на задний план; вместо этого он остается на переднем плане.
-h – Опция печатает краткое сообщение об использовании и завершает работу.
Примеры pppoe-relay
pppoe-relay -S eth0 -C eth1
Приведенный выше пример ретранслирует кадры между PPPoE-клиентами в сети eth1 и PPPoE-сервером в сети eth0.
pppoe-relay -B eth0 -B eth1
В данном пример применяется прозрачная ретрансляция. Кадры ретранслируются между любым набором клиентов и серверов в сетях eth0 и eth1.
pppoe-relay -S eth0 -C eth1 -C eth2 -C eth3
Этот пример ретранслирует кадры между сервером в сети eth0 и клиентами в сетях eth1, eth2 и eth3.
Как узнать имена интерфейсов.
Для того чтобы узнать какие у вас присутствуют интерфейсы необходимо набрать следующую команду:
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 3c:d9:2b:f9:f4:21 brd ff:ff:ff:ff:ff:ff
inet6 fe80::3ed9:2bff:fef9:f44c/64 scope link
valid_lft forever preferred_lft forever
3: enp3s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 3c:d9:2b:f9:f4:22 brd ff:ff:ff:ff:ff:ff
4: enp4s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master vmbr0 state DOWN group default qlen 1000
link/ether 3c:d9:2b:f9:f4:23 brd ff:ff:ff:ff:ff:ff
5: enp4s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master vmbr1 state DOWN group default qlen 1000
link/ether 3c:d9:2b:f9:f4:24 brd ff:ff:ff:ff:ff:ff
.....
или же если у вас установлен пакет net-tool, то команда может быть вот такой:
После использования утилиты pppoe-relay я перекинул кадры PPPoE в локальную сеть. На Виртуальной машине установил пакет pppoeconf и с помощью него установил соединение с интернетом. Далее уже настроил данную виртуальную машину на раздачу интернета в локальную сеть, т.е. поднял на ней DHCP-сервер, DNS-сервер и NAT. Теперь все это великолепие работает без перебоев. В будущем планирую установить USB-modem для бесперебойного канала связи. Ведь как говорится может случится всякое, а особенно с провайдером RT.
В Helm есть много замечательных инструментов, но хранение диаграмм всегда было проблемой. Давайте посмотрим, как мы можем сделать этот процесс намного проще!
Одним из больших преимуществ понимания того, как работает экосистема контейнеров, является то, что вы можете использовать один и тот же шаблон для нескольких спецификаций.
Не так давно Helm объявил, что будет поддерживать артефакты OCI, которые представляют собой не что иное, как открытую спецификацию OCI для распространения образов контейнеров и других типов данных, называемых артефактами.
Эта спецификация, как и все другие спецификации OCI, не зависит от облака, что делает ее фантастическим инструментом для работы.
Контейнерные записи
Запись контейнера (CR) или реестр — это то, что приходилось использовать всем, кто когда-либо имел дело с контейнерами. CR — это место, где мы храним наши образы контейнеров, поэтому мы можем получать их из любого места и в любое время.
По сути, изображение — это набор файлов, которые имеют примерно такую структуру:
Файл index.json представляет собой список всех доступных манифестов, то есть это список всех изображений, доступных в определенном месте. В нашем случае это список всех карт руля.
Каждый файл внутри blobs/sha256 представляет собой JSON, который идентифицирует артефакт, будь то изображение или диаграмма. Этот JSON соответствует спецификации OCI для файлов SHA.
Если коротко, то это список настроек, описывающих характеристики BLOB, его настройки, свойства, слои файловой системы, а также начальные команды.
Обратите внимание, что у нас есть дифференциация mediaType, в то время как обычный образ Docker имеет тип application/vnd.oci.image.config.v1+json.
Здесь у нас тип application/vnd.cncf.helm.config, то же самое и со слоями, каждый слой изображения OCI имеет тип application/vnd.oci.image.layer.v1.tar+gzip, а здесь у нас есть только формат .tar.gz.
Размещение диаграмм в Реестре контейнеров Azure
Размещение диаграмм Helm в Azure CR очень похоже на их локальное хранение. Вам необходимо иметь доступ к Azure через Azure CLI. Мы предполагаем, что у вас уже есть Azure CLI, поэтому давайте создадим наш ACR.
Сначала мы должны создать нашу группу ресурсов, а затем ACR с помощью команд:
az group create -n helm-reg -l eastus
az acr create -n chartregistry$RANDOM -g helm-reg --sku Basic -o tsv --query loginServer
Теперь мы собираемся войти в наш реестр, используя управляемые ключи Azure, но нам нужно включить административный контроль с помощью az acr update -n $ACR —admin-enabled true.
Затем выполните следующие две команды, чтобы получить учетные данные для входа и сохранить их в оболочке:
Теперь мы можем войти в наш реестр с помощью Helm helm registry login $ACR —username $ACRUSER —password $ACRPASS, и отсюда у нас уже настроен наш реестр.
Давайте создадим еще один артефакт с помощью helm chart save hrepo $ACR/hrepo:2.1.3(в качестве примера я буду использовать диаграмму из пустого репозитория с именем hrepo). Затем мы подтолкнем его с помощью helm chart push $ACR/hrepo:3.8.0.
Как только он будет там, мы сможем перечислить все в репозитории с помощью команды Azure CLI:
az acr repository show -n $ACR --repository hrepo
Обратите внимание, что у нас будет именно то, что мы отправили:
Хотя использовать Helm легко, все же не существует «простого» способа разместить диаграмму Helm как своего рода частную запись.
Хотя в Helm есть отличные инструменты, такие как Chart Museum, они все же не являются полностью стандартными, и для легкой распределенной разработки важно, чтобы у нас были открытые стандарты, которым может следовать каждый в целом.
Helm недавно перевел поддержку реестра OCI с экспериментальной на общую функцию, что является убедительным признаком того, что экосистема контейнеров становится все лучше.
Сегодня мы поговорим о том, как Docker использует дисковое пространство хостовой машины, а также разберемся в том, как это пространство освободить от ошметков неиспользуемых образов и контейнеров.
Общее потребление
Docker – крутая штука, наверное сегодня мало кто в этом сомневается. Всего несколько лет назад этот продукт предоставил нам совершенно новый способ построения, доставки и запуска любого окружения, позволяя значительно сэкономить ресурсы процессора и оперативной памяти. В дополнение к этому (а для кого-то это будет даже самым важным) Docker позволил нам невероятно упростить и унифицировать управление жизненным циклом используемых рабочих сред.
Однако, за все эти прелести современной жизни приходится платить. Когда мы запускаем контейнеры, скачиваем или создаем собственные образы, разворачиваем сложные экосистемы, нам приходится платить. И платим мы, в том числе, дисковым пространством.
Если вы никогда не задумывались о том, сколько же места реально занято на вашей машине Docker’ом, то можете быть неприятно удивлены выводом этой команды:
$ docker system df
Здесь отображено использование диска Docker’ом в различных разрезах:
образы (images) – общий размер образов, которые были скачаны из хранилищ образов и построены в вашей системе;
контейнеры (containers) – общий объем дискового пространства, используемый запущенными контейнерами (имеется ввиду общий объем слоев чтения-записи всех контейнеров);
кэш сборки (build cache) – временные файлы, сгенерированные процессом построения образов (при использовании инструмента BuildKit, доступного начиная с Docker версии 18.09).
Готов поспорить, что уже после этого простого перечисления вы горите желанием почистить диск от мусора и вернуть к жизни драгоценные гигабайты (прим. перев.: особенно, если за эти гигабайты вы ежемесячно перечисляете арендную плату).
Использование диска контейнерами
Каждый раз при создании контейнера на хостовой машине в каталоге /var/lib/docker создается несколько файлов и каталогов, среди которых стоит отметить следующие:
Каталог /var/lib/docker/containers/ID_контейнера – при использовании стандартного драйвера логгирования именно сюда сохраняются журналы событий в JSON-формате. Слишком подробные логи, а также логи, которые никто не читает и не обрабатывает иными способами, часто становятся причиной переполнения дисков.
Каталог /var/lib/docker/overlay2 – содержит слои чтения-записи контейнеров (overlay2 – предпочитаемые драйвер в большинстве дистрибутивов Linux). Если контейнер сохраняет данные в своей файловой системе, то именно в этом каталоге они и будут размещены.
Давайте представим себе систему, на которой установлен девственно чистый Docker, ни разу не участвовавший в запуске контейнеров и сборке образов. Его отчет об использовании дискового пространства будет выглядеть так:
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 0 0 0B 0B
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Запустим какой-нибудь контейнер, например, NGINX:
$ docker container run --name www -d -p 8000:80 nginx:1.16
Что происходит с диском:
образы (images) занимают 126 Мб, это тот самый NGINX, который мы запустили в контейнере;
контейнеры (containers) занимают смешные 2 байта.
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 1 126M 0B (0%)
Containers 1 1 2B 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Судя по выводу, у нас еще нет пространства, которое мы могли бы высвободить. Так как 2 байта это совершенно несерьезно, давайте представим, что наш NGINX неожиданно для всех написал куда-то 100 Мегабайт данных и создал внутри себя файл test.img именно такого размера.
Снова исследуем использование дискового пространства на хосте. Мы увидим, что контейнер (containers) занимает там 100 Мегабайт.
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 1 126M 0B (0%)
Containers 1 1 104.9MB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Думаю, ваш пытливый мозг уже задается вопросом, где же находится наш файл test.img. Давайте его поищем:
$ find /var/lib/docker -type f -name test.img
/var/lib/docker/overlay2/83f177...630078/merged/test.img
/var/lib/docker/overlay2/83f177...630078/diff/test.img
Не вдаваясь в подробности можно отметить, что файл test.img удобно расположился на уровне чтения-записи, управляемом драйвером overlay2. Если же мы остановим наш контейнер, то хост подскажет нам, что это место, в принципе, можно высвободить:
# Stopping the www container
$ docker stop www
# Visualizing the impact on the disk usage
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 1 126M 0B (0%)
Containers 1 0 104.9MB 104.9MB (100%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Как мы можем это сделать? Удалением контейнера, которое повлечет за собой очистку соответствующего пространства на уровне чтения-записи.
С помощью следующей команды вы можете удалить все установленные контейнеры одним махом и очистить ваш диск от всех созданных ими на уровне чтения-записи файлов:
$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Deleted Containers:
5e7f8e5097ace9ef5518ebf0c6fc2062ff024efb495f11ccc89df21ec9b4dcc2
Total reclaimed space: 104.9MB
Итак, мы высвободили 104,9 Мегабайта удалением контейнера. Но так как мы уже не используем скачанный ранее образ, то он тоже становится кандидатом на удаление и высвобождение наших ресурсов:
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 1 0 126M 126M (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Внимание: до тех пор, пока образ используется хотя бы одним контейнером, вы не сможете использовать этот трюк.
Субкоманда prune, которую мы использовали выше, дает эффект только на остановленных контейнерах. Если мы хотим удалить не только остановленные, но и запущенные контейнеры, следует использовать одну из этих команд:
Заметки на полях: если при запуске контейнера использовать параметр —rm, то при его остановке будут высвобождено все дисковое пространство, которое он занимал.
Использование диска образами
Несколько лет назад размер образа в несколько сотен мегабайт был совершенно нормальным: образ Ubuntu весил 600 Мегабайт, а образ Microsoft .Net – несколько Гигабайт. В те лохматые времена скачивание одного только образа могло нанести большой урон вашему свободному месту на диске, даже если вы расшаривали уровни между образами. Сегодня – хвала великим – образы весят намного меньше, но даже в этом случае можно быстро забить имеющиеся ресурсы, если не принимать некоторых мер предосторожности.
Есть несколько типов образов, которые напрямую не видны конечному пользователю:
intermediate образы, на основе которых собраны другие образы в – они не могут быть удалены, если вы используете контейнеры на базе этих самых «других» образов;
dangling образы – это такие intermediate образы, на которые не ссылается ни один из запущенных контейнеров – они могут быть удалены.
С помощью следующей команды вы можете проверить наличие в вашей системе dangling образов:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
none none 21e658fe5351 12 minutes ago 71.3MB
Удалить их можно следующим способом:
$ docker image rm $(docker image ls -f dangling=true -q)
Мы можем использовать также субкоманду prune:
$ docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y
Deleted Images:
deleted: sha256:143407a3cb7efa6e95761b8cd6cea25e3f41455be6d5e7cda
deleted: sha256:738010bda9dd34896bac9bbc77b2d60addd7738ad1a95e5cc
deleted: sha256:fa4f0194a1eb829523ecf3bad04b4a7bdce089c8361e2c347
deleted: sha256:c5041938bcb46f78bf2f2a7f0a0df0eea74c4555097cc9197
deleted: sha256:5945bb6e12888cf320828e0fd00728947104da82e3eb4452f
Total reclaimed space: 12.9kB
Если мы вдруг захотим удалить вообще все образы (а не только dangling) одной командой, то можно сделать так:
$ docker image rm $(docker image ls -q)
Использование диска томами
Тома (volumes) применяются для хранения данных за пределами файловой системы контейнера. Например, если мы хотим сохранить результаты работы какого-либо приложения, чтобы использовать их как-то еще. Частым примером являются базы данных.
Давайте запустим контейнер MongoDB, примонтируем к нему внешний по отношению к контейнеру том, и восстановим из него бэкап базы данных (у нас он доступен в файле bck.json):
# Running a mongo container
$ docker run --name db -v $PWD:/tmp -p 27017:27017 -d mongo:4.0
# Importing an existing backup (from a huge bck.json file)
$ docker exec -ti db mongoimport
--db 'test'
--collection 'demo'
--file /tmp/bck.json
--jsonArray
Данные будут находиться на хостовой машине в каталоге /var/lib/docker/volumes. Но почему не на уровне чтения-записи контейнера? Потому что в Dockerfile образа MongoDB каталог /data/db (в котором MongoDB по умолчанию хранит свои данные) определен как том (volume).
Заметки на полях: многие образы, в результате работы которых должны создаваться данные, используют тома (volumes) для сохранения этих самых данных.
Когда мы наиграемся с MongoDB и остановим (а может даже и удалим) контейнер, том не будет удален. Он продолжит занимать наше драгоценное дисковое пространство до тех пор, пока мы явно не удалим его такой командой:
$ docker volume rm $(docker volume ls -q)
Ну или мы можем использовать уже знакомую нам субкоманду prune:
$ docker volume prune
WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
d50b6402eb75d09ec17a5f57df4ed7b520c448429f70725fc5707334e5ded4d5
8f7a16e1cf117cdfddb6a38d1f4f02b18d21a485b49037e2670753fa34d115fc
599c3dd48d529b2e105eec38537cd16dac1ae6f899a123e2a62ffac6168b2f5f
...
732e610e435c24f6acae827cd340a60ce4132387cfc512452994bc0728dd66df
9a3f39cc8bd0f9ce54dea3421193f752bda4b8846841b6d36f8ee24358a85bae
045a9b534259ec6c0318cb162b7b4fca75b553d4e86fc93faafd0e7c77c79799
c6283fe9f8d2ca105d30ecaad31868410e809aba0909b3e60d68a26e92a094da
Total reclaimed space: 25.82GB
luc@saturn:~$
Использование диска для кэша сборки образов
В Docker 18.09 процесс создания образов претерпел некоторые изменения благодаря инструменту BuildKit. С помощью этой штуки увеличивается скорость процесса, оптимизируется управление хранением данных и безопасностью. Здесь мы не будем рассматривать все детали этого замечательного инструмента, остановимся лишь нам том, как он затрагивает вопросы использования дискового пространства.
Предположим, что у нас есть совершенно простое приложение Node.Js:
файл index.js запускает простой HTTP сервер, который отвечает строкой на каждый полученный запрос:
файл package.json определяет зависимости, из которых используется только expressjs для запуска HTTP сервера:
$ cat index.js
var express = require('express');
var util = require('util');
var app = express();
app.get('/', function(req, res) {
res.setHeader('Content-Type', 'text/plain');
res.end(util.format("%s - %s", new Date(), 'Got Request'));
});
app.listen(process.env.PORT || 80);
FROM node:13-alpine
COPY package.json /app/package.json
RUN cd /app && npm install
COPY . /app/
WORKDIR /app
EXPOSE 80
CMD ["npm", "start"]
Давайте соберем образ обычным способом, без использования BuildKit:
$ docker build -t app:1.0 .
Если мы проверим использование дискового пространства, то увидим, что место занимают только базовый образ (node:13-alpine) и конечный образ (app:1.0):
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 2 0 109.3MB 109.3MB (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B
Давайте соберем вторую версию нашего приложения, уже с использованием BuildKit. Для этого нам лишь необходимо установить переменную DOCKER_BUILDKIT в значение 1:
$ DOCKER_BUILDKIT=1 docker build -t app:2.0 .
Если мы сейчас проверим использование диска, то увидим, что теперь там участвует кэш сборки (buid-cache):
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 2 0 109.3MB 109.3MB (100%)
Containers 0 0 0B 0B
Local Volumes 0 0 0B 0B
Build Cache 11 0 8.949kB 8.949kB
Для его очистки воспользуемся следующей командой:
$ docker builder prune
WARNING! This will remove all dangling build cache.
Are you sure you want to continue? [y/N] y
Deleted build cache objects:
rffq7b06h9t09xe584rn4f91e
ztexgsz949ci8mx8p5tzgdzhe
3z9jeoqbbmj3eftltawvkiayi
Total reclaimed space: 8.949kB
Очистить все!
Итак, мы рассмотрели очистку дискового пространства, занятого контейнерами, образами и томами. В этом нам помогает субкоманда prune. Но ее можно использовать и на системном уровне docker, и она очистит все, что только сможет:
$ docker system prune
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Are you sure you want to continue? [y/N]
Если вы по каким-либо причинам экономите дисковое пространство на машине с Docker, то периодический запуск этой команды стоит ввести в привычку.
Так как в Docker более менее адекватный механизм удаления старых образов и контейнеров появился в версии 1.13: PR 26108 (за счет параметра prune который удаляет все старые контейнеры volume без контейнеров и образа без контейнеров), но зная что с каждой новой версией кол-во багов и проблем ростет, я лично не рискую обновляться, потому использую такие механизмы:
