Конфигурация сайта: конфигурация сервера

Продолжим, пожалуй, разговор про конфиги (часть 1, часть 2.1, часть 2.2).

На этот раз отвлечёмся от теории и перейдём к практике. Чтобы нам такое законфигурировать?

Законфигурируем, пожалуй, какую-нибудь конфигурацию :) Допустим, конфигурацию веб-сервера и пусть сервером этим будет Nginx.

Задача более конкретно:

  • Разрабатываем сайт example.ru
  • Я разрабатываю в своей локальной версии — go.example.local, а другой разработчик в своей — hugo.example.local + ещё верстальщик с дизайнером
  • Есть у нас общая локальная версия example.local на локальном сервере.
  • И есть тестовый поддомен test.example.ru, на котором заказчик проверяет последнии фишки, перед тем, как их зальют собственно на example.ru
  • test.example.ru находится в открытом доступе и его следует закрыть хотя бы с помощью htpasswd
  • Все загружаемые изображения лежат на поддомене «img.*», то есть img.example.ru, img.go.example.local и т.д.

Итак, у нас уже 7 версий сайта. Каждая на своём хосте. И для каждого хоста нужно иметь nginx-конфиг. Все конфиги имеют одинаковую структуру, но отличаются частностями.

Что мы будем их 7 раз копипастить и корректировать? А любое изменение в структуре вручную в каждую версию вносить? К чёрту! Давайте всё автоматизируем.
Остальной текст под катом

, , , ,

Конфигурация сайта 2.2: совместная разработка (наследование)

Продолжаем разговор из прошлых двух частей.
Конфигурация сайта 1: введение
Конфигурация сайта 2.1: совместная разработка (платформы)

В прошлой части у нас массив, соответствующий какой-то платформе (например, vasya), вливался в массив некой базовой конфигурации (config.php). Назовём это: «vasya наследуется от config».

Раньше я делал так:

config — конфигурация системы на рабочем сервере, от неё наследуются конфигурации разработчиков.

Оно не всегда удобно. Лучше наследоваться от какой-то базовой конфигурации, а рабочей сервер поставить в один ряд с разработчиками. Тем более в нашем примере рабочих серверов у нас несколько.

Наследуем всё от базового конфига и введём ещё промежуточные этапы:

Остальной текст под катом

, ,

Конфигурация сайта 2.1: совместная разработка (платформы)

В прошлой статье мы разобрались, как можно хранить конфигурацию системы и как её можно использовать.

Однако, мы подразумевали простейший вариант, когда система работает в единственной копии на сервере. Усложним положение:

Итак, бравые разработчики Вася, Петя, Миша и Гриша в поте лица разрабатывают очередную социальную сеть нового поколения. Каждый ведёт разработку в своей локальной версии на своём компьютере. Наработки они выкладывают на локальный тестовый сервер (где-нибудь в офисе в шкафу пылиться). Выкладывают, конечно, не по FTP, а с использованием какой-нибудь системы контроля версия, например, Mercurial.

Ведущий программист проверяет обновления на наличие ошибок и в случае чего даёт по шее. Если же ошибок не видно и локальная версия достигает какого-то стабильного состояния: все изменения отправляются уже на боевой сервер. Вернее на сервера, потому что проект крупный и серверов уже аж три штуки стоит.

Итого, система работает уже не в одной копии, а в восьми (4 разработчика, локальный сервер, 3 рабочих сервера). Назовём то, где работает конкретная копия системы платформой и дадим каждой имя (платформа server.1, платформа vasya, платформа local и т.д.).

Понятно, что конфигурация системы будет иметь одинаковую структуру для всех платформ, но вот на каждой конкретной значения параметров могут отличаться. То есть, у каждого из разработчиков могут быть свои параметры локальной БД. Или Вася захотел включить у себя вывод отладочной информации, а Петя этого не захотел. И так далее.

Подумаем, как это можно организовать.

Остальной текст под катом

, ,

Конфигурация сайта 1: введение

Сегодня заведём разговор на такую, казалось бы простую, тему, как конфигурация сайта. То есть поговорим о таких вещах, как параметры подключения к БД, различные настройки, как всё это хранить и как со всем этим работать.

Разобьём этот разговор на три части:

  • В текущей рассмотрим различные варианты организации конфига. Эта часть в первую очередь ориентирована на новичков.
  • Во второй задумаемся над более сложными вещами. Например, как поддерживать набор отличающихся конфигов для одной системы.
  • А в третьей части попробуем всё это высечь в коде.

Остальной текст под катом

, ,