OpenShift: few gear internals

A little high


Gear is the “engine” of Openshift, the actual runtime of your application. With free registration immediately give three. Actually, you can not know anything about the device. But it is harmful.

1. There is a specific 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 funny part is that the three directories are links to the runtime subdirectories, and runtime / data is the link to data in the current directory. runtime / .state contains the current state of the gear: started, idle, deploing.

2. All addresses, passwords, directories, etc. are contained in environment variables, and 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 for yourself, make changes, push it into the cloud and launch it there.
(example below).

2. If you are mainly engaged in the operation of the application and you only need access to the configuration, the installation is performed using scripts from ~ / myapp / .openshift / action_hooks / Scripts with
several pre_buld, build, deploy, post_deploy. In general, you can write them in bash, perl, python, ruby, etc. The task of these scripts:

- download and unzip the application;
- check liveness of the database;
- connect configs;
- apply patches if necessary;

Half of the scripts do nothing in practice. 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 it, and you get empty directories when cloning (git does not tolerate voids, so there are stubs - .gitkeeper files - they actually just work and work) .

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

But let's see in 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, configuration scripts are launched, which interactively ask you to enter database connection settings and other parameters. But we remember that OpenShift operates with environment variables, that is, the application must get the values ​​of these variables, whatever else it wants. Plus, you need to betray the necessary php parameters. There is no access to the head php.ini, .htaccess remains.

So create a 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 folder with the repository is a fully expanded directory. It remains to do two things. Apply a patch to replace the original keyboard input 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 slip the necessary php options.

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 launch our website spdevel-ourdomain.rhcloud.com.

We get to Step 4 of the installation:



It can be seen that the database parameters have already been entered. Everything, fill in the data on the administrator, then 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 will also get spdevel-ourdomain.rhcloud.com. And the spdevel / directory.

Option 2. We won’t be smart here, 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 is not there, it is there in ~ app-root / data / current (a subdirectory is added for convenience),

Actually, what is the convenience of this option:

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

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

Summary


What is convenient PaaS (before IaaS) saves the developer from the work of the system administrator - no need to tinker with the configuration. Yes, with an industrial deployment, a sysadmin is a must. It’s one thing to read a written instruction, another thing is to understand how it works. Let everyone do their own thing.

Also popular now: