This post explains output of free command in Ubuntu 16.04 paying special attention to information missing in documentation.

Understanding output

Let’s look at free output in humanreadable, wide mode:

free -hw
        total   used   free   shared   buffers   cache   available
Mem:     2.0G   566M   860M      14M       41M    531M        1.2G
Swap:    4.0G     0B   4.0G

This post explains ifconfig output of common developer’s box, paying special attention to parameters poorly explained in official documentation. It also slightly touches Linux network interfaces.

ifconfig

ifconfig is a command line tool for UNIX-like systems that allows for diagnosing and configuring network interfaces. At boot time, it sets up network interfaces such as Loopback and Ethernet. Most of the time, however, ifconfig is used for network diagnostics.

Before diving into details of its output, let’s first make clear what is an interface.

Previous post covers bare minimum of curl you need to know for testing RESTful microservices. Read it first if you need basics. This writing focuses on corner cases and advanced options, making curl experience more enjoyable.

There are plenty of tools available for testing RESTful microservices today. Most of them, e.g. SoapUI, are comprehensive solutions and best fit for creating testing suites. Using such a tool to check a single faulty endpoint would be an overkill.

So what should you choose for ad hoc testing instead? There are simplified GUI tools, e.g. Postman, and many developers are happy with them. But if you are after ultimate performance and love command line, there is a better option - curl. In this post I’ll show how to check RESTful endpoints using curl with a lot of examples.

You are lucky if you’ve never been involved into confrontation between devops and developers in your career on any side. In this post I’ll show a solution to an issue which is often under dispute - access to application logs in production.

The issue at hand

Imagine you are a devops responsible for running company applications in production. Applications are supported by developers who obviously don’t have access to production environment and, therefore, to production logs.

Imagine that each server runs multiple applications, and applications store logs in /var/log/apps. A server with two running applications will have log layout:

$ tree /var/log/apps

/var/log/apps
├── alice.log
└── bob.log

The problem: How to let developers access their production logs efficiently?

While ad hoc commands are indispensable for learning Ansible and executing one time tasks, playbooks are real workhorses. In this introductory post I will explain the essence of a playbook on example.

So what is a playbook?

At the first glance, it’s a file written in YAML that contains a list of plays. If we look closer, we’ll see that a playbook file is a mixture of configuration and script concepts. On one hand, it specifies the desired configuration of systems. On the other hand, like in a script, it defines in which order tasks must be executed in a play.

It’s better to see once than to hear 100 times. This is a playbook we’ll use as an example:

---
- hosts: frontend,backend
  remote_user: yury
  become: True
  tasks:
  - name: ensure golang is at the latest version
    apt: name=golang state=latest
- hosts: frontend
  remote_user: yury
  become: True
  tasks:
  - name: ensure apache is at the latest version
    apt: name=apache2 state=latest
  - name: write the apache config file
    template:
      src: conf/apache2.j2
      dest: /etc/apache2/apache2.conf
    notify:
    - restart apache
  - name: ensure apache is running
    service:
      name: apache2
      state: started
  handlers:
    - name: restart apache
      service:
        name: apache2
        state: restarted

Patterns is a set of expressions in Ansible that lets us specify concisely which systems a playbook or an ad hoc command must be applied to. In this post we will consider most useful pattern expressions and demonstrate them on examples.

In examples we will use module ping, which doesn’t produce much output. If you never worked with it before, ping module just pings all systems selected by pattern. Also we will make use of -o option, which condenses output to one line per system.

In general, our ad hoc commands will look like:

ansible <pattern> -m ping -o

In previous posts we created a cluster of VMs and set up Ansible to manage the cluster. So we have a cluster of VMs ready to play with. Today we will explore Ansible with a bunch of ad hoc commands, which is the easiest way to get a flavour of cluster management.

Ansible

Before going any further it’s important to understand Ansible philosophy, because it drastically differentiates Ansible from similar tools.

In contrast to Puppet and other tools that automate execution of commands on remote systems, Ansible manages remote systems’ state. In Ansible you specify a state that remote systems have to get in and it’s up to Ansible to execute appropriate commands to ensure the state is achieved. Therefore, most of Ansible commands are idempotent and do nothing if a remote system is already in requested state.

State management is at heart of Ansible design, but sometimes it’s necessary just to execute a command on remote systems. You can do it with Ansible too, although it is not a recommended approach in general.

Last time we created a cluster of VMs on Mac OS X. In this post you will learn how to setup Ansible to manage the cluster.

There are many performance analysis and troubleshooting tools for software engineers nowadays. The most popular among them are debuggers and profilers, which hook up to your program and show what’s going on or how much resources are occupied by who. These tools usually work in user space and don’t tell you much about how your program interacts with OS kernel. So if you need an ultimate drill down tool, DTrace could be the one.

Dtrace is included by default with Solaris, Mac OS X and FreeBSD. There is an equivalent for Linux, Strace, but it is not as great for troubleshooting production environments.