{"action":"created","issue":{"url":"https://api.github.com/repos/rackerlabs/otter/issues/1413","labels_url":"https://api.github.com/repos/rackerlabs/otter/issues/1413/labels{/name}","comments_url":"https://api.github.com/repos/rackerlabs/otter/issues/1413/comments","events_url":"https://api.github.com/repos/rackerlabs/otter/issues/1413/events","html_url":"https://github.com/rackerlabs/otter/issues/1413","id":73459618,"number":1413,"title":"Document: How to handle keeping your Auto Scale Group up to date","user":{"login":"wirehead","id":653135,"avatar_url":"https://avatars.githubusercontent.com/u/653135?v=3","gravatar_id":"","url":"https://api.github.com/users/wirehead","html_url":"https://github.com/wirehead","followers_url":"https://api.github.com/users/wirehead/followers","following_url":"https://api.github.com/users/wirehead/following{/other_user}","gists_url":"https://api.github.com/users/wirehead/gists{/gist_id}","starred_url":"https://api.github.com/users/wirehead/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wirehead/subscriptions","organizations_url":"https://api.github.com/users/wirehead/orgs","repos_url":"https://api.github.com/users/wirehead/repos","events_url":"https://api.github.com/users/wirehead/events{/privacy}","received_events_url":"https://api.github.com/users/wirehead/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/rackerlabs/otter/labels/docs","name":"docs","color":"006b75"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-05-05T23:18:22Z","updated_at":"2015-05-06T01:52:08Z","closed_at":null,"body":"This is a general-purpose question, but since Auto Scale is the first place that people are going to encounter it, we need to write something up.\r\n\r\nThe right solution depends on differing user needs.  Some users want to have a master server that exists outside of the autoscaling group and sync that master server back.  Sometimes there is content that exists on the master server as files.  Other users will store any large files on Cloud Files and any other data in the database, so they don't need to update content by replicating a master server.\r\n\r\nOther users are content to store all of their working content in an external server (perhaps a github repo) and so they just need the server to connect to github and clone the config at startup.\r\n\r\nWe might also provide a quick python script that users could run that would cycle the servers in a group at a defined rate.\r\n\r\nDanny Cheung reports this config works:\r\n* Have a “master” server. It is outside of AS group\r\n* Configure master server accordingly\r\n* Take image and create AS Group\r\n* Install Lsyncd on master\r\n* Install the lsync-rsautoscale script (https://github.com/boxidau/lsync-rsautoscale)\r\n* Setup a cron job on master to run the script every minute\r\n\r\n@sam-falvo's suggestions:\r\nOne approach that I've used successfully with AWS in the past is to use a custom server image that, when it boots up, talks to a well-known job server, from which the slave receives its role and configures itself accordingly.\r\n\r\nOpenStack has an ability to place custom shell scripts (such as the kind that'd execute upon boot-up) on servers that are spun up; they're called \"personalities.\"  This is another option.  (I would have killed for this feature when trying to use AWS autoscaling many years ago.)\r\n\r\nAnother approach is to just have specialized images for the spawned servers, and adjust your launch-config over time as it's needed.  This requires a bit more preplanning (you have to take the time to build each kind of image you need), but it's probably the simplest approach to take, and definitely results in the fastest start-up time for new servers (no need to automatically install dependencies on first boot, no need for \"first boot\" detection logic to back it, etc.)."},"comment":{"url":"https://api.github.com/repos/rackerlabs/otter/issues/comments/99285623","html_url":"https://github.com/rackerlabs/otter/issues/1413#issuecomment-99285623","issue_url":"https://api.github.com/repos/rackerlabs/otter/issues/1413","id":99285623,"user":{"login":"manishtomar","id":758529,"avatar_url":"https://avatars.githubusercontent.com/u/758529?v=3","gravatar_id":"","url":"https://api.github.com/users/manishtomar","html_url":"https://github.com/manishtomar","followers_url":"https://api.github.com/users/manishtomar/followers","following_url":"https://api.github.com/users/manishtomar/following{/other_user}","gists_url":"https://api.github.com/users/manishtomar/gists{/gist_id}","starred_url":"https://api.github.com/users/manishtomar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/manishtomar/subscriptions","organizations_url":"https://api.github.com/users/manishtomar/orgs","repos_url":"https://api.github.com/users/manishtomar/repos","events_url":"https://api.github.com/users/manishtomar/events{/privacy}","received_events_url":"https://api.github.com/users/manishtomar/received_events","type":"User","site_admin":false},"created_at":"2015-05-06T01:52:07Z","updated_at":"2015-05-06T01:52:07Z","body":"I like what @sam-falvo suggested: Every server created should know how to update itself with current data. That data could be anywhere, some fixed master server, cloud files, cloud DB, anything. "}}