Both tools can handle these type of work as well.

In this blog I will try to provide you information from all aspect which going to help you to choose between Puppet vs Chef. Discuss everything from the comparison to differences, pros and cons also. This guide is definitely going to help you in your decision of which server to work with. Let’s start-

What is Chef?

Chef is an open-source and code-driven configuration management tool used to transform infrastructure into code. It is well-known for automate how infrastructure is deployed, configured, and managed. Chef can also operate in the cloud, on premises, or even in a hybrid format that comfortable for each individual’s needs.

What is Puppet?

Puppet is another open-source configuration management tool, which is deemed to be the industry standard for configuration management. This tool is designed in a simple way that most users can learn, but it is complex enough to handle difficult level tasks and infrastructure.

System administrators and IT professionals are able to do a variety of tasks like managing large infrastructures to maintenance of the desired states of nodes.

Chef vs Puppet: Important Differences and Similarities

Chef and Puppet both are very promising configuration management software tools,  we are here to discuss some of their differences and similarities. Both the tools are simple to use and capabilities to automate complex high level IT application environment.

This differences are on the basis of different factors such as Availability, Configuration Language, Setup and Installation, Ease of Management, Scalability, Interoperability, Tool Capabilities and Pricing. These are:

Reports says, IT departments with a strong DevOps workflow deploy software 200 times more frequently, with 3000 times faster lead times, recover 28 times faster, and have three times lower change failure rates.

Final words

Here comes the main question that How to choose between Chef and Puppet, and the answer is it totally depends on the user’s requirements and purpose for which it going to be used.

No matter what you use at the end but decision is especially from the ones who will end up working with the tool. Someone with the same background might find it more suitable to use Puppet or Chef, before taking the decision also consider the premium features from each tool. At the end, features will help your organization in growth or fall.

Pricing is another factor which included but prices fluctuates a lot with time, and it varies depending on each customer needs.

At last both tools have their own advantages and categories in which they are better than the other. My only intention here is to help you in your decision making. So, it is necessary that you choose the appropriate tool which can be fitted according to your needs.

I hope this blog is helpful for you, and if you want to learn more depth knowledge about Chef and Puppet, I would suggest you DevOpsSchool, One of the best institute for training and certification online.

Thank you !!

The post What is Chef and Puppet? appeared first on scmGalaxy.

Recent studies shows that the global DevOps market size reached USD 5.8 billion in 2021 and is projected to attain USD 14.97 billion by 2026 with a CAGR of 19.1% during the forecast period.

There are a number of latest DevOps configuration tools such as Chef, Puppet, and Ansible with various features available in the market. So, there is an inevitable need for the comparison of various configuration tools to identify the best tool for the success of DevOps projects.

What is Ansible?

Ansible is a latest configuration management tool which makes configuration management and coordination system of computer very easy to user.

What is Puppet?

Puppet is the oldest version of configuration management system and hard to understand for user.

What is Chef?

Chef is newer than Puppet but older version than Ansible so it is easier than Puppet but not than Ansible configuration system.

Here we do comparison of the top configuration tools including Ansible, Puppet and Chef:

First of all these tools are simple to use and robust capabilities to automate complex multi-tier IT application environment.

The differences between Ansible, Chef and Puppet are portrayed on the basis of different factors including Availability, Configuration Language, Setup and Installation, Ease of Management, Scalability, Interoperability, Tool Capabilities and Pricing:

IT departments with a strong DevOps workflow deploy software 200 times more frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower change failure rates.

Conclusion

As you can see above, chef and puppet are the old players with the time whereas Ansible is new players in the market, and Ansible looks very promising with the growing trend. So, to conclude, all the three tools have their own advantages and categories in which they are better than the other. My only intention here is to help you in your decision making. So, it is necessary that you choose the appropriate tool which can be fitted according to your needs.

If you want to know more about Ansible, you can check out this blog on Ansible, Puppet and Chef with complete information.

If you are curious to learn and make a good career with this skill then I would suggest you please check out DevOpsschool.com.

The post Which is better for automation: Ansible, Chef or Puppet? appeared first on scmGalaxy.

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.

The post Chef Node Objects Defined! appeared first on scmGalaxy.

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

The post Understand the chefignore file appeared first on scmGalaxy.

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
https://railsware.com/blog/2013/09/26/getting-started-with-chef-server-part-2/

The post run_list and env_run_list explanined in chef role appeared first on scmGalaxy.

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

The post How to run chef-client in why-run mode aka “no-operation” appeared first on scmGalaxy.

Chef Apply
chef-apply is an executable program that runs a single recipe from the command line. Is part of the Chef development kit. A great way to explore resources

Chef
The chef executable is a command-line tool which Generates applications, cookbooks, recipes, attributes, files, templates, and custom resources (LWRPs) and Ensures that RubyGems are downloaded properly for the chef-client development environment along with Verifies that all components are installed and configured correctly

Knife
knife is a command-line tool that provides an interface between a local chef-repo and the Chef server. knife helps users to manage Nodes, Cookbooks and recipes, Roles, Environments, and Data Bags, Resources within various cloud environments, The installation of the chef-client onto nodes, Searching of indexed data on the Chef server

Chef Client
The Chef client works with the Chef server to bring nodes to their desired states with policies you provide as recipes. The chef-client executable can be run as a daemon. A chef-client is an agent that runs locally on every node that is under management by Chef. When a chef-client is run, it will perform all of the steps that are required to bring the node into the expected state, including:

• Registering and authenticating the node with the Chef server
• Building the node object
• Synchronizing cookbooks
• Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and
• all other dependencies
• Taking the appropriate and required actions to configure the node
• Looking for exceptions and notifications, handling each as required

Chef Development Kit
The Chef development kit contains all you need to develop and test your infrastructure, built by the awesome Chef community. Chef Development Kit has following Component installed…

• fauxhai
• kitchen-vagrant
• openssl
• delivery-cli
• test-kitchen
• git
• berkshelf
• chefspec
• knife-spork
• inspec
• tk-policyfile-provisioner
• opscode-pushy-client
• chef-dk
• chef-sugar
• chef-client
• generated-cookbooks-pass-chefspec
• chef-provisioning
• package installation

Chef Server
The Chef server makes it easy to automate your infrastructure, manage scale and complexity, and safeguard your systems.

Chef Server has following tools which should be running…

• bookshelf
• nginx
• oc_bifrost
• oc_id
• opscode-erchef
• opscode-expander
• opscode-solr4
• postgresql
• rabbitmq
• redis_lb

InSpec
InSpec is an open-source testing framework for infrastructure with a human- and machine-readable language for specifying compliance, security and policy requirements.

Push Jobs Client
The Push Jobs client communicates with the Push Jobs server, which extends the Chef Server to allow you to execute commands across hundreds or even thousands of nodes in your Chef-managed infrastructure.

Push Jobs Server
The Push Jobs server add-on, along with its associated client, extends the Chef Server to allow you to execute commands across hundreds or even thousands of nodes in your Chef-managed infrastructure.

Supermarket
Supermarket is an artifact repository that makes it easy to browse, use, and share communal cookbooks and tools within your organization.

Chef Automate
One platform with a unified workflow, end-to-end visibility, and automated compliance over your entire Chef ecosystem.

Chef Compliance
Assess and monitor infrastructure compliance and use InSpec compliance profiles to validate that production servers are properly configured.

Chef Backend
Chef High Availability makes it easy to build high-availability Chef clusters on any infrastructure.

Chef Manage
Chef Manage is an Enterprise Chef add-on that enables a web-based user interface for visualizing and managing nodes, data bags, roles, environments, cookbooks and role-based access control (RBAC).

Kitchen or Test Kitchen
kitchen is the command-line tool for Kitchen, an integration testing tool used by the chef-client. Kitchen runs tests against any combination of platforms using any combination of test suites. Each test, however, is done against a specific instance, which is comprised of a single platform and a single set of testing criteria.

“Test Kitchen is an integration tool for developing and testing infrastructure code and software on isolated target platforms.” It creates test machines, converges them, and runs post-convergence tests against them to verify their state. Test Kitchen is written in Ruby. It has a plugin system for supporting machine creation through a variety of virtual machine technologies such as vagrant, EC2, docker, and several others. Test Kitchen makes it easy for Chef developers to test cookbooks on a variety of platforms. It uses busser to install post-convergence integration test tools such as Serverspec or BATS that actually perform the tests.

foodcritic
Foodcritic is a helpful lint tool you can use to check your Chef cookbooks for common problems.
http://www.foodcritic.io/

ChefSpec
ChefSpec is a framework that tests resources and recipes as part of a simulated chef-client run. ChefSpec tests execute very quickly. When used as part of the cookbook authoring workflow, ChefSpec tests are often the first indicator of problems that may exist within a cookbook.
ChefSpec is packaged as part of the Chef development kit. To run ChefSpec
$ chef exec rspec
https://docs.chef.io/chefspec.html

RuboCop
Rubocop is a Ruby command-line tool that performs lint and style checks based on the community driven Ruby Style Guide. It performs static analysis of any Ruby code, which includes Chef recipes, resources, library helpers, and so forth. Rubocop can be configured via .rubocop.yml to exclude certain rules, and it can be run with “–lint” to perform only lint checking, excluding all style checks. Rubocop is used in the Chef community in cookbooks to make contributions more consistent and easier to manage.

Serverspec
Serverspec is an “outside-in” integration test framework. It is platform and tool agnostic, and is used by other configuration management systems to verify systems are configured as desired. It checks the actual state of the target node by executing commands locally, via SSH, via WinRM, or other remote transports. Serverspec is implemented in RSpec, and uses RSpec test syntax.

The post Ecosystem of chef and Its associated tools explained appeared first on scmGalaxy.

How to install Chef Development Kit(ChefDK)?

The Chef development kit contains all you need to develop and test your infrastructure, built by the awesome Chef community. Its Chef Developer tool.

Platform – Linux RHEL

Download Chef Development Kit(ChefDK)

# Download Package URL from https://downloads.chef.io/chefdk/2.5.3
$ sudo -s
$ cd /opt/
$ yum install wget -y
$ wget https://packages.chef.io/files/stable/chefdk/2.5.3/el/7/chefdk-2.5.3-1.el7.x86_64.rpm

Install Chef Development Kit(ChefDK)

$ rpm -Uvh chefdk-2.5.3-1.el7.x86_64.rpm

warning: chefdk-2.5.3-1.el7.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 83ef826a: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:chefdk-2.5.3-1.el7               ################################# [100%]
Thank you for installing Chef Development Kit!

Verify Chef Development Kit(ChefDK) Quick way

$ chef -v
Chef Development Kit Version: 2.5.3
chef-client version: 13.8.5
delivery version: master (73ebb72a6c42b3d2ff5370c476be800fee7e5427)
berks version: 6.3.1
kitchen version: 1.20.0
inspec version: 1.51.21

Verify Chef Development Kit(ChefDK) Detailed way

$ chef verify
[WARN] This is an internal command used by the ChefDK development team. If you are a ChefDK user, please do not run it.
Running verification for component 'berkshelf'
Running verification for component 'test-kitchen'
Running verification for component 'tk-policyfile-provisioner'
Running verification for component 'chef-client'
Running verification for component 'chef-dk'
Running verification for component 'chef-provisioning'
Running verification for component 'chefspec'
Running verification for component 'generated-cookbooks-pass-chefspec'
Running verification for component 'fauxhai'
Running verification for component 'knife-spork'
Running verification for component 'kitchen-vagrant'
Running verification for component 'package installation'
Running verification for component 'openssl'
Running verification for component 'inspec'
Running verification for component 'delivery-cli'
Running verification for component 'git'
Running verification for component 'opscode-pushy-client'
Running verification for component 'chef-sugar'
.................................../opt/chefdk/embedded/lib/ruby/gems/2.4.0/gems/chef-provisioning-aws-3.0.2/lib/chef/resource/aws_route53_record_set.rb:48: warning: constant ::Fixnum is deprecated
cannot load such file -- fog
.......
---------------------------------------------
Verification of component 'fauxhai' succeeded.
Verification of component 'kitchen-vagrant' succeeded.
Verification of component 'openssl' succeeded.
Verification of component 'delivery-cli' succeeded.
Verification of component 'test-kitchen' succeeded.
Verification of component 'git' succeeded.
Verification of component 'berkshelf' succeeded.
Verification of component 'chefspec' succeeded.
Verification of component 'knife-spork' succeeded.
Verification of component 'inspec' succeeded.
Verification of component 'tk-policyfile-provisioner' succeeded.
Verification of component 'opscode-pushy-client' succeeded.
Verification of component 'chef-dk' succeeded.
Verification of component 'chef-sugar' succeeded.
Verification of component 'chef-client' succeeded.
Verification of component 'generated-cookbooks-pass-chefspec' succeeded.
Verification of component 'chef-provisioning' succeeded.
Verification of component 'package installation' succeeded.

The post How to install Chef Development Kit(ChefDK) appeared first on scmGalaxy.

week1 – Overview of Chef.pdf

The post week1 – Overview of Chef.pdf appeared first on scmGalaxy.

week2 – Node setup, resources & recipes

The post week2 – Node setup, resources & recipes appeared first on scmGalaxy.

week3 – Node setup, resources & recipes

The post week3 – Node setup, resources & recipes appeared first on scmGalaxy.

week4 – Common configuration data with data bags

The post week4 – Common configuration data with data bags appeared first on scmGalaxy.

week5 – Using environments and knife-ec2

The post week5 – Using environments and knife-ec2 appeared first on scmGalaxy.

week6 – Community cookbooks and further resources

The post week6 – Community cookbooks and further resources appeared first on scmGalaxy.

How to generate the pre populated information in metadata.rb in chef

You can configure the values in my knife.rb:

cookbookcopyright “Rajesh Kumar”
cookbooklicense “apachev2”
cookbook_email “rajesh@scmgalaxy.com”

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post How to generate the pre populated information in metadata.rb in chef? appeared first on scmGalaxy.

FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully

> knife bootstrap uvo1t75faaktzc532w6.vm.cld.sr -x root -P Br356YS0iy --sudo

Doing old-style registration with the validation key at /Users/rajesh.kumar/chef-repo/.chef/scmgalaxy-validator.pem...
Delete your validation key in order to use your user credentials instead

Connecting to uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr
> Existing Chef installation detected
uvo1t75faaktzc532w6.vm.cld.sr Starting first Chef Client run...
uvo1t75faaktzc532w6.vm.cld.sr [2015-08-20T12:01:37-04:00] WARN:
uvo1t75faaktzc532w6.vm.cld.sr * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
uvo1t75faaktzc532w6.vm.cld.sr SSL validation of HTTPS requests is disabled. HTTPS connections are still
uvo1t75faaktzc532w6.vm.cld.sr encrypted, but chef is not able to detect forged replies or man in the middle
uvo1t75faaktzc532w6.vm.cld.sr attacks.
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr To fix this issue add an entry like this to your configuration file:
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr ```
uvo1t75faaktzc532w6.vm.cld.sr # Verify all HTTPS connections (recommended)
uvo1t75faaktzc532w6.vm.cld.sr ssl_verify_mode :verify_peer
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr # OR, Verify only connections to chef-server
uvo1t75faaktzc532w6.vm.cld.sr verify_api_cert true
uvo1t75faaktzc532w6.vm.cld.sr ```
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr To check your SSL configuration, or troubleshoot errors, you can use the
uvo1t75faaktzc532w6.vm.cld.sr `knife ssl check` command like so:
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr ```
uvo1t75faaktzc532w6.vm.cld.sr knife ssl check -c /etc/chef/client.rb
uvo1t75faaktzc532w6.vm.cld.sr ```
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr Starting Chef Client, version 11.16.2
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr ================================================================================
uvo1t75faaktzc532w6.vm.cld.sr Chef encountered an error attempting to load the node data for "C2445575914.domain"
uvo1t75faaktzc532w6.vm.cld.sr ================================================================================
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr Authentication Error:
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr Failed to authenticate to the chef server (http 401).
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr Server Response:
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr Failed to authenticate as 'C2445575914.domain'. Ensure that your node_name and client key are correct.
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr Relevant Config Settings:
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr chef_server_url " api.opscode.com/organizations/scmgalaxy "
uvo1t75faaktzc532w6.vm.cld.sr node_name "C2445575914.domain"
uvo1t75faaktzc532w6.vm.cld.sr client_key "/etc/chef/client.pem"
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr If these settings are correct, your client_key may be invalid, or
uvo1t75faaktzc532w6.vm.cld.sr you may have a chef user with the same client name as this node.
uvo1t75faaktzc532w6.vm.cld.sr
uvo1t75faaktzc532w6.vm.cld.sr [2015-08-20T12:01:41-04:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
uvo1t75faaktzc532w6.vm.cld.sr Chef Client failed. 0 resources updated in 3.598799916 seconds
uvo1t75faaktzc532w6.vm.cld.sr [2015-08-20T12:01:41-04:00] ERROR: 401 "Unauthorized"
uvo1t75faaktzc532w6.vm.cld.sr [2015-08-20T12:01:41-04:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited u

I just login to the nodes and deleted all files under /etc/chef/ and rerun the commands and worked like charm.

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Fatal: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully appeared first on scmGalaxy.

Project 1 – Write a cookbook which can add your bash script in crontab on your nodes.

Project 2 – Perforce the following workflow of chef configuration management tools?

— create a new cookbook and add a recipe to it
— upload your cookbook to the Chef server
— configure your node’s run list
— run chef-client to trigger the configuration process on your target node

Project 3 – Write a cookbook with external cookbook_files in Chef?

Project 4 – Write a cookbook which can Set Chef Cookbook Dependencies in metadata file and use it?

Project 5 – Write a cookbook add jenkins slave nodes in jenkins master server using Chef cookbook?

Project 6 – Write a cookbook to configure nginx with chef solo on vagrant?

Project 7 – Write a cookbook to Setting up a MySQL database with a user with Vagrant and chef-solo?

Project 8 – Write a cookbook to track changes made to systems via knife in chef?

Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post Configuration management chef tools projects to test your skills? appeared first on scmGalaxy.

Error

gitlab-ctl reconfigure
Starting Chef Client, version 11.12.2
Compiling Cookbooks...
Recipe: gitlab::default
* directory[/etc/gitlab] action create (up to date)

[2014-11-03T12:38:40+05:30] ERROR: Exception handlers complete
[2014-11-03T12:38:40+05:30] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/chef-stacktrace.out
Chef Client failed. 0 resources updated in 3.925307977 seconds
[2014-11-03T12:38:40+05:30] ERROR: External URL must include a FQDN
[2014-11-03T12:38:41+05:30] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

more /etc/gitlab/gitlab.rb
# Check and change the external_url to the address your users will type in their browser
external_url ‘hostname:9999’
unicorn = 9090

Log file

Dumped to
/opt/gitlab/embedded/cookbooks/cache/chef-stacktrace.out

OS
RHEL 6.5
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited u
Solved after
hostname.dev.corp.local:9999
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

rajeshkumar replied the topic: FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited u
I am still not able to access the gitlab url from browsers…with following info….
gitlab-ctl show-config
Starting Chef Client, version 11.12.2
Compiling Cookbooks…
{
“gitlab”: {
“bootstrap”: {

},
“user”: {

},
“redis”: {

},
“gitlab-rails”: {
“secret_token”: “f276844818b47932ab27c670536111f68d4ad8d84e3d02a42a0f8be23e00c78a0094f62efbd08655f3430a9524258f39b82281e10d52c391c2e751f5747d45dc”
},
“gitlab-shell”: {

},
“unicorn”: {
“port”: 9090
},
“sidekiq”: {

},
“nginx”: {

},
“logging”: {

},
“remote-syslog”: {

},
“logrotate”: {

},
“high-availability”: {

},
“postgresql”: {

},
“web-server”: {

}
}
}
Converging 0 resources

Running handlers:
Running handlers complete

Chef Client finished, 0/0 resources updated in 10.57749914 seconds

gitlab-ctl status
run: logrotate: (pid 19510) 136s; run: log: (pid 10239) 4278s
run: nginx: (pid 20043) 2s; run: log: (pid 9765) 4365s
run: postgresql: (pid 19516) 135s; run: log: (pid 9569) 4393s
run: redis: (pid 19524) 135s; run: log: (pid 9432) 4475s
run: sidekiq: (pid 19529) 134s; run: log: (pid 9712) 4371s
run: unicorn: (pid 19534) 134s; run: log: (pid 9664) 4377s

more /etc/gitlab/gitlab.rb
external_url = ‘xysudyd.dev.corp.local:9999’
unicorn = 9090
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn

The post FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited u appeared first on scmGalaxy.

Chef Server
All logs generated by the Chef server can be found in /var/log/opscode. Each service enabled on the system also has a sub-directory in which service-specific logs are located, typically found in /var/log/opscode/service_name.

The Chef server has built-in support for easily tailing the logs that are generated. To view all the logs being generated on the Chef server, enter the following command:
> chef-server-ctl tail

To view logs for a specific service:
> chef-server-ctl tail SERVICENAME
where SERVICENAME should be replaced with name of the service for which log files will be viewed. SERVICENAME represents the name of any service that is listed after running the “> chef-server-ctl service-list” subcommand.

Another way to view log files is to use the system utility tail:
> tail -50f /var/log/chef-server/opscode-chef/current
> tail -50f /var/log/opscode/opscode-chef/current

Supervisor Logs
Supervisor logs are created and managed directly by the service supervisor, and are automatically rotated when a the current log file reaches 1,000,000 bytes. 10 log files are kept. The latest supervisor log is always located in /var/log/chef-server/service_name/current and rotated logs have a filename starting with @ followed by a precise tai64n timestamp based on when the file was rotated.

Supervisor logs are available for the following services:

1. bifrost
2. bookshelf
3. nginx
4. opscode-erchef
5. opscode-expander
6. opscode-expander-reindexer
7. opscode-solr4
8. postgresql
9. rabbitmq
10. redis

nginx

The nginx service creates both supervisor and administrator logs. The administrator logs contain both access and error logs for each virtual host utilized by the Chef server. Each of the following logs require external log rotation.

To follow the logs for the service:

 $ chef-server-ctl tail nginx

Chef Client

Client.rb3 file might help you. Default value of log_location is STDOUT. You can give /path/to/log_location in place of this. You can locate this client.rb file in C:\chef\client.rb or /etc/chef/client.rb directories.

Use the verbose logging that is built into the chef-client:
-l LEVEL, –log_level LEVEL
The level of logging to be stored in a log file.
-L LOGLOCATION, –logfile c
The location of the log file. This is recommended when starting any executable as a daemon. Default value: STDOUT.

Knife
Use the verbose logging that is built into knife:
-V, –verbose
Set for more verbose outputs. Use -VV for maximum verbosity.

chef-solo
-l LEVEL, –log_level LEVEL
The level of logging to be stored in a log file.

The Chef file and folder locations are different on Linux and Windows machines. This article explains the purpose of each file and the location.

Summary

When you test your cookbook in Test Kitchen

The .kitchen.yml file contains the username to execute the Chef cookbook. It is specified under platforms:, transport:, username:

Use that value in place of USER-NAME-FROM-KITCHEN-YML below.

 
Cookbook location

When the Chef recipes are executed, all cookbooks are stored on the node. You can examine the code to make sure your latest changes are reflected on the machine.

The log of the Chef client run

The output of the Chef cookbook execution is in the chef.log or chef-client.log file

On Windows

The log of the first Chef Client run and subsequent runs are stored in different log files. After the initial Chef Client run, the rest of the log entries are collected in the second file.

Stacktrace

Chef saves information on the hard drive when scripts are executed. If there is a failure, the stack trace of the last error is saved in the chef-stacktrace.out file.

Ohai output

All the information that Ohai collects on the instance, is saved in the failed-run-data.jsonfile, even if there is no error. It is a great resource to get the server specific values.

Reference

https://docs.chef.io/server_logs.html
https://docs.chef.io/debug.html

The post Logging in Chef Explained appeared first on scmGalaxy.

Chef notifies and subscribes explained with examples

Timers

Notifies

Subscribes

The post Chef notifies and subscribes explained with examples appeared first on scmGalaxy.