кубер в целом не для недоверенного кода. Вариант с docker-in-docker возможен, но теоретически в нем есть уязвимости, которые могут позволить коды выйти из песочницы и все поломать. Идеально - смотреть в сторону enforcing на уровне runtime (gvisor), пытаться переходить с контейнеров на мини-ВМ (kata-containers или firecracker).
ответ - без понятия. Как я ниже описал - он мог создать контейнеры с restart: always через docker-compose up, а потом перезагрузиться и очень сильно удивляться, почему это порядок запуска не работает
Сначала сделать curl с хост машины. Далее - из контейнера с nginx. Т.е. провести стандартную диагностику веб сервера. Никаких дополнительных нюансов тут нет.
Очень странная задача, т.к., во-первых, в микротиках есть sip alg, а, во-вторых, обычно эта проблема легко решается соответствующей конфигурацией на стороне сип сервера для конкретного экстеншена
Все что выполняется у клиента - априори может быть сдампано, декомптлировано, взломано. Единственный вариант избежать этого - разделить проект на клиентскую и серверную части. Все ноу-хау в серверной части на подконтрольным Вам и только Вам ресурсам. А клиент - он просто генерит запросы и получает ответы. Во всех остальных случаях - софт будет рано или поздно сломан.
Ну, тогда могу порекомендовать почистить все образы в локальном кэше докера, почистить все volume, с хост-системы удалить лишние файлы и попробовать заново ) скорее всего тогда получится
Я вообще не понял, что тут происходит. Могу посоветовать вообще посмотреть в сторону отказа от docker в пользу systemd unit - у них тоже есть средства изоляции приложений. А ещё модно подумать как, например, запускать докер без изоляции ("linux namespaces"). Может помочь режим host'овой сети. Не зная специфику ВПН клиента сложно помочь.
Ещё я не понял цели этих приседаний с resolv.conf - я уж не говорю, что можно вообще весь каталог /etc отобразить внутрь контейнера, если очень надо.
В общем - наверняка речь шла о какой-то другой проблеме и аочти наверняка для нее есть более красивое решение
Докерфайл и необходимые файлы можно держать в разных местах. Только нужно учитывать, что левый параметр COPY берется только из контекста и путь пишется относительно контекста. Докерфайл же может быть и вне контекста - хоть с stdin его скармливай демону (через параметр -f)
Или можно настроить pg_hba.conf внутри контейнера - он тоже управляет тем какие хосты могут, а какие не могут ходить в базу, но на уровне самого сервера бд (приложения).
Это разве туннельный режим ipsec? Откуда вопрос? Потому что ipip работает и вне ipsec - раз, и, два - на strongswan/libreswan таких "странных" доп настроек производить не надо
