git

cf-deploy v2 released

/ bronto / Leave a comment

Update: this article refers to the third version of cf-deploy. For the latest release, check the github repository.

Errata corrige: it’s actually v3! This is what happens when you don’t publish updates for your software for too long…

github-logo I took some time this weekend to release an update for cf-deploy. You have now the option to override the configuration hardcoded in the script by means of environment variables. Check the README for the details.

If you don’t know what cf-deploy is, that’s fair 😉 In two words, it’s a Makefile and a Perl front-end to it that makes it easier to pack together a set of files for a configuration management tools and send them to a distribution server. Designed with git and CFEngine in mind, it’s general enough that you can easily adapt it to any version control system and any configuration management tool by simply modifying the Makefile. If it sounds interesting, you are welcome to read Git repository and deployment procedures for CFEngine policies on this same blog. Enjoy!

 

Advertisement

Report from Config Management Camp 2015

/ bronto / 1 Comment

cfgmgmtcamp-logoThe Config Management Camp 2015 is gone leaving its trail of inspiring presentations, interesting discussions, pleasant meetings with great people and, hopefully, satisfaction for how each of us has played his/her part to make this edition a success.

A big thank for the brave people that attended my seminar and to those who asked questions. The questions gave me a couple of ideas to further expand the seminar, and more may come if you’re so kind to let me know your opinion on the talk: what you liked, what you didn’t, what could be improved in both the talk and the speaker’s style. Thanks in advance. As for the code of the tools, I promise to publish it on GitHub as soon as I get “clearance” (this week, possibly!).

For those who weren’t at the seminar, I presented how we evolved our git repository structure to support more than one project, each one with its own needs, but at the same time being able to share the relevant common libraries and tools and to make the deployment of the policies easy, manageable and maintainable, whatever the number of hubs and projects involved. The questions dove nose down to how we manage access to the hubs so that a person working on project A can’t accidentally deploy his policies on the hubs supporting project B, how we manage access rights to files in separate projects and to branches, and how easy or hard is to extend the deployment tool with new functionality.

The slides of the presentation are on SpeakerDeck (or further down the post if you don’t bother go to SpeakerDeck 😉 The good guys at Normation also filmed the seminar, so it’s just a matter of time that a video of the seminar will be available. Then you’ll also be able to hear my appeal to support cancer research, talking of which you can check another blog post of mine.

Regarding the talks I attended and the “hallway track”, Jez Humble’s keynote was definitely a mind blowing experience. Leaving aside the things that I am doing wrong, that we are doing wrong in my work environment, and that a broad set of people in our profession is f***ing up completely, I understood that there is a category that definitely needs to be more present at events like this: bosses. Because we can do a good job as professionals, follow the best practices, use the brightest and shiniest tools of today and some of the tools of tomorrow, but that’s definitely not enough to establish a culture of cross-area collaboration. That’s not going to happen without the direct involvement of the bosses and their mandate.

Continue reading →

git: some tricks

/ bronto / Leave a comment

I used RCS, CVS and SVN in the past, so I am not new to version control. GIT is a bit different from them, by the way, and is new to me, so I need to write down things before I learn them by earth. I am publishing my notes in the hope it will be useful to you, as well. Also, feel free to comment if you’d like to suggest better ways to do the same things.

I am writing things as I use them, so beware this post will still change several times in the future. I hope this doesn’t drive your RSS reader nuts…

(Updated: September 15th, 2014: revert last commit, get a branch/tag’s commit ID)
(Updated: September 7th, 2012: make a local branch remote, check out a file from another branch)
Updated: April 3rd, 2012: new repo with gitolite in the middle)
(Updated: March 14th, 2011: git remote prune)
(Updated: January 27th, 2011)
(Updated: many other times…) … Continue reading →

cf-deploy: easier deployment of CFEngine policies

/ bronto / 2 Comments

Update: this article refers to the very first version of cf-deploy. For the latest release, check the github repository.

GitRepoStructureIn my latest post “git repository and deployment procedures for CFEngine policies” I explained how we structured our git repository for CFEngine policies, and how we built a deployment procedure, based on GNU make, to easily deploy different projects and branches from the same repository to the policy hubs. Please read that post if you haven’t yet, as this one is not going to make much sense without it.

The make-based deployment procedure worked pretty well and was functional, but still had annoyances. Let’s name a few:

  • the make command line was a bit long and ugly; usually it was something like:
    make -C /var/cfengine/git/common/tools/deploy deploy PROJECT=projX BRANCH=dev-projX-foo SERVER=projX-testhub
  • the Makefile was not optimized to deploy on more than one server at a time. To deploy the same files on several hubs, the only solution was to run make in a cycle several times, as in
    for SERVER in projX-hub{1..10} ; do make -C /var/cfengine/git/common/tools/deploy deploy PROJECT=projX BRANCH=dev-projX-foo SERVER=$SERVER ; done
  • deploying a project on all the policy hubs related to that project required one to remember all of the addresses/hostnames; forget one or more of them, and they would simply, hopelessly left behind.

At the same time, there were a few more people that were interested in making tiny changes to the configurations via ENC and deploy, and that long command line was a bit discouraging. All this taken together meant: I needed to add a multi-hub deployment target to the Makefile, and I needed a wrapper for the deployment process to hide that ugly command line.

For first, I added to the Makefile the functionality needed to deploy on more than one hub without having to re-create the temporary directory at every run: it would prepare the files once, deploy them as many times as needed, and then wipe the temporary directory. That was nice and, indeed, needed. But the wrapper couldn’t wait any longer, and I started working on it immediately after. That’s where cf-deploy was born.

Continue reading →

Git repository and deployment procedures for CFEngine policies

/ bronto / 4 Comments

This is the first installment of three, where I’ll talk about how we structured the git repository for our CFEngine policies together with the deployment policies. This first episode will be about how the repository was (badly) structured before and how we redid it (better), and it will introduce our deployment procedures based on GNU Make. The second installment will talk about how we built upon the deployment procedure and we made it easier. The third installment will be about how we greatly simplified how we manage agent runs by hand on our nodes, so that even the non-CFEngine-savvy can do the right thing with little to no knowledge of CFEngine.

Continue reading →

Managing hundreds of Linux servers with CFEngine and Git: full control over configuration

/ bronto / Leave a comment

Remi Bergsma's blog

Back in June, just before I went off for holiday, I attended a CFEngine training in Amsterdam. When I returned from holiday a few weeks later, me and my team started making plans to implement CFEngine in our environment. After two months of hard work, I’m proud to say we manage about 350 out of our 400 Linux servers with CFEngine!

The ride has been fun, although not always easy. In this post I’ll give a quick overview of our CFEngine implementation, where I found useful info, etc.

CFEngine is different
To start, let me tell you that one of the most difficult parts of learning CFEngine is to get used to the terminology and to ‘think’ CFEngine. For example, a ‘class’ in CFEngine is not what you think it is. It has nothing to do with object oriented programming. It’s more like a ‘context’ that you can use…

View original post 1,269 more words