Category: Development (page 2 of 2)

Running Ruby on Rails on a production server – The evolution of our solution.

A bit over a year ago, OSU Libraries web development team first started toying with Ruby on Rails. Since that time we have established it as our language of choice for any new project. For me, the switch to Ruby has been absolutely outstanding. For the most part Ruby makes things so much easier.  It tends to get out of my way and let me focus on the application I’m trying to write and not the syntax of the language.  Heck, even running a local development copy of a web application is easy!  In PHP you need to have MAMP (or some other apache installation) set up and configured, point it to the directory, set up a new virtual host….guh!  I just want to run my application real quick to check something. In rails it’s as simple as “rails s” on the command line.

But what happens when you want to take that rails application that you wrote on your laptop and push it to a production web server?  It turns out that this is an incredibly complex thing. So many options can lead to confusion and complexity. For us, it took a progression from one method to another.  I’m by no means saying that our solution is the best or even that it’s finished yet, but maybe our progression will provide some insight for someone else out there.

Continue reading

Upgrading Elastic Search from 0.18.6 to 0.19.11

Two issues in Elastic Search recently came up, moving our Elastic Search data to a different server, and upgrading our Elastic Search instance from ES 0.18.6 to ES 0.19.11. All the while, new data was pouring in, and we didn’t want to lose it, and we didn’t want to cause much downtime. The motivation for doing all of this was that our statistics queries were coming back too slow, bogging down the system, and would sometimes crash our DSpace server if you were unlucky, requiring the SysAdmin or DevOps to come to the rescue and restart Tomcat. The users were not happy with that arrangement.

We had a food party at work where I, the DSpace Developer, and Travis, the SysAdmin found that we would have more fun drawing on the whiteboard about how to go about the move to the new Elastic Search architecture, as opposed to just talking about food, and how someone will be dearly missed.

So our Before State was that we had two applications, DSpace-Production and DSpace-Staging, that both produced and consumed Elastic Search data. The Elastic Search master instance lived on DSpace-Staging, and thus our Production application was very dependent on our Staging instance. At one time, the staging server also housed all of our Dark-Archive files, which required tons of Disk I/O, especially during disk backup periods, which could end up halting our production system. Not good.

Continue reading

Newer posts