как я понял по ответам тут собрались адепты докера. В этой церкви последователь должен появиться атеист. Только сегодня был большой срач насчет какие проблемы можно получить при переходе на докер https://habrahabr.ru/post/332450/ очень советую почитать.

Теперь к вашему вопросу. Докер НЕЛЬЗЯ использовать для персистентный образов. Т.к. если его правильно готовить никакой уверенности нет на какой ноде будет запускаться ваш контейнер физический. Т.е. все что пишет в память или на диск нельзя оборачивать в докер контейнер. Потом есть системы оркестрации, которые ваш контейнер могут с одной ноды на другую перебросить, что вы думаете будет с памятью контейнера - правильно, она очистится.

Тут мне могут возразить что у нас все работает на "отлично" - это вы господа с проблемами не сталкивались. Читаем статью по ссылке выше и начинаем готовиться.

Давайте разберем ваш стек и посмотрим что можно упаковать в докер контейнер.
- NodeJS - не знаю как это у вас работает, если нет состояния - то можно
- MongoDB - база, пишет в файлы, однозначно нельзя
- ElasticSearch - этого зверя точно нельзя он и в память и на диск пишет
- Redis - пишет в память, точно нельзя

И что в итоге вы хотите обернуть в контейнер? И зачем вам докер? Чтоб mongodb была запущена от имени root? При этом мы помним о проблемах с безопасностью самой mongodb. Или elasticsearch завернуть в докер, он физический сервер способен утилизировать на 100% по памяти, пропускной способности дисковой подсистемы и 100% процессорного времени, а вы ему хотите еще один уровень абстракции в лице докера? ))

Одно дело на компьютере разработчика использовать docker-composer и совсем другое дело в продакшене.

1. Проверить несколько файлов можно так www.yiiframework.com/doc-2.0/guide-input-file-uplo... file валидатор умеет проверять массив файлов, а поскольку image валидотор сделан на его основе https://github.com/yiisoft/yii2/blob/master/framew...

This validator checks if the input value represents a valid image file. It extends from the file validator and thus inherits all its properties.

тогда и он может

2. Image валидатор всего лишь получает метрики изображения https://github.com/yiisoft/yii2/blob/master/framew... и сравнивает их с теми что вы указали в настройках валидации. Можно создать валидное изображение с вредоносным кодом. Потенциально это дырка в безопасности. Можно обезопасить себя через "пересборку" изображения под конкретные размеры, для nginx почитайте тут habrahabr.ru/post/94435 или можно реализовать подобное на php с кешированием, но работать конечно будет медленнее.

3. Есть, вот пример использования https://github.com/yiisoft/yii2/blob/master/framew...

Ответ на ваш главный вопрос - это количество памяти которое кушает расширение отвечающее за работу с изображениями. GD нужно меньше, а вот ImageMagic кушает совсем не прилично много.