Последние сообщения

Как минимум, заменить stub-зону полноценной вторичной зоной, содержащей все записи зоны. Возможно этого будет даже достаточно.

Кеширующий сервер висит на порту 53 и все неизвестные запросы отправляет на сервера forwarders, а все запросы к основной зоне — на авторитативный сервер на порту 5353 

Строй Дом

В том и проблема, что на внешний запрос у вас отвечает не авторитативный сервер, а кеширующий. Ответ от кеширующего не может считаться авторитативным.

Нужен непосредственный доступ извне к авторитативному серверу. 

Не вижу никаких проблем, как и любое лицензионное ПО Вы можете спокойно продавать в рамках объекта собственности. Мы в пандемию в 2021 году, когда закрывались, продали свой маркетплейс, а через год уже купили и сделали новый, в договоре сказано, что Вы не можете его тиражировать, а не продавать

Не вижу никаких проблем, как и любое лицензионное ПО Вы можете спокойно продавать в рамках объекта собственности. Мы в пандемию в 2021 году, когда закрывались, продали свой маркетплейс, а через год уже купили и сделали новый, в договоре сказано, что Вы не можете его тиражировать, а не продавать

Проще говоря сайты на DST Platform, можно продавать точно также как и любые другие сайты на других платформах, например, как на том же CS Cart и на том же Битриксе, но нельзя делать массово копии и продавать их от лица как будто Вы Битрикс или CS Cart, логично что этот пункт придерживаются все платформы. Так что свой сайт Вы совершенно спокойно можете продавать и это не нарушает никаких лицензий.

Проще говоря сайты на DST Platform, можно продавать точно также как и любые другие сайты на других платформах, например, как на том же CS Cart и на том же Битриксе, но нельзя делать массово копии и продавать их от лица как будто Вы Битрикс или CS Cart, логично что этот пункт придерживаются все платформы. Так что свой сайт Вы совершенно спокойно можете продавать и это не нарушает никаких лицензий.

В пункте 8.5. договора сказано:

Заказчик вправе распоряжаться сайтом, как объектом собственности, может продать его, отдать в дар, передать по наследству, ограничение права накладывается на само ПО и его копии, которые по условиям настоящего договора Заказчик не вправе делать.

То есть ограничение накладывается не на сам сайт, им вы можете распоряжаться полностью как своей собственностью и предать лицензию новому владельцу, ограничение действует только на тиражируемые копии, то есть вы не можете продавать ПО другим людям, а вот сайт можете.

Сайт вы продать сможете, но не сможете продать именно исключительное авторское и имущественное право на ПО. Вы сможете передать новому владельцу только права по лицензионному соглашению, саму лицензию.

В пункте 8.5. договора сказано:

Заказчик вправе распоряжаться сайтом, как объектом собственности, может продать его, отдать в дар, передать по наследству, ограничение права накладывается на само ПО и его копии, которые по условиям настоящего договора Заказчик не вправе делать.

То есть ограничение накладывается не на сам сайт, им вы можете распоряжаться полностью как своей собственностью и предать лицензию новому владельцу, ограничение действует только на тиражируемые копии, то есть вы не можете продавать ПО другим людям, а вот сайт можете.

Сайт вы продать сможете, но не сможете продать именно исключительное авторское и имущественное право на ПО. Вы сможете передать новому владельцу только права по лицензионному соглашению, саму лицензию.

Попробую на пальцах

базы данных — в нормальных контейнерах типа lxc/openvz или в отдельной впс. чисто потому что бекапы и репликация там в нормальном режиме с нормальным доступом, плюс опять же ip адрес статический, чего в докере нет и врядли будет.

докерные контейнеры — это повторимая виртуалка имени одного процесса. Тоесть, вы четко говорите в докерфайле что, зачем выполнять и что конкретно запускать в форграунде, т.е на первом плане, вариант service apache2 start не канает, контейнер остановится после ухода приложения в бекграунд, также почитайте про проблему docker pid 1 и почему это все запускается в обвязке из того же bash.

Докер очень сильно привязан к своему хабу и гиту, чтобы «git pull & start app одной кнопкой» на каком-то та внутреннем айпишнике из серой сети.

Может, это не ваш случай, но после 700 конкурентных запросов, у меня на сервере тоже происходил затык.

Дело было в в создании файлов сессий на диск, после переноса сессий в редис от этого избавился.

А чем плох dotdeb? у меня и в убунте и в дебианах разных работает хорошо.

в притом на реальном боевом проекте с 5000-6000 в сутки пользователями, в онлайне правда не как у ТС но всёж.
сервачок купил на ебее за 100 баксов 3 года назад.

тоже валился от нагрузки, настроил кэширование на nginx (это уже после всяких мемкэшедов, еАццелераторов, и прочих штук кэширующих мускул запросы)

Про уровень управления всей инфраструктурой. Сейчас много говорят про гугловый Kubernetes. Однако, лично мне больше понравился не такой раскрученный, но очень навороченный Rancher. Мне кажется, он вам подойдет хорошо. Он позволит:

а. Подключить в одну web(!)-консоль машины от разных облачных провайдеров.
b. Управлять большинством параметров как непосредственно контейнеров, так и более масштабных связок.
с. Управлять томами для хранения персистентных данных. Проблема переноса данных между хостами там можно решить подъемом в 3 клика кластера GlusterFS, например. Также есть своя разработка для синка — Convoy.
d. Контролировать функционирование сервисов и хостов, автоматически запуская контейнеры на других хостах.
e. Поднять между хостами (напомню, что они могут быть размещены в разных ДЦ у разных провайдеров) свою приватную сеть, где все хосты и все сервисы смогут «видеть» друг друга.
f. Балансировать нагрузку между несколькими контейнерами на разных машинах.

Магии там нет. Все можно настроить и так. Однако, как стартовое решение, которое скроет кучу настроечных сложностей, должно подойти хорошо.

> Docker. Как его применять на вебсервере?

Никак. Docker — игрушечная технология не предназначенная для использования в реальных задачах. Ставя докер вы четко говорите себе «Мне плевать на обновления безопасности, они мне не нужны».
Если вам нужна контейнеризация, то есть lxc.

Если вы контролируете обстановку, можно собрать и поставить php-fpm самому. Желательно адекватным способом, а не make install. (то есть собрать deb-пакет и дать менеджеру пакетов самому поставить его)

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

Увеличте backlog бэкэнда, запросы которые он не сможет принять буду ставиться в очередь. Но увлекаться этим не стоит, пользователь не будет у вас ждать, пока его запрос из backlog будет бэкэндом взят и обработан. Значит смотрите в сторону ускорения приложения. Сколько времени генериться страница? Если ли страницы которые одинаковы для всех? Выносите их в memcached и забирайте самим nginx-ом, не дергайте лишних раз бэкэнд. Включены ли акселераторы в духе XCache? Все ли скрипты при этом в кэше? Как обстоят дела с соединения к базе, сколько по времени они занимаются? Используется ли кэширование на этом уровне? К примеру, у меня в случае забора ответа от СУБД страница в среднем на одном проекте генерится ~15-20 мс, если данные забираются из кэша в роли которого работает Redis, то величина падает до ~2-10 мс, т.е. до 10 раз. И бэкэнд готов обрабатывать следующий запрос.

В общем обращаю внимание, что установка php-fpm чудесным образом ситуацию может не изменить, хотя возможно сгладит её.