Docker не запускается linux

не запускаются контейнера в Docker не Debian 10

не получается запустить контейнер никакой даже стандартное hello-world не идет Докер скачивает образ создает контейнер он присутствует по % docker ps -a пытаешься запустить, последнее сообщение в доступе отказано Debian установлен на виртуалке ,на сервере . docker: Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting «proc» to rootfs at «/proc» caused: mount through procfd: permission denied: unknown.

а твоя виртуалка видимо сама контейнер, вот и не даёт вложенные создавать; ядро в /boot есть? lsmod / modprobe работают?

и вообще, брось эту гадость (докер)

да так и есть виртуалка в контейнере обойти никак?

Если у тебя задача запустить недодокер на недовиртуалке (как итоговая самоцель) — то никак. Если задача более практически направленная, то конечно можно другое решение придумать, и даже не одно:

1. отказаться от бесполезного докера
2. заменить недовиртуалку на полноценную виртуалку, вложившись в это дело лишних 100р в месяц
3. захостить всё у себя дома бесплатно, хоть виртуалкой, хоть на настоящем железе, и не иметь ограничений

надо запустить OpenMeetings а для него нужно видео-аудио через MySQL — Docker а оно контейнеры не запускает может можно какой-нить костыль присобачить или контейнер в контейнере не судьба

Источник

Не может запустить докера на Ubuntu 16.04 с драйвером не поддерживаемая ошибка

Попробованный для выполнения недавно установленного докера на Ubuntu 16.04

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

5 ответов

По-видимому, удаление папки не является лучшим планом действий, потому что Вы удаляете любые контейнеры, у Вас было выполнение. Лучший план действий устанавливает пакет отдельно оплачиваемых предметов изображения Linux, который соответствует Вашему текущему ядру.

Проблема в том, что aufs не поддерживается в ядре 4.0.x

По-видимому, удаление aufs из докера:

Как упомянуто в комментарии @ dragon788 ниже, это приведет к удалению всех существующих контейнеров AUFS.

В зависимости от Вашей версии ядра можно переключиться на overlay или overlay2 . Проверьте свою версию ядра с uname -a :

• >= 3.18 : используйте overlay
• >= 4.0 : также overlay2 должен поддерживаться

, Просто обновляют Ваш драйвер устройства хранения данных в /etc/default/docker с чем-то как:

и услуги Докера перезапуска.

Я провел некоторое исследование, и я нашел ответ, я смог устранить проблему при помощи overlay2 как драйвер устройства хранения данных, я перешел по ссылке ниже для этого: https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver /

Ниже шага я взял для устранения проблемы: Остановите Докера.

$ sudo systemctl останавливают Копию докера содержание/var/lib/docker к временному местоположению.

Редактирование/etc/docker/daemon.json. Если это еще не существует, создайте его. При предположении, что файл был пуст, добавьте следующее содержание.

$ sudo systemctl запускаются, докер

Проверяют, что демон использует overlay/overlay2 драйвер устройства хранения данных. $ sudo информация о докере

После того, как это, я смог выполнить контейнер докера на своих «16.04.2 LTS (Гостеприимный Xerus)» sudo выполненный докер — ubuntu

Для Докера CE, только некоторые конфигурации, тестируется, и Ваша работа system’s ядро, не может поддерживать каждый драйвер устройства хранения данных. В целом следующие конфигурации работают над последними версиями дистрибутива Linux:

дистрибутив Linux Поддерживаемый Докер драйверов устройства хранения данных CE на Ubuntu aufs, devicemapper, overlay2 (Ubuntu 14.04.4 или позже, 16.04 или позже), наложение, zfs

Источник

Исправление проблем под 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»

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

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

Ищем ещё идеи. Все варианты с перезагрузкой докера отмели, остались варианты с возможными изменениями в родительском образе. У меня образ собирается на основе 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:

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

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

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

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

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

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

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

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

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

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

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

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,vers=2.0» не пашет.

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

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

Источник

🐳 Как исправить ошибку, когда контейнер Docker не запускается

Это руководство поможет исправить ошибку:

container is marked for removal and cannot be started

Как и ожидалось, ту же ошибку можно увидеть при прямом использовании docker-compose.

Я попытался перезапустить службу Docker

Опять не сработало:

Это был nginx на хосте

Теперь я могу без проблем запускать сервис.

• Аудит ИБ (44)
• Вакансии (10)
• Закрытие уязвимостей (98)
• Книги (27)
• Мануал (1 937)
• Медиа (66)
• Мероприятия (38)
• Мошенники (22)
• Обзоры (724)
• Обход запретов (33)
• Опросы (3)
• Скрипты (106)
• Статьи (292)
• Философия (77)
• Юмор (17)

Anything in here will be replaced on browsers that support the canvas element

Источник

Установка Docker на Linux

Мы рассмотрим процесс установки Docker на системы семейства Linux — а именно, CentOS, Fedora и Ubuntu.

Ubuntu

Docker на Ubuntu ставится, относительно, просто.

Обновляем список пакетов:

Устанавливаем докер командой:

apt-get install docker docker.io

Разрешаем автозапуск докера и стартуем его:

systemctl enable docker

systemctl start docker

CentOS 8

dnf install wget

Скачиваем конфигурационный файл для репозитория докер:

wget -P /etc/yum.repos.d/ https://download.docker.com/linux/centos/docker-ce.repo

Теперь устанавливаем docker:

dnf install docker-ce docker-ce-cli

И разрешаем автозапуск сервиса и стартуем его:

systemctl enable docker —now

CentOS 7

yum install wget

Скачиваем файл репозитория:

wget -P /etc/yum.repos.d/ https://download.docker.com/linux/centos/docker-ce.repo

yum install docker-ce docker-ce-cli containerd.io

Запускаем его и разрешаем автозапуск:

systemctl enable docker —now

Fedora

Устанавливаем плагин, дающий дополнительные инструменты при работе с пакетами:

yum install dnf-plugins-core

dnf config-manager —add-repo https://download.docker.com/linux/fedora/docker-ce.repo

dnf install docker-ce docker-ce-cli containerd.io

Запускаем его и разрешаем автозапуск:

systemctl enable docker —now

Проверка

Чтобы убедиться, что docker в рабочем состоянии, выполняем команду:

docker run hello-world

Сначала система обнаружит, что нужного образа нет и загрузит его:

Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
b8dfde127a29: Already exists
Digest: sha256:308866a43596e83578c7dfa15e27a73011bdd402185a84c5cd7f32a88b501a24
Status: Downloaded newer image for hello-world:latest

После отобразит приветствие:

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker.

Docker работает корректно.

Установка Compose

Команда docker-compose позволяет развернуть многоконтейнерные Docker-приложения.

Для ее установка сначала переходим на страницу github.com/docker/compose/releases/latest и смотрим последнюю версию docker-compose. В моем случае, это была 1.29.2.

curl -L «https://github.com/docker/compose/releases/download/$COMVER/docker-compose-$(uname -s)-$(uname -m)» -o /usr/bin/docker-compose

* где 1.29.2 — последняя версия файла.

Даем права файлу на исполнение:

chmod +x /usr/bin/docker-compose

Запускаем docker-compose с выводом его версии:

Возможные проблемы

1. undefined symbol: seccomp_api_set

Сервис докера не запускается, а в логе можно увидеть следующий текст ошибки:

/usr/bin/containerd: symbol lookup error: /usr/bin/containerd: undefined symbol: seccomp_api_set

Причина: ошибка возникает, если установить свежую версию containerd на систему с необновленной библиотекой libseccomp.

Решение: обновляем libseccomp.

yum update libseccomp

apt-get —only-upgrade install libseccomp2

2. error initializing network controller list bridge addresses failed no available network

Сервис докера не запускается, а в логе можно увидеть следующий текст ошибки:

error initializing network controller list bridge addresses failed no available network

Причина: система не может создать docker-интерфейс.

Решение: создаем docker-интерфейс вручную. Устанавливаем утилиту для работы с bridge-интерфейсами.

yum install bridge-utils

apt-get install bridge-utils

brctl addbr docker0

Назначаем IP-адреса на созданный интерфейс:

ip addr add 192.168.84.1/24 dev docker0

* в нашем примере для docker мы задали адрес 192.168.84.1.

Источник