deepblack

Средствами ноды или перечисленными в ответах способами сделать можно, но это не эффективно, обычно для такого используют менеджеры очередей, типа RabbitMQ и ему подобные.

1. Через резолв docker dns
   
2. Nginx сам ничего не сделает
   
3. Потому что предыдущие пункты. Правится созданием upstream, он уже разобьёт server на несколько ip из ответа DNS
   

global user_id
Ну как бы вот виновник. Глобальные переменные. Они общие на всего бота и на всех пользователей. Если тебе нужно дифференцировать пользователей - делай это сам.
Делай хранилище "ключ-значение", где ключ - ID пользователя, значение - хранимые для этого пользователя данные. При обработке сообщения читай ID пользователя, доставай из хранилища данные, и уже сообразно им обрабатывай сообщение.
Таким хранилищем может быть простой словарь (если не нужно сохранять состояние между перезапусками бота), БД или ещё что.

Не знаю, есть ли в telebot реализация Finite State Machine, но обычно для реализации сценариев используют её. Идея та же - для каждого юзера храним его текущее состояние (шаг в сценарии) и ассоциированные с ним данные.

У тебя в строках массива несколько нулей. Метод index() по умолчанию находит только первое искомое значение. Если бы ты почитал документацию, ты бы это понял, и увидел, как это обойти.

list.index(x[, start[, end]])

Return zero-based index in the list of the first item whose value is equal to x. Raises a ValueError if there is no such item.

The optional arguments start and end are interpreted as in the slice notation and are used to limit the search to a particular subsequence of the list. The returned index is computed relative to the beginning of the full sequence rather than the start argument.

Вообще, раз уж ты ручками перебираешь строки и ячейки матрицы, используй enumerate().

for i_row, row in enumerate(grid):  # row == grid[i_row]
    for i_col, value in enumerate(row):  # value == row[i_col]
        # далее сам

Во-первых, нужно не if ... if ... if ... print(), а if ... elif ... elif ... else: print()

Во-вторых,

if c != "множення" and "додавання" and "віднімання" and "ділення" :

Очень многие совершают эту ошибку. Так НЕ работает.
Код вида if x != 2 or 3: эквивалентен if (x != 2) or (3 != 0):, что, в свою очередь даёт if (x != 2) or True:. А что угодно or True даст True, т.е. условие будет всегда выполняться.
Правильно - if x != 2 and x != 3: или if x not in (2, 3):
Для своей задачи приспособишь по аналогии.

https://codepen.io/aleksays/pen/XWYaoYM

Автоматически - точно так же, как вручную, но "завернуть" все команды в GitHub Actions.
Вот примеры от самого GitHub https://docs.github.com/en/actions/automating-buil...,
можно поискать в гугле по "мой-язык пример github actions"

Дополню немного ответ Dr. Bacon, поскольку мне кажется он не так понял ваш вопрос, а вы, возможно, не так поняли суть проблемы.
Под БД, например постгрес, обычно понимают две разные вещи:
1) сами данные в файловой системе,
2) сервер базы данных, который реализует сетевой интерфейс для работы с БД и правильным образом кладёт и читает данные в файловой системе.

Так вот, сервер можно развернуть ка кна хостовой машине (как вы сказали "локально"), так и в докер-контейнере.
Файлы БД можно разместить как в файловой системе контейнера, так и в локальной файловой системе, примонтированной внутрь контейнера.
И тут полно нюансов.
Давайте начнём с того, как правильно.
Правиьным будет взять стандартный докер-образ сервера БД, сконфигурировать его через компоуз-файл, а размещение файлов БД примонтировать в виде отдельного volume.

Что имел в виду Dr. Bacon. Он имел в виду, что если не монтировать файлы БД в volume, то они будут лежать внутри контейнера, а значит при его перезапуске все данные будут стерты, поскольку состояние файловой системы контейнера не принято хранить. Это одно из преимузеств докера - сделал образ унаследовав его от других образов, а потом при запуске контейнера он какждый раз как новенький.

Скорее всего, где-то остались удаленные, но не закрытые файлы - какие-то программы их держат.
Их можно найти командой
lsof -X / | grep deleted
Если совсем лень разбираться, можно просто перезагрузить систему

Параллельное и асинхронное программирование в Python отдельной главой есть тут:
1. https://lib.org.ua/ru/vbook/Prohorenok_Python3_Ess...
2. https://read-me.shop/ua/p1501673941-kniga-professi...

Отдельные книги
1. https://www.amazon.com/Using-Asyncio-Python-Unders...
2. https://www.manning.com/books/python-concurrency-w...

Отдельные статьи для понимания:
https://towardsdatascience.com/introduction-to-asy...
https://tproger.ru/translations/asynchronous-progr...
https://medium.com/velotio-perspectives/an-introdu...
https://towardsdatascience.com/why-you-should-use-...

Начну с конца - для индексов это критично разные вещи. Планировщик даже пытаться анализировать не станет, эквивалентные это условия или нет. Если у вас есть индекс по my_column -> 'a', а в запросе вы написали "my_column"['b'] - то этот индекс использоваться не будет.

Касательно самих двух операторов:
-> ровесник jsonb как такового
jsonb[element] - jsonb subscripting на языке документации - штука недавняя, лишь только прошлогодняя из pg14. Пока что нужно иметь в виду если вам может потребоваться более старая версия базы.
По поведению отличий вроде не должно быть никаких. Оба варианта возвращают jsonb, поэтому IRL куда чаще используется ->> возвращающий текст.
На уровне реализации оба приходят к одному и тому же getKeyJsonValueFromContainer. Вы скорее упрётесь в производительность разбора формата самого jsonb, чем заметите какую-то разницу в производительности родного оператора от type subscripting.

Как то так

file = open("text.txt", "r" )
    file_r = file.read()
    file_p = re.findall("'(.+?)'", file_r)

    for x in file_p:
        bot.send_message(message.chat.id, str(x), reply_markup=markup)