When you push changes to OpenShift the service stops your application then builds and deploys the new code before starting the app back up again. This means your application is temporarily unavailable, and may be unnecessary depending on your changes. To avoid downtime, you can opt to hot deploy your code instead. In this blog post we'll look at how to do that for PHP applications, but many other cartridge types also support hot deployment.
Choosing a PaaS Without Application Scaling Doesn't Make Sense
While infrastructure node scaling can easily be done by many infrastructure management tools that are already in use, application scaling can only be done by the platform. It is the core capability of PaaS and a bit more complicated than infrastructure node scaling. Scaling applications involves scaling all the dependencies, including the data store, while also keeping data consistency and application availability. It is much easier said than done and very few platforms have done application scaling right.
Cloudy with a Chance of Data: Master-Slave Database Replication on OpenShift
Clouds provide some great mechanisms to scale your web applications, particularly as traffic expands or contracts. However, to do the same with your data it takes some work, a little pre-planning and a rather deep knowledge in how databases or your preferred storage mechanism works. Needless to say, data is hard. My job, however, is to try and make it a little less complicated and hopefully to keep the data all intact. To that end, I’ve been trying to get MySQL and MariaDB to work in a clustered arrangement within OpenShift.
Taking Advantage of Environment Variables in OpenShift PHP Apps
Environment variables (ENV) are an important aspect of OpenShift PaaS. PHP is one of the most prominent languages on OpenShift. In my blog post I want to show you how you can and should use environment variables to consume information from OpenShift.