Общая конфигурация DC CMS
Общая конфигурация
Безопасность
Чтобы обезопасить установку DC CMS, пожалуйста, ознакомьтесь с разделом “Безопасность DC CMS”.
Настройка проекта в delivery-окружении
Создание проекта или веб-сайта для delivery-процесса можно осуществить с использованием как традиционных методов развертывания, так и бессерверных (serverless) методов. Кроме того, можно настроить проект или сайт для работы как на staging-, так и на live-окружении.
Для традиционного delivery-процесса воспользуйтесь статьей “Настройка CMS Engine для Delivery-процесса проекта”, а для бессерверного delivery-процесса следуйте указаниям раздела “Бессерверный delivery-процесс”.
Порты и имена хостов
Порты и имена хостов по умолчанию
DC CMS использует по умолчанию следующие порты и имена хостов:
Модуль | Порт | Имя хоста |
---|---|---|
CMS Studio | 8080 33306 5701 |
localhost |
CMS Engine | 8080 9080 |
localhost |
CMS Deployer | 9191 9192 |
localhost |
CMS Search | 9201 9202 |
localhost |
Изменение портов и названий хостов
Иногда необходимо изменить порты или хосты в настройках вашей установки DC CMS. Обычно такая потребность возникает в следующих случаях:
- если нужно изменить порт, к которому привязано приложение в текущей установке
- если нужно установить связь между приложениями в текущей установке и другим приложением, расположенным на другом хосте и/или порте
Все хосты и порты, используемые приложениями DC CMS для связи можно задать в переменных окружения. Например, переменные MAIL_HOST
и MAIL_PORT
используются для определения хоста и порта для почтового сервера. Если эти переменные присутствуют, DC CMS будет использовать их; в противном случае он вернется к значениям по умолчанию.
Порты и имена хостов authoring-окружения
Пример ниже иллюстрирует предустановленные значения для имен хостов и портов, используемых authoring-приложениями в DC CMS:
export MAIL_HOST=${MAIL_HOST:="localhost"}
export MAIL_PORT=${MAIL_PORT:="25"}
export SEARCH_HOST=${SEARCH_HOST:="localhost"}
export SEARCH_PORT=${SEARCH_PORT:="9201"}
export DEPLOYER_HOST=${DEPLOYER_HOST:="localhost"}
export DEPLOYER_PORT=${DEPLOYER_PORT:="9191"}
export MONGODB_HOST=${MONGODB_HOST:="localhost"}
export MONGODB_PORT=${MONGODB_PORT:="27020"}
export MARIADB_HOST=${MARIADB_HOST:="127.0.0.1"}
export MARIADB_PORT=${MARIADB_PORT:="33306"}
export TOMCAT_HOST=${TOMCAT_HOST:="localhost"}
export TOMCAT_HTTP_PORT=${TOMCAT_HTTP_PORT:="8080"}
export TOMCAT_HTTPS_PORT=${TOMCAT_HTTPS_PORT:="8443"}
export TOMCAT_AJP_PORT=${TOMCAT_AJP_PORT:="8009"}
export TOMCAT_SHUTDOWN_PORT=${TOMCAT_SHUTDOWN_PORT:="8005"}
export TOMCAT_DEBUG_PORT=${TOMCAT_DEBUG_PORT:="8000"}
Порты и имена хостов delivery-окружения
Пример ниже иллюстрирует предустановленные значения для имен хостов и портов, используемых delivery-приложениями в DC CMS:
# -------------------- hostnames and ports --------------------
export MAIL_HOST=${MAIL_HOST:="localhost"}
export MAIL_PORT=${MAIL_PORT:="25"}
export SEARCH_HOST=${SEARCH_HOST:="localhost"}
export SEARCH_PORT=${SEARCH_PORT:="9202"}
export DEPLOYER_HOST=${DEPLOYER_HOST:="localhost"}
export DEPLOYER_PORT=${DEPLOYER_PORT:="9192"}
export MONGODB_HOST=${MONGODB_HOST:="localhost"}
export MONGODB_PORT=${MONGODB_PORT:="28020"}
export TOMCAT_HOST=${TOMCAT_HOST:="localhost"}
export TOMCAT_HTTP_PORT=${TOMCAT_HTTP_PORT:="9080"}
export TOMCAT_HTTPS_PORT=${TOMCAT_HTTPS_PORT:="9443"}
export TOMCAT_AJP_PORT=${TOMCAT_AJP_PORT:="9009"}
export TOMCAT_SHUTDOWN_PORT=${TOMCAT_SHUTDOWN_PORT:="9005"}
export TOMCAT_DEBUG_PORT=${TOMCAT_DEBUG_PORT:="9000"}
Логирование
Подробнее о логировании можно узнать здесь.
Обратный прокси (Apache HTTPd / NGINX)
Использование обратного прокси (reverse proxy), такого как Apache HTTPd, NGINX или CDN, для обслуживания веб-приложений CMS Studio и CMS Engine часто представляет собой преимущество. Эта настройка облегчает более быстрое обслуживание статических ресурсов, обеспечивает кэширование и предоставляет преимущества, такие как завершение SSL. В этом разделе мы рассмотрим конфигурацию обратного прокси через настройки виртуального хоста (vhost) Apache 2 HTTPd, настроенного для authoring- и delivery-процессов. Подобный подход можно применить и к другим HTTP-серверам.
Ниже приведены директивы, используемые для настройки обратного прокси с Apache:
- authoring-конфигурация
<VirtualHost *:80>
ServerName authoring.example.com
ProxyPreserveHost On
# Proxy Authoring and Preview (CMS and Engine Preview)
ProxyPassMatch ^/(studio/events)$ ws://localhost:8080/$1
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
# Configure the log files
ErrorLog ${APACHE_LOG_DIR}/cms-studio-error.log
CustomLog ${APACHE_LOG_DIR}/cms-studio-access.log combined
</VirtualHost>
- delivery-конфигурация
<VirtualHost *:80>
ServerName example.com
# Remember to change {path_to_dccms_home} to DC CMS installation home
# Remember to change {myproject} to your actual project name
# Path to your DC CMS project
DocumentRoot /{path_to_dccms_home}/data/repos/sites/{myproject}
RewriteEngine On
# Assign DC CMS project for this vhost
RewriteRule (.*) $1?cmsSite={myproject} [QSA,PT]
# Block outside access to management services
RewriteRule ^/api/1/cache / [NC,PT,L]
RewriteRule ^/api/1/site/mappings / [NC,PT,L]
RewriteRule ^/api/1/site/cache / [NC,PT,L]
RewriteRule ^/api/1/site/context/destroy / [NC,PT,L]
RewriteRule ^/api/1/site/context/rebuild / [NC,PT,L]
# Take all inbound URLs and lower case them before proxying to CMS Engine
# CMS Studio enforces lower-case URLs.
# Using the rewrite rule below, the URL the user sees can be mixed-case,
# however, what's sent to DC CMS is always lower-case.
RewriteCond %{REQUEST_URI} !^/static-assets/.*$ [NC]
RewriteCond %{REQUEST_URI} !^/api/.*$ [NC]
RewriteMap lc int:tolower
RewriteRule ^/(.*)$ /${lc:$1}
ProxyPreserveHost On
# Don't proxy static-asset, instead, serve directly from HTTPd
ProxyPass /static-assets !
# Proxy the rest to CMS Engine
ProxyPass / http://localhost:9080/
ProxyPassReverse / http://localhost:9080/
# Configure the log files
ErrorLog ${APACHE_LOG_DIR}/cms-engine-error.log
CustomLog ${APACHE_LOG_DIR}/cms-engine-access.log combined
</VirtualHost>
Использование директивы ProxyPreserveHost
определяет, используется ли входящий заголовок HTTP запроса Host для прокси-запроса.
В примере выше директивы ProxyPass
и ProxyPassReverse
указывают, что запросы к серверу, определенному в вашей конфигурации, должны быть перенаправлены на http://localhost:8080/
для authoring-установки и http://localhost:9080/
для delivery-установки. Включение директивы ProxyPassReverse
обозначает вашу конфигурацию как настроенную для обратного прокси.
Ниже приведены директивы, используемые для настройки обратного прокси-сервера с помощью NGINX:
- authoring-конфигурация
server {
listen 80;
server_name authoring.example.com;
# Proxy Authoring and Preview (CMS Studio and Engine Preview)
location ~ ^/(studio/events)$ {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Configure the log files
error_log ${NGINX_LOG_DIR}/cms-studio-error.log;
access_log ${NGINX_LOG_DIR}/cms-studio-access.log combined;
}
- delivery-конфигурация
server {
listen 80;
server_name example.com;
# Remember to change {path_to_dccms_home} to DC CMS installation home
# Remember to change {myproject} to your actual project name
# Path to your DC CMS project
root /{path_to_dccms_home}/data/repos/sites/{myproject};
location /static-assets/ {
# Serve static assets directly from NGINX
# Adjust the path as needed based on your setup
alias /{path_to_dccms_home}/data/repos/sites/{myproject}/static-assets/;
}
location / {
rewrite ^/(.*)$ /$1?cmsSite={myproject} break;
# Block outside access to management services
rewrite ^/api/1/cache / break;
rewrite ^/api/1/site/mappings / break;
rewrite ^/api/1/site/cache / break;
rewrite ^/api/1/site/context/destroy / break;
rewrite ^/api/1/site/context/rebuild / break;
# Take all inbound URLs and lower case them before proxying to CMS Engine
# CMS Studio enforces lower-case URLs.
# Using the rewrite rule below, the URL the user sees can be mixed-case,
# however, what's sent to DC CMS is always lower-case.
if ($request_uri !~ ^/static-assets/.*$ ) {
if ($request_uri !~ ^/api/.*$ ) {
rewrite ^/(.*)$ /${lc:$1} break;
}
}
proxy_pass http://localhost:9080/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Configure the log files
error_log ${NGINX_LOG_DIR}/cms-engine-error.log;
access_log ${NGINX_LOG_DIR}/cms-engine-access.log combined;
}
В зависимости от вашей конфигурации вам может потребоваться настроить следующие свойства DC CMS:
-
Установите свойство
cms.engine.forwarded.headers.enabled
в разделе “Forwarded Headers” в файлеserver-config.properties
. -
Настройте свойство
studio-config-forwarded-headers
в разделе “Forwarded Headers” в файлеstudio-config-override.yaml
.
При настройке delivery-окружения альтернативным подходом может быть указание HTTP-заголовка с именем X-CMS-Site
со значением {myproject}
, вместо использования перезаписи URL, как показано в приведенных выше примерах.
Forwarded-заголовки
Forwarded-заголовки настраиваются для определения фактического имени хоста и протокола, когда CMS Engine находится за балансировщиком нагрузки или обратным прокси. По умолчанию forwarded-заголовки отключены.
# Indicates if Forwarded or X-Forwarded headers should be used when resolving the client-originated protocol and
# address. Enable when Engine is behind a reverse proxy or load balancer that sends these
cms.engine.forwarded.headers.enabled=false
CMS Studio
CMS Studio помогает создавать контент и код на проекте/сайте и управлять ими. Узнайте больше о конфигурации и администрировании CMS Studio в статьях “Конфигурация CMS Studio” и “Администрирование CMS Studio”.
CMS Engine
CMS Engine доставляет контент пользователям. Подробнее о настройке и администрировании CMS Engine читайте в статье “Конфигурация CMS Engine".
CMS Deployer
CMS Deployer объединяет CMS Studio и CMS Engine и отвечает за публикацию контента из CMS Studio в CSM Engine. Узнать подробнее о конфигурации и администрировании CMS Deployer можно здесь.