Конфигурация сайта что это
Конфигурация сайта что это
Настройка файла конфигурации
Внутренняя часть файла выглядит следующим образом:
Обязательные значения
Чтобы настроить работу сайта, необходимо указать лишь несколько значений.
Данные значения предоставляет хостинг-компания, которой вы сейчас пользуетесь.
Имя хоста в большинстве случаев остаётся localhost, но можно и уточнить в панели управления.
Имя пользователя БД, пароль БД это те значения, которые создаются при добавлении нового пользователя в разделе БД MySQL хостинг-компании.
В названии от БД указывается та база, которая была предварительно создана для текущего сайта в панели хостинг-компании.
Чтобы узнать путь корневой директории, необходимо перейти в административный пункт «Информация о системе«.
В раздел: «Информация о PHP«.
Данный путь указан, напротив DOCUMENT_ROOT.
Заключение
Конфигурация сайта 1: введение
Сегодня заведём разговор на такую, казалось бы простую, тему, как конфигурация сайта. То есть поговорим о таких вещах, как параметры подключения к БД, различные настройки, как всё это хранить и как со всем этим работать.
Разобьём этот разговор на три части:
Итак, где же можно хранить настройки системы?
Нигде не хранить
Можно вообще не напрягаться с отдельным хранением настроек, а использовать их напрямую в нужном месте:
mysql_connect(‘localhost’, ‘vasa’, ‘qwerty’);
И так желательно сделать в каждом файле, где нужен доступ к базе. Тогда попытка изменить какой-то параметр обязательно превратиться в незабываемый праздник.
После использования данного подхода некоторое время на сайтах объёмом более трёх файлов, разработчики обычно понимают, что дальше так жить нельзя.
Глобальные переменные
Первое что делают после осознания того, что настройки системы следует объявлять единожды и в одном месте:
Уже лучше, но есть и минусы. Те же самые, что и вообще у глобальных переменных. Загадили глобальный контекст неоднородными, неструктурированными данными. С областями видимости будут постоянные проблемы. А так как и вся система при таком конфиге, очевидно, будет построена на глобальных переменных, то встаёт вопрос конфликта имён со всеми неприятно вытекающими последствиями.
Константы
Теперь мы загадили глобальный контекст неоднородными, неструктурированными константами. Единственная радость: они доступны в любой области видимости и их нельзя случайно изменить.
Имея небольшое преимущество перед глобальными переменными, в некоторых случаях константы даже хуже них.
База данных
Настройки можно хранить в базе данных (ну, кроме, собственно, параметров подключения к базе), а при необходимости, выбирать их оттуда запросами.
На первый взгляд это весьма забавное и имеющее право на существование решение. Тем более, что многие популярные форумы и блоги используют его.
Но при более детальном рассмотрении, это самое идиотское, что можно придумать по этой теме. В базе можно хранить настройки, которые будут меняться через веб-интерфейс, а также настройки пользователей и т.п. Хранить там общую конфигурацию, это пиз.ц.
Изменить что-то не предусмотренное в подобной админке, а тем более добавить новый параметр выливается во множество неприятных ощущений. А попытка скопировать себе сайт на локалку для разработке, превращается вообще во что-то мазохистское. После копирования нужно лезть в базу и выискивать там все параметры, которые необходимо изменить. Особенно радует, что хранятся они обычно в совершенно неудобоваримом формате.
Массивчик
Теперь у нас всё в отдельном конфигурационном массиве и не засоряет глобальную область.
Можно ещё избавиться от вредных привычек и вспомнить, что ассоциативный массив позволяет нам по-человечески всё структурировать:
Теперь и глазу приятнее и можно работать не со всем массивом, а с его частями.
return array()
Теперь у нас вообще никаких глобальных переменных нет. Конфиг перестал определять то, как его должен использовать программный код, а определяет только конфигурацию. А уже в коде в нужном месте:
$config = include(‘/path/to/config.php’); // Считываем конфигурацию из файла в переменную
Интерфейс доступа
Напишем простейший класс для получения конфигурации:
$config = Config::get(); // в нужном месте
В отличии от предыдущего примера мы снизили подключения файла до одного раза, даже при множестве запросов конфигурации и избавили прикладной код от знания пути к файлу.
Но гораздо важнее другое: мы разделили хранение конфигурации и интерфейс доступа к ней. Код, читающий конфигурацию, не обременяет себя знаниями о том, где она лежит, в каком виде и какими путями (может быть достаточно сложными) формируется. Можно полностью изменить способ хранения — на прикладной код это не повлияет.
С этого момента вопросами хранения конфига можно заниматься не задумываясь о вопросах его использования и наоборот.
Улучшение интерфейса
Интерфейс доступа к конфигу (в прошлом примере это Config::get() ) можно улучшать бесконечно и по своему вкусу.
Убрать статику, а на объект навешать магических методов и SPL-интерфейсов, чтобы получилось что-то вроде:
Получение config-объекта можно сделать через IoC-контейнер или через какую-нибудь другую заумную вещь.
По поводу улучшения интерфейса можно придумать много чего, а ещё больше можно найти готового в интернете. Оставим эту тему и в дальнейшем сконцентрируемся сугубо на способе хранения конфигурации.
Форматы хранения: адаптеры
Как показывает практика, наиболее удобным для использующего кода, форматом представления конфигурации является древовидная структура. То есть всё тот же ассоциативный массив.
А вот для хранения могут быть удобны разные форматы. Опять-таки массив (как выше), xml, ini-файл или ещё что-то.
Так как хранение от представления мы уже отделили, хранить мы можем в чём угодно, никак не влияя этим на интерфейс. Единственное, что нужно, это преобразовывать выбранный формат хранения к древовидной структуре для доступа к ней (то есть использовать различные адаптеры для загрузки).
Один из примеров такого подхода: Zend_Config.
P.S. Что хранить в конфиге
В конце вводной части задумаемся над тем, что вообще следует хранить в конфигурации сайта, а что не следует.
Вот такого вот делать не надо:
Потребуется что-то изменить, перенести на другой сервер, скопировать на локалку: о такое можно убиться.
Все значения, которые можно сгенерировать на основании какого-то базового, лучше генерировать:
Не надо пытаться конфигурировать каждую мелочь: лишней работы вы и те, кто придут после вас, получите гарантированно, а лишняя гибкость пригодится далеко не всегда.
Для начала, пожалуй хватит. В следующей части поговорим о более интересных вещах.
18 комментариев »
В питоне все прикольнее, например имеем settings.py:
DATABASE_NAME = ‘name’
DATABASE_USERNAME= ‘username’
DATABASE_USERNAME= ‘password’
и юзаем где надо:
import settings
или
from settings import DATABASE_NAME, DATABASE_USERNAME
и т.д.
Мне такой способ хранения конфигов куда больше нравится 🙂
Не вижу особой разницы, если честно.
А в следующей статье напишу вещи чуть посложнее, расскажешь как такое в питоне сделать.
Я о том, что не надо никаких зендконфигов и прочей мутни… И это не (супер)глобальные переменные и т.д.
phpdude, чего прижал? Поржал?
artoodetoo, я в тебе и не сомневался 🙂
интересно как хранить настройки для всего сайта и реврайтить некоторые для поддоменов, например…?
Бля, Вася_ц, пароль «qwerty» — это же просто трындец, сайты твои поломают на раз-два-три. Поменяй на что-то путевое!
Givi, сломай, дам пирожок )
>интересно как хранить настройки для всего сайта и реврайтить некоторые для поддоменов, например…?
не понял
>не понял
ну заходит юзверь на поддомен, а там функционал на другой СУБД висит…
kostyl, в следующей статейке четай.
2. В случае с путями, обычно получается построить вокруг __DIR__.
3. Я же люблю шаблоны:
return array(
‘a’ => 1,
‘b’ => 2,
‘ab’ => ‘<< a >>-<< b >>’,
);
В коде уже обрабатывать.
vasa_c, спасибо за идеи! Для моей текущей задачи воспользуюсь полухаком.
Я тоже часто пользуюсь полухаками, благо до return можно производить работу…
Не ожидал увидеть такого слаженного решения рассматриваемого вопроса.
Автору респект. 🙂
Создание PHP+MySQL сайта: от простого к сложному — шаг первый
Для создания перспективного, расширяемого и эффективного сайта любой сложности следует начинать с простого. Это процесс нелёгкий, требует определённых базовых знаний PHP и MySQL, но если его рассмотреть по пунктам — то можно составить своего рода «рабочий план», который пригодится при создании новых сайтов. Подготовим «ядро» и базу для проекта. Вначале это будет обычный сайт визитка, но потом, добавляя функционал, его можна превратить во что угодно. Итак, приступим.
1. Подготовка базы данных. Создаём первую таблицу в БД MySQL
Создаём новую базу данных, например «mysite». Лично я привык работать с кодировкой UTF-8, по-этому сразу оговорюсь: проследите, чтобы все текстовые файлы сайта, сама база, таблицы и поля таблиц были в одной кодировке.
В новой базе делаем таблицу. Назовём её «pages». В этой таблице будут храниться статические страницы будущего сайта и информация о них. Таблица должна содержать следующие поля:
Сразу после создания таблицы вставляем в неё значения для главной страницы сайта. В поле «page_alias» для главной страницы предлагаю вставить значение «home». Метатеги — соответственно тематике всего сайта. Таким же образом можно посоздавать другие страницы, например «О компании» с алиасом «about» и своими метатегами, или «Контакты» с алиасом «contacts» и т.д.
2. Создаём файл конфигурации сайта
function close() <
mysql_close($this->link);
>
Этот файл пока содержит только простой класс подключения к базе данных, но в дальнейшем в него можно добавлять разные полезные функции, которые будут доступны из любого места в коде сайта. Не забудьте изменить логин и пароль к Вашей базе.
Если Вы работаете в среде Windows, я могу порекоммендовать использовать редактор Notepad++. В этом редакторе есть нумерация строк, и он легко переводит текст из одной кодировки в другую. ВНИМАНИЕ! Если Вы работаете в кодировке UTF-8 — конвертируйте файлы в UTF-8 without BOM — это поможет избежать проблем в будущем.
3. Создаём index.php — главный контроллер сайта
Файл конфигурации создан. Теперь в корневой папке сайта создаём index.php — это и будет основной скрипт сайта, своего рода «главный контроллер». Содержание файла index.php:
// ГЛАВНЫЙ КОНТРОЛЛЕР
switch ($_GET[option]) <
case «page»:
include($_SERVER[DOCUMENT_ROOT].»/com/page.php»);
break;
default:
include($_SERVER[DOCUMENT_ROOT].»/com/home.php»);
break;
>
include ($_SERVER[DOCUMENT_ROOT].»/template.php»);
$db->close();
4. Создаём компонент вывода обычной страницы
Создаём в папке «com» файл «page.php». Содержимое файла следущее:
5. Создаём компонент вывода главной страницы
Главная страница у нас в базе данных хранится под псевдонимом «home», и пока по своей структуре не отличается от обычных страниц сайта — это просто статья. Тем не менее создадим для неё отдельный компонент — на перспективу, так сказать.
Содержимое компонента «home.php» в папке «com» почти совпадает с содержимым компонента обычной страницы, за исключением строки запроса к базе и названия компонента. Строка запроса теперь выглядит так:
$query = «SELECT * FROM wx_pages WHERE page_alias=’home’ LIMIT 1»;
6. Создаём шаблон дизайна всего сайта
В корневой папке также должны быть папки «css» и «images» для элементов дизайна. В файле /css/style.css — можно настроить стили по своему усмотрению.
RewriteEngine On
RewriteBase /
Солидные фронтенды: конфигурация
Манифест 12-факторных приложений внес весомый вклад в процесс разработки и эксплуатации веб-приложений, но это по-большей части коснулось бекендов, и обошло стороной фронтенды. Большенство пунктов манифеста или не применимы к фронтендам, или выполняются сами собой, но с номером 3 — конфигурация — есть вопросики.
В оригинальном манифесте сказано: «Сохраняйте конфигурацию в среде выполнения». На практике это означает, что конфигурацию нельзя хранить внутри исходного кода или финального артефакта. Ее нужно передавать в приложение по время запуска. У этого правила есть практические применения, вот парочка:
Приложение в разных окружениях должно обращаться к разным бекендам. На продакшене — к продакшн API, на стейдженге — к стейджинг API, а при запуске интеграционных тестов — к специальному мок-серверу.
Для е2е тестов нужно снижать время ожидания реакции пользователя. Например, на если на сайте после 10 минут бездействия что-то происходит, то для тестового сценария можно уменьшить этот интервал до минуты.
Если фронтенд-приложение содержит в себе SSR, то задача становится чуточку легче. Конфигурацию передают как переменные окружения в приложение на сервере, при рендере она попадает в ответ клиенту как глобальные переменные, объявленные в ‘ *.html
Я не большой знаток Bash, вероятно получилось странно. Этот скрипт призван показать общую идею, а не использоваться в проекте напрямую.
И теперь немного подправим Dockerfile:
После этих манипуляций можно передавать на фронтенд любые параметры через переменные окружения — нужно отметить переменную в env.dict и передать ее при запуске контейнера.
Если внимательно посмотреть на этот вариант, станет понятно, что он почти не отличается от варианта с SSR приведённого в начале статьи. Для удобства можно воспользоваться isomorphic-env-webpack-plugin, и дописать пару скриптов: генерации файла и вставки ссылки на него в HTML.
В этой схеме есть еще один небольшой эдж-кейс — обычно в имена файлов с ресурсами добавляют хеш содержимого, чтобы в браузере без проблем кешировать все файлы навсегда по имени. В таком случае нужно немного усложнить скрипт генерации файла с переменными, хешировать содержимое и добавлять результат в имя файла.
Заключение
Правильная работа с параметрами фронтенд-приложения помогает создавать надежные и удобные в эксплуатации системы. Достаточно отделить конфигурацию от приложения и перенести ее в среду выполнения, чтобы радикально улучшить комфорт членов команды и снизить количество потенциальных ошибок.
А как вы передаёте конфиги в клиентские приложения?
Just another tool: знакомство с конфигурацией сервисов с помощью Desired State Configuration
Desired State Configuration (DSC) — инструмент управления конфигурацией сервера. С его помощью можно настроить сервер (внести изменения в реестр, копировать файлы, установить и удалить компоненты), проконтролировать текущее состояние настроек и быстро откатиться до базовых настроек.
DSC интересен тем, кто придерживается DevOps-подхода. Этот инструмент хорошо укладывается в парадигму Infrastructure as a Code: разработчики могут вносить свои требования в конфигурацию и включать ее в систему управления версиями, а команды — развертывать код без использования «ручных» процессов.
Совместно со Станиславом Булдаковым из Райффайзенбанка мы объединили наш опыт работы с движком DSC и разделили его на 2 статьи. В первой мы разберем основные принципы работы и познакомимся с особенностями использования на практических примерах:
Знакомство с движком начнем с изучения предустановленных ресурсов. Далее попробуем написать конфигурации.
Ресурсы DSC
Ресурсы DSC — своеобразный аналог модулей PowerShell. Любой сервер Windows уже имеет предустановленный набор ресурсов DSC, они лежат в том же каталоге, что и модули PowerShell. Список можно получить через командлет Get-DscResourse. Вот как этот список выглядит на Windows 10 1809:
Названия ресурсов дают понимание, с чем они работают:
Как установить дополнительные ресурсы. Используем командлет Install-Module. Установка ресурсов — это обычное копирование файлов ресурса по одному из путей в переменной окружения $env:PSModulePath. Установленные ресурсы автоматически не подключаются по ходу компиляции, поэтому позже мы дополнительно подключим их в самой конфигурации.
Для использования ресурса нужно установить его локально и на целевом сервере. В On-Premise инфраструктурах политика безопасности обычно запрещает доступ в интернет для серверов. В этом случае сервер DSC не сможет подгрузить дополнительные ресурсы из внешних источников. Для публикации архивов с модулями мы разворачиваем локальный репозиторий NuGet или обычный веб-сервер. Для веб-сервера установить дополнительные ресурсы можно с помощью распаковки модуля в каталог C:\Program Files\WindowsPowerShell\Modules\
Это как раз и делает командлет Install-Module.
Во второй статье мы подробнее рассмотрим, чем отличается установка для режимов Push и Pull.
Разбор простой конфигурации
Конфигурация — это простое последовательное описание того, что должно быть сделано на сервере. Так выглядит простая конфигурация DSC:
На ее примере посмотрим, из чего состоит конфигурация.
Блок Configuration — специальный тип функции PowerShell с описанием того, что мы хотим получить.
Внутри блока содержится:
Настройка Local Configuration Manager
Local configuration manager отвечает за применение конфигураций, которые мы скомпилировали в mof-файлы. Именно он следит за сохранением состояния, определенного в конфигурации. Если система выходит из этого состояния, LCM вызывает код в ресурсах для восстановления заданного состояния.
Посмотрим настройки Local configuration manager через Get-DscLocalConfigurationManager:
То же самое для последней версии WMF с комментариями:
Особенности метаконфигурации. При написании метаконфигурации мы используем те же блоки, что и для обычной конфигурации DSC. Исключение — внутренний блок LocalConfigurationManager (v4) или атрибут DSCLocalConfigurationManager (v5) для конкретного сервера. В них описываются все необходимые настройки.
Метаконфигурация тоже компилируется в mof-файл, но для ее применения используется командлет Set-DSCLocalConfigurationManager, а не Start-DSCConfiguration.
Теоретически ничто нам не мешает совмещать настройку LCM и обычных ресурсов в рамках одной конфигурации. Но для простоты рекомендуется написание и применение конфигурации и метаконфигурации разделять.
Частичные конфигурации
Частичные конфигурации (Partial Configurations) — несколько конфигураций, которые исполняются последовательно друг за другом. Они полезны в том случае, когда над сервисом работает несколько команд. Каждая из команд указывает настройки для своей части сервиса, а частичная конфигурация затем применяет все настройки последовательно. В настройках LCM мы указываем частичные конфигурации в PartialConfigurations.
В частичных конфигурациях мы должны учесть прямолинейную логику DSC. Движок не допускает ветвлений, так что для выполнения разных условий нужны дополнительные ресурсы. Разберем это на нескольких примерах.
Допустим, мы хотим гарантированно доставить конфигурацию на сервер и действуем по следующему алгоритму:
В первой части конфигурации указано Download and install modules: скачай и установи необходимые ресурсы. Вторая часть ServerOSConfig приводит сервер к нужному состоянию. Какие здесь могут быть нюансы с прямолинейностью DSC:
Про безопасность
Жирным минусом DSC на «земле» является отсутствие Run As Accounts. Этот механизм безопасно хранит учетные записи в виде логин+«соленый хэш пароля» и подсовывает их сервису, который отвечает за аутентификацию. Без него DSC не может управлять учетными записями от имени другого сервиса. А если нам нужно аутентифицироваться под учетной записью с особыми привилегиями, процесс автоматизации сильно осложняется. Например, так будет при вводе сервера в домен.
Все, что есть в нашем распоряжении:
Подобный подход применим только к сценарию Push, поскольку Pull в достаточной степени прямолинеен и не подразумевает замену конфигурации на лету. В следующей статье от buldakov мы в деталях рассмотрели настройку и особенности работы в режимах Push и Pull.
А еще приходите обсудить нюансы технологии DSC и границы ее применения 28 мая в 18.00 на первом онлайн-митапе сообщества DGTL Communications Райффайзенбанка. Также на встрече поговорим, как подружить ELK и Exchange и что может Microsoft Endpoint Manager в управлении устройствами. Вот тут регистрация на митап.