Did you know a large portion of Ansible’s functionality comes from the Ansible plugin system? These important pieces of code augment Ansible’s core functionality such as parsing and loading inventory and Playbooks, running Playbooks and reading the results. Essentially, Ansible uses plugins to extend what the system is doing under the hood.
In this blog, I’ll review each of these plugins and offer a high-level overview on how to write your own plugin to extend Ansible functionality.
Action Plugins
One of the core critical plugins used by Ansible are action plugins. Anytime you run a module, Ansible first runs an action plugin.
Action plugins are a layer between the executor engine and the module and allow for controller-side actions to be taken before the module is executed. A good example of this is the template module. If you look at template.py in the modules directory, it’s basically a Python stub with documentation strings, everything is done by the action plugin. The template action plugin itself creates the template file locally as a temporary file, and then uses the copy or file modules to push it out to the target system.
If Ansible finds an action plugin with the Continue reading
In case you missed it last month, we announced that Docker is extracting a key component of its container platform, a part of the engine plumbing called containerd – a core container runtime – and committed to donating it to an open foundation.
You can find up-to-date roadmap, architecture and API definitions in the Github repository, and more details about the project in our engineering team’s blog post.
You can also watch the following video recording of the containerd online meetup, for a summary and Q&A with Arnaud Porterie, Michael Crosby, Stephen Day, Patrick Chanezon and Solomon Hykes from the Docker team:
Here is the list of top questions we got following this announcement:
A. Although runC is the default runtime, as of Docker 1.12, it can be replaced by any other OCI-compliant implementation. Docker will be compliant with the OCI Runtime Specification
A. SwarmKit is using Docker Engine to orchestrate tasks, and Docker Engine is already using containerd for container execution. So technically, you are already using Continue reading
It’s a new year, and we are looking for new stories of how you are using Docker technology to do big things. Submit your cool hack, use case or deep dive sessions before the DockerCon 2017 CFP closes on January 14th.
To help with your submissions, we’ve answered the most frequent questions below and put together a list of tips to help get your proposal selected.
A. Submit your proposal here.
A. This year, we are looking for cool hacks, user stories and deep dive submissions:
A few days ago I posted a tweet about a new tool I’d (re-)discovered called jrnl
. Someone replied to that tweet, asking me to list my “multi-platform toolbelt.” While it’s still evolving (every day!), I thought it might make for a good blog post. So, here’s a list of my still-evolving multi-platform toolbelt.
Sublime Text: Over the last few years, I’ve moved to creating the vast majority of my content in Markdown (MultiMarkdown, to be more specific). At first I was using OS X-specific text editors (first TextMate 1.x, then BBEdit), but last year I switched to Sublime Text. Sublime Text supports OS X, Linux, and Windows. I don’t have any Windows-based systems, so I only use it on OS X and Linux.
Wire: My use of Wire is still a bit limited, but only because the reach of the platform is also still a bit limited (this is a classical example of network effect). I’m currently using Wire on Linux and OS X, with plans to extend to iOS and Android. (If you’re using Wire, feel free to look me up! My username is “scottslowe”).
IMAP/SMTP: I’ve standardized on using IMAP/SMTP for all my e-mail Continue reading
Remember last year when I said the market for Docker jobs was blowing up? Well, it’s more than doubled in the last year. And Swarm is also rising quickly, growing 12829%, almost all of that in the last year. We expect that with our partnership with Microsoft and Windows Docker containers, that this will grow even faster in the next year as .NET developers start to containerize their applications and Windows IT Professionals start porting their infrastructure to Docker. Take a look at this trendline from indeed.com.
So what are you doing to increase your Docker skills? Want a few suggestions?
Whether you’re a developer or more an ops person, a great place to start is the Docker Labs repository, which has currently 28 labs for you to choose from. They range from beginner tutorials, to orchestration workshops, security and networking tutorials, and guides for using different programming languages and developer tools.
Of course there’s also the Docker Documentation, which has a rich set of resources.
At Dockercon 2017 in April, there will be rich set of material for beginners and experts alike, and you will get to meet people from all over the world Continue reading
Welcome to Technology Short Take #75, the final Technology Short Take for 2016. Fortunately, it’s not the final Technology Short Take ever, as I’ll be back in 2017 with more content. Until then, here’s some data center-related articles and links for your enjoyment.
Nothing this time around!
2016 has been an amazing year for Docker and the container industry. We had 3 major releases of Docker engine this year , and tremendous increase in usage. The community has been following along and contributing amazing Docker resources to help you learn and get hands-on experience. Here’s some of the top read and viewed content for the year:
Of course releases are always really popular, particularly when they fit requests we had from the community. In particular, we had:
When Microsoft made Windows 2016 generally available, people rushed to
We also provide a lot of information about how to use Docker. In particular, these posts and articles that we shared on social media were the most read:
As I’ve done for the last few years, in early 2016 I published a list of my planned personal projects for the year. In this post, I’d like to look back on that list of projects and grade myself on my progress (or lack of progress, if that is the case). Even though 2016 isn’t over yet, it’s close enough to the end of the year that things won’t change that much before 2017 is upon us.
For reference, here’s the list of planned 2016 projects:
Let’s look at each of these planned projects and see how I fared.
Complete a new book (again): Well—in the spirit of total honesty and transparency—this was a major failure. Not only did I fail to complete the network automation book I’ve been working on with Matt Oswalt and Jason Edelman, but the other book project I had planned also did not go anywhere. Granted, the circumstances preventing the second book project were outside my control, but the fact remains I still did Continue reading
2016, what a year. Ansible upgrades galore, Tower 3 was released, a tipping point for DevOps, and much more.
All these themes were reflected in our blog this year. From doing more with automation, working across platforms (think Windows automation), orchestrating containers at scale, to exploring all the great new features in Tower 3, we covered a lot.
Just in case you missed them, here are our 10 most viewed blog posts of the year (plus a sneaky few honorable mentions).
Containers are an integral part of DevOps workflows. With containers you can be sure that if you build an application once, you can run it in the same way across every environment along the application lifecycle. That’s great, until one developer announces the need for a second, third, or fourth container. More of them, all doing different things, and all connecting together – somehow. But how? Docker has a tool that can help – docker-compose. But it’s limited to environments with a Docker-centric view of the world and doesn’t solve non-Docker orchestration problems. That’s where Ansible comes in. Read more
Ansible plus Docker was a big deal in 2016, Continue reading
As part of my effort to make myself and my workflows more “cross-platform friendly,” I’ve been revisiting certain aspects of how I do things. One of the things I’m reviewing is how I capture—and later review—posts or articles on the web. On OS X, I would run an AppleScript that generated a .webloc
file (aka an Internet location file). This is an XML file that OS X understands. However, Linux doesn’t natively understand these files, so today I came up with a solution to reading .webloc
files with Ubuntu and Firefox.
The solution to the file involves the use of xmllint
, a tool that you can install on Ubuntu as part of the “libxml2-utils” package. Using xmllint
, you can easily extract a single XML element from an XML file—and .webloc
files are just XML files. For the sake of illustration, here’s the contents of a .webloc
file generated on OS X:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>URL</key>
<string>http://blog.fntlnz.wtf/post/systemd-nspawn/</string>
</dict>
</plist>
Using xmllint
, you can extract the URL value, and then pass Continue reading
Applications requirements and networking environments are diverse and sometimes opposing forces. In between applications and the network sits Docker networking, affectionately called the Container Network Model or CNM. It’s CNM that brokers connectivity for your Docker containers and also what abstracts away the diversity and complexity so common in networking. The result is portability and it comes from CNM’s powerful network drivers. These are pluggable interfaces for the Docker Engine, Swarm, and UCP that provide special capabilities like multi-host networking, network layer encryption, and service discovery.
Naturally, the next question is which network driver should I use? Each driver offers tradeoffs and has different advantages depending on the use case. There are built-in network drivers that come included with Docker Engine and there are also plug-in network drivers offered by networking vendors and the community. The most commonly used built-in network drivers are bridge, overlay and macvlan. Together they cover a very broad list of networking use cases and environments. For a more in depth comparison and discussion of even more network drivers, check out the Docker Network Reference Architecture.
The bridge
networking driver is the first driver on our list. It’s simple to understand, Continue reading
Last Wednesday we had our 52nd meetup at Docker HQ, but this time we joined forces with the Prometheus user group to host a mega-meetup! There was a great turnout and members were excited to see the talks on using Docker with Prometheus, OpenTracing and the new Docker playground; play-with-docker.
First up was Stephen Day, a Senior Software Engineer at Docker, who presented a talk entitled, ‘The History of Metrics According to Me’. Stephen believes that metrics and monitoring should be built into every piece of software we create, from the ground up. By solving the hard parts of application metrics in Docker, he thinks it becomes more likely that metrics are a part of your services from the start. See the video of his intriguing talk and slides below.
‘The History of Metrics According to Me’ @stevvooe talking #metrics and #monitoring at the #Docker SF #meetup! @prometheusIO @CloudNativeFdn pic.twitter.com/6hk0yAtats
— Docker (@docker) December 15, 2016
Next up was Ben Sigelman, an expert in distributed tracing, whose talk ‘OpenTracing Isn’t Just Tracing: Measure Twice, Instrument Once’ was both informative and humorous. He Continue reading
About 4 years ago, I discussed some changes in the Apple ecosystem that might lead me to move away from OS X. To be honest, I’ve made only token efforts since that time to actually migrate away, even though the forces that I described in that post are still in full effect. In fact, some might say that the “iOS-ification” of OS X (now rebranded as “macOS”) is even stronger now. As a result, I’ve stepped up my work on a Linux migration, and I’m happy to report that I’ve made some progress.
Here’s a quick update on where things stand so far.
I’ve looked at a fair number of Linux distributions. I tried Elementary OS, which some have raved about but which I found too simplistic. I also went back and looked again at Ubuntu derivatives like Linux Mint. Given that Ubuntu is itself derived from Debian, I also took a look at Debian “Jessie”. Finally, I tested Fedora 25. For a number of reasons—which I’ll describe in more detail in a moment—I’ve settled on Ubuntu 16.04.
So, why Ubuntu 16.04 “Xenial Xerus”? Keep in mind that the reasons I list below are my Continue reading
In this post, I’m going to share how to hide the user list on the login screen for Ubuntu 16.04. The information here isn’t necessarily new or ground-breaking; however, in searching for the solution myself I found a lot of conflicting information as to how this may or may not be accomplished. I’m publishing this post in the hopes of providing a bit more clarity around this topic.
I’ve verified that this procedure works on the desktop distribution of Ubuntu 16.04. Note also that this is probably not the only way of making this work; it’s likely there are other ways of accomplishing the same thing.
To make configuration changes to the login screen, you’ll want to add configuration files to /etc/lightdm/lightdm.conf.d
. I used a single file to hide the user list and disable guest logins; presumably, you could use separate files for each configuration directive.
To disable the user list and disallow guest logins, add this content to a file in the etc/lightdm/lightdm.conf.d
directory (I used the filename 00-hide-user-list.conf
):
[SeatDefaults]
greeter-hide-users=true
greeter-show-manual-login=true
allow-guest=false
Once this file is in place, you’ll need to either restart your Ubuntu system, or restart the LightDM Continue reading
The Ansible Container project is targeting mid-January for its next release, and so we thought now would be a good time to check in and look at the features actively under development and anticipated to ship.
With only a glance at the roadmap page, the casual visitor may think it seems a bit smallish, having only three items. However, the items represent features that are important to the project, and require a level of effort that’s anything but small, as we’ll see.
The first item up is an image build cache. Building container images is of course a core function of the tool, and having a caching mechanism can improve the speed at which images are built.
If you’re not familiar with container images and how they’re built, think of an image as a tall building with dozens of floors, where each floor is layered on top of the previous floor, starting with the building’s foundation, and adding one floor or layer at a time until you reach the top. In the same way, a container image is a file system built in layers.
The build process starts with a base image, say Fedora 25, Continue reading
Today we announced that Docker is extracting a key component of its container platform, a part of the engine plumbing–containerd a core container runtime–and commits to donating it to an open foundation. containerd is designed to be less coupled, and easier to integrate with other tools sets. And it is being written and designed to address the requirements of the major cloud providers and container orchestration systems.
Because we know a lot of Docker fans want to know how the internals work, we thought we would share the current state of containerd and what we plan for version 1.0. Before that, it’s a good idea to look at what Docker has become over the last three and a half years.
The Docker platform isn’t a container runtime. It is in fact a set of integrated tools that allow you to build ship and run distributed applications. That means Docker handles networking, infrastructure, build, orchestration, authorization, security, and a variety of other services that cover the complete distributed application lifecycle.
The core container runtime, which is containerd, is a small but vital part of the platform. We started breaking out containerd from the rest of the engine in Docker 1.11, Continue reading
Today Docker is spinning out its core container runtime functionality into a standalone component, incorporating it into a separate project called containerd, and will be donating it to a neutral foundation early next year. This is the latest chapter in a multi-year effort to break up the Docker platform into a more modular architecture of loosely coupled components.
Over the past 3 years, as Docker adoption skyrocketed, it grew into a complete platform to build, ship and run distributed applications, covering many functional areas from infrastructure to orchestration, the core container runtime being just a piece of it. For millions of developers and IT pros, a complete platform is exactly what they need. But many platform builders and operators are looking for “boring infrastructure”: a basic component that provides the robust primitives for running containers on their system, bundled in a stable interface, and nothing else. A component that they can customize, extend and swap out as needed, without unnecessary abstraction getting in their way. containerd is built to provide exactly that.
What Docker does best is provide developers and operators with great tools which make them more productive. Those tools come from integrating many different components into a Continue reading
A few weeks ago I wrote a post about installing Ansible 2.2 on Fedora 25; today, I’d like to tackle what’s involved in installing Ansible 2.2 on Ubuntu 16.04. This post, like its Fedora counterpart, stems from my ongoing evaluation of Linux distributions and desktop environments. While the information here is very similar to the information in the Fedora post, I’m putting it in its own post in the hopes of making the information easier for readers to find.
It’s not really a secret that I like to run Ansible in a Python virtualenv, but I don’t believe that it will make any difference to the procedure described in this post. The errors that result when trying to install Ansible 2.2 without the necessary prerequisite packages should be the same either way (in a virtualenv or not). However, I’m happy to be corrected if someone knows otherwise.
To create a Python virtualenv, you’ll first need virtualenv installed. I prefer to install virtualenv globally for all users using this command:
sudo -H pip install virtualenv
Alternately, you could install it via a package, with apt install virtualenv
. As far as I can tell, either approach Continue reading
The holidays are upon us. And while we can't automate your gift wrapping, we can make your Playbook more festive.
Introducing Ansible holiday-themed cowsay!
Copy and paste this code:
---
curl "https://gist.githubusercontent.com/jlaska/14bc829af01526add07efcaa83582aaf/raw/5f4918be06ffa69ea848354c5563c6a2d7b59807/happy_holidays.sh" | bash
Decorations are popping up everywhere so why not in your Playbook?
Share your designs with #AnsibleCowsay @ansible
Ascii sources: chris.com and ascii-code.com