Jaan Paljasma | Tech Blog

AWS OpsWorks. Image courtesy of Amazon Web Services Does AWS OpsWorks drive you nuts with its auto-update feature eating up your resources and messing up your deployments? There is now a solution to mitigate that, with manageable agent updates. This recently-added feature allows you to select if you'd like to opt in for agent auto-updates or would you like to stick to a specific (and tested by you) version of AWS OpsWorks. Go to  Add Stack  page, in the  OpsWorks Agent Version  field, choose  Manual update  and pick a version. Try this out today by editing one of your stacks to specify an agent version (be sure to do this in your test environment first). This updates the agents and cookbooks on all online instances in that stack immediately. Click the  Changelog  link to learn about the changes that come with the new agent. You can also update the agent on a single instance instead of the entire stack by selecting a version on the...

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