You define a state in YAML and tell a host to execute the state with the state.apply execution module. On top of execution modules are state modules ( ). (Note: I replaced asterisks with tildes in the above example due to HN formatting.)
#Alfred and keepassx install#
You can send shell commands directly using cmd.run - salt 'web~' cmd.run 'yum -y install httpd' ), which are just Python modules that abstract the commands underneath and you can blast to machines, such as salt 'web~' pkg.install httpd to install Apache on all servers named web. The easiest way to learn Salt is by starting with execution modules (. They recently rewrote the tutorial, which is available here: It has been a very painful road to get this thing stable! It would be considerably easier if people weren't trying to nuke all my hard work while my back was turned.! As a result, the Jenkins folder on the master is now an SVN working copy with all the config files under version control, and a scheduled task runs daily to commit the changes. Basically lobotomised the server, and that was when we discovered we'd been backing up the build NODES, but not the MASTER itself! I was able to salvage some of the config and rebuilt the server on the latest version of Jenkins. He hadn't thought to restrict this to the build artefacts folders. I also recommend imaging your build nodes so they're quick and easy to deply, and BACK UP YOUR JENKINS CONFIG! :) When I came back from my Christmas break, it was to discover that the Jenkins server I had worked oh so hard on had been inadvertently trashed by one of the guys on my team the disk had run out of space, so he'd remoted onto the server, gone into the Jenkins folder and deleted everything older than a month. I cannot tell you how annoying it gets when a build fails because some tiny thing is out of alignment on a fresh build node.
Most importantly, ensure you can always build from a fresh checkout. It becomes much easier to manage than restricting builds to hostnames. This also means that if one node breaks and is unable to build, I just remove that label and Jenkins will stop scheduling builds on it. Use labels as much as possible I have our cluster set up so that builds that require dependencies are bound to label '' and I add/remove the labels from the build nodes as the dependencies are added. This way, the product and the steps required to build it are kept together, and are very unlikely to come out of sync.
We used to keep all our build scripts in a separate repository which would have to be checked out onto the build node in preparation invariably, the scripts never got updated. This meant that we couldn't run builds in parallel, and if an SVN operation were interrupted, the working copy would lock and would need to be manually cleaned up.įor complex builds, write a script that is kept in the root of the project, then after checkout, simply do. In the same vein, always use Jenkins version control our old build scripts used to shell out to svn.exe and run the checkouts that way, into a static folder. Jenkins can do almost everything either natively or via its extensive library of plugins. The best advice I can give is to use the Jenkins plugins wherever possible.
0 kommentar(er)
