Welcome to Technology Short Take #56! In this post, I’ve collected a few links on various data center technologies, news, events, and trends. I hope you find something useful here.
In this post I’m going to share with you an OS X graphical application I found that makes it easier to work with RESTful APIs. The topic of RESTful APIs has come up here before (see this post on using cURL to interact with RESTful APIs), and RESTful APIs have been a key part of a number of other posts (like my recent post on using jq to work with JSON). Unlike these previous posts—which were kind of geeky and focused on the command line—this time around I’m going to show you an application called Paw, which provides a graphic interface for working with APIs.
Before I start talking about Paw, allow me to first explain why I’m talking about working with APIs using this application. I firmly believe that the future of “infrastructure engineers”—that is, folks who today are focused on managing servers, hypervisors, VM, storage, networks, and firewalls—lies in becoming the “full-stack engineer,” someone who has knowledge and skills across multiple areas, including automation/orchestration. In order to gain those skills in automation/orchestration, it’s pretty likely that you’re going to end up having to work with APIs. Hence, why I’m talking about this stuff, and why Continue reading
I wanted to call out a couple of software packages whose vendors I’ve worked with recently that I felt had really good customer service. The software packages are BusyCal (from BusyCal, LLC) and Textual (from Codeux Software, LLC).
As many of you know, the Mac App Store (MAS) recently suffered an issue due to an expired security certificate, and this caused many MAS apps to have to be re-downloaded or, in limited cases, to stop working (I’m looking at you, Tweetbot 1.6.2). This incident just underscored an uncomfortable feeling I’ve had for a while about using MAS apps (for a variety of reasons that I won’t discuss here because that isn’t the focus of this post). I’d already started focusing on purchasing new software licenses outside of the MAS, but I still had (and have) a number of MAS apps on my Macs.
As a result of this security certificate snafu, I started looking for ways to migrate from MAS apps to non-MAS apps, and BusyCal (a OS X Calendar replacement) and Textual (an IRC client) were two apps that I really wanted to continue to use but were MAS apps. The alternatives were dismal, at best.
While I was at Kubecon this past week, one of the presenters showed off a handy CLI tool for working with JSON. It’s called jq, and in this post I’m going to show you a few ways to use jq. For the source of JSON output, I’ll use the OpenStack APIs.
If you’re not familiar with JSON, I suggest having a look at this non-programmer’s introduction to JSON. Also, refer to this article on using cURL to interact with a RESTful API for a bit more background on some of the commands I’m going to use in this post.
Let’s start by getting an authorization token for OpenStack, using the following curl command:
curl -d '{"auth":{"passwordCredentials":
{"username": "admin","password": "secret"},
"tenantName": "customer-A"}}'
-H "Content-Type: application/json"
http://192.168.100.100:5000/v2.0/tokens
This will return a pretty fair amount of JSON in the response, and it presents the first opportunity to use jq. Let’s say you only wanted the authorization token, and not all the other output. Simply add the following jq command to the end of your curl request:
curl -d '{"auth":{"passwordCredentials":
{"username": "admin","password": "secret"},
"tenantName": "customer-A"}}'
-H "Content-Type: application/json"
http://192.168.100.100:5000/v2.0/tokens |
Continue reading
This is a liveblog of the opening keynote at the inaugural Kubernetes conference, Kubecon, taking place this week at the Palace Hotel in San Francisco. Brendan Burns, Senior Staff Software Engineer at Google, is delivering the opening keynote. Burns is a co-founder of the Kubernetes project.
Burns starts out with a quick review of a bit of Kubernetes history, and reviews the broad diversity of submitters that are participating in the development of Kubernetes. He doesn’t spend much time there, though, and quickly transitions into a “where are we going?” discussion.
He says that Kubernetes wasn’t really about containers, or scheduling; it was really about making reliable, scalable, agile distributed systems a CS101 exercise. Kubernetes is really about making it easier to build distributed systems, to scale distributed systems, to update distributed systems, and to make distributed systems more reliable. Burns demonstrates how Kubernetes makes this easier by showing a recorded demo of scaling Nginx web servers up to handle 1 million requests per second, and then updating the Nginx application while still under load.
After the demo completes, Burns takes a few minutes to break down the architecture behind the demonstration. “Loadbots,” managed by a Kubernetes replication controller, Continue reading
Generally speaking, when launching instances in a cloud environment (such as AWS or an OpenStack-based cloud), the preferred/default way of accessing that instance is via SSH using an injected SSH key pair. There are times, though, when—for whatever reason—this approach won’t work. (I’ll describe one such situation below.) In such instances, it’s possible to configure cloud-init, the same tool used to inject SSH keys, to change passwords for user accounts. Here’s how.
Please note that this is a total hack. (Do NOT use this for any sort of production workload!) That being said, sometimes things like this are necessary to complete preliminary evaluations of a new technology, new product, or new architecture. In my case, I had a demo environment (using DevStack) that I needed to get up and running, and the instances would not have any external connectivity. This meant I was limited to console access only—hence, SSH keys are useless. The only means of access would be via password login through the console. So, I found this snippet of cloud-init code:
#cloud-config
chpasswd:
list: |
user1:password1
user2:password2
user3:password3
expire: False
For this particular use case, I needed to change the default user on the Ubuntu Continue reading