Everything_is_not_so_bad

1. Можно включить вендоринг - тогда все зависимости будут размещены в подпапке vendor и при следующих сборках доступ в интернет не понадобится. go mod vendor
2. Можно установить переменную GOPROXY так, чтобы исходники качались не через прокси proxy.golang.org, а через другой или напрямую с гитхаба. Environment variables
3. Можно использовать уже скачанный локально репозиторий. replace directive in go.mod

UPD: конкретно для go install можно попробовать п.2 с GOPROXY. Либо склонировать исходный репозиторий и собрать бинарник командой go build - для разрешения проблем с доступом к зависимостям воспользовавшись п. 1-3.

UPD 2: по конкретно интересующему вас репозиторию: клонируете его, переходите в папку installer и выполняете в ней GO111MODULE=off go build, получите собранный бинарник - нет там никаких внешних зависимостей и даже go.mod

location /elastic {
            proxy_pass http://127.0.0.1:9200;
        }

Добавьте слеш

location /elastic {
            proxy_pass http://127.0.0.1:9200/;
        }

В документации это написано
https://nginx.org/ru/docs/http/ngx_http_proxy_modu...

Слегка похоже на RAW RGBA
первые три байта цвет (черный) и прозрачность, но кусочка скрина недостаточно. так что это предположение.
PS . RAW RGBA дает такую картину, но что то мне кажется что разрядность альфаканала или порядок байт еще не верен, да и цвет должен черным быть, а синего по краям быть не должно, в

Image.frombuffer("RGBA", (256, 256), data, "raw", "RGBA;4B", 0, 1)

Может коллеги подскажут ...

Поменял SD-карту на новую и продул сжатым воздухом разъем SD-карты, проблема исчезла

https://t.me/clickhouse_ru

Хочу такой вариант пропустить и сразу перейти к kubernetis

"You think you do, but you don't"

Знаю, что могу вынести DB и pgbouncer на отдельные сервера

Чтобы увеличить RTT?

Для поддержки кубика нужна целая выделенная команда, которая, помимо кубика, ещё настроит и будет поддерживать ёлку (ELK), какой-нибудь vault, графану, прометей, консул, докер реджистри, s3 (типа minio или seaweedfs, ведь контейнеры теперь stateless и хранить на них ничего нельзя) и кучу других сложных штук. Если у тебя нет сотни разработчиков в компании, то не нужно играть в гугл.

Во-первых, какая у тебя нагрузка? Сколько тысяч запросов в секунду приходит и отмасштабировал ли ты вертикально и упёрся уже в потолок? gunicorn оптимально настроен? сколько процессов/потоков, какой тип воркеров? json парсишь и сериализуешь orjson'ом? Приложение профилировал?
Во-вторых, 12 factor
В-третьих, у базы есть реплики? read запросы раскидал на реплики? а редис? Действительно ли нужен zero downtime (это исходит из вопроса про нагрузку)

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

P.S. DRF — медленное нетипизированное говно, выкинь его

Да. Такая зараза уже была обнаружена исследователями антивирусных компаний.
Но это сложная и редкая зараза. Слишком много отличий между EFI разных производителей и разных моделей, трудно обеспечить совместимость заразы с разными материнками. В результате получается как и в биологии - от одного вируса, например, люди могут умереть, птицы болеют, но не умирают, крысы вообще не болеют, но переносят, а селёдки не болеют и не переносят. Так и тут - если именно за вами охотятся хакеры, работающие на иностранную разведку, то подсунут вирус, который сможет заразить ваш EFI, но на 90% других компьютеров этот же вирус не сможет сработать.

Зависит от того что именно за данные (для какой цели) будут передаваться и между кем и кем.
Rest как и любой другой синхронный метод взаимодействия несёт плюсы:
+ Сравнительно быстрая реакция на запрос и ответ. (как правило от запроса до получения ответа менее секунды)
+ Очень прост в использовании, нет никаких проблем с поддержкой на клиенте
+ Очень простая инфраструктура (в минимальном варианте она не нужна вообще)
+ Всё хорошо изучено. Та же аутентификация и авторизация очень легко реализуется в рамках http.
+ Достаточно легко разрабатывать и тестировать
+ Есть grpc и openapi - нет никакой проблемы с документированием такого API.
+ В http запрос с каким-нибудь multipart form data может спокойно быть размером в десятки мегабайт, а может и больше - полезно при загрузке файлов.
И минусы:
- Не понятно что делать, в случае недоступности ответной стороны
- При неправильной реализации клиента (политики ретраев) - можно легко заддосить сервер

Всякие разнообразные брокеры сообщений тоже имеют свои плюсы:
+ Строгая очерёдность обработки данных (событий) из коробки
+ В случае недоступности ответной стороны - брокер у себя может хоть несколько дней держать данные
+ Все политики ретраев реализуются на стороне брокера
+ Если это rabbit, то можно разные сложные механики рассылки и маршрутизации реализовать
+ Если это кафка или какой-то другой лог, то можно вычитывать события повторно

Но есть и минусы:
- Инфраструктура обычно сложнее
- Достаточно большие задержки
- Использовать можно будет только у себя внутри - внешнему клиенту (браузер, мобильное приложение, публичный API) такое дать не получится.
- Сложнее разграничивать в правах.
- Сложно разрабатывать и тестировать. На примере той же кафки - подключиться к топику и записать в него что-то через гуй - это отдельный челендж.
- Запросы должны быть небольшими (сотни кб)