Docker desktop is shutting down что делать

Устранение неполадок при разработке Visual Studio с помощью Docker

При работе со средствами контейнеров Visual Studio могут возникнуть проблемы при сборке или отладке приложения. В этой статье описаны некоторые распространенные действия по устранению неполадок.

Общий доступ к корпоративным данным не включен. Включение совместного использования томов в параметрах Docker CE для Windows (только контейнеры Linux)

Общий доступ к файлам должен управляться только в том случае, если вы используете Hyper-V с Docker. Если вы используете WSL 2, следующие действия не являются обязательными, и параметр общего доступа к файлам не будет отображаться. Чтобы устранить эту проблему, выполните следующие действия:

1. Щелкните правой кнопкой мыши Docker для Windows в области уведомлений и выберите Параметры.
2. Выберите Ресурсы>Общий доступ к файлам и поделитесь папкой, к которую необходимо получить доступ. Совместное использование всего системного диска возможно, но не рекомендуется.

Visual Studio выводит запрос, если общие диски не настроены.

Не удается запустить отладку

Одна из причин этой проблемы может быть связана с устаревшими компонентами отладки в папке профиля пользователя. Выполните следующие команды, чтобы удалить эти папки, чтобы последние компоненты отладки загружались в следующем сеансе отладки.

• del %userprofile%\vsdbg
• del %userprofile%\onecoremsvsmon

Ошибки, связанные с сетью при отладке приложения

Попробуйте выполнить скрипт, скачанный из раздела Очистка сети узла контейнера, который обновит сетевые компоненты на хост-компьютере.

Отказано в подключении

При использовании Docker для macOS может возникнуть ошибка при ссылке на папку /usr/local/share/dotnet/sdk/NuGetFallbackFolder. Добавьте папку на вкладку Общий доступ к файлам в Docker.

Группа пользователей Docker

При работе с контейнерами в Visual Studio может возникнуть следующая ошибка:

Чтобы использовать Docker Desktop, текущий пользователь должен быть в группе docker-users. Добавьте себя в группу docker-users, а затем выйдите из Windows.

Чтобы иметь разрешения на работу с контейнерами Docker, необходимо быть членом группы docker-users. Чтобы добавить себя в группу в Windows 10 или более поздней версии, выполните следующие действия.

1. В меню Пуск откройте раздел Управление компьютером.
2. Разверните узел Локальные пользователи и группы и выберите Группы.
3. Найдите группу docker-users , щелкните правой кнопкой мыши и выберите Добавить в группу.
4. Добавьте учетную запись пользователя или учетные записи.
5. Чтобы эти изменения вступили в силу, выйдите из нее и снова войдите в систему.

Вы также можете использовать net localgroup команду в командной строке администратора, чтобы добавить пользователей в определенные группы.

net localgroup docker-users DOMAIN\username /add 

В PowerShell используйте функцию Add-LocalGroupMember .

Мало места на диске

По умолчанию Docker хранит образы в папке %ProgramData%/Docker/ , которая обычно находится на системном диске, *C:\ProgramData\Docker*. Чтобы изображения не занимали ценное место на системном диске, можно изменить расположение папки образа. Для этого:

1. Щелкните правой кнопкой мыши значок Docker на панели задач и выберите Параметры.
2. Выберите Подсистема Docker.
3. В области редактирования добавьте graph параметр свойства со значением нужного расположения для образов Docker:

 "graph": "D:\\mypath\\images" 

Выберите Применить & перезапуск. Эти действия изменяют файл конфигурации по адресу %ProgramData%\docker\config\daemon.json. Ранее созданные образы не перемещаются.

Несоответствие типов контейнера

При добавлении поддержки Docker в проект вы выбираете контейнер Windows или Linux. Если узел Docker Server не настроен для запуска контейнера того же типа, что и целевой объект проекта, появится сообщение об ошибке следующего вида:

Чтобы устранить эту проблему, щелкните правой кнопкой мыши значок Docker для Windows на панели задач и выберите Переключиться на контейнеры Windows. или Переключиться на контейнеры Linux. .

Другие проблемы

Другие проблемы, с которыми вы столкнулись, см. в статье Проблемы с Microsoft/DockerTools .

Ссылки

Исправление проблем под Docker. Казалось бы, при чём здесь GIT?

Докер под Windows — это постоянные приключения. То ему нужно обновить операционку, иначе последние версии не ставятся, то он забывает, как подключаться к сети. В общем, каждый день от него новости. «Поставил и забыл» — это не про Docker Desktop for Windows. Особенно, когда он используется не совсем так, как рекомендуют его разработчики. А они почему-то не одобряют подключение внешних windows сетевых дисков в качестве локальных. И совсем не одобряют доступ к к таким сетевым папкам, которые расположены ещё и на host машине. Пишут, что это ужас-ужас с точки зрения безопасности, требуют всяких ключей типа:

cap_add:
— SYS_ADMIN
— DAC_READ_SEARCH

для работы команды mount в контейнере и прочая, и прочая.

В общем, когда в очередной раз после выгрузки контейнеров на сервер заказчика сервисы перестали видеть сетевые диски, я не особо удивился. Так уже бывало, и даже была написана пошаговая инструкция для группы поддержки, как и что перезагружать, когда ломаются сетевые настройки докера.

Так что я открываю свою инструкцию и начинаю действовать. Перезапускаю контейнеры — не помогает. Перезапускаю через docker-compose с пересозданием инфраструктуры — не помогает. Сбрасываю настройки Docker к заводским, восстанавливаю параметры виртуалки, загружаю заново образы, запускаю через docker-compose — опять всё по старому — не видит сеть. Точнее не подключается к сетевым шарам, хотя пинг из контейнера до SMB сервера проходит нормально. Последний пункт — перезагрузку сервера и переустановку Docker, пока пропускаю, так как перезагружать сервер очень не хочется. На этом инструкция кончилась.

Ок, перехожу на свою домашнюю машину, тут у меня тоже Docker под Windows, но чуть более новой версии. Проверяю на нём. Те же яйца:

Ага. Ну неужели, думаю, Docker накатил обновление с какой-то безопасностью и теперь мои скрипты из-за этого не запускаются? Последняя проверка — начисто удалить Docker с машины, и поставить заново. Это должно быть круче сброса к заводским настройкам. Проделываю весь перечень из предыдущего шага, только в дополнение к этому ещё и перезагружаю свою машину, чтобы уж совсем железно. Ставлю Docker c нуля, заливаю образы, запускаю docker-compose — ёпрст! Все сервисы как не видели сетевых шар, так и продолжают писать при загрузке «mount error(22): Invalid argument»

Пробую запустить скрипт по строкам из командной строки: подключаюсь к контейнеру, запускаю по очереди команды и вижу, что всё подключается и работает как надо:

mkdir -p $SMB_MOUNT_POINT mount -t cifs $SMB_SHARE $SMB_MOUNT_POINT -o user=$SMB_USER,password=$SMB_PASSWORD,vers=2.0 ls $SMB_MOUNT_POINT 

То есть, это что же, какая-то хрень с передачей параметров в скрипт при запуске контейнера?

Ищем ещё идеи. Все варианты с перезагрузкой докера отмели, остались варианты с возможными изменениями в родительском образе. У меня образ собирается на основе openjdk:8-jdk-alpine, конкретной версии не указано, так что какие-нибудь улучшения безопасности могли сломать мои скрипты. Может поменяли что-то в OpenJDK или дочернем Alpine?

Проверяю логи проекта, пробую выбрать более старые openjdk:8-jdk-alpine-3.8, openjdk:8-jdk-alpine-3.7 и т.д. — каждый раз пересобираю контейнер, проверяю — всё по-старому.

Чёрт подери! Может я что-то всё-таки поменял в своей сборке? Выгружаю из GIT’а версию проекта месячной давности, собираю — те же глюки. Трёхмесячной давности — проблема всё ещё тут. Как же так? Что изменилось? Конфигурация докера к настоящему моменту гарантировано рабочая, конфигурация образа — тоже не поменялась, исходники проекта те же самые (GIT всё сохраняет). Чудес не бывает — надо понять, где всё-таки появились изменения. В проде вручную запускаю команды подключения к шарам — так до перезапуска сервисы будут работать нормально и иду спать. Утро вечера мудренее.

Связи нет, но вы держитесь!

Наутро приходит идея — что пора, видимо, узнать, а что собственно говоря не нравится скрипту при выполнении.

Сообщение «mount error(22): Invalid argument» — это не сильно информативно. Нахожу, что есть волшебный ключик -х для баша с которой он выводит отладочную инфу при выполнениии скриптов.

Начинаем отладку внутри sh:

/ # sh -x /entry-point.sh ' echo 'Mount ///Exchange/Pipeline to /pipeline Mount ///Exchange/Pipeline to /pipeline ' mkdir -p '/pipeline ' mount -t cifs ///Exchange/Pipeline /pipeline -o 'user=,password=,vers=2.0 mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) mount: mounting ///Exchange/Pipeline on /pipeline failed: Invalid argument ' ls '/pipeline + exec

И тут появляются какие-то непонятные моменты — строка начинается с кавычек, потом кавычки в конце… Откуда кавычки?

Идея — может запуск с помощью настоящего bash будет информативнее?

Инсталлирую в контейнер BASH:

apk add bash

/ # bash -x /entry-point.sh ' echo 'Mount ///Exchange/Pipeline to /pipeline Mount ///Exchange/Pipeline to /pipeline + mkdir -p $'/pipeline\r' + mount -t cifs ///Exchange/Pipeline /pipeline -o $'user=,password=,vers=2.0\r' mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) mount: mounting ///Exchange/Pipeline on /pipeline failed: Invalid argument + ls $'/pipeline\r' + exec

Блин, тут вроде, когда строка начинается с плюса — это хорошо, но появились какие-то \r и параметры $’. ‘

Ставим Midnight Commander, чтобы уж экспериментировать с удобствами apk add mc и открываем скрипт на редактирование, а там:

Оппа! ^M в конце каждой строки. Ну-ка, ну-ка, смотрим в локальном проекте — а что у нас с окончаниями строк. CRLF. Работаем под Windows, однако.

Меняем в этом конкретно файле CRLF на LF (да здравствует Notepad++!), собираем проект — бинго! Работает как надо.

Почему раньше было ок, а сейчас всё полетело? Смотрю по коммитам — не было никаких перемен. И тут вспоминаю, что GIT умеет на лету править символы перевода строк текстовых файлов. А я на днях подключил новый репозитарий, и возможно выгрузил оттуда все файлы с конвертацией в CRLF.

В итоге добавляем в проект файл .gitattributes, с указанием, что в отдельных файлах надо-таки сохранять символы конца строк как в UNIX:

# Set the default behavior, in case people don't have core.autocrlf set. * text=auto # Declare files that will always have LF line endings on checkout. *.sh text eol=lf 

Мораль — иногда виновник даже не попадает в круг первоначальных подозреваемых.

Постскриптум

После обновления на последнюю версию Docker Desktop for Windows 2.2.0.3 всё обратно перестало работать. На этот раз я сразу пошёл внутрь контейнеров, и начал отладку. Оказалось, что перестал работать IP адрес 10.0.75.1 для доступа к хост машине, DockerNat теперь удалён из системы, а виртуалка DockerDesktopVM даже не имеет внешнего сетевого адаптера, т.е. связь с ней идёт не через стандартную сеть, а как-то иначе. И для доступа к хосту надо пользоваться host.docker.internal. Товарищи разработчики так и написали, что

DockerNAT has been removed from Docker Desktop 2.2.0.0 as using an IP address to communicate from the host to a container is not a supported feature. To communicate from a container to the host, you must use the special DNS name host.docker.internal.

Ок, поправил конфиги для тестового окружения, база данных подцепилась, пинг из контейнера до host.docker.internal проходит, а вот сетевые диски не подключаются. Пробую запустить mount вручную из шелла, и получаю знакомую ошибку «mount error(22): Invalid argument».

Убираю по очереди аргументы — запускаю просто «mount -t cifs //host.docker.internal/playground /pipeline» — вроде работает, но стучится от пользователя «root».

Добавляю пользователя: mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser — спрашивает пароль и подключается!

Полный вариант тоже работает:

mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword

а вот «mount -t cifs //host.docker.internal/playground /pipeline -o user=smbuser,password=smbpassword,vers=2.0» не пашет.

Меняю последний параметр на vers=2.1 — ура, работает!

Похоже, что Docker в последней версии сделал свою собственную имплементацию SMB сервера с блекджеком, но без поддержки 2.0. Ерунда, конечно, по сравнению с другими новостями.

Всем добра, сил и упорства!

Приложение в контейнере — Docker: Основы

В этом уроке мы научимся запускать готовое приложение в Docker и разберем все элементы, необходимые для его работы и обслуживания. Так мы сможем сложить цельную картину использования Docker, которую затем разберем по частям, изучая образы, файловую систему, сеть и другие составляющие.

Для примера возьмем Node.js приложение, созданное с помощью веб-фреймворка Fastify. Если вы не знакомы с Fastify или Node.js, то ничего страшного, потому что в уроке мы работаем только с Docker. Все то же самое можно сделать с практически любым другим приложением.

После запуска это приложение отдает по HTTP страницу с приветственным текстом. Это приложение создано специально для курса. Оно уже упаковано в Docker и доступно для запуска под именем hexletcomponents/devops-example-app. Исходный код доступен здесь .

Запуск

Команда запуска этого приложения выглядит так:

# -p - проброс портов # -e - переменная окружения docker run -p 3000:3000 \ -e SERVER_MESSAGE="Hexlet Awesome Server" \ hexletcomponents/devops-example-app Unable to find image 'hexletcomponents/devops-example-app:latest' locally 9cc8d6197555: Download complete 45796f425418: Download complete cd666498bb13: Download complete 57b89cfa1177: Download complete 339fa49b454d: Download complete 1d1b4cabe4ab: Download complete de82c3f2de88: Download complete 42c077c10790: Download complete fd2a83b16756: Download complete f691a4cef6f1: Download complete 633d34d77448: Download complete f428e85c5188: Download complete > devops-example-app@1.0.0 start > fastify start server/plugin.js -a 0.0.0.0 -l info -P 21:46:46 ✨ Server listening at http://0.0.0.0:3000 

После запуска команды мы увидим следующий процесс:

1. Скачивание образа, в случае первого старта
2. Запуск приложения командой, указанной внутри образа: fastify start server/plugin.js -a 0.0.0.0 -l info -P . Эта команда была указана при создании образа. Подробно мы разберем этот момент в соответствующем уроке.
3. Вывод лога запущенного приложения 21:46:46 ✨ Server listening at http://0.0.0.0:3000

Если все сделано правильно, открыв в браузере http://0.0.0.0:3000 или http://localhost:3000 , вы получите такую страницу:

Теперь если снова посмотреть в терминал, то там в лог добавятся новые записи:

Логи

Независимо от того, с каким приложение мы работаем, Docker требует от его создателей определенного подхода в логировании. Логи не должны сохраняться в файлы, их нужно выводить в STDOUT. Благодаря этому мы видим их в терминале после запуска приложения. Откуда берется такое требование?

В 12 факторах есть пункт посвященый логированию . Он говорит о том, что масштабируемое приложение не должно самостоятельно заниматься хранением и обработкой логов. Вместо этого, каждый процесс должен отправлять логи в STDOUT, что позволяет гибко и универсально управлять процессом сбора логов. К тому же это удобно для разработчиков и администраторов, так как им не нужно разбираться с самим приложением, чтобы понимать как посмотреть его логи.

Так как в нашем случае приложение запускается через Docker, то Docker и является той системой, которая управляет сбором логов. Если посмотреть его документацию , то можно увидеть, что Docker поддерживает десяток мест, куда он может отправлять логи самостоятельно. Кроме этого есть возможность подключать к нему внешние плагины, для поддержки любых других систем логирования. Среди поддерживаемых из коробки: syslog, journald, awslogs, fluentd, gcplogs и другие.

Автозапуск

Запущенное, описанным выше способом приложение, завершится при закрытии терминала. Поэтому подобный способ подходит только для разработки. В продакшене же, для запуска нужно демонизировать приложение. Для этого используется флаг -d :

-d -p 3000:3000 \ -e SERVER_MESSAGE="Hexlet Awesome Server" \ hexletcomponents/devops-example-app 

При таком запуске приложение оказывается в фоне. Оно останется открытым даже если мы закроем терминал, но все же этого недостаточно для полноценного продакшена. Представьте если внутри приложения случится ошибка и оно остановится. Что произойдет в этом случае? По умолчанию Docker ничего не будет делать. Если контейнер остановился изнутри, то больше он не запустится. Это поведение можно изменить, так как Docker работает в режиме супервизора. Мы можем указать ему на необходимость перезапуска в случае ошибок:

-d -p 3000:3000 --restart on-failure \ hexletcomponents/devops-example-app 

В случае указания on-failure контейнер перезапустится если внутри произошла ошибка. В большинстве случаев это и есть желаемое поведение, но иногда нужно перезапускать контейнер в любом случае, для этого используется вариант always . Такой контейнер перезапустится даже если его попытаться остановить командой docker stop . Если же нужно исключить этот вариант, то подойдет unless-stopped .

В реальной жизни перезапуск контейнеров, почти всегда, выполняется внешними, по отношению к Docker, средствами. Либо это Kubernetes с его настройками, либо Systemd.

Проброс портов

Наше приложение стартует веб-сервер, который слушает определенный порт на каком-то ip-адресе. В большинстве веб-серверов это 127.0.0.1:80, то есть localhost. Без использования Docker, такой запуск позволяет работать с веб-сервером локально, например, открывая страницы в браузере. С Docker же, подобный запуск не сработает как мы ожидаем.

Сеть внутри Docker контейнера изолированная. Localhost внутри контейнера и снаружи это разные вещи. Поэтому для выхода наружу Docker использует механизм проброса портов, который состоит из двух частей:

Во-первых, нужно сделать так, чтобы сервер внутри контейнера стартовал по адресу 0.0.0.0. В нашем приложении это достигается явным указанием в строке запуска:

# По умолчанию используется порт 3000 fastify start server/plugin.js -a 0.0.0.0 -l info -P 

Запущенное таким образом приложение все еще недоступно снаружи, так как Docker требует явного указания того, какой порт мы хотим пробросить. По умолчанию, наше приложение стартует на порту 3000, поэтому его и нужно пробрасывать. Делается это с помощью флага -p .

-p 3000:3000 hexletcomponents/devops-example-app # -p : 

Формат задается двумя числами, где справа – это порт внутри контейнера, который мы хотим выставить наружу, а слева порт, через который мы сможем попасть во внутрь. В нашем примере они совпадают, но это не обязательно, внешний порт может быть любым свободным.

Переменные окружения

Приложения соответствующие 12 факторам конфигурируются переменными окружениями. Сами переменные задаются либо на уровне системы, либо при запуске приложения. В случае с Docker первый способ не работает, так как контейнер изолирован от внешних переменных окружения. Работает только второй способ, но не так как это происходит обычно. Без Docker мы можем сделать так:

NAME=value

Docker такую переменную проигнорирует. Передача переменных окружения в контейнер работает только через явное указание:

-p 3000:3000 \ -e SERVER_MESSAGE="Hexlet Awesome Server" \ hexletcomponents/devops-example-app 

Передавать можно любое количество переменных:

docker run -p 3000:3000 -e NAME=value -e SERVER_MESSAGE=»Hexlet Awesome Server» hexletcomponents/devops-example-app

Как приложение отображается на контейнеры?

1. Все приложение — один контейнер, внутри которого поднимается дерево процессов: приложение, веб-сервер, база данных и все в этом духе
2. Каждый запущенный контейнер — атомарный сервис. Другими словами каждый контейнер представляет собой ровно одну программу, будь то веб-сервер или приложение

На практике все преимущества Docker достигаются только со вторым подходом. Во-первых, сервисы, как правило, разнесены по разным машинам и нередко перемещаются по ним (например, в случае выхода из строя сервера), во-вторых, обновление одного сервиса не должно приводить к остановке остальных.

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Docker failed to initialize Docker Desktop is shutting down — Error in Windows Fixed

docker failed to initialize docker failed to initialize docker desktop is shutting down docker failed to initialize windows 11 docker failed to initialize windows 10 how to fix docker failed to initialize docker failed to initialize after update docker failed to initialize docker desktop is shutting down docker failed to initialize docker desktop is shutting down windows 11 docker failed to initialize docker desktop is shutting down after update docker failed to initialize docker desktop is shutting down error docker failed to initialize shutting down docker desktop fails to start Deleted settings and locked-directories files but still i get error Deleted Docker and Docker Desktop still getting error how to fix docker desktop failed to start how to see failed docker container logs why is docker failing to start docker desktop is not functioning as expected docker is failing to start docker desktop unable to start The operation has timed out. Docker failed to initialize shutting down windows 11 Docker failed to initialize shutting down windows 10 docker failed to start docker desktop failed to start windows 11 docker desktop failed to start docker desktop is unable to detect a hypervisor how to get rid of docker failed to initialize docker failed to initialize docker failed to run backend processes [SOLVED] Docker Failed to Start Error «Docker Desktop is shutting down» always after the update Docker Failed to Initialize on Windows Why does Docker fail to initialize? How long does it take to start the Docker engine? Why is Docker Desktop data not running?

Показать больше

Войдите , чтобы оставлять комментарии