Ваши проблемы)

Вы заявили о своей основной проблеме как

когда один из разработчиков запускает небезопасный код (допустим, это php-код), например, запускает бесконечный цикл! сервер полностью вылетает у всех, и я не могу определить, кто является неисправным разработчиком!

Поскольку код разработки всегда может дать сбой или зависнуть, вы эффективно решаете две разные проблемы:

1. Процессы разных пользователей не должны мешать друг другу и не забирать все ресурсы, голодать других или даже приводить к сбою сервера.
2. Идентификация пользователя, который «сделал это».

Если вы решите вторую проблему, вам все равно нужно будет решить первую; но если вы решите первый, вам больше не нужно решать второй, поэтому я сосредоточусь на решении первого здесь (кроме того, решать проблемы, не спорить с людьми о плохих вещах, всегда проще и меньше конфронтации).

Возможные решения

У вас есть три основных пути на выбор при изоляции действий пользователя друг от друга:

1. Процессы и файловая система: Самый простой и самый старый способ разделения - предоставить ресурсы каждому пользователю в многопользовательской системе UNIX.
   • uptime365 уже давал предложения по ulimit, Я просто хочу добавить, что вы должны убедиться, что ваши приложения также используют этих пользователей (вместо общих пользователей-демонов для каждой службы) и что они не хотят запускать процессы с другими учетными записями пользователей. Из-за этого недостатка сегодня этот подход используется редко, за исключением простых вещей, таких как сценарии сборки без инфраструктуры непрерывной доставки.
   • Квоты файловой системы сегодня более полезны, поскольку хранилище по-прежнему является основным ресурсом и работает почти со всеми приложениями.
2. Приложения: Большая часть программного обеспечения, к которому вы получаете доступ, уже имеет встроенное управление пользователями и квотами, но вам нужно управлять / настраивать его отдельно. Например, база данных может устанавливать квоты и разрешения для каждого пользователя и ограничить то, что он может сделать. Обратной стороной, помимо различной конфигурации (которая может быть объединена сценариями или приложениями), является то, что не все программное обеспечение одинаково хорошо оборудовано. Например, кажется, что GitLab все еще не поддерживает дисковые квоты. Вам нужно будет оценить причины ошибки и посмотреть, подходят ли данные функции для вашего случая.
3. Контейнеры и виртуальные машины: Использование виртуализации (полной виртуализации, такой как KVM или ESXi; или контейнеризации, такой как Solaris Zones, FreeBSD Jails, Linux LXC, или на основе приложений, например, Docker и др.), Позволяет вам предоставить каждому пользователю полноценную виртуальную систему, в которой он может делать все, что вы разрешите ему, но ограничьте его ресурсы, чтобы он не мешал другим пользователям. Это наиболее продвинутая форма разделения, потому что, по сути, каждый пользователь имеет свою собственную машину и вообще не вмешивается (если настроен правильно), поэтому у вас также есть разные параметры конфигурации и времени выполнения, разные сети, разные жесткие диски и так далее. Обратной стороной этого решения является то, что у него самые высокие накладные расходы на конфигурацию и использование ресурсов из трех.

Конечно, всегда возможны комбинации, поскольку подходы работают на разных уровнях. Например, вы можете использовать контейнеры, чтобы у каждого был свой веб-сервер, но разрешить всем пользователям использовать одну и ту же базу данных для экономии ресурсов (доступ к базе данных происходит быстрее, чем с несколькими разными базами данных), ограниченный квотами базы данных.

Что делать в вашем случае?

Как видите, возможностей много, и каждая из них требует значительных усилий, поэтому вам нужно сузить круг:

• Сначала проанализируйте, с какими именно проблемами вы столкнулись. Взгляните на свой процесс (или, если у вас его нет, спросите своих коллег, как они выполняют свою работу) и определите возникающие проблемы (дисковое пространство заканчивается при выполнении тестовых примеров, бесконечные циклы резервируют слишком много памяти, веб-сервер вылетает из-за неперехваченных исключений или плохой архитектуры и т. д.).
• После того, как вы узнаете, с чем сталкиваетесь, подумайте о том, как смягчить проблемы, сохраняя при этом простоту. Конфигурация для 10 ПК занимает примерно столько же времени, что и для 100, поэтому сначала следует попробовать простые вещи (в большинстве случаев этого уже достаточно). Дисковое пространство может быть ограничено пользовательскими квотами, в то время как бесконечные циклы, а также чрезмерное потребление памяти могут быть обнаружены модульными тестами преждевременно (выполняются как локальный пользователь, а не на веб-сервере).
• Если этого недостаточно, вы можете подумать о реализации более крупных и лучших решений, таких как контейнеры. Вначале вы потеряете время, но в конечном итоге это может окупиться - конечно, в зависимости от конкретной ситуации.

В качестве превентивной меры вам следует изучить ulimits, если вы хотите установить определенный набор ограничений для пользователей. Вы можете установить ограничения процесса / ЦП / памяти.

Пожалуйста, обратитесь эта ссылка

Другой способ - отслеживать использование ресурсов системой с помощью внешнего инструмента мониторинга (наиболее распространенный пример: nagios / nrpe), который может предупредить вас в случае превышения порогового значения ресурсов.