Василий Банников

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

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

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

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

Вполне возможно, что эта разметка формируется на стороне сервера.
Если так, то никак - парси html

Если видео нормально показывается через yt-плеер, то смело устраивай.
А вот скачивать видео нельзя

cron например, либо свой демон, который будет смотреть на время и периодически запускать нужные задачи.

А чтобы несколько серверов не конфликтовали друг с другом - надо либо как-то их оркестрировать, чтобы работа разделялась на несколько серверов (Нужно смотреть на конкретную задачу, чтобы сказать, как можно разделить и можно ли вообще), либо делать распределённые блокировки.

тест coverage

Такой отчёт может CI/CD система выдавать, но для этого тестовый фреймворк должен ей эту информацию сообщий.
Это не статический анализ.
В случая голанга для этого используется go tool cover
Если используется гитлаб, то вот инструкция по настройке:
https://docs.gitlab.com/ee/ci/testing/test_coverag...

code smells и code security issues

Это точно умеет Sonarqube даже в бесплатной версии.
Можно ещё в ci добавить какой-нибудь dependabot или его подобие, который будет смотреть за устаревшими библиотеками. + npm audit

Суть в том, что я не совсем понимаю работу вебсокетов

Клиент отправляет на сервер 1 HTTP запрос, после которого у него остаётся на длительное время открытое двухстороннее соединение, по которому он может общаться с сервером, будто у него сырой TCP-сокет (по факту так и есть).

Подробнее можно почитать на MDN.

Может быть сам чат никто с 0 не пишет и есть какие-то готовые решения?

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

Насколько хорош мой выбор(yii2+vue+mongo)?

Не уверен только на счёт mongo, тк в моих глазах это очень специфичное решение, которое не везде есть смысл применять.
Если у тебя зафиксирована структура данных, и при этом у тебя нет кучи разных данных, которые хочется хранить в денормализованном виде, то реляционная СУБД будет, вероятно, и эффективнее и проще.
Возможно, mongodb будет иметь смысл, если ты захочешь работать с сотнями тысяч клиентов, и тебе нужно будет распределять данные на несколько серверов (возможно, в разных ДЦ)

yii2 - вполне ок вариант, раз у тебя уже есть опыт работы с ним. Модули для работы с вебсокетами для него есть.

Нюанс в том, что Youtube сделан как SPA - тоесть формально у него только одна страница.
+ Какой-то SSR для индексации и чуть более быстрого первого открытия.

Чтобы сделать что-то подобное, тебе как минимум нужно знать какой-нибудь фреймворк для создания SPA. Например Vue или React.

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

Тогда "скачать фронт" - это всё равно что сделать скан журнала, который тебе пришёл по почте.
А вот "скачать бэк" - это всё равно что получить копию издательства и полиграфии, вместе с людьми которые там работают.

Гипотетически второе тоже возможно, особенно в каком-то ограниченном подмножестве.
Если возвращаться к вопросу, то это возможно, если админ сайта оставил без пароля доступ к серверу, или если ты смог этот пароль подобрать, а весь бэк сайта - это голый php на одном серваке. Или если исходники полностью открыты и ты можешь посмотреть оригинал, например, на гитхабе.

Но в общем случае это невозможно.

"быстрая и простая" - всё закинуть на один мощный сервер.
Безопасность системы от количества серверов никак не зависит.

Если вы уже посчитали, что вам нужно несколько серверов, то:
1. Доступ к ним из интернета не должен быть (вернее должен быть только к фронту и бэку)
2. Везде обязательно должны стоять не дефолтные пароли
3. Сами пароли желательно должны храниться в каком-нибудь безопасном хранилище типа HC Vault
4. Обязательно должна быть какая-то система аутентификации пользователя и какая-нибудь ролевая/правовая система, чтобы обычный пользователь ну никак не могут сделать что-то, что ему нельзя.

Из коммуникаций у тебя даже в самой большой схеме получается что-то такое:
1. Пользователь (браузер на компьютере пользователя) загружает фронтовые файлы с Сервера 1, который раздаёт статику
2. С браузера посылается запрос к API на сервере 2
3. API с сервера 2 посылает запрос к БД.
N. Всё то же самое в обратном порядке для отправки ответа, кроме Сервера 1, который раздаёт статику.

Тоесть тут вообще никаких неочевидных проблем с выбором способа коммуникации вообще быть не должно.

А для надёжность стоит хотя бы по одной копии каждого сервиса сделать.

PS: ничего плохого в делании API Закрытым и server-server коммуникации нет.