chupasaurus

Насколько выгодным будет трансфер в SAP

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

Никто из моих знакомых SAP'истов не сидит без работы и дня. Правда, никто из них свою работу не любит.

Ken3kiEater, Если вы во всем так быстро и хорошо разбираетесь, так разберитесь и устройтесь без опыта. Если ответите на все вопросы на собеседовании и расскажите как решать те или иные проблемы на стеке технологий на который вы собеседуетесь, а также не будете тормозить в рабочих тасках, убежден, вас возьмут и без опыта.
Уверен, потому что я сам прошел такой же путь. Требуемый опыт был от 3х лет коммерческой разработки, а со стеком я познакомился за месяц до трудоустройства. И я говорю не о джуниорской позиции.

Все поды будут работать как работали, но вся оркестрация K8S пропадет - рестарт подов, миграция, и прочее.

Для fglrx вам нужен дистрибутив времен 13-14 года. С ядром 3.x.x и старыми иксами.
На вашем месте я бы сидел на открытых.

Ну на самом деле многие вещи являются внутренней информацией производителя дисков. В публичный доступ детали обычно не выкладываются, а внутренние документы все равно постоянно обновляются - никто не стоит на месте.

Почитайте для начала википедию, только англоязычную - она гораздо более полная и содержит ссылки на интересные источники.
https://en.wikipedia.org/wiki/Cylinder-head-sector
https://web.archive.org/web/20190204014430/http://...

Плюс к этому - можно ли в принципе что-то узнать о физическом (не логическом) устройстве какого-то конкретного жесткого диска? Производители не распространяются особо о дисках - сколько, например, у него пластин, какой тип головок. Есть ли тут какие-то утилиты, позволяющие извлечь информацию из какой-то служебной памяти устройства (а она у него есть наверняка), где все прописано? Без вреда для диска естественно.

Производители могут сообщить общие сведения.
Утилит как таковых в публичном доступе нет и не должно быть, поскольку работать напрямую с диском, не разбирая его вы не можете. А работая с контроллером - вы ограничены стандартным API. Об инженерных забытых паролях можно попробовать что-то найти, но вероятность невелика.

Как и в стандартном мире embedded программирования, версия софта в контроллере диска обычно залочена под продакшн. То есть оттуда вычищают все отладочные примочки, входы, выходы. Учитывая массовость и сложность производства дисков, разработку скорее всего проводят на специальных инженерных контроллерах, где есть и выходы и дополнительные интерфейсы для подключения, тестирования и программирования. А в продажу выходят диски, контроллеры на которых уже залочены, и возможно собственно даже сами интерфейсы не распаяны или даже отсутствуют.

Опыт показал, что это все баловство. Лучше отдельный чемоданчик, в него набить чего надо и положить бумажку с наименованиями. Готовые наборы как правило не самого лучшего качества, + все эти резиночки - полная фигня, особенно если что-то надо заменить.

1) ENTRYPOINT заменить на CMD и почитать про разницу
2) Наследоваться от python:3.7, а не от ubuntu
3) Не лепить виртуальную среду в докер образе

Решением было: увеличение количества nginx воркеров и коннекшенов:

user www-data;
worker_processes 32;
worker_priority -10;
pid /run/nginx.pid;
worker_rlimit_nofile 200000;

events {
        worker_connections 4096;
        use epoll;
}
...

И самое главное: включение режима keep-alive для upstream-a:

upstream partner_api {
                server WW.XX.YY.ZZ;
                
                keepalive 512;
        }

Так-же оказывается, что установив proxy_http_version 1.1; поддержка keep-alive соединения не включится. Нужно также установить proxy_set_header Connection "";

Со всеми числами можно поиграть и добиться нужного результата.
Раньше у нас отваливалось 5-6 запросов в секунду. Сейчас тоже отваливается, но гораздо реже: 1 запрос в 10-15 минут. Текущий результат пока что удовлетворяет. В будущем будем добиваться максимально возможных результатов.

но к ним нельзя подключиться извне (из-за использования networks, а как открыть нетворк -
догадаться нужно самому)

А через директивы ports - разве не прокидываются нужные порты из контейнеров наружу?

При внесении каких-то изменений в основное приложение
можно лишь надеяться что они когда-то появятся в контейнере

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

Можно пять раз удалить контейнер с приложением, потом десять раз удалить образ
никакие изменения никуда не попадут.

Не знаю как у вас построено - но приведу насчет примеров с проектами на python.
В Python создается папка с виртуальным окружением, куда устанавливаются все необходимые библиотеки для работы. Эта папка мапится вместе с проектом в контейнер. При этом используется контейнер python из стандартного образа на все проекты, а виртуальное окружение - из примапленной директории. Нет необходимости ничего дополнительно устанавливать в контейнеры. Поэтому что вы там пытаетесь делать с образами - непонятно...

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

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

Не надо хранить там основную базу - это поисковая машина, а не нормальная база в конце-концов) она для этого не подходит. Но если вам приспичило то относитесь к ней как как документ-ориентированной