Скорее всего на wifi устройствах включен random mac. Посмотрите на каком нибудь одном устройстве после подключения к сети wifi какой mac/ip? Затем переподключите и снова проверьте, скорее всего будет новый mac и следовательно новый ip. С точки зрения dhcp сервера новый мак это новый клиент, значит надо выдать новый ИП, все честно, это нормальное поведение систем.
Простите, поменять записи на своем сервере? Так они поменяются только на своем! :) В интернет эти изменения не уйдут. Регистраторы доменов в таком случае перестали бы существовать.
Sanes, значит не ваше это. Нужно подождать, когда созреете или в кругу ваших задач не появится автоматизация такого уровня.
Я не навязываю, просто высказал свое видение перспектив, полагаясь на свой опыт.
Tech radar тот же подсказывает, что тенденция идёт к контейнеризации всего :) на десктопах snappy, flatpack. На серверах docker, systemd-nspawn, podman, crio, lxc/lxd. Системы оркестрации виртуализации proxmox тот же умеет в lxc. Про кубер вообще молчу.
Если для вас обновление с даунтаймом это глупости, тогда сорян. Видимо контейнеры и правда пока не надо вам.
Sanes, в докере все библиотеки от dev до прода проходят весь путь и поведение абсолютно предсказуемо. + Задел на будущее миграция в кубер или swarm, где можно реализовать и canary release и бесшовный upgrade. Даже с ansible эта задача превратится в не решаемую, если допустим понадобится откат :)
К тому же деплой происходит 1 командой (docker-compose) и в минимальные сроки с минимальными проблемами. Нет зависимостей от дистрибутива на хосте.
Технология уже не настолько новая, чтобы ее бояться. Плюсы очевидны ;)
Sanes, не поверите, в докере локально тестирую ансибл роли молекулой, затем это делается в CI, при комммте. :)
И ансибл не даёт той гибкости версий софта и тех гарантий относительно докера.
Это сильно разные вещи, не нужно сравнивать инструмент управления конфигурациями и технологии контейнеризации.
glassMonk, скорее антенны принято настраивать на середину диапазона, чтобы обеспечить линейность на протяжении всего диапазона.
В варианте с квартирой можно не заморачиваться даже, все равно повышение мощности только навредит.
И помним, повышая мощность на точке доступа, кто повысит мощность на роутере? :) Связь должна быть двухсторонней. Кстати не помешает обратить внимание на соседский роутер, где он фонит, свой лучше не ставить.
Иван Шумов, тогда в вашем кейсе нужен packer или ostree. Там можно проконтролировать каждый файлик и собрать микромонолит :)))) вроде модный тренд кстати:)
Иван Шумов, итак мы выяснили, что при использовании хвостовой cgroup для сети по сетевой части оверхеда нет, теперь смотрим на изоляцию процессов, сколько килобайт там потратится на новый неймспейс? 1-2? Мне кажется это не та экономия :) кстати, при использовании, например systemd, можно руками так же как и докер настроить capabilities, создать cgroup namespaces, чтобы, например применить отличные от хоста sysctl. И это даже происходит в некоторых сервисах и никто не жалуется на оверхед :))
Что касаемо изоляции это очень хорошо, ведь с докером очень легко доставить весь софт со всеми зависимыми библиотеками! Кроме того повышается безопасность. Взломав вордпресс, зловреды вряд-ли выйдут на хост и узнают ключи от хоста или пароли от соседних проектов или демонов.
И самое главное, что накладные расходы минимальны, так ещё и лимитировать можно потребление ресурсов! :)
Кстати, если нужен shm между контейнерами, то можно использовать общий неймспейс для процессов (ipc), и да, если процесс на хосте, то можно хостовый неймспейс взять, но это уже так себе изоляция :)
Докеры на vps норм штука, при умелом использовании.
Иван Шумов, ну вот опять, откуда нат в докере взялся? С какой целью на VPS входящий трафик прогонять через такого монстра как NAT?
Я вам тоже из личного опыта говорю :) ничего он не жрет, считай бесплатный, главное головой пользоваться при принятии решений, что и как будет работать.
Для того, чтобы с входящих соединений убрать все оверхеды решение простое - не использовать ничего перед ними, тоесть использовать сеть хоста. В итоге nginx окажется на интерфейсах хоста, так, как будто он был запущен на хосте! Ни NAT ни docker-proxy больше не помешают и задержек не будет. И зачем тут глубокие познания сети? :)
Иван Шумов, не знаю где вы это взяли, но это не правда. Сетевая латенси, о которой вы говорите берется от неграмотного использования и не понимания принципов работы docker. Да действительно она будет, но только в том случае, если порты будут проброшены (publish), а проброс делается через docker-proxy, который написан на go и под нагрузками даёт просадки по cpu и rps. Выход? Не делать проброс в портов, а использовать сеть хоста! --net host, при создании.
Мощь cgroup и образов не даёт никакого оверхеда в рантайме, зато мега круто повышает скорость и простоту доставки приложения до прода + воспроизводимость в разных окружениях.
Для справки, если без докеры, то systemd из коробки использует cgroup для запускаемых сервисов.
Когда уберет проброса портов и если будет много трафика и будете упираться в conntrack, так же рекомендую в iptables в цепочке raw сделать notrack для 80 и 443 ну или на каких у вас работает nginx. Это значительно разгрузит сетевой стек и cpu.
NRinat, если переподключение произошло быстро, а это происходит быстро даже при wpa2-psk, tcp не рвется, он умеет "перезванивать". В udp не сессий, звонок просто словит тишину на 1-2 сек. При использовании wpa2-eap переподключение ускоряется за счёт передачи сессионных данных с радиуса и технически выглядит как типичный лаг в сети, 2-3 пинга потерялись, то есть по факту 1 сек.
По ощущениям mikrotik работает хуже за счёт худшей антенны и радиомодулей. Правда у меня были 951 кроты против unify ac pro, где есть технология fairness и поддержка 5Ггц и усовершенствованная антенна и кажется там MIMO групп больше, нужно спеку смотреть. В любом случае unify выходят приятнее как по управлению так и по цене и функционалу. Только не берите дешёвые, берите Pro серию и обязательно наличие fairness(справедливость) это когда точка равно делит air time между клиентами.