Комментарии 20
В 2022 у нас есть Ansible, Chef, Puppet, SaltStack ... а люди продолжают писать статьи о том, как поставить 6 приложений, написать кучу конфигов и запустить одно свое (сайт).
Напишите лучше рецепт/формулу/плейбук/манифест для этого всего и объясните как ее/его настроить, люди вам спасибо скажут.
Вы опять же не понимаете для кого написан данный материал, в первой статье я подробно ответил на аналогичную претензию.
Если вы не умеете поднимать это руками, а статья предназначена для людей которые только входят в администрирование, о какой системе управления конфигурациями может идти речь? На первом же фейле возникнет очень много вопросов.
Ну, если для начинающих, тогда точно Ansible! Ваша статья, даже визуально выглядела бы почти так же, только к ней был бы приложен воспроизводимый результат - github репозиторий, который можно брать и пользовать!
Вы учите писать бумажные письма в век мессенджеров и удивляетесь почему кто-то недоволен. То что вы называете "администрирование" приличные люди называют DevOps, который вполне себе устоялся в плане инструментов и процессов.
Приличные люди никогда не назовут установку лампы девопсом. Сисадмины да, они могут и не такое.
А потом такие DevOps, которые вошли в профессию через Ansible не зная базы, в надежде что плейбук на galaxy рабочий, раскатывают его в проде и все падает, а все потому, что прейбук написал "такой же" DevOps который вкатился пол года назад после инфоциганских курсов. Не все конечно плейбуки кривые, но такие встречаются и не редко. По этому знать и понимать как развернуть это руками - необходимо. ИМХО. Как минимум для того, что бы открыть очереджной плейбук и понять, нормальный ли он или там написана какая-то чушь, которая в лучшем случае не заработает. А то умельцев много, начать плейбук с команд:
apt update && apt upgrade
Никто не мешает написать вот точно такую же статью, только добавить немного кода. Плейбуки кривые не потому что использовать CM с самого начала это плохо, а потому что нет культуры его применения. DevOps шагает по планете с 2011 года, но по прежнему есть те кто превращает его в ремесло "системного администрирования" и вместо кода с хорошими комментариями пишет вот такие статьи.
PS
Количество минусов под моими комментариями наводит на мысль что DevOps будет горячей позицией ещё пару лет))
Если цель статьи обучение, обучайте правильно.
Если нет, весь цикл скорее иллюстрация к статье "Почему у нас на проекте на взлетел DevOps".
Такое дело, для всех этих инструментов уже написано все что нужно. Для лампов, лемпов, и чертами ступе. Велосипедировать смысла нет.
статьи такое дно, что дальше уже некуда падать.
и даже если не хочется связываться с Ansible, Chef, Puppet, SaltStack (не будучи опсом)
то сейчас без докера все равно никуда.
зачем устанавливать кучу хлама напрямую в систему, если можно поднять всё одним docker-compose, благо примеров в инете так же миллион. а заодно научиться пользоваться нормальными реверс проксями типа traefik или jwilder/nginx-proxy
зачем устанавливать это в таком виде (по заверениям автора чтобы научиться основам), если в таком виде никто и нигде не устанавливает. просто вредительство.
самое ужасное что ЭТО кто-то плюсанул.
Я специально ждал этой части, но так и не понял, как РНР подключается к апачу. Я правильно понимаю, что установщик РНР прописывает в httpd.conf LoadModule?
В httpd.conf должно быть:
LoadModule для загрузки модуля, который умеет обрабатывать скипты PHP.
AddType для указания тех расширений файлов, которые этой модуль должен обрабатывать.
DirectoryIndex для указания на то, что в качестве индексной страницы теперь можно использовать не только статическую HTMLку, но и PHP скрипт.
Но у автора вообще это как-то осталось за кадром, да.
Ну меня в первую очередь интересует именно LoadModule. Потому что например в RHEL оно уже 5 лет как объявлено нежелательным в пользу php-fpm. В целом же тут очень смешная ситуация — Aпач служит исключительно в качестве интерпретатора файла .htaccess.
И если делать по уму, при жесткой необходимости поддержки этого файла, то надо ставить только Апач без Нжинкса, но не с mod_php, а с mpm_event/php-fpm, чтобы ПХП не грузился в память при отдаче каждой картинки плюс нормальная многопоточность. Соответственно, производительность на статике будет вполне приемлемой, и Nginx станет не нужен.
Апач без Nginx страдает от архитектуры типа "одно соединение - один воркер". Злоумышленник относительно легко может задосить апач, насыпав ему на вход пачку "медленных запросов" и потом еще медленно скачивая ответный контент (не важно что это за контент - статика или результат работы скрипта). В результате будет быстро израсходован критически важный ресурс - воркеры. Их всегда относительно мало т.к. каждый воркер жрет много памяти - в нем же запускается интерпретатор PHP. Плодить воркеры в неограниченном количестве на сервере нельзя т.к. это будет просто выстрел в ногу из пушки.
Nginx решает эту проблему путем буферизации запросов, буферизации ответов, и удержания keep-alive соединений своими силами с экстремально малыми затратами памяти на каждое такое соединение. То есть резко снижается потребность в воркерах Апача при той же нагрузке на входе.
При использовании связки Nginx + Apache с точки зрения Апача все выглядит так, как будто у него есть один единственный клиент, который достучался до Апача один раз и с тех пор использует очень малое количество keep-alive соединений и очень малое количество воркеров к которым сплошным потоком идут запросы к скриптам. Эти запросы с точки зрения Апач поступают мгновенно и никогда не тормозят. Ответы с точки зрения Апач улетают к клиенту мгновенно и сразу после этого воркер имеет возможность взять следующий запрос. В результате каждый воркер Апач близко к 100% работает только на исполнение какого-либо скрипта.
mpm_event uses a dedicated thread to deal with the kept-alive connections, and hands requests down to child threads only when a request has actually been made (allowing those threads to free back up immediately after the request is completed).
Я не вижу здесь особой разницы.
Если что, меня не надо агитировать за советскую власть, я уверен что конфигурация Nginx+php-fpm удалает mpm_event+php-fpm в любой день недели. Но для целей, заявленных в статье, производительности mod_event должно быть достаточно с избытком.
Забыли "must have" расширение для php - mbstring, его "попросит" любой нормальный проект от Wordpress до Symfony.
-short_open_tag = Off
+short_open_tag = OnВредный совет т.к. противоречит стандарту PSR-1
Хочется сразу отметить, что параметры PHP можно задать в трех местах
Ну большинство значений можно еще и самом php файле изменить с помощью ini_set
Далее приступим к настройке FTP
Боже, ну какой FTP в 2022 году? Это устаревшая практика, но самое важное что протокол не зашифрован, нельзя такому учить начинающих. Вы выше уже настроили SSH, так в чем проблема дать доступ по SFTP или SCP?
return 301 https://DOMAIN_NAME$request_uri;Я бы сделал более универсальным
return 301 https://$host$request_uri;А еще было бы хорошо включить поддежку HTTP2 в nginx и вместо
listen 443 ssl;использовать
listen 443 ssl http2;И тут еще конечно много чего можно и нужно добавить, как минимум настроить TLS ну и как максимум выкинуть к чертям Apache :)
Надо понимать, что это инструкция не для standalone проектов, а для организации копеечного шаред хостинга на коленке. То есть упор на клиентуру qna.habr.com с вопросами типа "у меня в базу данных не добавляеца". Для которой PSR это пустой звук, а надо запустить какой-нибудь вордпресс или битрикс. То же самое касается и всех остальных претензий, типа .htaccess (без которого данная клиентура как без рук) или FTP. В какой-нибудь инструкции из прошлого века для 1С прописано фтп, значит вынь да положь фтп.
Чисто минимизация нагрузки на поддержку. Студенту, на которого эта инструкция рассчитана, надо лабы сдавать, а не отвечать в 100500-й раз на вопрос "почему у миня похапе код не исполняица?".
Стоп, а самое главное-то я забыл.
Как хомячки здесь отделяются друг от друга?
Что мешает пользователю перейти в папочку к соседу?
Очень полезная статья для начинающих, доступное разъяснение каждого пункта. Спасибо, мне очень помогло понять некоторые моменты
Настройка LEMP сервера для простых проектов. Инструкция для самых маленьких. Часть третья