Вы опять же не понимаете для кого написан данный материал, в первой статье я подробно ответил на аналогичную претензию.
Если вы не умеете поднимать это руками, а статья предназначена для людей которые только входят в администрирование, о какой системе управления конфигурациями может идти речь? На первом же фейле возникнет очень много вопросов.
обычно в таких случаях Apache вешают на 127.0.0.1:80, а nginx на внешний_ip:80(443). Этим вы закрываете доступ к Apache извне минуя nginx и оба работают на порту 80.
В третьей части статье будут описаны непосредственно виртуальные хосты, там будет разделение статики и передача PHP запросов Apache2. В целом в текущей настройке также предполагается, что Apache закрыт от внешних подключений, открыт только Nginx.
Прочитайте пожалуйста обе статьи, я несколько раз сделал упор на то, что ПО поднимаемое в статье не является полноценным стэком LEMP
Зачем связка ngnix+Apache2?
Разница в особенностях обработки соединений. Nginx лушче работает как прокси, поэтому мы используем его в этой схеме для обработки статических данных площадки. В то же время Apache занимается интерпретацией PHP.
Но можно из коробки и не брать ngnix, а обойтись Apache2
.Нет, если есть возможность использовать Nginx+Apache2, площадка будет работать быстрее. Пул Apache не будет использоваться при запросе статики.
тем более что это будет проще, чем то что описано и апач уже настроен на http, а https тут и не пахнет
При создании виртуальных хостов вы можете выпустить сертификат и настроить работу площадки по HTTPS на уровне Nginx. Это будет отражено в третьей статье, сейчас не совсем понимаю вашего вопрооса. Прием трафика Apache по 443 порту в дефолтной конфигурации нужно будет также отключить, так как этим будет заниматься Nginx.
Или я что-то совсем не понял и Apache2 не может принимать соединения на 80 порту?
Этот момент подробно отражен в статье, но я поясню для вас. Nginx устанавливается первым и по умолчанию занимет 80 порт сервера. После устанавливается Apache2, и не может запуститься так как 80 порт уже занят Nginx.
PHP-FPM не применяет файлы .htaccess из коробки, вероятно в вашей связке за их применение отвечает Apache2, так как судя по вашему сообщению он развернут. Или вы использовали решение, которое позволяет интегрировать.htaccess файлы в php-fpm, на сколько я знаю оно существует, но сам его ни разу не настраивал.
Люди! Прекратите использовать FTP при наличии в системе SSH.
Здесь мы говорим о тех доступах, которые просят клиенты такого уровня проектов. FTP до сих пор актуален, и это не моя прихоть описывать его настройку в статье. Если бы мы регулярно не сталкивались с просьбами предоставить доступ по FTP от разработчиков, я бы не описывал этот момент в текущей статье.
И шарашит по своим инструкциям для организации шаред хостинга. Потому что к шаред хостингу в обязательном порядке прилагается фэтэпэ, потому что… просто потому что тут так заведено. Ну и плюс они используют фтп для чрутования юзверей.При том что обозначенному в преамбуле "начинающему администратору своего сервера" этот самый фтп нафиг не сдался. В итоге и в статье место потрачено, и толком ничего не объяснено, поскольку по-хорошему тут надо отдельную статью писать, а не просто конфиг кинуть.
Настрока ПО по инструкции из данных статей прекрасно будет работать для CMS по типу Bitrix, в связи с чем вам так или иначе придется предоставить разработчикам доступ к файлам площадки. Для этих целей здесь и используется FTP. В третьей статье будет описано как предоаствить такой доступ, и там естественно будет chroot для FTP пользователя площадки.
Да, вы можете использовать SFTP для этих целей, однако вам придется позаботится о том, чтобы чрут каталог пренадлежал пользователю root. Что будет абсолютно неудобно при наличии нескольких площадок на сервере. Как показывает наша практика, разработчики на проектах подобного плана прекрасно использую FTP до сих пор.
Точно так же непонятно, нафига здесь Апач.Ну то есть опять же, на шаред хостинге, которым будет пользоваться типичный похапешник, без апача нельзя, поскольку без файла .htaccess эта социальная группа как без рук. Но на собственном сервере это совершенно лишний анахронизм.
В этом то и суть, что я описываю разворачивание стэка, который потом будет будет передан разработчикам, для размещения площадки. Администрирование же останется на плечах администратора. То есть разработке придется заливать файлы и настраивать редиректы. А как показывает практика настроить это в .htaccess файле для разработки быстрее, чем просить администратора вынести то же в Nginx. Для этих целей здесь используется Apache2.
У нас есть свои ansible роли для разворачивания стандартного стэка ПО, в зависмости от ТЗ клиента. Повторюсь, что цель серии статей не в том, что бы дать людям готовое решение, а описать именно ручное разворачивание вплоть до базовых команд. Мы посчитали это необходимым так как очень часто видим типичные ошибки у начинающих администраторов, которые приводят в том числе к простоям в работе проектов. Это, например, банальное не тестирование конфигураций перед их применением или внесение прав в sudo без использования visudo, что вобще может привести к потере рут доступа к серверу.
В данной статье я бы хотел вперую очередь предостеречь будущих администраторов от таких вещей и объяснить философию нашей компании - всегда проверяй все свои шаги по несколько раз.
Да, возможно в плане текста пулучилось достаточно сумбурно, здесь извиняюсь перед читателями, в следующих частях, которые будут выпущены на следующей неделе, я проведу модерацию текста.
Касаемо docker, я ответил выше, но повторюсь, перед тем как поднимать что то в docker, нужно понимать как работает ПО на хосте. Какие файлы и в какой момент используются. Docker все же стоит выше по уровню квалификации, и если вы сейчас начинаете заниматься контейнеризацией вашего стэка, вы можете пройти мимо этой статьи.
У нас есть статьи по настройке этих же решений в Docker. Целью серии статей является указать на особенности в настройке серверов, которыми пользуемся мы, тот же git autocommit. А также указать новичкам, которые хотят постигать администрирование, на какие особенности стоит обратить внимание в начале.
Я не совсем понимаю придирки касаемо exim, который в этом случае работает в режиме smarthost.
Касаемо же готового решения от Битрикс, то все минусы его я приводил в своей предыдущей статье. Безопасность, система логирования, внесение настроек и troublshooting решения от Биттрикс приносит боль и страдания многим администраторам. А приводить ее к удобному виду выйдет сильно дольше чем настроить сервер с нуля по общим стандартам администрования.
Да и как вы говорите проще нужно было описать как стэк выглядел бы в docker, но для новичков, я считаю, это не будет так актуально. Все же перед тем как поднимать данное ПО в Docker, нужно иметь большой опыт в поднятии этого же стека на хосте.
Вы опять же не понимаете для кого написан данный материал, в первой статье я подробно ответил на аналогичную претензию.
Если вы не умеете поднимать это руками, а статья предназначена для людей которые только входят в администрирование, о какой системе управления конфигурациями может идти речь? На первом же фейле возникнет очень много вопросов.
В третьей части статье будут описаны непосредственно виртуальные хосты, там будет разделение статики и передача PHP запросов Apache2. В целом в текущей настройке также предполагается, что Apache закрыт от внешних подключений, открыт только Nginx.
Прочитайте пожалуйста обе статьи, я несколько раз сделал упор на то, что ПО поднимаемое в статье не является полноценным стэком LEMP
Разница в особенностях обработки соединений. Nginx лушче работает как прокси, поэтому мы используем его в этой схеме для обработки статических данных площадки. В то же время Apache занимается интерпретацией PHP.
.Нет, если есть возможность использовать Nginx+Apache2, площадка будет работать быстрее. Пул Apache не будет использоваться при запросе статики.
При создании виртуальных хостов вы можете выпустить сертификат и настроить работу площадки по HTTPS на уровне Nginx. Это будет отражено в третьей статье, сейчас не совсем понимаю вашего вопрооса. Прием трафика Apache по 443 порту в дефолтной конфигурации нужно будет также отключить, так как этим будет заниматься Nginx.
Этот момент подробно отражен в статье, но я поясню для вас. Nginx устанавливается первым и по умолчанию занимет 80 порт сервера. После устанавливается Apache2, и не может запуститься так как 80 порт уже занят Nginx.
Спасибо, поправил!
PHP-FPM не применяет файлы .htaccess из коробки, вероятно в вашей связке за их применение отвечает Apache2, так как судя по вашему сообщению он развернут. Или вы использовали решение, которое позволяет интегрировать.htaccess файлы в php-fpm, на сколько я знаю оно существует, но сам его ни разу не настраивал.
Рад получить положительную обртаную связь!
Во второй частье статьи я постарался описать базовую настройку Nginx, в третьей части будет описано создание виртуальных хостов веб-сервера.
Спасибо за потраченное на чтение время, надеюсь информация изложенная в статье будет вам полезна!
Я поправил, спасибо.
Здесь мы говорим о тех доступах, которые просят клиенты такого уровня проектов. FTP до сих пор актуален, и это не моя прихоть описывать его настройку в статье. Если бы мы регулярно не сталкивались с просьбами предоставить доступ по FTP от разработчиков, я бы не описывал этот момент в текущей статье.
Настрока ПО по инструкции из данных статей прекрасно будет работать для CMS по типу Bitrix, в связи с чем вам так или иначе придется предоставить разработчикам доступ к файлам площадки. Для этих целей здесь и используется FTP. В третьей статье будет описано как предоаствить такой доступ, и там естественно будет chroot для FTP пользователя площадки.
Да, вы можете использовать SFTP для этих целей, однако вам придется позаботится о том, чтобы чрут каталог пренадлежал пользователю root. Что будет абсолютно неудобно при наличии нескольких площадок на сервере. Как показывает наша практика, разработчики на проектах подобного плана прекрасно использую FTP до сих пор.
В этом то и суть, что я описываю разворачивание стэка, который потом будет будет передан разработчикам, для размещения площадки. Администрирование же останется на плечах администратора. То есть разработке придется заливать файлы и настраивать редиректы. А как показывает практика настроить это в .htaccess файле для разработки быстрее, чем просить администратора вынести то же в Nginx. Для этих целей здесь используется Apache2.
У нас есть свои ansible роли для разворачивания стандартного стэка ПО, в зависмости от ТЗ клиента. Повторюсь, что цель серии статей не в том, что бы дать людям готовое решение, а описать именно ручное разворачивание вплоть до базовых команд. Мы посчитали это необходимым так как очень часто видим типичные ошибки у начинающих администраторов, которые приводят в том числе к простоям в работе проектов. Это, например, банальное не тестирование конфигураций перед их применением или внесение прав в sudo без использования visudo, что вобще может привести к потере рут доступа к серверу.
В данной статье я бы хотел вперую очередь предостеречь будущих администраторов от таких вещей и объяснить философию нашей компании - всегда проверяй все свои шаги по несколько раз.
Да, возможно в плане текста пулучилось достаточно сумбурно, здесь извиняюсь перед читателями, в следующих частях, которые будут выпущены на следующей неделе, я проведу модерацию текста.
Касаемо docker, я ответил выше, но повторюсь, перед тем как поднимать что то в docker, нужно понимать как работает ПО на хосте. Какие файлы и в какой момент используются. Docker все же стоит выше по уровню квалификации, и если вы сейчас начинаете заниматься контейнеризацией вашего стэка, вы можете пройти мимо этой статьи.
Прочитайте текст статьи внимательнее.
У нас есть статьи по настройке этих же решений в Docker. Целью серии статей является указать на особенности в настройке серверов, которыми пользуемся мы, тот же git autocommit. А также указать новичкам, которые хотят постигать администрирование, на какие особенности стоит обратить внимание в начале.
Я не совсем понимаю придирки касаемо exim, который в этом случае работает в режиме smarthost.
Касаемо же готового решения от Битрикс, то все минусы его я приводил в своей предыдущей статье. Безопасность, система логирования, внесение настроек и troublshooting решения от Биттрикс приносит боль и страдания многим администраторам. А приводить ее к удобному виду выйдет сильно дольше чем настроить сервер с нуля по общим стандартам администрования.
Да и как вы говорите проще нужно было описать как стэк выглядел бы в docker, но для новичков, я считаю, это не будет так актуально. Все же перед тем как поднимать данное ПО в Docker, нужно иметь большой опыт в поднятии этого же стека на хосте.