puppet camp london june 2017 Masterless puppet
10 June 2017 · Filed in Development Infrastructure
Puppetcamp, London
This week I attended and spoke again, at PuppetCamp London 2017. We enjoyed some interesting talks off the back of the State of Devops report, and the DevOps Enterprise Summit.
Whilst enjoying the views of london, I listened to several people from Puppet in the morning.
View from Altitude, London
A chord was struck with me when Dion Hinchcliffe was mentioned in conjunction with working practices inside Enterprise organisations. Specifically around Silos and team dynamics. Having worked in fast-paced and effective teams, I do feel a slight discomfort when working in a team that has not got to this level yet. Environment and size of team are key to the performance of a team, both of which are heavily influenced by the management.
Anyway, getting back on track, I spoke about Short-lived Immutable servers, and managing or specifically, building them with Puppet 3. Of course support for Puppet 3 is now deprecated, so I’ll be updating my examples to Puppet 4 at some point soon.
Video of presentation
The biggest challenges with this approach are; i) Immutable servers don’t change, this means should any configuration or software needs to be updated, you will have to rebuild the server. In Development this is no big issue, especially if those environments are rebuilt daily. After all, no point paying for a server or environment when your developers are tucked up in bed. ii) The puppet code is usually only run once, on boot. This means intrusion detection needs to be factored into the design, as you cannot rely on puppet to revert edited files, malicious or not. Again regular rebuilds can reduce this issue, but active monitoring of all instances is a must. iii) Unless logs are shipped elsewhere, when the server is rebuilt, those logs will be lost. An ELK/Elastic stack or Loggly can help with logging to a central server.
Agenda
The bit that always get a laugh, is where I explain ordering. In puppet you define a state that you want the server to be in. This means a lot of what is done can be executed simultaneously. In some cases this creates issues where certain things have to happen in a specific order. The fun is around the keywords used to specify this in the Puppet manifest.
Before me, or before you
The issue confuses new techies I mentor. In the image above the before tag is stating that the class should be executed before the File['copy-init-file'].
The reason this can confuse you for the first time, is where you compare this to the require tag. This states that Exec['unarchive-source] is required to run ‘before’ this class.
Some of this can be implied by the layout of the code, however it should be stressed that the layout order of the code only effects the catalogue compilation, not the execution.
If you would like me to explain in more detail, we can discuss below.
Links: Slides
Previous Post: code quality Next Post: Avoid unstable server builds using version control and bundles Tags: immutable · masterless · puppet