Archive

Category Archives for "Systems"

Docs Spotlight: Keeping the FM in RTFM

blog-header-docspotlight

Crafting and maintaining high quality documentation is something we all know is very important. Reputable documentation is much more than the result of fantastic product or project management - especially when we're talking about community-driven documentation. Open source communities in particular like to reference "RTFM" (Read the Fine Manual, for the cleaner acronym explanation), but that's only helpful when the "Fine Manual" contains quality documentation. For projects like Ansible, it is our active users that make all the difference, and with their contributions and efforts we are able to help provide the great documentation that supports Ansible.  But, that also comes with some caveats.

Many people contribute to open source projects so that they may "scratch their own itch." Whether this works well or creates clunky and cluttered code is not up for debate in this blog post, but how well it works in relation to open source documentation is debatable. Often contributions boil down to very bare bones coverage of a feature or implementation, other times the only contribution made is a typo fix. And while even the small fixes are helpful, these are not the contributions that make the docs great (better, yes, but not yet reaching Continue reading

Technology Short Take #58

Welcome to Technology Short Take #58. This will be the last Technology Short Take of 2015, as next week is Christmas and the following week is the New Year’s holiday. Before I present this episode’s collection of links, articles, and thoughts on various data center technologies, allow me to first wish all of my readers a very merry and very festive holiday season. Now, on to the content!

Networking

Containerd: a daemon to control runC

As we build out Docker’s infrastructure plumbing, we are committed to releasing these plumbing components as open source to help the community. Today we’re releasing a new daemon to control runC called: containerd. It’s built for performance and density, and will eventually be … Continued

Using Cloud-Init to Register an Instance into Consul

This post describes a method for using cloud-init to register a cloud instance into Consul on provisioning. I tested this on OpenStack, but it should work on any cloud platform that supports metadata services that can be leveraged by cloud-init.

I worked out the details for this method because I was interested in using Consul as a means to provide a form of “dynamic DNS” for OpenStack instances. (You can think of it as service registration and discovery for OpenStack instances.) As I’ll point out later in this post, there are a number of problems with this approach, but—if for no other reason—it was helpful as a learning exercise.

The idea was to automatically register OpenStack instances into Consul as they were provisioned. Since Consul offers a DNS interface, other instances and/or workloads could use DNS to look up these nodes’ registration. Consul offers an HTTP API (see here for details), so I started there. I used Paw (a tool I described here) to explore Consul’s HTTP API, building the necessary curl commands along the way. Once I had the right curl commands, the next step was to build a shell script that would pull the current Continue reading

Modifying OpenStack Security Groups with Terraform

In this post I’d like to discuss a potential (minor) issue with modifying OpenStack security groups with Terraform. I call this a “potential minor” issue because there is an easy workaround, which I’ll detail in this post. I wanted to bring it to my readers’ attention, though, because as of this blog post this matter had not yet been documented.

As you probably already know if you read my recent introduction to Terraform blog post, Terraform is a way to create configurations that automate the creation or configuration of infrastructure components, possibly across a number of different providers and/or platforms. In the introductory blog post, I showed you how to write a Terraform configuration that would create an OpenStack logical network and subnet, create a logical router and attach it to the logical network, and then create an OpenStack instance and associate a floating IP. In that example, I used a key part of Terraform, known as interpolation.

Broadly speaking, interpolation allows Terraform to reference variables or attributes of other objects created by Terraform. For example, how does one refer to a network that he or she has just created? Here’s an example taken from the introductory blog post:

GALAXY 2.0 – BETA RELEASE

We have been working hard on some exciting changes to Galaxy that we think you’re going to like. The changes are substantial, and we want your feedback, so today we are releasing Galaxy 2.0 in beta

Check it out and help us shape the future of Galaxy. Comments and bug reports can be filed at Galaxy Issues. Keep in mind that the beta site is purely a playground for trying out the new Galaxy. Any roles you import or remove will not be reflected in a future production Galaxy site.

What follows is a summary of some of the new features you’ll see on the beta site.

Tighter Integration with GitHub

Using your GitHub login, Galaxy now interacts directly with the GitHub API. This allows you to import all the repositories you collaborate on, including those in organizations you belong to.

To make it even better, we decoupled roles from the Galaxy username. Roles imported into Galaxy are now namespaced by GitHub user rather than Galaxy username. This gives you the flexibility of importing roles from your GitHub account or from an organization. The repo namespace in Galaxy will exactly match the GitHub namespace.

This might sound scary, Continue reading

GALAXY 2.0 – BETA RELEASE

 

We have been working hard on some exciting changes to Galaxy that we think you’re going to like. The changes are substantial, and we want your feedback, so today we are releasing Galaxy 2.0 in beta

2015-galaxy-blog-header.png

Check it out and help us shape the future of Galaxy. Comments and bug reports can be filed at
Galaxy Issues. Keep in mind that the beta site is purely a playground for trying out the new Galaxy. Any roles you import or remove will not be reflected in a future production Galaxy site.

What follows is a summary of some of the new features you’ll see on the beta site.

Tighter Integration with GitHub

Using your GitHub login, Galaxy now interacts directly with the GitHub API. This allows you to import all the repositories you collaborate on, including those in organizations you belong to.

To make it even better, we decoupled roles from the Galaxy username. Roles imported into Galaxy are now namespaced by GitHub user rather than Galaxy username. This gives you the flexibility of importing roles from your GitHub account or from an organization. The repo namespace in Galaxy will exactly match the GitHub namespace.

This might sound Continue reading

AnsibleFest San Francisco 2015 Presentations

AnsibleFest-SF-15.jpgIf you missed our latest AnsibleFest in San Francisco you missed out connecting with over 450 members of the Ansible community and some amazing presentations from Splunk, NEC, Riot Games, J.Crew, SparkCentral and others.

Tickets are on sale now for AnsibleFest London and we are busy planning our New York event (details coming soon).

AnsibleFest San Francisco 2015 Presentations

 

 

Technology Short Take #57

Welcome to Technology Short Take #57. I hope you find something useful here!

Networking

Using SSH Multiplexing

In this post, I’m going to discuss how to configure and use SSH multiplexing. This is yet another aspect of Secure Shell (SSH), the “Swiss Army knife” for administering and managing Linux (and other UNIX-like) workloads.

Generally speaking, multiplexing is the ability to carry multiple signals over a single connection (see this Wikipedia article for a more in-depth discussion). Similarly, SSH multiplexing is the ability to carry multiple SSH sessions over a single TCP connection. This Wikibook article goes into more detail on SSH multiplexing; in particular, I would call your attention to the table under the “Advantages of Multiplexing” to better understand the idea of multiple SSH sessions with a single TCP connection.

One of the primary advantages of using SSH multiplexing is that it speeds up certain operations that rely on or occur over SSH. For example, let’s say that you’re using SSH to regularly execute a command on a remote host. Without multiplexing, every time that command is executed your SSH client must establish a new TCP connection and a new SSH session with the remote host. With multiplexing, you can configure SSH to establish a single TCP connection that is kept alive for a specific period Continue reading