Trifork Blog

Axon Framework, DDD, Microservices

Posts Tagged ‘Puppet’

Puppet from the trenches – How to prevent overwritten user configuration with a custom type

October 29th, 2013 by
(http://blog.trifork.com/2013/10/29/puppet-from-the-trenches-how-to-prevent-overwritten-user-configuration-with-a-custom-type/)

Puppet_LogoIn this installment of the ‘from the trenches’ series I cover the use of Puppet during one of our projects. We have used Puppet to provision Jenkins instances as part of a build and deployment platform for a large organization. I discuss the problem of when Puppet overwrites user managed configuration and how we solved it by writing a custom type.

Read the rest of this entry »

Ansible – next generation configuration management

March 26th, 2013 by
(http://blog.trifork.com/2013/03/26/ansible-next-generation-configuration-management/)

The popularity of the cloud has taken configuration management to the next level. Tools that help system administrators and developers configure and manage large amounts of servers, like Chef and Puppet, have popped up everywhere. Ansible is the next generation configuration management. Ansible can be used to excute tasks on remote computers via SSH so no agent is required on the remote computer. It was originally created by Michael DeHaan.
I won’t compare Ansible with Puppet or Chef, you can check the Ansible FAQ. But the key differentiators are that Anisble does not require an agent to be installed, its commands can be ordered, can be extended via modules written in any language as long as they return JSON, basically taking the best of both worlds (Puppet and Chef).

Instalation

You’ll want to install Ansible on a central computer from which you can reach all the other computers.

On Fedora, it is already packaged:

sudo yum install ansible

On Ubuntu, you need to add a repo:

sudo add-apt-repository ppa:rquillo/ansible
sudo apt-get install ansible

On Mac, you can use MacPorts.

On others, compile it from source https://github.com/ansible/ansible.

Getting started

One of the core constructs in Ansible is the notion of an inventory. Ansible uses this inventory to know which computers should be included when executing a module for a given group. An inventory is a very simple file (by default it uses /etc/ansible/hosts) containing groups of computers.

Example:

[appservers]
app1.trifork.nl
app2.trifork.nl

As part of the inventory you can also initialize variables common to a group. These variables can then be reused when executing tasks for each computer.

[appservers]
app1.trifork.nl
app2.trifork.nl

[appservers:vars]
tomcat_version=7
java_version=7

You can set your own inventory by setting a global environment variable:

export ANSIBLE_HOSTS=my-ansible-inventory

You can then start using Ansible right away:

ansible appservers -m ping -u my-user -k

What this does is run module ‘ping’ for all computer in the group appservers, it returns:

app1.trifork.nl | success >> {
"changed": false,
"ping": "pong"
}

app2.trifork.nl | success >> {
"changed": false,
"ping": "pong"
}

You see that the module executed successfully on both hosts. We’ll come back to the ‘changed’ output later.
-u tells Ansible that you want to use another user (it uses root by default) to login on the remote computers. -k tells Ansible that you want to provide a password for this user.
In most cases you’ll probably want to setup a passwordless connection to the remote computers, ssh-copy-id will help you do that. Or better, you can rely on ssh-agent.

Gathering facts

Most of the time when using Ansible, you want to know something about the computer you are executing a task on.
The ‘setup’ module does just that, it gathers facts about a computer.

ansible appservers -m setup -u tomcat -k

You get a big output (I’ve removed some of it):

app1.trifork.nl | success >> {
    "ansible_facts": {
        ...
        "ansible_architecture": "x86_64",
        ...
        "ansible_distribution": "Ubuntu",
        ...
        "ansible_domain": "trifork.nl",
        ...
        "ansible_fqdn": "app1.trifork.nl",
        "ansible_hostname": "app1",
        "ansible_interfaces": [
            "lo",
            "eth0"
        ],
        ...
        "ansible_machine": "x86_64",
        "ansible_memfree_mb": 1279,
        "ansible_memtotal_mb": 8004,
        "ansible_pkg_mgr": "apt",
        ...
        "ansible_system": "Linux",
        ...
    },
    "changed": false,
    "verbose_override": true
}

app2.trifork.nl | success >> {
    "ansible_facts": {
        ...
        "ansible_architecture": "x86_64",
        ...
        "ansible_distribution": "Ubuntu",
        ...
        "ansible_domain": "trifork.nl",
        "ansible_fqdn": "app2.trifork.nl",
        "ansible_hostname": "app2",
        "ansible_interfaces": [
            "lo",
            "eth0"
        ],
        ...
        "ansible_machine": "x86_64",
        "ansible_memfree_mb": 583,
        "ansible_memtotal_mb": 2009,
        "ansible_pkg_mgr": "apt",
        ...
        "ansible_system": "Linux",
        ...
    },
    "changed": false,
    "verbose_override": true
}

These are Ansible facts, Ansible can also use extra facts gathered by ohai or facter.

Let’s review some of the Ansible facts:

ansible_pkg_mgr: This tells which package manager is in use on the remote Linux computer. This is important if you want to use the ‘apt’ or ‘yum’ module and want to make your scripts (playbooks) distro-agnositic.
ansible_distribution: This tells which Linux distribution is installed on the remote computer.
ansible_architecture: If you want to know which OS architecture it is.

Next time we’ll use these facts together with modules in a playbook example.

Prepare for the Storm and be saved by Puppet!

February 28th, 2013 by
(http://blog.trifork.com/2013/02/28/prepare-for-the-storm-and-be-saved-by-puppet/)

GOTO_night_Amsterdam_v2

After a highly successful edition of the GOTO Night in December with Timan Rebel and Erik Meijer, we are happy to announce the next GOTO Night that will take place on March 7 2013.

This time at the Trifork office in Amsterdam on March 7 we have two great technical presentations lined up:

  1. Within the eye of the Storm (Introduction to Storm framework) // Sjoerd Mulder from Persuasion API
  2. Using Puppet, Foreman and Git to Develop and Operate a Large Scale Internet Service (in this case eBuddy) // by Joost van de Wijgerd from eBuddy

Here is just a little taster of what what they said their presentations will cover:

Sjoerd: “Curious about the Storm Framework? Storm is a distributed real-time computation system. It’s new and exciting and you might have heard about it and have some questions about it. How does it work? What are its use-cases? How do I get started? What are the differences with Hadoop? How can I run it in production? How do I connect it with product XYZ?”. This is what I will cover and show you how you can get started with Storm, including some live coding, and I’ll even cover how you can use Storm in production”. Read more about Sjoerd & his session in detail and sign up now.

Joost: At eBuddy we are implementing DevOps and in this talk I would like to introduce our current setup. We use Foreman in combination with Puppet and a Custom Git based Configuration Management solution to manage our Infrastructure and the Services running on top of it. My talk will be centered around Foreman and Puppet and I will show how we use these tools to do deployments, scale out our clusters and configure new machines on the fly. Read more about Joost & his session in detail and sign up now.

Just before we dive into the beers, Dan Roden, our special guest from the Program Committee for GOTO Amsterdam, will present a short teaser for his sessions & track Emerging Interfaces at the GOTO Amsterdam event.

So sign up and join us on March 7 at 18.00 for great talks, free beers & pizza at Trifork.

WANT TO SPONSOR GOTO AMSTERDAM 2013?

We are already proud to have some great sponsors onboard, including 42, Appdynamics, Basho, Hippo, Neo4J & Zilverline to name a few, if you are interested contact me, Daphne Keislair or visit the event website.

Automated Configuration Management with Puppet

February 15th, 2011 by
(http://blog.trifork.com/2011/02/15/automated-configuration-management-with-puppet/)

Puppet is a systems management platform that enables sysadmins and developers to standardise the deployment and management of the IT infrastructure. This blog entry shows you how to automate your configuration management using Puppet.

Read the rest of this entry »