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

Для объединения нескольких компьютеров в одну локальную сеть можно использовать хабы и свитчи. - от английского «hub» (центр деятельности) - сетевой концентратор, через который к сети подключается несколько компьютеров посредством витой пары. Сходил в магазин за клещами для обжима. Все удовольствие 300 рублей. Провода в витой паре принято обжимать по таким цветам:

Бело-оранжевый,
- оранжевый,
- бело-зеленый,
- синий,
- бело-синий,
- зеленый,
- бело-коричневый,
- коричневый.

Можно с 3-го по 6-й цвета местами и не менять, но тогда нужно с двух сторон обжать обязательно одинаково. Просто когда придет именно мастер с телефонной станции, то он обожмет правильно, и обычно только с одной стороны. Так что делайте лучше сразу по стандарту.

Еще одно наблюдение: на картинке концы проводов зачищены. Так вот этого делать не надо, просто обрезаете ровно, вставляете в RJ-45 и все работает.

Но вернемся к сетям.

На рисунке ниже - схема с 6-портовым сетевым концентратором (Hub), к которому подключены три компьютера.

Когда какой-либо из компьютеров в сети с хабом пытается «пообщаться» с другим компьютером, он посылает сетевому концентратору определенный сигнал с данными, именуемый пакетом. Возьмем в качестве примера представленную выше схему с тремя компьютерами, пусть это будут ПК1 и ПК3. Хаб, в свою очередь, размножает пакет от ПК1, передавая его всем остальным компьютерам локальной сети, т.е. ПК2 и ПК3. Когда сигнал доходит до ПК3, которому он был предназначен, тот посылает ответ сетевому концентратору. Этот ответ хаб опять же транслирует всем компьютерам сети, пока пакет от ПК3 не дойдет до компьютера-отправителя, т.е. ПК 1.

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

Свитч - от английского «switch» (переключатель) - сетевой коммутатор. Как и хаб, свитч предназначен для объединения множества компьютеров в одну локальную сеть. Схема ниже ничем не отличается от предыдущей, за исключением того, что вместо хаба компьютеры подключены уже к сетевому коммутатору.

Хотя на первый взгляд может показаться, что свитч очень похож на сетевой концентратор, он принципиально отличается от своего предшественника способом передачи данных между компьютерами. Получив пакет от одного компьютера, сетевой коммутатор не передает его без разбору всем остальным ПК в сети, а направляет по адресу - именно тому компьютеру, с которым необходимо установить контакт. Например, когда ПК1 отправляет пакет ПК3, свитч передает его именно этому компьютеру, не нервируя лишними данными ПК2. Ответ от ПК3 свитч также транслирует исключительно отправителю, т.е. ПК1.

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

Роутер - от английского «router» - маршрутизатор, который умеет передавать данные между различными сетями, например сетью вашего интернет провайдера и вашей домашней локальной сетью. Маршрутизатор также имеет разъемы для подключения к нему посредством кабеля других устройств, например компьютеров, модемов или сетевого коммутатора. Как вы, наверное, уже догадались, эти разъемы именуются портами.

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

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

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

Подключение к интернету: роутер, свитч и домашние компьютеры

Подключение к интернету: роутер и домашние компьютеры

Поскольку количество компьютеров дома обычно невелико, то можно обойтись без сетевого коммутатора. Благо, большинство роутеров позволяют одновременно подключить 4, а то и 8 компьютеров к интернету. Чем больше портов у роутера, тем он дороже. Маршрутизатор может иметь дополнительные функции, например межсетевого экрана, настройки шифрования трафика в беспроводных сетях и т.п.

В компьютерных магазинах вы можете найти ADSL-роутеры, Wi-Fi роутеры и множество других моделей. ADSL-роутер подходит для подключения нескольких компьютеров к глобальной сети.

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

Выпускаются и ADSL роутеры с поддержкой беспроводных сетей. Это означает, что кабель от телефонной розетки подключается к маршрутизатору, а он уже «раздает» интернет вашим домашним компьютерам посредством технологии Wi-Fi.

Общее подключение к интернету через роутер имеет ряд неоспоримых преимуществ:

  • Нет необходимости дополнительно настраивать компьютеры и программы.
  • Нет необходимости постоянно держать включенным главный компьютер, через который другие ПК сети получают интернет.
  • Роутер потребляет меньше электроэнергии по сравнению с обычным ПК и его труднее взломать при грамотной настройке.
  • В случае с Wi-Fi роутером вы сможете работать в интернете с любого места вашей квартиры и наконец-таки избавитесь от кучи проводов.
Подводя итоги, определимся, какое же оборудование следует приобретать для домашних сетей. Если вы просто хотите объединить несколько компьютеров в одну локальную сеть, вам понадобится сетевой коммутатор (свитч). Если вы хотите подключить все домашние компьютеры к интернету, то задумайтесь о приобретении роутера, имеющего несколько портов для подключения к ним ваших ПК. При этом свитч будет уже не нужен. Если же у вас компьютеры с беспроводными адаптерами или ноутбуки со встроенной поддержкой Wi-Fi, ваш выбор - Wi-Fi маршрутизатор.

В этой статье мы поговорим о том, как работает коммутатор сети ethernet (switch) или мост. Это базовые знания, которыми должен обладать каждый сетевой инженер. Сетевой коммутатор локальной вычислительной сети является центральным элементом инфраструктуры. Понимание его работы является неотъемлемым навыком любого сетевого инженера.

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

Сетевой коммутатор (ethernet switch) - это устройство 2 уровня модели OSI, которое используется в качестве концентратора (центральной точки) для подключения других проводных устройств, работающих по технологии ethernet.

Как происходит подключение устройств?

На приведенном ниже рисунке объясняется, как устройства показано подключаются в единую сеть с общей шиной Ethernet и обмениваются друг с другом данными через коммутатор (switch) либо концентратор (hub). Устаревший на сегодняшний день тип устройств с общей шиной из-за снижения пропускной способности пропорционально количеству подключенных устройств.

Насколько дорого использовать коммутаторы в сети?

Своим появлением в 1989 году коммутатор сети ethernet switch обязан компании Kalpana (работала в Кремниевой долине в 1980 и 1990 годах и была поглощена компанией Cisco в 1994 году). Он назывался Kalpana EtherSwitch EPS-1500 и имел на борту 7 портов.

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

Надежность сети при использовании коммутатора (ethernet switch)

Является вы использование коммутатора локальной вычислительной сети в качестве центрального звена сети надежным решением? Если вы сравниваете коммутируемый Ethernet с коаксиальным Ethernet, коммутатор определенно более надежен. До того, как коммутатор был изобретен, компьютеры были подключены в цепь. В конце которой подключался концевик (terminator) для поглощения сигнала. Иначе множественная пересылка сигнала сводила полезный трафик в сети к нулю.

В чем отличие Коммутатора (Switch) от Концентратора (Hub)

Концентратор (Hub) - это сетевое устройство, позволяющее подключать несколько компьютеров к одной сети. Концентраторы могут быть основаны на соединениях Ethernet, Firewire или USB.

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

Концентратор (Hub) Коммутатор (Switch)
Уровень OSI Физический: концентраторы классифицируются как устройства 1 уровня в соответствии с моделью OSI. Канальный: сетевые коммутаторы работают на 2 уровне модели OSI.
Функционал Для соединения сети персональных компьютеров их можно объединить через центральный концентратор. Позволяет объединять несколько устройств, управлять портами и настройками безопасности VLAN
Форма передачи данных Электрический сигнал или биты Кадр (для L2 Switch) и Пакет (для L3 switch)
Порты 4/12 портов Коммутатор является многопортовым мостом. 24/48 портов
Тип передачи Концентраторы всегда рассылают кадры на все порты (flooding), кроме того, с которого пришел; рассылка может быть одноадресной (unicast), многоадресной (multicast) или широковещательной (broadcast) Первоначально широковещательная (broadcast) рассылка; затем одноадресная (unicast) и многоадресная (multicast) рассылка по мере необходимости.
Тип устройства Пассивное устройство (без программного обеспечения) Активное устройство (с программным обеспечением)
Used in (LAN, MAN, WAN) LAN LAN
Таблица сетевых адресов (MAC) Сетевой концентратор не может узнавать или сохранять MAC-адрес. Коммутаторы используют CAM-таблицу с доступной памятью, к которой обычно обращается ASIC (специализированные интегрированные микросхемы).
Режим передачи Полудуплекс (Half duplex) Полу-/полный дуплекс (Half/Full duplex)
Широковещательный домен Концентратор имеет один широковещательный домен. Коммутатор имеет один широковещательный домен [если не реализован VLAN]
Определение Электронное устройство, которое соединяет множество сетевых устройств вместе, чтобы устройства могли обмениваться данными Сетевой коммутатор - это компьютерное сетевое устройство, которое используется для соединения множества устройств в компьютерной сети. Коммутатор считается более продвинутым, чем концентратор, потому что он будет отправлять сообщения на нужный порт устройства или запрашивать информацию с него.
Скорость 10Mbps 10/100 Mbps, 1 Gbps
Адрес, используемый для передачи данных Использует MAC-адрес Использует MAC-адрес
Необходимо для подключения к Интернету? Нет Нет
Категория устройства Не интеллектуальное устройство Интеллектуальное устройство
Производители Sun Systems, Oracle, Cisco Cisco, D-link, Juniper, MikroTik
Столкновения (Collisions) Столкновения (Collisions) обычное явления в инфраструктурах, использующих концентраторы. В полнодуплексном коммутаторе не происходит столкновений.
Spanning-Tree Не используется Spanning-Tree Возможно использование множества экземпляров Spanning-Tree

Различия в производительности концентраторов и коммутаторов

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

  • таких как многопользовательские игры
  • обмен тяжелыми музыкальными файлами.

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

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

В следующем видео сравниваются концентраторы, коммутаторы и маршрутизаторы.

Почему коммутируемый Ethernet более надежный и эффективный?

При возникновении проблемы в coaxial-ethernet (10base2) трудно определить где ошибка. Инженеру-связисту необходимо проверить все разъемы один за другим, что требует времени. Также необходимо учесть, что из-за хрупкости коаксиального кабеля сеть часто выходит из строя.

Коаксиальный ethernet использует 2 кабеля (внутренний и внешний) для передачи и приема данных в сеть. При полудуплексной связи, компьютер не может одновременно данные принимать и отправлять. Когда сеть загружена возникают множественные коллизии при попытки одновременно вести передачу данных двумя и более станциями. Что почти гарантированно снижает скорость передачи данных в разы, нередко десятки и сотни раз..

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

Что касается производительности, механизм внутри коммутатора может обеспечить полнодуплексную связь (full duplex). Поскольку вероятность возникновения коллизий в сети при правильной настройке оборудования практически сведена к нулю, то данный факт повышает производительность всей системы.

Как работает коммутатор локальной сети Ethernet?

Коммутатор локальной сети анализирует заголовок 2 уровня входящего кадра. Каждый ethernet кадр содержит 2 адреса: MAC-адрес источника и MAC-адрес назначения.

Коммутатор вместе с кадром получает MAC-адрес источника и записывает в свою таблицу коммутации напротив номера порта. Эта таблица - волшебный секрет того, как коммутатор обеспечивает полдуплексную связь.

Затем в таблице коммутации ищется MAC-адрес получателя, и принимается решение о пересылке кадров на определенный порт. Благодаря данному механизму другие сетевые устройства докальной сети не знают о кадрах соседей. Таким образом мы добиваемся работы в полнодуплексном режиме (full duplex).

Процесс пересылки кадра между компьютерами:

  1. Получение коммутатором на 1 порту сообщения от компьютера А с адресом назначения bbbb.bbbb.bbbb
  2. Проверка таблицы коммутации с целью найти порт, к которому подключен адресат с mac-адресом bbbb.bbbb.bbbb
  3. Такой адрес не обнаружен, рассылка запроса на все порты, кроме того, с которого пришло первоначальное сообщение
  4. Ответ от компьютера В компьютеру с адресом aaaa.aaaa.aaaa, так как mac-адрес сетевой карты компьютера В совпадает с заголовком кадра
  5. Заполнение коммутатором свой таблицы ответом от компьютера В
  6. Пересылка ответа от компьютера В компьютеру А

Анимация ниже более наглядно описывает процесс обмена данными между участниками сети:

Вопрос: что произойдет, когда MAC-адрес назначения отсутствует в таблице коммутации свитча, в какой порт следует пересылать он пересылает?

Ответ: в этом случае коммутатор пересылает кадр во все порты кроме, того с которого получил первоначальное сообщение; ожидая, что станция ответит на сообщение, и коммутатор обновит свою коммутационную таблицу.

Nginx? Назначение, особенности, варианты настроек - это вещи, с которыми должен быть ознакомлен каждый веб-разработчик, чтобы тестировать свои наработки.

О nginx замолвим слово

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

Запуск, перезагрузка и логи

Для этого необходимо заставить работать исполняемый файл. Настройка nginx-сервера возможна, только когда он запущен. Управление осуществляется благодаря вызову исполняемого файла с параметром -s. Для этого используйте такую запись:

nginx -s сигнал

В данном случае подставлять можно такие команды (должны поступать от пользователя, что запустил инструмент):

  1. Stop. Используется для быстрого завершения работы.
  2. Reload. Команда необходима, чтобы перезагрузить конфигурационный файл. Дело в том, что любые изменения не будут применены, пока файл работает. И чтобы они вступили в силу, необходима перезагрузка. Как только будет получен этот сигнал, главный процесс начнёт проверять правильность синтаксической составляющей конфигурационного файла и попробует применить имеющиеся там указания. В случае неудачи он откатит изменения и будет работать со старыми параметрами. Если всё произошло успешно, то будут запущены новые рабочие процессы, а старым будет отправлено требование завершиться.
  3. Quit. Применяется для плавного завершения работы. Применяется, если необходимо подождать, пока закончат обслуживаться текущие запросы.
  4. Reopen. Закрыть и открыть лог-файлы.

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

Настройка процессов может осуществляться также с помощью средств Unix (в качестве примера будет рассмотрена утилита kill). Обычно они используют механизм отправки процессу сигнала напрямую с данными. Увязываются они с помощью ID. Эти данные хранятся в файле nginx.pid. Допустим, что нас интересует процесс №134. Тогда для плавного завершения нам необходимо отправить следующую информацию:

kill -s QUIT 1628

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

ps -ax | grep nginx

То есть, как видите, при использовании дополнительного инструментария указывается, что идёт именно его применение. А теперь давайте сконцентрируемся на том, как совершается nginx-настройка.

Структура конфигурационного файла

Установка и настройка nginx предусматривает работу с модулями. Они настраиваются с помощью директив, которые указываются в конфигурационном файле. Они бывают простыми и блочными. Первый тип директив состоит из имени и параметров, которые разделяются с помощью пробелов, а их конец указывается точкой с запятой - (;). Блочная имеет похожее строение. Но в данной директиве вместо окончания размещается набор дополнительных инструкций, которые размещают в фигурных скобах ({ указания }). Если в них можно разместить имена и параметры других процессов, то называются такие конструкции уже контекстом. В качестве примера можно привести http, location и server.

Раздача статического содержимого

Это одна их самых важных задач, которая стоит перед конфигурацией nginx. Под раздачей статистического содержимого подразумевают изображения и HTML-страницы (не динамические). Допустим, что нам нужна разовая работа по настройке nix nginx кластера. Сложно ли это сделать? Нет, и давайте рассмотрим пример. Прежде чем приступать к нему, необходимо детализировать условия задачи. Так, зависимо от запросов, файлы будут идти из разных локальных каталогов. Так, в /data/www мы имеем HTML-документы. А в каталоге /data/images содержатся изображения. Оптимальная настройка nginx в данном случае требует редактирования конфигурационного файла, в котором необходимо настроить блок server внутри http. Для поддержки будет использоваться также два location.

Реализация: server

Итак, для начала нам необходимо создать сами каталоги и разместить в них файлы с необходимыми расширениями (в html необходимо добавить содержимое). Затем открываем конфигурационный файл. В нём по умолчанию уже есть несколько блоков server, которые в массе своей закомментированы. Чтобы добиться оптимального результата, этот процесс необходимо проделать по отношению ко всем составляющим по умолчанию. Затем добавляем новый блок server с помощью такого кода:

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

Реализация: location

Определяется внутри server:

Наличие знака «/» необходимо, чтобы сравнивать получаемые данные и смотреть, есть ли такой адрес из обработанного запроса здесь. Если никаких проблем нет, то указываем путь /data/www к необходимому файлу, что находится в данной локальной системе. Если совпадение есть с несколькими блоками, то выбирается тот, у которого самый длинный префикс. В приведённом примере его длина равняется единице, то есть использование будет исключительно в том случае, если нет «конкурентов». Теперь давайте его усовершенствуем:

location /images/ {

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

location /images/ {

Это рабочий вариант, который случает стандартный Этот сервер без проблем может быть доступный на локальном компьютере, если пройти по адресу: http://localhost/. Как же это всё будет работать?

Принцип функционирования примера

Итак, когда придут запросы, что начинаются с с /images, то сервером файлы из соответствующего каталога будут отправляться пользователю. При его отсутствии будет передана информация, указывающая на ошибку 404. Если проводится настройка nginx на локальном компьютере, то при запросе http://localhost/images/example.png нами будет получен файл, месторасположение которого /data/images/example.png. При указании одного символа «/» поиск будет проводиться в директории /data/www. Но мы только изменили конфигурацию. Чтобы она начала работать, её необходимо перезагрузить. Для этого используйте команду nginx -s reload. В случае когда нормальная работа не является возможной, то в файлах error.log и access.log, расположенных в директиве /usr/local/nginx/logs, вы сможете поискать причину неисправностей.

Создание простого прокси-сервера

Можно сказать относительно nginx - настройка данного объекта является одним из частых применений (и довольно легким, между прочим). Здесь используется принцип сервера, который принимает запрос, а потом осуществляет перенаправление их к необходимым сайтам. После этого ожидается ответ от них, который направляет их к тому, кто поставил задачу. Поэтому давайте рассмотрим пример создания базовой точки. Она будет заниматься обслуживанием запросов пользователей и предоставлять им изображения из локального каталога. Итак, к блоку http добавляем ещё один server с таким содержимым:

А теперь давайте для вас расшифрую: создаётся простой сервер. Он будет прослушивать Не указать listen, то сервер будет работать на 80-м. Отображаться будут все запросы в рамках локальной файловой системы, которые направлены на каталог /data/up1 (конечно, его перед этим необходимо будет создать). Для возможности проверки там необходимо поместить файл index.html. Благодаря размещению директивы root в контексте server мы сможем воспользоваться location при любых условиях (поскольку, таким образом, снимаются ограничения доступа). Теперь работаем над созданием прокси-сервера. Для его работы нам понадобится директива proxy_pass, для которой будут указаны протокол, имя, а также порт объекта как параметры (при локальном подключении это будет выглядеть как http://localhost:8080). Получится такой результат:

proxy_pass http://localhost:8080;

location /images/ {

Если вы рассматриваете код и анализируете его, то можете заметить, что второй блок location был изменён. Так, в данном случае он может работать с типичными расширениями изображений. Немного по-другому его можно было бы отобразить таким образом:

location ~ \.(gif|jpg|png)$ {

root /data/images;

Итоговая конфигурация прокси-сервера выглядит следующим образом:

proxy_pass http://localhost:8080/;

location ~ \.(gif|jpg|png)$ {

root /data/images;

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

  • Администрирование доменных имен ,
  • Настройка Linux ,
  • Серверное администрирование ,
  • Системное администрирование
  • Здравствуй, уважаемый пользователь Хабрахабра. Мое повествование будет о том, как подготовить почву для локальной веб-разработки проектов в операционной системе Ubuntu 16.04.1 LTS.

    В данной статье хочется развеять и разъяснить возможные трудности связанные с установкой и настройкой ПО, которое требуется для современной веб-разработки, с которыми возможно сталкиваются начинающие разработчики и не только.

    Технологии которые будут использованы в статье: nginx, php-fpm.

    Перед началом повествования, хочу отметить, что я проделывал все эти действия на «голой» системе.
    Я буду работать с пакетным менеджером aptitude. Так же рекомендую обновить индекс пакетов и сами пакеты перед установкой ПО. В статье мы проделаем эти действия вместе.

    Поехали!

    Установка пакетного менеджера aptitude , обновление индекса и пакетов

    Устанавливаем:

    Sudo apt install aptitude
    Обновляем индекс.

    Sudo aptitude update
    Обновляем пакеты (команда обновит все пакеты, для которых есть новые версии, если потребуется удаление пакетов, то оно будет выполнено).

    Sudo aptitude full-upgrade

    Установка и настройка nginx (версия >= 1.10.0)

    Устанавливаем.

    Sudo aptitude install nginx
    Запускаем.

    Sudo service nginx start
    Проверяем версию, чтобы убедиться что не установили старую, то есть ниже 1.10.0.

    Установку и запуск произвели, теперь пойдем в каталог туда куда установлен наш nginx и посмотрим на его структуру. Каталог nginx находится по такому пути:

    Cd /etc/nginx/
    Посмотреть содержимое директории можно командой ls, с флагами -la будет удобнее просматривать содержимое каталога (в действительности эту команду с конкретными флагами можно описать детальнее и вернее, но у нас сегодня другая тема).

    Ls -la
    Наc интересуют в данный момент два каталога, которые вы видите на скриншоте. Это каталоги sites-available и sites-enabled.

    Давайте перейдем в каталог sites-available и начнем конфигурировать наш виртуальный хост (сайт).

    Cd /etc/nginx/sites-available
    Перед началом создания конфигурационного файла, проверим что лежит у нас в данном каталоге. В моей случае каталог не пустой, в нем уже есть конфигурационные файлы, я их затер, чтобы не вводить вас в заблуждение.

    Важное отступление

    В случае установки nginx «с нуля», именно «с нуля», так как при удалении nginx командой
    sudo apt-get remove nginx или sudo apt remove nginx конфигурационные файлы остаются и если вы вдруг будете не понимать, почему nginx не работает и захотите его переустановить (обычно к такому прибегают начинающие пользователи Linux), то и после переустановки он не будет корректно работать, из-за того что в старых конфигурационных файлах (они не удаляются после удаления командой remove) прописаны неверные настройки, их придется удалить, либо настроить верно, только тогда nginx заработает.

    Рекомендую удалять командой sudo apt-get purge nginx или sudo apt purge nginx . Если вы используете пакетный менеджер aptitude, то команда sudo aptitude purge nginx удаляет пакет полностью со всеми зависимостями и конфигурационными файлами.


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

    Ls -la

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

    Sudo touch project.local
    Посмотрим что получилось.

    Теперь откроем его в редакторе, я открою его в nano.

    Sudo nano project.local
    Видим что он у нас пустой. Теперь перейдем к формированию нашего файла. Нужно привести конфигурацию к такому виду, как написано ниже. Я опишу только жизненно важные директивы этого файла, описывать остальное не буду, так как это не является на данный момент важным, все-таки у нас тема базовой настройки. Этих настроек с «горкой» хватит для разработки проектов локально, не только мелких, но и довольно крупных. В следующих статьях опишу отдельно каждые использованные директивы (именно так называются строки, например server_name) этого файла.

    Смотрите комментарии прям в конфигурационном файле.

    Server { listen 80; # порт, прослушивающий nginx server_name project.local; # доменное имя, относящиеся к текущему виртуальному хосту root /home/stavanger/code/project.local; # каталог в котором лежит проект, путь к точке входа index index.php; # add_header Access-Control-Allow-Origin *; # serve static files directly location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ { access_log off; expires max; log_not_found off; } location / { # add_header Access-Control-Allow-Origin *; try_files $uri $uri/ /index.php?$query_string; } location ~* \.php$ { try_files $uri = 404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; # подключаем сокет php-fpm fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.ht { deny all; } }
    Сохраняем файл. Теперь нам надо проверить, нет ли в нем ошибок. Сделать мы это можем командой.

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

    Теперь нам надо активировать конфигурационный файл, в каталоге /etc/nginx/sites-enabled/ необходимо создать симлинк (символическая ссылка). Если у вас nginx был установлен «с нуля», то в этом каталоге есть симлинк на файл default, про который рассказывалось выше, его можно удалить, если он вам не требуется. Переходим в нужный каталог.

    Cd /etc/nginx/sites-enabled/
    Теперь мы в нужном каталоге. Давайте создадим наш симлинк. Для создания используется команда ln с флагом -s, далее мы укажем путь до нашего конфига project.local.

    Sudo ln -s /etc/nginx/sites-available/project.local
    Посмотрим на наш созданный симлинк.

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

    Файл hosts

    Этот файл находится по пути /etc/hosts. Наличие в нем записей, позволяет запускать nginx с использованием в качестве домена localhost. В этом файле можно присваивать альтернативные псевдонимы, например для нашего проекта project.local, мы присвоим домен project.local.

    Открываем файл в редакторе nano.

    Sudo nano /etc/hosts
    У вас в этом файле будет и другая информация, просто игнорируйте ее. Вам всего лишь нужно добавить строку как на моем скриншоте.

    Установка php-fpm (>=7.0)

    sudo aptitude install php-fpm
    Проверяем установленную версию, на всякий случай, хотя в Ubuntu 16.04.1 в репозиториях лежит именно 7.0 версия.

    Php-fpm7.0 -v

    Убеждаемся что все ок. Стартуем php-fpm.

    Sudo service php7.0-fpm start
    Если будете править конфиги, то не забывайте рестартовать демон. Это делает так. Но нам это не потребуется.

    Sudo service php7.0-fpm restart
    На этом установка и настройка php-fpm закончена. Правда, это все. Это не магия, путь до сокета php-fpm у нас уже был прописан в конфигурационном файле. Конечно, вам могут понадобиться какие-либо расширения php для разработки личных проектов, но их вы можете поставить по мере того как они будут требоваться.

    Теперь пойдем для в каталог с нашим проектом, у меня он лежит по такому пути.

    Cd /home/stavanger/code/project.local
    Поднимемся на каталог выше и сделаем права 777 (то есть мы будем делать полные права каталогу с нашим проектом project.local). В будущем это избавим нас от лишних проблем.

    Cd .. sudo chmod -R 777 project.local
    На этом настройка ПО завершена, давайте создадим тестовый файл в нашем рабочем каталоге project.local и убедимся что все работает. Я создам файл index.php с таким содержанием.

    Идем в браузер и видим что у нас все прекрасно работает! Интерпретатор php в том числе.

    С уважением к читателям, Stavanger.