¶ Требования к хостингу
¶ Требования для выкладки сайтов Canape CMS начиная с версии 3.23 и старше
- Unix подобная операционная система
- Для CMS 4.03 поддерживаемые версии PHP 7.0-7.4
- Место на диске от 2 ГБ (для года работы)
- Apache 2.4+ или nginx/1.14.0
Для apache:
|
|
- модули PHP:
cgi, cli, common, curl, fpm, gd (с поддержкой jpg), imap, intl, mbstring, mcrypt, mysql, opcache, pspell, readline, soap, tidy, xml, xsl, zip |
- php.ini
|
|
- Mysql 5.1+
- Возможность добавлять задания CRON
- До 60 проектов соседей на одном физическом сервере
- Для работы инсталлятора необходимы:
|
|
¶ Тестирование хостинга
¶ Утилита тестирования хостинга
Для проверки возможности выкладки сборки версии Canape CMS разработана специальная утилита. Она представляет собой php файл. (файл в архиве test_host)
Для ее использования необходимо закачать php файл по ftp на сервер в папку web и запустить его/
- Пример адрес_сайта/skewer.php
После чего появится следующий интерфейс:
Утилита обладает следующими возможностями:
- Вкладка "Обязательные параметры" — выводятся обязательные параметры для хостинга Canape CMS 4.03. Версия php подсвечивается 3 цветами:
- Зеленый - оптимальная
- Желтый - минимально допустимая
- Красный - недопустимая, CMS не будет работать
- Вкладка "Общий тест" — при переходе на вкладку запускается тестирование хостинга, после чего выдаются возможные несоответствия требованиям.
- Вкладка "Проверить почтовый хостинг" — при переходе на вкладку открывается окно с формой для проверки возможности работы почтового сервера. В ней нужно указать адрес и в случае успешной работы письмо отправится. В письме придет список возможных проблем на хостинге.
- вкладка "Проверить MySQL" — при переходе на вкладку открывается окно с формой для проверки работы с БД хостинга.
- Вкладка "Информация о PHP" — при переходе на вкладку выдается информация о php настройках сервера. Т.е. информация как при запуске файла info.php
¶ Подготовка к тестированию.
Для того, чтобы протестировать хостинг на соответствие требованиям для Canape CMS потребуются:
- Доступы к FTP (SFTP, FTPS) аккаунту хостинга.
- Доменное имя, привязанное к этому аккаунту.
- Параметры доступа к БД.
В случае, если есть доступ к ЛК хостинга, то все требуемые выше параметры можно завести там самостоятельно.
Важно! Если тестируемый аккаунт хостинга является "живым" (на нем располагаются действующие сайты клиента), то запрещается изменение любых параметров хостинга либо настроек DNS для этого аккаунта, которые могут привести к ошибкам, либо некорректной работе аккаунта на хостинге или сайтов на нем.
- Необходимо использовать утилиту (файл skewer.php в архиве test_host) для тестирования хостингов.
- После соединения с сервером хостинга по FTP (SFTP, FTPS) нужно закачать ранее полученный файл в директорию, являющуюся корневой для web-сервера при обращении к нему по имеющемуся доменному имени. После чего обратиться к этому файлу из-под браузера.
|
|
Обязательно делается проверка отправки писем средствами php mail() (В тесте есть соотв. вкладка) и проверка версии СУБД MySQL.
¶ Результаты тестирования
Результаты теста с вкладки "Общий тест" делятся на три уровня важности:
1. "Синие" сообщения - являются информационными, на работоспособность CMS не влияют.
2. "Желтые" - отражают предупреждения по параметрам, потенциально влияющим на функциональность сайта.
Пример:
Параметр max_uploaded_filesize = 2M ограничивает возможность загрузки файлов через систему администрирования размером более 2-х Мб. Что может привести к ошибкам при попытке загрузки "больших" изображений в фотогалерею.
3. "Красные" - сообщения, предупреждающие о том, что некоторые из параметров хостинга не подходят для использования его в качестве площадки для размещения сайта на Canape CMS.
Не все проверки (особенно системных параметров ОС и аппаратных возможностей) можно корректно провести из-под PHP,поэтому крайне важно правильно понимать, что подразумевает то или иное сообщение, и какие последствия возможны.
Так, если в результате работы теста появляется сообщение: Требуется 2Gb дискового пространства - доступно 0.00 и при этом аккаунт на хостинге новый, то имеет смысл перепроверить информацию системными средствами, предоставляемыми самим хостингом. Т.к. согласно здравой логике, скорее всего новый аккаунт не может быть продан клиенту с дисковой квотой в 0Mb.
Все "красные проблемы" делятся на два вида:
- Те, которые можно исправить, например средствами переконфигурации хостинга (редактированием локальных файлов конфигурации, либо с помощью панели управления хостингом в ЛК)
- Те, которые для изменения не доступны.
В первом случае возможны два варианта:
1. Аккаунт на хостинге новый, изменение его параметров не приведет к проблемам с "живыми сайтами"
- Проверяем возможность изменения требуемых значений
- Меняем, проверяем правильность работы
2. Аккаунт на хостинге содержит существующие "живые" сайты клиента
- Проверяем возможность изменения требуемых значений
- Формируем отчет, в котором указываем список параметров хостинга, требующих изменения. Обязательно нужно оставить предупреждение о том, что изменение конфигурации хостинга может привести к ошибкам в работе существующих сайтов клиента на этом аккаунте.
Во втором случае:
- Формируем отчет, в котором указываем, что хостинг не подходит по параметрам, которые указываем ниже списком согласно тесту.
После завершения процесса тестирования файл skewer.php удаляется с сервера. Все измененные параметры хостинга возвращаются в первоначальное состояние.
¶ Сообщения об ошибках в результате тестирования
| Директория хранения сессий PHP не доступна для записи | + | Возникнет проблема с авторизацией в CMS, т.к. не будет писаться сессия. Так же будут проблемы с любым процессом, где используются хранение данных в сессии. |
Провести дополнительное тестирование. Установить права 755 на папку куда пишется сессия. Типовой папки нет, для каждого хостинга нужно ее искать отдельно. Обратитесь за помощью к Админу. |
|---|---|---|---|
| Post_max_size меньше минимально допустимого | - | Post_max_size - параметр, который отвечает за максимальный размер "посылки" информации. Суммарный объем загружаемой (отправляемый) за раз на сайт информации (файлы, тексты). | Через настройки хостинга, если есть доступ. |
| Upload_max_filesize меньше минимально допустимого | - | Upload_max_filesize - параметр отвечает за размер максимально допустимого файла к загрузке. Например, загрузка фото, документов через файловый менеджер. | Через настройки хостинга, если есть доступ. |
| Информация о модулях web-сервера не доступна | - | Утилита не смогла прочитать, либо в php.info отсутствует блок load modules. |
1. Дождаться выхода новой версии утилиты 2. Посмотреть необходимые модули в php.info самостоятельно. Список модулей PHP |
| Минимально допустимое дисковое пространство равно 2G Доступно nG | - | Утилита протестировала свободное место и считает что, его не достаточно. |
1. если показывается что доступно 0, то утилита не смогла корректно оценить место на хостинге. Скорее всего все в порядке 2. если показывается, то доступно 1,5T (как пример), то значит, что места доступно больше чем нужно и утилита не распознала терабайт 3. Место можно увеличить, настроив хостинг. Обращаемся к Администратору. |
¶ Тестирование директории хранения PHP на запись.
В случае, если при тестировании хостинга появилась надпись: "Директория хранения сессий PHP не доступна для записи", то есть вероятность, что утилита не может провести корректно данную проверку. Можно проверить это самостоятельно по следующему алгоритму:
- Скачиваем архив, в нем 2 php файла.
- Распаковываем архив и заливаем на хостинг
- Запускаем в начале первый файл адрес_сайта/test1.php, потом запускаем второй адрес_сайта/test2.php
- Если в результате последовательного запуска на экран выводится сообщение "Директория хранения сессии PHP доступна для записи", то все в порядке..
- Если в результате последовательного запуска на экран ничего не выводится, то нужно найти папку для хранения сессии PHP и выставить на нее права 755.
¶ Автоматическая выкладка
Инструкция для сайтов версии 3.23 и старше
Для корректной работы инсталлятора необходимо чтобы на хостинге были выполнены следующие условия:
- safe_mode Off
- рабочие функции exec() и shell_exec()
Подготовка к выкладке
- Получаем от менеджера следующие фалы - экспортная копия сайта и инсталлятор.
Выкладка сайта
- Авторизуемся на хостинге через файловый менеджер. Рекомендуется использовать менеджер WinSCP. Скриншот.
- Закачиваем на хостинг, в корневую папку, экспортный файл (целиком весь архив) и инсталлятор. Скриншот. В программе WinSCP это осуществляется путем выделения файлов и переноса.
- Запускаем инсталлятор командой - домен_сайта/install_23.php
- На первом шаге заполняем доступы к БД и нажимаем кнопку "Дальше". Скриншот
- На втором шаге проверяем, правильно ли прописан основной домен. Если нет, то указываем верный, обычно для этого достаточно либо дописать, либо стереть www. Так же на этом шаге можно указать дополнительные домены, если они есть. После проверки и правок жмем "Дальше". Скриншот.
- Если процесс выкладки сайта прошел без ошибок, то откроется сайт.
- Устанавливаем задание на Cron, чтобы корректно и вовремя обновлялся файл sitemap.xml. Рассмотрим данный процесс на базе isp-панели:
-
- Заходим в isp панель хостинга.
- Находим пункт "Планировщик (cron)". Скриншот
- Нажимаем кнопку "Создать" (Cкриншот) и заполняем следующие поля:
- Команда - прописываем следующее wget -O /dev/null -q http://адрес_сайта/cron/index.php, где адрес_сайта - это адрес вашего сайта.
- Период - выбираем пункт другое.
- Минуты - выбираем "Каждые", а в появившемся пункте "Каждые" выбираем 05.
- Остальные пункты не трогаем. Должно получиться вот так - Cкриншот
- Добавляем данное задание, нажав ОК.
- После постановки задачи на cron нужно его проверить:
- Заходим в CMS и заводим тестовый раздел (обязательно добавляем информацию в поле редактор);
- Ждем около 10 минут со времени создания тестового раздела;
- Открываем файл sitemap.xml и проверяем его на наличие тестового раздела.
- Удаляем тестовый раздел
- Сайт выложен.
¶ Ручная выкладка сайта
Инструкция для сайтов версии 3.23 и старше
¶ Подготовка к выкладке
- Распаковываем содержимое архива (экспортный файл, который отдал вам менеджер компании) у себя на ПК. При этом не удаляем экспортный архив.
- В результате подготовки сайт к выкладке у вас на ПК должны быть следующие файлы - распакованный архив (внутри файл БД и папка site c файлами).
¶ Выкладка сайта
- Авторизуемся на хостинге через файловый менеджер. Рекомендуется использовать менеджер WinSCP. Скриншот.
- Закачиваем на хостинг, в корневую папку, файлы из папки site (не папку site, а именно файлы из нее). Скриншот. В программе WinSCP это осуществляется путем выделения файлов и переноса.
Внимание! Процесс закачки файлов весьма длительный, наберитесь терпения. Можете пока перейти к пункту 3. - Импортируем базу данных сайта на хостинг:
- Авторизуемся в панели хостинга.
- Находим пункт, связанный с базами данных, в нем ищем пункт PhpMyAdmin. Нажимаем на него и переходим на интерфейс авторизации PhpMyAdmin. Скриншот
- Авторизуемся. Слева выбираем свою БД и нажимаем на нее. Скриншот
- В открывшемся интерфейсе, в правой его части нажимаем на кнопку "Импорт". Скриншот
- Открылся интерфейс импорта, в нем нажимаем на кнопку "Обзор", затем находим файл БД сайта (она лежит в папке с распакованным экспортным архивом) и выделив его жмем "Открыть". Скриншот
- После того как файл БД добавился, его название появиться рядом с кнопкой "Обзор". Затем нажмите кнопку "ОК". Скриншот. Начнется прогресс импорта БД.
- В конце импорта вы увидите сообщение, об успешном завершении процесса и слева появятся названия таблиц БД. Скриншот. Не закрывая вкладку с PhpMyAdmin, переходим к следующему пункту.
- Указываем домен в базе данных:
- находим в левой части таблицу domains (скриншот). нажимаем на нее.
- вверху нажимаем на кнопку "Вставить". скриншот
- в открывшемся интерфейсе заполняем поля (данные вносим только в колонку "Значение" скриншот):
- поле d_id указываем число 1
- поле domain_idуказываем число 1
- поле domain прописываем домен,без http://
- поле prim указываем 1, если домен основной, и 0, если не основной.
- аналогично делаем для 2 набора полей, должно получиться так - скриншот, сохраняем изменения, нажав кнопку "ОК"
- на следующей странице нажмите на название таблицы domains и если вы увидите следующее - скриншот, то сделано все правильно.
- Проверяем, закончился ли в файловом менеджере процесс по закачиванию файлов. Если закончился, то переходим к следующему пункту, если нет, то ждем окончания и потом переходим к следующему пункту.
- Прописываем настройки базы данных сайта:
- открываем с помощью текстового редактора файл config.db.php. Файл лежит в папке config. (скриншот)
- в строке ‘dsn' => 'mysql:host=localhost;dbname=rc37', прописываем следующее. (скриншот):
- в части mysql:host=localhost вместо localhost прописываем хостинг базы. (но в большей части случаев этот параметр менять не надо)
- в части dbname=rc37 вместо rc37 прописываем имя базы данных
- в строчке 'username' => 'rc37' вместо rc37 прописываем имя пользователя базы данных. Скриншот
- в строчке 'password' => 'vrtrrtBRoertytteBJrtYagertrtr8AwF' вместо VBRoBJYagJIC8AwF прописываем пароль для базы данных. Скриншот
- сохраняем изменения.
- Прописываем настройки конфигурации сайта:
- определяем корневой путь до папки сайта - скачиваем файл, потом закачиваем его в папку web сайта, переименовываем расширение с txt на php, и открываем в строке браузера, набрав домен_сайта/home.php. В результате получим полный путь до папки с сайтом (скриншот). Запишите его в блокноте, он понадобиться.
- открываем файл constants.generated.php. Файл лежит в папке config (скриншот):.
- в строчке define('USECLUSTERBUILD', 1); вместо 1 пишем false Скриншот
- в строчке define('INCLUSTER', true); вместо true пишем false Скриншот
- в строчке define('ROOTPATH', '/var/www/test-obn/'); вместо /var/www/test-obn/ указываем полный путь до папки сайта (мы его узнали пунктом выше). Скриншот Обязательно должен быть открывающий и закрывающий /
- в строчке define('WEBPATH', '/var/www/rc37/web/'); меняем '/var/www/rc37/web/' на ROOTPATH.'web/' Скриншот Обязательно должен быть закрывающий /. Если строчка отсутствует, то добавляем ее.
- в строчке define('RELEASEPATH', '/var/skewerCluster/canape/0023/skewer/'); меняем '/var/skewerCluster/canape/0023/skewer/' на ROOTPATH.'skewer/' Скриншот Обязательно должен быть закрывающий /
- должен получиться файл вида - скриншот
- Сохраняем изменения.
- Проверяем .htaccess, находящийся в папке web (скриншот):
- открываем файл .htaccess. Если вы его не видите, то необходимо в файловом менеджере включить просмотр скрытых файлов.
Если сайт версии 3.26 и старше, то проверяем его, он должен выглядеть так:
Если сайт до версии 3.26, то удаляем из файла весь текст, и вставляем следующий:
- в строчке RewriteCond %{HTTP_HOST} ^адрес сайта вместо адрес сайта указываем не основной домен сайта, без http://
- в строчке RewriteRule (.*) http://адрес сайта/$1 [R=301,L] вместо адрес сайта указываем основной домен сайта, без http://
- должен получиться такой файл - скриншот. Cохраняем изменения в документе.
- Вводим в браузере адрес сайта, проверяем, чтобы он открылся без ошибок.
- Обновляем Robots.txt и sitemap.xml:
-
- Авторизуемся на FTP сайта
- Открываем файл robots.txt, он лежит в папке web.
- Прописываем файл robots.txt:
-
Вместо присутствующей записи прописываем следующее:
- Сохраняем изменения.
- Обновляем sitemap.xml:
- Авторизуемся в системе администрирования по ссылке http://адрес_сайта/admin
- Создаем новый раздел, добавляем любой текст в поле "Текст раздела", сохраняем изменения.
- Открываем вкладку соседнюю вкладку с адресом http://адрес_сайта/cron. Должна появиться 1.
- Проверяем sitemap.xml, в нем должны быть ссылки на домен сайта, для этого набираем строке браузера http://адрес_сайта/sitemap.xml
- Удаляем тестовый раздел
- Устанавливаем задание на Cron, чтобы корректно и вовремя обновлялся файл sitemap.xml. Рассмотрим данный процесс на базе isp-панели:
- Заходим в isp панель хостинга.
- Находим пункт "Планировщик (cron)". Скриншот
- Нажимаем кнопку "Создать" (Cкриншот) и заполняем следующие поля:
- Команда - прописываем следующее wget -O /dev/null -q http://адрес_сайта/cron/index.php, где адрес_сайта - это адрес вашего сайта.
- Период - выбираем пункт другое.
- Минуты - выбираем "Каждые", а в появившемся пункте "Каждые" выбираем 05.
- Остальные пункты не трогаем. Должно получиться вот так - Cкриншот
- Добавляем данное задание, нажав ОК.
- После постановки задачи на cron нужно его проверить:
- Заходим в CMS и заводим тестовый раздел (обязательно добавляем информацию в поле редактор);
- Ждем около 10 минут со времени создания тестового раздела;
- Открываем файл sitemap.xml и проверяем его на наличие тестового раздела.
- Удаляем тестовый раздел
- Сайт выложен.
¶ Методика расчета требуемых вычислительных ресурсов
В данной методике описывается процесс расчета необходимых вычислительных ресурсов на основе количества пользователей для типовой площадки сайта правительства на базе canape cms.
Для определения объема требуемых ресурсов потребуется знать примерное общее число пользователей, которые будут одновременно работать с системой.
Для разработки этой методики проводились нагрузочные тестирования средствами Yandex.Tank на эталонной системе на архитектуре x86 с частотой процессора 2GHz. Применялось линейное увеличения запросов в секунду с анализом потребляемых ресурсов. При этом запросы производись не к одной странице сайта, а ко всем, представленным в sitemap.xml. Также анализировалось потребление ресурсов на боевых машинах.
Исходя из нагрузочных тестирований были выявлены следующие нормы потребления ресурсов.
¶ Процессор
Для оптимального использования серверов рекомендуется, чтобы каждое виртуальное ядро использовалось на 70-80% в пиковое время.
В результате нагрузочных тестирований было выявлено, что одно виртуальное ядро способно обработать 20 запросов в секунду, при его нагрузке в 50% и 40 запросов в секунду при пиковых нагрузках.
¶ Оперативная память
Тесты показали, что для уверенной работы площадки требуется 42МБ оперативной памяти.
¶ Диск
Для одной площадки требуется от 2 до 10 ГБ в зависимости от объема контента на сайте. Для работы сайтов рекомендуется использовать ssd, так как он лучше справляется с чтением большого количества маленьких файлов. Во время работы сайту не требуется высокая скорость диска, но она понадобиться для создания резервных копий.
¶ Пример расчета требуемых вычислительных ресурсов
Исходя из анализа логов боевых площадок был сделан вывод что они относительно редко посещаются следовательно на одном сервер может размещаться множество таких площадок.
Например у нас на одном сервер расположено 100 площадок.
Допустим при нормальной работе в среднем на одной такой площадке 5 пользователей одновременно.
Допустим они делают 1 запрос в 2 секунды (0,5rps). Тогда нагрузка будет составлять 100 * 5 * 0,5 = 250 запросов в секунду.
При этом пиковые нагрузки на одну из площадок будут сглаживаться за счет их количества.
Количество виртуальных ядер: 250rps / 20 = 12,5 ядер, но нужно еще на операционную систему, мониторинг, антивирусную защиту, поэтому рекомендуется поднять до 16.
Оперативная память: 42MB * 100 = 4,2ГБ. Аналогично с процессором, нужно взять больше для ОС и другого ПО, например 8ГБ.
Дисковое пространство: Допустим в среднем площадки будут занимать по 5 ГБ. Итого нужно будет около 500ГБ свободного объема. Но площадки со временем разрастаются из-за постепенного добавления контента. Поэтому рекомендуется добавить 20 %, итого 600ГБ.