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.
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.
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, 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.
--- 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.
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.