Posts

As long as I have been working with configuration management tools (puppet & ansible) there hasn’t really been a good way to test the units you’ve been written. Up until recently my experience has been something like this: working on a feature on the master branch, in best case someone will lend their eyes to look at the changes, run changes directly on the target environment and hope everything works without spewing errors. Except being an embarrasing workflow this imposes a risk; there’s no way of knowing that your changes won’t set the target environment on fire and either way testing in production (or any other target environment for that matter) is unacceptable! ...

One thing that I really think is neat with Ansible is that when you need functionality that are not part of the Ansible core (let’s say you need to integrate Ansible with bigip F5 load balancer) you can just turn to Python (or any other language for that matter) to write your own modules that you later can use in the regular playbooks. This is a really neat functionality, you are not tied down to the dsl (such as in the case of Puppet). DSL:s are in my experience very limited and stupid; you would rather want turn to a real general purpose programming language. ...

So what makes a good and helpful command line application? I think these three point are important: easy to use helpful play well with others Bash is commonly used to write command line apps, but I can never shrug of the feeling of shame of writing a bash script with more than 30 lines. That’s why I’m shaking things up here and showing how to use ruby instead. I’ll be using the optparse gem so you need to do a gem install optparse before trying out the shown examples. ...

First let’s set up our build rpm environment by installing the following: [bob@vagrant-centos65 ~]$ sudo yum install -y rpmdevtools rpmlint Then we’ll set up the folder structure with the rpmdev-setuptree command. It will create tbe rpmbuild folder and it’s subfolders as shown below. [bob@vagrant-centos65 ~]$ rpmdev-setuptree [bob@vagrant-centos65 ~]$ tree rpmbuild/ rpmbuild/ ├── BUILD ├── RPMS ├── SOURCES ├── SPECS └── SRPMS In the SPEC folder we create elasticsearch.spec, and in the SOURCES folder we download the tar-file from elasticsearch. ...

Welcome to the first part article on how to build rpm packages. Here I will walk you through how to build a rpm package and how to work with the tools you will need. Let me just first start off with saying that I don’t consider myself an expert at rpm packaging but blogging about a topic forces you to graps the subject you are writing about better. With that being said this first part will cover the bascis like installing rpm tools, the structure of a spec file, macros and lastly a simple rpm build. In part two my ambition is to take the things I wrote about here to package a real world application into an rpm. ...

One thing with Ruby I don’t quite like (and many with me) are the Ruby gems. The one thing thats great with gems is that it’s almost as with CPAN, if you have a problem - there’s a gem for that! But I don’t like the idea of installing libraries system-wide. If installed with sudo it’s a security risk. And my belief is that libraries are supposed to be used by demand when an application needs them. For example Java + maven and Node.js and NPM is a good example of those getting this right. Let’s say you want to share a ruby project, the problem is that person must have the same set of gems installed to be able to run your program, and maybe he’s installing a newer version of that gem that you was testing on. Not good! Fortunately we have Bundler to help us keep track of gems and it’s dependencies that solves this problem. ...