Немного высокого

Gear — «движок» Openshift, собственно среда исполнения вашего приложения. При бесплатной регистрации сразу дают три. Собственно говоря об устройстве можно ничего и не знать. Но это вредно.

1. Имеется определенная структура каталогов. Для вашего приложения отведен ~/app-root.

типа ls

build-dependencies -> runtime/build-dependencies
data
dependencies -> runtime/dependencies
logs
repo -> runtime/repo
runtime

Собственно говоря интересны data и repo. Забавная деталь три каталога являются ссылками на подкаталоги runtime, а runtime/data — линком на data в текущем каталоге. runtime/.state содержит текущее состояние gear'a: started, idle, deploing.

2. Все адреса, пароли, каталоги и прочее содержаться в переменных окружения, с ними то и предстоит работа. Подробно переменные описаны здесь.

Теперь к земле поближе

Вообще существует два основных варианта установки приложений.

1. Для разработки. В это случае содержимое вашего репозитория и содержимое каталога ~app-root/repo совпадают. Вы разворачиваете приложение у себя, вносите правки заталкиваете в облако и там запускаете.
(пример ниже).

2. Если вы заняты в основном эксплуатацией приложения и вам достаточно иметь только доступ к конфигурации, установку производят с помощью скриптов из ~/myapp/.openshift/action_hooks/
Скриптов несколько pre_buld, build, deploy, post_deploy. Вообще писать их можно на bash, perl, python, ruby и т д. Задача этих скриптов:

— выкачать и распаковать приложение;
— проверить живость БД;
— подключить конфиги;
— наложить патчи, если надо;

Половина скриптов на практике не делают ничего. Скрипты вы пишите сами. Вам и карты в руки. В отличие от первого случая, данные ставятся в ~/app-root/data, на них делаются ссылки, а вам попадают при клонировании пустые каталоги (git не терпит пустоты, поэтому там заглушки — файлы .gitkeeper — они собственно просто содержимым и работают).

3. Собственно возможность отрегулировать что именно вы будете править. а что " так работает" — большое удобство.

Но посмотрим на практике.

На примере

Для примера возьмем LAMP. Сам LAMP на PaaS OpenSift уже в лучшем виде. Я выбрал vTigerCRM (SalesPlatform). Чем отличаются такие приложения? После развертывания запускаются скрипты конфигурации, которые в интерактивном режиме просят ввести настройки подключения к БД и другие параметры. Но мы помним, что OpenShift оперирует переменными окружения, то есть приложение должно получить значения этих переменных, чего бы другого оно не хотело. Плюс к этому, необходимо предать нужные параметры php. Доступа к головному php.ini нет, остается .htaccess.

Итак создаем LAMP (для варианта 1).

$ rhc app create spddevel php-5.3 mysql-5.5
clone произойдет автоматом, поэтому

$ cd spdevel

Здесь уже есть репозиторий, поэтому:

rm index.php
git add .
git commit -m "remove original index.php"

$ wget http://downloads.sourceforge.net/project/salesplatform/salesplatform-vtigercrm-6.4.0-201512.tar.gz

$ tar --strip-components=1   xf sales-platform-vtigercrm-6.4.0-201512.tar.gz -C ~/spdevel
rm salesplatform-vtigercrm-6.4.0-201512.tar.gz

Теперь в нашей папке с репозиторием полностью развернутый каталог. Остается сделать две вещи. Наложить патч, для замены оригинального ввода параметров с клавиатуры переменными openshift.

Собственно patch:

--- Index.php	2015-12-23 15:44:07.000000000 +0300
+++ Index.php.new	2016-01-13 09:00:18.272322263 +0300
@@ -98,11 +98,11 @@
 		$timeZone = new UserTimeZones();
 		$viewer->assign('TIMEZONES', $timeZone->userTimeZones());
 
-		$defaultParameters = Install_Utils_Model::getDefaultPreInstallParameters();		
-		$viewer->assign('DB_HOSTNAME', $defaultParameters['db_hostname']);
-		$viewer->assign('DB_USERNAME', $defaultParameters['db_username']);
-		$viewer->assign('DB_PASSWORD', $defaultParameters['db_password']);			
-		$viewer->assign('DB_NAME', $defaultParameters['db_name']);
+	#	$defaultParameters = Install_Utils_Model::getDefaultPreInstallParameters();		
+		$viewer->assign('DB_HOSTNAME', $_ENV['OPENSHIFT_MYSQL_DB_HOST']);
+		$viewer->assign('DB_USERNAME', $_ENV['OPENSHIFT_MYSQL_DB_USERNAME']);
+		$viewer->assign('DB_PASSWORD', $_ENV['OPENSHIFT_MYSQL_DB_PASSWORD']);			
+		$viewer->assign('DB_NAME', $_ENV['OPENSHIFT_APP_NAME']);
 		$viewer->assign('ADMIN_NAME', $defaultParameters['admin_name']);	
 		$viewer->assign('ADMIN_LASTNAME', $defaultParameters['admin_lastname']);	
 		$viewer->assign('ADMIN_PASSWORD', $defaultParameters['admin_password']);	

Сохраните его в любой файл, скажем db.patch. Далее:

$ patch modules/Install/views/Index.php db.patch

Теперь подсунем нужные параметры php.

vi  .htaccess

Options -Indexes
php_value date.timezone 'Europe/Moscow'
php_value error_reporting 22519
php_value max_input_vars 100000
php_value max_execution_time 600
php_flag log_errors on
php_flag display_errors off
php_flag allow_call_time_pass_reference on


$ git status
$ git add .
$ git commit -m "All ready to deploy"
$ git push

Все. Запускаем наш сайт spdevel-ourdomain.rhcloud.com.

Доходим до Шага 4 установки:



Видно, что параметры БД уже введены. Все, заполняем данные на администратора, далее все тривиально.

То же самое в один шаг. В своем домашнем каталоге:

$ rhc app create spdevel php-5.3 mysql-5.5 --from-code=https://github.com/zirf0/openshift-salesplatform

И вы тоже получите spdevel-ourdomain.rhcloud.com. И каталог spdevel/.

Вариант 2. Тут мудрить не будем, итак понятен принцип.

$ rhc app create sp php-5.3 mysql-5.5 --from-code=https://github.com/zirf0/openshift-salesplatform-example

cd sp/

ls -al

Скромненько так, самого приложения нет, оно там в ~app-root/data/current (подкаталог добавлен для удобства),

Собственно, в чем удобство такого варианта:

.openshift/
+-- action_hooks
¦   +-- build
¦   +-- deploy
¦   +-- post_deploy
¦   L-- pre_build
+-- config
¦   +-- db_conf.patch
¦   L-- .htaccess
...

Скрипты исполнятся на платформе, данные можно разместить в config, то есть при работе с той же базой sql-скрипт можно разместить в config, у WordPress 4 самое нужное — плагины и темы доступны, то есть в чем то такая схема удобнее. Собственно в содержимое db_cong.patch и .htaccess выше.

Резюме

Чем удобна PaaS (перед IaaS) избавляет разработчика от работы сисадмина — не нужно возится с настройкой. Да, при промышленном развертывании сисадмин просто необходим. Одно дело прочитать кое-как написанную инструкцию, другое — понимать как работает. Пусть каждый своим делом занимается.