Почему точно не стоит работать с PHP под IIS

Недавно столкнулся с задачей, которая помимо всего прочего включала перенос web приложения на Yii 2 с сервера Windows (IIS 10) на сервер Linux (LAMP).

Сам по себе процесс переноса абсолютно тривиален. Создать архив на сервере «первоисточнике» и распаковать его уже на своём сервере, прописать права на папки и доступ к базе данных. Но, после переноса сразу же начались проблемы.

При обращении к любой странице приложения браузер отображал только «белый экран». Не помогало даже включение ошибок для PHP.

Причину удалось найти только когда после безуспешных попыток выявить и устранить неисправность «традиционными» способами, дело дошло до ревизии файлов с PHP кодом. Выяснилось, что целый ряд жизненно важных файлов Yii 2 был просто на просто повреждён в процессе архивации. То есть, на сервер Linux были перенесены изначально неработоспособные файлы со всеми вытекающими последствиями.

Корректный перенос стал возможен только после выполнения на «первоисточнике» повторной архивации:

  • С остановкой IIS;
  • Без остановки IIS, но с предварительным копированием всех файлов в отдельную папку и с последующей архивацией в ней.

Таким образом получается, что, при создании копии web приложения на PHP под управлением IIS, есть реальная угроза потери данных.

Это особенно это опасно для production серверов. Ведь в данной ситуации при автоматическом резервном копировании нет гарантии, что приложение будет сохранено в архиве в работоспособном состоянии и в случае необходимости восстановления его действительно будет из чего восстанавливать.

В общем, как это ни прискорбно, стек Windows в очередной раз показал свою непригодность для серьёзной работы с PHP.

Безусловно, есть ситуации, когда нет альтернативы (например, необходимость напрямую работать с СУБД MS SQL Server), но в остальных случаях имеет смысл задуматься о том, чтобы завести в своём «арсенале» хотя бы виртуальную машину с Linux.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *