Tag: openshift

Custom cron interval on openshift cron cartridge

Openshift v1 does not allow custom cron times, cronjobs can only be placed in the folders minutely, hourly, daily, weekly and monthly.

You can use the script below to run a cronjob every 5 minutes. You can vary the timestamp by modifying the +4 parameter. The script must be placed in the minutely folder. Here it will run every minute, and write a timestamp to a temporary file. It will check the creation date of the file, and if it is more than 4 minutes ago the cronjob will run. After that the file will be removed and recreated via the touch command.

The example below will run a PHP cronjob.

#!/bin/bash
if [ ! -f $OPENSHIFT_DATA_DIR/last_run ];
then
    touch $OPENSHIFT_DATA_DIR/last_run
    cd $OPENSHIFT_REPO_DIR;php cronjob.php RememberCron
else
 if [[ $(find $OPENSHIFT_DATA_DIR/last_run -mmin +4) ]]; then #run every 5 mins
   cd $OPENSHIFT_REPO_DIR;php cronjob.php RememberCron
   rm -f $OPENSHIFT_DATA_DIR/last_run
   touch $OPENSHIFT_DATA_DIR/last_run
  fi  
fi

Leave a Comment

Combining your own local git repository with Openshift for deploying

On Openshift you can deploy a multitude of applications. You do this by adding the code to a git repository and pushing the result to the Openshift servers. In some cases, when you are already developing the code and you don’t want to manually copy the changes to the openshift checkout it is cumbersome to keep this in sync.

Remote git url during creation

The simplest solution is to, during the creation of your application, specify a remote git url to store the app data in. If for some reason you do not want that (repository is not public for example), there is another way to fix this.

Local branch

In this solution, a branch on your local repository will be used to push the code to the master of the Openshift repository. This solution is based on a Stack Overflow post.

Application creation

First, create the Openshift application using the normal flow and checkout the git repository linked to this application. We do this, because we want the contents of the .openshift folder, this is used by Openshift for configuration of the Cartridge. We will later overwrite the data in this repo with our own local git repository.

Preparing the local branch

In your own git repository with the existing code, branch from the master (or any other branch you want to openshift code to be based on):

> git checkout -b openshift
> git remote add openshift <openshift-git-repo-url>

We have just created a local branch called openshift, and added a remote repository called openshift. We will be committing changes to the local branch and pushing them to the openshift repo.

Now copy the .openshift folder from the checkout done earlier and copy this to your local openshift branch. After this modify any configuration you may have to match the openshift application (database, log locations, etc.). Commit your changes.

Pushing to openshift repo

We will now push the local branch to the openshift repo. This is not as simple as executing a git push, because the local branch is called openshift, but on the remote repository we want to update the master branch.

> git push openshift HEAD:master -f

This command will overwrite the remote repo with all local changes, because of the the -f flag. The HEAD:master parameter will tell git to push the branch to the master of the remote repo.

For any subsequent commits there is no need to specify -f again, because the repositories are now from the same source.

Leave a Comment

How to configure a writable upload folder on openshift for a PHP cartridge

When creating a Openshift gear for a GNU Social deployment I found that the files could not be uploaded. I needed
to create writable folder for the webserver to place the files. Openshift allows you to update the code via a git repository, but I did not want to
upload the files directly into the git repository on the server, because that would introduce problems everytime I updated the code. Openshift
also offers a separate dir for user data files and preferably the files are stored there. After some tinkering I found a solution.
There are some specific notes for Windows users at the end of the post.

The GNU social package has two folders which it uses for storing uploaded files /avatar and /file. I will be explaining how to perform this for
both folders, but you can execute this for any type of package you’d like, not only GNU social. The principle is the same.

The solution involves two separate steps: preparation and scripting. Some of the paths in the explanation start with /var/lib/openshift/[your app id]/, in this
case you need to replace the value [your app id] with the identifier of your app. You can find the value, if you don’t know it, by executing the following
command when signed into the console on the server:

echo $OPENSHIFT_DATA_DIR

Preparation

Make sure that the folder(s) you want to make world-writable for the uploads are not in version control (if they are, you might run into problems because then you are
basically updating version controlled folders when running the scripts. There is probably a way around that, but I tried to stay away from such a solution).

First, ssh into your server and execute the commands below, this will create the upload folders in the data part where the files can be uploaded:

mkdir $OPENSHIFT_DATA_DIR/avatar
mkdir $OPENSHIFT_DATA_DIR/file

Second, create the links into the repository and make them world-writable. The ln command does not really support environment variables, this is why
we are using the absolute paths here.

ln -s /var/lib/openshift/[your app id]/app-root/data/avatar /var/lib/openshift/[your app id]/app-root/runtime/repo/avatar
ln -s /var/lib/openshift/[your app id]/app-root/data/file /var/lib/openshift/[your app id]/app-root/runtime/repo/file
chmod -R o+rw $OPENSHIFT_REPO_DIR/avatar
chmod -R o+rw $OPENSHIFT_REPO_DIR/file

This completes the manual preparation.

Scripts

When performing a code update via git push we need to temporarily remove the link and recreate it again. Openshift offers the possibility to have scripts
executed in the different steps of deploying the code. In the folder in your local cloned git repository there is a folder .openshift/action_hooks. Two
files must be created here, pre_build and post_deploy. For more background information read the manual.

On Linux, execute chmod x .openshift/action_hooks/* to make the scripts executable. For Windows, see the special note at the end of the post.

pre_build

Remove the links:

#!/bin/bash
rm -f $OPENSHIFT_REPO_DIR/avatar
rm -f $OPENSHIFT_REPO_DIR/file

post_deploy

Re-create the links and make sure that they are world-writable:

#!/bin/bash
ln -s /var/lib/openshift/[your app id]/app-root/data/avatar /var/lib/openshift/[your app id]/app-root/runtime/repo/avatar
ln -s /var/lib/openshift/[your app id]/app-root/data/file /var/lib/openshift/[your app id]/app-root/runtime/repo/file
chmod -R o+rw $OPENSHIFT_REPO_DIR/avatar
chmod -R o+rw $OPENSHIFT_REPO_DIR/file

Notes for Windows

The scripts in the repository need to have the correct line endings and have the execution bit set. The manual
explains how to do this for Windows. In short execute in the root of your local clone of the git repository after creating the build hooks:

git config core.autocrlf input # use `true` on Windows
git config core.safecrlf true
git update-index --chmod=+x .openshift/action_hooks/pre_build
git update-index --chmod=+x .openshift/action_hooks/post_deploy

Message error: .openshift/action_hooks/*: does not exist and —remove not passed

.openshift/action_hooks/*: does not exist and --remove not passed

I got this message when attempting to execute the update-index command on a wildcard. When providing the individual filenames it worked.

Leave a Comment

Install Node-Red on Openshift

Node-Red is a visual tool for wiring the Internet of Things. It allows you to define flows, triggers and outputs
that process data. This can be used in all kinds of applications, such as home automation or security. I wanted to use
it to implement remote monitoring on my private server I have installed at home. To be able to do this I created a free gear
at openshift.com. The reason for selecting Openshift was basically the three free gears they offer.

Create the gear in OpenShift

For this howto I assume that you have created an account at openshift.com and have used the following webpage to create a
Node.js instance: Node.js Application Hosting @ Openshift. In short, you can use the command:

rhc app create MyApp nodejs-0.10

or via a webflow, as explained in this blogpost.

Clone via git

In order to be able to checkout the code that Openshift will execute when the applications starts you first need to configure your SSH
key at the settings.

After the SSH public key is set up, use the git clone ssh://xxx@appname-openshiftname.rhcloud.com command to clone the
source files, you can find this URL in the app details.

Your repository will have the following format:

node_modules/            Any Node modules packaged with the app 
deplist.txt              Deprecated.
package.json             npm package descriptor.
.openshift/              Location for OpenShift specific files
    action_hooks/        See the Action Hooks documentation 
    markers/             See the Markers section below
server.js                The default node.js execution script.

File updates

We will update two files: package.json and server.js. First replace the contents of package.json to:

package.json

{
  "name": "Node-Red",
  "version": "1.0.0",
  "description": "Node RED on Openshift",
  "keywords": [
    "OpenShift",
    "Node.js",
    "application",
    "node-red"
  ],
  "engines": {
    "node": ">= 0.6.0",
    "npm": ">= 1.0.0"
  },

  "dependencies": {
    "express": "4.x",
    "node-red": ">= 0.9
    "atob": "1.1.2",
    "basic-auth-connect": "1.0.0"
  },
  "devDependencies": {},
  "bundleDependencies": [],

  "private": true,
  "main": "server.js"
}

The author and homepage fields are provided by default in the example, but I left them out. This file defines the different dependencies for running
the server. The current dependency for node-red points to the last stable release. Since node-red is still in beta, you might sometimes want to use the
latest version from github. More on that at the end of the article.

server.js

The default server.js file needs to be replaced with a version that will run node-red.

var http = require('http');
var express = require("express");
var RED = require("node-red");
var atob = require('atob');

var MyRed = function() {

    //  Scope.
    var self = this;


    /*  ================================================================  */
    /*  Helper functions.                                                 */
    /*  ================================================================  */

    /**
     *  Set up server IP address and port # using env variables/defaults.
     */
    self.setupVariables = function() {
        //  Set the environment variables we need.
        self.ipaddress = process.env.OPENSHIFT_NODEJS_IP;
        self.port      = process.env.OPENSHIFT_NODEJS_PORT || 8000;

        if (typeof self.ipaddress === "undefined") {
            //  Log errors on OpenShift but continue w/ 127.0.0.1 - this
            //  allows us to run/test the app locally.
            console.warn('No OPENSHIFT_NODEJS_IP var, using 127.0.0.1');
            self.ipaddress = "127.0.0.1";
        };



        // Create the settings object
        self.redSettings = {
            httpAdminRoot:"/",
            httpNodeRoot: "/api",
            userDir: process.env.OPENSHIFT_DATA_DIR
        };

        if (typeof self.redSettings.userDir === "undefined") {
            console.warn('No OPENSHIFT_DATA_DIR var, using ./');
            self.redSettings.userDir = "./";
        }
    };

     /**
     *  terminator === the termination handler
     *  Terminate server on receipt of the specified signal.
     *  @param {string} sig  Signal to terminate on.
     */
    self.terminator = function(sig){
        if (typeof sig === "string") {
           console.log('%s: Received %s - terminating app ...',
                       Date(Date.now()), sig);
            RED.stop();
           process.exit(1);
        }
        console.log('%s: Node server stopped.', Date(Date.now()) );
    };

    /**
     *  Setup termination handlers (for exit and a list of signals).
     */
    self.setupTerminationHandlers = function(){
        //  Process on exit and signals.
        process.on('exit', function() { self.terminator(); });

        // Removed 'SIGPIPE' from the list - bugz 852598.
        ['SIGHUP', 'SIGINT', 'SIGQUIT', 'SIGILL', 'SIGTRAP', 'SIGABRT',
         'SIGBUS', 'SIGFPE', 'SIGUSR1', 'SIGSEGV', 'SIGUSR2', 'SIGTERM'
        ].forEach(function(element, index, array) {
            process.on(element, function() { self.terminator(element); });
        });
    };

    /*  ================================================================  */
    /*  App server functions (main app logic here).                       */
    /*  ================================================================  */

    /**
     *  Create the routing table entries + handlers for the application.
     */
    self.createRoutes = function() {
        self.routes = { };

        self.routes['/asciimo'] = function(req, res) {
            var link = "http://i.imgur.com/kmbjB.png";
            res.send("<html><body><img src='" + link + "'></body></html>");
        };
    };

    /**
     *  Initialize the server (express) and create the routes and register
     *  the handlers.
     */
    self.initializeServer = function() {
        self.createRoutes();

        // Create an Express app
        self.app = express();

        // Create a server
        self.server = http.createServer(self.app);

        //setup basic authentication
        var basicAuth = require('basic-auth-connect');
        self.app.use(basicAuth(function(user, pass) {
            return user === 'test' && pass === atob('dGVzdA==');
        }));

        // Initialise the runtime with a server and settings
        RED.init(self.server, self.redSettings);
        console.log('%s is the userDir for RED', self.redSettings.userDir);

        // Serve the editor UI from /red
        self.app.use(self.redSettings.httpAdminRoot,RED.httpAdmin);

        // Serve the http nodes UI from /api
        self.app.use(self.redSettings.httpNodeRoot,RED.httpNode);

        // Add a simple route for static content served from 'public'
        //self.app.use("/",express.static("public"));

        //  Add handlers for the app (from the routes).
        for (var r in self.routes) {
            self.app.get(r, self.routes[r]);
        }
    };

    /**
     *  Initializes the sample application.
     */
    self.initialize = function() {
        self.setupVariables();
        self.setupTerminationHandlers();

        // Create the express server and routes.
        self.initializeServer();
    };

    /**
     *  Start the server (starts up the sample application).
     */
    self.start = function() {
        //  Start the app on the specific interface (and port).
        self.server.listen(self.port,self.ipaddress, function() {
            console.log('%s: Node server started on %s:%d ...',
                        Date(Date.now() ), self.ipaddress, self.port);
        });

        // Start the runtime
        RED.start();
    };
}

/**
 *  main():  Main code.
 */
var red = new MyRed();
red.initialize();
red.start();

This is a variation on the default server.js from OpenShift that initializes the RED server. In initializeServer node-red
is started. I have added Basic Authentication to prevent unauthorized users from accessing. To prevent having the password in plain-text
it is base64 encoded. Via base64encode.org you can encode your password and place it in the server.js file.

Git push

Once you have the files ready, commit the changes via git. Issue a git push remote command to update the remote
repository at Openshift. This will trigger some hooks at the server side and start the node server. The output will end in
something similar to:

remote: npm info ok 
remote: Preparing build for deployment
remote: Deployment id is d46d7d66
remote: Activating deployment
remote: Starting NodeJS cartridge
remote: Tue Sep 09 2014 03:09:49 GMT-0400 (EDT): Starting application 'red' ...
remote: -------------------------
remote: Git Post-Receive Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To ssh://xxx@red-xxx.rhcloud.com/~/git/red.git/
   6317488..2724c91  master -> master

You can now access your node-red instance at http://red-[openshift namespace].rhcloud.com:8000. The added port 8000
is required because the Openshift proxy currently does not support forwarding WebSockets via port 80. If you open
the website at port 80, it will show an error message that the connection to the server is lost. See below for a workaround.

Workaround Openshift Websockets

In order to be able to access node-red at port 80 (and save typing the port :8000 addition) I have created a work-around
for this. The portnumber is set fixed in the file public/red/comms.js, it is taken from location.port. I have created
a fork and a separate branch where the portnumber is fixed to 8000. This is available at github. In order to use it
you need to update the node-red dependency to the following line:

"node-red": "git://github.com/matueranet/node-red.git#067028b59917e98615c87985c02810c4828a25fa"

This also references a specific commit, so that the server is not automatically updated on an update before I decide
to do so.

Leave a Comment