Я пытаюсь избежать проблемы, связанной с предположением и неправильным вопросом. Я собираюсь описать ситуацию, в которой я нахожусь, и в чем проблема.
В настоящее время у меня есть сервер разработки, на котором работают базы данных разработки и тестирования. Разработчики запускают apache локально, но подключаются к базам данных тестового сервера, чтобы все были на одной странице. Со временем обязанности этого сервера выросли. Он часто используется в качестве промежуточной площадки для подписания клиентами изменений. Между тем, количество клиентов и баз данных выросло. Сегодня сервер разработки остановился. Это было настоящим нарушением сегодняшнего рабочего процесса для команды разработчиков.
Сочетание задач активной разработки и CRON, которые были настроены во время тестирования, в конечном итоге замедлило работу сервера до такой степени, что он стал непригодным для использования. Я считаю, что доступ к диску сервера был узким местом.
Я просил об обновлении оборудования ранее, но, к сожалению, от руководства они не поступали. Апгрейд оборудования тоже не на что способен. Мне интересно, есть ли лучший способ достичь того, чего мы хотим, и хотим ли правильно настроить новый сервер, когда он появится.
В идеале мне нужна система, в которой легко «останавливать» сайты, включая их cron-рекламу, делая их промежуточные URL-адреса недоступными, когда они не находятся в активной разработке. Не менее важно то, что мне понадобится простой способ «запустить» их снова, предпочтительно через пользовательский интерфейс, чтобы наш нетехнический персонал мог это сделать.
Мне нравится идея решения на основе docker / vm, но я не уверен на 100%, как я буду это поддерживать. Самым большим препятствием для использования чего-то подобного, вероятно, является то, что я не уверен, как я смогу настроить их для использования в качестве промежуточной среды.
Было бы полезно изолировать разработку от пользовательского приемочного тестирования. Пара способов сделать это.
Разделите ресурсы на отдельные виртуальные машины dev и uat. Переход от разработчика к uat выполняется только тогда, когда другой разработчик соглашается с тем, что это не снижает производительность и не приводит к ужасным последствиям.
Попросите разработчиков внести свои изменения на свои рабочие станции. Иметь инструменты развертывания, которые могут запускать виртуальные машины с помощью локальной копии промежуточной базы данных и их версии кода. После объединения этой ветки приступите к интегрированному тестированию в системе staging / uat.
Вы можете назначить для каждого тестового проекта свой собственный порт высокого уровня для использования вместо обычного порта SQL и перенаправить эти порты на реальный сервер SQL на 1433 (или где-то еще). Тогда вы могли бы просто контролировать переадресацию портов. Вы можете сделать то же самое с портами HTTP.
Они могут быть переадресованы либо на самом сервере (с помощью iptables или firewalld), либо на клиентах (с помощью брандмауэров, туннелирования ssh или того, что они могут использовать на своих платформах).
Если бы это было сделано на стороне клиента, вам не пришлось бы предоставлять всем своим разработчикам root-доступ на сервере, чтобы снова включить их порты. Еще одно преимущество состоит в том, что если сервер станет полностью непригодным для использования из-за слишком большой нагрузки, вы все равно сможете отключить переадресацию портов на клиентах, пока нагрузка не станет более управляемой, и вы снова не сможете получить доступ к серверу.