Lately as a process of joining different Postgres databases with 1 schema each into 1 database with different schemas, I had to export a schema from a database and to import it into another database with a different schema name.
Ruby standard library provides a good solution for parsing command line options passed to the script or application. It’s called OptionParser. It’s powerful and very easy to use. The code you have to write is easy to read and modify. It also supports different kind of options: short and long flags, required or optional arguments, also different types of arguments including dates, lists and so on.
My work involvs writing many small command line applications (scripts) in ruby. One of the common things among them is logging. The application should produce adequate log messages, so that one could follow the application flow. Ruby has a very good logger in standard library. You can use it like that:
Testing your cookbooks with unit tests will help you not to break existing functionality. But how can you be sure that the recipe will successfully run on production node? The only answer to that is running this recipe on some other/similar machine and checking if everything is actually configured the way it must be. Don’t worry we will not need some additional hardware for testing cookbooks, it can comfortably be done in virtual machine or container.
Before going further to running integration tests on your cookbooks and roles we need to prepare a bit by creating an Lxd container, where we would run our tests. This is a script that creats an Lxd container with Chef installed and a running ssh server (required for Test Kitchen transport).
I decided to start blogging again. Somehow I felt necessary doing that not for someone else, but for myself. It’s a good way to organise my own knowledge and thoughts.
Disclaimer: as of Jan 4 2014, this is already implemented inside ChefSpec (>= 3.1.2), so you don’t have to do anything. The post just describes the problem and solution with more details.
Last time we were speaking about testing Chef recipes, I introduced to you ChefSpec as a very good tool for running unit tests on your cookbooks. But lately I encountered a problem with it. I have over 800 unit tests (aka examples in RSpec world) and now it takes about 20 minutes to run. 20 minutes, Karl!!! That’s a extremely long time for this kind of task. So I decided to delve, what exactly is responsible for taking so much time.
I always thought that it should be a trivial task. There are even some stackoverflow answers on that topic, but there is actually a catch that none of the answers talks about.
So now you have less errors and typos in your cookbooks, thanks to foodcritic. But you are still far from confident that your cookbook will not fail to run on some node. Next step for acquiring it is unit tests (aka specs in ruby world).
This post have been in draft for almost a year. At last I have made myself to turn back to my blog and continue writing.
A couple of years ago we have adopted automating our server configuration through Chef recipes. In the beginning we didn’t have many cookbooks and all the recipes were more or less simple. But as time passed new applications had to be installed and configured, including some not so simple scenarios. Turned out that “hit and miss” method wasn’t too good. We came across a lot of errors, such as: