default

Chef Node Objects Defined!

Chef Node Objects Defined!

For the chef-client, two important aspects of nodes are groups of attributes and run-lists.

  1. An attribute is a specific piece of data about the node, such as a network interface, a file system, the number of clients a service running on a node is capable of accepting, and so on.
  2. A run-list is an ordered list of recipes and/or roles that are run in an exact order.

The node object consists of the run-list and node attributes, which is a JSON file that is stored on the Chef server. The chef-client gets a copy of the node object from the Chef server during each chef-client run and places an updated copy on the Chef server at the end of each chef-client run.

An attribute is a specific detail about a node. Attributes are used by the chef-client to understand:

  • The current state of the node
  • What the state of the node was at the end of the previous chef-client run
  • What the state of the node should be at the end of the current chef-client run

Attributes are defined by:

  • The state of the node itself
  • Cookbooks (in attribute files and/or recipes)
  • Roles
  • Environments

During every chef-client run, the chef-client builds the attribute list using:

  • Data about the node collected by Ohai
  • The node object that was saved to the Chef server at the end of the previous chef-client run
  • The rebuilt node object from the current chef-client run, after it is updated for changes to cookbooks (attribute files and/or recipes), roles, and/or environments, and updated for any changes to the state of the node itself

After the node object is rebuilt, all of the attributes are compared, and then the node is updated based on attribute precedence. At the end of every chef-client run, the node object that defines the current state of the node is uploaded to the Chef server so that it can be indexed for search.

default

Understand the chefignore file

The chefignore file is used to tell knife which cookbook files in the chef-repo should be ignored when uploading data to the Chef server. The type of data that should be ignored includes swap files, version control data, build output data, and so on. .

The chefignore file can be located in any subdirectory of a chef-repo: /, /cookbooks, /cookbooks/COOKBOOK_NAME/, roles, etc. It should contain sections similar to the following:

Example of chefignore


# Ignore editor swap files
*~
*.sw[a-z]

# Ignore top-level Subversion data
*/.svn/*

# Ignore all files in a directory
files/default/subdirectory/*
files/default/subdirectory/**

# OS generated files #
######################
.DS_Store
Icon?
nohup.out
ehthumbs.db
Thumbs.db

# SASS #
########
.sass-cache

# EDITORS #
###########
\#*
.#*
*~
*.sw[a-z]
*.bak
REVISION
TAGS*
tmtags
*_flymake.*
*_flymake
*.tmproj
.project
.settings
mkmf.log

## COMPILED ##
##############
a.out
*.o
*.pyc
*.so
*.com
*.class
*.dll
*.exe
*/rdoc/

# Testing #
###########
.watchr
.rspec
spec/*
spec/fixtures/*
test/*
features/*
examples/*
Guardfile
Procfile
.kitchen*
.rubocop.yml

# SCM #
#######
.git
*/.git
.gitignore
.gitmodules
.gitconfig
.gitattributes
.svn
*/.bzr/*
*/.hg/*
*/.svn/*

# Berkshelf #
#############
Berksfile
Berksfile.lock
cookbooks/*
tmp

# Cookbooks #
#############
CONTRIBUTING*
CHANGELOG*
TESTING*

# Strainer #
############
Colanderfile
Strainerfile
.colander
.strainer

# Vagrant #
###########
.vagrant
Vagrantfile

# Travis #
##########
.travis.yml

Reference 

https://docs.chef.io/chef_repo.html#chefignore-files

Tags: ,
default

Lets Understand the Ruby programming world in 5 mins!!!

Lets Understand the Ruby programming world in 5 mins?

Ruby
Ruby is a dynamic, interpreted, reflective, object-oriented, general-purpose programming language. It was designed and developed in the mid-1990s by Yukihiro “Matz” Matsumoto in Japan. The Currnet most latest stable release is Ruby 2.5.

Gem – A Ruby Package
A Gem is a Ruby application package which can contain anything from a collection of code to libraries, and/or list of dependencies that the packaged code actually needs to run.

Gems are formed of a structure similar to the following:

/[package_name] # The main root directory of the Gem package.
|__ /bin # Location of the executable binaries if the package has any.
|__ /lib # Directory containing the main Ruby application code (inc. modules).
|__ /test # Location of test files.
|__ README #
|__ Rakefile # The Rake-file for libraries which use Rake for builds.
|__ [name].gemspec # *.gemspec file, which has the name of the main directory, contains all package meta-data, e.g. name, version, directories etc.

One of the tools we will be using for creating Gems is Bundler.

Bundler
Bundler a gem to bundle gems. Bundler makes sure Ruby applications run the same code on every machine.

It does this by managing the gems that the application depends on. Given a list of gems, it can automatically download and install those gems, as well as any other gems needed by the gems that are listed. Before installing gems, it checks the versions of every gem to make sure that they are compatible, and can all be loaded at the same time. After the gems have been installed, Bundler can help you update some or all of them when new versions become available. Finally, it records the exact versions that have been installed, so that others can install the exact same gems.

RubyGems – A Package Manager
RubyGems is the default package manager for Ruby. It helps with all application package lifecycle from downloading to distributing Ruby applications and relevant binaries or libraries. RubyGems is a powerful package management tool which provides the developers a standardised structure for packing application in archives called Ruby Gem. The webiste is https://rubygems.org/

Rake
Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax. you must write a “Rakefile” file which contains the build rules.

Rails
Rails is a web application development framework written in the Ruby programming language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks. Experienced Rails developers also report that it makes web application development more fun.

bower
Web sites are made of lots of things — frameworks, libraries, assets, and utilities. Bower manages all these things for you. Bower can manage components that contain HTML, CSS, JavaScript, fonts or even image files. Bower doesn’t concatenate or minify code or do anything else – it just installs the right versions of the packages you need and their dependencies.

yarn
Yarn caches every package it has downloaded, so it never needs to download the same package again. It also does almost everything concurrently to maximize resource utilization. This means even faster installs.

If i have missed any tools which is important of Rudy ecospace, please mentioned in the comments sections.

default

How to execute grovvy script remotely on Jenkins server?

A Jenkins Admin can execute groovy scripts remotely by sending an HTTP POST request to /script/ url or /scriptText/.

curl example via bash

curl -d "script=<your_script_here>" https://jenkins/script
# or to get output as a plain text result (no HTML)
curl -d "script=<your_script_here>" https://jenkins/scriptText

curl submitting groovy file via bash

curl --data-urlencode "script=$(< ./somescript.groovy)" https://jenkins/scriptText

curl submitting groovy file providing username and password via bash

curl --user 'username:password' --data-urlencode "script=$(< ./somescript.groovy)" https://jenkins/scriptText

Jenkins CLI offers the possibility to execute groovy scripts remotely using groovy command or execute groovy interactivelly via groovysh.

java -jar jenkins-cli.jar -noCertificateCheck -s https://10.0.0.91/ groovy disableEnableJobsMatchingPattern.groovy jobPattern=build_git_auto disableOrEnable=disable --username 12345 --password banana

Reference
https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console

 

 

default

How to run/execute groovy script in Jenkins?

Here are the List of way using you can apply grovy code in Jenkins

Method -1: Groovy plugin
This plugin adds the ability to directly execute Groovy code.
More info – https://wiki.jenkins.io/display/JENKINS/Groovy+plugin

Method -2: Jenkins script console
The inbuilt script console is a very useful and powerful Jenkins extension and ideally suits certain types of tasks. This simple but powerful built-in web console allows you to run Groovy scripts on your Jenkins instance (or its slave nodes) from directly within the user interface, and is installed as standard.

To access the console, either navigate to Manage Jenkins and then select Script Console, or simply append /script to your Jenkins host and port, like this for example: http://jenkinshost:8080/script
Running Script Console on the master
This feature can be accessed from “Manage Jenkins” > “Script Console”. Or visit the sub-URL /script on your Jenkins instance.

Running Script Console on agents
Visit “Manage Jenkins” > “Manage Nodes”. Select any node to view the status page. In the menu on the left, a menu item is available to open a “Script Console” on that specific agent.

More info – https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console

Method -3: Scriptler Plugins
Scriptler allows you to store/edit groovy scripts and execute it on any of the slaves/nodes… no need to copy/paste groovy code anymore.
More Info – https://wiki.jenkins.io/display/JENKINS/Scriptler+Plugin

Reference

https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console

 

default

Database of Groovy Script for Jenkins Automation

Here are the list of Groovy Script which can be used in Jenkins to automate the JOBs and CI process. Please add your list in the comment sections as well.

Main Source – 

  • https://github.com/scmgalaxy/jenkins-groovy-script-example
  • https://github.com/cloudbees/jenkins-scripts
  • https://wiki.jenkins.io/display/JENKINS/Jenkins+Script+Console
  • https://pghalliday.com/jenkins/groovy/sonar/chef/configuration/management/2014/09/21/some-useful-
  • jenkins-groovy-scripts.html
  • https://github.com/cloudbees/jenkins-scripts
  • https://github.com/jenkinsci/jenkins-scripts
  • https://gist.github.com/dnozay/e7afcf7a7dd8f73a4e05
  • https://github.com/samrocketman/jenkins-bootstrap-shared
  • https://github.com/samrocketman/jenkins-script-console-scripts

Example Groovy Script 

Tags: ,
default

Jenkins Architecture Explained!!!

Jenkins is continuous integration tools which help to integrate other tools to automate the software development activity and repetitive tasks. Jenkins has 2 releases. One, Community version which open source and free and another one is Jenkins Enterprise which is from Cloud bees for enterprise. Jenkins is extremely powerful with vast amount of plug-in supported. Jenkins is one of the most active open source projects so learning and finding the information is easily available on the internet. Jenkins uses master/slave architecture to manage distributed builds.
Jenkins Architecture

Jenkins Architecture is based on the distributed. This has 2 components.

  • Jenkins Server
  • Jenkins Node/Slave/Build Server

Jenkins server is a web dashboard which is nothing but powered from a war file, default run on 8080 ports. Using Dashboard, You can configure the Jobs/Projects but the build takes place in Nodes/Slave. By default one Nodes/Slave is configured and running in Jenkins Server. You can add more Nodes/Slave as well using IP address, user name, Password using the ssh/jnlp/webstart methods.

Your main Jenkins server is the master. In short, the master’s job is to handle scheduling build jobs, dispatching builds to the slaves for the actual execution, monitor the slaves (possibly taking them online and offline as required) and recording and presenting the build results. Even in a distributed architecture, a master instance of Jenkins can also execute build jobs directly.

The job of the slaves is to do as they are configured in the Jenkins Server, which involves executing build jobs dispatched by the master. You can configure a project to always run on a particular slave machine, or a particular type of slave machine, or simply let Jenkins pick the next available slave.
Jenkins is developed using Java and Java is platform independent thus Jenkins servers and nodes/slave can be configured in any servers including Windows, Linux and Mac.

default

Secure Tunnels to localhost using ngrok

Secure Tunnels to localhost using ngrok

ngrok is a free tool that allows you to expose a web server running on your local machine to the internet. It includes additional functionality that makes it easy to install and manage itself as a native operating system service on Windows, OS X and Linux.

It is is a multiplatform tunnelling, reverse proxy software that establishes secure tunnels from a public endpoint such as internet to a locally running network service while capturing all traffic for detailed inspection and replay.

The following are the issues that we were facing before Ngrok deployment:

  1. Unable to expose localhost application directly to internet without DMZ & other network configuration
  2. Unable to demonstrate an application to Client on urgent basis
  3. Unable to share websites for testing purpose
  4. Develop any services which consume Webhooks (HTTP CallBacks)
  5. Can’t share a website temporarily that is running only on our developer machine
  6. Time Consuming on network and DNS configurations
  7. Can’t debug or inspect HTTP Traffic in a precise manner
  8. Can’t run networked services on machines that are firewalled off from the internet
  9. Unable to expose application behind http proxy
  10. Unable to forward non-http and non-local network services

It’s really easy to install and use

ngrok is built in Go so it is packaged as binaries for each major platform. To install ngrok do the following:

  1. Download the package for your system
  2. Unzip the package
  3. There is no step 3!

Once you have ngrok installed, using it to tunnel to an application running on, say, port 3000 is as easy as:

$ ./ngrok http 3000

Once you’ve unzipped the ngrok executable move it to a folder that’s in your $PATH then you can run ngrok from anywhere you want on the command line by just typing:

$ ngrok http 3000

It has a dashboard
http://127.0.0.1:4040

You can secure your tunnels

$ ngrok http -auth "user:password" 3000

You can use custom subdomains

$ ngrok http -subdomain=thisisreallycool 3000

Tags: ,
default

run_list and env_run_list explanined in chef role

run-list
A run-list defines all of the information necessary for Chef to configure a node into the desired state. A run-list may include roles and/or recipes.

A run-list must be in one of the following formats: fully qualified, cookbook, or default. Both roles and recipes must be in quotes, for example:

'role[NAME]'
'recipe[COOKBOOK::RECIPE]'
'recipe[COOKBOOK::RECIPE],COOKBOOK::RECIPE,role[NAME]'

env_run_list
When you specify the env_run_list in role and the chef-client will pick up the _default run-list if env_run_list[environment_name] is null or nonexistent. env_run_list is only for roles.The env run list is an override, so it totally replaces the default non-env run list if the env matches.

{
 "name": "webserver",
 "default_attributes": {
 },
 "json_class": "Chef::Role",
 "env_run_lists": {
 "production": [],
 "preprod": [],
 "test": [ "role[base]", "recipe[apache]" "recipe[apache::copy_test_configs]" ],
 "dev": [ "role[base]", "recipe[apache]", "recipe[apache::copy_dev_configs]" ]
 },
 "run_list": [ "role[base]", "recipe[apache]" ],
 "description": "The webserver role",
 "chef_type": "role",
 "override_attributes": {
 }
}

where:

  • “webserver” is the name of the role
  • “env_run_lists” is a hash of per-environment run-lists for production, preprod, test, and dev
  • “production” and “preprod” use the default run-list because they do not have a per-environment run-list
  • “run_list” defines the default run-list

Reference
https://docs.chef.io/run_lists.html

Getting Started with Chef Server. Part 2

default

How to run chef-client in why-run mode aka “no-operation”

why-run mode is a way to see what the chef-client would have configured, had an actual chef-client run occurred. This approach is similar to the concept of “no-operation” (or “no-op”): decide what should be done, but then don’t actually do anything until it’s done right. Run the executable in why-run mode, which is a type of chef-client run that does everything except modify the system.

When why-run mode is enabled, a chef-client run will occur that does everything up to the point at which configuration would normally occur. This includes

  1. Getting the configuration data,
  2. Authenticating to the Chef server,
  3. Rebuilding the node object,
  4. Expanding the run-list,
  5. Getting the necessary cookbook files,
  6. Resetting node attributes,
  7. Identifying the resources, and
  8. Building the resource collection and
  9. Does not include mapping each resource to a provider or configuring any part of the system.

How to run chef-client?

$ sudo chef-client -o 'recipe[ntp]' --why-run
$ sudo chef-client -o 'recipe[ntp]' -W

© Tutorials
CyberChimps