This is what have been seen before:

• Sparrowdo automation. Part 5. Managing services and processes.

• Sparrowdo automation. Part 4. Managing users and groups.

• Sparrowdo automation. Part 3. Installing system packages.

• Sparrowdo automation. Part 2. Dealing with http proxy servers

• Sparrowdo automation. Part 1. Installing cpan packages

Well, while keep writing a sparrowdo tutorial the tool keep growing too. Let me introduce something new and excited about sparrowdo automation - how one can easily create a higher level entities using so called sparrowdo modules.

Sparrowdo modules ...

So far we have talked about some sparrowdo primitives. They are light, they are small and they relate to a small specific tasks, under the hood they are just sparrow plugins with parameters - sparrowdo tasks.

Well, here is the list to recall a few:

• System packages - package-generic plugin
• CPAN packages - cpan-package plugin
• Users and groups - are user and group plugins
• Linux Services are represented by service plugin
• And more and more and more ...

And so on, you can see all of them here, on sparrowhub site - https://sparrowhub.org/search. Most of sparrow plugins are just black boxes to solve a specific task. More or less plugins are just primitives.

Take a look at chef resources or ansible modules - they are probably of the same nature.

Now let's me introduce a sparrowdo module - a container for sparrow plugins.

Consider a quite common task. Installing Nginx web server. Having looked at sparrow toolkit we have all necessary bricks to "build" a running Nginx server:

• Package-generic plugin to install nginx package
• Service plugin to enable and run nginx service

Let's write code then:

use v6;

unit module Sparrowdo::Nginx;

use Sparrowdo;

our sub tasks (%args) {

  task_run  %(
    task => 'install nginx',
    plugin => 'package-generic',
    parameters => %( list => 'nginx' )
  );

  task_run  %(
    task => 'enable nginx',
    plugin => 'service',
    parameters => %( service => 'nginx', action => 'enable' )
  );

  task_run  %(
    task => 'start nginx',
    plugin => 'service',
    parameters => %( service => 'nginx', action => 'start' )
  );


}

Ok. The code is quite simple, I just want to add some vital comments here.

• Sparrowdo modules are plain Perl6 modules.

• You need to load Sparrowdo module to export some sparrowdo API functions, like task_run or others.

• You have to define at least a tasks(%args) function gets called when someone else use your modules, see how later

• You optionally may handle some arguments get passed into your module, see tasks function signature.

• And finally sparrowdo module is just a container for some sparrowdo tasks get called sequentially .

Ok. Now lets use our new sparrowdo module.

First step we need to ensure that module installed at the server where from we are going to run a sparrowdo tasks:

$ panda install Sparrowdo::Nginx

Ok when we are ready with module install we have two ways here.

1. running module as is

2. using module inside sparrowdo scenario.

Running module as is

This is the simplest way. This is very similar to running ansible modules:

sparrowdo --host=127.0.0.1 --module_run=Nginx

Running module via sparrowfile

Of course one can just use sparrowdo module using sparrowdo API

$ cat sparrowfile

run_module 'Nginx';

Sparrowdo uses a convention about modules names, it cut a Sparrowdo:: prefix from module name when run it via run_module function. So the rule is simple:

| Module Perl6 Name | Run_module $name parameter |
+-------------------+----------------------------+
| Sparrow::Foo::Bar | 'Foo::Bar'                 |

A current version of Sparrowdo::Nginx ignore an arguments, one day it would be possible to call 'Nginx' module with parameters:

run_module 'Nginx', %( port => 81 );

Little helpers for developers life

Sparrowdo provides some essentials helpers to simplify some developers tasks.

Guessing a target OS

It's very usual when we need to know a target server OS name to make a right decision about server configuration. Let me show you. Recall Nginx module, for centos we need install a repository so nginx package is not here by default:

our sub tasks (%args) {

  if target_os() ~~ m/centos/ {

    task_run  %(
      task => 'install epel-release',
      plugin => 'package-generic',
      parameters => %( list => 'epel-release' )
    );

  }

Passing a sparrowdo command line parameters

Remember a post on installing CPAN packages on the servers with http proxy restrictions?

Consider this sparrwodo module to install CPAN modules:

use v6;

unit module Sparrowdo::CpanInstall;

use Sparrowdo;

our sub tasks (%args) {

  task_run  %(
    task => 'install cpan modules',
    plugin => 'cpan-package',
    parameters => %( 
      list => %args<list>,
      http_proxy => input_params('HttpProxy'), 
      https_proxy => input_params('HttpsProxy'), 
    )
  );

}

And sparrowfile:

module_run 'CpanInstall' %(
  list => 'DBI Moose Mojolicious'
);

And finally sparrowdo scenario run:

$ sparrwodo --host=<$some-host> --http_proxy=<$http_proxy>  --https_proxy=<$https_proxy>

An input_params($param_name) function will pass all the sparrowdo client parameters back to Sparrowdo::CpanInstall module.

Conclusion

Sparrowdo modules are high level members of sparrowdo echo system. What is good they are just Perl6 modules. Anybody who codes at Perl6 could easily start a new ones ( a basic knowledge of existed sparrow plugins is required though ).

Here is a short list of my ones:

https://modules.perl6.org/#q=Sparrowdo%3A%3A

Will be happy to see a new members of Sparrowdo::* family at Perl6 modules repository.

Regards and have a good weekend.

Alexey Melezhik

Finally I decided not to use Test::More and Perl Test-Harness in Outthentic anymore.

These are the great tools proven in many many testing projects. But Outthentic tends to be more general purpose framework to run ANY scripts, rather than being a test framework only. Some testing facilitates are still here, but they poorly use a Test::More/Test-Harness entities, so I decided to rewrite story runner to get an asserts execution results in free style - so no TAP indeed is required.

$ cat story.pl 

print "hello from perl";


$ cat story.check 
hello from perl


$ strun 

/ started

hello from perl
OK  scenario succeeded
OK  output match 'hello from perl'
---
STATUS  SUCCEED

Such a changes might result in potential breakage for some sparrow plugins but I will fix it soon.

-- Regards

Alexey Melezhik

HI!

This time I want to tell you how to manage services and processes using sparrowdo.

Before this post a following list of topics was written by me:

• Sparrowdo automation. Part 4. Managing users and groups.

• Sparrowdo automation. Part 3. Installing system packages.

• Sparrowdo automation. Part 2. Dealing with http proxy servers

• Sparrowdo automation. Part 1. Installing cpan packages

As services are highly coupled with processes we will investigate them in one post.

Let's have an nginx web server gets installed on your system:

$ cat sparrowfile

use v6;

use Sparrowdo;

task_run  %(
  task => 'install nginx server',
  plugin => 'package-generic',
  parameters => %( list => 'nginx' )
);

We talked about package-generic plugin at this post. We use this plugin to install system packages.

Ok. This is very logical now having installed an nginx to make it "bootable", so next reboot of our system will pickup an nginx and make it sure it runs too. Some people call this autoload:

$ cat sparrowfile

use v6;

use Sparrowdo;

task_run %(
  task => 'enable nginx service',
  plugin => 'service',
  parameters => %( action => 'enable', service => 'nginx' )
);

task_run %(
  task => 'start nginx service',
  plugin => 'service',
  parameters => %( action => 'start', service => 'nginx' )
);

A service plugin makes it possible to enable and disabling Linux services, as well as starting and stopping them. It's very simple yet useful plugin for those who want to automate Linux services on target hosts.

At example here we not only make it nginx autoloadable enabling it, but also make it sure it starts. So good so far.

Well time goes and we need to ensure that nginx server is running. There are more than one way to do this.

The simplest one is to look up in a processes tree a process related to nginx master. This is what I usually do first when troubleshoot nginx server issues.

$ cat sparrowfile

use v6;

use Sparrowdo;

task_run  %(
  task => 'check my nginx master process',
  plugin => 'proc-validate',
  parameters => %(
    pid_file => '/var/run/nginx.pid',
    footprint => 'nginx.*master'
  )
);

A proc-validate plugin takes 2 parameters at input. The first one is the path to file where PID is written, and the second optional one - Perl regular expression to identify a process at process tree. Even providing only the first parameter is enough but I also set a footprint to make my example more explanatory.

Summary

We've learned how to manage Linux services with the help of sparrowdo. It's easy and it makes your routine tasks automated. And if you want to add some "audit" to your running services, which of course sounds reasonable for maintainers jobs the easiest way to start with is using simple proc-validate plugin.

See you soon at our next topic.

Have a fun in coding and automation.

-- Alexey Melezhik