У нас была проблема какого рода. Шасси Интел должно быть правильно сконфигурировано штатной утилитой и прописаны те кулеры, которые должны быть. Почему-то из коробки это не делается и сервер идёт на взлет. Я уж не говорю, что все кулера должны быть с датчиком холла или как там сделана обратная связь
Yoshimoto мой Пойнт был в чем.
Чтобы заплатить работнику условные 200 к руб на руки, он должен произвести продукта на 400 к руб. Т.е. это официальная 230 т.р. зарплата получается. Если же работодатель захочет законтрактоваться с ИП, то в договоре будет сумма все те же 200 круб, с которых ИП заплатит налоги. Ну, вот так оно работает - я несколько раз в разных организациях сталкивался с этой ситуацией. Ну, даже если будет 230 - это все равно не спасает сильно, т.к. ПФР, взносы, аудитору, налоги - все платит сам ИП.
Проще реально не рыпаться и быть наемным сотрудником
Разбираться с нодой - что там внутри докер образа где располагается и как должно быть. Вероятно попросту опять проблема с путями или модули не туда или не так устанавливаются
> Если я покупаю сервера в разных двух компаниях/датацентрах, то услуга не сработает?
если договоритесь с самим цодом (цодами) - тогда да. Ну, или сделаете туннель поверх туннеля. Только вот дело в том, что не нужно пытаться строить избыточно сложные конструкции - они не надежны, а лучше работают простые решения.
В хетцнер Клауд почти наверняка keepalived не будет работать. В целом, он не особо работает в облаках. По определённым причинам (особенности облачной сети). Что нужно сделать. Нужно руками собрать отказоустойчивый кластер приложения (например, постгрес). Заказать floating ip от провайдера. И реализовать систему мониторинга и реагировани, которая будет этот floating ip гонять по узлам. Т.к. в хетценере, как у самого дешёвого провайдера, этот функционал не реализован "из коробки"
Либо - закрыться каким-то внешним балансировщиком (вообще вне хетцнера).
Тогда правильным ответом будет использование пиринга или vpn на уровне инфраструктуры облака. Единственным недостатком подобного решения может явиться цена. Т.к. облако возьмёт дополнительные деньги за подобную услугу. Ну, либо, как Вы сделали - загнать ВПН клиента. Но нужно это делать не в каждый под, а достаточно было бы выделить одного ВПН клиента на ноду. Кстати, не обязательно брать именно openvpn, а можно ipsec или wireguard.
Но, что интереснее, можно вообще обойтись без впна. Если адреса, с которых кластер выходит в интернет, фиксированные, то можно попросту опубликовать нужные сервисы в интернет и закрыть белым списком. Шифрование - на уровне прикладного протокола.
Не знаю. Вообще по идее указанная задача решается средствами именно сетевого плагина в кубернетес. Но при прочих равных я бы все-таки, как в начале написал, склонялся в сторону ВПН на уровне облака
телепаты в отпуске.
Могу предложить начать с того, чтобы внимательно посмотреть документацию на текущую версию mysql клиента. Мало ли там с опциями что-то не то. Далее попробовать длинный вариант - не через -p, а через --password=
Но, что более существенно, и, что скорее является проблемой - НАЛИЧИЕ СПЕЦСИМВОЛОВ типа @# или подобных в пароле. В чем секрет? В том, что эти спецсимволы обрабатываются оболочкой - скорее всего bash'ем в Вашем случае. Решение какое ? Либо экранировать спецсимволы, либо закавычить пароль правильным образом.
Еще дополню, что если mysql доступен по порту с хост машины, то необязательно запускать mysql клиент в контейнере - его можно и с хоста запускать
Я рекомендую рассказать зачем такое может понадобиться. Как костыльное решение могу предложить создавать запущенный контейнер, в нем запускать утилиту, а потом делать docker commit / docker save для сохранения итогового образа. Получается, мы обходимся без build, без ограничений накладываемых им, и получаем целевой образ, который можем использовать и тиражировать
При любой возможности - лучше ставить общесистемные питон пакеты через пакетный менеджер операционной системы, иначе вы активно себе подкладывает мину, которая сработает, когда сделаете следующий apt upgrade.
Либо - ставьте пакеты не в глобальное окружение, а в т.н. virtual env - тогда проблем будет минимально
Round robin это худший способ обеспечения фейл овера. Любое лишнее кэширование у провайдера или на роутере клиенте, особенности кэша его компьютера - и мы имеем не фейл овер, а сплошное недоразумение.
Вариант с хождением в апи днс провайдера выглядит более оптимальным.
А ещё более оптимально использование CF и ко - у них точка входа изначально правильным образом защищена от сбоя.
Опять же - весь вопрос в том бюджете, который есть на реализацию отказоустойчивости. Возможно, что бюджета нет, да и потери не такие высокие, если сайт полежит
И чего тогда вообще запаривпться ?
> - Mysql репликация мастер-мастер
Я вообще не верю в мастер-мастер. Любая проблема, что нарушена связность между узлами, а при этом клиент видит оба узла и мы имеем неразрешимые конфликты. Я уж не говорю об неограниченной ничем задержке между узлами - там да стандартные каналы связи, которыми мы не управляем. И при "правильном" мастер мастер сбои на линии приведут к увеличенным таймаутам при хождении в бд
Несомненно, Ваше замечание верное. Но, а что лучше - строить отказоустойчивость на DNS? Упал сервер (кластер), быстренько пересоздаем записи A c указанием рабочего кластера (заранее TTL на записи - минимальный)? А BGP - это обычным смертным не осилить, т.к. надо настраивать + заранее откуда затащить пул адресов (купить AS? или арендовать пул). Поэтому я и указал, что проще всего реально поговорить с коллегам-инфраструктурщиками из ЦОДа и попросить их помочь проработать вопрос балансировки/отказоустойчивости.
Плавающий айпи тоже имеет подводные камни. В том же хетцнере его переназначить можно только "руками" между узлами, что при редких авариях и минимальных требованиях к RTO вполне допустимо
возможность отказа cloudflare (или любого аналогичного сервиса) существенно ниже, чем неправильно построенного HA, т.к. не у всех есть опыт его постройки.
Это так не работает.
Есть два нюанса
1. надо обращаться не по имени контейнера, а по имени сервиса (если запуск через docker-compose)
2. докер контейнер с pgadmin должен быть объединен с контейнером с базой в одну docker сеть, т.к. в сети по умолчанию (которая бридж docker0 на хосте) не работает докеровский DNS
все равно придется управлять парком контейнеров - просто без оркестратора это будет набор баш скриптов или ансибл плейбук. Оценить удобство и предоставляемые возможности можете сами.
Касательно докера - все равно остается доступ к самому демону. И любой пользователь, который имеет sudo или включен в группу докер, может скомпрометировать систему. Решением выглядит использование оркестраторов вроде kubernetes/nomad, в которых есть RBAC. И они отрезают пользователя от демона. Все управление идет через API оркестратора. В том же направлении движется редхат со своим podman.
