Jaan Paljasma | Tech Blog

For quite a while now I have been trying to exploit AWS OpsWorks to deploy software updates to our MetaSearch Gateway with less manual work. Before using OpsWorks, I built AWS servers from custom AMI, deployed app using git push to remote, and remote deployment hook pulled latest code updates to a folder; and if there were any secondary servers, these were updated with rsync. Now, AWS OpsWorks is great set of tools, based on famous Chef (currently 11.4 is supported). With little efforts I was able to include and configure necessary PHP extensions to a default PHP Web app: APC memcached Mongo Geoip Since AWS supports also elastic load balancer, I have two 24/7 instances running behind ELB, and third server (load-based) waiting for load to increase. Deployments are quite easy, with a push of a button, code is pulled from remote git and symlinks are updated. Sounds good? Well, too good to be true. By default, after deploying your app, Apache restarts itself; and naturally this c

The MongoDB Management Service  Backup announced earlier in May provides excellent backup and restore capabilities for your MongoDB replica set cluster. Setting up MongoDB backup is quite easy: Sign Up for service, Provide credit card details Install and configure agent In ~ 10 minutes your replica set is backed up and backup agent starts transferring the oplog data to backup mothership. Price for snapshot creating and storage is negligible, compared to the price ($2/GB) for oplog processing. For example, previous invoice was $0.89 for 330GB Snapshot storage, $0.65 for 71GB for snapshot create and $155 for 77GB of oplog traffic.  After analyzing my application, I figured out that most of the traffic was caused by two collections: metalog - 1GB capped collection which stores every API request with details opcounters - this stores various opcounters; every minute new document is created and $inc operator increases various counter(s) by one, depending on action, e.g. db.o