index0h

В Украине РКН не работает, используйте любого крупного не украинского и не российского провайдера. DigitalOcean например

mogilefs
minio

Импакт от докера по ресурсам довольно низкий, но для такого куцого сервера он может быть ощутим.
Тонкую настройку он не обеспечит, а сложностей добавит.
Про лоад балансер забавно. Какой смысл заморачиваться с распределением нагрузки на калькуляторе?
На счет утечки - исправить таки стоит. Что касается восстановления при падении - смотрите в сторону supervisord, что касается убивания обожравшегося процесса - oom killer.

Те, кто в теме, подскажите, насколько это оправдано(docker-compose уже собран и готов к работе)?

Для dev целей - оправдано, для оркестрации в рамках одной машины - оправдано.

Чем лучше оркестрировать docker-compose

Да как бы сам docker-compose вполне себе оркестрирует на одной машине.

как обновлять приложение без простоя

Это вопрос процесса разработки. Само приложение должно разрабатываться так, что бы в момент релиза могли существовать как минимум две версии релиза.
Но, у вас по утечке ребутается php-fpm, не парьтесь.

как рассчитывать необходимые ресурсы для контейнеров?

На основании средней и пиковой нагрузки.

https://www.youtube.com/watch?v=lHpVxk9TPA8

Гуглите на тему ELK

В полной мере - никак

Вопрос из серии пальцем в небо.
Не меряется нагрузка в посетителях. Она меряется в rps и *bit/s. Также нужно знать прожорливость вашего ПО к io+ram+cpu иногда еще и gpu.
Количество серверов, способы распределения нагрузки, всякие репликации бд, распределения между ДЦ подбираются по конкретный проект.
Не бывает в природе такого, что вот так хренак и у вас откуда не возьмись 1кк активных юзеров, ну разве что событийные проекты типа прямых трансляций. Именно по этому рекомендую начать с малого, а дальше оптимизировать и распределять нагрузку между серверами там, где это необходимо. Например, у вас фото сток: cdn - это то, что вам потребуется. У вас месенджер - стоит выделить кучку серверов на поддержание сокетов с пользователями + хорошо прработать историю сообщений.

Смотри что жрется и чем. Htop + iotop

В центре есть определенное количество компьютеров без пароля.

Снизьте это количество до 0. Для каждого учащегося заводим отдельную единую учетку (можете в сторону LDAP посмотреть) + свою маленькую песочницу. На счет sql инъекций - если это сайты вашего учреждения - режьте доступы по самое не балуйся. Если же чужие - как бы и хрен с ними, не ваша задача защищать весь интернет от школоло. Логгируйте активность.

Объявите конкурс: на обход защиты. При этом как и в реальности за раскрытие должны быть весомые плюшки, за скрытый взлом - весомые проблемы. Например:
* белый взлом - "отлично" автоматом
* черный взлом - "кол", без права пересдачи

э... а чего ssh ключи не подходят?

Для разработки и экспериментов - это вполне хороший подход. На счет всей остальной деятельности - похоже на паранойю, у вас входной ip все равно общий.
Правда эту паранойю можно немножко развить, если ваши виртуалки будут:
* разбросаны по миру
* не будут содержать информации о вас
* не будут содержать информации друг о друге
* в случае попытки взлома будут самоуничтожаться на уровне железа (например с помощью промышленной пиротехники)
* вы будете пользоваться ими с разных мест разными "однодневными" устройствами
* пользоваться разными защищенными каналами связи
* для сообщений будете использовать элементы стеганографии.
Вот в этом случае вас раскрыть будет довольно трудоемко и дорого.

-- --

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

Коллеги, вопрос ведь заключается не только в контроле поставленных задач, а в их правильной оценке трудозатрат, расписанию задач и выполнению.

Контроль выполнения поставленных задач - это задача project manager.
Контроль качества выполнения задач - это задача qa.
Расписание задач и выставление приоритетов на этапе планирования - это задача project owner + project manager + ...(зависит от процесса).
Расписание задач и выставление их приоритетов уже в процессе выполнения - это задача project manager.
Оценка трудоемкости - это задача developer.

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

Предприниматель как правило находится в роли project owner, оценка трудозатрат - это не его привилегия. Дело в том, что оценить их может только программист.

Может я конечно чего то не понимаю, но: если программист выполняет поставленные задачи за приемлемое время/деньги - вообще по боку, чем он занимается. Если не выполняет, вы уведомили его об этом и ничего не поменялось - пора прощаться.

Elasticsearch
Для логов: some_logs_source > Logstash [ > Redis ] > Elasticsearch > Kibana

Дизайнер - отдельный комп, железно.
На счет остальных - терминальный сервер + тонкие клиенты. Но многое зависит от используемого ПО, например PHPStorm если будет у каждого - оперативка будет расходоваться со скоростью звука.

Я бы на вашем месте посмотрел в сторону неттопов.