Развернуть 1с на raspberry pi 4

Обновлено: 07.07.2024

Сегодня мы рассмотрим очень интересный и удобный вариант сборки сервера управления умным домом на базе одноплатного компьютера Raspberry Pi 4B и универсального решения все — в одном Argon ONE M.2 c SSD диском на 128 ГБ. Я специально сказал решение, а не корпус, так как Argon ONE включает в себя несколько плат расширения и систему охлаждения, по сути кроме него и самого одноплатника — больше ничего не нужно, кроме источника питания. Но для удобства, далее в обзоре я буду употреблять термин — корпус.

Содержание

Где купить ?

  • Argon ONE M.2 на Aliexpress — цена на момент публикации $61.69 с SSD M.2 диском на 128 ГБ
  • Raspberry Pi 4 Model B на aliexpress — цена на момент публикации $61.62 на 4 ГБ

Комплект

Комплект рассмотренный в этом видео состоит из трех составляющих — компьютера Raspberry Pi 4B, корпуса Argon ONE M.2, и SSD диска на 128 ГБ Netac. Корпус и диск я купил одним комплектом. Несмотря на то что посылки отправились с разных магазинов и разными почтовыми службами, приехали они с разницей всего в день.


В моем случае была выбрана модель Raspberry Pi 4B с объемом оперативной памяти на 4 ГБ, хотя скажу честно и откровенно — 2 ГБ версии, для развертывания Home Assistant, даже с тяжелыми аддонами — хватает с головой.


Что касается корпуса — то кроме версии Argon ONE M.2 — есть версия и без расширения для SSD диска, его кстати можно докупить отдельно, кроме этого существует музыкальная модель Argon Nano sound и компактный вариант Argon Neo


А это M.2 SSD диск, который можно взять в комплекте с корпусом, одним лотом, мне показалось так удобнее. Всего доступно три варианта комплектации Argon ONE M.2 — без диска, с диском на 128 ГБ который рассмотрен в обзоре и диском на 512 ГБ — для моих целей это слишком много.


Argon ONE M.2

Как я и сказал Argon ONE M.2 это не просто корпус, это целый комплекс, решающий целый ряд задач и превращающий одноплатник в полноценный и готовый к работе ПК. И что мне понравилось — много внимания уделено именно удобству будущей работы с мини компьютером.


Верхняя часть корпуса занимается охлаждением — для чего тут имеется вентилятор, управление которым осуществляется программно. Кроме этого тут имеется джемпер управляющий режимами питания, принимающий ИК диод и порт питания для одноплатника, заменяющий штатный. Соединение с Raspberry Pi 4B организовано через шину GPIO которая кстати остается доступной для использования.


Нижняя часть корпуса — это плата расширения для установки SSD дисков M.2. длиной 30, 42, 60 и 80 мм с ключами B или B + M. Диски NVMe — не поддерживаются.


В комплекте имеется плата расширения, которая выводит разъемы HDMI и 3,5 мм аудио с боковой на заднюю сторону, что гораздо удобнее. Кроме этого, штатные micro HDMI порты, преобразованы в полноразмерные, что дает возможность подключаться к сборке обычным кабелем, без переходников.


Комплект крепежа из 4 коротких и 4 длинных винтов, термопроводящие наклейки, USB-USB соединитель для подключения SSD диска к одноплатнику и антискользящие ножки.


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


Сборка — верхняя часть

Сборка начинается с платы расширения для звукового и видео разъемов. Необходимо совместить разъемы на ней и одноплатнике, после чего аккуратно соединить вместе.


После этого, все разъемы кроме порта питания, буду располагаться с одной, назовем ее задней, стороны. HDMI теперь полноразмерные, к ним можно подключать стандартные видео кабеля.


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


С внутренней стороны верхней платы расширения находится разъем подключения вентилятора, тут видно и разъем продолжающий шину GPIO- через него на одноплатник будет подаваться питание — здесь же находится и USB Type C порт, заменяющий штатный и располагающийся на той же стороне что и все остальные разъемы.


Теперь внимательно совмещаем шину GPIO одноплатника с разъемом платы корпуса и аккуратно соединяем, при этом одноплатник с уже подключенным расширением устанавливается на свое штатное место.


Теперь все разъемы — штатные USB и LAN, а также выведенные платами расширения — HDMI, audio, разъем питания и кнопка включения — находятся на одной стороне корпуса.


Настала очередь коротких винтов комплектного крепежа — согласно инструкции закрепляем в одной, пока, точке плату Raspberry.


Остальные предназначены для платы расширения. Аккуратно, но плотно завинчиваем крепеж, теперь одноплатник, хоть и не полностью, но уже надежно закрепляется в корпусе.



Теперь установим режим питания — их есть два, переключаются они при помощи джемпера на плате крышки корпуса. По умолчанию установлен режим включения с кнопки.


Мне удобнее использовать режим всегда включено, поэтому я переключил джемпер на контакты 2-3. В этом случае одноплатник автоматически включится при подаче питания.


Bootloader

Теперь нужно обновить bootloader одноплатника, для активации режима загрузки с USB. И делать это надо на этом этапе, так как при полной сборке — необходимый для этой процедуры micro SD разъем будет закрыт корпусом. Нам понадобится штатная утилита Raspberry Pi Imager.


Качаем и устанавливаем ее, находим рабочую micro SD карту — можно и небольшого объема, и запускаем прошивальщик.


Нажимаем на кнопку выбора операционной системы и тут ищем раздел разное. В нем находится единственный на момент съемки этого видео раздел bootloader



Если сравнивать с моим уроком 2021 года по установке Home Assistant — то в этом разделе произошли некоторые изменения. Теперь тут несколько вариантов bootloader в зависимости от того, какая загрузка вам нужна. Я выбрал USB Boot. После этого нажимаем на кнопку выбора носителя — тут должна определится подключенная SD карта. Объем записи небольшой, так что размер значения не имеет.



Прошивальщик готов к записи — осталось нажать кнопку write. После этого, программа качает из сети и записывает bootloader на флешку. Процесс довольно быстрый но не мгновенный, известны случаи когда по какой-то причине запись не осуществлялась, соответственно загрузчик не обновлялся.



Записанную карточку устанавливаем в card reader одноплатника.


Подаем питание, на этом этапе ничего больше подключать не надо.


Процесс обновления весьма быстрый, о его успешном завершении свидетельствует быстро мигающий зеленый светодиод. Если он ведет себя как-то по другому, нужно перезаписать либо заменить и записать карту о попробовать снова.


Сборка — нижняя часть

Теперь перейдем к нижней части корпуса — тут находится плата для установки M.2 SSD диска, так что нам понадобится и он.


На плате имеются 4 винтовых крепления для дисков разной длины, сам же крепежный винт уже завинчен в последнем, которое кстати нам и пригодится.


Снимаем винт — он состоит из двух частей, золотистой — подставки и черной — винта крепежа. Сначала ставится золотистая.


Устанавливаем диск — он вставляется в разъем под углом, до упора.


Теперь прижимаем его и закрепляем к плате расширения при помощи того самого крепежного винта.


После этого можно записать на диск образ операционной системы. Удобнее всего использовать для этого USB кабель папа-папа, но в крайнем случае можно обойтись USB удлинителем и комплектным П образным переходником.


Запись образа

Подключаем диск к компьютеру и снова запускаем штатный прошивальщик. Идем в выбор операционных систем — раздел Raspberry Pi OS другие. Тут выбираем Lite версию, без десктопа, он нам не нужен. Напомню что процесс установки Home Assistant Supervised показан в моем уроке.



Вот так определился подключенный к плате расширения диск. В моем случае объем на 128 ГБ. Прошивальщик готов к работе — нажимаем write и ждем завершения процесса.



Он может занять некоторое время, так как образ качается из сети, сама запись — если через USB 3, то довольно быстрый. Образ записан — теперь надо отсоединить диск от компьютера и подключить его снова.



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


Завершение сборки

Завершаем сборку — совмещаем нижнюю часть корпуса с верхней половинкой, в этом случае внутри никаких соединений нет, все снаружи.


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


Используем оставшиеся четыре винта — длинных и свинчиваем обе половинки корпуса вместе.


Тут же нам пригодится комплектная наклейка с резиновыми ножками. Устанавливаем их в отведенные для этого места.


И, наконец, соединяем плату с установленным SSD диском с нижним USB 3,0 портом одноплатника при помощи комплектной перемычки. Напомню, что в этом случае при использовании USB Zigbee стика — обязательно будет нужен USB удлинитель.


Аппаратная часть сервера для управления умным домом полностью собрана и готова к установке и использованию.


Если для каких-то целей вам понадобится доступ к GPIO шине устройства — она находится под съемной крышкой сверху. Крышка держится на магнитах, пользоваться ей легко.


Использование

При работе — на фронтальной части корпуса, видна активность светодиодов через полупрозрачный материал корпуса.


Конфигуратор работы вентилятора ставим командой

Для настройки используется сервис


Вентилятор может быть всегда включен, работать в режиме 25, 50 и 100 % мощности в зависимости и трех установленных значений температуры или настроен кастомно.


Я оставил второй режим, только поднял на 5С второй и третий предел (50 и 100 % мощности вентилятора)


Установка Supervised Home Assistant — описана в моем уроке номер 1.1 Самое начало где показано обновление bootloader и запись образа — можно пропустить, мы это уже сделали, далее — идем по шагам инструкции.

Что касается температурного режима — до включения вентилятора дело не доходит, крышка корпуса отлично с этим справляется, пассивного режима полностью хватает.


Видео версия обзора

Вывод

Лично мне корпус очень понравился — решение все в одном, отличного качества и при этом внешне выглядит очень круто. Если Argon One M.2 — встретился мне год назад, то точно все мои 4ки были бы с ним. Достаточно большая площадь верхней части отлично справляется с охлаждением даже без вентилятора.


Кроме внешнего вида он еще и удобен — все разъемы выведены назад, в использовании это гораздо практичнее штатного подключения сбоку и конечно надо отметить полноразмерные HDMI. Недостатков этого решения — не вижу, даже на первый взгляд высокая цена, если ее разложить по составляющим, окажется более чем умеренной.

Raspberry Pi — в народе она же малинка — хорошо известная среди гиков платформа для экспериментов и прототипирования разной степени умности гаджетов.
Думаю тут вряд-ли имеет смысл вдаваться в подробную историческую справку, просто хочу отметить что я давно питаю любовь к этим одноплатникам — делал на их базе несколько арт-ботов, (один из них до сих пор работает в телеге), делал конвертор лая моей собаки в твиты (и таким образом, листая свою ленту, узнавал, что ей неспокойно, пока я на работе), испытывал сервера на node.js, хостил на нем свой веб-сервер (практически это довольно бессмысленно, но прикольно) и тд

Использовать малинку как эмулятор старых игр — очень распространенная практика — для этого под нее существует аж несколько готовых эмуляционных систем: Retropie, RecalBox или Lakka.

Чтобы их поставить — семи пядей во лбу не нужно — просто записываешь образ любой понравившейся системы на микро SD карту (это «жесткий» диск малинки), закидываешь ромы игр в папку roms, вставляешь это дело в рашпери, подключаешь монитор и любой геймпад — готово.

Конечно, в отличии от готовых решений типа Nintendo mini classic — сами игры в комплект не входят, и тут —

важный дисклеймер: игры, (кроме тех случаев, где их принадлежность к паблик-домену непрозрачно указана) — даже самые древние, которые уже не купить в магазине легально, все еще принадлежат своим правообладателям!
*Поэтому ищем на свой страх и риск, исключительно в ознакомительных целях. Гугл справляется с этим на отлично, есть большие тематические форумы и сайты.

От себя, я бы сказал, что в случае, если вы обладатель купленной копии игры, использовать ее образ в эмуляторе кажется наиболее морально и этически приемлемым, однако юридически — это может нарушать лицензионные соглашения. Тем не менее не думаю, что боевые спецназовцы из Atari срочно сделают машину времени и придут ловить вас с поличным :)

Цена вопроса такой самоделки может быть даже выше, чем готовые решения для ретро-гейминга от той же нинтендо, учитывая, что для рашпери понадобится блок питания не меньше 2.5A для RPi3 и не меньше 3A для четвертой малинки, сама SD карта минимум на 16 gb, (не менее 10 класса и желательно быстрая) геймпады и тд. Все это в комплект не входит (разве что вы покупаете готовый бандл в магазине)

Зато есть полная гибкость — вы не привязаны к одной платформе (SNES в случае с nintendo classic mini). На третьей малинке вполне легко без дополнительного охлада можно поиграть в игры для первой плойки — тот же Tekken3, Final Fantasy 7, Silent Hill — будет вполне бюджетно, а четвертая малинка с небольшим оверклокингом и охладом без проблем запускает хиты для Dreamcast — Сrazy Taxi, Sonic Adventures 2, Shenmue

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

Ближе к делу

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

Вот такой 4-х дюймовый 7(!)-цветный e-paper экран — я обожаю «бумажные» дисплеи в читалках, есть в этой технологии какая-то аналогово-цифровая магия, а тут он еще и цветной. Конечно это сугубо не для видео и не для гейминга, там полное обновление изображения занимает секунд 15 (кстати в процессе довольно классно переливается и моргает), но я давно хотел с этим что-нибудь придумать, например сделать игру, где частота кадров 4 кадра в минуту — не баг, а фича. В общем, брал скорее на будущее, с намерением что-то классное с этим потом сделать


Модуль автономного питания c аккумуляторами, который крепится пинами прям к задней панели малинки, не занимая гребенку пинов GPIO. Впоследствии он оказался скорее бесполезным — вернее, это отличная штука для нетребовательных задач, но с ретропаем или запущенной в графическом режиме OS он недодает по вольтажу — в дримкаст с таким точно не поиграешь.

Возможно это можно пофиксить, или поискать другие аккумы — не спец по электронике, но на всякий случай написал в техподдержку waveshare — вообще говоря довольно странно, что предупреждение о недо-вольтаже возникает даже при штатном использовании с третьей малинкой.

UPD: проблему недо-вольтажа можно решить дополнительно запитав малинку через ее штатный usb c порт — подключить шнур USB одним концом к USB порту модуля автономного питания, а type-c в обычный вход для питания малинки. ВАЖНО: нельзя совмещать одновременно автономное питание и обычное питание от розетки, (сам блок с батарейками при этом может быть подключен к розетке, но либо все через батарейки, либо без них обычным штатным питаловом.

Девайсы пришли на почту, захотелось протестировать их в действии, и тут я вспомнил, что в шкафу у меня завалялась целая куча использованных проездных на метро. Так как по сути в них обычная NFC метка, была идея использовать их для проекта с RFID сканером в качестве ключа или триггера


Недолго думая, я решил попробовать собрать портативную консоль, которая запускала бы любимые игры по «единому», читая команду с метки через сканер RFID. Для рашпери есть вот такая «шляпа»:

шляпа или hat — платы расширения для Raspberry Pi, которые крепятся к ней через GPIO по принципу бутерброда

шляпа или hat — платы расширения для Raspberry Pi, которые крепятся к ней через GPIO по принципу бутерброда

Удобно, что на плате есть удлинитель GPIO пинов, стало быть прикрепив модуль к малинке первым слоем, сверху к этому бутерброду можно добавить и «бумажный» экран и использовать его например для показа артов / обложки запущенной игры и для (неспешного) мониторинга системы — заряд батареи, температура процессора и тд.

Ингредиенты

Rasberry PI 4 / 4gb была в запасах не задействованная 3-я, но уж очень хотелось в Dreamcast :) Брал сразу набором на амперке, чтобы не искать по отдельности все нужные шнуры (microHDMI — HDMI) и блок питания (четверка к ним особо привередлива), плюс там в наборе уже есть микро sd c RaspberryPi OS на 16 гигов. Мне не потребовалась, использовал свою с большим объемом, но лишней точно не будет :) Весь комплект на амперке 10500р — на алике аналогичный возможно обойдется дешевле, но мне не терпелось

Развертывание приложения, зависящего от платформы

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

Убедитесь, что на устройстве Raspberry Pi включен протокол SSH. При необходимости см. инструкции по включению SSH в документации по Raspberry Pi.

При этом устанавливается последняя версия. Если вам нужна определенная версия, замените параметр --channel Current на --version <VERSION> , где <VERSION> — это версия конкретной сборки.

Чтобы упростить разрешение пути, добавьте переменную среды DOTNET_ROOT и добавьте каталог .dotnet к $PATH с помощью следующих команд:

Убедитесь, что отображаемая версия соответствует установленной версии.

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

С помощью клиента SFTP, например scp , скопируйте файлы из расположения публикации на компьютере разработчика в новую папку на устройстве Raspberry Pi.

Например, чтобы использовать команду scp для копирования файлов с компьютера разработчика на устройство Raspberry Pi, откройте командную строку и выполните следующую команду:

  • Параметр -r предписывает scp рекурсивно копировать файлы.
  • /publish-location/ — это папка, опубликованная на предыдущем шаге.
  • pi@raspberypi — имя пользователя и узла в формате <username>@<hostname> .
  • /home/pi/deployment-location/ — это новая папка на Raspberry Pi.

Последние версии Windows поставляются с OpenSSH, включая scp .

Запустите приложение из командной строки Bash на Raspberry Pi (локальном или SSH). Для этого задайте папку развертывания в качестве текущего каталога и выполните следующую команду (где HelloWorld.dll является точкой входа приложения):

Развертывание автономного приложения

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

Убедитесь, что на устройстве Raspberry Pi включен протокол SSH. При необходимости см. инструкции по включению SSH в документации по Raspberry Pi.

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

Разверните приложение в локальную папку, если используется Visual Studio. Перед публикацией выберите Изменить в сводке профиля публикации и перейдите на вкладку Параметры. Убедитесь, что для Режима развертывания задано значение Автономный, а Целевая среда выполнения — linux-arm.

С помощью клиента SFTP, например scp , скопируйте файлы из расположения публикации на компьютере разработчика в новую папку на устройстве Raspberry Pi.

Например, чтобы использовать команду scp для копирования файлов с компьютера разработчика на устройство Raspberry Pi, откройте командную строку и выполните следующую команду:

  • Параметр -r предписывает scp рекурсивно копировать файлы.
  • /publish-location/ — это папка, опубликованная на предыдущем шаге.
  • pi@raspberypi — имя пользователя и узла в формате <username>@<hostname> .
  • /home/pi/deployment-location/ — это новая папка на Raspberry Pi.

Последние версии Windows поставляются с OpenSSH, включая scp .

Запустите приложение из командной строки Bash на Raspberry Pi (локальном или SSH). Для этого задайте в качестве текущего каталога расположение развертывания и выполните следующие действия:

Предоставьте исполняемому файлу разрешение execute (где HelloWorld — имя исполняемого файла).

Еще один блог ;-) программиста-любителя о PHP, кросс-платформенной среде разработки Qt, интернете и прочем, что будет заслуживать внимание.

вторник, 26 октября 2021 г.

И снова здравствуйте!

Тот, кто уже не первый раз работает с Linux системой, может предположить, что мы будем устанавливать популярный в веб-разработке HTTP-сервер Apache, но это не так. Принимая во внимание ограниченные аппаратные ресурсы Raspberry Pi Zero W, нашей задачей является использование программного обеспечения, потребляющего как можно меньше этих самых "ресурсов". И из всего доступного многообразия HTTP-серверов, самыми производительными и "легковесными" можно считать два их них - Lighttpd и nginx. У каждого из них есть и свои "плюсы" и свои "минусы" и, пожалуй, сложно отдать предпочтение какому-то одному из них - ибо каждый из них хорош по-своему. Что использовать на "боевом" сервере решает уже администратор, исходя из специфики размещаемого веб-контента и ожидаемой модели обращения к серверу.

Сегодня же мы будем устанавливать и настраивать HTTP-сервер nginx. Почему? Просто потому, что данный HTTP-сервер с каждым годом набирает все большую популярность во всех сегментах веб-серверов от "домашних" до высоконагруженных промышленных и знакомство с ним будет определенно не лишним ;-).

Итак, для начала нам необходимо обновить мета-данные репозитория и обновить все установленные на нашей Raspberry Pi пакеты (как устанавливать подключение к девайсу по протоколу SSH было описано ранее). Для этого подключаемся к "малинке", авторизуемся и вводим последовательно две команды:


После установки nginx и всех зависимых пакетов, systemd штатно должен запустить процесс nginx в работу. Проверить его состояние Вы можете командой:

В терминале Вы должны увидеть подобную картину:


Осталось проверить непосредственно в браузере. Для этого в любом веб-браузере в адресной строке наберите: http://IP_адрес_RaspberryPi. Где IP_адрес_RaspberryPi, соответственно, IP адрес, который ваша "малинка" получила в вашей wi-fi сети. Например, в моем случае это - 192.168.1.71:


Если Вы увидели подобную тестовую страницу, значит на данный момент Вы все сделали правильно, и мы можем приступать к конфигурированию сервера nginx.

Следует сразу оговориться, что далее будет представлен вариант с настройкой HTTP-сервера nginx с двумя виртуальными серверами: один на стандартном порту 80, а другой на порту 8080. Делается это с одной целью - получить один виртуальный сервер исключительно как "девелоперский", на порту 8080, доступ к которому будет открыт только из внутренней сети, а другой виртуальный сервер - своеобразный "продакшн" сервер, на порту 80, доступ к которому можно открыть и из внешней сети. Это для случая, если Вы решите из своей Raspberry Pi Zero W сделать полноценный веб-сервер, на котором будет хостится ваш проект или домашняя страничка. Если в Ваши задачи входит только организация тестового веб-сервера, можете смело отбрасывать те настройки, которые будут относится ко второму виртуальному серверу (на порту 8080).

2 способ: базируется на основной логике дифференциации сервером всех имеющихся у него "виртуальных серверов" - непосредственно по их доменным именам. Для этого нам необходимо будет придумать некое доменное имя, которые мы будем использовать в качестве адреса нашего "виртуального сервера", и принудительно прописать его в локальной службе DNS, которую используют компьютеры нашей локальной сети. Что, непонятно звучит? :-)))). То ли еще будет. :-D. Это можно сделать также несколькими способами: можно прописать в службе DNS на роутере (если он поддерживает данный функционал), можно прописать на сервере DNS основного сервера (если, вдруг, у вас целая сеть, которая управляется, например, MS Server), а можно указать в локальном файле hosts (в ОС MS Windows он располагается по адресу: Windows\System32\drivers\etc\hosts, в ОС Linux: /etc/hosts).

Какой способ использовать - решает каждый сам за себя. Для меня проще и быстрее разнести "виртуальные сервера" по разным портам. При данном подходе необходимо все настройки сделать лишь на компьютере, который выступает сервером, и совершенно не важно с какого устройства, в последствии, будет происходить подключение к этому серверу. Главное - знать, на каком порту у нас "висит" требуемый "виртуальный серверок" :-))).

Создадим в каталоге /var/www/ два подкаталога: server80 - для первого виртуального сервера, и server8080 - для второго. Для этого используем команду mkdir с привилегиями суперпользователя, т.к. по умолчанию в директории /var/www/ у всех остальных пользователей доступ только на "чтение":

В итоге директория /var/www/ будет содержать следующие поддиректории:


Для проверки корректного конфигурирования nginx, создадим в каждой из вновь созданных директорий по простенькому файлу index.html, примерно следующего содержания:

Для директории /var/www/server80/

Для директории /var/www/server8080/

Создать данные файлы Вы вправе любым удобным способом (не забываем про необходимость использования привилегий суперпользователя), главное, чтобы они назывались index.html. Например, я создавал следующим образом. Сначала командой touch создал непосредственно файл index.html:

А затем, используя редактор nano, наполнил его содержимым:


Соответственно, аналогичные действия необходимо проделать для создания файла index.html в директории /var/www/server8080/.


Осталось самое интересное - сконфигурировать nginx для работы с двумя виртуальными серверами. И вот тут, мой дорогой читатель, я хотел бы сразу тебя предупредить, что ниже будут указаны самые базовые настройки, которые позволяют фактически "поднять" в работу два виртуальных сервера на базе nginx. И данный вариант конфигурации не закрывает все вопросы безопасности использования такого web-сервера. Nginx обладает очень гибкими настройками, и как любой подобный инструмент, обладает кучей своих нюансов и "специфичных фич", которые нужно знать, чтобы не попасть в просак. В последствии, я еще вернусь к вопросам безопасности его работы, но это будет не в этой заметке.

Как и большинство программ в ОС Linux, сервер nginx хранит все свои конфигурационные файлы в директории /etc. А если уж совсем точнее, то в /etc/nginx. Все основные настройки собраны в самом главном конфигурационном файле - nginx.conf. Пока мы этот файл оставим без внимания - базовые настройки полностью удовлетворяют поставленной задаче.

В рамках данной заметки, нас интересует две поддиректории: sites-available и sites-enabled. Как можно понять из названий указанных директорий, в sites-available размещаются конфигурационные файлы всех возможных (допустимых) хостов (виртуальных серверов). А вот в директории sites-enabled помещаются символические ссылки на конфигурационные файлы из sites-available, которые считаются "активными". Т.е. те виртуальные серверы, которые nginx должен считать рабочими и обращения к которым он должен обрабатывать.


После установки сервера nginx в директории sites-available Вы найдете один единственный конфигурационный файл - default. Символическая ссылка на этот файл помещена, соответственно, в директорию sites-enabled. Наша задача, как Вы уже могли догадаться, это создать два новых конфигурационных файла в директории sites-available (по одному для каждого виртуального сервера) и разместить символические ссылки на них в директории sites-enabled.

Но самое первое, что нам необходимо сделать, это удалить символическую ссылку из sites-enabled на конфигурационный файл default. Для этого перейдем в терминале в директорию /etc/nginx/sites-enabled и выполним команду:

И не забываем, что все работы на файловом уровне в данной директории должны вестись с правами суперпользователя.

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

В нашем конкретном случае, например, совершенно идентичными будут параметры, относящиеся к указанию страницы каталога по умолчанию (т.н. "индексная" страница). Так что давайте и вынесем эту конфигурацию в отдельный файл, а потом уже подключим его в файле конфигурации конкретного виртуального сервера.

Создавать такие общие файлы конфигурации Вы можете где угодно, главное исключить возможность доступа к ним посторонних лиц (в т.ч. "извне"). Опять же, хорошей практикой является помещение их в директории common, что будет сразу указывать, что тут располагаются общие файлы конфигурации, которые используются в нескольких местах. Поэтому, перейдем в терминале в каталог /etc/nginx и выполним следующую команду с привилегиями суперпользователя:

Можно теперь создавать общие файлы конфигурации непосредственно в директории common, а можно немного пойти дальше и создать в ней поддиректорию, соответствующую контексту, для которого создается общий файл конфигурации. В нашем случае мы будем создать общий файл конфигурации для контекста location, который определяет "маршрутизацию", если так можно выразиться, на сервере. Поэтому перейдем в каталог /etc/nginx/common и создадим в нем поддиректорию locations следующей командой:

У Вас должно получиться нечто подобное:


Перейдем в созданную директорию locations и создадим файл конфигурации common.inc, в котором опишем настройки индексных страниц для наших виртуальных серверов. Проделаем манипуляции, аналогично проделанным нами ранее при создании файлов index.html. Сначала создадим сам файл командой touch:

А затем, используя редактор nano, внесем необходимые параметры в файл common.inc:

Непосредственно в качестве содержимого файла необходимо внести следующий текст:


Данные опции определяют (опция index) в качестве индексных файлов корневого каталога два вида файла: index.html и index.htm. А так же устанавливают (опция try_files), что nginx должен проверить существование запрашиваемого файла или каталога и, в случае неуспеха, вернуть ошибку "404" (страница не найдена).

Не забываем сохранить внесенные изменения в файл common.inc и переходим в директорию /etc/nginx/sites-available.

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

Первым создадим конфигурационный файл для виртуального сервера, который будет располагаться на стандартном 80-м порту. Уже знакомой нам командой touch сначала создадим файл server80:

А затем, используя редактор nano, внесем требуемые параметры:


Полагаю, тут комментарии излишни.

Теперь создадим конфигурационный файл для второго виртуального сервера, который будет располагаться на порту 8080. Аналогично только что проделанной работе, командой touch создадим файл server8080:

И снова воспользуемся редактором nano, чтобы внести необходимые параметры создаваемого виртуального сервера:

Наблюдательный читатель мог заметить, что помимо измененного номера порта, который будет слушать nginx, и главной (root) директории виртуального сервера, в конфигурации появились еще две строчки:

Чтож, мы создали два конфигурационных файла для двух разных виртуальных серверов. Осталось дело за малым: создать символические ссылки на эти файлы в директории sites-enabled (см. выше) и дать команду nginx перечитать конфигурацию.

Перейдем в директорию sites-enabled:

и последовательно введем команды:

Для верности убедимся, что все прошло успешно и наши ссылки на месте, введем команду ls:

В окне терминала Вы должны увидеть список из двух файлов, как на скриншоте ниже:


Ну, а теперь, момент истины - даем команду nginx перечитать конфигурационные файлы:


И, конечно же, самое ожидаемое - проверка работоспособности. Наберите сначала в браузере просто IP-адрес вашей "малинки" (в моем случае это - 192.168.1.71). Вы должны увидеть нечто подобное:


Если вашему взору предстала аналогичная картина - поздравляю, Вы все сделали правильно :))).

А на сегодня это все. В следующий раз мы добавим нашему веб-серверу "динамичности" - "прикрутим" к нему движок PHP, что позволит создавать динамические сайты, либо сразу установить полноценную CMS.

Читайте также: