shurshur

А вот что именно должна делать команда

${WEBPACK_COMMAND:- ng build --configuration=production}

и почему удивляет, что она завершается некорректно? Определена ли вообще переменная $WEBPACK_COMMAND? Почему при сборке вообще потребовалось брать название команды из внешней переменной? Тут вообще работают bash-евые подстановки в командах (подозреваю что нет, но не проверял)? Может, там и shell в базовом образе не bash, а классический sh?

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

До кучи, тут CMD - это команда, запускаемая при старте контейнера. Но по логике этого докерфайал, эта команда предполагалась к запуску только при сборке образа. Чтоб это исправить, надо поменять CMD на RUN.

Что будет при неуказании CMD запускаться в создаваемом на базе этого образа контейнере будет в таком случае унаследовано из FROM node:14-alpine, в данном случае видимо это запуск nginx. Если нужно запускать что-то своё вместо дефолта, то CMD надо переопределить на команду реального запуска приложения (типа CMD node /path/to/app.js или что там у вас в node.js принято делать для запуска?),

Ну и делать внутри образа две копии приложения тоже немного странно. Лучше или собирать приложение сразу в конечном каталоге /usr/share/nginx/html, либо изменить конфиг nginx на использование другого каталога. Скорее всего, в этом образе - как и в официальном образе nginx - конфиг лежит в /etc/nginx/conf.d/default.conf.

А ещё более хорошо и правильно освоить multi stage build в докере.

Docker по умолчанию использует "слоённую" файловую систему overlayfs. В ней каждый образ состоит из нескольких слоёв, которые перекрывают друг друга (read only). Плюс собственный слой контейнера (read write). Поэтому если никакой большой записи приложение в контейнере не ведёт, то образ на диске хранится один раз и дополнительно место почти не расходуется. Это нормально, это так и задумано.

172.17.0.1 это обычно локальный IP интерфейса docker0. Вся сеть 172.17.0.0/24.

Модно посмотреть вывод ip addr list dev docker0 и docker network ls, чтобы убедиться.

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

import config

if __name__ == '__main__':
    if config.POLLING:
        ... start_polling
    else:
        start_webhook(...

Всё-таки основная часть бота - его бизнес-логика. Каждый раз проверять работу его вебхуков необязательно.

Если всё же хочется вебхуков, то организуем VPN по любой инструкции, коих тысячи, получаем туннель с парой IP. Например, 10.10.10.1 на сервере и 10.10.10.2 локально. На сервере поднимаем nginx, в котором настраиваем что-то типа

location /path/to/api_test {
  proxy_pass http://10.10.10.2:порт/path/to/api_test
}

Обязательно настраиваем https, можно с Let's Encrypt, но можно и с самоподписанным сертификатом. В последнем случае надо будет загрузить этот сертификат в Telegram через API при настройке вебхука.

Локально у себя пробросить в докере тот самый порт в нужный контейнер с ботом.

Возможны разные вариации, не изменяющие общий принцип. Например, можно не настраивать https на сервере, пробросить весь порт "как есть" через nginx stream, haproxy, двойной нат или нат с policy routing, а сам https настраивать у себя локально.

Идём сюда: archive.ubuntu.com/ubuntu/dists и видим, что там нет релиза hirsute. Зато он есть тут: https://old-releases.ubuntu.com/ubuntu/dists/ , так что меняем archive.ubuntu.com на old-releases.ubuntu.com. Ещё лучше, конечно, обновить Dockerfile на более новую версию убунты, но может потребоваться разобраться в разных нюансах (какой-нить пакет иначе называется, какие-то конфиги в другом месте лежат и всякое такое).

1. Очень сильно зависит от задачи. Конечно, если точно не понимаешь, зачем это тебе нужно, то имеет смысл доверить настройку сети докеру. Но если надо, чтобы вместо bridge был macvlan со строго заданной сетью и конкретным parent-интерфейсом, то этим нас докер сам не обеспечит, если ему не подсказать.

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

3. Это попытка бороться с довольно типичным подходом начинающих докероводов, которые обходятся "универсальным" контейнером, исполняющим любой php-код с внешнего каталога. Конечно, для быстрых экспериментов "ща я чёта сваяю и запущу для проверки" это даже не очень плохое решение, но при широком использовании такого подхода смысл докера существенно уходит: вместо готового к разворачиванию приложения мы имеем контейнер, который ничего не умеет и которому приходится самостоятельно пилить отдельную систему доставки самого кода. Вместо этого лучше сразу научиться и отладиться готовить полноценный образ. В конце концов, можно все приложения делать потомками этого супер-образа с php, что сделает их сборку довольно быстрой.

4. Относительные пути - это как раз очень удобно для многих задач. Мы имеем каталог с проектом, в котором docker-compose.yml и все нужные данные. Размещение данных предсказуемо, точно видно, кто их использует, какой у них размер и всё такое. Удобно в случае чего перекидывать между серверами вместе с данными: просто погасил, rsync, запустил. Напротив, хранение данных в анонимных томах в /var/lib/docker с непонятными именами - это часто антипаттерн, при котором ценное место в /var заполняется чем-то непонятным, что толком невозможно идентифицировать. А использование имён может привести к той же проблеме, что и container_name - в разных compose-проектах имена пересекутся, и узнаешь это только тогда, когда уже сломается.

Почему в ENTRYPOINT делается chmod? Надо просто ./client или даже полный путь /app/client.

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

Как минимум следует начать хотя бы с такого:

try:
  ...
except Exception as e:
  print (e)

Сейчас же, возможно, случается Exception, но мы этого даже не знаем.

Далее, не стоит использовать ORM вперемешку с обычными запросами. Это тоже источник потенциальных проблем, ведь ORM может кэшировать данные, в том числе ещё не сохранённые. Возможно, до вызова save случился Exception, данные в кэше отличаются от данных в базе, но при прямом запросе в базу мы получим не то же самое, что получили бы из кэша.

Вот такие мелочи могут создавать проблемы, которые при этом вообще нигде даже не отражается. И это ещё повезло, что эффект такой заметный. А если бы эффект проявлялся в одном случае из тысячи? Как бы его потом ловить и что отвечать пользователям, с которых списали лишних денег?

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

Ну как бы это вполне возможно. Нужно --net=host, чтобы fail2ban редактировал iptables на хосте, нужно прокинуть (или загнать в образ) конфиг, нужно прокинуть изучаемые им логи, ну и про privileged mode не забыть. Но зачем? Ему же по сути только конфиг надо настроить один раз и везде использовать, вон уже выше ansible посоветовали для упрощения этой операции.