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

Не вижу никаких проблем, как и любое лицензионное ПО Вы можете спокойно продавать в рамках объекта собственности. Мы в пандемию в 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 чудесным образом ситуацию может не изменить, хотя возможно сгладит её.

1) data-only containers

2) решите задачу подъема самого сервера с запущенным Docker, в контейнерах задаете политику всегда перезапускаться — они вместе с самим Docker запустятся

3) в идеале по контейнеру на процесс либо логическую часть, к примеру MariaDB это один, Python сервер это второй и так далее

4) внимательно изучать внутренности, кроме официальных выбирать только те, которые имеют автоматические билды с отрытым Dockerfile и поддерживаются актуальными, иногда придется делать свои

5) ответ тот же что и 1) + резервное копирование/восстановление из томов

6) не встраивайте чувствительные данные в образы и не попадут

В качестве неплохого примера можете посмотреть мою разработку (правда, ориентирована на PHP, но суть та же, посмотрите как устроено): github.com/nazar-pc/docker-webserver

Правильно делаете, что не доверяете dotdeb.org. Я лично ничего больше от них ставить не буду, был негативный опыт, причем два раза.

Поставить php-fpm можно вот таким способом: zagirov.name/debian-testing-install-php5-fpm

Т.е. по сути этот пакет одинаков для любого php 5.3. Достаточно просто убить внутри пакета зависимость от версии и можно ставить. Я это проделал у себя, все работает.

Вы читали кучу мануалов, но упустили самое главное — официальная документация. Как так? Там как раз и говорится как делать и почему. На вопросы уже поотвечали, но пройдусь ещё раз, раз столько времени на чтение ответов потратил :>

1) docs.docker.com/engine/userguide/dockervolumes/

2) docs.docker.com/engine/articles/host_integ...

3) Ответ простой — как хотите. Как лучше знаете только вы, звучит банально, но это так. Хотите хоть всё в один контейнер запихните, это ваше дело. Хотя рекомендуют 1 компонент на 1 контейнер. В этом есть своя логика — хочется обновить только mysql — обновляете этот контейнер и не думаете, поломался ли у вас uwsgi или nginx или ещё чего.

4) Напишите свой первый Dockerfile, станет куда яснее как выбирать. А пока доверяйте только официальным образам.

5) git? Этот вопрос — следствие непонимания вопроса 1)

6) Уже ответили. Самое простое, если не понимаете — не используйте dockerhub вообще. Или начните понимать. :) Или платите за приватные репозитории, чтобы не думать об этом.