I have configured ansible-pull successfully in a Amazon ec2 environment , the Web Tier is getting a new release every time we commit to the Master Branch on GitHub.
The problem is that ansible-pull is configured to run through a cronjob the same time on all servers in the Web Tier, that means when there is a new release all servers will pull down the new config at the same time, de-register themselves from the Elastic Load Balancer causing a service outage .
I was thinking to run ansible in push mode just to connect to the web servers and “activate” ansible-pull one by one by specifying the number of forks in the push mode but was wondering what other users with the same case scenario are doing.
I’m not 100% sure, but I imagine this would be a great job for AWX. It seems to me that you could make the pull an API call to AWX that tells AWX that the node is ready for configuration. Then AWX takes care of the serialization for you.
Alternatively, you could just try doing push. If you’re purposefully only wanting a certain numbers to be changed at once anyway, you wouldn’t be worried too much about scale.
our platform is cloud based , the number of servers are relatively small at the moment but we expect to expand as our business grow and also we want to be prepared for the holidays high traffic season. Pull mode seems to works better with autoscaling and make make things relatively simpler and quicker. The push model is the method we are currently using but seems to be slower in comparison to pull mode.
didnt’ had a chance to look on AWS but at the moment we would like to avoid it because of cost reasons and because we don’t like the idea of having a “server” for configuration.
AWX’s autoscaling callback is designed exactly for this.
When a node is spun up via autoscaling it can do a one-line curl request to the AWX server to request the most up to date configuration, and then you still benefit from centralized logging, error reporting, graphical/database inventory management, and all of those things.
You can email us at support@ansibleworks.com if you have questions getting going with that, but you can also see the PDF documentation about the callback feature.
The number of simultaneous jobs is also controllable, and can be easily tuned so nodes get in line to be configured automatically at any rate you like.
At my $DAYJOB, we’re also using ansible in pull mode. However, instead of cron, we run it under upstart, and have an “exec sleep 601”. So if the play runs for X seconds, then the next run will be 601+X seconds later. X varies a bit naturally, plus the upstart script starts running at boot, so you have a natural splay. This avoids all hosts connecting to the git server at the same time, and reconfiguring themselves at the same time.
we have our own API on our servers, where we initiate a pull request.
it can be very simple to create if thats all that is needed, only a few lines in a python or php script and your going. Just make sure to make it secure via encryption somehow.
But yea, ansible push to pull is also an option if you already have SSH keys setup.