OpenShift: some gear internals

Little high

Gear is the “engine” of Openshift, the actual execution environment of your application. With free registration immediately give three. In fact, the device can not know anything. But it is harmful.

1. There is a certain directory structure. ~ / App-root is reserved for your application.

type ls
')

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

Strictly speaking, data and repo are interesting. The fun part is that the three directories are links to the runtime subdirectories, and the runtime / data links to data in the current directory. runtime / .state contains the current state of the gear: a: started, idle, deploing.

2. All addresses, passwords, directories, etc. are contained in the environment variables, and then work is to be done with them. Details of the variables are described here .

Now closer to the ground

In general, there are two main options for installing applications.

1. For development. In this case, the contents of your repository and the contents of the ~ app-root / repo directory are the same. You deploy the application at home, edit it, push it into the cloud and launch it there.
(example below).

2. If you are mainly involved in the operation of the application and you only need to have access to the configuration, the installation is done using scripts from ~ / myapp / .openshift / action_hooks /
Several scripts pre_buld, build, deploy, post_deploy. In general, you can write them on bash, perl, python, ruby, and so on. The task of these scripts:

- deflate and unpack the application;
- check the liveliness of the database;
- connect configs;
- impose patches, if necessary;

In practice, half of the scripts do nothing. Scripts you write yourself. You and cards in hand. Unlike the first case, the data is put in ~ / app-root / data, links are made to them, and you get empty directories when cloning (git does not tolerate emptiness, therefore there are stubs - .gitkeeper files - they are just content and work) .

3. Actually the ability to adjust what exactly you will rule. and that "it works that way" is great convenience.

But let's look at the practice.

For example

For example, take LAMP. LAMP itself on PaaS OpenSift is already at its best. I chose vTigerCRM (SalesPlatform). What is the difference between such applications? After deployment, the configuration scripts are run, which interactively ask for the settings for connecting to the database and other parameters. But we remember that OpenShift operates with environment variables, that is, the application must receive the values ​​of these variables, whatever it wants. Plus, you need to give the necessary parameters php. Access to the head php.ini is not, it remains. Htaccess.

So we create LAMP (for option 1).

$ rhc app create spddevel php-5.3 mysql-5.5 clone  ,  $ cd spdevel 

There is already a repository here, so:

 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 

Now in our repository folder is a fully expanded directory. It remains to do two things. Put a patch to replace the original input of parameters from the keyboard with openshift variables.

Actually 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']); 

Save it to any file, say db.patch. Further:

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

Now we will drop the necessary parameters 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 

Everything. We start our website spdevel-ourdomain.rhcloud.com.

We reach the step 4 installation:



It can be seen that the database parameters have already been entered. Everything, we fill in the data on the administrator, further everything is trivial.

The same thing in one step. In your home directory:

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

And you also get spdevel-ourdomain.rhcloud.com. And the spdevel / directory.

Option 2. There will not be wise, so the principle is clear.

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

Modestly so, the application itself does not exist, it is there in ~ app-root / data / current (the subdirectory is added for convenience),

Actually, what is the convenience of this option:

 .openshift /
 Action── action_hooks
 │ ├── build
 │ ├─ deploy
 Post ├── post_deploy
 │ └── pre_build
 Config── config
 │ ├── db_conf.patch
 │ └── .htaccess
 ...

The scripts will be executed on the platform, the data can be placed in the config, that is, when working with the same database, the sql script can be placed in the config, WordPress 4 has the most necessary - plug-ins and themes are available, that is, this scheme is more convenient. Actually in the contents of db_cong.patch and .htaccess above.

Summary

What is convenient PaaS (before IaaS) eliminates the developer from the work of the system administrator - no need to mess around with the setting. Yes, with industrial deployment, sysadmin is a must. It's one thing to read some written instructions, another is to understand how it works. Let everyone do their own thing.