TL;DR
From the devOpsDream GitHub repo:
devOpsDream is the next evolution from Mass, which is about quickly and easily getting the information you need about your infrastructure, and doing something with it so you can get back to what’s important. It
- Brings organisation and understanding to the reality of environments with mixed legacy and current naming conventions.
- Presents the information in a clear and concise manner, with the ability to quickly get
--moreinformation when needed.- Provides an effective way to share information about what parts of the infrastructure are and what they do.
- Gives you fast access so you can get on with dealing with the task at hand.
- Can export everything it knows (or a selection of it) in many standard formats such as json.
This is a retro-active post. I first released under the devOpsDream branding in around 2015 after someone made a competitor that used the same name as mass, while being incompatible, and unable to be installed concurrently.
Table of contents
Video of it in action
This is a demo from a little while before the name change.
Examples
Importing hosts
There are several supposed sources for importing hosts. The ones that you’re probably most interested in are:
| Import from | Flag | Comment |
|---|---|---|
| AWS | -v --awsGetAll |
Uses the aws command line tool. This command must be logged in and have access to list everything that you want to import. |
| Google Cloud | -v --gcGetAll |
gcloud command line tool. This command must be logged in and have access to list everything that you want to import. |
| Puppet | -v --importFromPuppet |
Relies on knowledge in /var/lib/puppet/yaml/node. Must have an active puppet installation on the local machine, and have read access to /var/lib/puppet. |
| Chef | -v --getChefHosts |
Uses the knife comment line tool. This command must be logged in and have access to list everything that you want to import. |
Where possible, it’s worth using the cloud-provider to get first-hand up-to-date information. But when that’s not viable, the Puppet and Chef options are there.
NOTE: Since attention died down, I’ve been keeping it working at a works-for-me level. Which means that code that isn’t relevant to the infrastructures that I work on is less likely to work. If you spot a bug, please report it via a github issue, and I’ll be happy to work through it with you.
Listing available hosts
There are several tools available to help you search for the information you need. Here are a couple:
Above: A few ways to search through hosts.
SSHing to multiple servers at once
Historically, my favourite way to connect to several servers at once has been to use --cssh which uses clusterSSH. But more recently, I’m preferring --xpanes (or -x for short) which uses XPanes via TMux:
Above: XPanes in action.
With these tools, keyboard input goes to all of the servers at once, unless you instruct otherwise. This is useful when you want to interactively perform the same action across multiple hosts, or visualise how the hosts compare in some way.
You can also use tools like --term to bring up a single terminal window per host.
Interacting with servers
In the following example, I:
- Download the hosts file from each server.
- Confirm that I have the files.
- Upload one of the downloaded files to both servers.
- Run the
lscommand on both servers to confirm that the file is there.
Above: Doing a few interactions with the servers.
Exporting data
Exporting data is as easy as adding --json to the end of the command that lists the information you want.
You might want something more precise that you can parse with command line tools, you can do something like this
d --list --toString="~%IP%~ ~%hostName%~" -sWhich looks like this:
Above: Exporting the IP address and hostName.
You can use --nested to find out which fields are available. Eg
Above: The –nested view showing available fields.
NOTE: In the above example I’ve selected a host with very few fields to keep the screenshot to a reasonable size. If you show a host from AWS, you’ll get many more fields. And even then, many more are possible. - I actually strip out most of them during import to keep the stored data small.
But let’s say you want to make things difficult for yourself and you want to parse the human readable output that is subject to change… Have I dropped enough hints that you shouldn’t do this yet? You can do so with the --noColor parameter:
Above: Using –noColor to remove ANSI colour characters. Seriously, don’t do this.
Keeping it up-to-date
In its heyday, mass was getting a lot of attention via word-of-mouth. At the time, I was flat out implementing user requests. I kept this up for a while after interest died down. But eventually moved to works-for-me quality so that I could focus on other projects. I still use it, but I don’t think many other people do any more.
Code that I use is likely to work. Other code is more luck-of-the-draw. Github issues and Pull Requests are welcome.
If this becomes more popular again in the future, I may give it more attention again.