1. мне кажется, что эта штука вызывает больше проблем, чем решает
2. конечная цель все-таки какая? вряд ли это добавит сильно много к безопасности (докер и безопасность? ну-ну)
3. демон как настраиваете? оптимальнее всего через /etc/docker/daemon.json
4. файлы /etc/subuid и /etc/subgid созданы?
5. docker inspect для docker run hello-world что показывает?
Перестартуйте докер демона - иногда это помогает, если речь про машину разраба и постоянно меняется тип подключения к интернету (провод/wifi и имена и адреса сетей)
> исходя из файла docker-compose.yml куда мне нужно положить данные сертификаты и что прописать в nginx.conf?
В любое место, где они будут доступны.
Т.е. в volumes: добавляете две записи вида
- ./my_super.pem:/etc/ssl/my_super.pem
И стандартным образом в nginx прописываете сертификат (приватный ключ) по пути внутри контейнера
Аналогом traefik может выступать nginx в сборке от jwilder, но я ее не люблю. Это раз.
Два. Вы там придумали какой-то головняк с необходимостью подсовывать сертификаты. Если машина доступна из интернета - можно получить сертификаты LE на нее. Либо через HTTP проверку, либо через DNS. Приключения с переносом сертификатов начинаются именно, когда проверить напрямую невозможно.
Нет, я делал строго по оф. инструкции от килеманна, причем буквально... позавчера. И все работало.
Это может означать одно из двух: либо Вы где-то допустили отклонение от инструкции, либо у Вас какие-то проблемы с генератором случайных чисел...
Свежая версия образа от kylemanna работает отлично. Допускаю, что что-то сделали не по алгоритмы. Поэтому совет - удалить все "хвосты" и начать с самого начала.
Подтверждаю. Докер компоуз не регламентирует порядок запуска сервисов. Т.е. не так. При docker-compose up они, конечно, могут стартовать в нужном порядке. Но далее - если по дороге кто-то сдохнет или нода будет перезапущена - порядок уже нарушится. Там реально много нюансов. Отсутствие этого функционала ведёт к странным вещам - вроде засунуть docker-compose up в systemd юнит. И дальнейшему велосипедостроению. А, оказывается, что можно было все и без докера собрать....
Абсолютно согласен, что докер идеален для разработки, для тестирования и для организации через него пайплайнов сборки. Еще он из категории "терпимо" для сред вроде nomad/kubernetes, но в последнем его активно заменяют.
Для целей "распилить" один микросервер докер выглядит как не самое удачное решение. Выгод мало, а сложностей будет много.
voidSoul, ну, после перезагрузки - контейнеры никуда не исчезают. Но это не salt'овая особенность, а "фишка" самого докера. Можно ещё задать политику рестарта контейнера, т.е. после перезагрузки контейнеры могут автоматически запуститься. Это может быть как желательно, так и не очень (поэтому я и предлагал управление запуском переложить с докера на systemd)
Настройка взаимных зависимостей отдельных systemd-сервисов - еще та задачка...
Это существенно более гибкий механизм чем то, что предлагает docker compose для обеспечения порядка запуска сервисов.
Сейчас от коммита до накатывания обновления - 6 минут.
Я и с deb сделал бы не хуже... Ну, ок.
voidSoul
логи - положим, не проблема. Можно их либо писать в /dev/null (докер так умеет), либо в journald (кстати, системные логи тоже ведь нужно отключить для RO FS?), либо в еще какой-нибудь драйвер (например, rsyslog и доставлять их по сети на удаленный сервер).
контейнеры - само их состояние и overlay fs - однозначно поверх RO FS работать не будет. Поэтому я и предложил запускать поверх tmpfs, но выглядит как костыль.
Мне кажется, что все-таки стоит вернуться на дистрибуцию через deb. С salt'ом - нормально комбо. Касательно с докером - я даже не знаю. Что быстрее? Выкат? Разработка?
> Настроен всего 1 systemd-шный сервис - собственно запуск docker-compose
Не надо так делать. Никогда. Во-первых, docker-compose тут лишний. Во-вторых, у вас уже есть salt, который прекрасно умеет оркестировать контейнеры. В третьих, если засосывать docker-compose в systemd unit, то последний не сможет надежно проверять работоспособность сервиса в докере. Лучше уж тогда напрямую запуск каждого отдельного контейнера в отдельный systemd unit оборачивать. Там свои нюансы, но это выглядит более надежным решением, чем тащить туда компоуз.
Детализируйте вопрос.
Проблемы запустить php-fpm не от рута нет. Оно работает - я проверял. По крайней мере в официальном образе.
С правами проблема обычно при пробросе каталога с хостовой машины - ну, так не используйте укороченный синтаксис для проброса `-v`, а используйте полный - `--mount` и каталог для файлов создавайте перед созданием контейнера. Еще может помочь отказ от bind mount совсем.
Можете попробовать, но сомневаюсь, что получится и что это правильный путь.
Мне все-таки очень сильно кажется, что нужно подход поменять.
Если расскажете подробнее о проекте - могу посоветовать более предметно что делать и куда дальше бежать.
Ну, в такой формулировке вопроса помочь нельзя. Я лично никаких проблем с l2tp не ловил. Работает как часики. Возможно, что у Вас попросту какая-то уникальная конфигурация. Но чтобы был предметный разговор, а не набросив на тему "выкинь микрот - поставь микросервер на центось" очень желательно дать побольше данных и попробовать самостоятельно поймать за руку виновника.
И, да, я сталкивался с несовместимостью микротов в двух кейсах:
1. Айписек с каким-то брендовым железом. Не могли согласовать параметры подключения, туннель разваливался. Катнул виртуалку с centos - полет отличный.
2. Mikrotik + оборудование apple в разных комбинациях, преимущественно проблемы wifi.
Допускаю, что я тоже не довел исследование до конца и пошел менее верным, но более простым путем - либо заменил микрот, либо придумал ещё какой-нибудь воркэраунд.
Ну, правильной идеей тогда, очевидно, является заводить два хвоста от двух разных провайдеров, желательно, ещё, чтобы при сборе по электропитанию, один из двух каналов остался живой. Но всё зависит от бюджета. И, как я понимаю, без черной магии типа BGP переключение с одного провайдера на другой безболезненно не пройдет (прорвутся все пользовательские сессии)
2. конечная цель все-таки какая? вряд ли это добавит сильно много к безопасности (докер и безопасность? ну-ну)
3. демон как настраиваете? оптимальнее всего через /etc/docker/daemon.json
4. файлы /etc/subuid и /etc/subgid созданы?
5. docker inspect для docker run hello-world что показывает?