40i.net
← Усі статті

Як розмістити кілька проєктів на одному сервері через піддомени

DNS, віртуальні хости Apache, локальні порти та HTTPS. Практичний розбір схеми 40i.net зі статичними сайтами й застосунками на Rails.

Піддомен задає адресу, але не ізолює застосунок. DNS спрямовує ім’я на IP; Apache вибирає сайт за ім’ям хоста; віртуальний хост віддає файли або передає запит локальному процесу. На 40i.net кореневий домен віддає статичну вікі з /var/www/40i-wiki, site-builder.40i.net проксує до Rails на 127.0.0.1:3000, а інші піддомени мають власні каталоги або сервери застосунків.

Як запит потрапляє до потрібного проєкту?

Маршрут має чотири рішення: DNS зіставляє ім’я з IP; TLS вибирає сертифікат; Apache обирає віртуальний хост за іменем; хост віддає файли або проксує запит на локальний порт. DNS не запускає застосунок і не видає сертифікат, а Apache не підтримує застосунок запущеним. Під час збою перевіряйте ці рівні окремо.

Шлях запиту через один сервер
Браузер
  │  https://app.example.com
  ▼
DNS A / wildcard ──► SERVER_IP
  │
  ▼
Apache :443 ── TLS-сертифікат + віртуальний хост за Host
  ├── DocumentRoot ──► файли сайту
  └── ProxyPass ─────► 127.0.0.1:3001 (процес застосунку)

Які DNS-записи потрібні піддоменам?

Створіть для кожного імені проєкту запис A на публічну IPv4-адресу сервера. Wildcard-запис *.example.com може спрямувати туди інші піддомени; кореневому домену потрібен окремий запис. Конкретніші DNS-записи мають пріоритет. Wildcard полегшує резолв імен, але не створює сайти. Зберігайте поштові записи MX, SPF, DKIM і DMARC, змінюючи DNS вебсайту.

Чому залишаємо Apache, а не переходимо на nginx?

Це рішення про вебсервер, який уже обслуговує проєкти, а не твердження, що Apache завжди кращий. На сервері 40i.net встановлено й запущено Apache 2.4; nginx не встановлений. ISPConfig керує файлами віртуальних хостів Apache та маршрутом ACME-перевірок, а сайти, журнали й поновлення сертифікатів уже залежать від цієї конфігурації. ISPConfig підтримує обидва вебсервери, тож сама панель не визначає вибір. Для цього сервера Apache дає змогу не переносити згенеровані віртуальні хости й TLS-процедури та не додавати ще один рівень проксі — за поточного навантаження це майже не дасть користі. nginx пасує новому серверу або виміряній потребі; перехід потребує плану для сайтів, власника портів 80/443, поновлення сертифікатів і відкату.

Як пов’язані ISPConfig і вебсервер
Панель ISPConfig
  └── створює й керує віртуальними хостами та маршрутом ACME
       │
       ▼
Apache 2.4 (активний на 40i.net)
  ├── статичні сайти
  └── зворотний проксі ──► застосунок на 127.0.0.1:PORT

nginx: на цьому сервері не встановлений

Як Apache вибирає віртуальний хост?

Apache порівнює HTTP-заголовок Host із ServerName та ServerAlias серед хостів на потрібному порту. Укажіть для кожного хоста явний ServerName; додавайте ServerAlias лише для додаткових імен того самого проєкту. Широкий шаблон *.example.com може перехопити піддомен іншого застосунку. Якщо ім’я не збіглося, Apache відповідає першим підходящим хостом. Налаштуйте для невідомих імен передбачувану відповідь.

Коли Apache може віддавати статичні файли?

Для статичного сайту задайте окремий DocumentRoot та DirectoryIndex; процес застосунку не потрібен. Так працюють експортовані HTML-сторінки. Коренева вікі 40i.net використовує саме цю схему; окремі статичні сторінки є також у Transcriber і Profile Analyzer. Тримайте опубліковані файли окремо й надавайте Apache читання, але не секретів розгортання чи Git-репозиторію. Віртуальний хост розділяє маршрути, права Unix обмежують доступ до файлів.

Як проксувати вебзастосунок?

Запускайте застосунок на окремому локальному порту, а публічні HTTP та HTTPS доручіть Apache. Застосунок має слухати 127.0.0.1, щоб клієнти не обходили TLS і маршрутизацію доменів. Зберігайте вихідні Host та схему запиту для правильних URL і cookies. Site Builder проксується до Rails на порту 3000. Інші проєкти мають окремі статичні каталоги чи локальні backend-сервіси. Для WebSocket, наприклад Rails Action Cable, потрібне окреме правило перед загальним HTTP-проксі.

Віртуальний хост застосунку з локальним backend
<VirtualHost *:443>
    ServerName app.example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/app.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/app.example.com/privkey.pem

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"
    ProxyPass / http://127.0.0.1:3001/
    ProxyPassReverse / http://127.0.0.1:3001/
</VirtualHost>

Як systemd керує застосунками?

Створіть окрему службу systemd для кожного тривалого вебпроцесу та фонового завдання. Задайте Unix-користувача, робочий каталог, файл оточення та політику перезапуску. Секрети тримайте поза Git і публічним каталогом. У розгортанні Rails вебпроцес і фонові завдання працюють в окремих службах. Після зміни unit-файла виконайте systemctl daemon-reload та перезапустіть службу. Змінивши оточення застосунку, теж його перезапустіть. Перевіряйте журнал служби до діагностики Apache.

Як застосунок має обробляти домен?

Проксі зберігає публічний заголовок Host, але застосунку все одно потрібні дозволені домени й canonical URL. У Rails-розгортанні APP_HOST задає основний хост, APP_BASE_DOMAIN — основу піддоменів орендарів, RAILS_ALLOWED_HOSTS — прийнятні імена. Зарезервуйте www і admin, щоб маршрутизатор орендарів не сприймав їх як клієнтські сайти. Після зміни домену перевірте перенаправлення, посилання відновлення пароля, cookies, WebSocket і canonical URL.

Чи дає wildcard DNS wildcard-сертифікат HTTPS?

Ні. DNS спрямовує ім’я, але сертифікат потребує окремого підтвердження контролю домену. HTTP-01 Let’s Encrypt перевіряє токен за шляхом /.well-known/acme-challenge/ через порт 80. DNS-01 перевіряє TXT-запис і потрібен для wildcard-сертифікатів. Сертифікати для конкретних імен зручні для малого стабільного списку; DNS-01 wildcard — для частих змін за наявності безпечної автоматизації DNS. SAN-сертифікат потрібно поновлювати, не вилучаючи чинні імена.

Не перенаправляйте шлях HTTP-01 разом з іншими HTTP-запитами
Alias /.well-known/acme-challenge/ /path/served/by/certbot/

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^ https://app.example.com%{REQUEST_URI} [R=301,L,NE]

Як працює поновлення сертифікатів на 40i.net?

Для HTTP-01 Let’s Encrypt має отримати challenge для кожного домену. Не перенаправляйте ACME-шлях в обхід webroot Certbot. У конфігурації 40i.net використовується webroot ISPConfig; скрипт синхронізації отримує активні сайти й піддомени орендарів, розширює SAN-сертифікат через Certbot і перезавантажує Apache. Для site-builder.40i.net видано окремий сертифікат. Зберігайте активні імена під час розширення SAN. Після зміни webroot чи DNS перевірте Apache і зробіть тест поновлення.

Як додати піддомен без впливу на інші проєкти?

Зарезервуйте унікальне ім’я та перевірте його за списком піддоменів орендарів і сайтів. Спрямуйте DNS на сервер або перевірте wildcard. Оберіть окремий каталог статики або вільний loopback-порт. Створіть точний віртуальний хост Apache, налаштуйте дозволені домени та canonical URL і підготуйте сертифікат. Перевірте конфігурацію Apache до перезавантаження, тоді перевірте backend локально та публічний HTTPS. Зберігайте команду розгортання, unit systemd і конфігурацію в Git чи репозиторії експлуатації.

Як визначити рівень збою?

Перевіряйте послідовно: dig +short app.example.com показує DNS; apachectl -S — вибраний хост; apachectl configtest — помилки синтаксису; systemctl status і journalctl — стан застосунку; curl із Host до 127.0.0.1:PORT перевіряє backend без публічного DNS; openssl s_client показує сертифікат Apache. Помилка 502 зазвичай означає недоступний процес чи порт; чужа сторінка — інший віртуальний хост; невідповідний сертифікат — проблему TLS або маршрутизації хоста.

Де межа одного сервера?

Піддомени розділяють маршрутизацію, але не процесор, пам’ять, диск, базу даних або наслідки відмови машини. Перевантажений застосунок сповільнить інші, а збій сервера вимкне всі проєкти. Спільна база також може стати вузьким місцем. Стежте за ресурсами та перевіряйте відновлення копій. Переносьте проєкт на окремий сервер або схему з балансуванням, коли потрібні ізоляція, доступність чи потужність; до перемикання підготуйте DNS і сертифікати.

Проєкти за темою

Першоджерела технічної документації