During the last few weeks I have been interviewed for several DevOps positions. In two of them I had to reply a skills check-list and in the other one an exercise to be solved and send back by email. I think these check-list interviews are not good for DevOps positions, specially if the check-lists used are not updated properly. Let’s see why…
I have been working with DigitalOcean for several months, on average DigitalOcean deploys your VPS server in 55 seconds. After the server is deployed, all the manual/prone to errors/boring configuration process is needed.
As I am using puppet to configure all my servers I have create provisioningDO rakefile script (based on John Arundel’s book Puppet 3 Cookbook) to deploy and configure my servers in 4 min 15 sec. It means After 4 min 15 secs, my servers are ready for production.
provisioningDO uses Jack Pearkes’ tugboat CLI tool so, a fully installed and configured tugboat CLI is necessary. It shouldn’t take you more than 5-10 minutes to have a working and ready to go tugboat installation
Llevaba ya tiempo dandole vueltas a la idea de montar un grupo de usuarios de puppet en Alicante, que no se si habra muchos…
La semana pasada mande un correo a la lista de usuarios de puppet por si habia alguien interesado y hoy he recibido un correo de puppetlabs.com indicandome que si tenia un grupo de meetup, que ellos me pondrian un link en su web. por lo que me he decidido a crear un group en meetup.com.
Por lo que oficialemente hoy ha sido creado el Alicante Puppet Users Group
Asi que si estas interesado en Puppet, DevOps, Data Center and Operations Automation y basicamente hacer las cosas una sola vez y que los ordenadores hagan el resto. Este es tu grupo.
Espero que os apunteis y cuando seamos unos cuantos hagamos la primera quedada.
Salu2 puppeteros Alicantinos
Since I started learning puppet several weeks ago I wanted to install the client and the server in the same host but using several aliases for the same machine. But there are several funny error related to puppet master and client sharing the same ssl directory: SSL certificate confusion, obscure errors, and SSL revocation horrors.
I took the main ideas from Splitting puppetd from puppetmaster from madduck‘s blog. But using this method you don’t have to create 2 differents ssl directories. Both installations (client and server) will share the same directory. I think it’s easier to implement and maintain.
The golden rule is to create all the SSL stuff (CA, keys, certificates,etc) in the right moment. And you may ask… When is the right moment? After the file /etc/puppet/puppet.conf is created with the certname directive properly updated. As by default puppet create all the SSL stuff using the hostname instead of the alias you want.
This tutorial assume you are using Debian (but should work on its derivatives: Ubuntu, Mint, etc) and have one server with two aliases replying to the same host (via /etc/hosts or DNS) In my case: puppet (server) and mediacenter (client).