sergiko

Итоговый результат слияния кода при merge и rebase одинаковый. Разница будет только в порядке коммитов в истории. Merge сверху применяет новые коммиты, rebase находит общего предка, убирает ваши новые коммиты в ветке, обновляет ветку, применяет ваши новые коммиты сверху.

У меня в похожей ситуации сложился такой набор инструментов:
- контейнеризация - докер
- конфигурация и запуск контейнеров - docker compose
- web IU к докеру - Portainer
- деплой - Gitlab CI

Советую поступить как нравится.

Оркестрация кубом в пределах одного физического сервера скорее прихоть, чем необходимость. Можно поиграться разве что для знакомства с системой. И k8s скорее всего точно мимо - впустую потраченные ресурсы одного сервера. minikube, k3s и подобные будут лучшим выбором.
Для поставки в куб все равно придется организовать сборку и публикацию контейнеров. Для доставки и helm хватит.

Что бы посоветовал - baremetal с оркестрация через Ansible.
Как вариант - гипервизор: виртуалки или lxс; возможно Proxmox. Просто на случай необходимости в изоляции или разных конфигураций ОС.

Писать надо на том, что знаешь. От языка способность держать высокую нагрузку зависит слабо - есть вполне себе хайлоад (лично видел, платежная система), написанный на PHP.
Для серьезного хайлоада важнее другая характеристика: не скорость работы, а стоимость ошибки. Если ваш хайлоад "ляжет" из-за какой-то ошибки (да еще с потерей части данных) - это будет очень-очень-очень плохой экспириенс для пользователей. А если это будет происходить неоднократно - потеря посетителей вам гарантирована.
Поэтому у меня для хайлоада приоритеты:
1. Надежность
2. Скорость разработки
3. Производительность

Итак, по пунктам.
Надежность. Это про то, насколько строго язык отлавливает ошибки программиста и насколько просто на нем написать подверженную ошибкам муть. Насколько просто будет сопровождать код, написанный на данном языке. В этом пункте ключевые слова "архитектура", "покрытие тестами" и "статическая типизация". Первые два пункта - это про любой язык, так как реализуются на уровне процессов разработки. Из предложенного списка языков статическую типизацию обеспечивают Java (Kotlin) в мире JVM и Typescript (не Javascript) в мире Node.js

Скорость разработки. Это про наличие большого количества готовых библиотек и про богатые возможности языка для выражения требуемых программисту структур данных и алгоритмов. Тут фавориты те же: Java/Kotlin и Typescript. На мой взгляд, JVM-мир сложнее, но дает все-таки больше возможностей (тот же Spring обеспечивает создание бинов за пару аннотаций).

Производительность. Не могу сказать о Node.js - не тестировал на производительность, но JVM обеспечивает очень хорошую скорость. Еще один немаловажный момент: очень часто в хайлоаде приложение чего-то ждет. Например, отправив запрос в БД ожидает ответа. А в это время могло бы обрабатывать другой запрос другого пользователя, а получив ответ из БД - вернуться к обработке первого (reactive programming). Для этого у нас есть разные реактивные фреймворки для той же Java (Reactor, Vert.x и т.п.) и, что особенно приятно, корутины в котлине, которые позволяют писать асинхронный код почти настолько же просто как и синхронный. На Javascript с их async/await тоже можно такое писать, хотя возможностей все-таки поменьше чем в Котлине.
Опять же, с корутинами достаточно легко и просто реализуется многопоточность, в ноде с ней не все так просто (хотя она тоже есть).

Таким образом, мой личный выбор для хайлоада: JVM и Kotlin.
Альтернативный вариант: Node.js и Typescript.

Другие я бы стал рассматривать только при наличии очень весомых преимуществ перед обозначенными.

P.S. Также Kotlin является официальным языком для Android, поэтому можно подумать о том чтобы писать и мобильное приложение и сервер на одном языке.

Звучит как задача для ClickHouse, Вроде как они недавно пофиксили производительность при отдельных инсертах без буфера. Даже если нет, есть схема с записью всех событий в Kafka и вычитыванием оттуда с помощью Materialized view в таблицу КликХауса. Эта схема точно рабочая и указанные нагрузки выдержит. Плюс отличное сжатие данных.
Чистый PostgreSQL по производительности не сильно отличается от MySQL, а вот с дополнением TimescaleDB вставка становится очень быстрой, возможно вам его хватит. Там полноценный SQL и возможность редактировать данные без проблем. Неплохо сжимает.
Про ScyllaDB уже написали.

В общем всем спасибо за мысли, вы мне посоветовали именно такой подход, как я планировал, но в вопросе не освещал, чтобы получить альтернативное видение.
В результате:
- поднятие OVPN клиента + маршрутизация трафика останется на pfSense
- написал скрипт, который будет запускаться в ВМ и контролировать внешний IP и в случае, если он не тот, блокировать все сетевые интерфейсы. Скрипт выполняется раз в 1 минуту.
https://gitlab.com/a.perminov/external-ip-monitor
- еще есть скрипт, который так же проверяет не пересекается ли внешний IP в всех ВМ и шлет уведомления о проблемах в Discord

Думаю этого будет достаточно...

У меня вот так

В firewall в filter Rules

chain=forward action=accept src-address=192.168.3.0/24 dst-address=192.168.1.0/24 log=no log-prefix=""
chain=forward action=accept src-address=192.168.1.0/24 dst-address=192.168.3.0/24 log=no log-prefix=""

3.0 видит 1.0
1.0 видит 3.0

Если не понятно, могу скрины выложить

https://golang.org/doc/effective_go
https://github.com/cristaloleg/go-advice
https://dave.cheney.net/practical-go/
https://github.com/golang/go/wiki/CodeReviewComments
https://github.com/golang/go/wiki/SliceTricks

Еще полезно поизучать крупные опенсурсные проекты на Github

Хз, в чём магия, но я вышел на апворк года с два с лишним назад. Взял пару заказов, сделал, получил хорошие оценки, и на год забил. Не могу сказать, что у меня было нечто особенное в работах или в навыках - WordPress, немного по веб-анимации. Но проблем с получением первого заказа не было. Через год у меня было уже не сильно актуальное портфолио, но я пришёл обратно и решил работать всерьёз. Каких-то проблем тоже не помню, народ потянулся. При этом не могу сказать, что занимался чем-то специфичным - WP-разработка и вёрстка, в основном.

Возможных проблем вижу несколько:
- плохой английский
- плохое портфолио
- негативные отзывы
- высококонкурентная сфера, где сложно показать, чем вы лучше
- плохие кавер-леттерс (лучше писать сразу под задачу клиента, предлагая варианты решения)

Думаю, имеет смысл прокачать специализацию и двигать её. Я сделал себе WordPress-портфолио, предлагал "всё для WP" - разработку плагинов, тем, WooCommerce, REST. За год получил "top rated" и шквал заказов - разве что, серьёзный по российским меркам кеш сделать не получилось (2к-3к на пределе) - видимо, для WP это непросто, ну или я поймал не ту волну. Сейчас думаю расширяться на более серьёзные фреймворки, будет интересно, что предложат там.

Да, и идея с низкими ценами - она плохая. Ставьте нормальную для себя цену и убеждайте заказчика, что вы отличный специалист. Индусов он и без вас найдёт :). Я обычно просто повторяю цену, заявленную в объявлении, а если вижу, что она слишком низкая для задачи - повышаю до комфортной для себя.

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