Ayudag, у нас в конторе раньше ходила шутка, что все проблемы сводятся к трём:
1. Проблемы с дисками.
2. Проблемы с DNS.
3. Неправильный MTU.
Была однажды история, задеплоили новый сервер и забыли ему понизить MTU (мы всегда делаем, чтобы во все ipsec пролазило). И вот идёт трафик по протоколу с маленькими пакетами, всё работает, пока не случается всплеск трафика и пакеты склеиваются, переставая влезать в MTU, что приводит в итоге к потере этих пакетов и реконнекту по таймауту. Поддержка несколько часов пыталась убедить поставщика, что у нас всё хорошо и это у них проблемы :)
Ayudag, вполне нормально разные контейнеры запускать по-разному. Например, один из способов поднять VPN - это запустить его в host-контейнере.
Нужно только понимать, что host-контейнер это как запуск напрямую на хосте без сетевой изоляции. Если это понимать и учитывать - то всё нормально. А то например пусть есть сервис на порту 123 у которого есть ещё порт 456 с админским интерфейсом. Когда мы его запускаем в стандартной bridge-сети - то порт 123 мы явно публикуем, а порт 456 нет и это не вызывает вопросов. Но порт 456 в host-контейнере будет доступен снаружи, так что надо будет об этом позаботиться (выключить админский интерфейс или зарезать к нему внешний доступ явно).
1. Есть инструменты типа sslh которые могут несколько протоколов проксировать с одного порта в разные приложения. По крайней мере sslh умеет openvpn.
2. Можно использовать policy routing и с его помощью принимать трафик в разные реальные порты в зависимости от IP обращающегося. Но это не поможет против РКН, потому что они с любого IP детектят легко определимые протоколы VPN. Вероятно, ради этого и затевался вопрос? Нет, показом "другого сервиса" их не обмануть.
3. Всякие vless/reality/итд тут уже упомянули. Их пока не умеют детектить, а обилие спецнастроек позволяет рассчитывать, что они будут работать ещё долго путём манипуляции этими настройками.
mxelgin, вот там есть пример создания /etc/apt/sources.list.d/docker.list в Dockerfile. Надо по аналогии создать /etc/apt/sources.list. Как вариант, можно просто сделать
sed -i s/deb.debian.org/mirror.yandex.ru/ /etc/apt/sources.list
Ибо вряд ли там будет что-то похожее н deb.debian.org кроме как в хостах.
Ayudag, если это легальный API для приложений - то ограничения CORS к нему никто не будет применять, вместо этого контроль запросов происходит через ключи доступа.
mxelgin, deb.debian.org редиректит на ftp.debian.org. Вообще, можно заменить его на mirror.yandex.ru. Для этого в сборке своего контейнера также поменять /etc/apt/sources.list.
mxelgin, возможно, лучше тогда сразу поставить gitlab и всё организовать в нём. Он может и сборку с деплоем (CI/CD) с использованием Gitlab Runners, и образа для docker прям в нём можно хранить. Jenkins - это прям очень махровый опенсурс со всеми его недостатками: запутанный интерфейс, длинная история разных некритичных и критичных багов, куча проблем с безопасностью (в том числе в прошлом бывали прям жёсткие RCE без авторизции).
У нас Jenkins используется только для задач, которые напрямую с CI/CD не связаны и которые поэтому не привязаны к коммитам в репе приложения. Например, связанные с установкой новых серверов. А сборка приложений и деплой их в прод - это в Gitlab (плюс образа контейнеров складируются в Harbor).
Ayudag, DROP тут это policy, это что делется в случае если другие правила в этой цепочке не подошли. А судя по отсутствию правил, связанных с IP-адресами контейнеров, в цепочке DOCKER, ни одного контейнера не запущено или они не в bridge-сетях.
Можно посмотреть docker network inspect test-app для изучения чё как запущен контейнер. А также docker network inspect bridge - там будет в том числе список контейнеров с адресами.
Для начала зайти внутрь контейнера и проверить изнутри что с сетью.
docker exec -it test-app /bin/bash
(Надеюсь баш внутри есть, если нет то возможно есть /bin/sh)
Дальще пробовать curl, ping и всё такое - в теории тоже может быть вырезано из контейнера.
Самая простая причина - это наверчено в iptables. Например, если в конфиге демона docker (/etc/docker/daemon.json) выключено управление iptables, то сеть не будет автоматически настроена так, как надо, и это придётся делать вручную.
Но в целом может быть ещё стопоцот других причин, например, выключенный ip_forward или криво указанный upstream dns. Надо тестить, искать ошибки, реагировать на найденное.
antdantd, нет никаких волшебных стилей. Если там в принципе вёрстка предполагает ширину экрана от 1000 пикселей, то запихиванием левых стилей можно получить какую угодно кашу. Например, что-нибудь типа такого:
Pira1179, существуют старые базы соответствий id-телефон из былых времён, когда у большинства номер по умолчанию не скрывался. Эту информацию сейчас тоже могут использовать, но никак напрямую из самого канала она не извлекается.
Жалобы в Телеграм работают очень плохо. Некоторые спамботы в группах без админов неделями спамят каждые 10 минут и не попадают в бан от самого мессенджера. Возможно, после кандала с задержанием Дурова он таки займётся налаживанием модерации и поддержки, но пока что есть, то есть.
1. Проблемы с дисками.
2. Проблемы с DNS.
3. Неправильный MTU.
Была однажды история, задеплоили новый сервер и забыли ему понизить MTU (мы всегда делаем, чтобы во все ipsec пролазило). И вот идёт трафик по протоколу с маленькими пакетами, всё работает, пока не случается всплеск трафика и пакеты склеиваются, переставая влезать в MTU, что приводит в итоге к потере этих пакетов и реконнекту по таймауту. Поддержка несколько часов пыталась убедить поставщика, что у нас всё хорошо и это у них проблемы :)