Какую технологию выбрать?

Всем привет. Подскажите, что стоит выбрать для моих нужд. Докер, виртуальную машину или что-то еще.

Что мне нужно:

1) Возможность подключаться по ssh, ftp с любого ПК в одной локальной сети.
2) Возможность сделать копию текущего состояния и развернуть на другом ПК со всеми файлами БД и.т.д. (Не в текущей локальной сети)
3) Возможность работать с nginx, apache, npm, php, python, mysql
4) Быстрое обновление до последних версий вышеуказанных модулей. (Как у докера. Указал в конфиге версии и собрал контейнер по новой)
5) Работа с пользователями ubuntu. У каждого пользователя будет своя папка и свои данные для подключения по ssh/ftp, где они будут работать с модулями указанными в пункте 3.
6) Веб-ресурсы пользователей должны будут отображаться в браузере на любом ПК в локальной сети.

Дополнительно:

Самое главное не указал:
1. Для чего именно ты собираешь окружение? Для разработки или для прода?
2. Что такое "веб-ресурсы пользователей"?
3. Для чего тебе к этому подключаться по ssh и ftp? (для каждого нужно отдельное пояснение)
4. Что подразумевает под собой словосочетание "возможность работать с ..."?
5. Кто такие "пользователи"?

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

Если тебе всё-таки именно виртуальные машины нужны, то тогда и бери виртуальные машины и настраивай их при помощи ansible.

Если тебе нужны контейнеры, то бери k8s, но тогда уже придётся отказаться от 1,2 и частично 4 с 5, тк:
1. Контейнеры не должны иметь состояние. Так что сразу отлетает п2
2. Контейнеры должны быть изолированы, а по тому сразу отлетает п1 с доступом внутрь контейнеров
3. Обновление зависимостей (например базового образа) требует пересборки и перезапуска контейнера
4. Один контейнер - одно приложение. Не будет такого, что у тебя в одном контейнере будет всё что ты описал в п3 одновременно работать.
5. Никаких "папок" для пользователей не будет. Но у каждого пользователя-человека вполне может быть своя учётка для доступа в кластер, чтобы в нём создавать свои ресурсы. При этом на уровне учётки можно запретить одному пользователю доступ к ресурсам другого пользователя например.

• По вопросам:

  1) Это локальная сеть в которой будут работать человек 15. Для того, чтобы пользователи подключались к серверу и выполняли тестовые задание, связанные с программированием на Laravel.
  2) Сайты написанные на Laravel.
  3) ssh взаимодействие с php на сервере через консоль. FTP - закидывать файлы со своего ПК.
  Переносить файлы с сервера на свои ПК.
  4) Использовать и настраивать через консоль или FTP, например, править конфиги Nginx.
  5) Иметь доступ только к своим папкам в директории /home на сервере с OC ubuntu.
  Грубо говоря по FTP Laravel закинуть к себе в домашнюю директорию.

• VoRoN1999, если проверяется именно работа с Laravel, а не умение деплоить в кубер, то легче будет действительно взять какой-нибудь proxmox например и использовать ansible для начальной настройки
• Василий Банников, Где могу более подробно изучить данную тему?
  Буду благодарен, если скинете пару статеек.
• VoRoN1999, да хоть на том же хабре вводи в поиск и сортируй по рейтингу - будет тебе куча статей.

• Если тебе нужны контейнеры, то бери k8s, но тогда уже придётся отказаться от 1,2 и частично 4 с 5, тк:

  Это вы прочитали в истинно верной книжке линуксоидов-безопасников?) С контейнерами можно делать всё то, что описал автор, и ему вовсе не нужно для этого разрешение международного консенсуса по правильному использованию контейнеров.
  На всякий случаю поясню для VoRoN1999 , что:
  1) Контейнеры успешно имеют состояние вопреки линксоидам
  2) Контейнеры просто работают, можно настроить доступ хоть по SNMP. Никой изоляции они не обязаны придерживаться, а эти слухи распускают безопасники.
  3) Обновление никак не связано со сборкой. Просто некоторые люди решили за вас пересобрать контейнер с новой версией. Но вы можете обновить софт, можете разделить софт и данные, можете много всего сделать с обновлением...
  4) Один контейнер - один контейнер. В нём будет работать абсолютно всё, что запущено, хоть 4235 приложений.
  5) Контейнер совершенно никак не связаны с файловой системой. Они могут содержать любые папки для любых пользователей, а также монтировать папки хоста и много чего ещё.

• Griboks, ага, но то что вы описываете очень сильно расходится с тем, как это показывается в любом руководстве => требует чуть более чем среднего понимания, чтобы не выстрелить себе в ногу.

  В то время как то что хочет автор является вполне обычным сценарием для "жирных" виртуалок.

  Пасы в сторону безопасников, если честно, не понял - это скорее про удобство работы, чем про безопасность.
  Гораздо легче собрать новый контейнер, и перенакатить deployment, чем подключаться к каждой поде по отдельности и менять исполняемые файлы как-то внутри них, попутно пытаясь не стриггерить перезапуск мёртвой поды из-за остановки процесса.
  => доступ по ssh и ftp тупо не нужен.

• Griboks, Для многих контейнер - это просто модное слово и оно совершенно отвязано от понимания того, что это просто упрощенная виртуалка. Про безопасников честно говоря совсем не понял - к чему тут? Контейнер безопасен не более и не менее, чем обычная виртуалка, запущенная в KVM или VB - просто у него другая область применения.
• CityCat4, контейнер менее безопасен чем виртуалка, которая в свою очередь менее безопасна чем выделенный сервер. Поэтому безопасники продвигают аудит контейнеров, минимальные изолированные сборки, блокировку портов и т.п.
• Griboks, Любой треп за безопасность не имеет смысла без модели нарушителя. Если мы под виртуалкой понимаем KVM, например, то чем один контейнер менее безопасен чем одна виртуалка?
• CityCat4, согласен, безопасники с давних времён портят всем жизнь. Пусть сначала исходящие порты закроют, а потом уже начинают копаться внутри сети.
  

  чем один контейнер менее безопасен чем одна виртуалка

  У контейнера больше эксплойтов + обычно используются готовые потенциально вирусные контейнеры из хаба. Т.е. установить на виртуалку вирус сложнее, чем написать docker run not-a-virtus-image.