Как стать автором
Обновить

Комментарии 19

От экспертов в DevOps и Kubernetes ожидаешь как минимум инструкцию как настроить это всё в docker-compose.
Если речь про тестовую площадку, то там нужен какой-нить mailhog, а не полноценный почтовый сервер.
А вообще, берете битриксовую виртуалку и не паритесь, там уже всё есть и настроено.

У нас есть статьи по настройке этих же решений в Docker. Целью серии статей является указать на особенности в настройке серверов, которыми пользуемся мы, тот же git autocommit. А также указать новичкам, которые хотят постигать администрирование, на какие особенности стоит обратить внимание в начале.

Я не совсем понимаю придирки касаемо exim, который в этом случае работает в режиме smarthost.

Касаемо же готового решения от Битрикс, то все минусы его я приводил в своей предыдущей статье. Безопасность, система логирования, внесение настроек и troublshooting решения от Биттрикс приносит боль и страдания многим администраторам. А приводить ее к удобному виду выйдет сильно дольше чем настроить сервер с нуля по общим стандартам администрования.

Да и как вы говорите проще нужно было описать как стэк выглядел бы в docker, но для новичков, я считаю, это не будет так актуально. Все же перед тем как поднимать данное ПО в Docker, нужно иметь большой опыт в поднятии этого же стека на хосте.

"Не смотря на то, что тема уже достаточно подробно отражена в сети, мы решили подробно описать общие стандарты администрирования с нуля,..."

--- без обид, но статья получилась нагромождённой и плохочитабельной. Блоки кода можно было спрятать под спойлер (или разворачивающийся блок.

В мире докеров и автоматизации, да и к тому же "... часто появляется потребность в настройке серверов... " - ключевое слово "ЧАСТО", было бы неплохо описать конфигурацию c помощью ansible и как вы подключаете конфигурационные файлы. Новичкам это было бы оочень полезно.

И обернуть в докеры или предоставить альтернативную реализацию в данной статье с docker-compose файлами.

У нас есть свои ansible роли для разворачивания стандартного стэка ПО, в зависмости от ТЗ клиента. Повторюсь, что цель серии статей не в том, что бы дать людям готовое решение, а описать именно ручное разворачивание вплоть до базовых команд. Мы посчитали это необходимым так как очень часто видим типичные ошибки у начинающих администраторов, которые приводят в том числе к простоям в работе проектов. Это, например, банальное не тестирование конфигураций перед их применением или внесение прав в sudo без использования visudo, что вобще может привести к потере рут доступа к серверу.

В данной статье я бы хотел вперую очередь предостеречь будущих администраторов от таких вещей и объяснить философию нашей компании - всегда проверяй все свои шаги по несколько раз.

Да, возможно в плане текста пулучилось достаточно сумбурно, здесь извиняюсь перед читателями, в следующих частях, которые будут выпущены на следующей неделе, я проведу модерацию текста.

Касаемо docker, я ответил выше, но повторюсь, перед тем как поднимать что то в docker, нужно понимать как работает ПО на хосте. Какие файлы и в какой момент используются. Docker все же стоит выше по уровню квалификации, и если вы сейчас начинаете заниматься контейнеризацией вашего стэка, вы можете пройти мимо этой статьи.

понял вашу мысль.
И дополню своё высказывание тем, что порой нужно насильно подтолкнуть новичков на путь автоматизации или хотя бы посоветовать им о документировании проделанных самостоятельно шагов, ибо все знания со временем улетучиваются и это время краткосрочно.

Буква 'E' в аббревиатуре LEMP - это сокращение от слова epache, видимо.

Прочитайте текст статьи внимательнее.

у вас хорошая статья, но если после аббревиатуры сразу пишут расшифровку - то обычно пишут именно действующую расшифровку

С "Е" нормально, а вот - "со стОком LEMP" уже не очень.

Я поправил, спасибо.

Люди! Прекратите использовать FTP при наличии в системе SSH.

Вот да. Это один из WTF?!-ов, которые возникают при прочтении этой статьи.
Автор просто так и не смог определиться, для кого она написана.
И шарашит по своим инструкциям для организации шаред хостинга. Потому что к шаред хостингу в обязательном порядке прилагается фэтэпэ, потому что… просто потому что тут так заведено. Ну и плюс они используют фтп для чрутования юзверей.
При том что обозначенному в преамбуле "начинающему администратору своего сервера" этот самый фтп нафиг не сдался. В итоге и в статье место потрачено, и толком ничего не объяснено, поскольку по-хорошему тут надо отдельную статью писать, а не просто конфиг кинуть.


Точно так же непонятно, нафига здесь Апач.
Ну то есть опять же, на шаред хостинге, которым будет пользоваться типичный похапешник, без апача нельзя, поскольку без файла .htaccess эта социальная группа как без рук. Но на собственном сервере это совершенно лишний анахронизм.


В целом, это такая инструкция для студентов, решивших организовать хостинг-провайдера на коленке.

И шарашит по своим инструкциям для организации шаред хостинга. Потому что к шаред хостингу в обязательном порядке прилагается фэтэпэ, потому что… просто потому что тут так заведено. Ну и плюс они используют фтп для чрутования юзверей.При том что обозначенному в преамбуле "начинающему администратору своего сервера" этот самый фтп нафиг не сдался. В итоге и в статье место потрачено, и толком ничего не объяснено, поскольку по-хорошему тут надо отдельную статью писать, а не просто конфиг кинуть.

Настрока ПО по инструкции из данных статей прекрасно будет работать для CMS по типу Bitrix, в связи с чем вам так или иначе придется предоставить разработчикам доступ к файлам площадки. Для этих целей здесь и используется FTP. В третьей статье будет описано как предоаствить такой доступ, и там естественно будет chroot для FTP пользователя площадки.

Да, вы можете использовать SFTP для этих целей, однако вам придется позаботится о том, чтобы чрут каталог пренадлежал пользователю root. Что будет абсолютно неудобно при наличии нескольких площадок на сервере. Как показывает наша практика, разработчики на проектах подобного плана прекрасно использую FTP до сих пор.

Точно так же непонятно, нафига здесь Апач.Ну то есть опять же, на шаред хостинге, которым будет пользоваться типичный похапешник, без апача нельзя, поскольку без файла .htaccess эта социальная группа как без рук. Но на собственном сервере это совершенно лишний анахронизм.

В этом то и суть, что я описываю разворачивание стэка, который потом будет будет передан разработчикам, для размещения площадки. Администрирование же останется на плечах администратора. То есть разработке придется заливать файлы и настраивать редиректы. А как показывает практика настроить это в .htaccess файле для разработки быстрее, чем просить администратора вынести то же в Nginx. Для этих целей здесь используется Apache2.

Люди! Прекратите использовать FTP при наличии в системе SSH.

Здесь мы говорим о тех доступах, которые просят клиенты такого уровня проектов. FTP до сих пор актуален, и это не моя прихоть описывать его настройку в статье. Если бы мы регулярно не сталкивались с просьбами предоставить доступ по FTP от разработчиков, я бы не описывал этот момент в текущей статье.

Спасибо за полезную и подробную статью, с удовольствем буду ждать новых частей.

Спасибо за потраченное на чтение время, надеюсь информация изложенная в статье будет вам полезна!

Спасибо, жду продолжения, особенно про настройку nginx.

Рад получить положительную обртаную связь!

Во второй частье статьи я постарался описать базовую настройку Nginx, в третьей части будет описано создание виртуальных хостов веб-сервера.

Пожалуйста искользуйте & в коммнадах типа apt-get update && apt-get install... иначе при падении первой команды (просто ошибка сети) вы себе таких пакетов с зависмиостями наставите...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий