Tag: Implement

Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now

How to Implement Chef roles using Chef server ?

by scmgalaxy KChefLeave a Comment on How to Implement Chef roles using Chef server ?

implement-chef-roles-using-chef-server

What is Role?

A role is a way to define certain patterns and processes that exist across nodes in an organization as belonging to a single job function. Each role consists of zero (or more) attributes and a run-list. Each node can have zero (or more) roles assigned to it. When a role is run against a node, the configuration details of that node are compared against the attributes of the role, and then the contents of that role’s run-list are applied to the node’s configuration details. When a chef-client runs, it merges its own attributes and run-lists with those contained within each assigned role.

How to use Roles in Chef?

  1. Create a Role and add the cookbooks into it.
  2. Assign the role into each node or bootstrap new nodes using roles
  3. The the run list

How to create Role?

Method 1: In Chef Server directly

> knife role create client1

&

Add the run list e.g. “recipe[nginx]” under “run_list”

Save & exit

The role will be created in Chef Server.

Example

{ "name": "client1", "description": "", "json_class": "Chef::Role", "default_attributes": { }, "override_attributes": { }, "chef_type": "role", "run_list": [ "recipe[nginx]", "recipe[phpapp::web]" ], "env_run_lists": { } }

Let’s download the role from the Chef server so we have it locally in a Chef repository.

> knife role show client1 -d -Fjson > roles/client1.json

Now, Lets bootstrap the node using knife with roles

> knife bootstrap --run-list "role[client1]" --sudo hostname

How to edit the roles in chef Server?

> knife role edit client1

Method 2: In local repo under chef-repo folder

> vi webserver.rb

example –

name "web_server" description "Role for web servers" run_list(   "role[base]",   "recipe{web_server]" )

& Then upload to chef server using following commands.

> knife role from file path/to/role/file

How Assigning Roles to Nodes?

> knife node list
> knife node edit node_name

This will bring up the node’s definition file, which will allow us to add a role to its run_list:

{ "name": "client1", "chef_environment": "_default", "normal": { "tags": [  ] 	}, "run_list": [ 	"recipe[nginx]" ] }

For instance, we can replace our recipe with our role in this file:

{ "name": "client1", "chef_environment": "_default", "normal": { "tags": [ ] }, "run_list": [ "role[web_server]" ] }

How to bootstrap node using role?

> knife bootstrap {{address}} --ssh-user {{user}} --ssh-password '{{password}}' --sudo --use-sudo-password --node-name node1 --run-list 'role[production]'
> knife bootstrap --run-list "role[phpapp-web]" --sudo hostname

How to run roles against nodes?

You can run chef-client on multiple nodes via knife ssh command like, To query for all nodes that have the webserver role and then use SSH to run the command sudo chef-client, enter:

> knife ssh "role:webserver" "sudo chef-client"

To find the uptime of all of web servers running Ubuntu on the Amazon EC2 platform, enter:

> knife ssh "role:web" "uptime" -x ubuntu -a ec2.public_hostname

Reference

http://docs.chef.io/roles.html

https://docs.chef.io/knife_ssh.html

https://docs.chef.io/knife_role.html

Tagged : / / / / / / / / / / / / /

How to use Gerrit to enhance your Code Analysis?

by scmgalaxy KCode AnalysisLeave a Comment on How to use Gerrit to enhance your Code Analysis?

gerrit-to-enhance-your-git/

Check the video at the bottom of the page.

Click here

Tagged : / / / / / / / / / / / / / /

How to Execute external commands by using perl?

by scmgalaxy KPerlLeave a Comment on How to Execute external commands by using perl?

execute-external-commands-from-perl

There are many ways to execute external commands from Perl. The most commons are:

  • system function
  • exec function
  • backticks (“) operator
  • open function

All of these methods have different behaviour, so you should choose which one to use depending of your particular need. In brief, these are the recommendations:

method use if …
system() you want to execute a command and don’t want to capture its output
exec you don’t want to return to the calling perl script
backticks you want to capture the output of the command
open you want to pipe the command (as input or output) to your script

More detailed explanations of each method follows:

Using system()
system() executes the command specified. It doesn’t capture the output of the command.
system() accepts as argument either a scalar or an array. If the argument is a scalar, system() uses a shell to execute the command (“/bin/sh -c command”); if the argument is an array it executes the command directly, considering the first element of the array as the command name and the remaining array elements as arguments to the command to be executed.
For that reason, it’s highly recommended for efficiency and safety reasons (specially if you’re running a cgi script) that you use an array to pass arguments to system()

Example:      #-- calling 'command' with  arguments    system("command arg1 arg2 arg3");         #-- better way of calling the same command    system("command", "arg1", "arg2",  "arg3");     The return value  is set in $?; this value is the exit status of the command as returned  by the 'wait' call; to get the real exit status of the command you have to  shift right by 8 the value of $? ($? >> 8).     If the value of $? is -1, then the command failed to execute, in that case you may check the value  of $! for the reason of the failure.
Example:      system("command",  "arg1");    if ( $? == -1 )    {      print "command failed: $!\n";    }    else    {      printf "command exited with value %d", $? >> 8;    }

Using exec()
The exec() function executes the command specified and never returns to the calling program, except in the case of failure because the specified command does not exist AND the exec argument is an array.
Like in system(), is recommended to pass the arguments of the functions as an array.

Using backticks (“)
In this case the command to be executed is surrounded by backticks. The command is executed and the output of the command is returned to the calling script.
In scalar context it returns a single (possibly multiline) string, in list context it returns a list of lines or an empty list if the command failed.
The exit status of the executed command is stored in $? (see system() above for details).

Example:      #-- scalar context    $result = `command arg1 arg2`;         #-- the same command in list context    @result = `command arg2 arg2`;     Notice that the  only output captured is STDOUT, to collect messages sent to STDERR you should  redirect STDERR to STDOUT
Example:      #-- capture STDERR as well  as STDOUT    $result = `command 2>&1`;

Using open()
Use open() when you want to:
– capture the data of a command (syntax: open(“command |”))
– feed an external command with data generated from the Perl script (syntax: open(“| command”))

Examples:      #-- list the processes  running on your system    open(PS,"ps -e -o pid,stime,args |") || die "Failed: $!\n";    while ( <PS> )    {      #-- do something here    }         #-- send an email to user@localhost    open(MAIL, "| /bin/mailx -s test user\@localhost ") || die  "mailx failed: $!\n";  print MAIL "This is a test message";
Tagged : / / / / / / / / / / / / / / /

How to Write Trigger in Perforce? – Perforce Triggers Guide

by scmgalaxy KPerforceLeave a Comment on How to Write Trigger in Perforce? – Perforce Triggers Guide

trigger-in-perforce

1 Introduction
Perforce introduced the first server-side trigger in release 99.1 with the pre-submit trigger. This trigger satisfied a long-standing desire in the user community, but demand continued for more hooks. In release 2004.2, Perforce squarely hit the need with the addition of five new trigger types. Release 2005.1 adds yet one more trigger type to this list rounding out one of the categories of triggers to completeness. This paper discusses triggers, techniques for implementing them and purposes for using them. It presumes a general knowledge of scripting. The examples follow in several programming languages. They should be easy to follow with knowledge of general programming, and any more arcane constructs will be explained. The paper also presumes a reasonable knowledge of Perforce scripting alternatives, such as that presented in [Bowles2005]. Although this paper will address the scripting of triggers comprehensively, it will refer to other Perforce scripting contexts and to Perforce commands with an assumption of familiarity.

1.1 What is a trigger?
Triggers are programs that run on the server immediately in response to some welldefined event in Perforce. Therefore, the context for a trigger is running on the server
using the trigger mechanism to start. Triggers are typically written in a shell script such as Perl, Python or Ruby due to the flexibility and facilities they provide. However, triggers can be written in any programming language that can interface with Perforce, including UNIX shell (sh, ksh, csh and work-alikes) and compiled languages like C/C++.

1.2 Types of triggers
Triggers fall into two categories. Pre-submit triggers enable actions in response to the submission of changelists. Form triggers allow actions in response to various stages of the life cycle of a form, regardless of the form type. This section provides a brief overview of the trigger types in preparation for the more detailed discussion.
1.2.1 Pre-submit triggers
There are three types of pre-submit triggers corresponding to different points in the life cycle of a submission.
• “Submit” triggers execute after the changelist has been created but before the files have been transferred, allowing inspection of the changelist details but disallowing file inspection.
• “Content” triggers execute after file transfer but before commit, allowing for inspection of the files.
• “Commit” triggers execute after the commit, allowing inspection of the changelist and file contents, but disallowing canceling of the submission.

1.2.2 Form triggers
Form triggers come in four types depending on the point in the form’s life cycle in which they are invoked.
• “Out” triggers execute when the form is generated and can modify the form before it is presented to the user.
• “In” triggers execute when the form is sent back to Perforce but before it is parsed, also allowing modification of the form on its way in.
• “Save” triggers execute after the form has been parsed but before it is saved, allowing reaction to the form but not modification.
• “Delete” triggers execute before a form is deleted, allowing failure of the deletion.

1.3 Why use a trigger?
Knowing why to use a trigger is partially a matter of knowing what are the competing alternatives. The alternatives naturally come from other contexts, since triggers define a context of their own. This section details the salient operational characteristics of triggers and contrasts them with Perforce alternatives. The three primary alternatives to triggers are wrapper scripts, such as p4wrapper, 1 review daemons, and journal tailers. A variation on the wrapper script would be a script available from the Tools menu in P4Win.

1.3.1 Synchronous execution
Triggers execute synchronously in response to their associated event. This provides an immediacy of response that is sometimes required or at least highly desirable. One option that provides synchronous execution could be an action invoked from a wrapper script such as p4wrapper. Another option would be to forego synchronous execution and rely on frequently running review daemons. Journal tailers would also perform asynchronously, although with very rapid and event-driven response.
1.3.2 Immediate user feedback on error
Triggers can provide messages back to the user, but only on error. Messages are not delivered on successful execution. A wrapper script can deliver messages to the user regardless of whether an error occurs or not. Review daemons and journal tailers can only provide feedback through indirect mechanisms.
1.3.3 Enforceability
Enforceability refers to the ability of an administrator to ensure that the script will run regardless of the client program used to initiate the operation. Because triggers are
installed on and executed by the server in response to server events, they will execute regardless of the client program. Wrapper scripts will only be invoked when the wrapper is used, whereas direct use of p4 or use of a different client program will circumvent the desired action. Review daemons and journal tailers are also enforceable due to their context on the server.

1.3.4 Modify a form
Form triggers can modify a form as it is delivered to the user or as it is sent back to Perforce. Wrapper scripts share this characteristic. Review daemons and journal tailers can not modify forms except to the extent that any user or administrator can after the operation has finished.
1.3.5 Customize any action
Form triggers have a limited ability to customize actions that involve forms, but they do not have the ability to react to any arbitrary command. Similarly, pre-submit triggers can only react to submits. Review daemons can only react to commands whose side effects can be reliably observed, something that is not readily available from the command line in many cases or from review mechanisms. Journal tailers have the ability to react to any action that affects database entries, which includes almost all.
1.3.6 Optimization for bulk processing
The review mechanism gives the ability to process a large number of actions in an orderly and efficient manner as long as those changes impact a counter. This optimization is not readily if at all available to triggers, wrappers or journal tailers due to their association with individual commands or journal entries.

1.3.7 Deterministic execution
Triggers and wrappers provide an exact and deterministic understanding of when they will execute relative to the command that initiates them. Review daemons are generally driven in a time-based manner and therefore do not execute deterministically relative to the Perforce command. Journal tailers are closer to deterministic than review daemons, but can conceivably execute prior to completion of a command.
1.3.8 Summary
The following table summarizes the characteristics of the scripting contexts that compete with triggers for Perforce scripting.

 

Tagged : / / / / / / / / / / / / / / / / / /
Pages: 1 2 3 4