Кілька веб-сайтів на nginx, один IP


14

Тому я використовую цифровий океан та nginx. Я хочу розмістити кілька веб-сайтів (мої проекти), але не хочу купувати домен для кожного.

Чи існує спосіб розміщення декількох веб-сайтів у nginx та цифровому океані під час доступу до них за допомогою одного ip?


Розмістити їх у різних папках ( X.Y.Z.W/foo, X.Y.Z.W/bar)? Чому ви не можете отримати домени для них? (Ви можете призначити один і той же IP для кількох доменів)?
muru

Для цього вам знадобиться кілька доменів. Однак є безкоштовна послуга домену: freenom.com надає безкоштовні домени .tk, .ml, .ga, .cf та .gq.
The Wanderer

@muru Я думаю, що вони не хочуть витрачати гроші на кілька доменів. Вони хочуть певним чином мати кілька веб-сайтів на одній URL-адресі.
The Wanderer

@ Zacharee1 їм потрібен лише один домен, і вони можуть робити субдомени. Якщо вони відмовляться робити це, їм доведеться робити злий метод на основі IP, який залежно від типу програми / проекту, який вони використовують, не зможе підтримати методи розташування «підпапки».
Томас Уорд

@ThomasW. Я думав, що піддомени не будуть можливими
TheWanderer

Відповіді:


17

Є два способи досягти цього. Або ви робите все за IP-адресою, з розташуванням підпапок, або вам потрібно буде придбати один домен, а потім мати кілька субдоменів у цьому домені (субдомени не повинні коштувати нічого, якщо ви купуєте домен, але зверніться до свого реєстратора).

Я не раджу метод IP-адреси хоча б тому, що дуже зле запам’ятовувати IP-адреси, а якщо ви намагаєтеся обмінюватися інформацією з іншими, ви також маєте ту ж проблему, що й інші повинні пам’ятати IP-адресу.


Підхід в один IP, багато підпапок, без доменного імені

ПОВІДОМЛЕННЯ! Ми не маємо інформації про ваші проекти, над якими ви працюєте. Нам потрібно знати більше, щоб визначити, чи можна робити такий підхід, оскільки безліч веб-рамок не працюватиме без прив’язаного до нього справжнього доменного імені.


ПОПЕРЕДЖЕННЯ . Під час постійного тестування цих прикладів було виявлено, що підхід "Один домен, багато підкаталогів" не приймає доброзичливого зворотного наближення даних до бекенда, оскільки запитуваний URI буде включати підкаталоги в URI; це може призвести до того, що сервери бекенда можуть мати проблеми з нормальним поводженням.

З іншого nginxбоку, нам потрібно зробити "злий" підхід до цього - одна IP-адреса, безліч локацій і підпапок. Це дуже злий підхід і може викликати багато проблем у деяких веб-рамках.

Припускаючи встановлення за замовчуванням nginxяк базу репозиторіїв, тоді ми повинні створити конфігурацію сайту для обробки запиту кожного підкаталогу проекту. Тоді ми повинні позначити його в потрібному місці.

Створіть /etc/nginx/sites-available/my-projectsнаступне (використовуйте це як шаблон / посібник - це передбачає три проекти зі статичним HTML та відсутністю динамічних веб-додатків у PHP чи python чи подібних, і ви можете скопіювати окремі блоки місцеположення та створити нові місця відповідно; це також передбачає IP сервера 1.2.3.4).

server {
    listen 80 default_server;

    server_name 1.2.3.4;

    location / {
        return 410;  # Default root of site won't exist.
    }

    location /proj1/ {
        alias /var/www/proj1;
        try_files $uri $uri/ =404;

        # any additional configuration for non-static content
    }

    location /proj2/ {
        alias /var/www/proj2;
        try_files $uri $uri/ =404;

        # any additional configuration for non-static content
    }

    location /proj3/ {
        alias /var/www/proj3;
        try_files $uri $uri/ =404;

        # any additional configuration for non-static content
    }
}

Тепер ми замінюємо конфігурацію за замовчуванням (видаляємо її) і додаємо нашу:

sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/my-projects /etc/nginx/sites-enabled

А потім перезапустіть nginxслужбу:

# If on 14.04, use this:
sudo service nginx restart

# If on 15.10 or newer, use this:
sudo systemctl restart nginx

Однодоменний, кілька піддоменних підходів.

Цей розділ відповідей передбачає, що у вас є один домен і кілька субдоменів. Якщо у вас цього немає, уточнюйте це у своєму запитанні

З кожним nginx server {}блоком у конфігурації вам потрібно буде визначити ім’я сервера та, ймовірно, встановити четвертий блок сервера як "спіймати всіх" для інших запитів.

Приклад: У мене є три проекти, proj1, proj2, proj3. У мене є домен під назвою evil-projects.net(ПРИМІТКА: Не існує насправді). Я хочу три різних субдомена, по одному для кожної nginxконфігурації, який вказуватиме на один проект кожен. Мій сервер розміщений на 1.2.3.4, і він буде обслуговувати всі сайти.

З наведеним вище сценарієм у нас є дві частини: домени та піддомени та конфігурація сервера.

(1): Конфігурація DNS

Налаштуйте DNS на своєму хості таким чином, щоб у DNS-записах було вказано наступне:

evil-projects.net  IN A  1.2.3.4
proj1.evil-projects.net  IN A  1.2.3.4
proj2.evil-projects.net  IN A  1.2.3.4
proj3.evil-projects.net  IN A  1.2.3.4

(2): конфігурація NGINX на сервері (1.2.3.4)

Тепер для вашої nginxконфігурації. Я припускаю, що у вас будуть налаштування nginx за замовчуванням та пакети із сховищ (я буду використовувати 14.04 як базовий приклад). /etc/nginx/sites-availableСпочатку у нас будуть введені чотири файли конфігурації . Можливо, вам доведеться використовувати їх sudoпід час створення цих файлів, оскільки саме ця папка належить root.

/etc/nginx/sites-available/catch-all- це буде "ловити все" для будь-яких недійсних доменів. Мені подобається повертати http-код помилки 410 (GONE).

server {
    listen 80 default_server;

    server_name _;

    return 410;
}

Далі ми встановлюємо конфігурацію для ваших сайтів / проектів. Хоча я припускаю, що вони всі статичні файли. Кожен із них означає, що у вас є різні веб-каталоги для кожного проекту на сервері (різні "коріння документів").

/etc/nginx/sites-available/proj1.evil-projects.net:

server {
    listen 80;

    server_name proj1.evil-projects.net;

    root /var/www/proj1;
    index index.htm index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

/etc/nginx/sites-available/proj2.evil-projects.net:

server {
    listen 80;

    server_name proj2.evil-projects.net;

    root /var/www/proj2;
    index index.htm index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

/etc/nginx/sites-available/proj3.evil-projects.net:

server {
    listen 80;

    server_name proj3.evil-projects.net;

    root /var/www/proj3;
    index index.htm index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Потім нам потрібно видалити конфігурацію "за замовчуванням" /etc/nginx/sites-enabledі додати власну. Знову ж, sudoтут потрібно.

sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/proj1.evil-projects.net /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/proj2.evil-projects.net /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/proj3.evil-projects.net /etc/nginx/sites-enabled/

А потім перезапускаємо nginxпроцес:

# If on 14.04, use this:
sudo service nginx restart

# If on 15.04 or newer, use this:
sudo systemctl restart nginx

Після поширення DNS сайти працюватимуть як слід.


у цій конфігурації де ви б розмістили блоки для proxy_cache? Припустимо, proj1, proj2, proj3 мають всі однакові кінцеві точки, з різними коренями, і хочуть кешувати відповідь у різних папках.
користувач305883

@ user305883 Здається, це нове запитання.
Thomas Ward

Підхід до однієї ІР, багатьох підпапок - це саме те, що я хочу зробити. Однак я не можу змусити це працювати. Я точно скопіював код і змінив ім’я_сервера для своєї IP-адреси. У мене також є 3 основні файли index.html у адресах / var / www / proj1 та / var / www / proj2 та / var / www / proj3, де дозволи встановлено на 755. Але коли я переходжу до myip / proj1, я бачу та сама сторінка 410, як ніби я передаю no / proj1. Що відбувається не так? Настає 2020 рік, і я використовую Nginx 1.10.3 - змінився синтаксис?
SLater01

@ SLater01 синтаксис залишається тим самим, але для цього вам потрібно задати власне запитання, оскільки це відповідь є цілком окремим і потребує набагато більше часу / зусиль / деталей, ніж коментарі можуть надати. Однак, ймовірно, вам потрібно прочитати гарне велике жовте поле в цьому розділі, яке вказує на те, що більшість веб-сайтів / служб не так поводяться, тому не сподобається, що їх обслуговують з підкаталогу, а не кореневого домену.
Thomas Ward
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.