Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Конструкция конфигов на сайтах Алавар

Anna | 31.05.2014 | нет комментариев
Всем здравствуй!
Сайты Alawar — это сайты для русскогозаокеанского, европейских и других рынков, отдельные сайты для mobile-устройств, сайты партнерских программ и др. Все они развернуты на одном инстансе Yii, о чем мы теснее писали в нашем блоге на прогре.
Сегодня я расскажу, как мы организовали хранение, конструкцию и управление конфигами наших сайтов, какие при этом получили превосходства. А также поведаю, как осуществляется деплой нашего плана в разных окружениях.

Конфиги

Для осуществления настройки сайтов мы применили следующую конструкцию конфигов в Yii:

protected/config
		/console 
			/config.php
			/import.php
			/cache.php
			/log.php
			…
		/mobile
			/config.php
			/import.php
			/cache.php
			/log.php
			…
		/sites  
			/alawar.ru.php
			/iphone.alawar.ru.php
			/ipad.alawar.ru.php
			/site.php
			…
		/test
			/config.php
			/import.php
			…
		/web
			/config.php
			/import.php
			/log.php
			…
		/~server
			/amqp.php
			/crontab.txt
			/db.php
			/eauth.php
			/mongo.php
			/redis.php
			/smsgate.php
			/services.php
			/comment.php			
			…

Все конфигурационные файлы были разбиты на категории согласно их назначению:

  • web/config.php — конфиг, содержащий настройки и параметры всеобщие для всех web-сайтов
    <?php
    return array(
    	'preload' => array( 'log' ),
    	//список подключаемых файлов
    	'import' => require(dirname(__FILE__) . '/import.php'),
    	'components' => array(
    		…
    		//параметры подключения к MySql
    		'db' => require(dirname(dirname(__FILE__)) . '/server/mysql.php'),
    		//параметры подключения к Redis
    		'redis' => require(dirname(dirname(__FILE__)) . '/server/redis.php'),
    		//параметры подключения к Mongo
    		'mongo' => require(dirname(dirname(__FILE__)) . '/server/mongo.php'),
    		//настройки логгирования
    		'log' => require(dirname(dirname(__FILE__)) . '/web/log.php'),	
    		//настройки компонента комментариев
    		'comment' => require(dirname(dirname(__FILE__)) . '/server/comment.php'),
    		//настройки RabbitMQ
    		'amqp' => require(dirname(dirname(__FILE__)) . '/server/amqp.php'),
    		//настройки авторизации через соц. сети
    		'eauth' => require(dirname(dirname(__FILE__)) . '/server/eauth.php'),
    		…
    	),
    	'params' => array(
    		//параметры доступа к разным сторонним сервисам
    		'services' => require(dirname(dirname(__FILE__)) . '/server/services.php'),
    		//параметры доступа к sms-шлюзу
    		'smsgate' => require(dirname(dirname(__FILE__)) . '/server/smsgate.php'),
    		…
    	)	
    );
    
  • site/{site.ru}.php — итоговый конфиг для сайта {site.ru} (специфичные настройки всеобщий конфиг web/config.php):
    return CMap::mergeArray(
    	array(
    		'basePath' => dirname(__FILE__) . DIRECTORY_SEPARATOR . '..'. DIRECTORY_SEPARATOR . '..',
    		'name' => 'Site',
    		'theme' => 'site',
    		'host' => 'site.ru',
    		'language' => 'ru',
    		//модули site.ru
    		'modules' => array(
    			…
    		),
    		//модули site.ru
    		'controllerMap' => array(
    			…
    		),
    		//спецефичные компоненты для site.ru
    		'components' => array(		
    			…
    		),
    		// application-level parameters that can be accessed
    		// using Yii::app()->params['paramName']
    		'params' => array(
    			//runtime параметры
    			//например:
    			//Yii::app()->params['runtimeData']['css'] - путь к минифицированному css сайта 
    			//Yii::app()->params['runtimeData']['js'] - путь к минифицированному js сайта
    			'runtimeData' => @include(dirname(__FILE__).'/runtime/sites/site.ru.php'),
    			'adminEmail' => 'admin@site.ru',
    		),
    	), require(dirname(dirname(__FILE__)).'/web/config.php')
    );
    

    Такой подход к образованию итогового конфига сайта разрешает легко подключать новые сайты и довольно эластично их настраивать.

  • console/config.php — конфиг для консольного приложения, по структуре схож с web/config.php, но он имеет свои импорты, настройки логирования, подключаемые компоненты и др.
  • test/config.php — конфиг для тестового окружения

Спецификой конструкции конфигов является то, что в protected/~server сконцентрированы «сереверозависимые» параметры и настройки, которые хранятся в отдельных репозиториях под всякий сервер(~server — это каждого лишь симлинка на чекаут одного из репозиториев). Такая конструкция разрешает легко, стремительно и без костылей разворачивать план в разном окружении.

Деплой

В данный момент у нас план может быть развернут на 3-х серверах:

  • dev-сервер — сервер, на котором ведется разработка
  • test-сервер — сервер, на котором запускаются тесты
  • prod-сервер — продакшн

Соответственно, под всякий сервер заведен свой репозиторий с конфигами:

  • dev-config
  • test-config
  • prod-config

При развертывании плана (мы это делаем средсвами jenkins и phing) мы легко указываем, какую ветку и какой репозиторий с конфигами поднять:

#развертывание ветки task-xx в dev-окружении
phing -Dbranch=task-xx -Dconfig=dev-config deploy
#развертывание плана на продакшн сервере
phing -Dbranch=prod -Dconfig=prod-config deploy

Вот, что делает при этом phing:

<!-- Таск по развертыванию плана -->
<target name="deploy" depends="-get-properties">
		<!-- Путь к директроии, в которой развертывается план -->
		<mkdir dir="${deploy.path}" />
		<!-- Путь к директроии, в которой будет расчекаучена ветка репозитория с кодом плана -->
		<mkdir dir="${deploy.path}/application" />
		<!-- Путь к директроии, в которой будет расчекаучена репозиторий с конфигами -->
		<mkdir dir="${deploy.path}/config" />

		<echo msg="checkout application and config..." />

		<!-- Чекаут ветки -->
		<exec
			command="bzr co ${bzr.branch.path} ./"
			dir="${deploy.path}"
			checkreturn="FALSE"
			returnProperty="bzr.co.return"
			outputProperty="bzr.co.out"
		/>
		<if>
			<!-- Если ветки не существует, создаем её, пачкую от ветки транк -->
			<equals arg1="${bzr.co.return}" arg2="3" />
			<then>
				<exec command="bzr co ${bzr.trunk.path} ./" dir="${deploy.path}/application"  />
				<exec command="bzr switch -b ${bzr.branch.path}" dir="${deploy.path}/application"  />
			</then>
		</if>

		<!-- Чекаут репозитория с конфигами -->
		<exec command="bzr co ${bzr.config.path} ./" dir="${deploy.path}/config"  />

		<!-- Настройка прав доступа к папке runtime -->
		<chmod file="${deploy.path}/application/protected/runtime" mode="0777" />

		<!-- Создание симлинки на конфиги -->
		<exec command="ln -s ${deploy.path}/config/server server"  dir="${deploy.path}/application/protected/config/" level="info"/>

		<!-- Создание симлинки на php error log -->
		<exec command="ln -s ${php.error.log.path} phplog"  dir="${deploy.path}/application/protected/runtime/" level="info"/>

		<!-- Для всякого сайта генерация минифицированного css и js и  прописывание путей к ним в protected/runtime/sites/{site.ru.php} -->
		<exec command="php ${deploy.path}/application/protected/yiic deploy data=css" />
		<exec command="php ${deploy.path}/application/protected/yiic deploy data=js" />
		<!-- Генерация карты шардов redis и mysql -->
		<exec command="php ${deploy.path}/application/protected/yiic deploy data=shardmap" />
	</target>

Таким образом, позже развертывания конструкция каждого плана становится дальнейшей:

application/ #чекаут репозитория с кодом плана
	protected/
		…
		config/
			…
			~server/ #симлинка на config/server
			…
		…
	public/
	…
config/ #чекаут репозитория с конфигами
	…
	server/
	…

Итого

Применяемая нами конструкция конфигов дозволила:

  • легко разворачивать и конфигурировать новые сайты
  • автоматизировать деплой плана
  • легко разворачивать план в разных окружениях
  • иметь возмож

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB