Parus16.ru

Парус №16
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Настройка Nginx и SSL с

Настройка Nginx и SSL с Node.js

Nginx — это высокопроизводительный HTTP-сервер, а также обратный прокси-сервер. В отличие от традиционных серверов, Nginx использует асинхронную архитектуру, управляемую событиями. В результате объем памяти невелик, а производительность высока. Если вы используете веб-приложение на базе Node.js, вам следует серьезно рассмотреть возможность использования Nginx в качестве обратного прокси-сервера. Nginx может быть очень эффективным в обслуживании статических ресурсов. Для всех других запросов он будет обращаться к вашему бэкэнду Node.js и отправлять ответ клиенту. В этом уроке мы обсудим, как настроить Nginx для работы с Node.js. Мы также увидим, как настроить SSL на сервере Nginx.

Установка Nginx

Если на вашем компьютере уже установлен Node.js, давайте посмотрим, как установить Nginx.

Установка на Mac

Если вы работаете на Mac, вы можете использовать Homebrew для простой установки Nginx. Шаги следующие:

  • Для homebrew необходим каталог /usr/local который нужно chown для вашего имени пользователя. Итак, сначала запустите следующую команду в терминале:
  • Теперь следующие две команды установят Nginx в вашей системе.
  • После завершения установки вы можете ввести следующую команду для запуска Nginx:
  • Файл конфигурации Nginx можно найти здесь: /usr/local/etc/nginx/nginx.conf .

Установка на Ubuntu

Если вы используете Ubuntu, вы можете использовать следующую команду для установки Nginx:

После установки Nginx он запустится автоматически.

Установка на Windows

Для Windows зайдите на страницу загрузок Nginx и получите zip. Следующим шагом является разархивирование архива и перемещение в каталог в командной строке следующим образом:

Как видите, команда start nginx запустит Nginx.

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

Настройка сервера Node.js

Сначала давайте создадим простой сервер Node.js. Если вы хотите, вы можете скачать простое приложение на основе Express здесь . Получив код, распакуйте его и перейдите в каталог demoApp на вашем терминале. Затем введите следующие команды, чтобы запустить сервер на порту 3000.

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

Далее мы настроим блок сервера в соответствии с нашими потребностями. Мы хотим обслуживать статические файлы с нашего веб-сайта с помощью Nginx и передавать все остальные запросы в наш сервер Node.js. Итак, замените указанный выше блок server новым блоком, как показано ниже:

Как вы можете видеть, наш сервер Nginx прослушивает http://localhost:8080 . location / блок сообщает Nginx, что делать при поступлении любого запроса. Внутри блока location мы используем proxy_pass чтобы указать на proxy_pass Node.js, которая в нашем случае является http://localhost:3000 .

Теперь нам нужен еще один блок location /public чтобы сообщить Nginx, как обслуживать статические ресурсы. Внутри этого блока location мы устанавливаем корень в /usr/local/var/www . Вы можете выбрать другой каталог, если хотите. В результате всякий раз, когда есть запрос, такой как http://localhost:8080/public/somepath/file.html Nginx будет обслуживать файл из /usr/local/var/www/public/somepath/file.html .

На этом этапе вы должны сохранить файл и набрать следующее, чтобы перезапустить Nginx:

Mac:

Ubuntu:

Окна:

Далее, давайте подадим нашу таблицу стилей из Nginx вместо Node.js. Наш шаблон Node.js использует таблицу стилей с URL /public/stylesheets/style.css . Создайте файл с именем style.css в каталоге /usr/local/var/www/public/stylesheets и Nginx будет правильно его обслуживать. Например, вы можете поместить следующий CSS в style.css :

После этого вы можете перейти на http://localhost:8080 чтобы увидеть наше приложение в действии. Несмотря на то, что вы обращаетесь к серверу Nginx, вы получите фактический ответ от серверной части Node.js, тогда как Nginx будет обслуживать только таблицу стилей.

Настройка SSL

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

Читайте так же:
Гугл карта волгограда с улицами и домами

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

Sysadminium

Разберём, что такое Reverse Proxy. А также я покажу как настроить Nginx в качестве Reverse Proxy (обратного прокси сервера).

Теоретическая часть

Иногда бывает нужно чтобы различные url запросы обрабатывались на разных серверах, но первоначально приходили на один сервер. Например вы пробросили порт на своем роутере на один веб-сервер в вашей внутренней сети. Но хотите чтобы каталог /xxx открывался на втором веб-сервере, а /yyy открывался на третьем, и не хотите пробрасывать порты на каждый web-сервер. Получается вот такая схема:

Reverse Proxy

То что мы хотим сделать из сервера web1, называется reverse proxy (обратный прокси).

В то время как forward proxy (прямой прокси) работают от имени клиентов, то есть нам нужно настраивать браузер (клиент), чтобы тот ходил через прямой прокси сервер. Обратные же прокси работают от имени серверов, то есть клиент не знает, что он обращается на прокси сервер.

Reverse proxy принимает запросы от клиентов для того чтобы проксировать их на проксируемые web-сервера (как показано на рисунке).

В качестве обратного прокси сервера для веб серверов может выступать apace или nginx. Есть и другие решения, но в этой статье разберём настройку nginx. На официальном сайте nginx есть небольшой раздел, посвящённый reverse proxy.

Схема нашей лаборатории

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

У нас будет три сервера:

  • proxy – reverse proxy (ip 192.168.5.82) – установлен nginx;
  • web1 – backend web server (ip 192.168.5.84) – установлен apache2;
  • web2 – backend web server (ip 192.168.5.83) – установлен apache2;

Практическая часть

Настраиваем nginx

Устанавливаем nginx на сервере proxy:

У меня установился nginx такой версией:

Для настройки прокси создадим новый виртуальный хост:

Разбор конфига

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

Следующие опции управляют http заголовками на прокси сервере:

  • proxy_set_header X-Scheme http; – схема по которой подключается клиент (http или https);
  • proxy_set_header X-Forwarded-Proto http; – протокол который использует клиент (http или https);
  • proxy_set_header Host $http_host; – url-адрес по умолчанию, в качестве значения можем указать следующие переменные:
    • $http_host – то что клиент фактически набрал в адресной строке в браузере;
    • $proxy_host – имя и порт проксируемого сервера (web1 или web2), как указано в proxy_pass;
    • $host – имя этого сервера, как указано в server_name (proxy);

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

    • proxy_buffering on; – включаем буфер для прокси сервера;
    • proxy_buffer_size 8k; – размер буфера для первой части ответа получаемого от проксируемого сервера, такая часть ответа включает в себя только заголовки и хранится отдельно от остальной информации;
    • proxy_buffers 8 8k; – число и размер буферов для одного соединения, а вот сюда помещается ответ от проксируемого сервера.

    Теперь разберем часть где мы указываем что проксировать и куда проксировать:

    • /xxx – запрос который будем проксировать;
    • proxy_pass http://192.168.5.84/test/; – куда будем проксировать, то есть на сервер 192.168.5.84 и на каталог /test.
    • Ниже подобный блок для /yyy .

    Отключим конфиг “default“, включим созданный нами конфиг “proxy” и перезагрузим службу сервера:

    Настраиваем backend сервера

    На обоих серверах проделаем одно и тоже! Во-первых установим apache2, затем создадим новый каталог /var/www/html/test. В этом каталоге сделаем индексную страничку index.html в которую запишем имя сервера. Вдобавок поменяем владельца нового каталога на www-data.

    Проделываем следующее на обоих серверах:

    Проверка

    Используя адрес прокси сервера, откроем xxx:

    Используя адрес прокси сервера, откроем yyy:

    Как видим у нас открылись разные странички, которые лежат на разных серверах:

    • web1 лежит на сервере с адресом 192.168.5.84 в каталоге test:
    • web2 лежит на сервере с адресом 192.168.5.83 в каталоге test:

    Резервирование серверов

    Теперь сделаем так, чтобы один и тот же запрос ходил по следующим правилам:

    • /xxx – проксируем на http://172.30.93.84/test/ – если он доступен;
    • а если не доступен, то проксируем на http://172.30.93.83/test/.

    Для этого поправим наш конфиг /etc/nginx/sites-enabled/proxy и перед блоком server добавим блок upstream:

    В этом блоке указываем оба web-сервера. При этом webбудет основным сервером. Но если proxy в течении 120 секунд получит три ошибки при обращении к web1, то на 120 секунд все запросы пойдут на web2.

    Ниже в блоке server, где мы указывали что на что проксировать (блоки location), поменяем записи. Вместо ip-адреса web-сервера укажем название апстрима, которое мы придумали выше (backend). Второй блок (location /yyy) – удаляем. Получится так:

    Полностью конфиг будет выглядеть так:

    Проверка резервирования

    В браузере, используя адрес прокси сервера, открываем /xxx:

    Затем отключаем сервер web1 и обновляем страничку:

    Как видим мы перешли на второй сервер. Теперь включим обратно первый сервер и обновим страничку еще раз:

    Теперь мы вернулись на первый сервер.

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

    Здесь я разобрал многое, но не всё. Например, можно настроить не резервирование, а балансировку. Про неё, кстати, статей в интернете больше чем про резервный сервер. Я постарался использовать многие http заголовки, чтобы показать как их можно изменять при проксировании. Возможно не все заголовки вам будут нужны в реальной конфигурации. Это зависит от web-приложения, которое вы используете. Буфер для прокси сервера тоже нужно настраивать под конкретную задачу. Поэтому просто копировать приведённые выше конфиги не желательно, нужно анализировать свои действия и все перепроверять.

    Веб-сервер Nginx под Linux

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

    1. Установка Nginx под Linux

    Итак, предполагается, что есть только что установленная операционная система Ubuntu 18.04 LTS без графического интерфейса пользователя.

    Перед тем как продолжить, нужно проверить доступные версии программного обеспечения дистрибутива. Выполняем команду:

    В выводе результата команды можно увидеть, что доступны обновления. Рекомендуются их обновить с помощью команды (подсказка «Run ‘apt list –upgradable’»):

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

    Нужно выполнить команду команду:

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

    Далее нужно проверить, что помимо самой установки, веб-сервер запустился и готов обрабатывать запросы (для данной команды использование sudo не обязательно):

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

    2. Выпуск самоподписанного сертификата (необязательно)

    После установки Nginx в операционной системе уже должен быть установлен openssl. Поэтому можно сразу приступить к генерации сертификата.

    Первоначально нужно перейти в директорию хранилища сертификатов с помощью команды:

    После чего требуется ввести команду генерации сертификата, где вместо <SERVER> нужно подставить имя компьютера, на котором планируется размещен Apache:

    Во время выполнения команды будет задано несколько вопросов. Для «Common Name (e.g. server FQDN or Your bane)» нужно также указать имя сервера. Остальные поля заполняются произвольно (кроме «Country name» — здесь можно оставить по умолчанию).

    3. Привязка сертификата и переадресация запросов

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

    Предполагается, что уже есть две базы опубликованные на веб-серверах с Apache и IIS (см. Настройка веб-сервера IIS и 3. Установка Apache под Linux).

    Веб-сервер Apache расположен на компьютере <ИМЯ СЕРВЕРА APACHE>, а веб-сервер IIS расположен на компьютере <ИМЯ СЕРВЕРА IIS>.

    На веб-сервере Apache опубликована информационная база с именем <ИМЯ ПУБЛИКАЦИИ APACHE>, а на веб-сервере IIS опубликована информационная база с именем <ИМЯ ПУБЛИКАЦИИ IIS>.

    С помощью любого удобного редактора нужно отредактировать файл nginx.conf и добавить в секцию http после комментария «# SSL Settings» (предварительно удалив все параметры в этой секции) следующий текст настройки:

    После этого нужно сохранить и перезапустить службу nginx.

    4. Проверка публикации

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

    Перенаправление Apache и Nginx

    Статья давно не обновлялась, поэтому информация могла устареть.

    Содержание

    Apache

    Подключения модуля mod_rewrite

    Для включения перенаправления средствами Apache, достаточно чтобы модуль mod_rewrite.so был загружен в Apache.

    Для того ,чтобы директивы mod_rewrite можно было использовать в .htaccess, надо в конфигурационном файле Apache, в соответствующем разделе «<Directory /путь/до/директории>» прописать:

    После внесения изменений в конфигурационный файл Apache, для вступления в силу этих изменений, нужно перезапустить веб сервер:

    В .htaccess для работы перенаправления нужно указать следующую директиву:

    Правила Redirect

    Эти директивы вы можете прописывать как в конфиге Apache для нужного virtualhost, так в файле .htaccess.

    Redirect или RedirectPermanent

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

    Если нужно сделать несколько редиректов, то каждый новый редирект нужно написать с новой строки.

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

    RedirectMatch

    Этот редирект отличается тем, что в нем можно использовать регулярное выражение. Например, при переносе сайта с Windows на Linux, необходимо сменить все ссылки с *.php на *.aspx:

    RewriteRule

    Для работы данного модуля убедитесь в том, что включена опция FollowSymLinks, эту функцию нужно прописать в конфигурационном файле Apache или в файле .htaccess как указано ниже.

    Рассмотрим самые распространённые варианты её использования.

    Редирект с одного сайта на другой

    Редирект с www на без www

    Или более понятный синтаксис

    Вы можете использовать любой.

    Редирект с без www на www
    Перенаправление домена с https на http

    Для того, чтобы данное перенаправление работало, должен использоваться только Web-сервер Apache. При использовании связки Nginx+Apache будет возникать ошибка циклической переадресации. Поэтому редирект нужно будет настраивать именно в Nginx

    Перенаправление домена с http на https

    Для того, чтобы данное перенаправление работало, должен использоваться только Web-сервер Apache. При использовании связки Nginx+Apache будет возникать ошибка циклической переадресации. Поэтому редирект нужно будет настраивать именно в Nginx

    Nginx

    Модуль ngx_http_rewrite_module, необходимый для настройки перенаправлений, он устанавливается автоматически вместе с Nginx.

    Редирект 301 с www.domain.com на domain.com

    Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена с www, вторая для домена без www:

    Секция server для редиректа:

    Секция server, где находятся основные настройки домена:

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

    Редирект 301 с domain.com на www.domain.com

    Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для домена без www, вторая для домена с www.

    Секция server для редиректа:

    Секция server, где находятся основные настройки домена.

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

    Редирект 301 с https на http

    Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для https(443 порт), вторая для http(80 порт).

    Секция server для открытия по https(443 порт) и настройки редиректа:

    Секция server, для открытия по http(80 порт), где находятся основные настройки домена.

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

    Редирект 301 с http на https

    Для Nginx вам нужно создать две секции server в конфигурационный файл, одна для http(80 порт), вторая для https(443 порт).

    Для нового домена в конф. файле nginx

    Секция server, для открытия по http(80 порт) и настройки перенаправления:

    Секция server, для открытия по https(443 порт), где находятся основные настройки домена.

    Для существующего домена в конф. файле nginx

    Если вы вносите изменения в существующую секцию конф. файла nginx делайте это так: Из основной секции домена удалите строку вида

    И создайте новую секцию server такого вида:

    После внесения изменений в конфигурационный файл Nginx, для вступления в силу этих изменений, нужно его перезапустить так:

    NGINX — создание виртуальных хостов

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

    Виртуальные хосты

    Для начала нужно разобраться, что из себя представляет виртуальный хост. Это адресное пространство веб-сервера. Оно нужно для того, чтобы пользователь мог создавать несколько сайтов на своем сервере. Выглядит это примерно так: предположим у вас есть блог, интернет-магазин, сайт-визитка, корпоративный портал. Вы можете создать разные виртуальные хосты под каждый сайт, например: local.blog, local.shop, local.vizitka, local.korp-portal.

    Установка

    Сначала давайте убедимся, установлен ли у вас nginx и какой он версии. Для этого нужно ввести команду:

    Если у вас nginx установлен, то ответ будет примерно такой:

    nginx version: nginx/1.10.1

    Если же ответа не последовало, то, в таком случае, его придется установить. Делается это с помощью следующей команды:

    опцию «-y» мы используем, чтобы ответить на все вопросы «да», и установка сразу же началась.

    Создание директории

    Теперь нам нужно создать директорию для виртуального хоста. Это, по сути, будет как файловое хранилище для нашего сайта. Воспользуемся командой:

    Обратите внимание на ключ «-p». Это означает следующее: если нет родительской папки, то он ее создает автоматически. Название «mysite.ru» выбрано не случайно. Здесь мы используем реальное доменное имя, и в дальнейшем сможем понимать, где какой сайт находится.

    Создание тестовой страницы

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

    Внутри редактора, чтобы сохранить файл, нажмите комбинацию «ctrl+o» (буква «о» Олег). Чтобы выйти «ctrl+x»

    теперь наполним файл текстом, скопируйте html код:

    Настройка прав

    Скорее всего, после создания папок у вашего сервера не будет доступа на запись в них данных. Очень часто различные CMS или фрэймворки используют системы кэширования и логирования, которые пишут данные в файлы. Если у сервера будут проблемы с правами, то он будет выдавать ошибки, что, согласитесь, не есть хорошо. Чтобы разрешить проблему с правами, нужно поменять пользователя папки, ведь ее мы создавали от пользователя root, а nginx работает от пользователя www-data, чтобы изменить пользователя папки выполним следующую команду:

    Ключ «-R» означает, что мы выполняем команду рекурсивно на все вложенные папки, что в данном случае очень логично. Бывают еще ситуации, когда нужно дать права на чтение (при моем варианте это не пригодилось), но на всякий случай:

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

    Установка php 5.6

    Пройдя все этапы выше, переходим к установке php. Для начала убедимся, что данной версии у нас нет. Переходим в папку по адресу:

    Посмотрите, если видите следующую картину:

    И папка 5.6 не пустая, значит php5.6 версии у вас уже установлена. И устанавливать ее заново уже не нужно. Если же ее нет, то установить можно с помощью следующих команд:

    Подобная установка поставит все необходимые библиотеки для успешной работы php на вашем сервере и избавит вас от дальнейшей головной боли.

    Настройка php-fpm

    FastCGI Process Manager, «Менеджер процессов FastCGI». Это альтернативная реализация FastCGI режима в PHP с несколькими дополнительными возможностями, которые обычно используются для высоконагруженных сайтов. Настройка fpm делается в файле по следующему адресу:

    Чтобы воспользоваться поиском в nano, нужно нажать комбинацию горячих клавиш «ctrl+w»

    Конфигурация виртуального хоста

    И, самое главное — конфигурация виртуального хоста. Здесь важно не накосячить, а, иначе, ничего не заработает. Переходите в директорию, где они находятся:

    Существует несколько вариантов создания виртуальных хостов:

    1. Можно под каждый конфиг создать отдельный файл. Важно только не забыть создать символьную ссылку в папке sites-enabled
    2. Занести все конфиги сайтов в один в файл default, и каждый виртуальных хост хранить в конструкции server <> server <> server <>

    Мне нравится вариант 2. Все изменения делаем в файле default. Зайдя в этот файл, вы вероятнее всего уже увидите закомментированный кусок кода ниже, начинающийся со слова server . Вы можете либо создать новый хост ниже, либо заменить этот текст. Обязательно сделайте все по инструкции и обратите внимание на важные моменты, и я уверен, у вас все получится. Это оффициальная рекомендуемая конфигурация для настройки под фрэймворк yii2 (но я немного изменил под свои нужды), найти оригинал можно тут: https://github.com/nginx-configuration

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

    • server_name — это доменное имя, после ввода которого в адресную строку, пользователь сможет получить информацию из папки root, о ее настройке ниже
    • root — это директория, в которой хранится сайт
    • access_log и error_log — это логирование всех заходов и ошибок на сайте. Мы указываем путь до файлов
    • fastcgi_pass — Задаёт адрес FastCGI-сервера. Адрес может быть указан в виде доменного имени или IP-адреса, порта.

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

    После того, как все заполнено, вам нужно перезагрузить сервер и fpm. Делается с помощью следующих команд:

    Если во время перезагрузки произошли какие-нибудь ошибки, то можно запустить команду проверки nginx:

    В случае успеха должно быть выдано следующее сообщение:

    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful

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

    Настройка файла hosts

    Теперь остался последний момент. Если вы сейчас введете в адресной строке mysite.ru, то, вероятно, получите ошибку. Но, если настроить файл hosts и указать, что по этому домену он должен отправляться на наш сервер, то сайт заработает. Для этого откроем файл:

    В этом файле вы увидите примерно следующее:

    Нам сюда нужно добавить еще одну строчку:

    Обязательно обратите внимание, что между IP адресом и Доменным именем должна быть табуляция , а не пробел

    Теперь можете попробовать зайти на ваш сайт по новому адресному имени http://mysite.ru и получите такую долгожданную фразу — «Ура! Вы смогли настроить Virtual Host в nginx!»

    Секреты в настройке виртуальных хостов

    Есть одна хитрость, которую я очень часто использую при создании сайтов. Чтобы все ваши сайты лежали в домашней директории пользователя, можно создать там папку, например: www. Получится что-то следующее: /home/mylocalComputer/www/mysite.ru

    Чтобы эта папка заработала, нужно создать символьную ссылку на нее:

    Теперь пользователь может управлять сайтами из своей домашней директории.
    Опция «-s» — позволяет нам создать символическую ссылку.

    В общем, что знал — рассказал. Если у вас остались вопросы — задавайте их в комментариях. Спасибо за прочтение. Надеюсь у вас все получилось 🙂

    Облако тегов

    • Mysql
    • Ubuntu
    • Docker-compose
    • Docker
    • Видео
    • PHP
    • Yii3
    • Smm
    • Юзабилити
    • Linux

    Следующая статья

    Отличие MyISAM от InnoDB

    • Базы данных

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

    голоса
    Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector